Hello! For the past few days, I have been testing the 8088 card in Commodore 610 extensively to find out why it doesn't work. I still don't know what is causing the problems, but I have much more wisdom now than w week ago :-) Perhaps you will be able to pick it from now and come up with some ideas. Here's what I found so far: * The power is not an issue. I swapped the power supply with the 720 and it didn't help. * The EPROMs are not an issue. I swapped all EPROMs with the 720 and it didn't help. * The 8088 processor itself works! I was able to write a simple program which filled the wole RAM with different values, and executed it on the 8088 side. The program ran successfully. * This means that 8088 has unrestricted access to RAM, which in my opinion means that the PLA chip is not an issue. All RAM cells were accessed by the 8088 and filled with correct values, and there were no DRAM refresh problems. The whole memory architecture seems to work properly with 8088. I started then to observe the MS-DOS boot process closely. Tim Paterson, the original creator of MS-DOS, was kind enough to help me understand what is going on during startup. From what I was able to observe, the problem lies in inter-processor communication between 6509 and 8088. Generally, as I observed, even a long 8088 program executes properly without IPC. But when the boot process starts using IPC, problems start soon. Usually the boot process either hangs after isuuing IPC function 18h (load disk configuration), or function 12h (output character to screen; the boot process uses it to clear the screen with $93 character). One time the loader hung midway writing the "INIT TABLE BAD" string, even though it is a very simple loop calling IPC function 12h (remember that I run the whole RAM fill program many times and it never hung, and yet such a simple loop hangs somewhere). Because 8088 programs without IPC work very well, and programs with IPC stop working sooner or later, I conclude that the IPC mechanism is somehow causing the problems. I also noticed that after resetting the machine, the byte in bank 1 at location $21 is reset to 0. Coincidentally, it is part of the INT 08h vector, and this very interrupt is responsible for handling IPC responses from the 6509. It happens every time when I run a 8088 program using IPC, but never when I run a program without IPC. Also, it never happens on the 720 - after reset, this vector is always itact. So I have two theories at this moment: 1. Something at some point is resetting the value at byte $21. Because this overwrites the INT 08h vector, the next time the 8088 does IPC, it is not able to continue because the interrupt vector points to garbage and the code never returns. This is a nice theory, but it doesn't explain why this particular byte is overwritten, by what, and why it happens randomly. 2. Some hardware control lines which are used during IPC are behaving flaky, and are randomly causing some part of the IPC procedure to fail or hang. This theory could explain the randomness of failures, but it does not give any hints on why this particular byte gets overwritten. It looks like I have gotten quite far with this analysis, but now I am stuck and I don't know where to look next. Perhaps I will wake up tomorrow with lots of new ideas, but for now I would like to ask you whether you have any hints or insights on why something like this happens? Definitely some hardware difference between 610 and 720 must be causing this. So, what are exactly the hardware differences between them? And does anyone have any clue why they have such efect? Regards, Michau. Message was sent through the cbm-hackers mailing listReceived on 2011-01-22 21:38:35
Archive generated by hypermail 2.2.0.