It is currently Mon Nov 18, 2019 11:24 am




 Page 2 of 4 [ 54 posts ]  Go to page Previous  1, 2, 3, 4  Next
Author Message
 Post subject: Re: Fast Reads - how?
PostPosted: Thu Sep 16, 2010 11:25 am 

Joined: Wed Mar 04, 2009 7:27 am
Posts: 98
Location: United Kingdom
Thanks for your ideas! :) I need some time to digest this, and write a framework FDISK program in order to test some kind of scheme. The basic layout of your suggested partitioning scheme makes good sense, particularly since there's already software in the pipeline to read it on the PC.

A few immediate responses/questions spring to mind in the meantime, however:

1. How exactly do these "images" work (are they bootable?) and do they have any relevance to SpartaDOS X? Bear in mind that if you boot the machine without the cartridge, there'll be no DOS, no driver, and no way to access the disk. Unless the aim is to make the disk portable, but is there any likelihood of reading the partitions under SpartaDOS 3.x?
2. With reference to the above, the necessity for the "reserved" sector per partition.
3. I feel the partition table should be kept in RAM at all times, since we are aiming for speed as well as stability. For every sector operation (disregarding sequential optimisations for now), the partition information must be available. Of course, during operations on a given drive, we only require the geometry of the current partition, but for cross-partition copy operations we need two, and we still need a temporary buffer to read the partition sector into anyway. However, I'm open to being proved wrong on this point of view...
4. With regard to areas "outside" of partitions (free space), bear in mind that normal DOS operation is fast enough to stream movies from a file rather than raw sectors. I appreciate we're not going to quite hit 80KB/s, however. It would be nice to see as few casual applications as possible accessing the LBA blocks directly.
5. Provision must be made for a partition which is populated but not active: I suppose we could denote that by clearing the drive bit/drive number (whichever method we use).

Just suggestions!

Many of the methodologies MyIDE users are used to (and I keep coming back to images here) won't sit comfortably with the SDX driver. The disk will never boot, for starters. CONFIG.SYS can never be read from the (MyIDE) boot drive, either, since the driver must be installed by the CONFIG.SYS on the CAR: device before the HDD can be accessed. This has the handy side-effect of allowing the user to mount an SIO device on D1: and load CONFIG.SYS from there, bypassing the default CONFIG.SYS and thus the default MYIDE.SYS driver (this is how I test new versions of the driver), which can then be loaded off D1:, which will promptly disappear and be replaced by the MyIDE drive. And perhaps most elegant of all: by unplugging the (external) MyIDE device, SDX will boot normally, not install the driver, and print a barely noticeable message "MyIDE not present".

As I understand it, the images are just floppies copied onto the hard disk and swapped in as required. I most vehemently want to avoid hotkeys, console key+reset combinations and other such intrusiveness. I guess a command line program could be placed on the CAR: device to facilitate easy swapping of images should they be implemented.

Additional notes: the resident driver should be as small as possible. This means keeping image/partitioning/integrity checking/etc in separate applications (kept on CAR: if you choose). As I see it, the current test driver simply requires the ability to read LBA 0, add the LBA offsets to the sector # requests, and perform some simple error checking and it's done. The (resident) code and buffers should stay under 1K if at all possible, and I have every confidence that this will be the case. We also don't have a lot of room on the CAR: device: so any unnecessary stuff we can jettsion will all help.

Another important point here with relevance to games and images is that any code which reads the disk using the OS SIOV vector will fail.

...OK: I suggest I work with this at the moment and amend it as we go:

First record (8 bytes):

0 - 3: LBA size
4: ID byte
5: # partitions
6: Boot #
7: Options

(I reordered things purely for the sake of logic)

Individual partition entries (starting at offset 8 ):

0: Density + drive (0xN0 bytes per sector with 0x1 being 128, 0x2 being 256, 0x3 512, etc, and 0x0N allowing for 16 drive numbers (-1) )
1 - 4: LBA start
5 - 8: # sectors
9 : active flag
10 - 15: reserved

