Landover BBS - Commodore 128 & PET - since 1987

In case you haven't heard, Juggler 128 is a CP/M program that allows your Commodore 128 to read many "foreign" disk formats using a 1571 or 1581 disk drive.  "Foreign" means an MFM format disk from another CP/M system.  (As an interesting hidden feature, you can format IBM/MS-DOS PC disks, but CP/M can not use them).  A discussion about using it, and some links to the software are in this old post.
 
I've used this program on a few occassions, and it seems so useful that surely others have too.  In doing research for a BIOS modification to support CMD disks, I decided to have another look at it to be sure the updated CP/M would be compatible.  It seems the modification I have planned will actually improve this software.  This is because I discovered a few bugs in Juggler 128, and the planned BIOS modifications should fix (most) them.
 
Herne Data Systems lists copyrights of 1988 and 1996 (as I recall) and since then (200x) they have released this utility as freeware.  Although this powerful software, that allows access to well over 100 formats, was bound to have some bugs initially, you would think that 8 years later (1996-1988) the bugs would have been discovered and fixed.  The documentation notes several formats that may have "issues" (due to hardware constraints) but what I'm talking about are genuine bugs (software blunders).
 
I was (am) concerned about the increased size of the allocation vectors and the directory checksum for the larger CMD disks, so I decided to see if this was a problem that Juggler 128 had to cope with, and if so, how it did it.
 
Bug 1: ALV
 
CP/M maintains a table that DRI calls "allocation vectors" or ALV.  This is essentially an inverted BAM.  The BAM on (native) Commodore disks holds a 1 bit for every sector that is available... while CP/M's ALV holds a 1 bit for every allocation unit (cluster) that is used (not available).  Besides bit-flipping, the main difference is that native CBM disks hold their used/free map data in a dedicated system area (just before the directory), while CP/M dynamically builds its ALV in RAM by scanning the directory.  The ALV is a fixed size in bank 0 RAM.  I haven't checked older versions, but the "final" May '87 release of CP/M allocates 100 bytes to the ALV of each physical drive (that is A~E, but M is different).  (Presumably older versions would have fewer bytes.)
 
This ALV can accomodate 400 clusters.  So first I checked if any Juggler 128 formats have more than that.  Yes!  There is the "Librarian 1581" and "Maxi 1581" formats.  I tried these to see how the software increases the table size.  It does not!  This means using one of these formats will corrupt the following data in RAM... usually the directory checksum (discussed below) for the next drive.  So imagine you have 2 drives.  Drive B is a normal disk format, but drive A is using "Maxi 1581".  This will cause 2 bugs: the ALV of drive A will over-write the directory checksum of drive B (this makes drive B slower because it must re-read the directory more often), and worse, an access to drive B (which updates its directory checksum) will over-write the ending ALV of drive A, which can result in false "disk full" errors if you are lucky, or destroy/cross-link files in the worse case.
 
Bug 2: CSV
 
Although Commodore disk drives can easily detect a disk change (by monitoring the optical "write protect" sensor), it seems that CP/M was designed in case a system could not detect a disk change in hardware.  Specifically, it creates a sort of checksum or hash of each "record" in the directory (a CP/M record is just 128 bytes of data on disk... the original sector size of 8 inch disks).  DRI refers to this as the "checksum vector" or CSV.  In the "final" CP/M release of the C128, the CSV of all physical drives (A~E) is 32 bytes (presumably the same in older versions).  The RAM Drive (REU / drive M:) does not use a CSV because you can't (or at least shouldn't) swap REU's while the C128 is powered on.
 
So second I checked if any Juggler 128 formats have more than 32 checked records.  Yes!  There are several, including "Librarian 1571," "Morrow MD3," and "Zeneith Z-100" formats.  I tried these to see how the software increases the table size.  It does not!  This means using one of these formats will corrupt the following data in RAM... usually the ALV (discussed above) of the same drive.  So imagine you have 1 drive using "Librarian 1571".  Whenever CP/M updates the directory (for example, file write), it updates the CSV.  If the directory has a lot of files, this update will be at the end of CSV which over-flows into the ALV.  This will cause a bug in the ALV of the same drive.  This can result in false "disk full" errors if you are lucky, or destroy/cross-link files in the worse case.
 
