Jump to content
IGNORED

IDE Plus 2.0 - preorder starts today


drac030

Recommended Posts

I really don't understand how the GUI will work, but my hope is that it runs stand-alone, and an API will provide hooks to other applications (like SDX, hard disk, etc.) so that we can see the gui work before other 'requirements' are fulfilled. The sooner someone figures out how to flash the GUI demo on some kind of rom cart (like the XE super cart) the better :D

Link to comment
Share on other sites

I really don't understand how the GUI will work, but my hope is that it runs stand-alone, and an API will provide hooks to other applications (like SDX, hard disk, etc.) so that we can see the gui work before other 'requirements' are fulfilled. The sooner someone figures out how to flash the GUI demo on some kind of rom cart (like the XE super cart) the better :D

I'm rebuilding the whole thing to run on a cart as we speak. Of course, this may mean I lose half the "casual" user base, but on the other hand at least it means it won't be a half-baked, lumbering POS. The point about support for SDX and such like is that it needs to be there, and it's a juggling act to support fancy hardware and the features of advanced DOSes while keeping everything backward compatible with the lowest common denominator. However, it's a fact of life that many intelligent, sane people will quite rightly want to use it with DOS 2.5. :)

 

Anyway - back to the IDE Plus. :)

Edited by flashjazzcat
Link to comment
Share on other sites

 

Maybe there is a chance to implement an option in the firmware to let the user choose if he wants to waste space and gain speed?

 

ON other PBI devices like the MIO, the wasting space method (using 256b out of 512) actually loses speed - it is slower according to RWTEST.

Link to comment
Share on other sites

ON other PBI devices like the MIO, the wasting space method (using 256b out of 512) actually loses speed - it is slower according to RWTEST.

Because instead of doing a single 512 byte sector transfer and splitting the data in half, the controller is doing two transfers, and moving twice the data (although half will be dummy data register reads/writes).

 

But I'm sure a waste of space option would prove useful for many. :D

  • Like 1
Link to comment
Share on other sites

Yeah, in retrospect, that should have been a PM anywayze. And its not saying anything bad.. I know you DO in fact understand completely.

 

I'm very interested in following the development on this thing, and I know you are too. And I know that you tend to back up things that make good sense. And I also know that Drac030 is a good "listener". .

Link to comment
Share on other sites

ON other PBI devices like the MIO, the wasting space method (using 256b out of 512) actually loses speed - it is slower according to RWTEST.

Because instead of doing a single 512 byte sector transfer and splitting the data in half, the controller is doing two transfers, and moving twice the data (although half will be dummy data register reads/writes).

 

But I'm sure a waste of space option would prove useful for many. :D

 

Its not slower than sector-splitting. Its slower than full native 512byte sectors. Get out your black box and see how slow it is, when using 256byte sectors (it does split the upper/lower half and use all the space). On writes, it gets REALLY slow, because it has to actually load in the existing 512byte sector, append the 256byte sector (to be written) over the appropriate "half" in memory, and then rewrite the 512byte sector.

 

On the MIO, 256 byte sector (half-space wasting) mode is just about exactly half the speed of 512byte native (SDX DD512) mode. This is simply because you are still reading and writing full 512byte sectors, but only actually storing or retrieving data 50% of the time, versus 100% of the time when using native 512byte sector mode. Very simple..

 

If you are comparing the MIO to THIS interface, then you are comparing apples to oranges. SCSI requires more code overhead and is thus never going to be as fast as IDE (on the ATARI), unless theres an embedded chip on the controller handling it.

Link to comment
Share on other sites

Is there a reason why you would want to reduce the need for partitions?

 

I think people are using them to store floppy images (for software that does not run under DOS). This would not be necessary, I guess, if there was a possibility to "mount" a file and assign a drive number to it. But anyway, one does not prevent another, I'll just have to modify my partition table scheme to accomodate to "65536 partitions".

 

Why not make all the partitions the same size?

 

I like freedom :)

 

And, what happens if you overwrite the partition map?

 

I have had a harddisk for A8 since 16 years, did have disk crashes and disk's sudden (and physical) deaths, but I have never ever so far seen the partition map trashed.

 

But, if this happens, I would then either restore the settings from memory (my disk has 15 partitions, 65535 sectors each, so it is fairly easy to remember), or I'd restore the partition table from backup.

 

If the latter, then when SDX breaks that 65535 sector limit, the BIOS in your IDE Plus 2.0 won't understand it.

 

