Large Drive CBM DOS Mapping Proposals
in [Commodore]
|
From: Jim Brain on 14 Apr 2008 23:20 In the beginning, there were 170kB drives, with 1 head and 8 bits were used to hold track and sector values. Then, came 500kB disks (8050) and the rules still held. The 8250 and SFD1001 did not break the rules. Later, CMD HD came along and played by the same rules. 255 tracks of 256 sectors, each with 256 bytes of data. The 16MB native partition was born. CMD HD units also used unit number to represent what we now call a HD partition, permitting 255 partitions, raising the maximum referenceable disk space to 4GB or so. But, times have changed and drives now have 200GB or more on them. I'm reading up on IDE64 DOS commands for block level access, and have been looking at the proposed CMD HD DOS+ solution to creating sector addressable partitions, but I'm interested in ideas from the community. Some questions: IDE64 appears to forego emulating the older DOS addressing commands in favor of new ones (B=*), while HD-DOS+ appears to add a new byte to the existing command syntax. One offers a clean break, while the other offers more compatibility. Does anyone care? If so, which is preferred? Commodore drives contain 256 byte sectors, but newer drives all standardized on 512 byte sectors. One favors compatibility, the other favors ease of firmware development. Should a drive represent a disk in 256 byte sectors, or 512 byte ones? Newer ATA-based drives can access 48 bits of sectors, and each sector is 512 bytes in length. Assuming 512 byte sectors, and assuming such a disk is split into 255 partitions, that's 40 bits or 5 bytes of data needed to reference a location on disk. Currently, DOS commands allow T&S&buffer pointer. Do we add 1 or 2 more bytes? Are there other areas to consider? Someone suggested using u0>h1 and u0>h0 to offer other ways to increase reference space. Do we really need to worry about it? Are 16MB partitions large enough? If not, what is large enough? 4GB? Jim
From: ramswell on 15 Apr 2008 01:43 On Apr 14, 8:20 pm, Jim Brain <br...(a)jbrain.com> wrote: > In the beginning, there were 170kB drives, with 1 head and 8 bits were > used to hold track and sector values. > > Then, came 500kB disks (8050) and the rules still held. > > The 8250 and SFD1001 did not break the rules. > > Later, CMD HD came along and played by the same rules. 255 tracks of > 256 sectors, each with 256 bytes of data. The 16MB native partition was > born. CMD HD units also used unit number to represent what we now call > a HD partition, permitting 255 partitions, raising the maximum > referenceable disk space to 4GB or so. > > But, times have changed and drives now have 200GB or more on them. VERY TRUE! I for one, would be interested in seeing a Hard Drive (or at least something "like it") created that could utilize spaces of at least 50 GB or more (200 would be great). > > I'm reading up on IDE64 DOS commands for block level access, and have > been looking at the proposed CMD HD DOS+ solution to creating sector > addressable partitions, but I'm interested in ideas from the community. > Some questions: > > IDE64 appears to forego emulating the older DOS addressing commands in > favor of new ones (B=*), while HD-DOS+ appears to add a new byte to the > existing command syntax. One offers a clean break, while the other > offers more compatibility. Does anyone care? If so, which is preferred? Although ease of use is "extremely convenient," compatibility ends up being the MAIN FOCUS of the vast majority of the applications that I mess around with over here. So I vote for "compatibility." :) > > Commodore drives contain 256 byte sectors, but newer drives all > standardized on 512 byte sectors. One favors compatibility, the other > favors ease of firmware development. Should a drive represent a disk in > 256 byte sectors, or 512 byte ones? > Well which ever is more compatible would be my guess. > Newer ATA-based drives can access 48 bits of sectors, and each sector is > 512 bytes in length. Assuming 512 byte sectors, and assuming such a > disk is split into 255 partitions, that's 40 bits or 5 bytes of data > needed to reference a location on disk. Currently, DOS commands allow > T&S&buffer pointer. Do we add 1 or 2 more bytes? > > Are there other areas to consider? Someone suggested using u0>h1 and > u0>h0 to offer other ways to increase reference space. That sounds like it may work. Has anyone actually TRIED IT on any drives other than the 1571? If so, I am curious as to what results they came up with in their attempts. Could you share your experiences with us if you have tried please? > > Do we really need to worry about it? Are 16MB partitions large enough? > If not, what is large enough? 4GB? 4GB? WOW! 16 MB are "sufficient" for nearly all apps that the vast majority of us have any use for, however, for developers, engineers, and R&D reasons, I vote that you make them at least 2.5 GB just to make sure. ;) Thanks for this EXCELLENT POST, Jim!!! Charles > > Jim
From: Pheuque on 15 Apr 2008 04:53 The more I think about it, the more I see compatibility as the problem. We're risking the future of the Commodore 64 for the legacy of the Commodore 1541. Really, which was the more important part? As I understand it, compatibility issues come from 2 major points. Speedloaders, and copy protection. Remove those from any program, and the job of accessing newer storage becomes much easier. THAT is precisely how we should be handling this. Look at the files stored on the DTV. Their CP and fast load code was removed to make THEM compatible with the DTV. How much longer can we hope to support 5.25" disks? More importantly, WHY should we? Even virtually? In a very few short years the ferris oxide on the oldest disks will be irretrievably corrupted. We should be re-writing these programs to work with the available hardware, not designing hardware to work with protection schemes, and turbo routines designed to overcome the shortcomings of a bygone era. What piece of software for the Commodore 64 can't be rewritten today, even if it's from the ground up, to take advantage of any hardware we can create? We only need to fix the program ONCE, and it will be able to run forever. But there will be newer and better storage long after the last real MOS chip has failed. I say dump compatibility. It's just holding us back. It's not good for the real hardware, and it's not good for the emulators. Todays internet access is faster than even an REU. We should be working on something like an IEC Ethernet adapter that can access information from a NAS or the internet. Thats my opinion.
From: larry on 15 Apr 2008 09:54 .... > Do we really need to worry about it? Are 16MB partitions large enough? > If not, what is large enough? 4GB? > > Jim Large drive apps: From my experience the ony two main applications that ever used a lot of the drive's capacity were BBSs and GEOS. BBSs usually did a thier work on the file level (some exceptions Image did some DOS tricks to detect drives) and rarely did direct block access. Though many of the variables for drive operations were integer (0-32767) BBSs usually run under very tight memory so there is a limit to how much they can cache in RAM... GEOS I'm not very familiar with but from my few times playing with it it is very dependent of specific drive compatibility having a 1541/71/81 or CMD format mode support would be good (also for the game players). Using Large Drives with new programs: If you make a new program and want to use a large drive (and iIEC is affordable) you probably would want to implement whatever needed to be implemented, though keeping it close to how CMD or CBM did theirs makes life easier on the programmer. Sticking point - Large Drive Navigation: I have a couple CMD HDs, and use them for work now and again, though the DOS is pretty easy to use I have to remember partition numbers to jump to my work directories leaving zero as the current partition was a good move on CMDs part. If I were to make a meta-DOS (like CMDs partition system) for navigating the many partitions I would try to make it a directory/sub directory tree... with partition names, something like (examples via a DOS wedge): @$$/ (root) 99 "MEDIA" -- "GRAPHICS" -- "GAMES" -- "WORK" -- "COMMUNICATION" xxxx MB FREE then switch with: @CP/GAMES @$$ (list current meta directory) 99"GAMES" -- "DRIVING" -- "ADVENTURE" -- "BOARD" -- "ARCADE" -- "SIMS" etc, then when you get to the 'directory' you can mount it locally, using CP or whatever. then again having the partition numbers are real good for BBSs... hmmm I dunno. The other thing is having the drive accessible in some non-commodore usable format, as you have mentioned with uIEC using FAT system is a great move, makes the need for massive transfers via X1541 cables less necessary. In general whatever you do I expect people will buy, because there is a lack of CMD drives (also smallish SCSI HDs are getting hard to find) and many of the others do not sound as usable as the uIEC. Larry
From: BruceMcF on 15 Apr 2008 11:56
On Apr 14, 11:20 pm, Jim Brain <br...(a)jbrain.com> wrote: > IDE64 appears to forego emulating the older DOS addressing commands in > favor of new ones (B=*), while HD-DOS+ appears to add a new byte to the > existing command syntax. One offers a clean break, while the other > offers more compatibility. Does anyone care? If so, which is preferred? The focus within a native partition should be on emulation ... a clean break in managing partitions and large partitions is fine. The argument here would be that where emulation is handy is when using a legacy code base that benefits from having a larger diskspace to work with. And, indeed, sometimes that legacy code will already include some CMD support, since CMD drives would have been the most common way to get that larger diskspace to work with. But if its legacy codebase, then 16GB is ample. And even then, managing the current partitition was mostly for the user to do: (1) if there is a full screen menu system to do that, it doesn't really matter in use *what* the partition commands are, and (2) if the user has to sneak one of those commands through a drive command option in a program, easy to use and easy to remember are more important than "the same way as 1985". On the other hand, if its something new, taking advantage of the fact that there is massive storage in a cheap SD or CF card to allow doing something that would have been impossible or impractical "in the day", the important thing is ease of use. And then progressively more work is required to maintain backward compatibility with progressively less code in the code base and represented by progressively less actual original hardware actually available ... I think working beyond a single current native partition is a good place for a clean break. > Commodore drives contain 256 byte sectors, but newer drives all > standardized on 512 byte sectors. One favors compatibility, the other > favors ease of firmware development. Should a drive represent a disk in > 256 byte sectors, or 512 byte ones? > Newer ATA-based drives can access 48 bits of sectors, and each sector is > 512 bytes in length. Assuming 512 byte sectors, and assuming such a > disk is split into 255 partitions, that's 40 bits or 5 bytes of data > needed to reference a location on disk. Currently, DOS commands allow > T&S&buffer pointer. Do we add 1 or 2 more bytes? If its going to be used by a 6502 based system, it should be 256 bytes per sector, or else sectors sized to a convenient slot in the C64 memory map ... 2K is good, it fits two sectors (source, target) in the 4K Golden RAM slot ... equally handy whether working in Basic or reserving the space in an assembly language or C program. With a 10 bit offset into a 2K sector as a basic unit, (2K-1) tracks of 2K sectors, each with 2K data is just under 8GB (just under 8GB true, 8.5+GiB). That's ample, and allows buffer, sector and track routines to share common routines to pack and unpack the value and a chunk of up to six status bits into a 16-bit integer. As an added bonus, a next track and sector in a traditional linked sector arrangement will occupy four bytes of 2K, or less than a byte overhead per 256 bytes, meaning a traditional DOS sequence of tracks can be virtualized as 8 chunks of 254 bytes each, with the "next track / sector" emulated as the next chunk in the 2K sector or first chunk in the next 4K sector, with additional 12 bytes of header/work room to spare. When working with microcontrollers, a little spare work room in the basic data buffer is always handy. If the disk is too large for the actual partition table to hold the desired number of CBM-DOS partitions, create a partition that contains just virtual partition information, and present additional partitions to the CBM-DOS. Then there is never any *need* to have any partition greater than 16Mb ... a "large sector" partition would be purely by *want* to, rather than *have to*. Then, with the ability to locate any DOS comment inside a given partition, its only the partition creation API that has to be able to reference a specific location in the disk. And, indeed, that mostly involves writing the virtual and real partition creation utility for the new gear with an eye to easy re-use in different gear in the future, so that people re-use that API because its easier than rolling their own. > Are there other areas to consider? Someone suggested using u0>h1 and > u0>h0 to offer other ways to increase reference space. If the partitions are named (they do not need to be a hierarchy ... just, as with the Zsystem upgrade to CP/M, named, with an ability to list the partition directory), then a way to refer to that name is all that is needed for cross-partition references. If CMD directories are used, then a way to specify a partition name that cannot be confused with a CMD directory name would be sufficient. Most of the time you'll be working within one and won't need even that. > Do we really need to worry about it? Are 16MB partitions large enough? > If not, what is large enough? 4GB? As above. 16MB partitions are large enough for anything sane, 8Gb ought to be enough for even the insane. Then basically as many named partitions as you are going to want to work with ... since named partitions are not a legacy feature to support, keep that simple, just a flat namespace. |