Bug 3: EXM ?
 
CP/M was originally designed to address 16KB per directory entry ("dirent").  Note CP/M files can have multiple directory entries for the same file.  Each directory entry was originally referred to as an "extent."  Starting with CP/M 2 (I believe) the possibility to use larger cluster sizes meant each dirent could (depending on disk format) refer to more than 16KB.  So the DPB of CP/M 2+ (which of course includes our beloved C128) includes a field that DRI calls EXM.  This relates to the number of 16KB "extents" that can be referenced in a single "dirent".
 
For example, a 1541 (or 1571 single-sided) standard CP/M format has an extent mask (EXM) of 0 because each dirent can only reference 16KB.  A double-sided 1571 standard CP/M format has an EXM of 1 because a single dirent can refernce 32KB of data.  A final example is a 1581 standard CP/M format which has an EXM of 0 because one dirent can only refer to 16KB of data (note a 1581 has fewer clusters per dirent because a 1581 has MANY more clusters than a 1571).
 
Sorry if those examples confused you... the EXM has been troublesome to me too (see other posts I made regarding CP/M updates for CMD drives where I wrote "?" or "99% sure").  The point is, after reviewing DRI documentation, the BIOS source code, and using a debugger with CP/M, it now seems pretty clear that the "extent mask" must be 0 if a single dirent refers to 16KB, or 1 if it refers to 32KB (and I believe 3 if 64KB, 7 if 128KB, or 15 if 256KB... remains to be seen).
 
Assuming this 0/1 corresponds to 16/32 KB per dirent, there are many formats of Juggler 128 that break this rule.  I don't have any of those "foreign" disk formats to test this theory so I can't prove that it is wrong.  Assuming that Juggler 128 is wrong in this regard, it may be because the bug would never be discovered unless a file was greater than 32KB.  I don't know about you folks, but the vast majority of my CP/M files are under 16KB, and I don't think I have any that are larger than 32KB.  (BTW, CP/M files can in theory be 32MB, but to be "practical" 16MB is the limit).
 
Conclusion
 
So there are at least 2, likely 3, different types of bugs present in Juggler 128.  The modified BIOS that I've planed will increase the size of both ALV and CSV of all drives (both physical and REU).  This increased size should prevent the first two bugs listed above from ever occuring (an improvement in my opinion).  However, assuming Bug 3 is real, the planned update can not magically fix it.
 
Just letting everyone know now so I don't get messages about how I broke Juggler 128

This topic has been moved to Herdware.

http://www.commodore128.org/index.php?topic=4549.0

I made some videos that work fine on uIEC which transmit data ~56 microseconds.  The 1571/81 transmit data in ~64 microseconds.  Now the 1571 is too slow (and does not hold enough data), but the 1581 might could work.  I don't own 1581 to test, but the video plays in older versions of VICE.  Newer versions of VICE the videos play, but they skip horribly... I think because VICE now emulates track head delay.
 
I do not own FD-2000 nor FD-4000, but I made disk image to try in VICE.  Well the videos do not play at all!  It will randomly report BAD CODEC PARAMETERS, or FILE DATA ERROR, or just stop playing after 0.5 seconds.  I think this is because VICE is sending data faster than 43 microseconds (VIC-II bad line period).
 
As far as I can tell, VICE sends data 24 microseconds after it is requested.  I don't have FD drive to examine, but assuming it uses CIA 6526 clocked at 2MHz, then the fastest it could possibly send is 24 microseconds... in theory!  For this to happen, the CPU in the FD would have to cram data into the CIA on the exact microsecond that the C128 requests it.  I haven't examined the ROM of the FD units, but if it is anything like the JiffyDOS or 1581 ROMs, there is a huge delay between when C128 requests data and when the drive actually gives it to the CIA.  Something like 32 microseconds.
 
So the drive ROM/CPU delay + CIA transmit time should be > 50 microseconds.  Because that is much longer than VIC bad line, it should work on real hardware.  Of course playback may skip because of delays reading the physical sectors, but it should at least play.
 
