Ruud Baltissen wrote: > > Hallo Marko, [snip] > > > > The next problem is: what to do with the whole thing? > > > > The German proverb "Good question. Next question?" applies here. I think > > that the programming effort is too big. Interfacing the thing to the IEC > > bus á la CMD's hard disks would be a waste of resources (both design > > effort and computer resources; I agree, the IEC is quite a bottleneck, and old technology, you need to think a next generation interface/protocol to make the drive popular. > The only thing I know is that CMD uses a SCSI-HD and you can connect it to a > standard C64. The Disk controller/host adapter does a great job of IEC usage. You can emulate 1541s and 1581 partitions as well as up to about 16mb 'native' partitions (256 sectors by 254 tracks). There is a parallel interfacing option available if you have a RAMLink ands does speed it up considerably. But without JiffyDOS (a ROM upgrade on the 64) or a RAMLink (which also adds JiffyDOS via-it's cartridge type connection) CMD-HD is just as slow as a 1541 (yuck!). > I only have one good argument: GEOS. I myself are not a GEOS user but a lot of > people turned down my PC-DISK2 because it was not able to cope with GEOS. And I > cannot blame them. I don't mind connecting a HD directly to a C64 but then some > one must tell me how I can fool GEOS to use it. I think my best chance is to > let it think it is at least a 1541 or better. I haven't found anyone yet who > knows how to program a driver for GEOS, then it would be possible to attach the > D16 format as well. I'm sure once you got the interfacing and programming specs out there people will start working on a way to get it in GEOS (especially if it runs REAL fast or has features not found in CMD units)... Fortunately there is the new 'power-user' version of GEOS, Wheels, which probably is better designed to handle new devices. I myself don't use GEOS but would like to see it deveoped for other purposes such as databases, BBSs, and such. > I give you the ideas I'm thinking of (for the moment): > - 32-bits FAT, a cluster = 1 sector. This means you lose 4 bytes on every > sector of 512 byte (= < 1%). > - It should be able to handle disk-images as well as normal files. I think you fall into a trap on both points (inages and 'normal' files) you would not want to be tied down to, maybe leave oan opening for an expansion option - so you can keep the thing lean and mean, that is unless you want the backward compatibility. It would also let the deveopment time of a decent emulator surpass the development of the core technology and probably return a better 15xx, 8x50 emulator in the long run. > - The OS of the drive should be able look for a "boot program". In this way you > can patch the original OS. But then extra RAM is needed. Booting would be nice. You would have to have a ROM patch or a cartridge. My thooughts: I dream of seeing something (not this exclusively) externally accessible by other computers (and fast), if possible. So you can load it up from a Mac or IBM, or even share via other 64/128s (like the multi-plexing of the Lt. Kernal) I'm not sure what could be done, it's just that cross-computer accessibility is a big problem for those who have several platforms around. A CD ROM access would be nice too. To sum it up, make it really fast, don;'t hold yourself back with compatibility, but don't make it too hard to program. And if you could make it (drive or format) cross/multi-accessible with other computers using IDE controllers, even better! - 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.