NEW MIO production run.

[MEtalGuy66]

Ok.. Time for a big assed update to this big assed thread..

 

First, for everyone who I currently owe an MIO to, it's ready to ship..

 

 

The MI0 case from PacTek is available in two colors: Black and "PC-Bone". Initially, I ordered them all black because I wasn't sure what "PC-Bone" was.. Well, it turns out that "PC-Bone" is a pretty damn close approximation of the off-white on the XL series of machines.

 

So heres some pics of various case color combinations:

 

 

The half black, half white one looks pretty consistant with an XL styled device.

Unfortunately, if I build someone a white/black one, I also have to build a black/white one at some point to use up the other two case halves.. So for now, that's gonna be a "subject to availability" item, unless you REALLY want it and are willing to pay $20.00 for an extra case.

 

Ok.. Next, as I said in the other thread, I have started a Drive Support page on my site.

http://www.rasterline.com/drives.html

You can get there by selecting the products tab from the main page, and then clicking the "MIO Hard Disc Support" link. Ill try to keep this updated as best I can..

 

Also, we have started shipping MIOs with a slightly different chip configuration:

U1, U3, U4, U8, U11, U29, and U48 are being populated with "F" series ICs.

For example, instead of a 74LS138 or 74HC138, it's a 74F138. This reduces the propogation time on the adress decoder circuits, which helps out with EPROM compatability and reduces the infamous "PHI2-BUS Timing Skew" problem inherant to some ATARIs. It also tightens up the timing on SCSI reads, which shows a marked improvement on drive compatability. With this new config, ALL of the Seagate "Cheetah" series SCA drives seem to work fine, rather than just select models and firmware releases. We don't gurantee this, but that's the way it looks at this point.

 

This upgrade is completely optional. If your setup is already rock-solid, then I don't reccomend messing with it. That said, anyone who has purchased an MIO from me in the past and wants/needs a set of these "F-series" ICs is entitled to a free set.. Just pay shipping.

 

This should improve the original ICD MIO as well, since the affected circuits are identicle between the two. If you want a set for your original ICD unit, I'll sell you one for $10.00US plus shipping.

 

Last but certainly not least, in case anyone reading this didn't catch the other thread, we have had great success with (the latest 1.40 firmware and) certain IDE-to-SCSI adaptors lately. The ACARD AEC-7720U seems to work with any IDE or CF device you can stick on it.. The IODATA IDSC21-E/F also seems to work well. Check my Drive support page (link above) for full details.. Only downside is that these adaptors are pretty darned expensive, and are getting kinda rare these days..

 

Ok. Well, that about sums it up.

As alwayze, anyone with questions regarding ordering a new MIO or anything above can contact me at kjones66@earthlink.net or just shoot me a PM on AtariAge..

[flashjazzcat]

Very, very nice.

 

 

 

[tjlazer]

NICE WORK!!!

[spookt]

ITS HERE !!!!

 

Well, after paying good old Her Majesty's Revenue and Customs £31.00 in VAT and Parcelforce Worldwide £8.00 in "handling fees" I finaly got my hands on the package I've been waiting for from MetalGuy

 

 

Only bummer now is I have to work today

 

Thanks again Ken. I'm sure I'll have some questions for all you MIO users once I get it set up, but I'm planning to read through the relevant threads here again today.

[OldAtarian]

Any chance of making more?

[OldAtarian]

...

Y'all are obsessed with those old drives.

 

More on that later.

 

I noticed that when I setup 1.4b3 for 512b sectors (BLKSZ) and make a 65535 sec partition, it still reports 16383k in the bottom table. Is this normal? Or should it say 32766K?

 

Just curious, but why would you want to use large sectors at all? Wasn't that the big failing of Atari DOS 3 that the sectors were too large? If you had a file go just one bit over into another sector it wasted a lot of disc space and multiply that effect times many files and a large portion of your disc became unusable even though it was empty. I would think the smallest possible sector size would be better, right?

Edited November 22, 2010 by OldAtarian