There is an option in VICE, "virtual device traps" which eliminates delay of ROM/CPU code and gives only the physical transfer delay (24 microseconds).  But with this option off, it should include the full delay (50+ microseconds).  However, no matter what options I try, VICE always seems to send at 24 microseconds.  This just seems unreal to me.
 
Does anyone have FD-2000 they can test this video?
 
I've attached FD-2000 disk image (zipped D2M).  I can also post 1581 disk image.  I get an error trying to post FD-4000 image (even though it is less than 4096KB).
 
Just copy the disk image to a real floppy and RUN"*".  It should load Media Player 128 files, and then show directory.  Select one or both videos from the list (the two huge files) and then select PLAY FILES.  The video should at least play (although it may "skip" during playback).
 
If you can test this on real hardware and report back, it would be very much appreciated.  Please report type of disk drive and your system is PAL or NTSC, and naturally if plays or gives an error message.  If it does play on real hardware, we can let the VICE team know and maybe they can fix the bug in next release.

It just recently came to my attention that although most (all?) the CBM-II series display BASIC v4.0 on startup, the BASIC is actually v4.7 and has several differences from the real v4.0 of the PET series.  Thanks to wte and Steve Gray for bringing this to my attention (in this thread).
 
I am in the process of updating the BASIC wiki, but I am not very familiar with the CBM-II series, aside from reading some articles and experiments with VICE.  So feel free to correct me by posting here or updating the wiki.
 
So far, it seems the main difference is the addition of error-trapping, BLOAD, BSAVE and BANK commands which are more well-known on the Plus/4 and C128.  It also features the unique DISPOSE command.  As you might expect with a newer version, it has some bug fixes too, in particular the READ/DATA bug has been fixed.
 
So how do you know if you really have v4.0 as opposed to v4.7?  Well a simple way is, in direct mode, issue the command:
TRAP 10
On reall v4.0 you will get SYNTAX error, but on v4.7 you will get ILLEGAL DIRECT error.
 
Standing on my soap box, I must say that programming can be a challenge for beginners, and having the machine actually lie to the user (at the very beginning, to boot) just makes things worse.  Somebody should write CBM and demand an immediate release of a revised ROM.  Filing a lawsuit for psychological and emotional distress would also be appropriate. 

I've completed all the pages that describe Commodore BASIC from version 1.0 up to 7.0 on the wiki.  Although I did not create individual pages for the new v10 commands of the prototype C65, I did at least list them on the main page.
 
These pages describe all the commands, functions, keywords, operators, prepositions, reserved variables, statements, and tokens of the BASIC language used by the 8-bit Commodore machines (up to version 7).  The pages contain numerous cross-references for easy use and a few additional 'concept' pages.
 
They contain numerous details that are often missing (or wrong) in standard references such as The Commodore 128 Programmer's Reference Guide.  Being a wiki, the information is much easier to access (in my opinion) and perhaps more important, can be updated at any time.
 
I created the pages based on prior experience (with C128, C16, C64, Plus/4, and VIC-20 all NTSC), testing in VICE, and references such as the mentioned C128 PRG, The Commodore 64 Programmer's Reference Guide, the Plus/4 System Guide, the VIC-20 System Guide, and others.  The information should be fairly accurate, but being human, some errors or opinions may have snuck in.  Feel free to update any of the pages to correct errors, remove bias, or add new information.
 
I hope this will inspire some new software for the Commodore 128, or at least any of the Commodore 8-bit machines.  I would also like to thank Lance for hosting the wiki and commodore128.org.
 
Over 160 pages of techno babble for your infotainment.  Enjoy!
 

This topic has been moved to VICE.

http://www.commodore128.org/index.php?topic=4193.0

I've got a C128 conversion of Digimaster ready.  The original I based this on (for the C64) is V1.1j (and 1.1m) by Chris Brenner (c) 1993-1994.  It is my understanding he has since released this to the public domain (otherwise I will feel silly putting this here).
 
