Animation playback on the TI-99/4A

[Willsy]

Okay, I've downloaded the custom classic99 (further up in the this thread), I've assembled the corrected video player code (also further up in this thread). Now what?

 

I had to create a DSK1 folder for the custom classic99 - I put the videoplayer obj file in DSK1 and load from the ED/AS opt3. I also put the the video binary (the huge file) in DSK1. I just get a black screen. Any ideas?

 

Thanks

 

Mark

[Willsy]

Ah we posted at the same time, Tursi. Will try the above. Thanks!

[Willsy]

Quick check. From the readme file from the video convertor package:

 

 

The cartridge file (finalPACK8.bin) is a 378 bank-switch type cartridge. It's padded to a power of two multiple, but, note that this bank switch mechanism has a total possible size of 32MB. The maximum hardware cartridge we've built today is only 2MB, and that is the most Classic99 will load as of version 377. All the code is built in to the cartridge.

 

Does that mean we can just mount the cart using the Cartridge-->User-->Open menu method (assuming use of the "big hack" version of classic99)? I'm at the office at the moment so I'm not able to try any of this out!

Edited February 17, 2015 by Willsy

[Tursi]

Don't use the custom Classic99 anymore - the hack is rolled into the released version and only activated if you pass a filename on the command line. USE THE DEBUG LOG to make sure that it found and loaded your "big file".

 

Classic99 can't load cartridges larger than 2MB - anything bigger will be truncated. The "big file hack" allows unlimited files to be accessed through a different access mechanism for which the hardware is not yet designed. Just run from the command line (make sure you are in the Classic99 folder) and pass the filename of the "big file" as an argument, like so: classic99.exe finalPACK.bin

 

Then look at the debug log and make sure it found and loaded it. Size is unlimited in this mechanism but it's all loaded into RAM, so I don't recommend files larger than available RAM.

 

[Tursi]

