8088 and 610 saga continues...

From: Michał Pleban <lists_at_michau.name>
Date: Sat, 22 Jan 2011 22:38:35 +0100
Message-ID: <4D3B4E5B.2060200@michau.name>

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

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

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?


       Message was sent through the cbm-hackers mailing list
Received on 2011-01-22 21:38:35

Archive generated by hypermail 2.2.0.