60 fps video using SIDE 2

[phaeron]

For the "stupid Atari tricks" section: by abusing IR mode 2 addressing, I figured out a way to get ANTIC to DMA playfield data straight out of an IDE interface of a SIDE 2 cartridge. This allows reading off the CompactFlash cartridge at 360KB/sec instead of 86KB/sec and in this way I was able to boost the frame rate of my old video player all the way to 60 fps, while still playing 15KHz audio:

 

http://www.youtube.com/watch?v=LkiRCp-Y92U

 

Kind of useless other than for novelty purposes, but I was surprised that the hack worked.

[+wood_jl]

HOLY MOLY!

 

 

it's been a little while since the A8 made my jaw drop, but this is one of those moments. It's amazing that in 2013, people are still making the ol' machine do that. THANKS SO MUCH FOR SHARING!!!!! Love it!!!

[Rybags]

Cool stuff. For removable fast media it is useful, always good for a demo for shows etc.

[Xuel]

As a lover an fellow perpetrator of stupid Atari tricks, this is absolutely brilliant! It appears this works on a stock Atari, no? What graphics mode did you use? Do you issue new sector fetches during vertical blank?

Edited April 27, 2013 by Xuel

[phaeron]

Yes, it's stock 64K 800XL hardware... well, except for the cartridge with the IDE interface in it that provides the register that magically feeds 30MB of data. No PBI devices attached, though.

 

The screen is IR mode 2 (40 column hires) toggled between modes 9 and 11 via PRIOR on each scanline. The trick is to position the character set over the IDE registers and use the right character to select the correct 8-byte window. From there, the trick is to get ANTIC to use the right row so it only reads a single address over and over. Well, the IDE data register is at offset 0. By using vertical scrolling we can shorten all the mode lines to a single scanline, alternating between rows 0 and 7, and using the vertical reflect bit the row 7 accesses can be redirected to row 0. The register flips and the audio are all driven by a full-screen kernel, which issues a 12 byte sector read to the IDE device per frame. ANTIC DMAs in 5824 bytes of video over 182 narrow width scanlines, and then the CPU reads in another 320 bytes containing 262 bytes of sound data over 32 more scanlines. The IDE device has the remaining 3ms to prepare for the next read command. Source is attached.

 

I was originally using normal width scanlines and had the CPU reading interleaved audio in horizontal blank, but ran into a problem on the real hardware that didn't manifest in the emulator that I thought was related to a delay on the device between sectors. As such, I had to go to narrow width to give the IDE device ~30 cycles between each sector. I later found the actual problems that were causing the corrupted reads, so I might be able to go back to that setup. In theory that would boost the read rate from 360KB/sec to almost 500KB/sec.

 

Here's a video with a bit more color:

http://youtu.be/wYL_dzfp8G0

movplay60.zip

[Xuel]

Awesome work! It's great that SIDE2 is fast enough to fill its buffer during vblank. Genius using Char mode, VSCROL, and CHACTL to get ANTIC to hammer the read register for bitmap data. How lucky that $47 and $c0 are the perfect values to twiddle between for three different hardware registers for each pair of lines. Absolutely love it.

[DamageX]

now that is one seriously awesome hack.

[drac030]

Very nice.

[flashjazzcat]

Absolutely fantastic stuff.

[TheNameOfTheGame]

Wow you made me go into shock!! Amazing technique you developed...good job man, that really blows my mind! Edited April 27, 2013 by TheNameOfTheGame

[+Larry]

WOW! The neat things you clever programmers can get 1970's technology to do. Absolutely amazing!!!

 

-Larry

[Markdvdman]

Absolutely sensational! We must have thought the 8bit has been stretched to the limit! Not so - fair play - wonderful!

[+JAC!]

The screen is IR mode 2 (40 column hires) toggled between modes 9 and 11 via PRIOR on each scanline. The trick is to position the character set over the IDE registers and use the right character to select the correct 8-byte window. From there, the trick is to get ANTIC to use the right row so it only reads a single address over and over. Well, the IDE data register is at offset 0. By using vertical scrolling we can shorten all the mode lines to a single scanline, alternating between rows 0 and 7, and using the vertical reflect bit the row 7 accesses can be redirected to row 0. The register flips and the audio are all driven by a full-screen kernel, which issues a 12 byte sector read to the IDE device per frame. ANTIC DMAs in 5824 bytes of video over 182 narrow width scanlines, and then the CPU reads in another 320 bytes containing 262 bytes of sound data over 32 more scanlines. The IDE device has the remaining 3ms to prepare for the next read command. Source is attached.

That's what I call a great hack, the basic idea is not new (see also http://atariage.com/...it-atari-great/ and DPC+) but the execution taking all known ANTIC quirks together is simply brilliant. :thumbsup:

 

 

EDIT:

Just had a look at the source and found why my attempts to create something similar (different storage though) looked horrible.

I miss about 10 years of writing, well, VirtualDub :-)

 

float sat0 = red0*red0 + grn0*grn0 + blu0*blu0;
float sat1 = red1*red1 + grn1*grn1 + blu1*blu1;