Later, if images are implemented, they can follow the basic format suggested in the previous post. I suppose they can be kept at 8 bytes per entry, but I want to get the normal partitions working first.

How does that sound?

What information can we read from the RAW drive? I guess I can look through the old BASIC FDISK listing, but can we get some code to read the drive geometry and anything else we can extract (such as manufacturer and model)?



_________________
The Last Word, MA65 Assembler, RIF SpartaDOS Utilities, XEDIT
Offline
 Profile  
 
 Post subject: Re: Fast Reads - how?
PostPosted: Thu Sep 16, 2010 1:07 pm 

Joined: Mon Jan 23, 2006 10:49 am
Posts: 187
Location: Salzburg, Austria
Hi Jon!

flashjazzcat wrote:
Thanks for your ideas! :)

You are welcome!

Quote:
The basic layout of your suggested partitioning scheme makes good sense, particularly since there's already software in the pipeline to read it on the PC.

Well, I'd say these two schemes don't differ too much :-) I'd suggest we combine them (i.e. add the image information stuff to the header, extend size from 24 to 32 bit as you suggested, etc) and then I'll adadpt myidetool. IIRC I still have to add support for 512 byte ATRs, I can't remember implementing this yet.

Quote:
1. How exactly do these "images" work (are they bootable?) and do they have any relevance to SpartaDOS X?

Yes and no. You could just ignore them in your driver and only use the partitions on the drive.

Quote:
Bear in mind that if you boot the machine without the cartridge, there'll be no DOS, no driver, and no way to access the disk. Unless the aim is to make the disk portable, but is there any likelihood of reading the partitions under SpartaDOS 3.x?

If Sijmen picks up his work on the LBA MyIDE OS these drives will be readable with other DOSes, too. I guess it's a good idea to use a partitioning scheme thats suitable both for your SDX driver and the MyIDE OS. Of course 512 byte sector partitions won't be readable with other DOSes (yet), but for example a 720 sectors DD DOS 2.x partition can be accessed both from MyDOS and SDX.

Quote:
2. With reference to the above, the necessity for the "reserved" sector per partition.

This reserved sector is not only handy to store additional information, but makes live a lot easier: just add the sector number (i.e. 1) to the LBA start and you are done. If you store sector 1 at offset 0 you always have to substract 1 when calculating the absolute LBA sector number. Only drawback is that you have to take care of that in FDISK (add 1 to the size here) and that you "waste" one additional sector per image/partition. But I guess we can live with this :-)

Quote:
3. I feel the partition table should be kept in RAM at all times, since we are aiming for speed as well as stability.

Sure, for your driver this should be no problem. Again I was thinking more about the MyIDE OS where RAM usage is quite critical.

Quote:
4. With regard to areas "outside" of partitions (free space), bear in mind that normal DOS operation is fast enough to stream movies from a file rather than raw sectors. I appreciate we're not going to quite hit 80KB/s, however. It would be nice to see as few casual applications as possible accessing the LBA blocks directly.

Bear in mind that there's a world besides SDX :-)

For example I started the movieplayer from MyPicoDos and accessed the physical sectors directly. Having some unpartitioned space on the drive could be handy for other stuff too. Of course you can always setup the drive so that all of the space is available only for partitions. Image space and unallocated space should be optional.

Quote:
5. Provision must be made for a partition which is populated but not active: I suppose we could denote that by clearing the drive bit/drive number (whichever method we use).

Yes, of course. IIRC MyIDE OS used the drive bit for this purpose and left the drive number in the partition unchanged. But I have to say this is somewhat confusing, eleminating the drive bits and adding an active flag (or active bit in the drive-number, for example bit 7) would be more logical.

Sijmen?

Quote:
As I understand it, the images are just floppies copied onto the hard disk and swapped in as required. I most vehemently want to avoid hotkeys, console key+reset combinations and other such intrusiveness. I guess a command line program could be placed on the CAR: device to facilitate easy swapping of images should they be implemented.

