Posted By
JamesD
on 2013-08-14
15:35:09
|  Re: Z80 GUI: SymbOS
I'm not sure I'd refer to them as advanced DOSs. More optimized would be more accurate. I'm guessing they are basically DOS 3.3 with patches and some code moved around at the core. Franklin DOS was basically an Apple DOS with faster read/write routines. Beagle Bros just sold a patch for DOS 3.3. I know one DOS was a series of patches that showed up in some articles. I think it was part of 'Apple Assembly Lines'. I remember several patches were published over time that fixed various bugs. I don't think any pre-GS/OS DOS used scatter reads because it requires the faster clocked 65816 and 16 bit registers.
*edit*
I'm not sure what optimizations ProDOS uses but ProDOS pretty much replaced DOS 3.3 for any applications that were compatible.
Logical sector order does matter for DOS 3.3 based DOSs. You have to order it so the next logical sector arrives right after the DOS is done with the previous logical sector for the shortest delay between sectors.
You can read any interleave on any DOS, it will just impact performance.
This is just a hypothetical example but if DOS 3.3 requires an interleave of 4 and you read that on a faster DOS, it will read at the same speed as DOS 3.3. If a faster DOS requires an interleave of 2 and you try to read it under DOS 3.3, it will run slower because the disk has to rotate all the way around before it can see the next logical sector.
If I remember right, you could also skew tracks. Instead of starting them along the same radius of the disk you could have tracks start part of the way through the rotation. This would allow you to read quicker after a track step since the disk wouldn't have to rotate all the way around to start reading the next track. I'm not sure this will work on other drives.
*edit*
FWIW, I don't think any standard DOS used this. It was used more for copy protection than anything but with a custom loader you could use it as a speedup. I *think* I remember there being a format utility that could create such disks though. I don't know for sure, that was a long time ago.
GS/OS is a standard DOS, and so was DOS 2.
If you want the minimum speed, you need to go with something pre-DOS 3.3 that has fewer sectors per track.
If you want to know what the interface is capable of on a 6502 machine you need to go with a modified DOS.
If you want to know what that hardware is really capable of, you need to use GS/OS.
It certainly wouldn't hurt to know the difference in speed between DOS versions.
*edit*
At the very least you should check ProDOS because it pretty much became the standard from 1983 on and came out before the +4 and the 1551 which you are comparing against.
BTW, I found this comment in a section about ProDOS:
"Another problem with DOS was speed. Since each byte read from the disk was copied between memory buffers three times, much of the disk access time was spent in moving things around in memory."
So transfer speed isn't all you are measuring in DOS 3.3 when you benchmark it, you are measuring 3 memory copies.
FWIW, your "fact" is one benchmark loading one file from a disk with an unknown interleave, with unknown fragmentation and I'm guessing it's hand timed. Not exactly very scientific.
With the Apple II, all you have to do to switch DOS versions is swap disks, it's not like swapping ROMs like JiffyDOS on the Commodore machines. There were fast loader carts but some didn't support high speed writes and they didn't work with all programs.
I do remember a fast loader appearing in a magazine and they had versions for C64, VIC20 and I believe someone ported it to the +4. It's big drawback was that you had to load it from disk before you could use it and it only works on serial drives. The Apple II bootstraps DOS as well but it's over a faster parallel connection.
The 1551 should be able to top 4KB/sec but it's driver is in ROM making it impossible to patch unless you can move it to RAM. Part of the limit on Commodore machines may be that DOS is separated into the computer layer and the drive layer. The 1551 should be able to skip some of the overhead but I'm not familiar enough with Commodore machines insides to really know.
FWIW, if you want higher speeds there are several options.
A drive supporting double sided disks can alternate reading between disk sides and will step less between tracks. A simple bit of logic is usually all that is required to select between disk sides. It only requires setting one signal to select between sides of a disk. Sadly, the only times I saw it used was as a 2nd drive. The CoCo commonly used a drive select line to select sides.
CoCo disk controllers have been modded with faster clocks and some additional logic to support high density. It also requires a custom DOS ROM or people just use OS-9. High density has a higher transfer rate. The more common mod is to use 3.5" disks to get more storage space because it's a simple mod requiring patching the max number of tracks.
Another way to speed up drives in software is disk cache or RAM drive. There were several Apple II programs that used the language card memory or other memory expansions for this. It's not very useful for speeding up loading a single small program but for a lot of reading and writing it offers a considerable speedup. There were custom drivers for various memory cards from different manufacturers or the Apple IIe memory expanders.
Someone even replaced the 4116 RAM chips on an Apple II clone motherboard with 4164's and added some additional logic. The circuit should work with most Apple II/II+ and clone machines. They published code for a RAM disk driver. I'm sure similar things were done or could be done with the +4. It would certainly have more to gain with serial drives but you loose the benefit of caching the directory info. The 1541 itself could cache if it had enough RAM but with the serial connection I'm not sure there would be as much benefit. The 1551 would certainly benefit.
Since the +4 BASIC uses all 64K I think you'd want at least 128K to use cache and you'd want to put the driver in ROM similar to JiffyDOS. For a RAM drive you'd probably want even more RAM.
The Apple IIgs actually includes a RAM drive which is very handy for files that are read or written a lot. I use it for include files and parts of the compiler when I'm using my C compiler on the machine. Due to the number of small files and seeks/reads on a disk drive the performance gain is huge. It requires time to load the drive but once loaded it's very fast. Since buying the CF interface I haven't bothered but the RAM drive should still be still faster. My IIgs has a 4GB RAM expansion card on top of the normal system RAM so I have plenty of RAM.
@MMS,
The 1571 boost mode is actually the original speed Commodore drives were intended to communicate at. Drives would have started up at that speed if it weren't for the VIC hardware bug. Too bad the +4 didn't support it. It's actually the drive I use with my +4.
I've always wondered why they didn't include it as an option all along for future machines.
*edit*
The book 'Beneath Apple ProDOS' says that ProDOS can transfer diskette data at the rate of up to 8K per second.
|
