Media Player 128

[airship]

Uh... thumbs up for using Pink?

[Hydrophilic]

....using Pink?

At first I thought you were being sarcastic... but now I see it is a joke... umm the smiley should have clued me in.... Anyway... you're welcome... enjoy Pink

So after my my mental break, I'm finalizing the (demo) muxer... and adding primitive support for the VDC... please note 80-column mode only supports audio files... video is limited to 40-column (VIC-II)...

Can anyone provide links to some some SID files?

I am aware of the SID High Volume Collection for sale, but as I am not big SID fan, I have no intention to pay for a CD.  I have many games / intros / demos with SID music, but I am too lazy to try extracting the SID tunes from these files.

So if anyone could point me to some SID files for me test with Media Player 128, I would appreciate it...

BTW, did I mention I will release a demo with source for this Christmas?  You'll get credit of course... thanx!

[bacon]

I am aware of the SID High Volume Collection for sale, but as I am not big SID fan, I have no intention to pay for a CD.  I have many games / intros / demos with SID music, but I am too lazy to try extracting the SID tunes from these files.

So if anyone could point me to some SID files for me test with Media Player 128, I would appreciate it...

The High Voltage SID Collection. I'm not familiar with the collection you mentioned above, but I suspect it's a repackaging of the HVSC.

[Hydrophilic]

Thanks bacon!  I'm glad you knew what I was thinking!

I'm downloading the PSID64 collection now for analysis.  And it is free!

[Hydrophilic]

I wanted to get this online in time for Christmas, but it just so turns out the Christmas season is the busiest time of the year and I couldn't get it done in time.  This is mainly due to an unexpected last minute problem I found with the demuxer.  It's still not 100% fixed, but enough excuses!  If I don't get it out now, it may never be released...

This is the core audio/video player and it only supports one format... well 2 if you count video without any audio... well 4 if you count hi-res seperate from multi-color... well 8 if you count char-emulated bitmaps seperate from real bitmaps... the important thing is it plays videos with only 2-bit audio (if any).

I have a seperate audio player that 1-bit, 4-bit, and 8-bit digis and am working on SID file (non-digi) support.  That will eventually be merged into the player proper.  I've included the source files, the binaries and 2 videos, all ready to be downloaded to your CMD-HD, uIEC/SD/CF, or other mass-storage device.  Also included is a .d81 which (barely) holds one video for those who want to try it out in VICE (or want to try it on a real C1581, that would be interesting).

Even zipped up, it is too big for a forum post, so you can download it here.  Also it's an Alpha version (pre-Beta).  Intended mainly for CBM die hards.  If you've been following this thread, you should be aware of most of the issues.  If not, at least read the included Read Me.

With the right setup, even a noob can issue RUN"MPLAYER128.BAS".  You really just need to get the files onto a JiffyDOS device and you should be good to go.  Runs on both NTSC and PAL.

Funny thing is many games sound a lot different to me when running them on different standards, (NTSC or PAL), but this video player sounds pretty much the same either way.  Which it should because it is locked to the video which also needs to play at the correct speed.