(Also, don't assemble the file from earlier in this thread anymore, use the one included in the tools archive, it's tested. The one you assembled SHOULD work, but I've no way to troubleshoot it.)

[Tursi]

I guess I'll take 10 seconds to explain what the players do...

 

The cartridge version of the players uses the 378 (non-inverted) bank switch mechanism. While Classic99 currently only loads up to 2MB carts, the /concept/ is expandable to 32MB (then we need a new concept), so the tool will repack videos up to that size. I'll need to update Classic99 to allow it, though. In these cartridges, the first page contains the player, and a bunch of audio mute bytes in case the page is played by the video player. Every other page contains a small header to allow the TI to put it in the selection menu and select the right page before continuing, and one frame of AV data. Timing is not counted on this version right now, I just did a quick hack of the original player in order to get it tested on hardware. I've no idea how it sounds but it /might/ be noisier than proper timing would be (unlikely one could tell, though.)

 

The other file output by the script is the raw AV data. It's not framed into 8k chunks, it all runs together, and does not include a player. Right now, the only way to play this file is through the 'big file hack' described above. The hack defines two important addresses in the ROM cartridge space. Anytime the TI reads address >6000, the file pointer is reset to the beginning of the file (ie: reset). Anytime the TI reads address >7FFF, it gets the next byte of the file. So videoblaster.obj simply reads all the data from >7FFF continuously (no paging needed). For this one I've measured out the cycles and every audio sample should be precisely spaced.

[Tursi]

Apologies, it would appear I lied.. the current version of Classic99 limits the BigArrayHack to 20MB, so if you've seen glitching on bigger files, that's why (20MB doesn't line up with the end of a frame, and the data stream just wraps). I'll fix it to work as described above.

 

I'm in the final steps of testing a pretty heavy stress test of all the tools - I converted the entire Lion King movie. It found a number of bugs with large files. Hopefully, before bed tonight I'll try to release all the new code. The good news is that the conversions work - as long as the tools finish, your files are valid. The problems I've seen:

 

-tividconvert script hangs on the mogrify step (resizing images). The effect of this is that your frames may not all be resized. Usually there is not a huge time loss on this, rather than go into huge details I'd say kill it, delete the temp folder and wait for the new release (OR do the steps by hand, the hang is caused by my text output buffer filling up ).

-audioconvert crashes - this happens on an audio file larger than 10MB. Bugfix version required. Keep your temp folder safe and you can do the rest of the steps by hand -- all the longest steps of image conversion are already done.

-Playback crashes around 5 minutes in. This is a Classic99 "bug"/feature limiting the big file hack to 20MB. New version coming. Your output file is fine, keep it.

[+acadiel]

Newest conversion with Turi's tool:

 

https://www.youtube.com/watch?v=ubpoOEQc0Nk

[+acadiel]

Tursi, what do use to capture the video playback in classic 99 (in order to upload it to YouTube)?

 

Not sure what he uses, but I've been using a program named SnagIt for a long time. The videos it captures are super sharp, but when I upload them to YouTube, they seem to lose some of their fidelity.

[sometimes99er]

I want to see a video playback of a game played on the TI

Good idea.

 

I guess one could "just" record bytes going through VDPWA, VDPWD, SOUND and SPCHWT, and sync it with the VDP interrupt.

 

Playback is of course just pushing/streaming the bytes back. Crystal clear "video".

Edited February 17, 2015 by sometimes99er

[Tursi]

I've just published the toolchain with the fixes as noted above:

 

http://harmlesslion.com/software/tividconvert

 

I exercised the toolchain by converting the entire movie The Lion King. That found a good number of size limitations, which are all fixed (there's a new Classic99 posted too). The result was not bad.. audio was a bit hissy and there was a LOT of red (all the lions, much of the land ). But it was enjoyable.

 

It did bring up one other issue that I did not resolve in the toolchain -- over 75 minutes the rounding error on the audio amounted to it coming up about 20 frames short (which is about 2 seconds). I manually re-ran the audio conversion steps, increasing the frequency until the error was less than a frame. Even for this large a project, the audio conversion and video packing is pretty quick, it's mostly the Convert9918 stage that takes a long time (about 20 hours in this case on my machine). To facilitate this, the tividconvert wrapper tool will ask at the end if you want to save the temp files. If you think the audio error is such that you will want to manually repack, SAVE THE TEMP FILES. You can easily delete the temp folder later.

[Willsy]

Just got a chance to try out Money For Nothing (Dire Straits). WOW! I was amazed. The video is surprisingly clear, very watchable indeed. However, the thing that most impressed me is the audio. My jaw just fell open. You can clearly hear the bass guitar. The drums at the beginning are clear. Everything is there. You can ever hear the hi-hat lifting at the end of every few bars. The vocals are totally clear. You can clear hear Knopflers voice, and it's identifiable as Knopfler. Same for Sting. Incredible.

 

Tursi, how are you doing the audio?

 

We have GOT to get these videos running on real hardware. Cart is probably the easiest way to do that - stick a f**kton of memory in a cart and have at it.

 

Tursi you ROCK man.

 

[edit: I'll upload a video tonight]

Edited February 18, 2015 by Willsy

[Tursi]

Jim has already run the Spaceballs video on real hardware and confirmed for me that it works - I needed that before I released it. I don't know how well because I don't have any hardware to test on, but he says it was clear and he timed it for me, and it was within margin of Classic99's playback time, so it must be pretty close. The one difference is there is probably slightly more distortion in the audio, because there is a 50+khz carrier frequency underneath the audio that I don't emulate. But it should also be pretty close.

 

Audio is running at roughly 13khz. The converter first converts the audio from whatever it is in the video to 8-bit unsigned, and then my own packing tool maps the 8-bit unsigned to the 4-bit logarithmic attenuation of the TI sound chip. It does NOT do a fully accurate conversion, rather it does a manually-tuned scaling, softer sounds are made louder, and louder sounds compressed into the remaining space. I did this after a lot of experimenting, and noticing how soft sounds became crackly or outright lost when cut down to 4-bit. I changed it so a single step on the 8-bit scale became a step on the 4 bit scale, so you could hear it. (Otherwise you needed a step of 16!) While this increases the noise of noisy tracks, it made such an improvement that I kept it. (And if you listen to the 8 bit audio, you'll hear it's not so far off anyway!) I'm still learning what tricks the ear likes and which ones it doesn't, but this one works. I'd still like to test trying to keep the noise channel flat for digital playback, but I don't have a console right now.

 

After that it's easy. The playback happens in stages. There's a total of 6k of data to send to the screen per frame, split into 8 chunks (four for each table). 6 of the chunks are because we need to change VDP address, and the other two are just to keep all the chunks the same size, which helps a little with the flicker. It sends a chunk of pattern, then the related chunk of color, and then repeats. Every four bytes of video, one byte of audio is sent. And to keep the audio smooth, each time we need to reload the VDP address, we also send an audio byte. (There are no-ops in those areas that we'll eventually need to replace with counters so the video doesn't just loop ).

 

As noted, the 378 bank switch mechanism will support up to 32MB (that's just how many address lines we have, just need to shoehorn in another 378 (and probably another ROM with associated select circuitry). I'm working on the bigfilehack on and off.

 

I'm glad you enjoyed, I hope I can see your video.

[+acadiel]

Something like this could be used... but it's 3.6V and not 5V. Wonder if they have a 5V version

 

16 bit would mean... 512MB? LOL.

 

https://www.fairchildsemi.com/datasheets/74/74VCX16374.pdf

[+Ksarul]

Note that almost every single EPROM (or Flash chip) I've seen greater than 2MB is also 3.6V, and almost all of them are 16-bit. A few will work at TTL levels for inputs/outputs, but not many.

 

For the 5V operation, you'd have to use either a 74ACT16373 or a 74ACT16374. Then it is just a matter of finding a large enough EPROM/Flash chip that is TTL capable. If it ends up as a 16-bit device, we'd just lose half of the space without a lot of switching logic for the data lines.

Edited February 18, 2015 by Ksarul

[Tursi]

The flipflop's not really a problem, you can literally stick additional 378s right beside the first one without additional glue logic (might need to check how many devices we're allowed to drive off the write line though ). The additional circuitry issue comes from needing additional EPROMs, if we stick with the large DIP ones I think we're limited to 2MB (maybe 4MB? I can't remember what I last saw). When you add a second chip, you need some additional logic to select the correct chip. I did this with my recent Genesis cartridge project, where I just copied a circuit Sega used based on a quad NAND gate, so it doesn't take much.

 

If we move up to the more modern flash chips, voltage conversion isn't really a huge deal. There are devices specifically designed to do it, and there are (were?) 5-v tolerant CPLDs that we could just throw all the banking into and get free voltage conversation as a side effect - that's how the Jaguar Skunkboard worked.

 

Kind of pie in the sky right now, though We'll get around to it!

[sometimes99er]

There are obviously different solutions to animation playback.

 

I'm probably going to miss a few points, but you can choose smaller window sizes, lower frame rates, less color information, less pattern information, less resolution and compression including only storing changes from frame one to the next. Apart from creating and perhaps optimizing the stream on a more powerful computer.

 

This one from the Spectrum seems to use only part of the display with a letterbox effect (may be the video source) and updating patterns without updating color information. The letterbox seems to "save" 4 characer lines at the top and the bottom, so out of the 24 lines only 16 needs updating. The letterbox effect may however look awful on European TI's as there's already a letterbox effect to the 24 lines. An update like this will take 4K per frame. One could set a limit of 2K per frame (if that's possible on the TI) and only register changes. If the complete frame changes, then the frame rate would occasionally drop from maybe 60, 43 or whatever, to at least 30.

 

Other than that, the "cheaper" (faster to calculate) ordered dithering (Bayer) used here seems more relaxing to the eye than Floyd-Steinberg (with smaller changes in one area maybe leading to many pixels being affected giving a "nervous" experience).

 

Edited February 20, 2015 by sometimes99er

[Tursi]

It may not be clear from the videos, but the tools I published do convert to use only 50% of the display - 12 lines and 16 columns. So a total frame (color AND pattern) is 6k. I do agree that for some things an ordered dither is nicer than the more complex ones (I[m using Atkinson - for color bitmap it usually produces better results than ordered) - but I need to add more command-line options to Convert9918 before my script will let you select that. And of course the Bad Apple demo was pattern table only on top of only 50% of the screen, which is how the frame rate got up there.

 

I messed around a little with really, really dumb compression techniques to bring down Bad Apple. One lossy approach with a prebuilt dictionary brought the video from 11.7MB to 4.3MB with only a single cycle lookup needed to play it back (but I have nothing for the audio, and that was still too big). It looked "okay".

 

Dirty rectangle is a time-honored and usually very effective technique for video compression, and any serious project will probably want to look at it. The main issue with it is the difference between best case and worst case is huge, so you need to be able to cope with that.

 

Audio's really the big pain. You have to do it on reliable timing, no matter what else is going on, or it adds additional noise (and the 4 bit resolution plus the carrier frequency gives you a pretty noisy base). I tested to see whether you could vary your updates as long as the overall waveform still tracked, and it was completely hopeless, you MUST update the volume at a steady rate or you can hear it. With no reasonable timer to help this in hardware, you're down to cycle counting, and that means every path through your decompression technique, whatever it is, needs to be counted and interspersed with audio updates.

 

Anyway, my only purpose here was to prove to myself it could work and play with things I'd always wanted to see on our machine.. Hopefully others have fun with it too.

[sometimes99er]

I'm not trying to interrupt, divert or criticize as such, just trying to put other perspectives on the topic of "animation playback".

 

While at it, with the TI-99/4A out of its time-frame (nostalgia), advances in many areas since then, cross platform processing, - well, how about having the audio on cassette. I know, laughable, but why not, - an option.

 

This should actually be part of emulation as it was possible with a very small, standard and common TI-99/4A setup.

 

Back in the day I did do this, instruct the user to rewind tape and press play, and then controlling the power to stop and go - if it wasn't actually done on another computer.

[am1933]

Just got a chance to try out Money For Nothing (Dire Straits). WOW! I was amazed. The video is surprisingly clear, very watchable indeed. However, the thing that most impressed me is the audio. My jaw just fell open. You can clearly hear the bass guitar. The drums at the beginning are clear. Everything is there. You can ever hear the hi-hat lifting at the end of every few bars. The vocals are totally clear. You can clear hear Knopflers voice, and it's identifiable as Knopfler. Same for Sting. Incredible.

 

Tursi, how are you doing the audio?

 

We have GOT to get these videos running on real hardware. Cart is probably the easiest way to do that - stick a f**kton of memory in a cart and have at it.

 

Tursi you ROCK man.

 

[edit: I'll upload a video tonight]

Never mind about all this audio quality, what about the woman in the video, did she retain her "clarity"

[Tursi]

While at it, with the TI-99/4A out of its time-frame (nostalgia), advances in many areas since then, cross platform processing, - well, how about having the audio on cassette. I know, laughable, but why not, - an option.

 

I actually did this back in the day, too, it was cool to hear the soundtrack startup on demand. But requesting the user rewind was annoying.

 

I should have tried one of those loop cassettes they used for answering machines

[+OLD CS1]

 

I actually did this back in the day, too, it was cool to hear the soundtrack startup on demand. But requesting the user rewind was annoying.

 

I should have tried one of those loop cassettes they used for answering machines

 

8-track, baby!

[+acadiel]

Saw this in today's news. I think we have the NES beat by a few years.

 

http://gizmodo.com/netflix-on-an-nes-is-the-best-worst-way-to-watch-netfli-1690585053

 

[sometimes99er]

Saw this in today's news. I think we have the NES beat by a few years.

 

http://gizmodo.com/netflix-on-an-nes-is-the-best-worst-way-to-watch-netfli-1690585053

 

 

Not quite, but we could try. They probably got a PC handling logon, communication between Netflix and NES, apart from realtime dithering of images before sending the "image" to the NES. And then a 256K cart to do the GUI etc.

[Omega-TI]

 

Not quite, but we could try. They probably got a PC handling logon, communication between Netflix and NES, apart from realtime dithering of images before sending the "image" to the NES. And then a 256K cart to do the GUI etc.

 

A fancy new 2048K cart to hold all the coding, an F18A to cover a somewhat marginal display, and a UDS-10 to bring it all in... all piped into the ultra limited 32K choke point of the TI? While it may be technically possible, I question the sanity of such a project.