Why?

 

The KMK firmware supports "splitting" of 512-byte sectors into upper/lower 256-byte logical sectors for use with 256 byte/sector DOSes.. This allows DOSes other than SDX to use all the space on the drive, rather than wasting half of it by only using the first 256 bytes of each 512byte sector.

 

I am afraid you're wrong here. The old firmware (IDEa BIOS, v. 1.x) indeed did that. But I have given this up. The IDE+ 2.0 firmware always maps sectors 1:1, i.e. always the entire 512-byte sector is used for sector data, no matter if DOS sees it as a 128, 256 or 512-byter.

 

The result is that DOS-es other than SpartaDOS X 4.4 waste space. There is a significant speed gain, though. If space is important (like on a 32 MB CF card), I can prepare a "downgrade" program, which flashes the legacy firmware into the ROM.

Link to comment
Share on other sites

If the latter, then when SDX breaks that 65535 sector limit, the BIOS in your IDE Plus 2.0 won't understand it.

 

Why?

 

Does it understand larger partitions now? If not, then it won't understand them when SDX breaks it. Presumably an upgrade would happen thereafter, but should we have to upgrade our upgrades every time a new version of SDX comes out?

Link to comment
Share on other sites

Does it understand larger partitions now?

 

Yes. In fact, the firmware supported 512-byte sectors and 8 GB partitions from its very beginning in 1995. And yes, accessible via SIOV (see the programming section of the KMK/JŻ IDE manual).

 

IDE Plus 2.0 firmware supports 2 TB partitions (in theory, because LBA addressing the disk uses provides "only" 28 bits for absolute sector number, therefore the disk cannot be bigger than 128 GB). And yes, this is also accessible via SIOV (see XDCB.TXT distributed in the latest update archive).

Link to comment
Share on other sites

If all the partitions on every drive were the same - 256 small (1MB) and 16 large (16/32MB), then you would not need a partition table. You would not have to consider such things as fragmentation and losing your partition map. The largest non-HD diskette is 720K and the maximum sector count is 65536. Other that the wasted space, those are all you need. (this assumes a CF card setup)

 

Yes, I've been doing HDDs for quite a while and I've never overwritten the partition table because I don't keep it on the drive. It stays in non-volatile memory. (this is why I have a little program that will scan a drive for all partition values...) I started out with configurable partitions, but after accumulating *many* CF cards, I find that I tend to use just the two sizes - actually, just the small size.

 

Seems like to me, freedom is not having to hassle with building a partition. The code sure is a lot simpler.

 

Bob

 

 

 

Is there a reason why you would want to reduce the need for partitions?

 

I think people are using them to store floppy images (for software that does not run under DOS). This would not be necessary, I guess, if there was a possibility to "mount" a file and assign a drive number to it. But anyway, one does not prevent another, I'll just have to modify my partition table scheme to accomodate to "65536 partitions".

 

Why not make all the partitions the same size?

 

I like freedom :)

 

And, what happens if you overwrite the partition map?

 

I have had a harddisk for A8 since 16 years, did have disk crashes and disk's sudden (and physical) deaths, but I have never ever so far seen the partition map trashed.

 

But, if this happens, I would then either restore the settings from memory (my disk has 15 partitions, 65535 sectors each, so it is fairly easy to remember), or I'd restore the partition table from backup.

 

If the latter, then when SDX breaks that 65535 sector limit, the BIOS in your IDE Plus 2.0 won't understand it.

 

Why?

 

The KMK firmware supports "splitting" of 512-byte sectors into upper/lower 256-byte logical sectors for use with 256 byte/sector DOSes.. This allows DOSes other than SDX to use all the space on the drive, rather than wasting half of it by only using the first 256 bytes of each 512byte sector.

 

I am afraid you're wrong here. The old firmware (IDEa BIOS, v. 1.x) indeed did that. But I have given this up. The IDE+ 2.0 firmware always maps sectors 1:1, i.e. always the entire 512-byte sector is used for sector data, no matter if DOS sees it as a 128, 256 or 512-byter.

 

The result is that DOS-es other than SpartaDOS X 4.4 waste space. There is a significant speed gain, though. If space is important (like on a 32 MB CF card), I can prepare a "downgrade" program, which flashes the legacy firmware into the ROM.

Link to comment
Share on other sites

I'm having a terrible time with the interface. I am attempting to setup the disk with FDISK2 but I can't even get it to load. here are the steps I'm using

 