[MEtalGuy66]

ITS HERE !!!!

 

Well, after paying good old Her Majesty's Revenue and Customs £31.00 in VAT and Parcelforce Worldwide £8.00 in "handling fees" I finaly got my hands on the package I've been waiting for from MetalGuy

 

 

Those crooks!

 

And I piad them $46.00US on this end!

[sloopy]

Any chance of making more?

 

he still makes them, he has more pcb's, its just a little wait time, as he has to order the components as i understand it... send him an email, and he can give you the details, you can find his contact info on rasterline

 

sloopy.

[MEtalGuy66]

Just curious, but why would you want to use large sectors at all? Wasn't that the big failing of Atari DOS 3 that the sectors were too large? If you had a file go just one bit over into another sector it wasted a lot of disc space and multiply that effect times many files and a large portion of your disc became unusable even though it was empty. I would think the smallest possible sector size would be better, right?

 

The reason is because modern drives cannot natively support 256 byte sectors. The CSS Black Box is able to "split" each 512 byte sector into 2 256byte "virtual sectors" for the ATARI, but this requires the ATARI's CPU to perform the concatenation "on the fly", which is relatively slow, and takes lots of disk handler code. We only have 8k to work with, including the config menu program, which also resides in firmware.. The black Box has 64k of firmware space, and in those days, there was no decent DOS that supported 512byte sectors.

 

With the MIO, you have 2 options: a)discard the top half of each sector, and only use the first 256 bytes. B)use the full 512byte sector size if the DOS supports it (eg. SpartaDOS 4.42 DD512.)

 

By the way, with the 4.40 Firmware, the partition size display in the firmware menu is correctly displayed based on sector size.

 

Lastly, YES I can make more MIOs. I just built & shipped 4 of them last month. No, I dont have to order components, unless I am out of something. I keep a stock of parts just for building MIOs. email me or PM me if interested.

Edited November 22, 2010 by MEtalGuy66

[Mathy]

Hello OldAtarian

 

Wasn't that the big failing of Atari DOS 3 that the sectors were too large? If you had a file go just one bit over into another sector it wasted a lot of disc space and multiply that effect times many files and a large portion of your disc became unusable even though it was empty.

Way back when DOS 3 came out, we used 5.25" disks which could store 180 kB max. per side. Nowadays we have IDE drives and trying to find a new one with less then 20 GB is getting harder by the day.

 

sincerely

 

Mathy

Edited November 22, 2010 by Mathy

[flashjazzcat]

Just curious, but why would you want to use large sectors at all? Wasn't that the big failing of Atari DOS 3 that the sectors were too large? If you had a file go just one bit over into another sector it wasted a lot of disc space and multiply that effect times many files and a large portion of your disc became unusable even though it was empty. I would think the smallest possible sector size would be better, right?

When dealing with large hard disk partitions (32MB), 512 bytes per sector isn't wasting a meaningful amount of space even with small files. And 512 byte sectors are faster, and they allow double the partition size with 16 bit sector addressing. It's win, win with 512bps.

Edited November 22, 2010 by flashjazzcat

[OldAtarian]

ITS HERE !!!!

 

Well, after paying good old Her Majesty's Revenue and Customs £31.00 in VAT and Parcelforce Worldwide £8.00 in "handling fees" I finaly got my hands on the package I've been waiting for from MetalGuy

 

 

Those crooks!

 

And I piad them $46.00US on this end!

 

Everything costs more in socialist Europe.

[spookt]

Well I've got it hooked up but no HDD yet.

 

I just copied RealDOS into a RAM disk and set it as D1. My machine boots in about 1 second flat

 

Awesome stuff. Can't wait to get a real set of spinning platters connected !

Edited November 22, 2010 by spookt

[sloopy]

Well I've got it hooked up but no HDD yet.

 

I just copied RealDOS into a RAM disk and set it as D1. My machine boots in about 1 second flat

 

Awesome stuff. Can't wait to get a real set of spinning platters connected !

 

