Topic: Media Player 128 Beta

[Hydrophilic]

Now available for download is the latest version (beta) of Media Player 128.  I've put together 3 different downloads, so you can choose the one that you think is best for your real hardware (they all run in VICE).
 
MP128-D64.ZIP includes 3 1541 disk images.  These will run on 1541 or 1571.  It includes 2-bit and 4-bit audio files only.  8-bit audio and video is just too much for either of these devices.  In fact, you will notice the 1571 will slowly fall behind while playing 4-bit audio, but it should get to the end of file before the audio buffer completely drains.  If you are using a 1541, you will also need an REU to buffer files.  Of course JiffyDOS is highly recommended for the 1541.  You just need/want JiffyDOS in your 1541, it doesn't matter if you have JiffyDOS in your C128 because JLOAD128 is included.
 
MP128-D81.ZIP includes 5 1581 disk images.  These will run on 1581 or SD2IEC device (like the MMC or uIEC).  If your device does not support fast-serial, then you will also need an REU.  This version is also recommended for VICE users who want to try out Media Player 128 -- be sure True Drive Emulation is enabled.  This version includes 2-bit, 4-bit, and 8-bit audio files, and 2 partial videos (a full video will not fit on 1581 disk).
 
MP128-HD.ZIP includes all of the above, but as raw files and subdirectories.  This is for CMD-HD or SD2IEC devices.  Might also work with 64HDD.  If your device does not support fast serial, you will also need an REU to buffer the files.  The 2 videos mentioned above are now full length.  And a third video which requires an REU is also included.  The REU-only video has 2.5x greater frame rate.  Actually, a real REU expanded to 2MB (the max as I understand) will only hold about 80% the high-frame rate video.  In other words you need something like the 1541 Ultimate to see whole thing.  This version also runs in VICE, but in this case you need turn off True Drive Emulation, enable Virtual Device Traps, and also enable REU emulation.
 
Extra downloads include MP128SRC.ZIP, the source code for the player, and mp128util.zip which has some windows command-line utilities for producing 2-bit, 4-bit, and 8-bit audio files, or a video.  If all you want to do is listen to audio, you don't need the utilities because MP128 will play Windows .WAV and Amiga .AIF files automatically.
 
Features
Semi-graphical user interface -- works with keyboard, joystick, and/or mouse
Works in 40 or 80 column mode (videos display only on the 40-column screen)
Works on PAL and NTSC systems*
Plays CIF 2-bit, 4-bit, and 8-bit files (something I just made up)
Plays AIF, DFF, and WAV 8-bit files
Play/create play lists in M3U format
Supports 1581 partitions, CMD-style and VICE-style subdirectories
Pause/resume/abort playback of audio and video files
 
*The videos I've produced push the CPU and fast-serial bus to the limit.  Because an NTSC machine has fewer border rasters, the CPU has fewer 2MHz cycles.  Unfortunately this means that NTSC machine playing from a 1581 will occssionally 'hickup' when the audio buffer drains and wraps around.  However, this is not a problem for an NTSC machine using a faster device, such as uIEC or when playing from the REU.  Of course I (or you) could produce videos with a slightly lower bandwidth that would work on NTSC+1581.  But since I have uIEC and no 1581, I made the videos the way I did.
 
The video encoder has not been improved since the original alpha release (except that videos are now centered and properly clocked).  Which is to say gray-scale images look really good, in my opinion, but color images are hit-and-miss.  This also means the frame rate is still pretty low (1~4 frames per second), and that gray-scale video has a higher frame rate than color.  One of these days I'll find the time to improve the video encoder!
 
The audio formats are all monophonic.  I have not found the time to write stereo codecs.  (Nor have I found the time to install that second SID in my C128).  4-bit stereo seems the best you could do when streaming directly from a fast-serial device.  8-bit stereo may be possible with an REU.
 
The REU code is all new.  Thanks to Tokra for suggesting that.  The REU is really great for videos, but despite it's massive bandwidth, I could only manage 5 frames per second in wide-screen (16:9) format and slightly less than 4 fps in full-screen (4:3) format.  This is because the video is compressed and the CPU is nowhere near as fast as the REU!  Of course there is a possibility to use uncompressed video with the REU, but then it would be much like Nuvie Player.  Which is to say you would need at least an 8MB REU for a single video.
 
The main problem with the new REU code is getting the data into the REU.  In VICE the optimal setup takes a minute or two to load into the REU in real time.  Using real hardware it takes even longer.  For somebody with a 1541-Ultimate, this is really stupid to load data from the Ultimate over the serial bus back into the Ultimate REU emulation.  But until I get one and have time to re-write the REU routines, that's the way it is...  Of course in VICE you can activate warp mode to load the REU with a full video in less than minute, but then you'll probably miss the first few seconds of the video.
 
The other problem with the REU code, is the player will only use the REU if you don't have fast-serial... which is to say you have to load the REU via JiffyDOS, or God forbid, slow serial!  Yet another desgn issue to be fixed...
 