By default the MyIDE OS only operates with partitions. Only if you press start during powerup image-mode is activated. Here you basically just select a base image number to boot and then can enable/disable the image or activate image base+X with hotkeys. This is mostly useful for (multi-) disk games or other stuff that you want/have to keep in it's original format (for example a collection of disk magzines or so).

As for the SDX driver I'd also say stay away from hotkeys, a simple program to mount a specific image should be enough. For V1.0 you may also completely ignore these images.

Quote:
...OK: I suggest I work with this at the moment and amend it as we go:

First record (8 bytes):

0 - 3: LBA size
4: ID byte
5: # partitions
6: Boot #
7: Options

(I reordered things purely for the sake of logic)

Individual partition entries (starting at offset 8 ):

0: Density + drive (0xN0 bytes per sector with 0x1 being 128, 0x2 being 256, 0x3 512, etc, and 0x0N allowing for 16 drive numbers (-1) )
1 - 4: LBA start
5 - 8: # sectors
9 : active flag
10 - 15: reserved

Later, if images are implemented, they can follow the basic format suggested in the previous post. I suppose they can be kept at 8 bytes per entry, but I want to get the normal partitions working first.

How does that sound?

I'd suggest increase the header to 24 or 32 bytes so there's room for image information, partition start etc. It might also be good to have 2 option bytes, one that Sijmen may be using for his OS and one for your driver.

Quote:
What information can we read from the RAW drive? I guess I can look through the old BASIC FDISK listing, but can we get some code to read the drive geometry and anything else we can extract (such as manufacturer and model)?

In 512 byte (CFA) mode: a lot, in 256 byte mode: next to nothing (every second byte will be missing).

The relevant ATA command is $EC, "identify device". You'll get number of LBA sectors, manufacturer, features, capabilities etc.

so long,

Hias


Offline
 Profile  
 
 Post subject: Re: Fast Reads - how?
PostPosted: Thu Sep 16, 2010 1:43 pm 

Joined: Wed Mar 04, 2009 7:27 am
Posts: 98
Location: United Kingdom
I can see the sense in making space for stuff that SDX won't bother with but which might be important elsewhere. I guess the spare sector will save about two cycles per sector read, too, although wasted space really bugs me! :) Anyway, this is all relevant to your remark about there being a "world besides SDX". Well, of course, but this is an SDX driver and the initial aim is to allow MyIDE to be used as a cheap and professional HDD solution for that operating system. That's why I didn't want to slavishly follow the existing (CHS) partition scheme: I couldn't see any point in that. But if we can arrive at something sensible and efficient (which I think we're well on the way to doing!) I have no real problem with leaving in a bit of "breathing space", as long as the end product isn't klunky. As you say, free space and image space should be optional.

Must the image information be in a fixed location, I take it? If so, I might as well make the partition header 16 bytes (allowing room for an additional option byte, and for a 32 bit pointer to the first unpartitioned sector on the drive?), then leave another 16 (presently blank) for image info. So that's 32 bytes in total, followed by the 16 byte partition entries.

I've been reading through the ATA-3 document and I've got the drive information (0xEC) all jotted down. You're quite right that 256 byte sectors won't yield much of use, but having the HDD model number flash up in FDISK will be a nice bonus for CF card users!

I'll write up these amendements to the partition table later on and post them up tomorrow if they're agreeable. FDISK is coming along nicely and should be working by the weekend (it's a bit of a chicken and egg situation, since I need FDISK to work before I can amend the driver, and FDISK is my first large relocatable SDX project).



_________________
The Last Word, MA65 Assembler, RIF SpartaDOS Utilities, XEDIT
Offline
 Profile  
 
 Post subject: Re: Fast Reads - how?
PostPosted: Thu Sep 16, 2010 2:50 pm 

Joined: Mon Jan 23, 2006 10:49 am
Posts: 187
Location: Salzburg, Austria
flashjazzcat wrote:
That's why I didn't want to slavishly follow the existing (CHS) partition scheme: I couldn't see any point in that.

I totally agree with you. CHS is absolutely awful legacy stuff and I don't want to have to use it in a new project again.

I guess Sijmen felt the same way when he started work on the LBA MyIDE OS :-)

Quote:
Must the image information be in a fixed location, I take it?

Not really. In the (CHS) MyIDE OS you could set the starting cyclinder of image space in 256-cylinder steps (0=no image space, 1=cylinder 256, 2=cyl 512, ...). If image space is enabled, it extends up to the end of the drive. The space between the last partition sector and beginning of image space was then free for other use (movies etc).

In the LBA proposal we made this more flexible, i.e. set the start to any LBA sector and make the size adjustable.

So, basically it's just like a special kind of partition. Which leads me to another idea:

Why not store image space configuration in a normal partition entry?

For example: The last partition entry may either be a normal partition or an image space partition. So, with a 16 byte header and 16 bytes per partition entry you may either have 15 partitions or 14 partitions plus image space on the drive.

We could distinguish between image space and standard partitions just like we distinguish between single/enhanced/quad density partitions, via a partition type (density) byte.

Such a type byte would also open the possibility to add partition entries later (for example when you add 4k sector support to SDX :-)))