The C128 is (C)2012 by me.  You can call it shareware if you send some money to my PayPal account
 
It is a fairly straight conversion of the C64 code.  The main differences being internal relocation of code and data for the C128.  As such it runs only in 40 column mode.  For the faster-than-two-raster audio speed (when the screen is blanked) the CPU does use 2MHz.  This does not seem to affect sound quality from my testing.  It was required for the highest speed recording to enable bank-switching to access (virtually) all of bank 1 RAM, especially in the case of PAL systems.
 
That said, I've only tested it on my NTSC machine and only with a joystick (I have no mouse nor PAL system).  It runs fine in all configurations of VICE, but I can not test sampling in VICE (only playback).
 
Unlike the original Digimaster which had a seperate SETUP program (to configure for NTSC/PAL or Joystick/Mouse), this C128 version is all-in-one.  Just RUN"DM128.BAS" (or you can let it auto-boot).  Select Joystick or Mouse from the BASIC start-up and it will auto-detect NTSC or PAL.  This will run the capture/editor.
 
The attached disk image also includes the orignal PlayIt code for both C64 and C128, as well as the same sample clips.
 
As briefly mentioned above, the big change (err, BIG change) is now you have over 64,000 bytes available to capture/edit audio.  See the attached screen shot.
 
Of course there are a lot of things that could be done to make it even better.  An 80-column version or using an REU being the most obvious.  Anyway, this version is really fast compared to the C64 without JiffyDOS, thanks to the fast-serial bus of the C128.  For example, loading a 64,000 byte file takes less than 10 seconds with a 1581 or uIEC.  Unfortunately saving is not as impressive.  The same size file takes about 60 seconds... but still much faster than standard C64 serial bus.
 
One weird thing is when you select "Loop Playback" you have to press UP on the joystick instead of FIRE (or right-click instead of left-click when using a mouse) in order to stop playback.  That's the way the original is.  There are a lot of things that could be improved with the original code, but I just wanted to get a working C128 version out.
 
However, for anyone who would like to improve it, I've also include my NOTES file.  Which lists just about every routine and data structure from the original version, along with some notes about changes for C128.  It also has a fairly complete memory map of the C128 version.
 
Enjoy!
 
Oh, I almost forgot!  You want to create a work disk, or else copy the files to a larger disk because there is only 213 blocks free on the included D64, and saving a max-sized file requires 251 blocks.

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.

Here is a bug that is very difficult to replicate.  For a quite a while I thought this was caused by the well-known CHAR bug, or perhaps my VDC mouse code.  But when the problem occurred in 40-column mode also, I knew it wasn't CHAR or the VDC mouse code.
 
It *seems* that if you are using a 'dynamic string' as a parameter to PRINT USING and garbage collection is called during PRINT USING that the format string is trashed, and thus the printed string is also garbage.
 
By 'dynamic string', I mean one that is built from an expression and not simply a variable name.  For example, CHR$(34)+M$+CHR$(34).
 
Because nearly 64K is normally available for variables, the chances that garbage collection will occur in a PRINT USING statement is usually low.  But if you reduce the variable storage area for other uses (like audio / video buffers), then the chance increases greatly.  However, even in such a case, and assuming you do a lot of PRINT USING commands, the chance is still quite low.
 
In fact I've spent 5~10 minutes now tring to reproduce the bug with no success... so I could be wrong, but PRINT USING seems to be the problem.  Searching for bugs with PRINT USING, I didn't find anything on this site, but Google found this page which relates to B-series of Commodores.  Those machines have more than a few similarities to the C128, so maybe it is the same bug??  It is hard to say because the page doesn't describe the PRINT USING bug itself, only that Commodore was aware that a bug existed and a revised ROM to fix the problem was produced but was never released.
 
Anyway, here is some example code, that if you run it long enough, have enough patience, and a have a lot of luck, should demonstrate the bug:
 
10 f$="##### ################ #####"
20 n=128:m$="filename":t$="prg"
30 do
40 print using f$; n, chr$(34)+m$+chr$(34), t$
50 loop
This just prints
128   "filename"     prg
forever, or until the bug strikes which then shows a bunch of garbage and keeps running...  If would crash when the bug occurrs, I could just run that demo until it crashed to have something to show you...
 