SDX set to OFF

IDE+ bypassed

Utility (sparta) disk mounted as D1 on APE

 

Turn on 130XE and it boots to Spartados 3.2d

 

type DIR and sometimes get a full directory listing prior to it hanging the machine

if it does do a full DIR I type FDISK2.COM and it hangs the machine.

 

What am I doing wrong?

 

[EDIT]

 

tried with the MYDOS utilities image and the same issue...

Edited by orpheuswaking
Link to comment
Share on other sites

SDX set to On

IDE+ On

Utility (sparta) disk (or MyDOS disk) mounted as D2 on APE

 

Start into SDX and get to the prompt

Change to D2:

run fdisk2.com

 

If you want to boot to the disk, turn SDX off and set the ATR image to D1:, but you need to have the IDE interface on.

 

Also, once you are booted, run the KMKDIAG first to make sure your HDD/CF is recognized and good.

Link to comment
Share on other sites

You would not have to consider such things as fragmentation and losing your partition map.

 

With resizeable partitions I don't either.

 

The largest non-HD diskette is 720K and the maximum sector count is 65536. Other that the wasted space, those are all you need.

 

Let me disagree.

 

Yes, I've been doing HDDs for quite a while and I've never overwritten the partition table because I don't keep it on the drive.

 

I have never overwritten the partition table THOUGH I do keep it on the drive. Could you please tell me what and how could possibly overwrite it?

 

after accumulating *many* CF cards, I find that I tend to use just the two sizes - actually, just the small size.

 

Yes, but that's just you. Different people may have different preferences.

Link to comment
Share on other sites

Yes, I've been doing HDDs for quite a while and I've never overwritten the partition table because I don't keep it on the drive. It stays in non-volatile memory.

I wondered who I'd heard was using that approach. What happens when you remove the media and put a different CF card in? And what happens when you plug the CF card into the PC and want to read the partitions?

Link to comment
Share on other sites

Yes, I've been doing HDDs for quite a while and I've never overwritten the partition table because I don't keep it on the drive. It stays in non-volatile memory.

I wondered who I'd heard was using that approach. What happens when you remove the media and put a different CF card in? And what happens when you plug the CF card into the PC and want to read the partitions?

 

For the latter question, what do you do? Use a specially written program.

Edited by kurtm
Link to comment
Share on other sites

For the latter question, what do you do? Use a specially written program.

Well naturally one must, since there is not yet an Atari filesystem driver for Windows, and besides I assume Bob's partition table does not follow the MBR format. I think we might reasonably take that for granted. However, I was uncertain as to whether Bob's system was already assuming uniform partition sizes. If not, how does one then decypher the content of the disk when it is detached from the partition table in non-volatile memory?

Edited by flashjazzcat
Link to comment
Share on other sites

Whether you assign a very low probability to them or not, you do have to consider such things - unless you have some way to delete a 20K sector partition in the middle of a table and then use that space in a 65K sector partition? If the hardware can reach any sectors that contain partition data, it can be overwritten. Would you advise anyone not to back up their partition table? You follow 'best practices', I'm sure, but I'm just as sure that lots of users do/will not. I don't have anything against programmable partitions - I just can't see any advantage given the extra effort and liability in them. You should just plug in a new CF card, mount disk 001 (4096 sectors) as D2:, boot from floppy D1: and format D2:, or sector copy to D2:. Or, mount disk 101 (65K sectors)and do that. Why make it any more complicated than that? (not a rhetorical question)

 

As far as I know, all the DOS floppy partitions max out at 720K. 80 tracks, 18 sectors/track, DS/DD. So, you're not going to have a diskette in your hand that you want to copy to your CF card any larger than that. You can put 256 of these on your HDD. You may have very large APE partitions on your PC, so you may need some 65K sector space - you can have 16 of those. CF cards are $15 to $20 each. Are there really users out there that are going to be unable to manage without more space than that? What are we doing to the rest of the base by trying to accomodate them?

 

You disagree that the two partition sizes are all we need? How so? Is there some scenario where we need exactly 16K sector partitions? Is there a diskette format larger than 4096 sectors? I don't have any aversion to allowing a third or fourth attribute - I just want it to be as simple as possible and still get the job done.

 

