During my journey to build the SmartDisk II, I made a ton of mistakes, and at the same time I learned so much, but sometimes it takes very long to sort things out. This is the story of the Bouncing Kamungas where I scratched my head.

The initial software version of the SmartDisk II was using the SPI DMA. SPI is a common hardware interface that enables to send at a given frequency a buffer of bytes. This last word is very important and you will understand why.

The beauty of the SPI DMA is that it is not blocking or consuming CPU resources everything is done in the back. On top of it you can configure the bytes buffer to be circular and to restart at the end forever, a bit like the floppy disk drive.

SmartDisk was loading image track to the SPI buffer, with a length and the SPI channel was sending bit by bit each byte of data with 4us interval. It was easy and working like a charm for a lot of Images including woz but not for the Bouncing Kamungas… And this image was not working for a good reason, and I was about to discover why.

I spent dozen of hours, to repeat every time the same debugging session with A.Eintstein quote in my mind: INSANITY is doing the same thing over and over again and expecting different results.

I have deeply analyzed the bit stream out of the SmartDisk prototype:

I have written python bitstream scripts to check everything again and again:

I have redecoded the woz file structure (again and again)

and the solution was just in front of me since the beginning with a wrong assumption, and yes I forgot to challenge with obvious !

DSK, PO, and NIB Images are block images that provide sector data without any tricks or copy protection, it is pretty much always the same approach, data is read from the image file and transform using the GCR 6-2 algorithm. Nothing fancy, just straight forward, SPI works fine but it is not the case for the WOZ files

Whereas WOZ Files aims to reflect exactly the bitstream of a track, and the length of a track is define in the image file with bit granularity. And of course, the length is not a multiple of 8, it can be anything, and a sector can be split between the end of the track buffer and the beginning of it.

Looking at the above screenshot, we discover that the bit count of track 0 is 50995, and 50995 is everything but not a multiple of 8. If you remember the SPI is able to send Bytes bit by bit. In this case it means that SPI will successfully send 6374 Bytes and the 3 remaining bits are pads with 0.

So it means that the you have 7 chances over 8 to get a corrupted sector, or a corrupted 6502 instruction. The assumption that the bitstream was a multiple of 8 was so obvious that is was wrong.

We all know the expression “Render therefore to Caesar the things which are Caesar’s; and to God the things that are God’s.”. I was so desperate, I asked for help and the best ones to give me a little help were the team of AppleSauce, In 2 minutes, Disk Blitz pointed out my mistake…

I had to change the approach, and to rethink completely the structure of the hardware and the firmware of the SmartDisk.

Using Timers, and bit banging the GPIOs Bouncing Kamungas were finally Bouncing for real !

Vincent