On 11/16/23 01:15, Brian K. White wrote:
Basically A0-A7 and D0-D7 both use the same 8 physical pins, at
different times. When ALE is high, those pins are address, when ALE is
low, those pins are data.
Basically the low 8 bits of the bus to be used for both address and
data at different times. When ALE is high, AD0-AD7 are A0-A7. When ALE
is low, AD0-AD7 are D0-D7.
guess I was too tired while writing.
I was up all night playing with a whopping 32 channel logic analyzer
trying to reverse engineer how a 512k RAMPAC is supposed to work and
it's right at my limits of ability to figure stuff out.
-- wall of text warning --
I don't have and have never seen a 512k RAMPAC, I just know they
existed, and we have the RAM100/RAM200 software that supports it.
A few months ago I got a 128k/256k Node DATAPAC and reverse engineered
the hardware and produced a modern version of it the MiniNDP 256, and
that works with RAM100.CO and RAM200.CO.
The way the hardware works is among other things, it uses 2 address bits
A8 and A9 on the bus to select between two functions: set a block
number, or read or write a byte of data.
A8 is high for both of those, so you can consider the 3 pins (A), /YO,
and A8 to together be the selector for the device as a whole. all 3 of
those need to be in the right states or the device is not selected and
none of the other pins matters at all.
That just leaves A9 which selects whether you are doing a BLOCK op or a
BYTE op.
A BLOCK op latches in an 8-bit block number from AD0-AD7 and resets the
byte counter to 0, so that the next BYTE op gets byte 0 of the
just-selected block.
A BYTE op reads or writes a byte of data from/to AD0-AD7 and then
increments then byte counter by 1.
There are 10 bits in the byte counter so the interface to the device
allows for a maximum of 256 possible block numbers to choose from, and
you can read or write up to 1024 bytes in a block before the byte
counter rolls over and you'll just get byte 0 again.
The way BUS_A8 and BUS_A9 are read are they are fed into a 3:8 decoder
that translates 3 input bits into one of 8 possible single output pins.
There are 3 bits of input but only 2 are used, bit 2 is simply grounded,
and the only output pins that are used are bits 1 and 3. Output bit 1
(which you get when the input was just A8 high) means to do a BLOCK op.
Output bit 3 (which you get when the input was A8 and A9 high) , means
do a BYTE op.
So far, this all only allows for 256k. There are no other bits like, you
can't just add a 9th bit to the block number or an 11th bit to the byte
counter etc. (well you could do that last but the original software
would not know how to use it).
So the hardware interface is fully used up by 256k.
Yet there were later versions of the device that had 384k and 512k. I've
never seen one but they are in magazine ads, and the software has a
"Bank" button which does nothing on my 256k units.
So the 512k units somehow implemented a 2nd 256k bank, but otherwise
worked the same as a 256k unit.
I don't have a 512k RAMPAC to examine, but I do have software that
supports it, and I have this superdeduper 32 channel logic analyzer, so
I thought it would be fun to hook that up and just see what happens when
I hit the bank button in the software. I also found this neat little pi
gpio 1-to-2 adapter that makes a perfect neat little tap for the 102 bus
connector to make the hookup pretty neat.
https://www.amazon.com/dp/B07MCW4KCM/
You just plug the long pins into the T102 with the other pins pointing
up and the female connector pointing straight out just like the 102's
connector is, plug the external device onto that just the same as
plugging directly into the 102, and connect all the logic analyzer wires
to the pins pointing up. The logic analyzer wires already end in female
sockets.
https://photos.app.goo.gl/F6GdTjUG5gu4vkqf7
https://photos.app.goo.gl/VzwWCf8wB3aBhYJBA
Looking at the schematic
https://raw.githubusercontent.com/bkw777/NODE_DATAPAC/main/PCB/out/MiniNDP_256.svg
There is an unused address input bit on U4 (top-left), so it seems
natural that the bank function might somehow be based on adding A10 to
the 3rd input of that chip, and then one of the other output pins
becomes a BANK signal.
So I hooked everything up, captured a short session where all I did was
turn the machine on, run RAM100.CO, press the Bank button once, exit
RAM100.CO, turn the machine off.
I had the logic analyzer external trigger connected to the bus CLK pin.
Searched the capture for any instances where A8 is high, (A) is high,
/YO is low, and the rest don't care (so any/all access that the device
would respond to, and all other traffic ignored), and looked to see what
was the state of A10 during all of those, and sure enough A10 was low in
all cases except one.
That one time A10 was high, A9 was low, so it was essentially a /BLOCK,
but with A10 high at the time.
So it looks like the way the 512k devices worked was, when you do a
/BLOCK, if A10 is low it means use bank0, if A10 is high, use bank1.
If you never press the Bank button, A10 is always low during any access.
I found an earlier version of RAM100.CO that does not have any Bank
button, and A10 is always low.
So a new device with the added bank of 256k doesn't break old software
that doesn't know about it, and new software doesn't break on old
hardware that doesn't have it.
Now how to do the hardware for that?
Back to the schematic, the byte counter is 10 bits, but there are 12
bits of counter available. the last 2 bits of the 3rd 4-bit counter are
not used (U3 center-right), and 2 corresponding output bits also unused.
Here is my wild guess:
https://raw.githubusercontent.com/bkw777/NODE_DATAPAC/main/PCB/out/MiniNDP_512.svg
The differences are just:
* Add BUS_A10 to U4 A2
* U4 output O5 is /BANK, and connects to U3 input D3 (highest counter
input bit).
* The /BLOCK reset signal for U3 moved from the /MR pin to the /PE pin.
Instead of blasting all to 0's, now sets Q0-Q3 from D0-D3. D0-D2 are
grounded, so they always get 0's same as before, but D3 now reflects the
state of /BANK.
* U3 Q3 output bit connected to sram A18. So /A18 reflects /BANK, and is
essentially latched, so while /BANK is only set during the /BLOCK op,
the counter bit stays set until reset by another /BLOCK op. It's not
really latched, it's just that the counter never counts high enough to
flip it.
* AND gate combining /BANK and /BLOCK: Whenever there is a "/BLOCK with
A10" access, the /BLOCK pin will not go low, ONLY the /BANK pin will.
But whenever there is a /BANK access, we want to do a /BLOCK too. So the
AND gate acts as a negative logic OR gate. If either /BLOCK or /BANK go
low, then set the /BLOCK net low.
No other changes!
It's even still downwards compatible with a 256k chip! (I think)
Because of the way the 3:8 decoder outputs active-low, all the output
bits are high by default and only the single active bit is low at any
given time.
So, /BANK is high by default, and so A18 is actually high by default,
for "bank0". A18 actually goes to the physical pin for A17 on the chip,
and A17 (the highest bit on the block number latch U5) goes to the A18 pin.
The A17 pin (pin 6) is an active-high CE2 on the 256k chip. So, if you
install a 256k chip, the bank signal just goes to a CE2 pin, and since
it's high by default, and CE2 is active high, the chip just works like
normal unless the software tries to select bank1. If it does, it just
disables the sram and the software will read all 0's on all subsequent
/BYTE attempts, and presumably the software just recognizes that and
does another /BLOCK to reset.
At least, this is my best guess about it all so far.
Mostly this is an excuse to play with the logic analyzer. :)
If anyone wants to try to look at the data, I have a sample capture here,
https://drive.google.com/drive/folders/1mglvMPCFzt1PJEdszj_NHo4AtC-TVYK7?usp=sharing
which you can load into the DSView software. You don't need the hardware.
https://www.dreamsourcelab.com/download/
When you first load the file, look in the top-right corner under
Decoders, and change BLOCK to dec and DATA to ascii
Those are two decoders configured to sample AD0-AD7 during /BLOCK access
and during /BYTE access.
dec and ascii means to display the data as decimal or ascii.
The decoded data appears at the top of the display but doesn't start
until about half way through the session.
To find the one A10 access, use the search on the bottom. Leave all
channels as X and just set these four: A8:1 A10:1 (A):1 /YO:0
then OK then hit the > to the right. It should jump to 526ms
How the data was generated:
The physical hookup is as the channel labels show, IE channel labelled
/YO is on the /YO pin on the bus, etc.
One bus pin is not shown which is CLK, because that pin was connected to
the external trigger input instead of a normal channel input.
So the samples are actually only happening on the CLK pulses not by any
arbitrary mhz timing. This makes a cleaner looking capture with a lot
less data yet still accurate, otherwise it would have to be a 5 or 10mhz
capture to get a still wobbly capture of the 2mhz bus. I can sample at
up to 50 mhz while using all 32 channels but even 5 or 10 mhz generates
a lot of data and it balloons to 10g when exported to csv if you wanted
to try to process it outside of the DSView software.
The usual response to that problem is apparently setting up advanced
triggers so that you only capture the tiny subset of all traffic but I
haven't figured out how to do that yet.
The /BLOCK channel is connected to pin 14 of the 74HC138.
The /BYTE channel is connected to pin 12 of the same chip.
Those could theoretically be generated virtually by just matching the
right states of A8, A9, (A), and /YO, but might as well read the actual
hardware as long it's so easy with these big-ol'-dip-chips to clip on to.
The actions taken during the capture:
Start with the machine off.
Start the capture.
Since the external clock is on the bus CLK pin, the capture produces no
data at all until I turn the machine on.
Turn the machine on.
Run RAM100.CO
RAM100.CO does whatever it does to explore the device and display the
directory.
(I have files named BKW77.BA, ABCDEF.DO, GHIJKL.DO, and RAM100.CO stored
on the device)
That is the first burst of /block/byte traffic
I press the Bank button once.
that is the 2nd burst of block/byte traffic, although from the looks of
it, it's really just an attempt to switch to bank1 and then a repeat of
the original directory listing.
Press F8 back to the main menu.
Turn the machine off.
Stop the capture.
I'm a little confused about the timestamp values. I'm pretty sure I saw
in other captures using internal clock and reading CLK as a normal
channel, that it said CLK was running at a slightly wobbly 2.04mhz. but
the timing values shown here say everything is running crazy faster like
the (A) or ALE are pulsing at 6.25mhz?
Yeah the timestamps are pure fiction. The timestamp says that single A10
access happens at 526ms. That happened at about something more like 10
whole seconds in reality.
It's just so cool seeing all the signals just laid right out like that.
I love playing with this thing.
--
bkw
