pouët.net

Most of the questions you may want to ask will more than likely have the answers as below. So let us start.


WHY EASYFLASH AND NOT D64 OR SINGLE FILER?

A good music video type of demo with digitized audio on the c64 can be done in a single filer or running from a floppy, but there are several restrictions..
Storage space is one of the major ones. This can be circumvented by using a tune that only has a few loops that are sequenced together and some select effects that do not rely on full blown FMV

But as soon as wanting the wish of a whole 3 minute track with vocals at high quality and requirement of thousands of frames of unique video frames, the reality of this being a single filer or a disk based demo is a non-reality
(an exception may be the requirement of multiple disk swapping occasionally, but this would be cumbersome)

Secondly access to data at anytime was another requirement. There are many nice irq loaders including those by krill and bitbreaker and these can load in the region of 6-7k a second providing there is not much cpu usage in the demo while loading.

It could have been a possibility to load and depack data to a buffer while previous video frames were being played back, but as the cpu usage on the 25 frames per second video update and digital audio is constant most of the time, the loader would take considerable amount of time to load and depack to the other buffer leaving some delays. Remember the first point mentioned in the sentence "access to data at anytime"

The video consists of many thousands of frames each of which can be replayed back at any point without any delay whatsover

So overall, reasons for it being easyflash is that i need the storage space for thousands of frames and high quality full audio with vocals and also required data on immediate demand. However i did not want to go overboard with storage so i limited it to a 1mb easyflash cart.


OK, EASYFLASH. NOW ALL YOU NEED TO DO IS JUST PLAY RAW SAMPLES AND LOAD FRAMES.

Wrong. 1mb may seem like a lot, but in order to fit thousands of frames and 3 minutes of digitized audio, both video and audio require realtime decompression on the fly in order to be packed to 1mb.
Secondly, the easyflash does not make the c64's cpu any more powerful, all code is still run on a c64. Easyflash is just there for the immediate data access and storage (in 16k banks) :-)


BAHH. THIS IS NOT A DEMO, ITS JUST AN ANIMATION PLAYER

Yes, it is an animation player. but one that does 25fps video depack full screen and decode WITH >8khz digitized audio depacking and playback via custom adpcm hybrid decode all on a <1mhz cpu.


NOT GOOD. QUALITY NOWHERE NEAR AS NICE AS THE REU VIDEO PLAYBACK DEMOS

These REU demos would typically use 16mb of data with each frame using more than 16k.. at 25fps, this would equate to over 400k of data per second giving only maximum 40 seconds of playback for unique frames (and no digitized audio)
Quality is excellent no doubt, but when the storage limit falls down to 1mb only and unique frames are much more as well as having a full 3 minute digitized soundtrack, there has to be a compromise in quality


TECH DETAILS OF THE DEMO PLEASE

Ok, lets start off with the audio.

The original track was over 3 minutes and would have took up approximately 1.7mb at 8.4khz if unpacked. My goal was to squeeze this down into around 230k without losing much quality.

I started by splitting the whole song into four bar patterns and removing redundant data. The end result was 52 four bar patterns that can be resequenced to form back the entire song.
The result in file shrinkage due to this was 2:1 resulting in the audio now taking approximately 850k.

I then packed each four bar pattern using my ssdpcm2-v2 audio encoder. This packs one second of raw 8.4khz samples (8400 bytes) to 2.2k resulting in overal pack rate of nearly 4:1 finally the whole tune is now in approximately 230k.

The ssdpcm2-v2 audio technique is an improvement over the ssdpcm2 method used in sampleblaster and algodreams in that it has double the lookahead bytes and uses windowing system with brute force to generate the optimum waveshaping parameters per chunk

The decoder on the c64 side uses codetables that translate compressed byte data to code segments with each codesegment shaping the waveform appropriately and convenientaly pushing it to stack ahead of time.
The NMI simply plays back the stack backwards making sure that important stack data gets saved/restored per frame

The playback method is using presetup d418 method which produces higher than 4bits output. It is strongly recommended to run this on a c64 with a new-sid. Any digiboost hacks on the sid will result in this demo producing garbage
as sound.
For this reason, if you are also running it on an emulator, ensure digiboost is turned off and select newsid (and resid, not fastsid). I also have autodetect for old sid with relevant table used, but results will vary. (Audio will sound louder and more crackly)

Overall, estimated cpu usage for the actual digitized audio playback and the ssdpcmv2 decode is around 50% of cpu per frame.


Now some information on the video.