i remember the first time i hooked a 20meg up to my MIO in '88... when i saw all those free sectors, i dropped my jaw, and wondered what i was gonna fill it all with... and now, the only drive that works with the MIO (seagate ST15150), that i, have doesnt work... when payday comes i think i am gonna invest in a 73Gb drive and adaptor myself...

 

but either way, that ram disk kicks the split... i used to play Autoduel, with the second disk in the ramdisk, set as D2: and it was screaming fast...

 

sloopy.

[+bf2k+]

 

Just curious, but why would you want to use large sectors at all? Wasn't that the big failing of Atari DOS 3 that the sectors were too large? If you had a file go just one bit over into another sector it wasted a lot of disc space and multiply that effect times many files and a large portion of your disc became unusable even though it was empty. I would think the smallest possible sector size would be better, right?

 

Couple of reasons actually.

 

You are certainly correct about DOS 3 however, we are not talking about floppies now. We are talking about MIO and SCSI hard disks. Also we are talking about SpartaDOS... not Atari DOS which is also apples and oranges.

 

The physical sector size of these newer scsi HD's is 512 bytes. So using it all maximizes the storage - a 16mb partition occupies the same amount of space on the physical disk as a 32mb partition. So even if you format the HD to 256 byte sectors, you are still using all 512 bytes of the physical sector - just half of it is left empty. That's how it works. So why not fill it with data? Any file occupies half as many sectors on the 512b/s disk as it does on a 256 b/s disk.

 

Also read/write operations to 512 byte sectors are faster than 256 byte secs because you are not leaving half of the sector empty hence your file copy operation 512/512 takes roughly 1/2 as much time as a 256/256 copy operation.

[+Larry]

Dos 3 was introduced for the stock 1050, correct? Then it should have only supported 128-byte sectors, MFM. But Dos 3 had Clusters of multiple sectors, somewhat akin to what some other types of Doses (including MS-Dos) use. It's a similar concept, but a little different implementation.

 

FWIW -- Now here is another thought -- just how fast do you need to load a three kilobyte file? Speed is neat, especially when we went from cassettes to disk drives to Ultra/Warp Speed, to hard drive speed -- but I would argue that R/W speed behaves with diminishing marginal returns like most other things in life. Sure, there are exceptions to every rule (like doing a disk backup), but can you really tell much difference between a "slow" Atari hard drive and a "fast" Atari hard drive in typical everyday use? Both are pretty much "instantaneous" IMO.

 

-Larry

 

 

 

Just curious, but why would you want to use large sectors at all? Wasn't that the big failing of Atari DOS 3 that the sectors were too large? If you had a file go just one bit over into another sector it wasted a lot of disc space and multiply that effect times many files and a large portion of your disc became unusable even though it was empty. I would think the smallest possible sector size would be better, right?

 

Couple of reasons actually.

 

You are certainly correct about DOS 3 however, we are not talking about floppies now. We are talking about MIO and SCSI hard disks. Also we are talking about SpartaDOS... not Atari DOS which is also apples and oranges.

 

The physical sector size of these newer scsi HD's is 512 bytes. So using it all maximizes the storage - a 16mb partition occupies the same amount of space on the physical disk as a 32mb partition. So even if you format the HD to 256 byte sectors, you are still using all 512 bytes of the physical sector - just half of it is left empty. That's how it works. So why not fill it with data? Any file occupies half as many sectors on the 512b/s disk as it does on a 256 b/s disk.

 

Also read/write operations to 512 byte sectors are faster than 256 byte secs because you are not leaving half of the sector empty hence your file copy operation 512/512 takes roughly 1/2 as much time as a 256/256 copy operation.

[+Stephen]

Dos 3 was introduced for the stock 1050, correct? Then it should have only supported 128-byte sectors, MFM. But Dos 3 had Clusters of multiple sectors, somewhat akin to what some other types of Doses (including MS-Dos) use. It's a similar concept, but a little different implementation.

 

