MESS abandons d64 format in favor of g64?

[rhurst]

So I learned this past weekend that the latest "release" 0.136 has dropped d64 format to go even deeper into accurate emulation of the Commodore 8-bit line, which means upscaling your d64 to g64 format.

By default, VIC 20 is paired with C1540 drive and C64 with C1541. Fortunately, I was able to get the C1540 ROMs from Bo Zimmerman's site. Hopefully not too far into the future, it will allow for changing device types and daisy-chaining.

There were some links posted that pointed to such conversion utilities:

http://rittwage.com/files/nibtools/

http://ist.uwaterloo.ca/~schepers/personal.html

http://c64preservation.com/nibtools

If anyone knows more about this new format, I would like to hear more. I have not checked VICE out yet to see if it too can support g64 format.

[Mike]

VICE has *.g64 support built-in.

From what I know, *.g64 files model different write speeds for each track (maybe even mid-track changes in write speed), non-standard data encodings in headers and sectors, half-tracks, and sector offsets of adjacent tracks. Dunno about half-bits, though.

So most conceivable copy protection schemes can be faithfully represented by *.g64.

[saehn]

Wow... supporting G64 is great, but dropping D64...? questionable!

[carlsson]

Besides, I wonder if those VIC-20 trackmos support the 1540, i.e. if its ROM and memory map is equivalent enough to have 1541 programs run inside the drive. If the two drives are fairly different on the inside, it would be a bit pointless to pair the VIC-20 with a 1540 since the majority of disk based software would've been written with a 1541 or newer in mind. Collector's correctness by all means but anyone using MESS is not likely to run games from a collector's point of view.

[Mayhem]

Wow... supporting G64 is great, but dropping D64...? questionable!

Yeah... seems an odd one. As Mike states, the G64 format allows more information to be stored about each track, and so many copy protections can be preserved native and still load fine within emulation without having to be cracked. A few need the odd bit tweaking to work in emulation (but work fine when recopied to a real disk). Both CCS and Vice support this format already.

[gklinger]

What I find odd about this plan is that g64 isn't perfect. Granted, it's an actual approximation of a disk but it isn't comprehensive. If they're going to be sticklers, why not come up with the say all, end all?

Every few years I try MESS and delete it within a few hours. The OS X version is, well, a mess.

[rhurst]

Great feedback, guys, thanks. Anyone actually use g64 format for a specific title?

I've been tinkering with real media using OpenCBM, even though I have two uIEC drives (one powered by joystick port, the other by cassette). I am interested in this native g64 format for original copies of games, and not the cracked / trainer ones. The software links posted are not "friendly" for modern OS and hardware, and my first attempts at compiling the one for GNU and Windows will only work with 32-bit machines, even though it uses OpenCBM that can run 64-bit. So I am left pondering if I need to get involved and assist in getting that project up-to-date -- but is g64 formats "worth" having? Sigh.

I agree that g64 does not sound 100% complete, but there must be progress if it's ever going to get there. Reverse-engineering hardware using a 100% software solution isn't easy.

I am a VICE, UAE, and Stella (and most recently Petr Stehlik's Atari 800 compiled on Linux) guy myself, but I cannot let go of what MAME / MESS are all about either. It's a different objective than the targeted emulators, and perceived perhaps a bit too aristocratic... but it has steady, regular progress. And until this new VICE 2.2 release this past Christmas, IMO, it ran better than VICE 2.1 on a modern OS and hardware.

[gklinger]

Anyone actually use g64 format for a specific title?

The first thing that comes to mind is Portal (on the 64) because even after all these years there still isn't a good crack.

[Mayhem]

For the C64, yeah there's loads of titles available on G64, usually added in the extras for GB64...

[etabeta]

Hi,

I just registered to let you know that d64 support has not been dropped at all, only on hold while the code gets updated.

past d64 support (and actually the whole past commodore floppy emulation) was a huge hack which worked just by chance (and indeed it was failing on around 50% of c64 demo disks)

the new one is very accurate (and a bit more demanding in terms of CPU power) but had the disadvantage that d64 support had to be rewritten

g64 was very easy because it contains gcr raw data, d64 requires some more work (which is currently in progress).

everything should be ok for 0.137.

btw, in 0.136 the whole vic20 emulation has been improved and we would like to have some feedback. is there any known issues for vic20 in 0.136?
Feel free to report issues on other Commodore machines as well, if know any.

Notice that there was a known problem with quickload of .prg files, but this has been fixed (you can test the latest updates by using the daily builds at http://bobz38.free.fr/mess_autobuild/index.php )

[rhurst]

Thanks for that update (and for registering)!

I've certainly noticed the improvements made to Commodore 8-bit emulation within MESS this past year; it did come as surprise when the 0.136 release came with some obvious broken items coupled with new requirements. And you took the time to explain that mostly on the sdlmess forum. Keep up the good work!

I am looking forward to the 0.137 release. Meanwhile, my curiosity is piqued towards the attention given this g64 format.

[etabeta]

as you may have noticed, latest svn code contains back the d64 support (thanks to Curt Coder, which took my incomplete old code and turned it into a fully working floppy emulation)

feel free to test progresses by using the build from

http://bobz38.free.fr/mess_autobuild/index.php

and to report any problem you experience (with this or other Commodore machines)