I think I sort of half figured it out, just the hardware part, not the
software part.
Here's what I have so far:
https://github.com/bkw777/NODE_DATAPAC#theory-of-operation
-----
I am still piecing this together. This is only my hazy guess at how it
works so far:
U1-U3 form a 0-1023 counter, setting local sram address bits I am
tentatively calling A0-A9. We'll call this the byte counter.
U6 sets local sram address bits I am tentatively calling A10-A17 from
the bus AD0-AD7, and latches that setting, ignoring the bus except when
triggered to get a new address.
BUS_A8, BUS_A9, Y0, and /A from the bus combine to produce two signals
which I am tentatively calling /BLOCK and /BYTE.
Each time /BYTE is pulsed:
* The byte counter is advanced by 1 (A0-A9 are changed to the new
address).
* All sram are disabled during the transition.
Each time /BLOCK is pulsed low and then back up, it does 2 things:
* U6 updates A10-A17 from bus AD0-AD7. 5 of those bits are used
directly as A10-A14 going to all SRAM chips, and 3 A15-A17 are used
indirectly to activate only 1 of the 8 chips. The end result is the
same as the same 8 address lines going to a single larger chip. The
rest of the time while /BLOCK is not low (or not transitioning from
low to high) the local address lines are held latched in the last
set state. They don't change with bus changes except when /BLOCK
pulses low.
* The byte counter is reset to 0.
So the device appears to operate in 1k blocks, where the host computer
gives 1 of 256 possible "block-start" addresses, then reads up to 1024
bytes, one at a time. Each time the host reads a byte, the counter
advances itself and the next read will get the next byte. So the host
does not set the address for each byte like with normal direct ram.
The device is actually acting a bit like a disk even though it has no
brains or firmware, in that the host sets a starting address and then
reads a stream of bytes.
I do not yet know how the host computer side of the process works.
-----
I also just finished making a tiny version that replaces the 8 chips
with a single 256k chip, and replaces everything with all SMT parts, and
the result is a little card that just sticks into the bus connector, and
lies flat against the back of the machine. All the parts are available
new from Mouser or DigiKey.
This also resolves the problem that the cable crimp-on plug does not fit
in a 200 without damaging the 200. The only connector that fits is a pcb
solder type that is annoying to try to graft onto a cable.
The small unit doesn't need any cable.
I got impatient and just started routing the pcb without really
planning, and so the layout and routing are kind of tortured. But it's
just the first version. But I did manage to get all traces routed
without enlarging the pcb. It might even work!
Now I have to figure out the software side.
--
bkw
On 8/20/23 18:02, [email protected] wrote:
Brian,
Awesome reverse engineering! Keep us posted on the progress. This is
interesting.
As far as the 74161 counters, the counters can be preloaded by taking the not
load pin (pin 9) low. In your schematic it is tied high so no parallel load
so it doesn't matter what they are. It would seem tidier to tie them to
something and in the early days of CMOS we were told that open inputs make them
vulnerable to ESD. I'd have to stare at it a bit longer to tell you what the
counters actually do. (Not totally sure if this extended staring will
happen,) 😊
Good luck.
Lloyd
-----Original Message-----
From: M100<[email protected]> On Behalf Of Brian K. White
Sent: Saturday, August 19, 2023 11:58 PM
To:[email protected]
Subject: [M100] NODE DATAPAC
Don't ask me why, but I think I've replicated the NODE DATAPAC in KiCAD.
https://github.com/bkw777/NODE_DATAPAC
https://raw.githubusercontent.com/bkw777/NODE_DATAPAC/db347506f5eeb9908348710727fa3f3b53bfd047/PCB/NODE_DATAPAC_128K_256K.svg
This is from beeping out the connections of one with a meter and shining a
bright light through the pcb to try to see under the chips. The schematic is
not verified, I haven't actually built one, and I didn't desolder anything to
uncover the the board to see all the traces, so it might not be complete.
I may actually build one just to verify if the schematic is really complete,
and also I'm dying to test my guess about just adding piggyback chips to go
from 128 to 256k without needing anything else, but I don't want to hack on the
original units except the unavoidable removing the old battery and cleaning up
the residue. No problem on a new replica board.
But can someone explain the theory of operation from the parts & connections? I can
see that AD5,6,7 are used to select one of the 8 chips, but I don't understand what A8,
A9, /A, & Y0 are actually doing with those counters, nor why they all have all
their data inputs NC and not even grounded.
Also what is the likely purpose of that user bodge diode on RAM_RST?
Only one unit has that, and they both work the same, outwardly. I assume it
will have something to do with some weird issue that only happens in some
particular situation like you have a printer connected and the computer turned
off or something like that.
If I make an alternate updated pcb with a removable battery connector or
non-recharging coin cell or something, should I add that?
--
bkw
