ISA 27 and U45(1) seem to be connected . which is A4
from that I'm just assuming that A5 is 2, A6 3, A7 4, A8 5, A9 6, A10 7 & A11 8
Took a look myself. I think I can confirm at U45:
Pin 1 (/G) = ISA A11 (AEN)
Pin 2 (P0) = ISA A27 (A4)
Pin 3 (Q0) = DIP switch 1
Pin 4 (P1) = ISA A26 (A5)
Pin 5 (Q1) = DIP switch 2
Pin 7 (Q2) = DIP switch 3
Pin 9 (Q3) = DIP switch 4
Pin 10 GND
Pin 11 (P1) = ISA A21 or A23 (A8 or A10)
Pin 12 (Q4) = DIP switch 5
Pin 13 (P5) = ISA A22 (A9), you see the via at the "top" edge of C32, and you see a different trace to Pin 11
Pin 14 (Q5) = DIP switch 6
Pin 15 (P6) = ISA A21 or A23 (A10 or A8)
Pin 16 (Q6) = DIP switch 7
Pin 17 (P7) = ISA A20 (A11), as A22 is routed on front side only and the traces for the other address lines block access to earlier pins
Pin 18 (Q7) = DIP switch 8
Pin 20 VCC
This mapping makes it extremely likely that your first guess to 0xB30 is actually correct, and switch 8 needs to be flipped to return the card to the default setting of 330.
Got some progress. Adjusted the dip switches to the suggested combo. It changes the status register from ff to 5. Tried a couple other combos and they all show ff.
One fascinating note is while the jumper is on 10 I get those same waiting_buff, dmabuff numbers from my earlier images that look like they aren't doing anything. If putting it at 11 out of curiosity, I get different numbers each time it tries
ISA 27 and U45(1) seem to be connected . which is A4
from that I'm just assuming that A5 is 2, A6 3, A7 4, A8 5, A9 6, A10 7 & A11 8
Took a look myself. I think I can confirm at U45:
Pin 1 (/G) = ISA A11 (AEN)
Pin 2 (P0) = ISA A27 (A4)
Pin 3 (Q0) = DIP switch 1
Pin 4 (P1) = ISA A26 (A5)
Pin 5 (Q1) = DIP switch 2
Pin 7 (Q2) = DIP switch 3
Pin 9 (Q3) = DIP switch 4
Pin 10 GND
Pin 11 (P1) = ISA A21 or A23 (A8 or A10)
Pin 12 (Q4) = DIP switch 5
Pin 13 (P5) = ISA A22 (A9), you see the via at the "top" edge of C32, and you see a different trace to Pin 11
Pin 14 (Q5) = DIP switch 6
Pin 15 (P6) = ISA A21 or A23 (A10 or A8)
Pin 16 (Q6) = DIP switch 7
Pin 17 (P7) = ISA A20 (A11), as A22 is routed on front side only and the traces for the other address lines block access to earlier pins
Pin 18 (Q7) = DIP switch 8
Pin 20 VCC
This mapping makes it extremely likely that your first guess to 0xB30 is actually correct, and switch 8 needs to be flipped to return the card to the default setting of 330.
So I'm looking at the suggested
8......1
11001100
from earlier?
erhm... either that one or
18......1 200110011
(you know the one where you only needed to change one switch)
Also,
if the software is looking for INT 10,
you want to set the card to INT 10 !
Pin 13 (P5) = ISA A22 (A9), you see the via at the "top" edge of C32, and you see a different trace to Pin 11
Pin 14 (Q5) = DIP switch 6
Pin 15 (P6) = ISA A21 or A23 (A10 or A8)
Pin 16 (Q6) = DIP switch 7
Pin 17 (P7) = ISA A20 (A11), as A22 is routed on front side only and the traces for the other address lines block access to earlier pins
Pin 18 (Q7) = DIP switch 8
Pin 20 VCC
This mapping makes it extremely likely that your first guess to 0xB30 is actually correct, and switch 8 needs to be flipped to return the card to the default setting of 330.
So I'm looking at the suggested
8......1
11001100
from earlier?
erhm... either that one or
18......1 200110011
(you know the one where you only needed to change one switch)
Also,
if the software is looking for INT 10,
you want to set the card to INT 10 !
So from 8 to 1, 00110011 shows the same ff Status Register from the start point or any other combo I've messed with. 11001100 does show a Status Register of 5. I moved the INT back to 10, but it was curious that 11 showed different results.
Edit: Posted a cleaner image of the board on the original post. And I may just be dumb and have old eyes and flipping my sides. But the one specific combination at least gets a step closer with the status register showing something different. There's 2 boards. Dirtier one doesn't pick up via the rs232 port. I suppose I could swap my current board with the dirtier one, adjust the dip switches, and see if it acts different
One fascinating note is while the jumper is on 10 I get those same waiting_buff, dmabuff numbers from my earlier images that look like they aren't doing anything. If putting it at 11 out of curiosity, I get different numbers each time it tries
That's the correct output for a working IRQ. I have no idea why you need to set it to "11". The DDBD.EXE posted in this thread is clearly hooking vector 0x72 and using bit 2 in port 0xA1 to modify the mask. If I'm not completely off track, that is IRQ10. Possibly the silk screen is wrong?
DDBD.EXE asks the DMA controller to transfer 14400 bytes at a time. int_flag = 38 means that in 38 invocations of IRQ10 (yes, IRQ10. I am confident I traced the track from the IRQ10 pin to the jumper position 11) at which the DMA controller indicated that a transfer was complete. So 38*14400 = 547200 bytes have been sucessfully transferred to the Data Delivery Board. The internal buffers in DDBD.EXE contain 57600 bytes each (four DMA blocks), and there are 6 of those buffers, which means 24 DMA blocks are in RAM while the program is running. 38 Interrupts means 24 interrupts for transferring all 24 DMA blocks once and then 14 more blocks, i.e. 3 full program buffers (0,1 and 2), and 2 blocks of the buffer named "3". This matches the program state with dma_buff = 3 indicating that the block that is currently transferred is positioned in DMA buffer 3.
count is the number of times the "wait for a buffer to get completely sent or error" loop exited, plus 6. As long as there is no error, this is the number of the next chunk (of 57600 bytes) to load from disk. In your case, there was an error, so chunk 14 has been loaded, and chunk 15 would be the next one to load if transferring the content from "buffer 3" would have worked. This matches up as well. Chunks 0..8 have completely been transferred to the Data Delivery Board, chunks 9..14 are in the program buffers, so 15 would be the next chunk to load. waiting_buf indicates which program buffer is the next one to be overwritten by a new chunk. As long as this is the same buffer as dma_buf, the program spins in a loop. This again is correct: Chunk 15 would need to be loaded into program buffer 3, which is not yet completely sent.
cal_count is the number of underruns, in which re-loading chunks from the file was not in time, so the program buffer ran empty. In that case, the last 4 chunks get re-sent, hoping that loading the next chunk will be available then. You had no buffer underruns, which is fine.
spur_int = 1 may be a clue. This means there was one invocation of IRQ10 in which the DMA controller did not report a completed transfer and the card did not report an error condition that would abort the program with a message claiming "overrun", so the tool has no idea why IRQ10 was invoked at that point in time. Obviously, on a spurious IRQ, the next DMA transfer is not going to be set up, as the previous transfer is still thought of being "in progress".
The timeout error happens if the loop that polls for a program buffer to get free to be reloaded is executed around 32 million times without a program buffer getting free. So there are two possible causes for the "timeout error":
Your computer is too fast. 32 million iterations can be validly executed while 57600 bytes are being transferred to the DDB.
For some reason, the IRQ is invoked early or the DMA controller does not correctly report a finished transfer, so a "transfer complete" IRQ is misidentified as "spurious IRQ", and the process halts.
What kind of computer do you use to run the tool? I guess the tool is meant to run on something like a 486DX/33 computer. If you use a Pentium system, try patching bytes 4E0F and 4F7F of DDBD.EXE from 01 to 1F, multiplying the timeout by 16.
Your computer is too fast. 32 million iterations can be validly executed while 57600 bytes are being transferred to the DDB.
For some reason, the IRQ is invoked early or the DMA controller does not correctly report a finished transfer, so a "transfer complete" IRQ is misidentified as "spurious IRQ", and the process halts.
Looking at the screenshots in more detail, I don't think your computer is too fast. The total transfer time seems to be around 6 seconds, with no blocks transferred (wrong IRQ) and with 9 blocks transferred. So the block transfer is likely significantly faster, and the total transfer time is just the timeout time.
The status register of the DMA controller reports "channel 0 completed" only once. If anything on your computer reads the DMA controller status register before the IRQ10 handler gets around to read that register, the "channel 0 completed" indication gets lost and the IRQ is mis-identified as spurious. If you have EMM386 or a similar memory manager loaded, try without. EMM386 needs to virtualize the DMA controller, and might access the status register on its own.
For the computer, I'm using an old HP NetServer 5/66 LC. Pentium 66MHz.
Below are my config and autoexec files. These apart from the name of the cd driver are the same ones that came with the floppy ddbd was on. Worth noting the 10secntr is just a simple 10 second countdown application to give the operator time to cancel the process before it auto started.
For the computer, I'm using an old HP NetServer 5/66 LC. Pentium 66MHz.
Just grasping straws: This computer is a PCI system with integrated SCSI. Do you know whether the SCSI controller tries to use IRQ10 as well? If the system is like the Compaq ProLiant line, it should have a system configuration utilitiy to manage system resources, including auto-configuration for "true" EISA and PCI cards. It might help to add a "custom ISA card" in that utility, and assigning DMA0, IRQ10 and Port 330-33F to that card, to ensure that these resources are kept free from being used by PCI. Furthermore, I wonder whether the EISA card expects the interrupt to be level triggered (ISA cards generally use edge triggered interrupts), and the board would need to be configured accordingly (this could be done using an EISA .CFG file, so maybe one needs to be written).
If setting Bit 2 in port 4D1 (for example using debug) fixes the issue, the issue is in fact about level triggered vs. edge triggered interrupts.
For the computer, I'm using an old HP NetServer 5/66 LC. Pentium 66MHz.
Just grasping straws: This computer is a PCI system with integrated SCSI. Do you know whether the SCSI controller tries to use IRQ10 as well? If the system is like the Compaq ProLiant line, it should have a system configuration utilitiy to manage system resources, including auto-configuration for "true" EISA and PCI cards. It might help to add a "custom ISA card" in that utility, and assigning DMA0, IRQ10 and Port 330-33F to that card, to ensure that these resources are kept free from being used by PCI. Furthermore, I wonder whether the EISA card expects the interrupt to be level triggered (ISA cards generally use edge triggered interrupts), and the board would need to be configured accordingly (this could be done using an EISA .CFG file, so maybe one needs to be written).
If setting Bit 2 in port 4D1 (for example using debug) fixes the issue, the issue is in fact about level triggered vs. edge triggered interrupts.
I adjusted the SCSI controller to use INT9. My HP ECU shows IRQ 10 and 11 both as available, as well as DMA0 and the full port range from 300h through 377h all clear. Tried a generic config file, however for some reason the ECU will not let me manually assign DMA0 to anything even though the utility shows it as a free resource. With the IRQ set to 10 and the IO at 330h-33fh, still no dice.
Edit: Went ahead and set a generic .cfg file with each of the IRQ 10 and 11 individually claimed and once with both claimed. Port 330-33F reserved. Still the same blocker.
Edit: Went ahead and set a generic .cfg file with each of the IRQ 10 and 11 individually claimed and once with both claimed. Port 330-33F reserved. Still the same blocker.
Are you able to edit the CFG file in a text editor? If yes, try adding "TRIGGER=LEVEL" after "IRQ=10".
Edit: Went ahead and set a generic .cfg file with each of the IRQ 10 and 11 individually claimed and once with both claimed. Port 330-33F reserved. Still the same blocker.
Are you able to edit the CFG file in a text editor? If yes, try adding "TRIGGER=LEVEL" after "IRQ=10".
The !ISA0000.CFG on my floppy disk didn't have DMA 0 selectable, but I edited it to allow. Selected DMA 0 for the board. Still nada.
I appreciate all the effort. Feels super close. Thankful at least 1 of these 2 boards still kind of lives. The other, dirtier one doesn't even give me those new values with the correct switch and jumper settings.
I'm unsure whether this is the right path to go down, but the transfer basically works until the DDB and DDBD.EXE get out of sync.
Made the changes and the ECU showed LEVEL instead of EDGE when making selections. However, when running ddbd.exe, I'm getting the same outputs of waiting_buff=0, etc. I was getting when I had the incorrect switch configuration.
Went back to the defaults (EDGE) and getting values again. But our friend spurious interrupt is still there.
Edit: Posted a cleaner image of the board on the original post. And I may just be dumb and have old eyes and flipping my sides. But the one specific combination at least gets a step closer with the status register showing something different. There's 2 boards. Dirtier one doesn't pick up via the rs232 port. I suppose I could swap my current board with the dirtier one, adjust the dip switches, and see if it acts different
Do those tiny SMD capacitors, like C15, have numbers on them ?
Also, any clue on what the buttons do ?
Also, is there a difference in rom , U38, U23, contents between the two boards ?
Last edited by weedeewee on 2025-01-02, 23:13. Edited 1 time in total.
Made the changes and the ECU showed LEVEL instead of EDGE when making selections. However, when running ddbd.exe, I'm getting the same outputs of waiting_buff=0, etc. I was getting when I had the incorrect switch configuration.
Went back to the defaults (EDGE) and getting values again. But our friend spurious interrupt is still there.
Thanks for testing. This means "EDGE" is correct. DDBD.EXE writes a file DDB.LOG that contains the messages printed to screen, as well as some more detailed debug info, including a "trace" of the last interrupts as a hex dump. Can you post the end of that log file (starting at the last "lcount timeout" line)?
weedeeweewrote on 2025-01-02, 23:11:Do those tiny SMD capacitors, like C15, have numbers on them ?
Also, any clue on what the buttons do ?
Also, is there a differ […] Show full quote
Edit: Posted a cleaner image of the board on the original post. And I may just be dumb and have old eyes and flipping my sides. But the one specific combination at least gets a step closer with the status register showing something different. There's 2 boards. Dirtier one doesn't pick up via the rs232 port. I suppose I could swap my current board with the dirtier one, adjust the dip switches, and see if it acts different
Do those tiny SMD capacitors, like C15, have numbers on them ?
Also, any clue on what the buttons do ?
Also, is there a difference in rom , U38, U23, contents between the two boards ?
Some yes, some no. On the image, you can make out the numbers on a few that have the black top to them. The more brown colored look like they all say "VA5" on the good board. Nothing on them on the not so good board. Each of the boards were dumped and each had a U23 and a U38. There's no difference at a quick eye glance between one board and the other.
Made the changes and the ECU showed LEVEL instead of EDGE when making selections. However, when running ddbd.exe, I'm getting the same outputs of waiting_buff=0, etc. I was getting when I had the incorrect switch configuration.
Went back to the defaults (EDGE) and getting values again. But our friend spurious interrupt is still there.
Thanks for testing. This means "EDGE" is correct. DDBD.EXE writes a file DDB.LOG that contains the messages printed to screen, as well as some more detailed debug info, including a "trace" of the last interrupts as a hex dump. Can you post the end of that log file (starting at the last "lcount timeout" line)?
I wonder what program the 80188 runs from U23 and what data it stores/retrieves from the nvram and what it talks about with the two XC3090 fpga chips that get their program from U38 and if invalid data in the nvram, considering the battery is dead, could cause data transfer to halt and if maybe some further digging into the serial interface might reveal some clues. 😀
I wonder what program the 80188 runs from U23 and what data it stores/retrieves from the nvram and what it talks about with the two XC3090 fpga chips that get their program from U38 and if invalid data in the nvram, considering the battery is dead, could cause data transfer to halt and if maybe some further digging into the serial interface might reveal some clues. 😀
What it should be doing is passing the data from the cd image in a continuous loop to the board. The cd image contains that month's lineup for Sega Channel. Then the board connects to some RF modulators. Then to an RF combiner. Then to a Sega Channel adapter, which was a really simple cable set-top box. The Sega Channel name was literal...in that it was a legitimate cable channel.
So via the serial interface, there are options if you are in test mode. It passes some ASCII text back and forth. Can translate from a table, but can't speak to what it means. I can get the general gist of it having the "whatchu doin'/nothin'" conversation, but anything else doesn't make sense to me. When outside of test mode, all you can do is initialize an adapter. It doesn't print any logs though. After testing a "configure ddb" option. It just passes the below and then goes back to generic pinging.
