Hi guys! Ruud wrote: > So my first question to you is to give your opion about the 3 ideas and feel > free to add even more! I also played with the idea of the IDE stuff. Interfacing the drive to the C64, like the Czech guys did, may give the best performance (when performance = speed). Disadvantages: no fastloaders work, even no copy-protected stuffs work; the other, but for you, maybe it's not just a serious problem: the interface depends on the C64, you have to build another one for your other C= machines. Also, you lose hw compatibility with C64 cartridges (like the MK7). I didn't play with the thought of the server, 'cos you can get an XT or a 286 easier and use as server with no hard worx on the filesystem at all. I'm with the idea of using an 1541 wreck and use the digital board, the PS and the case for the hdd. You can expand the original board with RAM, ROM and a portchip easily (if needed), you can keep all 1541 properties. So you can make your business about 99.99% compatible to the original 1541, even using the HDD instead of the floppies. Since it's just a hacked 1541, it works with all computers supporting the serial IEC bus. Talking about the filesystem: I'd use a FAT-like system, just to make things easier. Maybe, I'd use a FAT-32 like stuff because of the many and small files. Or you can decide with the CBM like scheme, to allocate a big bitmap on the first blocks of the HDD as BAM and use daisy-chain linked file blocks. You can also create an 1541-like root directory with similar records. You have to use 512 byte long blocks, of course... Since it would be quite awful to use 16M long partitions, just use block lengths and other parameters as they're needed for a reliable and powerful (expandable) filesystem. You also should take care about marking bad sectors (maybe, with using two bits per block to sign if a block is free, allocated or bad?). This means about 4 or 8 megs when using a 2 Gig HDD, but who cares? ...It is worth it, because of the much and small files, not to mention that you don't have to play with the logical addresses and clusters. Try to create a standart HDD header, I mean the master boot record and the partitions table. Create a signbyte for the Commodore HDD partition :-) ...Maybe, CMD have done that? ...But from the other hand, if their partitions are limited to 16M, maybe you should re-invent the wheel, regardless to the precedessors. ...If I'm right, the Czech's created a good filesystem, maybe better than CMD. It's no question, the filesystem should have subdirs. I guess, a subdir is a regular file, which links into a rootdir like structure. ...I don't know, Commodore and CMD just did. You should contact the guys above (Doug Cotton at CMD, I don't know the other guy but you can find the contact addr on their homepage). ...Since they're business companies I don't know if they'll help. But from the other hand, if they don't, it's just their problem. Of course, any old programs supporting direct block read/write commands would go mad when applying onto this filesystem. However, you have the option to treat special filetypes (regular 1541 disk images) on the HDD as subdirs too. When being able to not just copy, but even CD to an image file, your DOS can emulate a normal 1541 disk (as long as you're in the image), all with the appropriate parameters, even low-level things like GCR codes. All depend on your program, and on the image files you use. Because of the image files, it would be possible to use not just 1541 but any type and kind of C= floppy images. This is where my idea of a flexible disk image format comes in. ...Heh, I won't blame you with this matter, when in phase of just setting up the drive. But this is an option. And it is possible to implement later, keeping in mind that we can treat image files as subdirs. The filetypes should be stored in the regular 1541 filetype sign-byte. The subdir type may have been just defined, but all others types should be marked using this too. Since you have the 1541 board (and the DOS 2.6), you also have the option to keep as many original 1541 DOS routines as you like. This not only helps you being compatible with the 1541, but also helps you not to implement obvious, but hard pieces of the code. You have a complete implementation of channels, file-handling, command-parser and so on! You just have to tie your work right, to the right places (to substitute the original lowlevel routines). Of course, this results in a 'worldwide spaghetti' code. Connect your routines into the original 1541 DOS by rewiring/placing absolute jumps and similar things (but modifying as few bytes of the original code as possible). This way, all original fastloaders will find the same routines as found in a normal 1541, and if your routines do right, they'll work too. The key is, to present the same functions in the same places as found in the original 1541 DOS. (This also gives you a chance to tie your routines to a modified - speeddos like - 1541 DOS easily). (Of course, it would be also a question of an at least 32K Eprom replacing the original, then all of your routines could reside in the expanded area (instead of scratching anything from the original DOS). There is fortunately, no problems with this extension, as there is fairly enough place to use in the memory map). I disagree with Marko: when speaking of C= hardware hacks, and not business, I see indeed sense in interfacing a HDD to the CBM. ...At least, you have to find something to die in ;-). I prefer using C= like devices, if the subject is C=, I hate to use old and noisy PC's for my work, be it any subject. Me too, disagree with implementing any filesystems depending on image file formats and 16M limits. Good luck, and don't forget to send reports to the list! (I don't know if I can help you, I don't know if you need my help at all, but let me know if so.) Levente Ps. I have an OC118N drive wreck, which I guess is ideal to house a small HDD. So be aware... I'll be one of the first persons re-building the stuff. - 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.