So, next proposal:
Header (16 bytes):
0 - 3: LBA size
4: ID byte
5: # partitions
6: Boot #
7: Options
8-15: reserved

Partition entry (16 bytes):
0 - 3: LBA start
4 - 7: size
8: active flag
9: type/density
10: drive number
11-15: reserved

BTW: for what purposes do you need the "# partitions" and "boot #" entries in the header?

so long,

Hias


Offline
 Profile  
 
 Post subject: Re: Fast Reads - how?
PostPosted: Thu Sep 16, 2010 3:37 pm 

Joined: Wed Mar 04, 2009 7:27 am
Posts: 98
Location: United Kingdom
Making images standard partitions sounds like the best idea since sliced bread! Much more elegant and to my liking. :)

Boot # opens the possibility of making SDX read AUTOEXEC.BAT from a drive other than A:. It's really a simulation of booting from a different device, since we're not really "booting" at all, but it would let you basically have C: as the HDD and A: and B: as floppies if you want. The KMK/IDEa interface offers something similar (but of course that can force SDX to read CONFIG.SYS off a hard disk on whichever drive number you like).

The number of partitions: well, I figured that would help us handle variable size LBA block 0, bearing in mind that we can't quite fit 16 partition blocks into a 256 byte sector, but we can in CFA mode. It also simply tells the driver when to stop trawling through the boot sector at startup, rather than stepping through 15 partition blocks just to see if any are populated.

I've just run into a very basic but frustrating bug in the FDISK app: it crashes on the latest IntSDX beta but runs on Maxflash SDX on the emulator. Must be something to do with the relocator. Once of those stupid bugs one can waste hours on...

Fixed that: now the read routine is hanging after issuing the $EC get drive info command.



_________________
The Last Word, MA65 Assembler, RIF SpartaDOS Utilities, XEDIT
Offline
 Profile  
 
 Post subject: Re: Fast Reads - how?
PostPosted: Thu Sep 16, 2010 5:46 pm 

Joined: Mon Jan 23, 2006 10:49 am
Posts: 187
Location: Salzburg, Austria
flashjazzcat wrote:
Making images standard partitions sounds like the best idea since sliced bread! Much more elegant and to my liking. :)

Great! Then we should go that route, if Sijmen doesn't object. I don't know why I didn't have this idea 2 years ago...

Quote:
Boot # opens the possibility of making SDX read AUTOEXEC.BAT from a drive other than A:.

Ah, OK. This makes sense. Thanks for the explanation!

