I am wondering, out loud, where to go next with the bubble board software for the SBC-85 1MBit bubble board. As it currently stands, I have subroutines that are called to initialize the board (called once upon power-up), write any number of bytes to the bubble, and read any number of bytes from the bubble.
The bubble device has 272 race tracks in each of two banks, and these are written-to and read-from essentially in parallel so a data 'page' has 68 bytes of information. This can be configured as 64 bytes with ECC or use the full 68 bytes raw (which is how I plan on using it). From a generic standpoint, accessing the bubble is done by specifying which page is desired (i.e., which of the 4K bubble locations on the race track the user wants), then the bubble controller simultaneously brings that particular bubble location on all 272 tracks to the read or write station, and then does a parallel read or write of all 68 bytes. Once the starting location is in place, the user can then sequentially read or write the specified number pages.
To use my write routine, the user first loads into memory buffers (1) the starting bubble page number, (2) the starting address of the source data, and (3) the number of bytes to be written. The routine is called which returns the bubble status byte when the operation is completed or times out. Since the bubble controller thinks in pages and not bytes, the number of bytes is divided by 68 to get the number of pages which is passed to the 7220. Also, since the 7220 controller will throw an error if a partial page is accessed, the routine fills out the rest of the page with filler during the transfer to the FIFO.
To use the read routine, the same parameters are passed, i.e., the starting bubble page, the destination memory address for the data, and the number of bytes to transfer. In this case the left over incoming bytes in the page are just sent to the bit bucket.
So obviously we can think of the bubble just like we would a disk with 68 byte sectors. When I started this board, my interest did not particularly lie in the software beyond the low level routines. However, to make the board usable, some sort of DOS will be required which is where I am now.
Right now I am leaning towards a 70's style chain topology which I have always favored for simple systems. I just have a table that includes a reference to the first page of a file, and then at the end of each of those pages there is a pointer to the next page. Reading was as simple as starting at the first page and then following the breadcrumbs from page to page. Overall memory formatting was accomplished with a "page utilization table" (PUT) that just had a bit set for each page used and reset for each free page. When writing to the memory, the first free page in the PUT was claimed as the starting page of the chain, and the file written one page at a time with the last two bytes pointing to the next free page subsequently claimed in the PUT. Hard to beat in terms of simplicity, easy to implement, easy to maintain, and no more subject to fragmentation than any other DOS.
So unless someone steps forward that is really into disk operating systems and wants to create something more exotic, this is going to be my path forward. But if anyone has any suggestions I am still in the pre-project thinking stage and willing to include any good idea.