Hi! On Sat, 10 Oct 98 10:42:51 GMT, g.j.p.a.a.baltissen@kader.hobby.nl (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 frequently. 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 easier). > 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!... Levente 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 cbm-hackers-request@dot.tcm.hut.fi.
Archive generated by hypermail 2.1.1.