Quote:
The number of partitions: well, I figured that would help us handle variable size LBA block 0, bearing in mind that we can't quite fit 16 partition blocks into a 256 byte sector, but we can in CFA mode. It also simply tells the driver when to stop trawling through the boot sector at startup, rather than stepping through 15 partition blocks just to see if any are populated.

Hmmm, well, I'd stick with a 256 bytes LBA sector 0. Reading this sector in CFA (512) byte mode results in a real mess - the original 256 byte table scattered around the whole sector, every even byte is the "original" 256-byte-partitiontable, every odd byte the (possibly random) additional data. This'll be really nasty to handle.

If you want to support more than 15 partitions it would be best to separate the partition information into additional sector(s) and use LBA 0 only for the header. You could then use, for example, a header entry containing the number of additional partition sectors and create hundreds or thousands of partitions (if you like).

Another thing: scanning through the whole partition table and checking for active (flag set) and valid (start != 0) partitions is quite easy and reliable. OTOH if some bug in a FDISK program sets the partition# byte wrong you might be spending some time wondering why only a few of your, lets say, 10 partitions show up. So I'd recommend eliminating this (redundant) information, it'll make life a lot easier :-)

Quote:
Fixed that: now the read routine is hanging after issuing the $EC get drive info command.

Ouch, this is not good :-( The ATA-8 specs say that the EC command is mandatory (and I can't remember seeing a drive that didn't support this command).

so long,

Hias


Offline
 Profile  
 
 Post subject: Re: Fast Reads - how?
PostPosted: Thu Sep 16, 2010 6:13 pm 

Joined: Mon Jan 23, 2006 10:49 am
Posts: 187
Location: Salzburg, Austria
HiassofT wrote:
If you want to support more than 15 partitions it would be best to separate the partition information into additional sector(s) and use LBA 0 only for the header. You could then use, for example, a header entry containing the number of additional partition sectors and create hundreds or thousands of partitions (if you like).

Yet another, maybe better, idea:

Keep the partition info of the first 15 entries in sector 0, add a byte/word of "additional partition sectors" to the header plus a 32 bit "first sector for partitions" info (this 32bit info might be kind of redundant, but also might come handy if you like/have to align partitions to some boundary).

Then applications/OSes that only read the first sector can access the first 15 partitions on the drive, but you also have the possibility to store more partitions if you like. This is a whole lot easier to handle than the chained extended partitions of the MBR scheme :-)

so long,

Hias


Offline
 Profile  
 
 Post subject: Re: Fast Reads - how?
PostPosted: Thu Sep 16, 2010 9:38 pm 

Joined: Sat Sep 13, 2003 12:21 am
Posts: 251
What about a byte for image size, or will image space always be 1040 sectors? I know this isn't really in scope of your work here, FJC, but probably should be in the partition spec.



_________________
MyIDE Tools
Offline
 Profile  
 
 Post subject: Re: Fast Reads - how?
PostPosted: Fri Sep 17, 2010 4:16 am 

Joined: Mon Jan 23, 2006 10:49 am
Posts: 187
Location: Salzburg, Austria
Shawn Jefferson wrote:
What about a byte for image size, or will image space always be 1040 sectors? I know this isn't really in scope of your work here, FJC, but probably should be in the partition spec.

I also thought of that. We could either encode the image-size in the partition-type field (i.e. have a fixed number of image slot configurations, say 720/1040/1440 sectors per slot) or store a 16 bit entry in one of the reserved bytes of the partition entry. The latter would be more flexible (i.e. the user could configure image slots to be of any arbitrary size) but the OS then has to multiply the image slot number with this value. Could be easier to implement in the OS than supporting a set of fixed sizes, though.

so long,

Hias


Offline
 Profile  
 
 Post subject: Re: Fast Reads - how?
PostPosted: Fri Sep 17, 2010 10:53 am 

Joined: Wed Mar 04, 2009 7:27 am
Posts: 98
Location: United Kingdom
All good ideas: however I don't want to get too bogged down in the finer points of the partition table until I have a working system. Amendments will then be trivial to action. I can see the #partitions value becoming redundant but I guess that will become apparent one way or another as I complete the FDISK program and figure out how it moves partition data around.