How could I overwrite the Partition Table? With my trusty little ED/ASM cart? If it is on the CF card, I can reach it, can't I? Maybe I do something really dangerous and plug it into my PC/MAC/SUNFIRE2000. Poof.... Bad, PC/MAC/SUNFIRE2000!!!!

 

People may prefer something safer and less complicated, if it is offered to them. Heck, these are Ataris!

 

Bob

 

 

 

 

You would not have to consider such things as fragmentation and losing your partition map.

 

With resizeable partitions I don't either.

 

The largest non-HD diskette is 720K and the maximum sector count is 65536. Other that the wasted space, those are all you need.

 

Let me disagree.

 

Yes, I've been doing HDDs for quite a while and I've never overwritten the partition table because I don't keep it on the drive.

 

I have never overwritten the partition table THOUGH I do keep it on the drive. Could you please tell me what and how could possibly overwrite it?

 

after accumulating *many* CF cards, I find that I tend to use just the two sizes - actually, just the small size.

 

Yes, but that's just you. Different people may have different preferences.

Link to comment
Share on other sites

I never plug my CF cards into a PC... might catch something nasty.

 

On this subject, can you control what the PC does to your CF card at the sector level? How do you know that it won't de-frag the card for you? So it will work better... Bad sector re-allocation? Does it do that? If your CF card reader had a problem, would the PC trash your card trying to 'fix' it? Nice thing about the old, slow Atari is that it would take hours to step on your data. A PC can do it in minutes...

 

Anyway, it would be very cool if we could move data on/off the CF card directly from the PC. Can we do that? Wouldn't you need to run the PCs file system on the Atari to do it? In 8K at 1.79mhz?

 

Not being a programmer, I don't have a menu or such for changing CF cards. I actually just read the sticky on the card and enter it manually with the ED/ASM cart. Not very elegant, Im afraid. One more reason to use fixed partitions...

 

I use a HD for speed, not capacity. I have everything on floppy, for the most part - just don't like the wait. I'd love to have a file of all my disk directories that I could search for a particular name or content. You would need a large, fast storage system for that. Don't really need such for printing checks or envelopes in BASIC, do we?

 

Bob

 

 

 

Yes, I've been doing HDDs for quite a while and I've never overwritten the partition table because I don't keep it on the drive. It stays in non-volatile memory.

I wondered who I'd heard was using that approach. What happens when you remove the media and put a different CF card in? And what happens when you plug the CF card into the PC and want to read the partitions?

Link to comment
Share on other sites

Low-tech paper label...

 

If that falls off, scan the card for boot sectors and make another label.

 

My CF cards are MBR-free.

 

Bob

 

 

 

For the latter question, what do you do? Use a specially written program.

Well naturally one must, since there is not yet an Atari filesystem driver for Windows, and besides I assume Bob's partition table does not follow the MBR format. I think we might reasonably take that for granted. However, I was uncertain as to whether Bob's system was already assuming uniform partition sizes. If not, how does one then decypher the content of the disk when it is detached from the partition table in non-volatile memory?

Link to comment
Share on other sites

For the latter question, what do you do? Use a specially written program.

Well naturally one must, since there is not yet an Atari filesystem driver for Windows, and besides I assume Bob's partition table does not follow the MBR format. I think we might reasonably take that for granted. However, I was uncertain as to whether Bob's system was already assuming uniform partition sizes. If not, how does one then decypher the content of the disk when it is detached from the partition table in non-volatile memory?

 

Please, allow me to emerge from my relatively crippled retro-computing world, but... this is the RIGHT question around this discussion should gravitate.

 

In all fairness, Bob-exotics-1200XL proposal is of paramount importance because LONGEVITY is (and must be) an integral component of what is being done around here.

 

However, I really don't want to be messing with drivers, or "implicit" concepts (such as equal size partitions that could be assumed as such). I do want to make sure that any storage resources deployed on the 8bit platform will be effortlessly and transparently handled on PC/Windows, because that is the defacto, every-day life working environment (and the one with most chances of surviving us all).

 

Therefore, and in short, I would humble recommend:

 

1. Storage and data-access encoding to be performed under max-flexibility (and existing) standards / variables (e.g. multiple partition sizes, etc.)

2. Maintain encoding on both read/write media, AS WELL AS non-volatile memory back-up.

3. Immediate, instant access from Windows, with

4. User interface pre-coded with easy, straight-forward choices (or subsets) of the wider, more flexible embedded options.

 

Just my 0.02c

 

F.

Link to comment
Share on other sites

