Brian, Do you know if it's possible to dump the original ROM using the programming adapter for the FlexROM 100?
Thanks! On Fri, Nov 17, 2023 at 07:14:24AM -0500, Brian K. White wrote: > 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 >
