Learning as you go
FAIL!
The board was a brave attempt, but I should have trusted my instincts which said 'This shouldn't work. There's strange voodoo
happening.' Here's the inspiration:
 | The
8K video RAM replacement chip is wired such that /OE and /CE are both
tied low. Aha, it's being controlled by CE2! Nope. That's tied high.
Here is the type of board that I was working from.
You see on the left how pins 28 & 26, 22 & 20 are tied?
Een over bekend printje voor het "hoge
geheugen met een 6264 in Den Haag en omstreken. Opmerkelijk dat het bij mij (H.v.d.H) en tientallen anderen werkte als de bekende speer.
Zie hieronder.
|
 |
 |
Dus toch H.v.d.H. groter klikken
|
Hmm. It works because the address lines from the video RAM to the VDC are
isolated from the rest of the system by some bus buffers. Unless the
video RAM is being accessed by the processor it remains 'firewalled',
with data presented to the bus constantly. This isn't a problem as the
VDC only reads. Reads from the CPU side are also OK as the firewall is
only opened as the CPU wants data on the bus. Accessing the video memory
on the Atom produces snow. This will be why, then! The data in the
memory location you're accessing is displayed by the VDC instead of the
data at the current scan position. I'm still not 100% sure how this all
works so I'll pore over the schematic with a nice cup of tea and a
sticky coconut macaroon later.
The upshot of this is that any memory expected to live on the CPU side of
the tracks cannot share address lines with the video RAM. You will not
be able to access the memory as the firewall is only opened for
addresses in the VDC range.
I'm strangely unperturbed by this
failure. I expect it's because I know that electrically everything
checks out. It's just the mechanical arrangement that's wrong.
Onward to plan 2! see here
Posted by Sir Morris
|