Re: P00-format + new D-format

From: Levente Harsfalvi (
Date: 1998-10-10 17:23:57


On Sat, 10 Oct 98 10:42:51 GMT, (Ruud Baltissen) wrote:

> Your remark also remembered me about a question I wanted to ask. The D64-format
> limits you to 35 tracks with 21 or less sectors. Server64 which I'm working on
> right now supports D64.

What about defining a new Commodore disk image format?

In fact D64 is simply crap just on the start, since its name relates the
whole shit to 'c64' while it should rather be related to '1541' or
'Commodore' or whatever.  ...I mean the disk image format is not part of
the c64 subject, even if people utilized 1541's for their c64's most

What about a flexible disk image format, with variable parameters?
I mean, if it contained a header, from which the programs could decide
if the image contains X or Y tracks/sectors etc.

Maybe, some presets could be used instead/besides the tracks/sectors etc.
datas, telling if the image is a plain 1541, 1551, 2031, 8050, 8250, SFD1001
etc. image. And the other parameter-definitions could modify this, like it is
seen in reality (I mean, 1541 disk with 41 tracks, 1541 disk stored in
GCR data and etc...). This could be done with storing the preset type,
and registering if one or another modifier is valid and must override
the appropriate setting given by the preset. (So in fact, this
format is as flexible as using no presets at all, but can be handled

> It also should be able to use subdirectories, I only have to threat a file as a
> directory and create an extra filetype for it: DIR. Theoretically any standard
> C64, C128, C16 etc. should be able to work with this filetype.

I guess you should follow the standard of Commodore drives and HDD's.
I don't know if the 8050 or other bigger fdd's can use subdirs, maybe
1581 does, but I know CMD's drives surely, do.

..Does anybody know the actual file/subdir format of the 1581 and/or
a CMD drive?

> I only will have problems with programs executed on the computer who want to
> reprogram the drive to enable a fastloader or for other purposes. To support
> this I have to build a complete emulator and I leave that to Frank :-)

'If you wanna have a fileserver for your C64, buy a Pentium II' :-)
Not a bad idea, anyway...

Once we discussed this with Credo/Resource+Success+TRC. This is quite
a hard job. You not only have to emulate the behavior of the drive, but
you just have to do it in realtime. This is a big-big difference to all
the current C64 emulators who also emulate an 1541, but they can sync the
virtual machines together by software. In short, first you have to run the
whole shit from DOS or whatever single task/single user environment. As
speaking of being precise in the timing, you can't use the system timer
because it is too slow for proper cycle exact emulation (it is running
at about 1.19 Mhz).

We saw only one possibility - to write the emulator 'pseudo time-exact',
I mean, being in realtime with the timing just in cycles where the 1541 DOS
writes or reads one or another I/O bit. Doing this, the system timer
could be used because those longer periods may be well timed by this
cripple timer.

But this also implies writing a very complicated time-optimizer routine.
We gave it up. 

Good luck!...


PS. About the IEEE subject. I remember GPIB was a patent of Hewlett Packard,
and if I'm right IEEE-488 was derived from that. I see a lot of HP
equipments still having GPIB connector, so I seem to think that also,
they should have offered some GPIB interfaces for PC's. If the GPIB and
IEEE488 standards are still hw compatible, why couldn't these interfaces
be used in connecting IEEE drives to the PC, and writing handlers just 
like they're written for the 1541 with X1541 (...and other) cables?

This message was sent through the cbm-hackers mailing list.
To unsubscribe: echo unsubscribe | mail

Archive generated by hypermail 2.1.1.