Hallo Marko, > > Now the testing phase starts. FYI, it is built with 7 common available ICs. > > Congratulations! It is extremely important that there are no programmable > logic chips or other chips that are difficult to obtain. It seems my son of 3 years old can better count than me: it are only 6. I'm sorry for any inconvenience. > > 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; The only thing I know is that CMD uses a SCSI-HD and you can connect it to a standard C64. > DMA transfer to the memory of the C64 would > be much faster), but it would ensure maximum compatibility (except with > fastloaders and copy-protected stuff). > I suggest that you use André Fachat's OS/A65 as a base for the system. If I have to use an extra computer anyway, then why not an obselete 1541 or 1571. IMHO I only have to change the SW which handles all operations regarding the disk. > Didn't he already have a filesystem implementation? Andre, do you? > Emulating 1541-like > or 1581-like disks is not an option, since the maximum would be 255 tracks > and 256 sectors, which is less than 16 megabytes. It sounds like my D16-format I last mentioned :-) > As someone recently > pointed out in comp.sys.cbm, it's not nice to divide a 4-gigabyte hard > disk to at least 256 partitions. Nonsence! Just think how an emulator uses his emulated 1541. In reality you tell it to use a simple file as floppy. You want to change the floppy, you change the file. The same you do with the HD. Anyway, partitions are things used by MS-DOS (and later by other OS like LINUX ;-) ) so it had a way to handle more disks. My new PC-DISK is (should be) capable of handling 20 disks of every format you choose (1541, 1571, 1581, 8050, 8250, D16). It is also capable of "changing floppies" by simply using another file. > In my opinion, interfacing a hard disk directly to the C64 doesn't make > sense, except if you are religious about it and want to do without a PC. > Speaking of which, last year you and Frank were playing with the thought > of connecting the C64 to a PC with DMA, so that the PC can access RAM and > I/O in the C64 address space without requiring any software to be > downloaded to the C64 first. I'd like to see something like that in > action. 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 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. - 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. Groetjes, Ruud - 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.