All video in the demo is running at 25fps. In order for this to be achieved, a full frame needs to be read and decoded in two frames before switching over to the updated buffer.

This brings us to one of the main section that i was not too happy with. The compression of frames is not optimal.

Some solution to this (which would have then given the restriction of not allowing any frame accessible at any point) would have been to depack chunks to ram and then depack the semi-packed data when finished or to utilise delta encoding in the encoder so that only changes are plotted. (This would actually have saved cpu time for some cases)

In order to get 25fps playback (and bearing in mind that more than half the cpu is used for the digitized replay and decode) there is little time to use other efficient packing methods, but 240 bytes per frame is fine as it is in this
case.

Most of the video data is compressed using my updated TileX2 encoder which further shrinks CSAM frames to either 60 bytes, 240 bytes or 480 bytes. I decided to opt for the middle option and to also intermingle these with full csam frames in the demo (Internal updated build of CSAM which utilises DCT preconversion). As mentioned before, these semi-packed frames are directly written to the cart without any further packing.

The decode is straightforward. read 240 byte frame from cart, decode to 4 tilelookups and plot to screen.

TileX2 mode does result in blocky output (in comparison to standard csam frame) for this reason, i use d016/d011 shifting per frame to reduce the appearance of larger blocks. Yes i am aware that it is a quick workaround but it IS effective provided that it is run on either a real c64 or emulator with monitor at 50hz output


Information on the core of the demo

The core of the demo is in the music sequence replayer where i have placed sync markers which trigger one of many video sequences (and video depack types).
When the trigger is activated, the decode of the video starts (after variable delay, also specified in sync mark). When finished, it falls back to ram image playback synced to the audio until another trigger is generated


CONTENT BREAKDOWN

1 2x2 font (2048 bytes) 002,048 bytes combined
3 codebooks (intro logo+indemo (each 2048 bytes) 006,144 bytes combined
52 four bar packed samples (each packed to 4400 bytes) 239,616 bytes combined (padded to $1200 bytes)
34 gfx codebooks for video (each 2048 bytes) 069,632 bytes combined
30 tileluts for video (each 1024 bytes) 030,720 bytes combined
1772 frames tilevqmode (each 240 bytes) 453,632 bytes combined (padded to $0100 bytes)
215 frames csamdct (each 1000 bytes) 220,160 bytes combined (padded to $0400 bytes)
code and misc (approx 16k) 016,384 bytes combined


As you can see above, the 1mb has been greatly utilised.. however note that packing the actual crt image via zip or similar brings it down to around 700k. this is due to the framedata not being fully packed in the demo)


ACCESS TO DATA

In order to switch banks on the easyflash and actually access the data, $01 needs to be #$37. I am using config switching in easyflash banks to $8000-$9fff and $a000-$bfff. I ensure that i set this back to #$35 after reading the data this is to save cycles on the nmi (which would otherwise run (SEI Jmp ($0318)) from kernal on each update eating up 7 cycles.
The result of this is that there is some variable delay in nmi sample update (due to the $01 switching) but it is not noticable.


DEVELOPMENT TIME

Nearly all of the development time for producing this demo was in the actual encoding and syncing of the demo. Millions of iterations per video sequences.
The actual demo code comprises of only a ssdpcm2-v2 depacker and tilex2/csam video decoder and the sequences trigger the relevant video sections. So the actual code is a animation player that plays back packed audio and video. ofcourse the highlights are full screen 25 frames per second video decompression and playback with realtime decode and playback of digitized audio.


HOW MUCH SPACE WOULD THIS DEMO TAKE IF IT WAS UNPACKED

Audio would take up 1.7mb
Gfx would be approximately 30mb

Hence compression level in this demo is around 32:1 If taking into account the 200 second runtime of video/audio, it would be equiv to a 40kbs stream (5kilobytes a second)

Digitized audio is possible on the plus 4. I would guess its register $ff11, but that only seems to have 3bit output. Hence unless there are other new techniques of digitized playback on a plus 4 machine, it would sound very noisy unfortunately. As an example, the C64 version outputs 6bits in this demo

I felt a bit guilty doing it for easyflash. However bear in mind that the easyflash is "only" for the storage and direct retrieval of the packed data. All depacking of audio and video is still done by the C64 albeit without the load and storage restrictions too much. It was mainly produced as a test for the easyflash cart and made a "demo" out of it. Overall it is only a animation/audio player that loads and depacks the data while playing back.

The hard part was the sequencing of the animations with the audio :-)