The only thing I can think to avoid the bug would be to assign the 'dynamic string' to a real string before invoking PRINT USING.  For example, replace line 40 above with this line
40 b$=chr$(34)+m$+chr$(34):print using f$; n, b$, t$
There is no gaurantee it will fix the problem, but it will slow down the program directly (more code) and indirectly (more frequent garbage collection).  So thought I would ask for any opinions or experience with this bug... thanks!
 
Edit
I finally got a screen shot of this bug.  I've attached two images, the good and the buggy.  As you can see in the bug view, the file size and file type are correct, but the filename (a dynamic string) is totally messed up! 
 
So now I've updated my BASIC code with the suggestion I mentioned above, but it is still too early to know if this fixes the problem because it is so rare...

Here's a tiny demo of the text-mode mouse/joystick arrow for the VDC.  It runs in 40 or 80 columns, but obviously we're concerned with 80 columns here.  I attached a screen shot from VICE and the two files needed for the demo.  Copy both those to a directory for VICE or onto a disk for a real C128 and simply
 
RUN"DEMO.BAS'
 
which will load the mouse/joystick driver and VDC arrow code (GUI.BIN) into $c00~$fff
 
The demo doesn't really do anything except list directory or print stupid messages when you click on something (I hope that keeps airship happy).  It is just a skeleton for developement / demonstration.
 
Notes:
 

• Only Sprite 1 (the arrow) is available to BASIC because the memory for other sprites is used by the mouse/joystick driver
• For speed, the KERNAL screen read/write functions are not redirected, so the programmer has to call arrow hide ($c0c) before using PRINT or INPUT.  Then arrow show ($c09) to restore it when done
• The mouse/joystick driver is enabled by calling mouse init ($e40) and un-installed by calling mouse uninstall ($e43)
• The VDC arrow driver is enabled by calling arrow init ($c00) and un-installed by calling arrow uninstall ($c03)
• Also included in GUI.BIN are hit-test (click area) functions.  The area information is stored at the end of the F-Key data region ($1080~10ff).  Because each click-area uses 6 bytes, you are limited to 21 clickable things
• The bytes defining the shape of the VDC arrow at $c1a~$c21.  This is just a character definition, but the bytes are stored backwards (some things are easier in ML if done backwards)
• The character replaced is screen code $e0, which is the Reverse-Shift-Space character in the upper/graphic PETSCII set.  I think that is fairly unused.  Anyway the original character definition is saved during install and restored during un-install

If anyone is interested I can explain more or provide source for the ML code.  But right now I'm using it to write a GUI for MP128.  That way I can sit on my couch and click on files for my play list instead of sitting on the floor and typing in filenames.
 

The C128 (and other Commodore systems) are a bit schizophrenic, in that they suuport either PAL or NTSC but not both.  I've also read there are several sub-standards involved as well.
 
I only have direct experience with NTSC; so for example, there is NTSC-M and NTSC-J... the "J" version is for Japan and is almost identical to "standard" NTSC (North America) except for the H-Sync / H-Blank voltage levels.  As I understand, the Japanese version gives the same voltage to "normal" black and also to "sync" black (in North America, the "sync" voltage is a bit lower than normal black).
 
As for PAL/SECAM, it seems there are even more variations.  From what I have gathered, there at least 3 versions of PAL supported by different VIC chips used in various Commodores.  For the C128, it seems there is only 1 (maybe 2) flavors of PAL supported.  I think the most common is PAL-B.  I'm a bit ignorant when it comes to VIC-IIe (C128 version VIC) PAL chips, so I could be wrong...
 
Never the less, standards have been published for the various color schemes.  To my suprise, when I google on the topic, I get many many web pages with no images what so ever!!!  I mean really... how can you adequately describe a color space without some reference images ?  Fû¢king idiots in my opinion...
 
Anyway, here are a some links that I think are useful:
 
YIQ Color Space (wikipedia)
YUV Color Space (wikipedia)
VIC-II Color Analysis (unknown author / PAL specific)
Musings on Color (Rebecca Bettencourt)
 