If you have a sharp eye, you may notice some mis-sync between the audio and video when running it on VICE.  The only way I know to do it on VICE is with a C1581.  But of course it has a "track read" delay (I don't think it implements head movement delay).

However with a real C128 and uIEC/SD (and, I imagine, with a CMD-HD), there is very little mis-sync.  However the synchronization is pretty sloppy at this point.  With some work, it should be rock solid on slower devices like the C1581.

I would be interested in any reports from PAL users (any storage device) or from any CMD-HD or FD-2000 users (any video standard).  Um actually real C1581 reports would be nice too.

Anyway, Happy New Year!

I'm looking forward to fast-serial support on the uIEC so I can add that feature to the media player.  JiffyDOS is just too slow, which I think you'll agree after you see the videos.  Um, did I mention the audio is 2-bit... it's pretty harsh... you've been warned

Edit
I forgot to include the video encoder.  It runs from a Windows command line.  Might could run it in Wine, I dunno.  Making videos would be / should be as much fun as viewing them, but it isn't very fast.  On 1.5GHz P4, gray scale video compiles in real time, and color video takes twice as long.  I'm gonna test on a 3GHz Centrino and write up some notes on use.  It's a LOT tricker than simply viewing videos.

In the meantime, here's some more videos:

This one should be color, but most of it turned out grayscale "Bad Romance" 16:9 aspect ratio

This one really puts the VIC-II (and the encoder) through it's paces with bodacious use of color.  Despite the exotic palette, most of it turned it out okay.  It sounded fine in VICE, but on my C128, Snoop Dog had way to much base.  Katy sounds fine.  "California Girls" 16:9 aspect ratio

This is one of Hydro's favorites, a dripping wet Madonna, "Cherrish".  I don't know why it has such a low frame rate considering it is both gray scale and is smaller 4:3 aspect ratio.  Also, it runs reliably in VICE (both NTSC and PAL), but has high likelyhood of failing to play completely on my C128.  Annoying!  Maybe you'll have better luck with a different setup.

Another Madonna video.  Not that I'm a huge fan, it just turns out her videos compress a lot better.  Like Cherish, it is 4:3 aspect, and is gray scale, but it has a 2 to 3 x frame rate... go figure.  Most of my videos have a 136 pixel height and the width varies according to aspect ratio (this to provide a consistant 2MHz area for good data bandwidth).  However, I liked it so much, I decided to make a much larger, near-full-screen version (I think 160x188 ... whatever was discussed many posts ago in this thread).  Well I messed it up!  First, it encoded it in color instead of grayscale, and second, I forgot to tell the encoder to use a lower bandwidth (lot less 2MHz loading).  Interesting if embarassing.

Now Metallica is a band I like, unfortunately, I don't like most of their videos.  Here is an exception.  King Nothing.  I thought snowy atmosphere would be particulary appropriate for us in the northern hemisphere.  Unfortunately, it didn't turn out as nice I would like.  And this video also has a tendency to stop 3/4 of the way through (on my setup, runs fine in VICE).  Grrrr.  Oh, it's 4:3 aspect ratio.

This is probably my favorite video so far.  Poker Face.  Although it doesn't have the fastest frame rate, it isn't the slowest either.  More important, it has several scenes with rather different lighting properties, and the color turns out nice in nearly all of them.  I actually have 2 versions, with ever so slightly different encoding parameters.  One of them plays fine on my C128 and the other plays fine in VICE, but they fail to play about 50% of the time if played on the "wrong" system.  Dunno why yet.  If that one consistantly gives you trouble you can ask me for the other.  4:3 aspect ratio too.

Here is one in 16:9 aspect ratio.  Stronger.  Parts of it have an abnormally high frame rate because of simple black background.  I'm not complaining, I like it.  Note in this software, this still means a pathetic 4 or 5 fps.  It's suppose to be color, but except for one scene (which is as Hydro's luck would have, features a dripping wet Britney), it turned out gray scale.

I got several more, but I think that should give you an idea of the range of what this can software can do with JiffyDOS.  Of course there is still room for improvement in the video decoder and especially the encoder, but I wouldn't think it would be anything drastic to give you something like 10~20 fps.  We need fast-serial for that (or some other hardware solution).

Sad thing is, I still haven't come close to filling my SD card... which is the entire reason (or at least a main reason) I started this project.

Edit 2
I just re-uploaded Media Player 128 (4.7MB).  It now includes some missing source files, an audio encoder, a video encoder, some batch files, and a lengthy read me explaining how to make your own videos.  The encoders are Windows binaries.  The player is CBM software and the player source can be compiled on just about any platform.

[RobertB]

     I'm away from my main C128DCR set-up right now until January 3.  Then I'll try your program out.

          Truly,
          Robert Bernardo
          Fresno Commodore User Group
          http://videocam.net.au/fcug
          The Other Group of Amigoids
          http://www.calweb.com/~rabel1/
          Southern California Commodore & Amiga Network
          http://www.sccaners.org

[XmikeX]

I'm wondering if there's some place in your code for undocumented ops, especially in your timing sensitive portions.

For example, looking at some of your sources I noticed stuff like this:

jIRQ2r3.src
   lda myVicY+1   ;[4] get y_scroll and stuff
   and #7      ;[2] mask y_scroll
   clc      ;[2]
   adc #constC   ;[2]
   adc vHeight   ;[4] rasters in video

With respect to the AND / CLC sequence above, would it be desirable/useful to save 2 cycles with "ANC" instead?
If not, then how about elsewhere?  How about with other "illegals" like LAX, SAX, which seem to work solid on 128s (IIRC)? ...

This page seems to describe ANC nicely : http://codebase64.org/doku.php?id=base:some_words_about_the_anc_opcode

65816 accelerator compatibility? who cares!?  =)

XmX

PS: This was amusing for me as well .. http://codebase64.org/doku.php?id=base:decrease_x_register_by_more_than_1

[redrumloa]

65816 accelerator compatibility? who cares!?  =)