FWIW -- Now here is another thought -- just how fast do you need to load a three kilobyte file? Speed is neat, especially when we went from cassettes to disk drives to Ultra/Warp Speed, to hard drive speed -- but I would argue that R/W speed behaves with diminishing marginal returns like most other things in life. Sure, there are exceptions to every rule (like doing a disk backup), but can you really tell much difference between a "slow" Atari hard drive and a "fast" Atari hard drive in typical everyday use? Both are pretty much "instantaneous" IMO.

 

-Larry

I have to argue that. There is a massive difference when loading more modern programs such as Last Word, Ice-T XE, NeoTracker, etc. Having the ability to load these programs in 3 seconds as opposed to 30 or more almost makes the machine feel as if it is multi-tasking. With Sparta DOS X on cart, and most apps now loading in under 5 seconds, the machine is truly a blast to use.

 

Also, the 400 is not the gold standard anymore. Demos / apps which require 320K are becoming more common. HDs also open up the possibilities for modern upgrades such as Covox and VBXE.

[+warerat]

Everyone who's responded has done a pretty good job explaining why it's better. I'll chime in as I reworked the firmware to work with new drives.

 

The underlying reason for why the 512-byte sectors are faster has to do with the native block size of the hard drive. Modern HDD's have a minimum block size of 512 bytes (most of them, at least the ones we'll use for this). From a low-level SCSI firmware perspective we focus on the data phase where the asynchronous transfer from Initiator (MIO) or Target (HDD) occurs. This transaction is always the size of the native block size of the target. Therefore, we must always read/write 512 bytes in the data phase. There is no way to abort this in mid-phase cleanly. I could in theory attempt to interrupt the data transfer after I read a short (128/256-byte) sector but the hardware isn't set up for the initiator to send an abort message to the target to cancel the current data transaction. Even if I was able to do this, the SCSI standard is murky and there is no guarantee that every vendor's drive will abort right after the message is received or if we must still keep strobing ACK- until the drive's buffer has cleared. Because of the latter, it really wouldn't buy any performance.

 

The key point here is I have to read/write 512-bytes in the data phase. If you request 256-bytes from the Atari, the read/write operation still requests 512-bytes but the second half of the transaction is discarded. When I reworked the firmware to work with newer devices I decided on a 1:1 sector mapping. By doing it this way, I don't have to have an additional buffer for the second half of the data not to mention having to monkey around remapping the second half to a physical sector. We have millions of sectors addressable, so burning them up only using half or a quarter of the capacity isn't an issue.

 

So the bottom line is a sector operation to/from the drive takes the same fixed amount of time, regardless if it's 128, 256, or 512. Therefore the throughput you observe is directly related to this. Reading a handful of sectors probably feels about the same. But if you're copying large blocks of data back and forth, that's where using the native block size really shines and truly is better.

[+bf2k+]

FWIW -- Now here is another thought -- just how fast do you need to load a three kilobyte file? Speed is neat, especially when we went from cassettes to disk drives to Ultra/Warp Speed, to hard drive speed -- but I would argue that R/W speed behaves with diminishing marginal returns like most other things in life. Sure, there are exceptions to every rule (like doing a disk backup), but can you really tell much difference between a "slow" Atari hard drive and a "fast" Atari hard drive in typical everyday use? Both are pretty much "instantaneous" IMO.

 

-Larry

 

