Hello, > 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). Did you have some more information about the IPC functions? I've look at the MSDOS.PRG and find some routines for reading sectors from disk and so on. At this time a found a mysteric: The MSDOS.PRG is to short (directory shows 2817 bytes including two bytes for the starting address). There is program code after the last (23) bytes in the last sector of the disk. Did you have complete disassembled the code? > 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. That's a good result! Great work. > 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. Okay, have a unterstand it, that this byte (10021h) is cleared after an ipc call from 8088 to 6509? At a look at the rom listing CBM-II there are some different causes for the ipc server at the 6509. Only if the highest bit at the ipc command is set to one the dram bus is arbitrated, the function called and after them released. When an ipc call without this bit is called, the 6509 can't access the dram at bank 1 and can't owerwrite the address 10021h. Is this the only address that was changed? Can you test it? > 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. And the other question is, why don't overwrite the 720 this byte? > 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. I don't think this is a solution. It works on the 720 and all thes hardware control lines are on the coprocessor board. > Definitely some hardware difference between 610 and 720 must be > causing this. But where are they? I've look at the schematics and can't found anything. The difference are: * Pin PC7 (Pin# 32) is at the low profile connected to ground, at the high profile over a resistor to VCC. * The low profile has an additional video output circuit for the composite video output. Greetings Martin Message was sent through the cbm-hackers mailing listReceived on 2011-01-23 16:00:10
Archive generated by hypermail 2.2.0.