This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Topics - Hydrophilic
« on: March 01, 2013, 07:15 PM »
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
« on: February 26, 2013, 07:07 AM »
I've attached a simple program that lets you read/write sectors on fast-serial device. It works with 1571, 1581, uIEC... it seems to work with FD-2000, and FD-4000... at least in VICE. If you have some time and a real CMD FD or CMD HD, can you test and report how it works ... or doesn't work ? Thanks.
* How to use it *
Get the D64 image to a real Commodore. You can copy to real floppy or to a disk image with SD2IEC device (should also work with 1541 Ultimate).
Once you have the disk loaded, RUN the first program (its BASIC). It will detect drive you loaded BASIC from, and then load a small ML program (it does fast-serial transfer). After, it will ask which unit is your CMD device. See first screen shot. Next it will send "Inquire Disk" command and display a menu.
The menu is shown in second screen shot. At the top of the screen it will tell which unit is selected, the type of disk commands that will be used (logical or physical), and sector size (in hexadecimal). For logical format, the sector size is always 256 bytes ($0100). For physical format, it should be:
- 256 bytes ($0100) for 1571
- 512 bytes ($0200) for 1581
- 1024 bytes ($0400) for FD-2000, and FD-4000. Also CMD-HD (Please report, thanks!)
The menu gives you 6 options (and Exit makes 7). These should be self-explanatory, but here is a brief summary.
(1) Unit lets you choose a different disk unit, in case you entered the wrong value when the program started, or you have more drives you would like to try.
(2) Sends "Inquire Disk" again. You should use this if you swap floppy disks... might also be needed after some read/write errors.
(3) Toggle physical/logical command format. It defaults to physical because the 1571 does not support logical sectors like 1581 and CMD drives. See notes below.
(4) Read sector. For logical format, you specify Track and Sector. For physical format, you must also specify a disk side (0 or 1). The data will be read into RAM starting at $C00 in bank 0. Again, see notes below.
(5) Write sector. Almost the same as 4, but data is transfered from RAM to the disk and then written to the sector you specify. It also asks you to press RETURN to confirm.
(6) View sector. This shows a hexadecimal dump of the data in RAM. It may display multiple pages, depending on 40/80 column display and the sector size. When it says "MORE" press almost any key to continue the listing or press ESC to return to the menu.
* How it works *
It sends BCIS commands to the disk drive. These are used in CP/M and some other software for fast read/write of sectors of data. This program only transfers 1 sector at time, but the commands allow multiple sectors to be transferred at once.
Whenever it transmits a command that returns a BCIS status byte, or whenever it transmits/receives sector data, the ML program is called to do the transfer. While waiting for the fast-serial bus, the 40-column screen will flash colors. If for some reason the drive stops sending data, the computer would be stuck in an infinite loop (this is true of CP/M code and maybe KERNAL Phoenix)... however in ML program it tests for STOP key... so if the program stops responding for a long time, you can press STOP to regain control. If this happens, you should send a standard command like DIRECTORY to the drive to get its attention.
* Notes about logical / physical command format *
Now this could be confusing because Commodore changed the syntax of BCIS between 1571 and 1581. CMD drives use the 1581 flavor. So we'll ignore the 1571 here.
With logical format, you do not specify a disk side, and sectors are always treated as 256 bytes. Also, the first sector on the disk is addressed as Track 1, Sector 0. For 1581, the sector number can be as large as 39 (i.e., 40 logical sectors/track). For CMD devices the sector number can be as large as 255 (i.e., 256 logical sectors/track).
With physical format, you must also specify the disk side (disk head), and the sector size will depend on the device you use. The first sector on the disk is addressed as Side 0, Track 0, Sector 1. The maximum sector number should be:
- 10 for 1581
- 10 for FD-2000 (assuming HD format)
- 20 for FD-4000 (assuming ED format)
- for CMD-HD (probably depends on particular hard drive)
There should be no harm if you specify a bad sector number. If it is bad, the drive just won't find it and report an error. BTW, if you are wondering why FD-2000 has same maximum sector as 1581, you should remember that FD-2000 physical format is 1024 bytes/sector, which is double the 1581 (and why FD-2000 can store about 1600KB compared to 800KB of 1581).
The track number also varies. With logical format, the maximum track# is:
- 80 for 1581
- 25 for FD-2000 (assuming HD format)
- 50 for FD-4000 (assuming ED format)
- Varies for CMD-HD.
As far as I can tell, all the drives will imediately report an error if you give a bad track# in logical format, so there is no danger.
Be very careful with track# when using physical format commands! It seems the drive will try to seek to any track you specify, even an invalid track, which could ram the read/write head into the center spindle. With physical format, the maximum track# is:
- 79 for 1581
- 80 for FD-2000 (assuming HD or ED format)
- 80 for FD-4000 (assuming HD or ED format)
- Varies for CMD-HD
Note the maximum track# is 1 less for 1581 because physical track# starts at zero (instead of one). This would also be true of FD drives, but they have an extra hidden track (would be track 81 in logical format, if it would allow you). This extra track is mostly empty, except for about 1K of data that defines the partition table. As far as I know, the physical format version of the BCIS "read sector" command is the only way to read this hidden information... i.e., using logical format BCIS commands or traditional U1 command will not work.
Anyway, have fun reading sectors.
* Background *
This is a very simple test software. There are many ways it could be better. If you think it is lame, just know this is the "enhanced" version. The original was all ML without a nice BASIC front end. It was written (originaly) when I was writing fast-serial firmware for SD2IEC. Well I got "burst-load" to work with everything, and also "burst read/write" to work with D64 and D71 images. But it has recently been suggested to add support for D2M D4M DNP image in CP/M. I think that is a worthy goal, but it means "burst read/write" support must be expanded for SD2IEC, not to mention changes to CP/M itself (see this thread
I updated the software for additional testing before hacking CP/M. Well I did release a quick hack, but it only supports FD-2000, and only after you load it from a "normal" disk. In other words more testing is needed to make a real CP/M solution. Not only would it be nice for CP/M, but fast-serial support of CMD disk images would also be great in SD2IEC. The problem is I don't have real CMD hardware, just VICE.
* Strange things with VICE *
When I first tried this, I had terrible trouble with FD-4000. Later I got it working using FD-2000 and reported about it the CP/M thread... I thought everything was going well.
But when I tried FD-4000 again, I was still getting bizarre behavior in VICE. One thing was I would constantly get "invalid block" errors, even when I specify valid (side)/track/sector. I found out one to get around the error: before issue BCIS "Inquire Disk", first issue BCIS "Set Status" with a value of zero. That is, $55 $30 $4C $00. This was not needed with 1581 or FD-2000. I never would have thought of it, except that I noticed that CP/M does this the first time it accesses a drive or after an error. Not sure why only FD-4000 needs it, but at least I got it working...
Later I discovered that I could not access past logical track 25 on FD-4000, even though DIRECTORY reported 3MB size (i.e., 12736 Blocks Free). You should be able to access logical track up to 50!! Also it was not a problem with the BCIS commands. Using classic "U1" commands would not allow tracks greater than 25 either
However, using physical command format, I could access anything on the FD-4000. I looked at the hidden sectors on the reserved track, and the partition layout looked very similar to one of FD-2000. I think the FD-4000 image generated by VICE was corrupt. I did a "full format" of the same FD-4000 disk, and again it reported 12736 Blocks Free, but now access to logical track 50 is possible
Either with BCIS or classic U1. So maybe there is a bug with "make disk image" in VICE ? Or I did something "wrong" ?
Although the Directory and BAM used by CMD drives is well documented, I haven't found any good information on the CMD partition table in the hidden track. This lack of reliable information may be the root cause of the error... assuming the error isn't the user Edit
Fixed information about maximum physical track, added info about maximum sectors.
« on: February 26, 2013, 04:41 AM »
« on: February 26, 2013, 04:38 AM »
« on: December 24, 2012, 09:09 AM »
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.
« on: October 14, 2012, 01:24 AM »
On the C128 (also Plus/4 and CBM-II) we have the handy USING preposition. This is documented to work with PRINT and PRINT# as I think most C128 programmers are aware.
What other command(s) can use USING?
Hint, I mean really use it... not something that is ignored like MONITOR USING or BEND USING
« on: October 12, 2012, 10:09 AM »
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:
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.
« on: July 18, 2012, 10:18 AM »
I imagine some people enjoy writing a GUI app, but not me. Seems like you have to write 4 or 5 or more routines for every element of a simple command line program. Not to mention time spent to actually design the interface ( layout, images, etc.). So although it has taken a bit longer than I wanted, at least I have made some progress I can show.
I am talking about graphical user interface for the command-line encoder that was included with Media Player 128 (beta)
. Although MP128 can play some 'foreign' files (like 8-bit .WAV and .AIF), it requires a (large) REU. For other devices (like 1571/81/CMD-HD), the files need to be converted to a CBM 'native' format (such as 4-bit audio or VIC-II bitmap). I've attached a few screen shots for anyone to comment on.
The first is the 'Make' dialog that accepts various arguments for the audio/video file you would like to convert for playback on C128 (possibly C64 or others). I have not added any new features to the encoder yet. You can see the 'Make' dialog is a bit complicated, as it reflects the many arguments that are possible with the command-line version. In fact, some of the options are disabled (grayed out) because I haven't written GUI windows for everything yet (for example, the Video Settings... which allow you to adjust things like brightness, contrast, hue and saturation).
The second screen shot is the main window at 1024x768 size. It can be resized to fit your needs. Oh yeah, the app does not use any fancy features like DirectX or .Net framework, so it should run on any 32-bit Windows or newer (including Linux Wine).
Anyway, at the top you have standard menus and tool bar. Just below them are two windows. At the left is a little bar graph that shows the encoder's current time within the audio/video (it is currently working on frame 128 which occurs at time 00:31.75 in the original video). The very wide white box that stretches all the way to the right will show 'future' video frames that encoder is considering... the so called 'look-ahead' buffer. The original encoder did not use a look-ahead buffer, so this area is blank for now.
Below the encoder information are several windows on the left side that represent the current state ("now") of the decoder (i.e., the state of the C128 at a specific point in time during playback). At the top is the audio playback time (currently playing audio sample 249567 at time 00:31.93 in the output file). Below that is the state (fullness) of the audio buffer (currently 92% full, $eca bytes out of $1000).
Streching all the way to the bottom is a view of the decoder's frame buffers. These are the images in the C128 memory that have already been loaded. One of them is being displayed for the user at any given time (in this case, the very last one). For each video buffer, you can see the VIC-II conversion of the frame, its location in C128 memory (bank 1), the compressed size, and compression ratio. For example the current (last) frame is based at address $a000, it is encoded with 1175 bytes which is a compression of 79%.
Although this layout is 'logical' in that it shows the C128 frame buffers in the same order they have in RAM, it is not very meaningful to the user or the encoder. For example, you wouldn't know that the last frame is the one being displayed 'now' had I not told you. I'm going to change this so it shows the frames in MRU order. That is, Most-Recently-Used order. So for example, the last image ($a000) would appear first, followed by the previous frame, (two images above in the screen shot at $6000), followed by other prior frames (for example, the next-to-last frame at $8000 actually occurred several seconds in the past).
Oh yeah, to the right of that is the big 'main' window which just shows a text-file version of the 'Make' parameters. These can be saved to a file so you can easily re-encode a video by tweaking some settings if you are not happy with the way it plays on your C128. This is very similar to writing a batch file to call the command-line version. But hopefully I will find the time to add some real-time refinements... for example a line could be added like
@t 01:22 vin_contrast = 1.25
which would increase the contrast of the video starting at time 1:22 of the video (presumably it was different at the start of the video). The idea is to improve quality of scenes that encoder does a bad job of encoding (or perhaps the source video was not very good at that scene).
If everything goes well, I should find the time to add some VDC encoding options. For example, I released a command-line VDC image encoder for use with Tokra's 8x2 video mode. Well that was actually derived from the MP128 encoder. So it shouldn't be much effort to put it 'back' in to this new version. I also want to try VIC-II text modes for image encoding. If that works well (and time permitting) I might even try a VDC text-based video. Ha, ha, ha!
Although this is all very preliminary, at least it is making videos now. The final attachment is from VICE which shows a screen shot from the video a few seconds later. Hello Europe!
« on: June 21, 2012, 10:00 PM »
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!
« on: May 20, 2012, 01:30 PM »
Compared to a disk storage system, tape is somewhat slower...
« on: April 19, 2012, 11:11 PM »
« on: February 29, 2012, 11:59 PM »
Want to see the 80-column output of your C128 but don't have a lot of money to spend? Well here is a cheap method to get a monochrome display.
All you need is three things, which you may already have
- TV or Monitor with composite input *
- A composite audio/video cable
- Wire cutters/strippers (or a knife)
If you have those items then this method is free... is FREE cheap enough for you?
Step 1: Get a composite video cable to use (see photo 1)
Step 2: Using wire cutters, cut off one end of the video cable (see photo 2)
Step 3: Strip about 1 inch | 2.5 cm of insulation from the end you cut (see photo 3)
Step 4: Twist the outer wire mesh (ground) into a solid wire (see photo 4)
* You can use a TV without composite input if you have a VCR with composite input... I did this back in the day, ask if you need details about this method.
« on: February 14, 2012, 06:47 AM »
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.
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.
« on: February 01, 2012, 11:24 AM »
I should be patching MP128 like I said I would, but instead I've been looking into building a MAME-type arcade cabinet. Of course mine wouldn't just support the arcade titles of MAME, but also Atari 2600, NES, and of course CBM games courtousy of VICE.
You can buy cabinets from various online retailers or build your own if you're good at carpentry and design. Good at design is the important thing if you don't want to buy one...
I came accross a site that has numerous examples of BAD design. Sometimes there are some ideas that seem like a good idea but the layout (design) is really bad. Note the pages contain a lot of filthy language and real negative attitude, which I find quite unsavory (high school kids may find it amusing) but the pictures of the bad designs are very informative for anybody considering such a project. Here's the link
« on: December 11, 2011, 07:38 PM »
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.
« on: December 09, 2011, 06:02 PM »
Does anyone know if the Chameleon works with the C128 in 128 mode?
I've been thinking about getting an REU or some sort of memory expansion for a while now, but I would prefer not to tie up the expansion port with a device that only provides REU functions (but I guess if you have to use only 1 device, REU would be at the top of the list). Anyway from what I read, the Chameleon has everything I would want in a cartridge: REU capability upto 16MB, reads SD memory cards, and can be connected to ethernet somehow as well... just amazing. If that weren't enough, it also functions as a stand-alone system with video out and keyboard/mouse inputs...
So I want one, or something very similar. The sellers say it runs on the C64 but make no mention of the C128, so I am assuming it does not work on the C128 (or they are just not savy marketers).
So who knows?
« on: December 08, 2011, 08:37 AM »
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$="##### ################ #####"
40 print using f$; n, chr$(34)+m$+chr$(34), t$
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...
« on: December 08, 2011, 07:06 AM »
The bug involves the internal address registers pair (registers 18 and 19 decimal, $12/13 hex). I say it is new because I've never read anything about it before, but it seems to be as old as the VDC itself. This bug has driven me a bit crazy, but now that I've *finally* squashed it, I think I should report just to help other programers avoid it.
I discovered this bug while working on the VDC mouse routines for Media Player 128. The mouse pointer appears correctly in VICE, but on a real machine -- the mouse leaves a trail of colorfull / blinking / underlined characters.
Because the mouse pointer runs during IRQs, I was trying to save cycles by directly writing the VDC registers directly instead of calling the VDC_READ and VDC_WRITE routines in the Editor ROM. When that failed with the 'color bug' described above, I decided to use the ROM routines anyway... a slow routine that works is better than a fast one that fails, right?
But then it STILL failed with the 'color bug'. Which is to say the bug is present on a real machine but appears okay in VICE. Some experimenting confirms (to my satisfaction, judge for yourself) the bug is with address register pair $12/$13.
Specifically, it seems the VDC will 'forget' the high byte you write to register $12 if you write a low byte to register $13 first. Now the Commodore 128 Programmers Reference Guide does mention the importance of ordering register writes when it comes to block copy / block move. Obviously you need to set up the source address and destination address before you tell the VDC to actually perform a copy/move operation!
However the C128PRG (or any other reference manual to my knowledge) fails to mention the fact that you have to write the RAM access high ($12) first and low ($13) after. If you write the address halves in the opposite order (low byte first, which is typical for non-VDC programming) then as said above, the VDC will 'forget' the high byte.
In my particular case, it meant when the program was trying to save the old attribute (color, blink, underline, etc.) under the mouse pointer (at address $0870 for example), the program was really saving the character screen code instead (from address $0070 for example). Which is because the VDC 'forgot' that I updated the address high byte -- it forgot I changed the high byte from $00 to $08.
Well once you know the bug exists, the solution is simple. ALWAYS write the high byte first and the low byte second. That is, write register $12 then register $13 in that order only. Problem solved.
« on: September 19, 2011, 11:13 AM »
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
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.
- 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.
« on: September 13, 2011, 10:23 AM »
I wanted to test out my mouse/joystick driver before putting into MP128 (so I could test in a simpler environment), so I made this BASIC program which I thought was fairly simple (more about that later).
The program just models the gravitational force of n-bodies in 2 dimensions. To use it, attach the disk to unit 8 and power-up to auto boot, or you can enter RUN"PLANETS" after power-up. It doesn't need to be in disk unit 8. It should even work from cassette but I haven't tried it.
Once the program is loaded, the screen is cleared and you have 3 menu options. Plug a mouse into port 1 or a joystick into port 2 (or both, that's a fun game with a friend/enemy!) You can also use the keyboard for most operations (all except drag-n-drop). Building a Solar System
To start building, click Add or press A. You get the New Body menu where you set the mass, velocity (speed), and color of the new body. I always start with a star = mass of 1000 and speed 0. Whenever you're done setting the options for the body (star / planet / comet ) click O.K. or press Return.
Your new body will be attached to the cursor and you can move anywhere on the screen you like. When you find a nice location, click on the spot set the initial position. If you gave your body a non-zero speed then it should start moving right away. Even if you gave your new body a zero speed, it should start moving soon if there are other bodies present (gravitational attraction).
Of course adding only 1 body (a star for example) is rather pointless. So you will want to Add at least one more body. If you added a star like described above, the second thing to try might be to add a planet. A large jupiter-size planet should have a mass of about 1.0. A small earth-size planet should have a mass of 0.01 or less.
Whatever mass you give to your planet/comet, be sure to give it some velocity. If you give it zero velocity, it will simply fall into the star. A good starting condition is to place the planet on the same horizontal line as the star, and give the planet an x-velocity of 0 and y velocity of non-zero (1 to 10 depending on distance). Or you can place it on the same vertical line as the star and give your planet a non-zero x-velocity and zero y-velocity. I hope that makes sense! Basically you want the planet to move perpendicular (at right angle) to the star.
It's easy to get 2 bodies to orbit. When you try adding a third, you may find it rather challenging to find an oribt that is stable for all bodies. This is the so-called n-body problem. If you don't do a good job of guessing a starting positition/speed/mass for the 3+ body, then it or one of the other bodies will likely get ejected from your solor system. Editing and Deleting Bodies
If you see one of your planets flying off into deep space, or if you're just not happy with it, you can change or delete it. Just click on the body you're interested in, and you'll get the Edit Body menu. This works just like the Add body menu. You can change the velocity, mass, or color. You can delete the body from your solor system by clicking Delete (or press ESC). Otherwise, click O.K. when you're happy with the new settings, and you get the option to reposition the body. If you click Yes (or type Y) then you can move it anywhere, just like when you add a new body. If you click No (or type N) then body returns to it's previous location but with the new properties you just defined. Demo
Hopefully you'll have some fun trying to build a nice solor system. It can be quite a challenge with multiple planets which have a large variety of mass. In fact it can be quite frustrating. To demonstrate it can be done, you can choose Demo from the main menu. Then you can select the number of bodies to model, 1 to 7. Selecting only 1 is a bit silly as you'll just have a lonely star sitting in the middle of the screen. Although the n-body problem is a challenge, I got those demo settings after playing around with it for a day. Then I went to sleep without turning off my computer by accident. The next morning I was pleasantly suprised to see all my planets were still in orbit The question is, would be it stable for 4.5 billion years? I think not. Quit
Bored already? Click Quit (or press Q) from the main menu to end the program and turn off all sprites except the pointer, so you can test it outside the program (or with other programs). If you want to restore the defualt IRQ routine (disable mouse/joystick control of pointer) then type SYS DEC("B83"). Or simple press STOP+RESTORE. Technical
The program was meant to test the joystick/mouse driver, so it is not very sophisticated. The most noticable thing is scaling: because VIC pixels are not square, a planet in a circular orbit will apear to be in an eliptical orbit. Another thing is no provision for collisions: bodies just pass through one another. Finally there is the issue of units. The program doesn't use standard units of mass, distance, and velocity.
All of the above could be corrected fairly easily, by employing some constants in the equations, but that would just slow the simulation down. It seems to run okay with 2 or 3 bodies, but beyond that you will notice it becomes slugish. I compiled the BASIC program to make it faster, but it didn't help much. Usually when you compile a BASIC program, it will be 10x faster (or more). However due to lots of floating-point calculations, a poor compiler, or my bad programing, it runs only about 2x faster when compiled.
I tried compiling it with Data Becker's 128 Compiler (v1.03) but it gave me lots of trouble. That compiler kept giving me errors about BEGIN/BEND. And it doesn't perform IF X correctly. That's just terrible in my opinion! I tried re-writing my program with GOTOs and IF X>0, and eventually got past those problems, but then there was a problem with STR$(). It seems if their are 8 digits after the decimal point the run-time version will crash randomly (depending on the digit before the decimal point). At this point I gave up on that compiler.
Next I tried Blitz! 128. This compiler doesn't have as many options (in particular, no native 6502 ML), but at least it works! I think maybe the speed could be improved if the variables were accessed in 1-d arrays instead of a 2-d array. However I've spent too much time on this already, so didn't investigate the possibility.
Anyway, the compiled program "PLANETS" is what is normally run. The disk image also includes "PLANETS.BAS" which is the uncompiled version. Should you want to play with it. Also on the disk, "PLANETS.SPR" are the 7 sprites (besides the pointer) used in the program. They should load to $E40~$FFF. Also on the disk is "MJ-G-DRV.BIN" which is the mouse/joystick driver with Group option (for drag-n-drop). This is the ML driver used in the program, and loads to the area $B80~$E3F (it includes the sprite pointer). Not used in the program, but also on the disk is "MJ-DRV.BIN" which is the smallest version I could make. It loads into $E00~$FFF and includes a sprite for the pointer but does no sprite grouping (no drag-n-drop); more importantly the memory used for BASIC sprites 2~7 are instead used by IRQ code. Theory
I was suprised the compiled version was so slow considering the BASIC algorithim is simple (to me anyway). Here it is,
FOR I=1 TO N-1
FOR J=I+1 TO N
Well that's the theory. In the program the outer loop is DO/LOOP and not FOR/NEXT because some elements (planets) might be missing (if you deleted them) and a check of mouse/keyboard/joystick can break the loop. I also optimized away the division of L by making it a part of the F calculation. Anyway, this calculates the forces (and gravitational acceleration) between all possible pairs of bodies. The number of times this loops is related to the square of the number of bodies. Specifically
number of inner iterations = (N-1)*N/2.
So with 3 bodies, there are only 3 iterations. But with 4 bodies there are 6 iterations. With all 7 bodies, there are 21 iterations of all that code.
Finally there is more code to take the accelerations calculated above and apply them to the velocity/position of each sprite (and also reset the acceleration). So as you can see, BASIC has a lot of work to do. So maybe now you can see why it runs slugish with 4 or more bodies. The End
Well it works for me in VICE with joystick or mouse or on my C128 with a joystick (actually a sega game pad). Unfortunately I don't have mouse any more for my C128, so if anybody with a real C128 and mouse would care to report how it works, or fails, I'd love to hear about it! Edit
Corrected some typos... it seems I can spell gravitational acceleration but not solar... thanks Naquaada
« on: June 21, 2011, 09:07 PM »
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
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
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
« on: May 31, 2011, 04:53 PM »
So me an DeeKay are having a conversation about VIC-II sprites. In particular, a *feature* called sprite-crunching. He gave me a reference to a document by the VICE team. This covers some of the missing details of the "VIC-Article" by Christian Bauer.
Anyway, the VICE document refers me to US Patent# 4572506
. Somewhat informative but very confusing. I have a degree in Electronics Engineering and also have considrable experience with the VIC-II. Yet this document is still extremely
difficult to read. Good luck to anybody without a heavy technical background...
So instead of trying to read lawyer / nerd mumbo-jumbo excuse for the English language, I thought it would be easier to simply look at the schematics
. It seems the images are some type of PIW format
I've seen plenty of document/image formats from Commodore/IBM/Linux/Mac, but have never come across this. It seems I am not alone. Neither Microsoft IE nor Google Chrome have any idea how to render such images. I'll do some research when I get bored if I don't forget, but in the meantime, if anybody can tell me more about the PIW format (and how to view it) that would be great... thanks!
« on: May 23, 2011, 04:51 AM »
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
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!
« on: May 08, 2011, 05:35 AM »
Warning: long technical post (but easier than QCD)
This happens to relate to C128 software, audio, video, and the fast serial bus; but hopefully we can discuss ideas about bandwidth and data throughput in general (as applicable to C128). So it doesn't have to deal with the serial bus or audio or video. Just the idea of effeciently and reliably dealing with a continous stream of data.
I've been testing Media Player 128 with the fast serial protocol, and I've got the IRQ routines working well. The frame rate is really nice compared to the JiffyDOS version, but I don't think I'm making full use of the potential bandwidth capable with fast serial.
So let me describe what my software is doing and what I think the issues are. Please post if you notice something I'm missing or have any ideas or links that may might help. Thanks!
There is the main IRQ running at approximately 7.8kHz. Each IRQ will play a bit of audio and usually read a byte from the serial bus. So to a first approximation, the bandwidth is 7.8k byte/s. Here 'k' means 1000 and not 1024.
However, in the visible portion of the VIC screen, the VIC DMA (so called bad lines) means there is not always enough time to read a byte. So 1 in 4 IRQs will not get data while VIC is in the visible portion. Also the transition from 1MHz to 2MHz and the other transition 2MHz back to 1MHz do not read a byte from the serial bus.
So to a second apporximation (taking the above factors into account) the data bandwidth is 6.66k byte/s. But when the video is encoded at that bandwidth, playback tends to stall every 20 seconds or so because data is not actually getting delivered at that speed.
Two reaons for this descrepancy seem obvious to me. First there is delay by the drive between sectors. On C1581 (emulated in VICE), there is about 256 microsecond delay between sectors on the same track, so there is a loss of about 2 byte transfers for each 254 bytes (on the same track). Also there is 1 status byte transferred for each sector. So that basically means 3 bytes 'lost'... or approximately 1% loss.
I haven't measured the delay for sectors not on the same track. This is the main delay from the side of drive. I don't think VICE emulates this delay accurately. Even if it did, there would be variance with other devices like CMD-HD or uIEC.
A second source for reduced bandwidth is from the player software. It has to temporarily suspend loading data at the end of each packet / start of next packet to calculate pointers. This usually takes the time normally needed to load 1 to 3 bytes (depending on packet type and current CPU speed). The packet sizes are usually a bit smaller than a sector... about 200 bytes on average. So I guess overall this causes another 3% loss to bandwidth.
I tried scaling back the bandwidth on the video encoder by 10%... now down to 6.00k byte/s. But it doesn't solve the problem... video playback will still studder. It happens less frequently, but it still happens. And it is always annoying when it happens. When I say the video stutters, this is actually a symptom of the audio buffer being drained.
The stutter is rather predictable when playing back on VICE with C1581 emulation. But on real NTSC C128 using uIEC, it *almost* never happens. Some videos play fine, but most will experience one or two delays. I imagine a real C1581 would stutter worse than the VICE emulation. And I imagine a CMD-HD would be somewhere in the middle; that is to say more than SD2IEC device but less than C1581.
So one obvious solution is to reduce the encoded bandwidth even more, down to say 5.75k byte/s. Another one would be to increase the size of the audio buffer. Right now the audio buffer is 4 kiByte = 2.1 seconds of audio (using 2-bit audio). I have another 4 kiByte that I was reserving for a second audio channel (stereo SID), so I could easily do this... but it seems to me 2.1s should be plenty to account for any delay by the disk drive...
It sounds like it might be a bug in the encoder, but I have several checks in there and haven't been able to track down a problem... I guess I could try changing the priority of the audio buffer versus the video frame... As I recall, it tries to keep the audio buffer at least 40% full which would be about 1s of audio. I think 1 second should be plenty of time for a C1581 to move its head and load a track (assuming no read errors).
However, it seems like I'm just not using the potential of the fast serial bus correctly. After all, you can load data at sustained speeds over 6k byte/s with most any fast serial device (the C1571 might be an exception). Of course that is just sitting in a polling loop (as opposed to loading during IRQ like I'm doing...)
Some other less promising ideas involve changing the IRQ routines. Such changes could make the IRQ routine a bit faster, and since they are called very often, this would actually add a few thousand cycles to the main routines. However, such changes would be a hassle and more importantly, I don't think it would make a huge difference in data throughput. So like, it would mean the packet demuxer could run a bit faster, but it is only taking 2% to begin with... improving down to 1.9% doesn't seem like it would be worth the effort.
Just in case somebody thinks changing the IRQ routines might help, let me describe how it works...
The CIA#1 timer A is used to generate the IRQs. The timer IRQ is cleared by simply reading status register at $dc0d. This also contains the status bit of fast-serial byte received. Because the software is not always ready to receive a byte (because of VIC DMA for example), the status bit must be saved during every IRQ. So the IRQ routine does this...
'old_stat' is in zero page, so the ORA / STA instructions take 6 cycles total. By the way, if the software isn't ready to read data, the BNE opcode gets changed to a dummy command, like CMP #nn. Thus the fast-serial flag would be saved until the software can read the data.
One idea would be to have CIA#2 generate the timer interrupts. Then we wouldn't have to save the fast-serial bit because we wouldn't even look at $dc0d when not ready to get data from the serial bus. The main problem with the idea is that CIA#2 generates NMI and not IRQs. During the visible portion of the screen, interrupts can occassionaly 'stack' on top of each other.
This stacking doesn't happen often, only during VIC DMA and the audio buffer has a page wrap. The important thing is it does happen. It is not a problem with normal IRQs because they will wait, but I imagine it would be trouble with NMIs which never wait...
Anyway, when there is data available and we decide to (un)load it from the serial register, there are two DEC commands performed...
That's a bit simplified because 'byte_n_packet' is actually a 16-bit number. The 'byte_n_sector' tells us when the drive will send a status byte so we know not to put it in the audio or video buffer as normal data.
It should be noted this is wasting some time by doing 2 DEC for each byte loaded. Remember, this should ideally happen every IRQ... thus by elimating 7 cycles per IRQ, we're really saving about 54000 cycles per second...
As I said before I don't think such a change would improve data thoughput by a significant amount. The change would require some slightly messy code. Here's I think it would go...
You'd have to compare 'byte_n_packet' and 'byte_n_sector' before starting to load a packet. Put the smaller number in a variable 'byte_until_something' then decrement that 1 variable (thus only 1 DEC per IRQ). When it hits zero, check another variable that tells us if 'something' is 'end of sector' or 'end of packet'. If not 'end of packet' then read status byte and re-calculate 'byte_until_something'. Yeah, that's what I call messy... and I probably left something important out...
I played around with some code to load data in a polling loop, but I didn't like how it was going... it was real messy with IRQs coming from CIA#1 (thus not very CPU effecient). Might be better with CIA#2 assuming the NMI issue mentioned above doesn't crash the system... but either way, the software would have to toggle from normal video decoding into byte-polling mode and back...
This mode switching isn't completly bad idea; once the main thread has decompressed a video frame, it doesn't have anything else to do except check the STOP key. So switching to a polling routine seems natural at that point. Maybe I should have another look at the idea...
Another idea would be to increase the average packet size. Thus given the same amount of raw data, there would be less overhead. Therfore more effecient use of bandwidth, but I don't think it would improve the bandwidth... which is what I would like to do if possible.
Also, the average packet size is just under 256 bytes because video packets get loaded into a page of memory for decompression. This makes decompression fast by using absolute indexed addressing. For example LDA $F000,X takes 4 or 5 cycles; as opposed to indirect indexed addressing like LDA ($FE),Y which takes 5 or 6 cycles.
That's not much of a difference for a single byte, but because a bitmap is about 2 kiByte compressed that amounts to about 2000 cycles per frame... Wait, the frame rate is only 2~5 fps anyway.... so maybe larger packets would be a good idea...
Well, that's about it for my ideas. Please let me know of any ideas or experiences that could be helpful for effecient data throughput / maximizing data bandwidth. Thanks again!
« on: April 24, 2011, 12:47 PM »
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 Loader
Notice there is 1 insturction (LDA) between SEI and the first STA (more info below).
Part 2 - Disable Loader
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 like
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,
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
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!!!