https://github.com/HanJammer/avi2atari:
>no magic number, no header, no metadata - just rigidly
>no magic number, no header fields and no metadata
>no title, no author, no preview, not even whether
>no palette, no attribute coupling, no blending required
>no seeking, no resync marker and no tolerance
>No decoder, no scaling
>no layout decisions, no wasted space, full 160*192 quality

holy rule of three LLM batman!

>GTIA2RGB upgrade (I consider it more like an adapter than acceleator as it does nothing when it comes to processing power

full new graphic card with more powerful text mode than any VGA ever supported, 80x96 @ per char 12bit RGB 😮 nice hardware

Soo, the format is we are reading 8KB per frame at 50/60 frames per second and dumping that raw data stream on video hardware? and it works thanks to bruteforce speed of modern cartridges disk IO easily pushing that 500KB/s from a flash card 😳 500 Kilobytes = ~4 Megabits = standard bitrate of 720p@60 Twitch streams 😀 not so subtle hehe.

>all the processing lifting here is done by the 40+ years old hardware

I would argue all the processing is done by Python math libs with Atari relegated to the role of backplane providing direct connection between SIDE and GTIA2RGB 😜 cant argue with results tho 😀

>I'm working on the AVF player for DOS as well - it will run on something as slow as 286 12MHz (I already have the simple version complete). And it will leverage the stock hardware from the era - ie. ET4000AX.

8088 Domination on steroids?
Jonas Eschenburg is porting Command & Conquer to Atari ST (pretty insane) and wrote light video codec for it
https://medium.com/@jonas.eschenburg/stv-a-vi … st-6e46355c50e4 might be good inspiration.

rasz_pl wrote on 2026-08-29, 16:24:

full new graphic card with more powerful text mode than any VGA ever supported, 80x96 @ per char 12bit RGB 😮 nice hardware

Not exactly... it's not really like VBXE with frame buffer and so on, lovely hardware anyway. By "adapter, not accelerator" I only meant it takes zero work off the 6502. One correction: it's 80x24 character cells with two 12-bit colours each. The 160x96 comes from abusing the font RAM as a 2x4 subpixel mask per cell, so the character byte becomes the bitmap.

rasz_pl wrote on 2026-08-29, 16:24:

Soo, the format is we are reading 8KB per frame at 50/60 frames per second and dumping that raw data stream on video hardware? and it works thanks to bruteforce speed of modern cartridges disk IO easily pushing that 500KB/s from a flash card 😳 500 Kilobytes = ~4 Megabits = standard bitrate of 720p@60 Twitch streams 😀 not so subtle hehe.

"Brute force speed of modern cartridges" still pushed by the original bus though, and that's Avery Lee's original trick: ANTIC's DMA fetches the picture straight from the cart's data register, so the CPU never touches a video byte. At 1.79 MHz with a PWM audio sample due every scan line there are no cycles left to decode anything, so the format is whatever the hardware can display as-is. ~434 KB/s, about 3,5 Mbit. Bandwidth is cheap in 2026, 6502 cycles are not.

rasz_pl wrote on 2026-08-29, 16:24:

I would argue all the processing is done by Python math libs with Atari relegated to the role of backplane providing direct connection between SIDE and GTIA2RGB 😜 cant argue with results tho 😀

SUB Cart in this case. A backplane running a cycle-exact kernel, but fair: all the cleverness is in the encoder, same as 8088 Domination. In the APAC profile there's no FPGA at all though, just 1979 silicon.

rasz_pl wrote on 2026-08-29, 16:24:

8088 Domination on steroids?
Jonas Eschenburg is porting Command & Conquer to Atari ST (pretty insane) and wrote light video codec for it
https://medium.com/@jonas.eschenburg/stv-a-vi … st-6e46355c50e4 might be good inspiration.

Different goal on DOS: not delta-compiled code, but the very same .avf file playing on both machines. Right now it's working on MDA (text mode video) at around 5fps with PC Speaker or Covox sound.