Limitations
- WAVE files must be mono 8-bit, be PCM-encoded, and must have a sample rate between 7.1 and 13 kHz.  Note the fast-serial bus is limited to about 9kHz, so you need an REU for a higher rate.
- AIF files must be mono 8-bit.  It seems AIF files always uses signed 8-bit numbers, although the player supports either signed or unsigned 8-bit.  In any case, the sample rate should be between 7.1 and 11kHz.  This lower limit than WAV files is due to the CPU time needed to convert signed to unsigned samples.
- 99 items per directory
- 99 files per play list
- 9 unique paths
 
Bugs and design issues
- Can not enter a path directly from main screen (must use Config->Media).  This isn't a problem for 1581 or CMD-style subdirectories, but in VICE, subdirectories are not listed(!) so you have to access the Config/Media and type a path whenever you want to go 'down' the directory structure (you can go 'up' by simply clicking the up arrow at the top left of the screen).
- The edit window for PATH is limited to about 64 characters.  Not a problem for most users, but in VICE on windows, the path names can easily be much longer
- When playing 4-bit files from the REU in 40-column mode, the bottom half of the screen fills with garbage
- The mysterious PRINT USING bug may rarely corrupt the screen.  If this happens, you can click on List (which erase the directory shown) and then click on Directory to re-display it.
- If you change the device, you really should go to Config->Media and click OK to re-set the device driver.  For example, if you start media player from 1541 device 8, but then turn off your 1541 and turn on a 1581 also with device 8, the program may lock up when you try to read the directory.  This also applies to configuration changes in VICE.  For example, if you start with True Drive Emulation turned on, but then turn it off, the program may lock up when you try to read a directory.  Or if you switch from a disk image to your native file system.  In all these cases you can avoid any problem if you remember to select Config->Media and click OK... the problem is remembering to do that!
- When you select files from the directory, the ones added to your play list will be highlighted.  But if you change to a different directory and then return to the original directory, your files will not be highlighted (even though they are still in your playlist).  This is by design, as BASIC is too slow to compare all the files in your playlist with all the files in the current directory (n*n problem).
- Speaking of which, the GUI is written in BASIC if you haven't gathered that.  It should be re-written in ML.  It seems fine to me in 80-column mode, but the slugishness of BASIC becomes more appearant in 40-column mode (only 1MHz).  It is still usable, but it is a bit like GEOS without an REU...
- When saving a playlist, you must already be in the correct directory.  That is, you can not edit PATH from the Save screen.  You need to use Directory screen to click on directory names or the up arrow (as appropriate) to navigate to the correct directory first.
 