Already tried, doesn't work in SCPU turbo mode :-/

[Hydrophilic]

I look forward to your feedback, RobertB.

Thanks for the report, redrumloa It doesn't suprise me, it was only designed / tested for a stock 8502.

I hadn't thought about undocumented opcodes... the code you mentioned, XmikeX, isn't very critical... the critical part is in the 1MHz load data routines... in particular that fü¢king Byte_B ... oh what a pain... but without it, 1MHz loader would be reduced by 50%...

If you've ever had the player stop in the middle of a video (very annoying), it is probably that Byte_B code ... I'll take a look at using some undoc'd opcodes to see if I can fix that problem...

New Download for VICE Users(2MB)

I just realized that normal VICE will not run JiffyDOS on the 1581.  Silly me, I forgot I was developing with a mod version of VICE that implements missing features of the WD1770 chip. 

So for VICE users, I made a new download that includes a modified version of the 1581 JiffyDOS ROM.  The only thing changed is in the comparison of the CRC code.  For some reason, the CBM and JiffyDOS ROMs manually calculate the CRC and then compare it with that of the WD1770.  VICE will "magically" skip this part of CBM ROM (because VICE doesn't implement CRC in the WD1770), but it does not do it for the standard JiffyDOS ROM.  Anyway, the modified JiffyDOS ROM simply ignores the CRC value.

Here's step by instructions for VICE users:
1. Download and unzip the VICE version of Media Player 128 Alpha
2. Start VICE and be sure Options>True Drive Emulation is selected
3. Go to Settings>ROM Settings>Drive and for 1581, change the file to "Jiffy-1581-mod.bin" (be sure the path is correct for wherever you un-ZIP-ed the file)
4. Go to Settings>Drive Settings, and set device 8 to a 1581
5. (Now you're ready) Attach the player disk, "mp128a-vice.d81" to drive 8
6. Enter RUN"*

That should start the BASIC part which will load the JiffyDOS handler and the MPlayer ML code.

When it asks for unit and drive, just press RETURN (accept default unit 8 and drive 0).

Next it will ask you for a filename.  On the same disk is a video of "Single Ladies" so just enter "video.bin" and it should play 

Also included in the ZIP file is 2 more D81 images, with 1 video each; PokerFace.d81 and Somebody4Me.d81.  After watching the first video, you can attach either one, and then when it asks for a filename, just enter "MYV.BIN"

Unfortunately, none of the videos fit on a 1581 disk, so they will stop when they reach the last sector on the disk ... it should be obvious because the video will stop and the audio will go into an infinite loop; just press STOP to return to the BASIC program and you can play another video.

Also, I want to appologize / explain about the flashing border.  It is quite annoying!  But it is for debugging purposes.  Here is what the colors mean:

   
• Light Green - loading data and playing audio
• White - working hard - loading data, decompressing video, and playing audio
• Black - blocked - playing audio and decompressing video, but can not load the next video packet
• Blue - blocked - playing audio, maybe decrompressing video, but can not load the next audio packet
• Red - corrupt data discovered - this will happen at the end of the video (because it won't fit) or maybe due to a coding error by me
• Other color - not fully anticipated / coded exception - the player will usually continue (very rare)

If any VICE users have trouble, let me know.  The videos should play in both NTSC and PAL modes.  You may want to change the filter setting for NTSC to a larger value.  The ML part normally sets it to a larger value for NTSC, but the BASIC companion destroys that optimization so you probably want to set it manually (something like 150) if using NTSC emulation.

Edit
I just wanted to add that the JiffyDOS code is *critically* designed for stock 1MHz/2MHz operation... there is no way it will ever work at accelerated speeds; However, in the new year, I look forward to implementing fast-serial drivers.  Being hardware based, they should be CPU-speed independant, so there is a chance it may work on a SuperCPU (keep your fingers crossed).

Edit 2
Anyone with a real C128 or who wants to make their own video should download the full Media Player 128 Alpha.  I would love to see any video you make!  If you don't want to put your video out on the WWW, at least PM or Email me... thanks and Happy New Year!

Edit 3
I've posted several color images before, but they were I-Frames (high quality).  The actual video uses P-Frames (lower quality) a lot so I thought I would post some of them.  Many of the color frames suffer problems because, not only is the I-Frame encoding not yet as good as it is for gray-scale, but the P-Frame encoder was never optimized for color... in fact I'm suprised that color works at all!

[Mark Smith]

Just think how much fun you could have if you got one of those Chameleon carts (when they come out), more CPU power and more colours to play with :-)


I think having a CPU speed agnostic fast loader would be a good thing  as well.


Nice work, thanks for sharing!

[bacon]

And if he did it on a PC he'd have even more CPU power and colors...

Isn't the point of this to try to implement a media player on the C128 with its inherent limitations? Using something like the Chameleon would defeat the whole purpose in my opinion.

[Hydrophilic]

I am completely ignorant of Cameleon, but if somebody wants to adapt the software for it, I provided the source, so have fun!

Also, I changed my mind, and now plan on NOT using undocumented opcodes.  This is so hopefully it can run on SuperCPU.  Of course that could be considered cheating too, but it was released back in the day, so I would like the player to work with it, if possible.

redrumloa reported MP128 doesn't work on the SuperCPU, and a major reason would be because the JiffyDOS software requires 1MHz operation.  Searching the forums, I only found this thread which had no responses.

So, can somebody confirm that you can set the SuperCPU to 1MHz with POKE 53370,0 ?  That seem's dubious to me, because that is $d07a -- somewhere in the VIC I/O region, but I guess anything is possible with a hardware hack lack the SuperCPU...  Thanks!

Of course I still plan to add fast-serial support which should negate the software-load issue, but until then a little tweak like this would be useful.

Also, I would like to thank everyone who downloaded and tried Media Player 128 (the limited VICE version or the full version), and would love to hear your opinions.  Actually, I was expecting a bunch of "that's crap" comments and (maybe) some "that's cool" comments.  So far it seems like the opinion is "whatever".

So if I can make a request, could you let me know if you try it, and what setup you used (VICE, real NTSC, real PAL, C1581, uIEC, CMD HD, etc.) Thanks again!

Although I think it should work as-is with CMD-HD and uIEC (and JiffyDOS C1581), I was curious about 64HDD.  Has anybody tried it?  There is a thread somewhere about experiences with 64hdd, and it is noted it supports fast serial, but no mention about JiffyDOS.  When I check the website, it says Tolerent** and ** says "LPT port latency is critical.  My personal experience suggests that many fast loaders lose synchronisation"

[RobertB]

redrumloa reported MP128 doesn't work on the SuperCPU, and a major reason would be because the JiffyDOS software requires 1MHz operation.

The SuperCPU has a switch which disables its built-in JiffyDOS.

          FCUG celebrating 30 years,
          Robert Bernardo
          Fresno Commodore User Group
          http://videocam.net.au/fcug

[bacon]

I am completely ignorant of Cameleon, but if somebody wants to adapt the software for it, I provided the source, so have fun!

It's an FPGA implementation of the C64 with an accelerated processor (don't know if whether they've implemented a 65816 of if it's jus a sped-up 6510) and VGA out, in cartridge form, so you plug it into the expansion port of your C64. Not sure if it takes over all the C64 functionality or if the SID is still used for sound, but at least the VIC and processor is in the FPGA.

Also, I changed my mind, and now plan on NOT using undocumented opcodes.  This is so hopefully it can run on SuperCPU.  Of course that could be considered cheating too, but it was released back in the day, so I would like the player to work with it, if possible.

The SCPU 128 was released in the late 90s. That's not what I consider "back in the day". On the other hand, I don't consider anything cheating; it's your prerogative as the developer to do whatever pleases you. I just had the impression that you wanted to implement this on a stock C128.

[Hydrophilic]

Thanks for the info about the Chameleon.  Would it even work with the C128, in 128 mode of course?

You are right bacon, I would like it to run on a stock C128 becuse that is all I've got... but it would be nice if it could run on a 65816... using undoc'd opcodes could shave a cycle here or there, but the main problem is JiffyDOS is software based and hogs a lot of CPU power.

Also, I reread redrumloa's post, and it says it MP128 doesn't work in turbo mode... so it works with SuperCPU at 1 and 2 MHz speed?  That would be cool if true.

There are about half a dozen things that need to be improved, so any feedback to help me prioritize things would be appreciated.  Thanks!

[tokra]

So if I can make a request, could you let me know if you try it, and what setup you used (VICE, real NTSC, real PAL, C1581, uIEC, CMD HD, etc.) Thanks again!

I was trying this on my C128D with UIEC (but NO Jiffy DOS). I think I got about 1 fps out of it. Would a faster drive produce more fps? Maybe you can utilize REUs? Using DMA-access they are blazingly fast.

[Hydrophilic]

Thanks for the report, tokra.  The uIEC implements JiffyDOS protocol and MP128 has JiffyDOS drivers so it should work (no JiffyDOS ROM is required in the C128).

A new driver to support fast-serial hardware is planned, and it should dramatically improve frame rate.

The frame rate is all over the place!  Whenever the camera moves, or zooms in, or there is a lot of action, the frame rate drops to about 1fps.  When the camera is still, and there is moderate action, frame rate is about 2 to 4 fps.  If there isn't much motion at all (camera and actors relatively stll), it goes much higher.  Kind of a waste of disk space... not really, those frames compress about 99%.

I don't have an REU, but I agree, it would help, because the video decoder relies exclusively on Copy and RLE.  Both of which an REU is good at doing.  However it might not help as much as you might think, because most of the copy sequences are short (maybe 4 bytes average).  Setting up the REU registers for such a short job might not pay off...

Oh no, I just thought of another problem: the REU can't do long sequences because the IRQ must constantly play audio samples.  Well, I guess you could limit the REU to say, 30 to 40 bytes...

Anyway, you would still need a way to sync the REU with the IRQ... tricky stuff!

I think in the short term, best way to improve the frame rate is to improve the encoder.  Besides being optimized for grayscale and not color, it only does small vertical motion detection.  Unfortunately, a lot more motion is horizontal!

If you're familiar with VIC-II bitmaps, you probably know why I started with Y-shifts and left X-shifts on the TO-DO list 

Another idea is to use char-set emulated bitmaps.  This can radically reduce the amount of data the CPU needs to process, but puts strict limits on video quality.  Still, this is very promising and something I plan to work on soon.

Oh, tokra, are you using PAL or an NTSC machine?  Anyway, thanks again for your feedback!

[saehn]

Just tried it for the first time, through VICE... really cool! Impressive that you've been able to accomplish so much on a 20+ year old machine, video AND sound! Of course the framerate is slow, but eh. Still neat. What would be the ideal setup that is currently usable? uIEC NTSC/PAL 128? Would 128D or REU make a difference yet, or would those not (yet?) make a difference? Great work :-D

[Hydrophilic]

Thanks for your feedback, saehn!  There is really no optimal setup, as this is still alpha software with no specific optimizations.  Well, a mass-storage device like uIEC or CMD-HD is highly recommended because C1581 has space for only the shortest videos (all the videos I released in .d81 format are cut short).

Anyone with a CMD-HD or C64HDD to report results, I would appreciate it!

Now that I think about it, PAL has a slight speed advantage due to larger border = more 2MHz time.  But the video is (loosly) locked to the audio which is (strongly) locked at approximately 7843 Hz, so there shouldn't be much difference between NTSC and PAL.

The sharp reader may have noticed I said approximately 7843 Hz.  This is the sample frequency used to encode the audio, but the player will actually be off by a few dozen Hz depending on national standards.  It should play at 7819.4 Hz on PAL, or play at 7867.2 Hz on NTSC.

In other words, NTSC would run about 0.6% faster than PAL.  See?  Not much difference.  Another way to think about it is NTSC videos will be 0.3% too fast and PAL videos will be 0.3% too slow.  As an example, a one hour video would be off by about 11 seconds (plus or minus, depending on PAL or NTSC standard).  Note this is just a calculation...  I haven't made any 1 hour videos to verify this value!

[tokra]

Oh, tokra, are you using PAL or an NTSC machine?  Anyway, thanks again for your feedback!

I'm using a PAL-machine. Do you think something like the Media Player could work on the VDC chip as well? I know accessing it through the registers is very cumbersome, but maybe the 2 Mhz-mode would alleviate that.

[Hydrophilic]

Thanks for the feedback!  Nice to hear it works on real PAL.  Video on the VDC would be a neat trick.  With JiffyDOS, you still could not have full 2MHz capability, but you would still have a lot more CPU speed than with VIC.  I don't think that would compensate for the slow VDC RAM access, but it would be interesting to try...

Note that JiffyDOS was just an easy way for me to test the concept.  Well, maybe not easy (look at the source code, it's a nightmare).  Anyway, I'm working on fast serial routines which should help the frame rate a bit...

[gsteemso]

Unfortunately, 2MHz mode â€" while it would aid enormously in unpacking the frames and sorting out the data â€" would not help in transferring that data to the VDC RAM, which AFAIUI operates at circa 1MHz regardless. That's why that one register has a status flag in it to say when the VDC has finished its operations and is ready to have its registers twiddled some more, and why ignoring that bit causes data to go missing.

[airship]

Hydro, I assume you've seen this over on the Lemon forums?

http://www.lemon64.com/forum/viewtopic.php?t=36998&highlight=

[Hydrophilic]

No I haven't.  Thanks for the link.  Man, that guy has got the color down pat!  I don't see how the VIC can do that... gonna have to take a peek...

As I understand it requires a 1541 Ultimate which can transfer data at REU-like speeds... quite a bit more than a 1581, CMD-HD, or uIEC can cope with... on the other hand, wuz up with the audio?  If you got that much bandwidth, why wouldn't you have 4-bit (or 8-bit) audio samples... guess all (well most) of the bandwidth is going to the VIC...

But still don't see how the VIC is doing the color... sprites under bitmap? urrr... this is gonna bug me till I find out.

Edit
Trying to find out more about this software, I search on CSdB for 'nuvieplayer' and #118874, but get "We're terribly sorry" message.  Really strange that links through CSdB can't be found; maybe because it is hosted on sourceforge ?  But still... bad index, very bad, bad index...

Edit 2
The link above takes you to possibly related Java SID player... but searching there turned up nothing about the nuvie player...  is this a case of vaporware ?  I did download the 'player' from lemon, but without any media files (or a 1541U), I dunno how useful it will be...

Edit 3
Returning to CSdB, a search for "video player" also turned up 0 results.  Me thinks their search no worky... I mean there has gotta be a video player of some sort for C64 right?

Sing along if you know the words:

There's someting wrong with the world today
The lightbulb's gettin' dimmed
There's meltdown in the sky

[tokra]

The player as well as demo-files are both linked in the original post on Lemon:

http://noname.c64.org/csdb/release/download.php?id=118874

http://www.megaupload.com/?d=TEEZ58TC

The player is included in the megaupload-archive as well.
Haven't tried this myself yet, but looks pretty impressive...