just an idea... 

a brief intro to the problem: one of the dilemmas of trying to load an image onto each track is that the entire track/image would have to be written in one fell-swoop, in realtime. This because it'd be darn-near impossible to expect the read and write heads to be aligned so perfectly as to be able to manipulate individual bits on the disk...

This, I presume, is a huge factor in why disks are written in sectors. 512 bytes of consecutive data, prepended by a header that gives info about that sector, and that header prepended with numerous repeating bytes which indicate the beginning of a sector, allowing the controller to resync its clock with this new and likely misaligned stream of data. (Misaligned with respect to the previous sector, as each is typically written in different rotational-cycles).

Writing the whole image-frame in one fell-swoop would be challenging... The uC itself probably isn't fast enough to render in realtime, so I was planning to send images from a host computer... but the math wound up requiring a serial connection at 1Mbps. That should be doable. The problem is that that data stream can't be interrupted, e.g. if the host computer decides to task-switch to handle a mouse movement.

I'm sure it's doable, a receive-buffer would help, xon/xoff, a faster baud rate, 'renice' at a high priority, a custom downloader program, a few other things.

But, not ideal... Also because it means the only images that could be stored would have to be pre-rendered... and, again, loaded from a computer.

So, it occurs to me... Why not write the floppy in chunks... yahknow, like... sectors! Duh.

----

Here's the thing, I know all about sectors... I was trying to avoid them, for the sake of a simple demo... The uC would've basically been doing nothing more than could've been handled with a few TTL parts, in translating the stream of PWM data coming from the Floppy drive into the parallel data-bits required to drive the display-timing and draw the image. I like that idea.

... So, I've been avoiding sectors. But, the fact is, I *will* be using a uC in this project... at least for writing the images to disk, And then, for readback, because the hardware would already be set up. Also, the solution to the other day's 'duh moment' would be a bit more difficult to do with TTL.

------

But, tonight occurred to me that a stripped-down sort of 'sector' could be quite easy to implement. What if *every* line was a 'sector'... my display is 160 lines tall. So, after each Hsync, maybe the uC just writes a bunch of Hsyncs repeating. When read-back, the first latches the uC's Hsync output signal and indicates to the uC to resync the PWM-data, etc. Then the beginning of the next line of data will overwrite some of those repeating Hsyncs with a short header just long enough to assure the PWM-data is being read correctly, then the uC will switch Hsync off when appropriate, beginning the next line.

This'd be easier than regular sectors for a ton of reasons, one of which is that there's 16 possible PWM-data values in each PWM-nibble, but only 9 or 10 are allocated (8 colors, hsync, maybe vsync). Thus, the beginning of the next line/sector-data could be prepended with an 'hsync-off' nibble. Easy-peasy.

This is all further aided by the fact that the 'sectors' will always be read-back sequentially and in realtime. Older computers, of the era when floppies were invented, just couldn't handle that much processing... floppy controllers were even dumber. They couldn't process two sectors back-to-back (thus interleaving). Further still, there was no hard requirement that sectors would always be a certain lenght! So, sector-headers had to contain enough information to be located at-random. Here there's no need for all that. These 'line secctors' are all sequential and all the same length. A line-data-header, here, could probably be no more than 4 PWM-nibbles, just enough to resync the PWM-data 'clock', and maybe contain the hsync-off value.

So... the hsync pulses may vary slightly in duration, but that shouldn't matter to the LCD... And as far as a TTL-implementation, I think it'd only add a latch and a 'match' (what're those called, 4-bit comparator?). *maybe* an 8-bit counter and comparator and some glue... ok, getting uglier.

But, the resyncing bit,.. from the 'duh moment'... (that would also be necessary/reused here)... that's still an unknown in the TTL-implementation realm. Counters, comparators, latches. Maybe not so bad, but on the same scale as the entire rest of the circuit :/

.....

Anyways, a side-benefit, of course, is that now the AVR could actually use the floppy as a frame-buffer for images of its own rendering... which opens up a lot of doors. Maybe a Mandelbrot set, maybe a zoom... 160 frames, yo!

...

But... Also feature-creep... TTL-translation was kinda exciting, 'duh moment' might've ruined that :/