It is relative really... I have been using MIO/HD setup since 1985-6 (whenever the MIO first came out - I couldn't get one fast enough ). So really I have been using HD setups much longer than I ever used exclusively Floppy setups. And even so, when I first hung a new(er) Seagate SCSI drive on my MIO with Warerat's new firmware, I was pretty amazed at the speed difference. I forget the RWtest numbers at this time but they are probably published elsewhere in this thread. Maybe 4-5 times faster?

[+Stephen]

Dos 3 was introduced for the stock 1050, correct? Then it should have only supported 128-byte sectors, MFM. But Dos 3 had Clusters of multiple sectors, somewhat akin to what some other types of Doses (including MS-Dos) use. It's a similar concept, but a little different implementation.

 

FWIW -- Now here is another thought -- just how fast do you need to load a three kilobyte file? Speed is neat, especially when we went from cassettes to disk drives to Ultra/Warp Speed, to hard drive speed -- but I would argue that R/W speed behaves with diminishing marginal returns like most other things in life. Sure, there are exceptions to every rule (like doing a disk backup), but can you really tell much difference between a "slow" Atari hard drive and a "fast" Atari hard drive in typical everyday use? Both are pretty much "instantaneous" IMO.

 

-Larry

I have to argue that. There is a massive difference when loading more modern programs such as Last Word, Ice-T XE, NeoTracker, etc. Having the ability to load these programs in 3 seconds as opposed to 30 or more almost makes the machine feel as if it is multi-tasking. With Sparta DOS X on cart, and most apps now loading in under 5 seconds, the machine is truly a blast to use.

 

Also, the 400 is not the gold standard anymore. Demos / apps which require 320K are becoming more common. HDs also open up the possibilities for modern upgrades such as Covox and VBXE.

One other thing to remember Larry, we are not talking about the difference between 1k/sec and 3k/sec like the US Doubler gave us. fcj's new driver can read dat using the full file system at an amazing 71k/sec with the screen turned on!

[+bf2k+]

One other thing to remember Larry, we are not talking about the difference between 1k/sec and 3k/sec like the US Doubler gave us. fcj's new driver can read dat using the full file system at an amazing 71k/sec with the screen turned on!

 

Actually, we're talking about the MIO, not MyIDE.

[flashjazzcat]

One other thing to remember Larry, we are not talking about the difference between 1k/sec and 3k/sec like the US Doubler gave us. fcj's new driver can read dat using the full file system at an amazing 71k/sec with the screen turned on!

 

Actually, we're talking about the MIO, not MyIDE.

I think Stephen was simply using MyIDE as a general example of the magnitude of performance gain that 512 byte sectors make possible with HDD interfaces as opposed to floppy drives.

[MEtalGuy66]

Its true that using the entire physical sector for data provides an obvious speed increase. IDE, itself is the other factor responsible for speed where MyIDE is concerned.. Theres much less overhead to the disk handler code when using IDE vs SCSI. Flashjazzcat's handler code is what the MyIDE handler should have been in the first place. It would be nice if the same optimizations could be applied to the KMK/IDEa..

Edited November 23, 2010 by MEtalGuy66

[flashjazzcat]

Its true that using the entire physical sector for data provides an obvious speed increase. IDE, itself is the other factor responsible for speed where MyIDE is concerned.. Theres much less overhead to the disk handler code when using IDE vs SCSI. Flashjazzcat's handler code is what the MyIDE handler should have been in the first place. It would be nice if the same optimizations could be applied to the KMK/IDEa..

Another factor which makes the SDX MyIDE driver more efficient is the use of LBA addressing. IDEa would beat MyIDE by a fraction if it used an LBA BIOS and unrolled loops in the space vacated by the CHS conversions. I've looked at a disassembly of IDEa code, but it's pretty dense. I wouldn't be at all surprised if Draco rises to the challenge, though.

[drac030]

Back in 1994/5, when I was writing the IDE BIOS, there were so many disks which didn't support LBA, that I had no option but to use CHS. I managed to avoid the two divisions which are theoretically required for the CHS->LBA calculation, this is why IDEa is so fast. Of course, unrolling the loops *more* (they're already somewhat unrolled) and getting rid of the CHS->LBA code would speed the device up yet a bit.

 

For now, it can be little bit speeded up by changing the device ID (there are the jumpers on the PCB). Most of the time selecting dev. 0 is the best choice, for both ROM SIO and the default SpartaDOS X 4.4 SIO driver. But the SDX 4.20 will prefer setting the IDEa as dev. 7 (the same if you use the "classic" SIO in SDX 4.4 - i.e. you do SIO /C in config.sys).