Hi Gang! We made a small discussion with Ruud in private e-mail in the last two weeks, and he asked me to write and post the results to the list. Part of the discussion was on/about the actual filesys of the HDD. Some of the results may appear or may match the facts Ruud described in his documents sent to the list a few days ago. Guess I have nothing to comment on this part. I guess I have more to talk about the 1541 emulation and the disk image handler part of the HDD controller. - We're so stupid, but we expect the HDD a lot of 1541 compatible features. - No surprise, the 1541's own filesystem is too small, simply unable to use as main filesystem for a HDD. The useability of the HDD and it's filesystem is much more serious than the need to be compatible with the 1541. From the other hand, if we don't follow the structure of the 1541 filesystem, we'll definitely lose compatibility with most of 1541 dependent software. That's it. But it's obvious. - The solution is, to use regular disk images. How, and why to do this? - No surprise, the HDD's own filesystem must have subdirs. Since our OS know what CD, MD and others are about, we have an option to treat anything like a subdirectory. Say, we copied a .d64 image to the disk, like a regular 683K long file. We can make our OS to pretend like changing into a subdirectory when the user applies a "CD imagename.d64" command. This subdirectory has actually the contents of this disk image. - Since our OS knows where it stays in the directory structure, it gives us the chance to implement "context sensitive handling". That is, we can decide which part of our OS is in action when staying at the main filesystem or inside a disk image in the directory structure. In other words, a complete disk image handler can be written, which works completely independent from the HDD's own filesystem. ...When working with the HDD's own filesystem and files, the main filesystem handler / command parser is in action. But when inside an image, we can tell a different program, an 1541 emulator to work. This means both handling of files like the original 1541, but also the low-level commands and other funny stuff. So we can more or less perform hw-like 1541 compatibility when working inside an 1541 disk image file. - When speaking of disk images, one thinks 1541 is good but there are a lot of other floppy drives too, all with the appropriate image formats. What about these? - .d64 should be supported, that's no question. However, there are problems that d64 can't solve. Also, for the other drives, image formats could be described for each. - Here comes my point. This is just an earlier idea of mine, to describe a versatile, parametric disk image format. This was invented because I thought there is no correct Commodore disk image format around (if so, it's not capable of everything a CBM disk could contain). Here's a rough scheme (it's just the start). It's quoted from the letter I wrote to Ruud. -------- format ----- >- Header text, in ascii encoding. Commodore disk image format, or >whatever. Not serious. But fixed size, maybe 16 bytes. > >- Image type preset byte, the type of the drive the disk was created >from. > - 0:unavailable, see datas below on the disk params > - 1:1541 disk and compatible > - 2:1571 disk and -"- and so on > - ... > - ... > >It's also considerable if we create own types even for partially >compatible drives, for example, for the 1541 and the 1551 (and maybe, >also the 4040). Just because it's more beautiful, correct, and 255 types >are enough for a lot of different drive type numbers. (And at least, the >1551 uses different interleave than the 1541). > >- Image params present flags, one byte. > bit0: extended param flags byte present > bit1: Number of tracks byte present > bit2: Number of sectors per tracks table present > bit3: First BAM track number present > >- Extended parameter flags, only if IPP bit0 is set > bit0: the sector datas are in normal (0) or GCR (1) encoding. > bit1: single density (40tpi, 0) or double density(80tpi, 1) disk. > bit2: number of sides (0 or 1) > >- Number of tracks, one byte, only if IPP bit1 set. > >- Number of sectors per tracks table, only if IPP bit2 set. > This table has the following format: > Number of records (one byte) > BOUND1_low BOUND1_high NOS1 > BOUND2_low BOUND2_high NOS2 > ... > ... > > NOSx: number of sectors, at the xth area. BOUNDx_low: start, >BOUNDx_high: end tracknumber of an area with the same sectors/track. One >byte each. > >- First BAM track number, only if IPP bit 3 is set. >This is neccessary, if I want to be fully independent from the type >preset byte. > >byte# ((filepos+512)div512)*512 >- Sector data, sequentially, in order, sector to sector, track to track, >side to side. >(Each sectors are 256 bytes (normal) or 512 bytes (GCR) long). > >Some comments. If the image type preset is known, the handler must know >the default parameters for the image. So, if it is set to 1541 type, the >handler must know that it is single sided, single density, 35 tracks and the >appropriate sector/track numbers and boundaries and so on. Even if no >more info is present, the image is correct. > >However, if the image is, for example, from a manipulated 1541 disk, >it's still easy to go. Say, the image has 41 tracks. First the type >preset should be still set to 1541 (the defaults are then known). Then >set IPP bit1 (number of tracks present), set IPP bit2 (number of sectors >per track table present), then number of tracks byte (41), an "1" byte >(1 records in the sectors/track table), 36 (start), 41 (end), 15 (number >of sectors in this area). Voila'! We created and handle a non-standard >image type quite easily. > >Other. The GCR encoding won't need this 2* the normal size overhead (320 >bytes instead of 512 would be enough). Maybe it would be even better to >use the more compact 320 bytes per sector model. But from the other >hand, it's more difficult to code, decode and handle packed GCR data >streams (as long as our GCR to byte decoder is not optimized to decode >whole blocks). ...Well, it's not much serious by now. > >(This GCR thing would also need a closer check. As Frank pointed out, >we'll be in trouble if we can't present the GCR nybbles easily. I think, >the Warp-like (maybe, even Gigaload-like) fastloaders will all hang, >because they need the drive data to be given in GCR format. That means, >the HDD should emulate the 1541 even at the GCR encoding level, >regardless of the actual data type on the HDD. That's hard. ...It won't >be a problem if we could hook the routines which read from $1c01, but >this is not a good way because these accesses are also used to be inside >tight timing loops. ...So we can either abandon using GCR at all, or >find something to solve the problem. ...Maybe, a second 6502 would do? >:-)). ...Should I suppose, that Frank knows a lot more about this GCR >encoding/decoding process. > >Even if the preset byte is not used, I mean, the image was generated >totally independent from any existing drives, the handler would still >work with any images, provided that the parameters are set in the header >of the image. > >(I suspect if the directory structure should be described better, since >different drives also use quite different directory formats. But this >time it is just a rough scheme. It can be completed later, in this >style). > >...The only problem I see, it's just a bit more complicated to look for >a block in the image than in a d64. ...Not much, provided that we can >seek in the image file. > >That's what I called a versatile image format. > ------- format descript ends --- After writing the scheme and reading some docs on image formats, I realized that my format is quite like X64, the disk image format of VICE. ...But reading it's specs, seems like it doesn't solve all problems I'd like to be solved (like the main feature, to create and handle non standard disk images easily). This preview is just a very-very rough scheme. It's only the style I wanted to show. The main idea behind this, to make the whole image handling in the HDD OS parametric, so, with giving parametric data on track#, sector# and other datas the emulator will work regardless to the fact that the disk was created from an 1541 or a 8250 disk. The other part, to find an appropriate fileformat, to store the disk data most easily, with the less possibility of bad parametered images and with the less parametric overhead. Guys, any idea on this are welcome. I mean, I'll collect and organize the fileformat, the list of the original floppy drives and other stuff, but I'll be definitely in trouble when collecting info on for example, the sector header format of the 2031 and the other drives (maybe, even the 1541 if I don't get my books back). Also, info on the old CBM hard drives, and the other, the big CMD floppy drives filesystem and track/sector system would be welcome. Merry Christmas, ...Boldog Karácsonyt! Levente - 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.