raymv1987 wrote on 2025-01-02, 23:52:Went ahead and cleared the old logs and got a fresh one going. The program always spins 14 times before it goes to "abnormal program termination" based on my testing today: https://www.dropbox.com/scl/fi/0kindgwdd6d7zn … t=j6yy2n7j&dl=0
Sorry for the delay. I looked at the log file now. The first iteration is quite short, and thus easy to parse.
- F0 23 00 00: An IRQ was received, the value at port 330 was 23. The DMA controller indicated that a block of 14400 bytes from program buffer 0 have been transferred. The main loop is currently waiting for program buffer 0 to be completely transferred.
- F2 2b 00 00: An IRQ was received, the value at port 330 was 2b. (Don't get hung up on 23 vs. 2b) The DMA controller did not indicate that the second block of 14400 bytes has been "just completed" (That's F2 instead of F0). This might be due to two reasons: Either the block completion has already been indicated to a different reader of the status port, or the block has indeed not been completed. The status register did not indicate an "overrun error" (the low bit would be clear). So the IRQ handler classifies the interrupt as spurious.
- E0: The loop waiting for a buffer to get free exited. The reason is not indicated in the trace buffer.
- The message "lcount timeout" above the trace indicates the reason for exiting the main loop: ~6 seconds since loading the initial 6 chunks of the flle have passed without loading another chunk. THe timeout is dependent on CPU speed, but 6 seconds is likely well more than enough.
Looking at all the other traces, we find the same pattern. Only the first IRQ observes a status value of "23", all other IRQs observe a status value of "2b". This is not unexpected, because the control value sent to the card when setting up a 14400-byte transfer has bit 3 clear (like 23 also does) for the first block, and bit 3 set (like 2b also does) for all the other blocks. The different status thus has an obvious cause, and furthermore, we already observe 2b on the second IRQ, no matter wheter that IRQ is classified as spurious or not. The spurious IRQ is always the last IRQ before the timeout is observed.
There are still some reasons why this could happen:
- There is another party driving IRQ10, and that party uses level triggering. As soon as that party drives the IRQ line, the IRQ line is stuck, unable to receive any edges until that other party releases the IRQ ilne. This would only happen if the IRQ handler for that other party is invoked and acknowledges the IRQ. As you said that the system is "quite empty", and you reserved IRQ10 for the DDB in the ECU, I consider this unlikely.
- For some reason, the DDB cancels the data delivery, and triggers an IRQ to indicate that data delivery has been cancelled. It did in fact not receive the complete 14400 byte DMA block. The logic in DDBD.EXE is working correctly in detecting that it should not set up a new transfer yet. I consider this possiblility unlikely too, as I would expect to find some status indication for why the data delivery has been cancelled in the status register. The status register content is the same for the "spurious" IRQ and the "normal" IRQs.
- The data delivery board did trigger the IRQ because 14400 bytes have been received (no idea whether the DDB is counting bytes or reacting to the "terminal count (TC)" pin on the (E)ISA bus indicating the completion of a DMA transfer. For some reason the completion of the block is not detected when reading the DMA controller status register.
While I don't have a clue why the DMA controller should fail to indicate the completion of the last block, I still consider a false classification of the IRQ as spurious the most likely reason. As you seem to be able to execute DOS commands after "schedule" aborts due to repeated failure, we can investigate the state of the DMA controller. On shutdown, the state of DMA0 does not get reset, just transfers are blocked. So please run "DEBUG" after the program exits, and issue o0C 00 (to make sure the next byte read/written is the LSB) followed by i01 twice. If you read 00 two times, this indicates that the DMA transfer has finished by now. It does not necessarily indicate that the DMA transfer had finished when the IRQ ocurred, but I consider it likely. While the card could purposefully report the IRQ too early to compensate for the expected response time, I would put this idea aside for now. You can also try "i 08" to read the DMA status register. The lowest bit will be set if the DMA controller reports that DMA0 has finished since the last read of the status register. We don't know whether some other code (like the SCSI controller BIOS) also reads that register, so we can't know for sure whether the read of the status register by the IRQ10 handler in DDBD.EXE was the last one, but we do know that during the aborted transfer the main loop was spinning on polling variables and not reading the next chunk from disk, so even if the SCSI BIOS reads the status register (I don't think its likely), which might interfere with the DDB IRQ handler, the issue is independent from it.
If you detect that the transfer count is indeed zero, you can hack DDBD.EXE to treat "spurious" IRQs as "block complete" IRQs by patching it. This will most likely prevent the symptom of IRQ timeouts, bit will cause corruption of the data being transmitted if the "spurious" IRQ is too early. To achieve this, patch the bytes starting at 47BB from "FF 06 4A" to "E9 30 FE".
weedeewee wrote on 2025-01-03, 01:09: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 reverse engineerd that code. It seems to be the code that is sending and receiving the serial data packets shown in the AUTHSEGA screenshots. The FPGA closer to the 80188 is most likely an I/O address decoder and possibly implements some simple functions like flashing a "TX" and an "RX" LED. The combination of the right FPGA and the Altera Max CPLD likely handle the encryption and the transfer protocol to send the data to the modulator. Key material for the encryption seems to be transferred through the programmable logic ICs. The 80188 does not seem to process the data at all, it is a plain management CPU.
The DS1225 battery-backed RAM is the only RAM used by the 80188! The firmware in U38 does not require more than the 8 Kilobytes (64 Kilobits) provided by this static RAM. During bootup, it checks whether some location contains a valid magic value (like the 1234h at 40:72h for warm-booting PCs), and continues with the old configuraion, node address and key data if the magic value still exists. Otherwise, it will fall back to the default node address of 01234567, which can be changed using authsega.
raymv1987 wrote on 2025-01-03, 16:11:Something funny while experimenting. DDBD.exe does not appear to be Y2K-proof. When running it in a sandbox where the date is after 2000, it doesn't even try to load anything. Just cycles through and times out. None of the 0 values or anything. Post broadcast date file sets an end date to 1999.
Yeah, that's not surprising, as the end date for the transmission is specified with a 2-digit year. I assumed you already knew that, and that's why your system is set to 1997.
raymv1987 wrote on 2025-01-04, 02:46:Would the NVRAM likely have just been a temporary holder of information, or would it have held permanent data? I'm wondering about how likely it is given the ddbd.exe seems to fail at different intervals.
I don't expect the NVRAM (or anything related to the 80188) to be the cause for DDBD.EXE treating interrupts as spurious. The 80188 firmware contains code to complete reset the system, including erasing the RAM contents. The Tx data packet is supposed to look like "05 0d xx" or "85 0d 01 23 45 67 xx" (with xx being the checksum, which I am too lazy to calculate now), and I guess that packet can be sent using "factory setup".