Prototyped Bubble Memory

[NeXT]

I made a reckless offer on an Intel BPK-72/IMB-72C bubble memory prototyping board attached to a mess of wire wrap and another prototyping board and I ended up winning it.
Now that I have it on my bench it appears someone (they are using an invitation to a Christmas party in Berkeley) had actually built an adapter board to use bubble memory on an S-100 bus!

- A0-A7 are used
- D0-D15 are used (16-bit data bus?)
- pWR
- pDBIN
- sOUT
- sINP

The absolute minimum needed to make it appear on the bus and be readable and writable. It would be nice if it also had included PWRFAIL but the manual for the BPK-72 kit has apparently never been scanned so I don't know if that pin exists on the prototype board.
All the glue logic, the regulators, a dip switch bank and an 8mhz crystal are living on the backside of the board and while I thought this was a mess of wrap and broken wires it does in fact all seem to be intact. In theory if I drop it into a system it should just work but I don't know where it should be sitting in memory, assuming it's doing something like appearing to the computer as a chunk of nonvolatile ram.
What is also bothering me is that I feel like I've seen this board before somewhere. A photo online using the same board adapting to S-100 but I can't find the photo anymore. Is this ringing a bell to someone? Was it a how-to from a magazine?

 

[daver2]

I am sure I have seen the manual online somewhere. I have a BPK-72 (and the manual) somewhere.

Yep, here: https://www.wolfgangrobel.de/museum/files_bubble5/intel BPK72 Prototype kit users manual.pdf.

Only 8 data lines are used. No power fail signal that I can see.

Dave

 

[NeXT]

Oop, found it. The other board I was remembering was form a hackaday article back in 2023.

| Details | Hackaday.io

<p>A few months ago I decided to see if my first computer still worked. It's been languishing in various boxes and closets for nearly forty years now. This is what the computer, an Explorer 85 from Netronics Research, looks like:</p> <figure><img...

hackaday.io

Similar orientation, same Intel board but a different chip count and mine uses an 8mhz crystal for clock generation whereas this one uses a 4mhz crystal.

 

[daver2]

I would have thought it more logical to appear as a few I/O ports to be honest.

That is how I built mine. It then just looks like a disk controller device.

There only seems to be sufficient 'glue logic' onboard to perform an interface, rather than emulating a block of RAM.

Dave

 

[daver2]

Ah, the data bus is D0 through D8 (not D7). D8 is used for ODD parity transfers across the bus.

I suspect the use of D8 is optional if you decide not to use it. The status register may tell you there is a parity error - but you just ignore it. You can also disable the parity error interrupt.

There is a /PWR.FAIL signal on figure 2-2; but it looks internal to the module - so (I suspect) it is dependent upon the characteristics of the +12V and +5V power supply fed to it.

Dave

 

[Eudimorphodon]

- D0-D15 are used (16-bit data bus?)

One must always remember that S-100 is weird and archaic and horrible when tracing connections on it.

The original Altair flavor of S-100 had two unidirectional data busses, DOx and DIx. The "DI"'s were recycled into bits 8-15 with IEEE-696. I would guess that this card is just tying the single bidirectional 8 bits of the module to both sets of lines (through those '244 buffers?) to be compatible with the Altair flavor. (Some 8-bit S-100 machines, like the Sol-20, were pretty early on effectively just tying the two unidirectional busses together... compatibility is a whole ugly can of worms here.)

In theory if I drop it into a system it should just work but I don't know where it should be sitting in memory, assuming it's doing something like appearing to the computer as a chunk of nonvolatile ram.

It only has A0-A7 and the I/O signals (sIN/sOUT), no sMEMR, so this thing is almost certainly just decoded to an I/O range. I can't quite read the label on the chip next to the '244s on the back but it *looks* like it might be a AM25LS2521, if that's what it is then that's almost certainly your address decoder. You should be able to figure out the port by looking at what the pins are tied to. (Which I think is that DIP switch.)

Remember when sussing this out that "Bubble Memory" is kind of misleading to modern ears. That makes it sound like "flash", IE, random access nonvolitile memory, but architecturally it acts essentially like a bulk shift register (IE, serial access to storage "loops") and was generally abstracted to act like a disk device. If you tried to make bubble memory "look like" novolitile RAM you'd either need some creative caching algorithm or it'd be slow as h**l. (Like, disk drive slow, or worse.)

 

[NeXT]

Sorry, I'm used to the nature of the ISA bus.

 

[hmb]

I would guess that this card is just tying the single bidirectional 8 bits of the module to both sets of lines (through those '244 buffers?) to be compatible with the Altair flavor.

That is exactly what this board is doing. It is very common practice for S100 boards to have a bidirectional data bus internally, which is then steered to the S100 DI and DO data lines based on whether a read or write bus cycle is taking place.

As you pointed out this is a very simple interface with a couple of 8-bit buffers, an 8-bit address decoder, and a few glue chips. It is similar to what is needed to interface a CF/IDE card to the S100 bus.

 

[Eudimorphodon]

The manual for the bubble memory module is interesting reading. A few random takeaways:

• The module has a single address line designated A0; therefore it's likely that only 7 bits of the address decoder are used.
• Internally the controller actually has 9 registers along with a data buffer FIFO. The second port (A0 = 1) is always the status register when read, writes to it either select which "hidden" register the next data transaction on A0=0 goes to, or which 4 bit command is executed. This is vaguely reminiscent to how the registers on a 6845 CRTC chip are addressed.
• Basically to read or write to this thing you write to the "register address counter" a 4 bit starting address for loading the six registers that define the parameters for a transfer (it's not entirely obvious why it uses four bits when there's actually only 7 choices for how the "data" port multiplexes, but whatever), you send the read/write/whatever command, and then start pounding data in or out of the FIFO.
• The parameters basically map like what you'd set for a raw disk transfer, so translating code intended for a floppy controller should be reasonably straightforward. The register layout is a little weird, but it looks like in practice it maps especially closely to how you'd drive an Intel 8272A floppy controller. )

Reading the account in that Hackaday article it looks like people trivially hacked floppy-oriented OSes to work with this by just mapping "pages" (bubble memory equivalent to sectors) to a fake floppy geometry. The hackaday example shows a bubble memory unit that has effectively has 64 byte pages, so their OS combines pairs of them into CP/M-equivalent 128 byte sectors.

 

[ClassicHasClass]

Which, by the way, was actually a new thing in the Intel 7110. Earlier bubble memory chips like TI's had bizarre page sizes; it was a then-novel feature of the 7110 that it had more typical powers-of-two quantities.