{"id":89497035,"date":"2012-02-22T14:33:54","date_gmt":"2012-02-22T14:33:54","guid":{"rendered":"http:\/\/ocaoimh.ie\/?p=89497035"},"modified":"2017-10-21T11:36:51","modified_gmt":"2017-10-21T10:36:51","slug":"the-commodore-64-disk-masher-c64-dms","status":"publish","type":"post","link":"https:\/\/odd.blog\/2012\/02\/22\/the-commodore-64-disk-masher-c64-dms\/","title":{"rendered":"The Commodore 64 Disk Masher (C64 DMS)"},"content":{"rendered":"

DMSREADER and DMSWRITER are two parts of a Commodore 64 tool I wrote way back in 1994. I presume I got the name from the Amiga DMS tool<\/a> but I really don’t know. The purpose of the tool was to create an image of 5 1\/4 disks but break the image up into smaller DMS files.<\/p>\n

Download dms64-1.0.zip<\/a>.<\/p>\n

\"\"<\/a> According to the attached note, I wrote it to upload C64 demos to local BBSes but it was also used by me and the few people I still swapped C64 disks with back then. Were D64 image files around in 1994? If they were I didn’t know about them. They could only be useful to users of higher capacity disks anyway. Don’t bother trying to send a message to the email address in the note. It’s an address I had in first year in college and is long gone!
<\/p>\n

I’m posting this here because there’s no sign of this tool at all online. Some of my demos are already on CSDB<\/a> but not this. It’s obviously not that useful these days when a D64 image file is only 171KB but for historical reasons it’s probably of interest. Each of the two parts are a mixture of BASIC and assembly language. By the looks of things I used some sort of illegal character trick to hide the BASIC loader but you can view it easily in CBMXfer.<\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a><\/p>\n

DMSWRITER recreates the disk from the DMS files. It’s fairly easy to use. Enter your drive number(s) and follow the instructions. Well, almost.<\/p>\n

\"\"<\/a> Where I wrote “destination disk” in the DMSWRITER it should have been “source disk” instead. Ooops. When data is written to the destination disk the border flashes with thick multicolour bars but when it flashes quickly with a grey\/blue flicker you need to change the source disk to feed it more DMS files.
\nI noticed that the source drive light continues to flicker after the process is over but sending a reset or loading the disk directory will sort that out. I also noticed the text of the on screen display flashes up while writing as if that data is written to disk. I need to make sure that isn’t the case or we’ll end up with corrupted disks. I never noticed any problems previously so hopefully it’s a false alarm.
<\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a> DMSREADER is responsible for creating DMS files. The process is much the same, only in reverse. The source drive should contain the disk you want to make an image of and the destination will be a blank disk. You’ll have to use two destination disks unfortunately as I never got around to compressing the output files. There’s still a bug in the READER where it asks you to flip the destination disk a second time, ignore that and just hit space.
\nUnfortunately when I first tested the reader I received a “?SYNTAX ERROR IN 1000” error just after I was told to flip the destination disk. Fixing it was easy, replacing the following code: <\/p>\n

1000 IF (PEEK ($DC01)AND $10)< > 0THEN GOTO 1000<\/code>
\n1000 IF PEEK (56321)< > 239THEN 1000<\/code><\/p><\/blockquote>\n

When I wrote that BASIC programme I was too smart by half. To stop people looking at the code I added REM commands followed by an illegal character. Just so I could debug the programme itself I had to edit the RAM where it lived and replace that character. Look for 8F CC in the screenshot below of the Action Replay machine code monitor. I replaced CC with 34 (character “4”) to get a code listing.<\/p>\n

\"\"<\/a><\/p>\n

The DMSWRITER BASIC loader uses 56321 which is correct, but I have to wonder why I didn’t use a BASIC command to wait for a key press rather than fooling around with low level registers<\/a>. The original file has been renamed DMSREADER.ORIG.
<\/p>\n

While looking at the ASM code in the file DMSREAD I think I found a small bug in the otherwise excellent CBMXfer. The first screenshot below is from CBMXfer and you’ll notice that the BNE returns to the wrong address. I loaded an Action Replay<\/a> cartridge and used the monitor in that to view the same code in Vice where the BNE address is correct. Gave me a fright to think there was such an obvious bug in my code…<\/p>\n

Oh yes, make sure you disable any fastloaders and enable true drive emulation in Vice when using these tools.<\/p>\n

\"\"<\/p>\n

\"\"<\/p>\n

So totally chuffed that I can use an Action Replay in Vice. I did all my development in that monitor. Yes, not easy …<\/p>\n