float fi0 = 0.595f*red0 - 0.274f*grn0 - 0.321f*blu0;
float fq0 = 0.211f*red0 - 0.522f*grn0 + 0.311f*blu0;
float fi1 = 0.595f*red1 - 0.274f*grn1 - 0.321f*blu1;
float fq1 = 0.211f*red1 - 0.522f*grn1 + 0.311f*blu1;

int c1 = (((int)floorf(atan2f(fq0, fi0) * 7.5f / 3.1415926535f + 1.0f + da1) + 15*1000) % 15) + 1;
int c2 = (((int)floorf(atan2f(fq1, fi1) * 7.5f / 3.1415926535f + 1.0f + da2) + 15*1000) % 15) + 1;

Edited April 27, 2013 by JAC!

[roland p]

Cool! How many colors are we looking at?

[candle]

my head almost fell off because i laughted so hard

nice work Avery

any chance to have this over fat32? with some assumptions (ie frame always aligned to cluster, clusters big enough to fit it)

[phaeron]

I forgot the multiplexer tool to merge the streams -- now included.

 

Someone asked for how to get this running locally. Well, it's a bit involved, and unfortunately the movie files are waaay too big to attach here. Here's the steps:

• Resample video to 128x182 at 59.9227 fps, in 4:2:0 progressive YCbCr (YV12) and convert audio to 15.7KHz, unsigned 8-bit mono.
  
• Use the encvideo60 tool to convert the video to a raw 64x182 video stream with interleaved Gr.9/11 mode lines. The tool takes the video in on stdin, because it's meant to be used with VirtualDub's external encoder feature, but it should be easy to rig up against another tool like ffmpeg or just with a file as source.
  
• Use encaudio60 to convert the audio to a raw AUDF1 value stream.
  
• Use mux60 to interleave the two files together to produce a movie stream with 12 sectors (6144 bytes) per frame. The video is straightforward, but the audio layout is a bit crazy. The movie starts at sector 16.
  
• Mount the movie file as a hard drive image in SIDE 2 mode in Altirra to test, or write it onto a CompactFlash card for playback on real hardware.
  
• Run the movplay60 program on the Atari.
  

Obviously this is not a polished pipeline, so expect some difficulties. You need an NTSC computer to do this, as currently the audio layout is set up for 262 scanlines. No reason it couldn't be done in PAL, just that the player and multiplexer need to be modified and the hue mappings in the video converter would need tweaking. The existing player works on SIDE and SIDE 2, and could probably be modified to work on MyIDE or IDEPlus by changing the IDE register base and init paths.

 

The audio quality is about as good as it'll get, being about 6.5 bit PWM with error diffusion during the conversion. Classic 4-bit volume audio could be done too -- it would give better bass and less hiss at the cost of sounding a bit muffled.

 

The video conversion, on the other hand, could use some improvement. Currently encvideo60 converts the luma by applying a 2:1 reduction box filter and then Floyd-Steinberg error diffusion to go to 4-bit, while the chroma goes through a 4x4 ordered dither. I originally wrote this when the best I could do was 7.6 fps, so this could be improved by adding error diffusion to the chroma path and also doing temporal dithering (2-frame flicker). With regard to the wacky math in the chroma path, it is first converting the Cb/Cr to RGB and then to I/Q, then converting that vector to polar form to extract Atari hue. Dither is then applied both to the hue and to saturation (i.e. color or no color).

 

I didn't even think about FAT32, but that seems doable and a good idea. It would need 8KB sectors with the current video format. There's not really enough time to read FAT sectors during playback but there's plenty of memory to buffer up a minute or so of sector start numbers.

movplay60.zip

[Stephen J. Carden]

This is some of the coolest work I have seen to date! Good Job in showing us yet another thing our little 8-bit can do!

 

Stephen J. Carden

[fibrewire]

So you're saying that there will be CUT SCENES for the soon-to-be-released Atari Strip Poker Game?!?!

 

Edited April 28, 2013 by fibrewire

[phaeron]

Here's a test hard drive image. Up to this point I've had to upsample 24-30 fps sources to 60 fps. I wanted to test with a real 60 fps source, so I captured myself going around the track really sloppily in Gran Turismo 3.

 

http://www.mediafire.com/?amr7qnxb82z8q75

 

To test in Altirra, go to System > Hard Disk, enable HD, set Hardware to SIDE 2, select solid-state device mode, select the extracted testhd.bin, enter 256 as Resulting Size (MB). Then boot movplay60.obx.

[pixelmischief]

Holy fuck-knuckles! We're gonna get FMV gaming on the Atari 8!

[Xuel]

Cool! Looks even more awesome with PAL blending enabled.

 

 

Here's a compiled movplay60.obx for anyone who needs it:

 

movplay60.obx

[seban]

Hi!

 

I never thought I'd see the day, in which the 8-bit Atari will be able to play high-quality video! Fantastic Idea and great work Avery!

 

greetings

Seban

[flashjazzcat]

What's especially wonderful about this is that it's done entirely in software without any add-on DMA controllers. Simply great lateral thinking and using the power of the existing hardware in inventive ways. This is a tremendous win for the A8.

[TMR]

So... game with pre-rendered backgrounds done using this when...? =-)

[Irgendwer]

Great and fascinating!

Who likes to do a 'Dragon's Lair' conversion?