27 replies to this topic

[chjmartin2]

Hi all,

This is not the best output I can produce and the audio is a little fast, but this was enough progress that I felt ok starting the topic for further work. What you are seeing here is a combination of my graphics conversion code, my video loop playback code and my sound playback code. The loader is in incremental bytes so as to try to time the audio correctly. I haven't cycle counted the code yet, so there could be some imbalances. Also, the gain on the audio input was adjusted to boost the volume to try to drive the audio above the noise, but sacrificing some dB range. (I think.)

The binary format is AUDIO+CHARACTER+COLOR+CHARACTER+COL+CHARACTER+COL+... There is one audio byte for every 8 character and color bytes. The player reads these in sequence and plays back the audio in time to the video. The player does not wait for any vertical retrace (which could improve the code if properly cycle counted.) The length of the video is 29.055 seconds and the number of frames is 508. This audio is encoded at ~14kHz. One bit sigma delta modulation with gain was applied. More to follow... (The converter seems to work better with cartoons, but I really want to optimize those. I'd expect that I will be posting several videos over the next few weeks.)



Thanks,

Chris

[intvnut]

Funny you should pick Dallas, since I work in Dallas!

Too cool!

(EDIT:  And yes, I've actually visited South Fork Ranch.  My employer has held a couple outings up there.)

Edited by intvnut, Tue Mar 6, 2012 11:30 PM.

[revolutionika]

Pretty cool!

Can you do Spongebob NEXT?

[chjmartin2]

There is a Commodore 64 Dallas Video out there which was my inspiration.



Obviously my video isn't as good - but I think it was a bigger challenge...

I have more videos to post.  Thundercats Intro, Mask Intro, Simpsons Intro, a Clip from Glee .... and anything else I might think up.  I plan on enjoying converting some videos.

I also believe I can enhance the sound with some oversampling.  

I believe if I two-repeat my SDM playback that it will work.  (10110100 would be played back as 10101111010100)

[chjmartin2]

revolutionika, on Wed Mar 7, 2012 8:23 AM, said:

Pretty cool!

Can you do Spongebob NEXT?

I'll post Sponge Bob tonight...

[revolutionika]

chjmartin2, on Wed Mar 7, 2012 9:02 AM, said:

revolutionika, on Wed Mar 7, 2012 8:23 AM, said:

Pretty cool!

Can you do Spongebob NEXT?

I'll post Sponge Bob tonight...

chjmartin2, on Wed Mar 7, 2012 9:02 AM, said:

revolutionika, on Wed Mar 7, 2012 8:23 AM, said:

Pretty cool!

Can you do Spongebob NEXT?

I'll post Sponge Bob tonight...

Really?  Thanks.  

[catsfolly]

It sounds like you are trying to play back the real sound track from the Dallas intro , while the Commodore movie is playing a version of the soundtrack made for their sound chip.

So, they are cheating....

[chjmartin2]

catsfolly, on Wed Mar 7, 2012 3:59 PM, said:

It sounds like you are trying to play back the real sound track from the Dallas intro , while the Commodore movie is playing a version of the soundtrack made for their sound chip.

So, they are cheating....

I agree - they ARE cheating!  

[revolutionika]

When will you be making a Debbie Does Dallas conversion movie?

[chjmartin2]

I will make some porn for people - but I'll have to find a way/place to post it...

[GroovyBee]

Surely the Aquarius is porn enough?

[chjmartin2]

I converted Spongbob last night, but I had to go to bed before I could post it.  I'll post it tonight.

I used the full character set for Spongbob.

Basically I can convert 508 frames of video and playback at up to 17.5 frames per second with synchronized audio.

The audio sampling rate has to vary by the playback speed, but is going to be around 10,000 Hertz and a fixed sample count of 487,680 samples, or 120 Bytes of audio data per frame.

I have extra cycles at lower frame rates, so I want to try to implement a real-time over sampler.

Once I get settled, I plan on converting a bunch of movies.  This was my goal from the start - synchronized video playback - so I am pretty proud of it.  I need to post more so you'll be sufficiently impressed as the Dallas video isn't really the best example.

[vprette]

is something like this faisable on Intv?

[chjmartin2]

Intellivision has a screen that is 159x96 bitmap.  The processor being 800 kHz may be a problem...

I'm not sure.  No idea.  The Aquarius Z80 is at 3.5 MHz, but it isn't 16 bit...

I am sure something could definitely be done!

[revolutionika]

chjmartin2, on Wed Mar 7, 2012 9:56 PM, said:

I will make some porn for people - but I'll have to find a way/place to post it...

chjmartin2, on Wed Mar 7, 2012 9:56 PM, said:

I will make some porn for people - but I'll have to find a way/place to post it...

I was just joking!  

[chjmartin2]

revolutionika, on Wed Mar 7, 2012 11:10 AM, said:

chjmartin2, on Wed Mar 7, 2012 9:02 AM, said:

revolutionika, on Wed Mar 7, 2012 8:23 AM, said:

Pretty cool!

Can you do Spongebob NEXT?

I'll post Sponge Bob tonight...

chjmartin2, on Wed Mar 7, 2012 9:02 AM, said:

revolutionika, on Wed Mar 7, 2012 8:23 AM, said:

Pretty cool!

Can you do Spongebob NEXT?

I'll post Sponge Bob tonight...

Really?  Thanks.  

Copied from Youtube:

Here is a capture of my Mattel Aquarius playing the Sponge Bob intro in its entirety.  It is a 17 fps frame rate.  320x192 limited resolution.  (The pixels are 320x192, but only for a predefined character set of 8x8)  It is 16 colors but limited to 2 colors per 8x8 block.  The character resolution is 40x24.  The sound playback is 1 bit at just under 12 kHz.  The playback is enabled by using the SuperCart I with a 1 Megabyte EPROM (27C080.)  The output to the TV is from an Intellivision composite mod installed into the Aquarius.  The video/audio stream is interleaved, with one byte for audio followed by two bytes for 8 character/color combinations.  The Mattel Aquarius has a 3.5 Mhz Z80 and only 4K of RAM.

[jaybird3rd]

Well, I finally had the chance to check out your handiwork (most of the machines I use every day are not Flash capable), and I must say that I am duly impressed.  With enough dedication and clever programming, it's amazing what the "worst computer of all time" can do.

[intvnut]

chjmartin2, on Thu Mar 8, 2012 2:28 PM, said:

Intellivision has a screen that is 159x96 bitmap.  The processor being 800 kHz may be a problem...

I'm not sure.  No idea.  The Aquarius Z80 is at 3.5 MHz, but it isn't 16 bit...

I am sure something could definitely be done!

Well, it's not actually a bitmapped display, but rather character oriented like the Aquarius.  It does allow you to define 64 character tiles with whatever you like, though, which would let you do an arbitrary bitmap.  

The Intellivision's character grid has half as many characters across and vertically as compared to the Aquarius.  It has a similar foreground/background color scheme, but is slightly more restrictive.  So, color is definitely a challenge, and Intellivision's huge, chunky fonts probably won't work very well pretending to be hunks of video.  That leads to using the GRAM in a bitmap-like way.

If you didn't mind having the video in a tiny window, you could probably do something that looks acceptable in black-and-white in a, say, 64 x 48 region of the screen at something less than 60fps.  64 x 48 would take up 48 of the GRAM cards.  If you're super aggressive, you can update half of the GRAM cards every frame, so you could support a full bitmap refresh at 30fps.  (You may be able to update as many as 29 GRAM cards per frame, although you'd have to unroll the code 100%.  If your bitmaps have repeated pairs of rows, you may be able to update even more cards, but the required ISR gets trickier.)  

Probably the most straightforward way to get B&W in that scheme would be to set background cards to either "black & grey" or "grey & white" or "black & white".  You can maybe use MOBs to clean up places where you need a lot of black, grey and white simultaneously.

None of this considers the audio.  The STIC cycle-steals from the CPU, so doing PCM playback via the PSG's volume registers (something both Arnauld and I have experimented with over the years) sounds pretty crummy unless you also blank the display.  And if you're really soaking the GRAM to get the bitmap updates, that doesn't leave much, if anything, left for playing PCM data.  You'd probably just want to stick to tracker-driven music like the C64 Dallas video.

[theloon]

The graphics are indeed impressive.  I'm a bit biased as I've always loved ASCII.

Nevertheless, the sound is what I'd imagine having a bad acid trip entails..

Edited by theloon, Fri Mar 9, 2012 4:48 PM.

[chjmartin2]

intvnut, on Fri Mar 9, 2012 4:37 PM, said:

chjmartin2, on Thu Mar 8, 2012 2:28 PM, said:

Intellivision has a screen that is 159x96 bitmap. The processor being 800 kHz may be a problem...

I'm not sure. No idea. The Aquarius Z80 is at 3.5 MHz, but it isn't 16 bit...

I am sure something could definitely be done!

Well, it's not actually a bitmapped display, but rather character oriented like the Aquarius. It does allow you to define 64 character tiles with whatever you like, though, which would let you do an arbitrary bitmap.

The Intellivision's character grid has half as many characters across and vertically as compared to the Aquarius. It has a similar foreground/background color scheme, but is slightly more restrictive. So, color is definitely a challenge, and Intellivision's huge, chunky fonts probably won't work very well pretending to be hunks of video. That leads to using the GRAM in a bitmap-like way.

If you didn't mind having the video in a tiny window, you could probably do something that looks acceptable in black-and-white in a, say, 64 x 48 region of the screen at something less than 60fps. 64 x 48 would take up 48 of the GRAM cards. If you're super aggressive, you can update half of the GRAM cards every frame, so you could support a full bitmap refresh at 30fps. (You may be able to update as many as 29 GRAM cards per frame, although you'd have to unroll the code 100%. If your bitmaps have repeated pairs of rows, you may be able to update even more cards, but the required ISR gets trickier.)

Probably the most straightforward way to get B&W in that scheme would be to set background cards to either "black & grey" or "grey & white" or "black & white". You can maybe use MOBs to clean up places where you need a lot of black, grey and white simultaneously.

None of this considers the audio. The STIC cycle-steals from the CPU, so doing PCM playback via the PSG's volume registers (something both Arnauld and I have experimented with over the years) sounds pretty crummy unless you also blank the display. And if you're really soaking the GRAM to get the bitmap updates, that doesn't leave much, if anything, left for playing PCM data. You'd probably just want to stick to tracker-driven music like the C64 Dallas video.

I really do not know anything about the Intellivision from a programming perspective. I'd imagine that knowledge is somewhat transferrable, but clearly significant differences exist. I am considering upgrading my video player to use the PSG in the Aquarius expander. I could probably reverse engineer the Viterbi (sp?) alg from the MSX audio converter - which seems to work really great. I also have a cool idea for my video player that I want to try out this weekend. I am not sure I'd take on this activity for another device just yet. I kind of want to learn some Atari 2600 stuff - I have toyed with it a bit. Not sure where to go from here. A guy at work today gave me an old 486 - at least that is what I think it is - an old 486 laptop. I always wondered why Assembler was so fast - now I know why. There is so much to explore, but I have to tell you that I am still bugged out by the video of the kids freaking out from the Sponge Bob fake drinking straws.

Anyway... As I understand it you are very experienced on the INTV. I had to write programs to format my data, etc. Aren't there BMP Intellivision conversion tools?

[intvnut]

chjmartin2, on Fri Mar 9, 2012 6:29 PM, said:

Anyway... As I understand it you are very experienced on the INTV. I had to write programs to format my data, etc. Aren't there BMP Intellivision conversion tools?

I think Arnauld has written some tools to convert bitmaps into assembly code.  I've written my own programs to do similar things as needed.  Since there aren't very many pixels to manipulate, I tend to just draw everything out in macros that convert the graphics to bits.  

If I or someone were to write a video converter, they'd have to format the data themselves, and possibly output it directly to a binary format.  Currently, our assembler doesn't handle ECS-style bank switching, so you'd have to generate the raw binary image directly and concatenate it to the player.  (That's how I currently build Colossal Cave for the Intellivision.)  The assembler does have support for Intellicart-style paging, but that only gets you 64K words.  With ECS-style switching, you can address nearly 1M words.  The JLP gives you around 120K words currently via this method, but theoretically, you could spread a large game across multiple JLP chips.

[chjmartin2]

intvnut, on Fri Mar 9, 2012 6:38 PM, said:

chjmartin2, on Fri Mar 9, 2012 6:29 PM, said:

Anyway... As I understand it you are very experienced on the INTV. I had to write programs to format my data, etc. Aren't there BMP Intellivision conversion tools?

I think Arnauld has written some tools to convert bitmaps into assembly code.  I've written my own programs to do similar things as needed.  Since there aren't very many pixels to manipulate, I tend to just draw everything out in macros that convert the graphics to bits.  

If I or someone were to write a video converter, they'd have to format the data themselves, and possibly output it directly to a binary format.  Currently, our assembler doesn't handle ECS-style bank switching, so you'd have to generate the raw binary image directly and concatenate it to the player.  (That's how I currently build Colossal Cave for the Intellivision.)  The assembler does have support for Intellicart-style paging, but that only gets you 64K words.  With ECS-style switching, you can address nearly 1M words.  The JLP gives you around 120K words currently via this method, but theoretically, you could spread a large game across multiple JLP chips.

I use TASM and I don't know how to use any advanced features.  Frankly, I can't even set variables correctly.  I have to hand assemble the binary data and then use that as a data source for conversion code loaded in the first 8k.  The bankswitching is relatively elegant, as long as you can fit all of your program code in 8k (which is a boatload for Z80 ASM.)  Jay's card makes this possible - I wouldn't have a shot at this without it.

[chjmartin2]

Thundercats Introduction



~7 fps.  6.4kHz 1 bit Sigma Delta Audio

[chjmartin2]

Here are some more technical details about my converter.  I am going to show the same frame converted in each of the available modes in the converter so you can really see the options:



You can see there are many modes which include multiple dithering and character selection options.  Switch driven in the code.

[thegoldenband]

chjmartin2, on Thu Mar 8, 2012 7:33 PM, said:

Here is a capture of my Mattel Aquarius playing the Sponge Bob intro in its entirety.

Very cool, but -- and forgive me if you've already answered this -- why is the audio going about 25% too fast?  (I assume the video is too.)

EDIT: Never mind, you address this in the OP, I think.  Carry on!