...can you control what the PC does to your CF card at the sector level? How do you know that it won't de-frag the card for you? So it will work better... Bad sector re-allocation? Does it do that? If your CF card reader had a problem, would the PC trash your card trying to 'fix' it?

Without the magic bytes at $1FE,$1FF in sector 0, Windows keeps asking you to format the card. If you say no, it just ignores it, since there's no FS on it as far as Windows is concerned. You can access the card with specialized software, of course (this is the exact approach we use with MyIDE, via Hias' MyIDETool), or with a sector editor in the usual fashion. If the Atari used the MBR partition table format, we could manipulate the partitions, but not the individual files on them without a Sparta/AtariDOS/etc filesystem driver. So really - at the moment the worst thing that can happen to a card is the user saying "yes, please format it" and then doing a few more misguided affirmative clicks.

 

Anyway, it would be very cool if we could move data on/off the CF card directly from the PC. Can we do that? Wouldn't you need to run the PCs file system on the Atari to do it? In 8K at 1.79mhz?

I think it would be better if we ran the Atari filesystem on the PC. It could be done: after all, Windows 7 reads and writes Apple FS partitions just fine using a driver.

 

Not being a programmer, I don't have a menu or such for changing CF cards. I actually just read the sticky on the card and enter it manually with the ED/ASM cart. Not very elegant, Im afraid. One more reason to use fixed partitions...

Certainly, in this case.

 

I use a HD for speed, not capacity. I have everything on floppy, for the most part - just don't like the wait. I'd love to have a file of all my disk directories that I could search for a particular name or content. You would need a large, fast storage system for that. Don't really need such for printing checks or envelopes in BASIC, do we?

I think there are two groups of people: those who want to use a HD on the Atari just like they would on a PC: with nested folders and all the other luxuries that certain DOSes afford. For those people, floppy disks or their SIO2xxx counterparts are just a means of getting data to and from the HDD. Then there's another group of people, who want to use the HDD as a huge array of floppy disks. Personally, I've always felt that never the twain should meet (re: earlier remark: "there's no room for any of that crap in HDD firmware"... though I paraphrase). However, there's no reason why fixed size partitions and/or floppy disk image slots shouldn't co-exist if someone wants to put up and write the firmware.

 

I have to say that Kyle Dain's incomplete MyIDE driver for SpartaDOS X - with a few amendments - was quite adequate for my needs before I sat down and wrote a partition editor for it. It used fixed 65536 sector partitions which were automatically assigned a bunch of drive letters. All the work put into creating a partition table format and editor was effectively to make the package "fit" for public consumption. What a wonderful thing hindsight is...

 

1. Storage and data-access encoding to be performed under max-flexibility (and existing) standards / variables (e.g. multiple partition sizes, etc.)

2. Maintain encoding on both read/write media, AS WELL AS non-volatile memory back-up.

3. Immediate, instant access from Windows, with

4. User interface pre-coded with easy, straight-forward choices (or subsets) of the wider, more flexible embedded options.

I agree about flexibility. If KMK makes the partitions fixed-size, personally I'll be digging the MyIDE cart out again. That's not a practical consideration, just an issue of personal choice. I can only fit a certain number of 32MB partitions on a 128MB card... why should I not be free to make partitions whatever size I want in order to have more partitions within the available space?

 

Another means of backing up the partition table is to stick a copy of it on the last sector of the drive. Hias and I considered that, but dropped the idea when the MyIDE LBA partition table grew beyond one sector in size.

 

Quite frankly, every DOS I ever used has caused me to lose valuable data through a VTOC screw-up/broken file links/scrambled sector map, etc at some point along the way. I never lost data yet through a lost partition table on the IDEa, IDE Plus, or with the SDX/MyIDE driver.

Edited by flashjazzcat
Link to comment
Share on other sites

At the FS level, control rests with data in sector 0. Good. But, what about lower levels that are not under the OS? BIOS and such?

 

Running the Atari FS in Windows sounds great, but won't we then need to expose the CF to the PC FS? (put the magic bytes in sector 0)

 

I'm not sure why the two user 'groups' can't use the same firmware. The Big DOS folks use the 65K partitions and the JBOD troops use the 4096 partitions.

 

I don't think any of this has to either/or. At the hardware level, PBI systems are pretty compatible. You can run any code you want in there.

 

Bob

 

 

 