Of course YUV (PAL) and YIQ (NTSC) are analog technoligies.  More recently, with digital technology, we have things like YCbCr (very similar to PAL).  Also from a physiological / theoretical perspecitve we have "ideal" color spaces such as LUV.  That, by itself, makes some sense to me...
 
But there are even more color spaces!  For a quick over view of most of them, I recommend a view of Color Spaces (unknown author).
 
As if that were not enough to blow your mind (you did look at all those pages, right?), you need to also consider this:
 
All of the above references ASSUME the human retina has 3 color "cones" which perceive RED, GREEN, and BLUE.  I believe this is due to many decades of biased color research.  It seems most research into color vision had a majority of participants who were male.  This bias was not considered important as it was ASSUMED that men and women have identical visual perception.
 
However, it seems that a minority of wormen, around 10% as I understand, actually have a 4th "cone" in the retina of the eye.  This extra receptor is most responsive to "gold" as I like to call it... somewhere between red and green, but not quite yellow... more of a orange-yellow...
 
Anyway, you guys should take note!  The next time your wife nit-picks about the color of carpet/walls/clothes/shoes/etc... you should consider that she may have superior color perception!!!
 
Getting back to the C128, there are a few color spaces that I considered when developing Media Player 128.  Ultimately I decided to use my own.  That is because I can't follow standards or because my standards are higher than everyone else 
 
I did all the color-space tranformations in my head, but I made some images to help people understand what I'm thinking... please note I'm NOT saying my thinking is right, but here it is for your consideration...
 
YIQ Color Space (NTSC)
YUV Color Space (PAL)
Hopefully you noticed these are nearly the same, except for a rotation of the corrdinate system.
 