Good news: I got the $EC command to work. It was actually a logic error (I hadn't populated the sector data pointer so it was overwriting page zero: ouch indeed!). Of course all the bytes in "TRANSCEND" were transposed: I need to reverse the order of the LSB/MSBs in the ID string.

I certainly hear you about keeping the partition table sector at 256 bytes, since the first half of a 512 byte sector will be garbled. However, surely reading a CFA formatted disk in non-CFA mode would be disastrous anyway: why would you want to do it? I suggest we need some clever ID bytes in the lower part of the partition block which will prevent non-CFA reads from screwing up a CFA disk. If the driver was to assume 256 byte sectors on boot, it would be reading every other byte of block 0 if the disk had in fact been set up in CFA mode. The driver needs to identify this situation and switch to CFA. With this in mind, it becomes reasonable to allow a larger partition table in block 0 of a CFA disk, and therefore the # partition value may become relevant. Perhaps we could have a four byte ID string, and when the first block is read in non-CFA mode, we could analyse the bytes retrieved and deduce whether to switch to CFA mode or not. Which bytes get read in standard mode? I assume the lower order bytes of a block (i.e. 0, 2, 4, etc).

I really need to work on the UI for FDISK so I'll be busy for a day or two. I reckon I'll have something practical to demonstrate on Sunday.



_________________
The Last Word, MA65 Assembler, RIF SpartaDOS Utilities, XEDIT
Offline
 Profile  
 
 Post subject: Re: Fast Reads - how?
PostPosted: Fri Sep 17, 2010 12:05 pm 

Joined: Mon Jan 23, 2006 10:49 am
Posts: 187
Location: Salzburg, Austria
flashjazzcat wrote:
All good ideas: however I don't want to get too bogged down in the finer points of the partition table until I have a working system. Amendments will then be trivial to action.

Sure, these were just some suggestions.

In the meanwhile I started implementing support for 512 ATRs and for the new partitioning scheme in myidetool. The exact offsets, values etc. can easily be changed while we refine the partition table definition, I just have to set new offset definitions (I avoided using absolute numbers in my code wherever possible). I hope I have something usable this weekend.

Quote:
I certainly hear you about keeping the partition table sector at 256 bytes, since the first half of a 512 byte sector will be garbled. However, surely reading a CFA formatted disk in non-CFA mode would be disastrous anyway: why would you want to do it?

The question is: do you want your driver to work with CF cards only or also with real harddisks?

Of course 512 byte sectors won't be usable with standard harddisks, but other than that SD and DD partitions would work with both.

Supporting harddrives shouldn't be a big deal, just enable 8bit CFA mode only when doing 512byte sector accesses, use standard mode for other accesses. You'd just need to keep a flag in your driver to remember if the drive is currently in 8bit CFA mode so you can issue the commands to switch between 8 and 16bit mode whenever needed. When powered up the drive is in 16bit mode, but you can issue a "set 16bit mode" command at driver initialization, just to be sure.

We could also completely drop support for harddisks (I don't like them anyways :-) and always use 8bit mode. In this case we should re-arrange the sector data so that only the first 128/256 bytes are used.

Quote:
Which bytes get read in standard mode? I assume the lower order bytes of a block (i.e. 0, 2, 4, etc).

Yes, exactly. The drive operates in 16-bit mode and only the lower 8 bit are connected to the Atari data bus.

so long,

Hias


Offline
 Profile  
 
 Post subject: Re: Fast Reads - how?
PostPosted: Fri Sep 17, 2010 12:32 pm 

Joined: Wed Mar 04, 2009 7:27 am
Posts: 98
Location: United Kingdom
Great to hear the revised MyIDE tool is coming along nicely. FDISK is going well: I'm writing a little window/menu library for text mode apps which will be amply reusable for other projects (so it's not really overkill or wasted time in that sense!), and adaptable for Draco's VBXE drivers.

It was certainly my intention to support hard disks as well: CFA will be optional. What I was trying to get at is that since the config data is all stored on the disk, the driver will have to cold boot assuming the attached device is a hard disk, and then interrogate the partition table flags to establish if 512 byte sectors are being used. If so, it must switch to CFA mode. If not, it just uses standard access. It's therefore important that the sector size byte is clearly and unambiguously readable in either mode, so byte alignment is important. :)



_________________
The Last Word, MA65 Assembler, RIF SpartaDOS Utilities, XEDIT
Offline
 Profile  
 
 Post subject: Re: Fast Reads - how?
PostPosted: Fri Sep 17, 2010 2:45 pm 

Joined: Mon Jan 23, 2006 10:49 am
Posts: 187
Location: Salzburg, Austria
flashjazzcat wrote:
What I was trying to get at is that since the config data is all stored on the disk, the driver will have to cold boot assuming the attached device is a hard disk

I wouldn't assume this. For example one could cold-boot the Atari (using the Turbo Freezer, some special OS, some extra hardware) without power-cycling and/or pressing reset while the device is in 8bit mode. Then the device will be in 8bit mode when your driver reads the partition table.

It's best you issue the "set 16bit mode" at the very beginning of your driver initialisation (and whenever in doubt, for example after a reset or so). Harddrives will ignore this command (and report an error) and CF cards will be put in 16bit "harddisk" mode.

BTW: accessing 128 and 256 byte partitions in 16-bit mode will also be a little bit faster than in 8-bit mode. In 8 bit mode you have to read (and discard) 384 (or 256) additional bytes, whereas in 16 bit mode it's only 128 (or 0) bytes.

so long,

Hias


Offline
 Profile  
 
 Post subject: Re: Fast Reads - how?
PostPosted: Fri Sep 17, 2010 3:57 pm 

Joined: Wed Mar 04, 2009 7:27 am
Posts: 98
Location: United Kingdom
One thing: just because a CF card is attached, doesn't necessarily mean it was set up in CFA mode. One way or the other (whether while in CFA mode or 16 bit mode), the pre-configured access mode must be read from the partition table (assuming the disk was previously set up with FDISK) and the driver must switch the drive into the appropriate mode. So - my point was that the 8/16 bit mode information must be stored in LBA block 0 and readable in both modes.

FDISK itself will include - as well as a tool to surface test the drive and decide whether fast or careful I/O is advisable - the ability test whether the attached device supports CFA mode or not.

So, given that individual partitions can have their sector size set individually, we also require a flag in the partition header which tells us whether the disk is set up in 8 or 16 bit mode. This is roughly equivalent to "real" and "emulated" modes on the KMK/IDEa interface, and will be an extra option in FDISK.



_________________
The Last Word, MA65 Assembler, RIF SpartaDOS Utilities, XEDIT
Offline
 Profile  
 
 Post subject: Re: Fast Reads - how?
PostPosted: Fri Sep 17, 2010 4:55 pm 

Joined: Mon Jan 23, 2006 10:49 am
Posts: 187
Location: Salzburg, Austria
flashjazzcat wrote:
One thing: just because a CF card is attached, doesn't necessarily mean it was set up in CFA mode.

I think we are talking about different things here.

If you use 16bit mode for all I/O except for 512 byte/sector partitions, it doesn't matter if you setup/read/write a harddrive or a CF card - the data on the media will be identical (every even byte contains data, every odd byte is garbage).

So the only case where it makes a difference is when accessing 512 byte/sector partitions. This cannot be done with harddrives, only with CF cards. And only in this case configure the CF card to use 8bit mode so you can access all 512 bytes of a sector.

so long,

Hias


Offline
 Profile  
 
Display posts from previous:  Sort by  
 Page 2 of 4 [ 54 posts ]  Go to page Previous  1, 2, 3, 4  Next


Who is online

Users browsing this forum: No registered users and 11 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  

cron