...can you control what the PC does to your CF card at the sector level? How do you know that it won't de-frag the card for you? So it will work better... Bad sector re-allocation? Does it do that? If your CF card reader had a problem, would the PC trash your card trying to 'fix' it?

Without the magic bytes at $1FE,$1FF in sector 0, Windows keeps asking you to format the card. If you say no, it just ignores it, since there's no FS on it as far as Windows is concerned. You can access the card with specialized software, of course (this is the exact approach we use with MyIDE, via Hias' MyIDETool), or with a sector editor in the usual fashion. If the Atari used the MBR partition table format, we could manipulate the partitions, but not the individual files on them without a Sparta/AtariDOS/etc filesystem driver. So really - at the moment the worst thing that can happen to a card is the user saying "yes, please format it" and then doing a few more misguided affirmative clicks.

 

Anyway, it would be very cool if we could move data on/off the CF card directly from the PC. Can we do that? Wouldn't you need to run the PCs file system on the Atari to do it? In 8K at 1.79mhz?

I think it would be better if we ran the Atari filesystem on the PC. It could be done: after all, Windows 7 reads and writes Apple FS partitions just fine using a driver.

 

Not being a programmer, I don't have a menu or such for changing CF cards. I actually just read the sticky on the card and enter it manually with the ED/ASM cart. Not very elegant, Im afraid. One more reason to use fixed partitions...

Certainly, in this case.

 

I use a HD for speed, not capacity. I have everything on floppy, for the most part - just don't like the wait. I'd love to have a file of all my disk directories that I could search for a particular name or content. You would need a large, fast storage system for that. Don't really need such for printing checks or envelopes in BASIC, do we?

I think there are two groups of people: those who want to use a HD on the Atari just like they would on a PC: with nested folders and all the other luxuries that certain DOSes afford. For those people, floppy disks or their SIO2xxx counterparts are just a means of getting data to and from the HDD. Then there's another group of people, who want to use the HDD as a huge array of floppy disks. Personally, I've always felt that never the twain should meet (re: earlier remark: "there's no room for any of that crap in HDD firmware"... though I paraphrase). However, there's no reason why fixed size partitions and/or floppy disk image slots shouldn't co-exist if someone wants to put up and write the firmware.

 

I have to say that Kyle Dain's incomplete MyIDE driver for SpartaDOS X - with a few amendments - was quite adequate for my needs before I sat down and wrote a partition editor for it. It used fixed 65536 sector partitions which were automatically assigned a bunch of drive letters. All the work put into creating a partition table format and editor was effectively to make the package "fit" for public consumption. What a wonderful thing hindsight is...

 

1. Storage and data-access encoding to be performed under max-flexibility (and existing) standards / variables (e.g. multiple partition sizes, etc.)

2. Maintain encoding on both read/write media, AS WELL AS non-volatile memory back-up.

3. Immediate, instant access from Windows, with

4. User interface pre-coded with easy, straight-forward choices (or subsets) of the wider, more flexible embedded options.

I agree about flexibility. If KMK makes the partitions fixed-size, personally I'll be digging the MyIDE cart out again. That's not a practical consideration, just an issue of personal choice. I can only fit a certain number of 32MB partitions on a 128MB card... why should I not be free to make partitions whatever size I want in order to have more partitions within the available space?

 

Another means of backing up the partition table is to stick a copy of it on the last sector of the drive. Hias and I considered that, but dropped the idea when the MyIDE LBA partition table grew beyond one sector in size.

 

Quite frankly, every DOS I ever used has caused me to lose valuable data through a VTOC screw-up/broken file links/scrambled sector map, etc at some point along the way. I never lost data yet through a lost partition table on the IDEa, IDE Plus, or with the SDX/MyIDE driver.

Link to comment
Share on other sites

I think there are two groups of people: those who want to use a HD on the Atari just like they would on a PC: with nested folders and all the other luxuries that certain DOSes afford. For those people, floppy disks or their SIO2xxx counterparts are just a means of getting data to and from the HDD. Then there's another group of people, who want to use the HDD as a huge array of floppy disks.

 

Touché. Also, an analogy comes to mind: when floppy disk drives became affordable, there were people who still wanted to use them as a sort of fast cassette recorders; others saw that the device gives new possibilities and allows to use the machine in new ways. The same I can say about parallel hard disks: this device of course _may_ serve as a drawer for floppy images, but also opens some new possibilities.

 

If KMK makes the partitions fixed-size

 

No worry, this won't happen.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...