Now for Hydro's Color Space (Version 1)... very similar to YIQ/YUV except it is rotated so that Up / North equals 0 degrees.  Colors proceede clockwise from the North (12 o'clock) position.  So RED is 0 degrees (straight up / 12 o'clock), and GREEN is 120 degrees (mostly right / 4 o'clock), and BLUE is 240 degrees (mostly left / 8 o'clock).  Programmers of C128 BASIC should immediately recognise this co-ordinate system (assuming familiarity with GRAPHIC / MOVSPR commands).
 
Hopefully you can see that aside from grays (shown in the center) the colors are spread "evenly" around the color wheel.  But if you look carefully, you should see it is not really semterical... in particular, there are 2 shades for each of RED / GREEN / BLUE (2 shades * 3 colors = 6 values), but there is only 1 shade of CYAN and only 1 shade of PURPLE, and most important is there are 3 shades of yellow = YELLOW / ORANGE / BROWN.
 
The above is what was used in my initial Alpha / JiffyDOS version of MP128.
 
Anyone familiar with the C64/128 (or the VIC-II chip) will know that YELLOW/ORANGE/BROWN are not the same hue... although they are very similar...
 
Anyway, I've made the color space used for Media Player 128 more complex (see below) in an effort to more accurately render color.  As before, RED / GREEN / CYAN / BLUE / PURPLE are unchanged.  But now ORANGE/YELLOW/BROWN is split into 3 seperate but over-lapping hues.
 
Previously the hues were non-overlapping which made the code of the video encoder rather fast and simple.  But the new color model, although more accurate, slows things down and reduces video compression / frame rate.  To see why, I think all you need to do is to compare the "new" color space (shown below) with the "original" color space (shown above)... noticably more complex, yes ?
 
Hydro's Color Space (Version 2)
The color space has been made more complex / slower, but I managed to improve both the video decoder and encoder such that, overall, the frame rate is better than before.  It may sound hard to believe that I increased the video information (quality) and reduced the file size (increased frame rate) at the same time, but, that is the truth... I found it hard to believe myself... but I really do enjoy the videos 

Back in the day, me and my friends would often get frustrated waiting on the slow load times of the C64 and C1541 disk drive.  Of course the good commericial software had fast loaders.  Some of them, like from Epyx "Winter Games" or "Super Cycle" or GEOS were pretty amazaing and almost made you forget...
 
Some of the commercial software, (Electronic Arts comes to mind instantly) had lame fast-loaders... but it was still much better than standard C1541 disk access...
 
The only thing worse was using datasette.  Start LOAD and then, go rebuild the transmission on your automobile or something because it will probably take an hour...
 
Of course things have dramatically improved since then.  For example, this here PC, which is not bleading edge, is running at 3GHz with 512MB of RAM and over 100 GB of mass storage.  That is about a factor of 1000 better in all 3 categories compared to C64.
 
And yet this equation seems evident from today's experience:
 
Microsoft + McAfee = Total Shit
 
I started out trying to upload a somewhat large file (about 35MB).  I have a pretty fast download speed, but upload takes much longer.  According to my calculations, it should around an hour to upload that.  No problem, I just check some email, and play some videos in the mean time.
 
Well about an hour into the upload, McAfee anti-virus decides to kick-in and install an update.  This turned my PC into a slush-o-matic.
 
After several minutes of very slugish response, I decided to hit CTRL+ALT+DEL to bring up the task manager and see what the fuck is going on.  When it didn't appear immediatley, I started counting...
 
One - one - thousand
Two - one - thousand
Three  - one - thousand
Four  - one - thousand
Five  - one - thousand
Six - one - thousand
Seven - one - thousand
Eight - one - thousand
Nine - one - thousand
Ten - one - thousand
Eleven - one - thousand
Tweleve  - one - thousand
Thirteen  - one - thousand
Fourteen  - one - thousand
Fifteen  - one - thousand
Sixteen  - one - thousand
 
Oh, finally there it is!!!!!!!
 
What the hell?  Did it load task manager from a datasette?
 
I see the McAffee update manager is using around 200MB.  If you know anything about Windows, you probably know the OS hogs 1/2 of physical RAM for itself.  So the Microsoft + McAfee are using almost 100% or RAM... in addition to the applications I want to run, this exceeds real available amount.
(P.S. When task manager finally did appear, I tried to stop the McAffee update, but got error message "Access Denied".)
 
Of course with virtual memory, this should not be a problem.  The total "commit charge" reached a peak of about 1.2 GB which is about 2x greater than real RAM.  But it should still work right?
 
And by the way, I think it should work "responsively".  That is, when I hit CTRL+ALT+DEL, I should NOT have to wait, even in extreme cases, for over a dozen seconds for a response!!!  (Just my opinion)
 
So in this case maybe it should be a little sluggish... um okay... grrr...
 
But when McAffee finally finishes updating, I get message "please restart your computer..."
 
Hey, I'm not running DOS or Win9x... rather XP / NT 5.1... maybe it's my fault for not buying Windows 7 ?  Really, I don't know why I should spend money on OS that has proven to be crap but anyway....
 
Okay, I'll restart as soon as the upload finishes.  But then all IE windows close with error message "we're sorry..."
 
Yes, you are sorry.  Over an hour of waiting and putting up with your crap... and you failed the upload (not mention lost the email I was composing).  More sorry than a C64 with a C1541.
 
It's a good thing this computer is in my study, and not in my garage where I would have ready access to a sledge hammer... because this thing would be a pile of plastic and silicon scrap right about now...
 
On a side note, Media Player Classic, continued to play flawlessly through the entire process (and consumed only about 30MB of RAM).  This is not the media player that ships with Windows... it is better as it supports more formats by default.  Just saying I recommend it.
 
More importantly, I disrecommend Microsoft + McAfee.  Somehow they managed to reduce the performance of this PC by a factor much greater than 1000.... the closest example I can think of to help Commodore owners relate would be:
 
PRESS PLAY ON TAPE
 
If that means anythings to you (in terms of aganozing wait), then I think you know what I'm talking about.
 
---------------
 
P.S. This experience is very ironic, because before I started the upload I was testing Mult-MHz VICE and I had the OPPOSITE problem... I couldn't make the emulated C128 run slow enough!
 
I tried running (uncompiled) BASIC program like:
 
20 FOR I=1 TO 100:GOSUB30:NEXT:PRINT TI:END
30 A=LOG(SQR(EXP(SIN(TI)))):RETURN
 
When testing VICE at 30MHz, this would execute almost immediately (about 0.4 seconds).  But the TI (time) calculations of BASIC are not very reliable for such short time periods... thus I was trying to make the BASIC program slower to better categorize multi-MHz performance...
 
Oh the irony!

Recently I was re-programming Media Player 128 from using JiffyDOS to Fast Serial protocol.  There was a major bug that took forever to track down... at first I thought it was a problem with fast-serial firmware I wrote for SD2IEC, but 'fixing' the firmware didn't solve the problem...
 
FYI, I never saw the problem while emulating on VICE even after viewing several megabytes of video... but as soon as I tried my player on a real C128 I would suffer a system crash within less than a minute! 
 
To spare you many many hours of tedious debugging, let me summarize by saying the problem revolved around these two sets of code...
 
Part 1 - Enable LoaderSEI
LDA #OPCO_BNE
STA wrtA
STA wrtB
STA wrtC
;whatever
Notice there is 1 insturction (LDA) between SEI and the first STA (more info below).
 
Part 2 - Disable LoaderLDA #OPCO_BVS
STA wrtA
STA wrtB
CLI
STA wrtC
;whatever
Notice there is 1 instruction (STA wrtC) between CLI and 'whatever'.
 
The reason for the '1 instruction delay' is something I've read about (and have learned from experience) affects the 6502 and the SEI instruction.  For some reason, there is a 1 instruction delay after execution of SEI.
 
That is, after SEI, the next instruction can really be interrupted.  You can run your own experiments to prove this to yourself.  Also, you may have seen code likeSEI
NOP
;whatever
with the NOP inserted to deal with the 6502 'bug' (err, feature?).
 
Knowing this from experience, I have for a long time assumed the same is true with CLI.  So I inserted one instruction after CLI, as shown above in 'code part 2'
 
It seems VICE was coded with this theory as well.  Using the VICE debugger, you can step through the code... and even though an interrupt may be enabled by hardware long before CLI executes, you will discover that VICE delays the interrupt by one instruction... just I have long thought...
 
But the 8502 in my C128 thinks otherwise!  Using my original code, almost any video would crash in just a few seconds.  But moving CLI after the last STA fixed the probleml; specifically,
 
The SolutionLDA #OPCO_BVS
STA wrtA
STA wrtB
STA wrtC
CLI

Well, this is the just the 'logical' solution one might expect.  However SEI does not operate that way (it definately has a one instruction delay).
 
This came as quite a suprise to me, considering how VICE is very capable of running cycle-exact software like the many demos available for the C64.  Obviously I was using x128 version of VICE instead of x64, but both are compiled from the same '6502 core'.
 
So I was curious if this is a bug with VICE or maybe something funny with the 8502, as opposed to a 'real' 6502 like in 1541/71, or as opposed to 6510 used in the C64 ?
 
Before posting, I took a look at some of my books and searched the web.  Unfortunately, all I found was generic info like 'SEI sets the I flag' and 'CLI clear the I flag'. 
 
Well, I also found a web page that tried to install a virus on my computer... he he he    I mean really... how many people search for '6502 SEI' and/or '6502 CLI'... and what kind of bastard would put a virus on such a page?  Is the 6502 really a good vector for viruses?  I guess somebody thought so...
 
Anyway, I found and squashed the bug, so this is all academic at this point.  But still, I wonder if VICE has a flaw in the 6502 core, or if my 8502 is defective (err, special) ?  Also possibly relevant is the fact the MP128 routinely switches between 1MHz and 2MHz.
 
I know the 65C02 and 65816 made some 'corrections' to the 6502.  I'm just wondering if the 8502 of the C128 has the same core as the 6502 of the 1541/71... and also if this is the same behavior of a 6510 of a real C64 ?
 
And what about the C16 / Plus4 CPU (a 7501 if memory serves correctly) ?
 
So this is just a call out to 6502 experts out there.  Could you let me know about your experience / knowledge with CLI and SEI ?  Thanks!!!