OK... somehow it's taken a year and a half to grab this stupid thing from its box in the back of my van, despite rummaging around it countless times, and realize that it needs to be *installed* in the van it's been riding in for a year and a half.

... two and two ...

..........

Now, that it's installed, I finally realize this is a great path for floppy-bird. (two and two x2). The stupid thing, as-is, with the old software seems to be refreshing at... dum dum dummm... 5Hz. Which, of course, is the rotational-speed of a floppy drive.

A few things... This guy, MarioThingMini, has an ATtiny84 driving the Sony ACX705AKM-7 display... As I recall, it actually updates fast enough to draw each of the 240x160 pixels differently, but even a single image-frame would max-out the onboard Flash, nevermind only having 512B RAM which is only enough for two lines of the 160. Nowhere near enough for a frame-buffer.

Floppy-bird, ideally, should store an entire 240x160 image frame on *each* of the 160 tracks on a floppy disk. So, using 16x16 sprites and a 16x16 viewing-window, as in MarioThing, would be a bit of a ridiculous use.

OTOH, the present scenario, with Floppy-bird, being as it is, that much storage-capacity may be a bit much to expect... At least until i have the time/money to do those characterization experiments mentioned in past logs... And what could I do with, say, 1/4th or 1/16th the ideal capacity? Low-Res... Duh. Maybe even as low as 16x16. Works in MarioThing!

.

Of course, part of the 'fun' of floppy-bird is the huge quantity of still-frames, and the weird visual-effects likely while switching between them (stepping between tracks). Not sure how that could fit with MarioThing which has realtime moving sprites and a moving camera window. Pre-rendered frames for every action? Seems a bit ridiculous, but who knows... Not like 'ridiculous' isn't this project's middle name.

Might be a path to ponder, anyhow.

......

Ooooh, it's slowly coming back to me...

As I recall, I fiddled quite a bit with the driving of this display. I think I wound-up refreshing twice for each image-change, then *not* refreshing at all until the next change (about 1/5th of a second later). This is a "display parallel interface" (DPI) raster-drawn display... It doesn't have a graphics controller, scaling circuitry, or any onboard memory. Every pixel must be drawn in realtime, in sequence (a refresh), and often enough to retain the image. Here's where I misuse TFT's inherent "memory" at every pixel. The image fades after about one second, so as long as you refresh at least that often, the image remains. So... There's no need to have a constant refresh-rate.

 (Well, they say it's bad for the liquid-crystals. I can't vouch for that. I had another display running like this 24/7 for a year without trouble. its CCFL probably shouldn't've lasted that long!)

But... why was this relevant here...?

Oh yeah. For this display, anyhow (maybe many/most DPI raster-interfaced TFTs?), I think it boiled down to that there needn't even be a steady/constant pixel-clock frequency. I think I just stopped the pixel-clock after each refresh. And I might've even loaded a new color at the beginning of each of the 16x16 sprite-pixels, then strobed the pixel-clock as fast as I could [240/16] times before repeating the process. (it's been *years*).

That could probably be done with a simple arduino sketch.

(This might work with most DPI displays, but almost certainly not work with e.g. LVDS-displays nor probably DVI/HDMI. For LVDS, the pixel-clock drives a PLL, which requires a steady clock-frequency. Though, as I recall, I found tricks like these for those as well... imagine seconds-long 'porches'. E.G. Tens of thousands of "pixels" after the last drawn-pixel on one line before the hsync indicating the first pixel on the next.)

OY... what did this have to do with floppy-bird?!

...

Maybe it was just confirmation that the somewhat random data that'll come during a track-step should result in some interesting visuals, which I've been looking forward to. (rather than, say, the display's 'freezing' while awaiting resynchronization). And that, say, if the screen was only half-redrawn before a step interrupts, and, say it steps in slightly after the beginning of the next track's image, we'll probably get one image frame consisting of the top half of the last image, below that some random 'garbage' while the head moves from one track to the next, below that would be the *top* of the next image... Then, when the next track finally comes 'round to the vsync, it should resync, showing the next image properly on the next refresh. (as opposed, say, to it's 'scrolling' vertically, due to the excessively long frame-data received).

.

OH SH**

Previous comments about "most" displays probably need to be rescinded! I completely forgot about DE-Only displays, which pay no attention to Hsync and Vsync, and base all their timings on the dead-time between 'active' pixels (indicated by Data-Enable, aka DE).

And some non-DE-only displays do have similar effects with excessively long porches. Sh**. I vaguely recall *this* display having some oddities like that.

That shouldn't be a huge problem for this project, since odd-visuals are part of the appeal... But... It probably means I should just delete the majority of this post. Wee!