Using MP 128
If you have the disk version (.D64 or .D81), just put the MP128 disk into your favorite drive.  If it is drive 8, then it will boot automatically on reset/power up.  Otherwise type BOOT Un (where n is your device#).
If you have the HD version, issue CD commands (or their equivalent) to get to the correct directory.  Then enter RUN"MP128INI.BAS",Un (again, n is your device#)
The initialization program will start and print a copyright/version message and begin allocate BASIC arrays.  After a second or so, it will remind you to plug a mouse into port 1 or joystick into port 2 (you can also use the keyboard).
Next it will load JLOAD128 and try to activate the JiffyDOS driver.  If fast-serial is detected, JiffyDOS will be disabled.  If neither is detected, the default KERNAL routines will be used (presumably slow serial, but it may work from cassette... not tested).  In any case, MP128 will print a message telling you what type of protocol it is using.
Next it will load several support files and finally the main GUI.  Once that is loaded the screen will clear and the directory will be read.
 
To add items to your play list, just click the name from the Directory screen.  If you are using the keyboard, use the cursor keys to move the file indicator and press Space to (un)select file(s).  On a 1581, clicking on CBM file types will read in the directory of the partition.  On CMD-compatible devices, clicking on DIR file types will read in the subdirectory.  In VICE subdirectories are not displayed!!  You have to know the full name, select Config->Media, type in the name, and then click OK.
 
By the way, the keys you can press on the keyboard (besides the cursor keys and Spacebar already mentioned) are ususally highlighted in white.  The exceptions are OK and Cancel.  Whenever you see these items, you can press RETURN for OK or press ESC for Cancel.  Just remember that in VICE the real ESC key is not mapped to the C128 ESC... you need to press F1 in VICE...
 
If you click on a filename with an M3U extension, the file is opened and the playlist is read into memory.
 
To view files in your play list, click LIST at the top of the screen.  Click DIRECTORY to return to the filenames in the current directory.  You can re-read the directory at any time (for exampe after a disk change) by clicking DIRECTORY when the directory is already displayed.  If you change disks, be sure to clear your playlist (this needs to be improved).
 
If you are not using VICE, the up arrow at the top left of the screen will be unavailable when you first start MP128 (also in VICE if you happen to be in the root directory).  But once you go 'down' into a subdirectory (or partition) then you can click the up arrow to go back up the directory tree.
 
Once you have selected one or more files, (that is, your play list is not empty), then you can click on PlayFiles and enjoy.  By the way 'INFO' does not do anything, no matter how hard you try!
 
There are lots of other things to try out, but I think that is enough for now!  If you have any issues, please let me know what type of setup you are using... in particular your device type (1581 etc) and your machine type (NTSC or PAL).
 
Edit
I updated the links above for the latest version.  They should now each include a brief ReadMe text file.

[RobertB]

     Oooo, thanks for the Christmas gift!    It might be too late to get it on the agenda for this month's FCUG meeting, but it will definitely be shown at the January meeting.

          Truly,
          Robert Bernardo
          Fresno Commodore User Group
          http://videocam.net.au/fcug

[sledge]

Wow. Thanks. My newly arrived uIEC will like this alot

[airship]

Thanks very much, dude. This has been an amazing project to follow. Now I HAVE to unbury my C128 and put it back together! 

[xand]

Thank you!! This will be really cool...

[Hydrophilic]

Glad you're exicted about this.  Thanks for Digimaster, RobertB.
 
Airship, I don't know why you would disassemble and bury your C128, but just beware of the evil Static Electricity when you re-assemble
 
sledge, you should find that MP128 works with uIEC using the official firmware via JiffyDOS.  However, JiffyDOS is not as fast as fast-serial and so you also need an REU when using JiffyDOS.  If you don't have an REU, then you will probably need the fast-serial firmware available here (as I understand fast-serial is not included in the official uIEC firmware).
 
Sorry if that is confusing!  I attached an image of the boot screen (80 column) from VICE.  Notice under the "Attach Mouse" and "Searching for JLOAD128" there is a line the reads:
 
USING KERNAL; R.E.U. REQUIRED
 
If your device supports JiffyDOS, it should read
 
USING JIFFYDOS; R.E.U. REQUIRED
 
If you see that, you probably want to install the fast-serial update in your uIEC.  If your uIEC already supports fast-serial (or you have another fast-serial device like 1581 or CMD-HD) then it should read
 
USING FAST SERIAL
 
(an R.E.U is not needed).
 
-------------
I forgot to mention in the first post, but when a file is playing, you can press SPACEBAR / FIRE / Left-Click to pause/resume playback.  When a file is playing, you can press 1 / UP / Right-Click to skip to the next file in your playlist.  When a file is playing, you can press STOP / FIRE+UP / Left+Right Click to abort playback.  You can also abort playback while a file is loading (before it starts playing) by pressing STOP.  If loading by slow-serial, you will need to hold down STOP for several seconds because the keyboard is only checked after every 4KB of data (this should not be an issue with JiffyDOS or fast-serial).
 
I also forgot to mention if you are using VICE with a 1581 True Drive Emulation, be sure the emulation is set to PAL.  As explained previously, NTSC+1581 is too slow for the videos I made.  Anyway, I attached 1 frame from each of the videos.  First is 4:3 aspect ratio and second is 16:9.

[RobertB]

Thanks for Digimaster, RobertB.

     Heh, don't thank me yet; I still have to mail you a SUX 6400 cart (which I should be able to do this week, now that another batch has been assembled).

          Just 5 more work days and then vacation!
          Robert Bernardo
          Fresno Commodore User Group
          http://videocam.net.au/fcug

[tokra]

Just gave this a little try. Strangely, the mouse-cursor would slowly move even if the mouse was perfectly still. Didn't happen in VICE just on my real machine. Did not notice this in GEOS before, but anyways...

I have the fast-serial-patch on my uIEC, and using this worked as it should. Audio and video loads fine, however as Hydrophilic notes the frame rate for video is pretty poor. Having only fast serial I cannot fully try the REU-variant though I have a 1541 U2 (which has 16 MB REU). I've connected an older SD2IEC, but I fall asleep before the REU is fully loaded. Would be nice if there was a "Finished loading REU, press key to continue"-option. I tried an 8-bit-audio file and this was played through the REU fine, but once the song finished I got a garbled screen and have to STOP/RESTORE to restart the MP128. I've watched some Nuvie-videos afterwards to make sure the REU worked fine.

A great accomplishment for the C128!

[Hydrophilic]

I really need to buy a mouse and see what the problem is... but will take a peek at the code tonight and see if I can guess what the problem is.  I will look into the crash of 8bit when using REU also.
 

I've connected an older SD2IEC, but I fall asleep before the REU is fully loaded

Yes using JiffyDOS takes a long time to load the special REU 2+ megabyte video (I assume that is the one you mean).  There really should be a configuration option to use fast-serial with the REU... sorry about that, but I ran out of BASIC memory.  Also there should be a better way for 1541-Ultimate.  Like some command you can send over the serial bus (or poke into $df00 registers) to load the REU directly with a file, instead of transfer over serial bus?  How do you load the monster-size Nuvie videos into the Ultimate?
 
Again, sorry you fell asleep because the REU-only version has a much better frame rate.
 
Some good news is the JiffyDOS code for loading the REU is not very effecient, which means it should be possible to increase speed, maybe 2x faster.  That part is in ML as you may have guessed, and there is still room available there.
 

Would be nice if there was a "Finished loading REU, press key to continue"-option.

That's a good idea.  And it should be easy.
 
Oh can I ask one more question (after this one) ?  When you use the older SD2IEC, does it say Using JiffyDOS when you start Media Player?  If not, then it is using slow serial (which will take FOREVER). 
 
If you change the device without restarting, then you should go to Config->Media and click Okay so it can install correct drivers.  For example, if you load from fast-serial device then switch to JiffyDOS without doing this it will try fast serial (and fail) then use KERNAL/slow serial as a back-up.
 
Well, I guess I need to fix it so it always tries every protocol for every time it tries to read the disk (directory or load)... I didn't do this originally because I didn't want to slow things down, but if it is causing trouble then it should be done.  Thanks for the feedback!

[tokra]

There really should be a configuration option to use fast-serial with the REU... sorry about that, but I ran out of BASIC memory

It would be good enough if one could choose JiffyDos-mode instead of FastSerial I guess...

How do you load the monster-size Nuvie videos into the Ultimate?

The Ultimate has an option to load a file into the REU directly. This takes about a minute or so for a 16 MB file. Once the file is loaded, you can start the Nuvie player, which just plays whatever video has been loaded into the REU.

Oh can I ask one more question (after this one) ?  When you use the older SD2IEC, does it say Using JiffyDOS when you start Media Player?  If not, then it is using slow serial (which will take FOREVER).

It said "Using JiffyDOS" and the the screen rotated colors. I left the room for a few minutes not knowing how long it would take, and when I came back it had already "crashed". Using the old SD2IEC is a pain, so I'd rather have the option to still use the JiffyDOS and REU even when the device is fast serial. Ideally fast serial could fill the REU itself. As I see it now using the REU should be more of an option than a requirement for a specific setup. If you could choose in the menu whether or not to make of the REU that would be ideal. Of couse if you need either REU or FastSerial for the player to work at all, maybe it should not even start if neither is found?

[RobertB]

MP128-HD.ZIP includes all of the above, but as raw files and subdirectories.  This is for CMD-HD or SD2IEC devices.  Might also work with 64HDD.

     Do you think it would work with a CMD RAMLink?

          Truly,
          Robert Bernardo
          Fresno Commodore User Group
          http://videocam.net.au/fcug

[RobertB]

...I still have to mail you a SUX 6400 cart (which I should be able to do this week, now that another batch has been assembled).

     The SUX 6400 cart was mailed to you today via Priority Mail.

          Happy audio-digitizing!
          Robert Bernardo
          Fresno Commodore User Group
          http://videocam.net.au/fcug

[Hydrophilic]

Oooh, a Christmas gift!  Thanks, RobertB!
 
Yes, it does require a either Fast Serial or else an REU.  If you don't have fast-serial, it tells you need an REU on boot up.  I'm not going to waste time or bytes on code to stop the user who wants to ignore the message and try anyway.  You are right, it does need a configuration option... but when I said I ran out of BASIC room, I wasn't kidding, there is like 24 bytes unused.
 
I think I can shift the ML up to make room in BASIC to allow configuration for loading preference.  In particular fast-serial + REU.  This of course is preferred for real REU because fast-serial is faster than JiffyDOS.  Yeah, the design is flawed in that respect, as I only originally designed it to use the serial bus and all the REU stuff is new.
 
But, I'm sure it would be better for people with 1541-Ultimate to use it's native method... 16MB in one minute is MUCH better than fast serial!  It would probably take 5+ minutes to load 16MB with fast-serial... fortunately music videos aren't that big, but still waiting for 1 or 2 minutes is no fun.  Can you describe more how you tell the Ultimate to load the REU with a file?  Is there some specific command you send on the serial bus or code to poke into the $df00 region?
 
Yes there is possibility to support RAM Link, or ethernet, or RS-232.  I've worked to make the code as modular as possible.  So the file codec, video codec, and GUI are all independent.  The only problem in developing for a new device is the loader is intimately linked with audio codec.  So to support RAM Link, someone would need to write 3 versions (2bit, 4bit, and 8bit audio).  Actually all three are not required, as the codec can refuse to support formats it doesn't like (for example, it could be 8-bit only).  Although I am not familiar with the details, it seems the RAM Link would not be too difficult to code... just copy the REU code and make changes...  I wouldn't have the time to write that code anytime soon.
 
I looked at the mouse code, and I couldn't find any bugs... it is doing what is was designed to do, which is filter 1-bit noise.  Although I no longer have a mouse, I did, and am aware of the noisy pot reading it gives.  It was my experience (and reported elsewhere) that the mouse has 1-bit noise.  But the mouse problem reported sounds like the noise has gone over 1-bit.  All I can imagine is the SID is reading values like
 
100 -> 101 -> 102 -> 100 -> 101 -> 102 -> 100
 
this gives difference values of
 
1, 1, -2, 1, 1, -2
 
In this case, the 1-bit noise will get filtered (no movement) but the 2bit noise passes through and the mouse wanders to the left.  I tried altering the code to filter 2-bit noise, but it made the mouse rather insensitive... I don't like it.  So the other option is to remove the filter completly.  Then the mouse will be like the GEOS 1531 driver -- it will dance around in one spot even when you're not moving it (except in VICE it would sit quietly because the noise is not emulated).
 
I haven't had a chance to track down that JiffyDOS + REU bug.  Thanks again for the feedback!

[maraud]

I tried this yesterday and it's VERY cool.  Now the question is how I digitize my own stuff?

[tokra]

Can you describe more how you tell the Ultimate to load the REU with a file?  Is there some specific command you send on the serial bus or code to poke into the $df00 region

Well, it's just an option in the 1541 Ulitmate menu. Once you browse through the directory with the cursors keys and press "Return" und a .reu-file, it will ask you if you want to load it into the REU. No idea how it could be done by a program. Maybe you need to ask in the 1541Ultimate forum for that.

I looked at the mouse code, and I couldn't find any bugs...  [...] So the other option is to remove the filter completly.  Then the mouse will be like the GEOS 1531 driver -- it will dance around in one spot even when you're not moving it (except in VICE it would sit quietly because the noise is not emulated).

I checked my mouse with another program just to be sure -  I got a rock-solid mouse-pointer there. With MP128 the mouse cursor moves (in 40 col) or skips (in 80 col) slowy into one direction. I've not noticed the "dance around in one spot" thing you noticed about GEOS either on my machine. Maybe it has to do with PAL/NTSC? I'm using PAL.

[Hydrophilic]

GEOS has 2 mouse drivers.  1351 and 1351a.  The 1351 driver gives "high-resolution" but dances around a point when not touching the mouse (I hope somebody can back me up on that!).  The "a" version (alternate?) is low resolution (the readings from SID pot registers get divided by 2)... this version usually does not jump around at all (at least not when I used it back in the day).  If your SID is reading an error greater than 1 bit, it may dance around a little bit...  Neither will dance around in VICE because there is no emulation of the error.
 
Anyway, the "a" version only moves at half-speed (unless you adjust the speed/acceleration paremeters in control panel).  The mouse driver I wrote can be compiled to act like that as well, but I don't like it... I have to make gross movements across the entire mouse pad in order to move around the full screen.  Call me lazy, but I don't like putting that much effort into the mouse.  I also do not want to make the interface more complicated with a mouse control panel.
 
I assumed the 1-bit filter I implemented would provide the best of both worlds, but it seems to fail if the error goes over 1-bit.  Tokra, could you post or provide a link to the test program you described that works well for you?  Another idea I had was to average two readings, which should act like a filter as well... the only problem with that idea is when the SID pot values wrap around... this could be compensated by making the mouse driver more complex, but unfortunately there is no room to add any code.  Removing the filter as described earlier is easy because it only requires removing code.
 
I wonder if an NTSC machine would have the pointer drift in the opposite direction (right)... or not at all... I guess it could also depend on things like the mouse itself, the type of SID, and the capacitors connected to the SID...  The no-filter method should work with them all.
 
I was afraid the REU loading would be some menu interface instead of a simple command.  A simple command should make it rather easy to patch the player... if it is going to be more complex, that feature would have to wait for the next version. 
 
I should be able to get a fix for REU + fast-serial out before the end of the year.  Also a "Finished loading REU" prompt.  So thanks again for the feedback.
 
I'm glad you like it maraud.  There is no software that runs on a Commodore for creating audio or video, unless you count Digimaster.  It makes 8-bit audio files, but is limited to what will fit in C64 RAM.  Which is to say, much less than 30 seconds of audio!
 
If you are using Windows, and you have an audio file that is already .WAV format, you can use the "Sound Recorder" accessory included with Windows to convert your .WAV file into 8-bit mono 8kHz or 8-bit mono 11kHz (note 11kHz is too fast for fast-serial so you would need an REU).  Of course there is a good chance your audio files are not .WAV format, in which case you would need different software...
 
Linux, Mac, and Windows users can use the free FFMPEG to convert other (for example MP3) audio files (or the audio stream of a video) from almost any format into either .WAV or .AIF 8-bit files.   These 8-bit files can be played directly with MP128.  If for some reason you want to have 4-bit or 2-bit audio files, you would then need to also use the WAVTO4BIT or WAVTO2BIT software included in the "utilities" download.  The utilities only run on Windows, or perhaps on Linux with Wine (not tested).
 
So I would suggest starting by making some 8-bit .WAV or .AIF files.  If these work for you, then you can try making the 2bit or 4bit audio files.
 
If you have a lot of patience, then you can move onto making videos.  This requires first making a 2bit audio file as described above, then running the BMP2VIC2 video encoder with that audio file and a directory full of images for the video.  The images can be Windows .BMP or Linux .PPM files.  The images must be either 8bit gray-scale or 24bit color.  They also must be sized for the VIC screen... for example 160x200 for multi-color or 320x200 for hi-res.  I use FFMPEG to generate the images.  You will get a very low frame rate if you use full screen (Nx200), which is why the videos I made are smaller.
 
That can get you started, but there's a lot more you should know about making videos... all that would be too much for a post and should go in a different thread... I really need to write some documentation for that and include it with the "utilities" download.  I actually have some of it written, but haven't found the time to finish it and include it in the download.  Also the video encoder needs a lot of work for color images, but I haven't found the time to work on that either.  Anyway, I'll try to get the documentation out by year's end.

[RobertB]

There is no software that runs on a Commodore for creating audio or video, unless you count Digimaster.  It makes 8-bit audio files, but is limited to what will fit in C64 RAM.  Which is to say, much less than 30 seconds of audio!

     Digimaster will record about 5 seconds of 8-bit audio.  Now if only it could be modded to run in C128 mode in order to use its larger RAM and/or use a REU in order to use its RAM...

          Hey, I had forgotten about the RAMLink,
          Robert Bernardo
          Fresno Commodore User Group
          http://videocam.net.au/fcug

[maraud]

 I'm going to convert a whole song just for giggles (use my CMD HD instead of 1581).  Now that said, I do have a parallel cable on the HD and am curious to see if it will utilize that if I disable fast serial.  That should allow higher sample rates, no?

[maraud]

well I used ffmpeg to convert a WAV.  Specifically I used the following arguments "-acodec pcm_u8 -ac 1 -ar 11000"  When I take that over to the 128 I get an error that the codec parameters are not supported.  Which was a bummer because let me tell you how SLOW it is copying a 3.1MB file from uIEC to the CMD HD!


edit: well it wasn't a problem with my file, it was the fact that I had my RAMLink enabled (which forces JDos on).  So much for oping to use the parallel.  I presume the driver just "knows" the max bitrate a protocol can support and that's what leads to the error?


Ah well I reconverted a song to 8 bit at 8500, time to see if it'll keep up.   Kinda funny playing a 14,000 block file!  I have finally gotten it to work but I think I need to drop to <8000 on the bitrate to keep the buffer from draining.  Any hints on how to "kill" the SID squeal I hear?  Very high pitched and I've not been able to correct it as of yet.  Do note this is a 128DCR metal unit.  THe good news is after ages of transfer I've listened to my first two complete Dave Matthews Band songs on a C128!!!!

[RobertB]

Which was a bummer because let me tell you how SLOW it is copying a 3.1MB file from uIEC to the CMD HD!

     Though I've never tried copying a 3.1 meg file from a uIEC to an HD, perhaps you should use WCopy+, the improved version of FCopy+.  See http://www.commodore128.org/index.php?topic=3250.0

          If speed is what you need,
          Robert Bernardo
          Fresno Commodore User Group
          http://videocam.net.au/fcug

[Hydrophilic]

If you disable fast serial, the KERNAL/JiffyDOS routines will be used.  JiffyDOS serial is about the same transfer speed as fast-serial, but has a much greater CPU burden so audio can't be played (must buffer in REU).  If you have JiffyDOS in ROM then when it says using KERNAL it may be using parallel cable... this should be faster than fast-serial but I have no way to test it, so it will get buffered through the REU as well.
 
Well, I'm glad you were able to make your audio files.  It is weird to play a file with thousands of blocks on a Commie, huh?
 
The whining noise is due to the method used to playback 8-bit files, but exactly how that gets through the SID chip is still a mystery to me.  If you use a sample rate of 7816 in FFMPEG, then MP128 will choose a rate that is closest to a VIC 2-raster rate for your machine (that is, 7778 Hz PAL or 7846 Hz NTSC).
 
At this rate I do not hear any squeel in the sound on my NTSC machine.  In VICE 2.1 (using reSID engine) there is a very faint squeel, but at least the audio can be heard when I turn up the sound.  In VICE 2.3 (using reSID again) the sound is almost inaudible even when I turn up the volume to maximum, not suprisingly there is no squeel heard due the low volume output.
 
If I play a .WAV file at the Windows 'standard' frequency of 8000 then I usually do not hear any squeel on my NTSC machine, except very faintly during moments of silence.  For all 8-bit audio, the sound is going through the SID low pass filter.  So I would think that as the sample rate increases, the squeel would get filtered more and more, but that is not what happens!
 
As the frequency increases above 8000 Hz, the squeel gets worse until around 9000 Hz then it starts fading with higher frequencies.  At 10 kHz I can still hear some squeel, but it is completly gone by 11 kHz (or higher).
 
It sounds like you used the correct parameters with FFMPEG for 11kHz, so I'm not sure why you got the error.  There is an 11 kHz audio clip included in the HD download that does play... hmm...  Oh, you say RAMLink enabled forces JiffyDOS on and you think that caused the error?  Well I never had a RAMLink or parallel cable to test with, so if you say so...  it sounds like one of those was causing corrupt data to be read, causing 'codec parameters not supported'.
 
MP128 only knows the fastest that the IRQ loader can run with a protocol (fast serial, JiffyDOS, etc), but has no idea how fast your device can actually deliver data.  I didn't have a CMD-HD to test with, so I'm glad to hear it actually works.  Also I am suprised that the audio buffer drains while playing at only 8500 Hz, as the 1581 seems to be able to handle almost 9000 Hz.  Of course that was with testing in VICE as I don't own a 1581 either. 
 
Have you tried playing any of the videos?  If the CMD-HD is slower than a 1581 then the videos may have problems (video pause and audio buffer wrap).
 
You can try adjusting the filter cut-off value in the Config->SID settings.  This may help a little with the squeel if you fine-tune it.  But if you set the value so low as to kill the squeel completely you also kill most of the high frequencies in the audio you want to hear!  In other words, try to avoid sample frequencies between 8500 Hz and 10 kHz to prevent the squeel to start with because SID just can't seem to filter it well.
 
So to wrap up, it sounds like 8000 Hz should work well on CMD-HD, and if your machine is like mine, you should hear very little if any squeel at 8kHz.  On my machine, both 8kHz and 11kHz sound good, but I can't play 11kHz with a uIEC so I use 8000 or 7816.  I can't say that 7816 is better or worse than 8000, but 7816 will result in a 'resonance' with the VIC chip (even though the screen is blanked) for both NTSC and PAL machines.
 
Also, there seems to be no substantial improvement of 11k over 8k.  Maybe a little better, but I wonder if that isn't a psychological effect... I haven't conducted a double-blind trial   However there is huge difference in file size, so that is another reason I prefer 8k Hz.
 
I believe the 128DCR used the 8581 SID chips exclusively and the flat 128s used the 6581 exclusively while the 128D (no -CR) may have used the 6581 as well.  Assuming that is true, it seems like MP128 is working with both 6581 (mine) and 8581 (yours), but as to the sound quality... well that seems open for discussion.  Anyway, thanks for the feedback!
 
Edit
I just got the 'codec not supported' error with an 11k .WAV file in VICE because I did not have REU emulation turned on.  It should say something like 'REU required'.  Ooops, I need to fix that.

[tokra]

Tokra, could you post or provide a link to the test program you described that works well for you?

I just searched a bit and found this nice mouse-driver for the 80-column mode in the german magazine 64er issue July, 1988 - see attachment.

Start by

Code: [Select]

BLOAD"sprite80.m"
BLOAD"maus.m"
SYS 4864
SYS 4867
Then you can move the mouse freely. Once you press a button you can get the coordinates with X=USR(1) and Y=USR(2). You can set the cursor with adresses $1170/$1171 for x and $1172 for y, before starting with SYS 4867. A sprite-editor and the source is included in the .D64 - I get no jumping cursor with this driver as well, and I also tried another painting program called "Paint R.O.I.A.L".

[maraud]

well I'm happy to say that the 7816 setting for the bitrate definitely stays within the parameters of what FAST SERIAL can do.  With regards to the RAMLink/CMD HD it does indeed say the transfer method is KERNAL when the RAMLink is enabled.  Is it possible to make a build of this which does not check the xfer type so that it doesn't assume a kernel mode xfer cannot support the bitrate of the selected file?


With regards to the high pitch noise, the 7816 didn't help and in fact made things worse.  It's louder and higher pitched.  You are correct that the 128D I have uses an 8580 SID.  I'll try this on one of my flat 128's to see if the 6581 fares any better.  Good news is that squeal aside, I've gotten 16MB worth of WAV files transferred to my CMD HD and it works flawlessly in fast-serial mode!

[Hydrophilic]

Thanks for taking the time to post that.  Looking at the IRQ code, it is much like the 1351a driver in GEOS in that is uses low resolution of the mouse readings (SID pot / 2).  An interesting feature is the old reading is not updated when the new reading is +/- 1 of the old reading.
 

old	new	diff	update old
100	100	0	100
100	99	-1	100
100	101	+1	100
100	98	-2	98
100	102	+2	102

It should be noted this +/- 1 test is effectively done before the division by 2.  Otherwise it would be +/- 2 filter!  I tried +/- 2 filter and didn't like it, it felt 'sticky'.  I also don't like dividing the SID pot by 2 as this makes the mouse move slow (1/2 speed).
 
What I don't understand is that because this is using +/- 1 filter, and my code is using +/- 1 filter, why the mouse will drift in MP128 but not with this code... I can only guess it has to do with not updating the last reading because my code always updates the last reading.  Hmm, I wonder how difficult that will be to change (conceptually easy, but memory constraint is tight).
 
If anyone is interested, here is the memory use of MP128:
Bank 0:
$0000~$03ff - System (KERNAL / BASIC)
$0400~$07ff - VIC-II text
$0800~$097f - FileHelp ML (read/write BASIC string to file with options)
$0980~$09ff - BASIC stack
$0a00~$0aff - More KERNAL use
$0b00~$0bff - Reserved as buffer for drivers (currently unused)
$0c00~$0d7f - Arrow80 (80-column pointer)
$0d80~$0dff - Hit Test (find,add,delete click regeion)
$e00~$0e3f - Sprite for VIC-II
$e40~$0fff - Mouse/joystick driver (with keyboard filter)
$1000~$10ff - Click region data
$1100~$12ff - More BASIC use
$1300~$1bff - Reserved for device drivers (JLOAD128 uses $1680~$1bff)
$1c00~$5fff - BASIC GUI (currently $1c00~$5fe8)
$6000~$cfff - MP128 ML (currently $6000~$a1xx)
$d000~$dfff - Reserved for saving VIC-II colors or some BASIC variables
$e000~$efff - Audio buffer for videos
$f000~$f2ff - Temporary buffers for demuxer (actually $f100~$f2ff now free, see below)
$f300~$f4ff - Run-time for file codec
$f500~$f8ff - Run-time for 'video' codec (this is the buffer graph for audio-only files)
$f900~$fdff - Run-time for audio codec/loader
$fe00~$feff - Demuxer
$ff00~$ff04 - MMU
$ff05~$ff45 - System INT routines
$ff46~$ff4f - Free!
$ff50~$ffc0 ? Run-time variables, many for demuxer
$ffc1~$fff9 ? Free!
$fffa ~ $ffff - CPU vectors
 
Bank 1:
$0000~$01ff - unused (MMU maps pages 0/1 from bank 0 here)
$0200~$bfff - raw video (uncompressed) buffers
$0200~$0fff - audio-only unused (VIC-II text screen 'appears' $0400~$07ff when using REU)
$1000~$7fff - audio-only buffer
$8000~$bfff - audio-only unused
$c000~$ccff - unused (posible video use if text-mode, but not bitmap)
$cd00~$ceff - compressed video buffers (was bank 0, $f100~$f2ff but moved for REU)
$cf00~$cfff - unused
$d000~$feff - BASIC variables
$ff00~$ffff - System use (MMU, INT code, secure string, CPU vectors)
 
You should see the bank 0 low RAM is pretty well used up, except for $b00 page and few pages starting at $1300.  The MP128 ML code can be moved up a little from $6000, but the first few thousand bytes needs to start below $8000 as that part makes direct calls into the BASIC High ROM (that is, not using cumbersome JSRFAR).
 
----------
maraud, I'm glad to hear the CMD-HD can at least do 7816 (and probably 8000), but still suprised that it seems slower than 1581.  The CPU in the 1581 (and 1571) runs at 2MHz, does anyone know what speed the CPU in the CMD-HD runs at?  It seems that may be a bottleneck, as it is hard to believe that a hard-drive would have slower seek/read times than a floppy.
 
I'm also suprised to hear that squeel got worse.  Not only louder, but higher pitch?!  Louder I can possibly understand (less filtering) but higher pitch -- that's a neat trick!  And if it is a higher pitch, it should get filtered more because of the low-pass filter.  So it seems there are some differences between the two chips using 8-bit audio...
 
But I wonder if it might be due to 'aliasing'.  This occurs when the audio includes frequencies greater than 1/2 the sample rate.  This relates to the Nyquest (sp?) frequency criteria.  Without going into details, it basically means you need a sample rate 2x greater than the highest frequency used.  So if the sample rate is 8kHz, any frequencies > 4kHz in the audio can be 'distored' so that they sound like another (higher) frequency.  I've always assumed (and never tested) that programs like Sound Recorder and FFMPEG will filter out higher frequencies when you convert a file to a lower sample rate.  That assumption is based on the fact that I can take a file at, say, 44kHz sample rate and convert it to 8kHz or 11kHz and do not hear any distortion.
 
Which leads me to believe the issue is with the SID model and/or the filter capacitors (that is, assuming that aliasing is not the problem).  Because for me, going from 8000 -> 8500 makes the noise worse but for you the opposite is true...
 
Did you try changing the cut-off frequency in Config->SID ?  Did it help any?  The SID filter works off capacitors so even if you have the same model SID, two machines can sound different if they have different size capacitors.  I'm not sure about the C128, but I've read that CBM used several different sizes of capacitors in their various production runs of the C64.
 
Another thing you might try is to change the Resonance to 0 on the Config->SID screen.  I set it to 4 to help a little with the crummy 2-bit audio, and I left it like that for 8-bit audio because it didn't cause any problems for me.  But maybe it will help.  Let me know if it does, and I can make 0 resonance the default for 8-bit.
 
I plan to shift the ML code up a bit to make some room for the BASIC GUI and add an option to Config->Media so you can specify a maximum transfer for your device before REU buffering is required.  That would help with people using fast-serial + REU, but would not help with using KERNAL or JiffyDOS, as these would still require an REU.  This is because the CPU is too slow (even at 2MHz) to play audio samples and make calls to a loader (KERNAL or JiffyDOS) during an IRQ routine...
 
Another way to say that is ROMs must be disabled when playing audio because this allows fast interrupt code:

Code: [Select]

JMP ($FFFE)
PHA
... irq code here
PLA
RTIBut if you enable ROMs, this becomes (you probably need to scroll to see it all)

Code: [Select]

JMP ($FFFE)
PHA
TXA
PHA
TYA
PHA
LDA $FF00
PHA
TSX
LDA $105,X
AND #$10
BEQ irq
JMP ($316)
irq:
JMP ($314)
... irq code here
PLA
STA $FF00
PLA
TAY
PLA
TAX
PLA
RTI
Hopefully you can see that when KERNAL is enabled, the poor CPU spends way too much time to service an IRQ... it may have enough time to play an audio sample, but it won't have enough time to play a sample and JSR to a KERNAL routine.  Hence an REU is required to buffer the file.
 
That being said, somebody could write a driver specifically for the parallel cable (that is, code to read the data without invoking ROMs).  That somebody won't be me as I don't have any device with a parallel cable to test.
 
As always, thanks for the feedback guys!

[RobertB]

The CPU in the 1581 (and 1571) runs at 2MHz, does anyone know what speed the CPU in the CMD-HD runs at?  It seems that may be a bottleneck, as it is hard to believe that a hard-drive would have slower seek/read times than a floppy.

     No, I don't know the CPU speed of a CMD HD.  However, that would be an experiment... to load off a FD-4000 floppy drive whose CPU runs at 4 MHz.  Now I just have to find the time to do it.

          Vacation mode on, Christmas mode on,
          Robert Bernardo
          Fresno Commodore User Group
          http://videocam.net.au/fcug