NEW MIO production run.

[Allas]

Yes,

 

- Is that 256byte bank could be relocatable in any page from the main memory? If the answer is yes, that banking is very powerful, because let to change fonts, unique sprites, etc. Better control that the 16K banking scheme.

 

- Is the banking as fast as the 130XE banking?

 

- Have MIO device a internal clock for Sparta OS system?

[+warerat]

Yes,

 

- Is that 256byte bank could be relocatable in any page from the main memory? If the answer is yes, that banking is very powerful, because let to change fonts, unique sprites, etc. Better control that the 16K banking scheme.

 

- Is the banking as fast as the 130XE banking?

 

- Have MIO device a internal clock for Sparta OS system?

 

The internal MIO memory (when enabled) is accessible from $D600-$D6FF. This is fixed can cannot be relocated. It is accessed like any location in memory, so yes, it's no different from switching regular 16K banks except the window is smaller. One megabyte of memory requires 20 address bits. Your first eight lower addresses (A7-A0) come directly from the CPU (256-bytes), the next eight (A15-A8) from a latch at $D1E0, and the last four (A19-A16) from half of a latch at $D1E2.

 

Not quite sure what you mean by the speed. Only penalty would be you'd have to switch pages every 256-bytes (as opposed to every 16K), and switch banks (high-order A19-A16) every 64K.

 

The stock MIO doesn't have a RTC although including one in the expansion board is a good possibility.

Edited August 17, 2008 by warerat

[+Larry]

It's good to know many Atari users are interested,... but until now, I don't understand what is a MIO.

I have the idea is a device that provide SCSI ports to the XL, XE series using the PBI port. So, I see, the useful thing is that I can use SCSI HDs, printers on it.

 

Is there other advantages I am losing? For example, all this memory on the MIO is only for buffer purposes or it works like an memory expansion?

 

As it stands, the MIO provides the following.

1) scsi/sasi interfave used mostly for Hard drives.

2) parallel printer interface compatible with PC printer cables.

3) 64K printer buffer (default) tho that size can be set to any size upto the limit of ram on the mio

4)RS232 serial interface capable of 19200 baud.

5)extra ram used as disk drive. This is the fastest drive on the 8 bit, bar none. depending on the size of ram, a 1 gig drive can be set up.

The ram can be broken in to 8 parts to emulate 8 floppy drives if you want and the ability to boot from them. I have setup bootable games on the MIO and the speed they load at.......

 

From my under standing, future expansion plans include.

ability to address 16 meg of ram. Just think, fastest drive at 16meg. niiiiiiiiiiiice.

Plans for a 80 coloum display board.

Updates to firmware to include support for more scsi devices including cd roms

 

James

 

Hi James-

 

Well, almost the fastest... The XE internal ramdisk is slightly faster, but not by very much. And the KMK/JZ interface is faster using SDX with 512-byte sectors. Check out the the last page of this thread where all the benchmarks are summarized:

 

http://www.atariage.com/forums/index.php?s...26074&st=40

 

But there still may be some "apples to oranges" in these numbers. The MIO is still a killer piece of hardware -- just wish I'd gotten a 1-MB instead of 256-KB. But at the time I bought mine, there was a "ram shortage" and the 1-MB's were out of sight. Good as the BB? Maybe not quite since the BB has such good firmware. IMO, of course.

 

-Larry

[MEtalGuy66]

Well, the only thing I'd add to that is that the hugest bottleneck in any of those systems is the code that the atari runs to access them. Thus, the speed differences between any 1 RAMDISK and another is determined by the DOS and HANDLER, not the hardware.

 

ANd from a coding standpoint, at least with sector copies, the MIO RAMdisk has the potential to out perform a standard (16k banked) ramdisk because of the 256byte bank size.

 

With DOS copies of files, there is so many variables depending on dos and handler code, its totally "up in the air" as far as whose is faster and why..

 

Using an assembly language routine written specifically for the task, raw contiguous data can be "mirrored" from internal atari ram to the MIO ram at speeds approaching (or even exceeding) 100k/second. This is a moot point, as far as real-world ramdisk useage goes, but it serves to show that its not the hardware that imposes these speed limitations.

 

One thing is for sure, the 6502 can read/write a byte of ram at $D600(MIO) at exactly the same speed that it can read/write a byte of ram at $4000(ATARI EXTENDED RAM BANK)....

 

As far as hardisks go... heh. Well, I didnt write the MIO SCSI code... And it could obviously be optimized and improved in MANY ways. But youve also gotta remember that the range of drive compatability that it currently supports limits you to some pretty archaic and slow-assed old drives... Once we get the MIO firmware working with some more modern/faster devices, we'll see what we can do about increasing the speed/efficiency...

Edited August 17, 2008 by MEtalGuy66

[ijor]

Q: Can we get the components from you and assemble them ourselves?

 

No.

 

No MIOs are leaving my hands, that I dont have the opportunity to test to a 100% functional state.. This is a temperamental device, and I am not in any way willing to provide the level of support (and open the "can of worms") that would be necessary to start offering them in various stages of assembly.

 

That is very reasonable. But would you publish schematics? Either for your own version, or the (reverse engineered) schematics of the original ICD design, or both?

 

Many of us are would be very interested in getting schematics for the MIO. And for reasons not related in anyway to assemble, manufacture, or produce a MIO.

[MEtalGuy66]

Q: Can we get the components from you and assemble them ourselves?

 

No.

 

No MIOs are leaving my hands, that I dont have the opportunity to test to a 100% functional state.. This is a temperamental device, and I am not in any way willing to provide the level of support (and open the "can of worms") that would be necessary to start offering them in various stages of assembly.

 

That is very reasonable. But would you publish schematics? Either for your own version, or the (reverse engineered) schematics of the original ICD design, or both?

 

Many of us are would be very interested in getting schematics for the MIO. And for reasons not related in anyway to assemble, manufacture, or produce a MIO.

Heh. The schematics have been posted on Atariage MANY times.. and I dont care if you reverse engineer or reproduce it.. hahah.. Its not "My design"..

Actually, I have compiled an entire service manual for it, which I will release soon.. I am working on the final section of it which deals with ATARI PHI2 clock signals and PBI device stability. Im taking screen shots of waveform comparissons using my 4-channel digital scope and including them for reference.. But I want to make sure I cover all possible 6502C CPU models, so that it's complete and comprehensive. I just have to get around to doing the last few "setups" for that..

 

Anywayze, I will release the complete manual.. I just want it to be complete when I do...

So far, its about 75 printed pages...

 

as far as the ORIGINAL ICD schematics go, You can do a search on these forums.. Several people have posted them. If I run across them, Ill post those as well..

[ijor]

Heh. The schematics have been posted on Atariage MANY times..

 

Found it. My initial local search and google didn't come up with anything, but I guess I missed it. Thanks.

[sup8pdct]

Hi James-

 

Well, almost the fastest... The XE internal ramdisk is slightly faster, but not by very much. And the KMK/JZ interface is faster using SDX with 512-byte sectors. Check out the the last page of this thread where all the benchmarks are summarized:

 

http://www.atariage.com/forums/index.php?s...26074&st=40

 

But there still may be some "apples to oranges" in these numbers. The MIO is still a killer piece of hardware -- just wish I'd gotten a 1-MB instead of 256-KB. But at the time I bought mine, there was a "ram shortage" and the 1-MB's were out of sight. Good as the BB? Maybe not quite since the BB has such good firmware. IMO, of course.

 

-Larry

 

I did my tests comparing loading pictures one after the other, The MR 'T' demo that loads from disk.

A more real world application. The MIO was about twice as fast comapred with internal ramdisk.

Think about it for a minute. Say the pics load from $6000 to $67ff.

The internal ram disk cannot copy data directly from a banked ram to the main bank so some form of bufffer must be used or a lot of bank switching is used just to copy 128/256 bytes.

That means copying data twice.

The MIO ramdisk can copy data directly to destination with out the buffer. only once so there fore twice as fast.

What ever was used to get those benchmarks, did it take into acount the window area? or was it just getting the same sector over and over?

 

James

[sup8pdct]

1.) The 6551 UART (used in the MIO and BLACK BOX) is capable of 115kbps serial operation. If you dont believe this, look at the datasheet, and then ask Apple II users who do it all the time (Its implemented the exact same way in both of the apple IIc serial ports, as well as the Super Serial Card for the IIe/II+ as it is in the MIO and Blackbox. even clocked at the same exact frequency, but the Apple hardware doesn't even have the handshaking lines connected!). This amounts to a simple and minor change to the serial handler (ROM).. You totally cant compare a P:R connection, Rverter, 850 interface, or any other SIO connected serial port solution to the MIO or BLACK BOX serial ports..

 

Yea. what data sheet is that speed listed on? I have looked at 3 and max speed is 19200 with standard crystal.

the MIO has a 1.8xxx speed crystal so no speed advantage there. unless you plan to change the crystal either on the fly via hardware or install a different crystal in new versions.

 

James

Edited August 18, 2008 by sup8pdct

[+Larry]

Hi James-

 

Well, almost the fastest... The XE internal ramdisk is slightly faster, but not by very much. And the KMK/JZ interface is faster using SDX with 512-byte sectors. Check out the the last page of this thread where all the benchmarks are summarized:

 

http://www.atariage.com/forums/index.php?s...26074&st=40

 

But there still may be some "apples to oranges" in these numbers. The MIO is still a killer piece of hardware -- just wish I'd gotten a 1-MB instead of 256-KB. But at the time I bought mine, there was a "ram shortage" and the 1-MB's were out of sight. Good as the BB? Maybe not quite since the BB has such good firmware. IMO, of course.

 

-Larry

 

I did my tests comparing loading pictures one after the other, The MR 'T' demo that loads from disk.

A more real world application. The MIO was about twice as fast comapred with internal ramdisk.

Think about it for a minute. Say the pics load from $6000 to $67ff.

The internal ram disk cannot copy data directly from a banked ram to the main bank so some form of bufffer must be used or a lot of bank switching is used just to copy 128/256 bytes.

That means copying data twice.

The MIO ramdisk can copy data directly to destination with out the buffer. only once so there fore twice as fast.

What ever was used to get those benchmarks, did it take into acount the window area? or was it just getting the same sector over and over?

 

James

 

Hi James-

 

Interesting test. Yes, I can see the effect you describe.

 

Drac030's RWTEST was used for all those tests. The benchmark test is at

 

http://drac030.krap.pl/en-inne-pliki.php

 

But a somewhat different test than you describe. Drac030 explained in the ICD Multi-I/O thread:

 

" The program works as this:

 

1) open the file for write

2) get clock state

3) write, write, write, write

4) get clock state

5) close

6) calculate & display the result

 

And the same for reading."

 

I guess -- different benchmark, different result. So I take it back -- sometimes it's not the fastest...

 

-Larry

[MEtalGuy66]

1.) The 6551 UART (used in the MIO and BLACK BOX) is capable of 115kbps serial operation. If you dont believe this, look at the datasheet, and then ask Apple II users who do it all the time (Its implemented the exact same way in both of the apple IIc serial ports, as well as the Super Serial Card for the IIe/II+ as it is in the MIO and Blackbox. even clocked at the same exact frequency, but the Apple hardware doesn't even have the handshaking lines connected!). This amounts to a simple and minor change to the serial handler (ROM).. You totally cant compare a P:R connection, Rverter, 850 interface, or any other SIO connected serial port solution to the MIO or BLACK BOX serial ports..

 

Yea. what data sheet is that speed listed on? I have looked at 3 and max speed is 19200 with standard crystal.

the MIO has a 1.8xxx speed crystal so no speed advantage there. unless you plan to change the crystal either on the fly via hardware or install a different crystal in new versions.

 

James

 

Look at the baud rate setting... And look what happens if you set all 4 bits to zeros... The Apple II also uses a 1.8xxx crystal.. and Im here to tell you, it DOES work at 115k..

 

With bits 0-3 of the control register all set to zeros, the baud rate is the external clock (divided by) 16..

 

The MIo uses a 1.8432mhz crystal to clock the 6551.. (as does the Apple II)...

 

1,843,200 / 16 = 115,200... bits per second...

Edited August 18, 2008 by MEtalGuy66

[+warerat]

Yea. what data sheet is that speed listed on? I have looked at 3 and max speed is 19200 with standard crystal.

the MIO has a 1.8xxx speed crystal so no speed advantage there. unless you plan to change the crystal either on the fly via hardware or install a different crystal in new versions.

 

James

 

It's true. The card he's referring to is the 6551-based Apple Super Serial card:

 

http://compuhaven.net/index.php?option=com...mp;ascdesc=DESC

http://compuhaven.net/pub/Comp/AppleII/App...SuperSerial.jpg

 

Stock 1.8432 MHz crystal.

 

Whether or not we can really sustain that rate without dropping characters is another story.

[drac030]

Drac030's RWTEST was used for all those tests. The benchmark test is at

 

http://drac030.krap.pl/en-inne-pliki.php

 

But a somewhat different test than you describe. Drac030 explained in the ICD Multi-I/O thread:

 

" The program works as this:

 

1) open the file for write

2) get clock state

3) write, write, write, write

4) get clock state

5) close

6) calculate & display the result

 

And the same for reading."

 

I can add that the benchmark dumps 4x16k from the memory to a file, and then reads the file back. And, obviously, a hard disk is (or at least should be) faster than the internal ramdisk, for the reasons explaine. Although the buffer, in fact, can be avoided, or strictly speaking reduced to 1 byte which fits in the accumulator. But the hard drive will (should) still be faster, because either no buffer or no bank switching is necessary.

[ijor]

Stock 1.8432 MHz crystal.

Whether or not we can really sustain that rate without dropping characters is another story.

 

The 6551 can of course do 115,200 bps with the 1.8432 MHz standard crystal. But it is indeed an interesting question if it is usable on an Atari.

 

The Atari can probably sustain that rate, but only on a closed loop as it is done by high speed SIO routines. You wouldn't be able to use an interrupt based routine. A closed loop solution is fine for SIO, because the computer controls the transfer and it knows exactly how many bytes are incoming. A generic terminal software can't use this approach, because it usually has no idea about what the other side would send or when.

 

Perhaps an application that would do file transfers, and not a generic terminal program, is doable.

 

For the records, a modern PC would also have a hard time using 115,200 with a 6551 (it can, but only because the PC Uart has a FIFO buffer). One reason is of course, the software lattency of the OS. But also the hardware has a huge interrupt lattency.

Edited August 18, 2008 by ijor

[MEtalGuy66]

Stock 1.8432 MHz crystal.

Whether or not we can really sustain that rate without dropping characters is another story.

 

The 6551 can of course do 115,200 bps with the 1.8432 MHz standard crystal. But it is indeed an interesting question if it is usable on an Atari.

 

The Atari can probably sustain that rate, but only on a closed loop as it is done by high speed SIO routines. You wouldn't be able to use an interrupt based routine. A closed loop solution is fine for SIO, because the computer controls the transfer and it knows exactly how many bytes are incoming. A generic terminal software can't use this approach, because it usually has no idea about what the other side would send or when.

 

Perhaps an application that would do file transfers, and not a generic terminal program, is doable.

 

For the records, a modern PC would also have a hard time using 115,200 with a 6551 (it can, but only because the PC Uart has a FIFO buffer). One reason is of course, the software lattency of the OS. But also the hardware has a huge interrupt lattency.

 

That's true.. There is no question that it would require dedicated software.

 

One application, for which it works extremely well on the Apple, is the transfer of disk images to/from a PC.

 

Theres a program called ADT (Apple Disk Transfer) that can turn an Apple .DSK image from the internet into a physical floppy on your apple with AMAZING SPEED. It runs at 115kbps over the serial port.

 

Because of the fact that the Apples have their floppy controller chip internal to the machine, the "Apple Version of SIO2PC" ends up requiring a very complex device. There is a guy who builds these, but they cost about $200.00 each. This is outside the price range of what most people are willing to pay. So instead, they have a program that reads entire floppy disks and sends them over the serial port to a PC, or vice versa...

 

I used this program to make floppys of about 50 or 60 disk images (The entire Bard's Tale, Ultima, Wizardry collections, as well as many other games), and it was unbelievably fast, and I never saw a single error.. And the nullmodem cable I was using to go from my Apple IIC to the PC was made out of an old PC mouse cord with a DIN connector soldered on the opposite end.. Not exactly a "high quality shielded cable".

 

Apple Disks are 143k each, and I was hard pressed to have enough time to write the label of the next disk before the current disk was done!

 

I also used this system to transfer all of my brother's old home-brew Apple II program disks to the PC so that he could "relive his youth" with an emulator... It was just as fast going from "Apple Floppy to PC Disk image" as it was going from "PC Disk image to Apple Floppy."

 

 

Given: this is two pieces of dedicated software that run on "both ends"...

 

But imagine This...

 

We write rom resident handler code that uses some of the MIO RAM as a dedicated sector buffer, and enables 2 MIO equipped ATARI's (connected to eachother via a high quality shielded null-modem cable at the MIO serial ports) to share storage devices connected to the SIO port of either machine.

 

This could be a really kewl feature to add to the new "expanded MIO" firmware..

Edited August 18, 2008 by MEtalGuy66

[DamageX]

Maybe the faster bitrates would come in handy when using a terminal program on the MIO's planned 80-column display module. With ANTIC turned off it could handle more frequent interrupts.

 

For file transfers between machines I would expect parallel to be faster. Does the MIO's parallel port have all the status/etc. lines connected so we can get 4-bits in each direction? I know the Amiga's p port was missing at least one of the inputs so parallel Zip drives could not be used, and file transfers using a standard cable used a slower protocol. It would be cool if a parallel Zip drive could be used on the A8. (Of course that would require a driver. Might as well focus on supporting more devices on the SCSI bus first)

Edited August 18, 2008 by DamageX

[Mathy]

Hello DamageX

 

The parallel version of the ZIP drive uses some kind of crippled SCSI protocol. After SCSI support has been improved, the SCSI version of the ZIPdrive shouldn't be a problem. I've used a SCSI ZIPdrive on my BlackBox for years. I see no reason why the MIO wouldn't work with a SCSI ZIPdrive either after the planned update has been finished.

 

Greetings

 

Mathy (who'ld love to see his BlackBox's 6551 do 115kbps)

[MEtalGuy66]

Mathy (who'ld love to see his BlackBox's 6551 do 115kbps)

 

So would I... Among other things... Can you convince Bob Puff to un-ass the source code for the ROM?

 

I mean the REAL ORIGINAL commented source for the latest & greatest firmware version...

 

IF you had that, it would be no problem to enable 115k serial operation.. However, as stated above, it's not likely to be very error-free by just turning on the fast baud rate and using the existing firmware handler.. Youd almost certainly want to turn OFF the Black Box R: device, and manipulate the hardware directly in any such "high speed" communications applications..

 

The reason I'd like to see the Black box rom, is to get some idea of a "standard" to implement as far as SCSI compatabliltiy for the MIO. Im not talking about stealing features of the black box scsi code, but if I can make the MIO's SCSI code work closer to that of the black box, it serves to unify the standard for applications somewhat..

 

I can certainly "un invert" the data in the MIO SCSI, and come up with a routine for handling 512byte sectors.. But Id hate to do it in such a way that widens the compatability gap, rather than closes it.. unification of standards is the only way to keep the scope of development at a decent level in a scene like the ATARi 8-bit.. This is why I chose to replcate the MIO in the first place..

 

The Black Box will alwayse be far superior to the MIO in terms of a disk controller (and so much more) and this is due to superior hardware design. But there are alot of MIOs out there... And to bring the MIO closer in terms of compatability standards increases the development interest in the user base for both devices..

[ijor]

Mathy (who'ld love to see his BlackBox's 6551 do 115kbps)

 

So would I... Among other things... Can you convince Bob Puff to un-ass the source code for the ROM?

I mean the REAL ORIGINAL commented source for the latest & greatest firmware version...

 

That would be great indeed. And I would add, that if somebody can convince Bob to release sources, he might very well release sources and schematics for other CSS products as well. Most were already reserve engineered to some degree. But, i.e, the only thing I've seen regarding the Bit Writer was just a picture

 

Now Ken, you in turn, might try to convice Steven to release the MIO firmware sources. And I mean, as you did, the original commented sources he has. You might get then, even more chances of other people improving the MIO firmware.

 

Yeah, I know, not exactly the same thing. Bob is the copyright holder for the BB ROM, and Steven is not for the MIO. Still ...

[MEtalGuy66]

Mathy (who'ld love to see his BlackBox's 6551 do 115kbps)

 

So would I... Among other things... Can you convince Bob Puff to un-ass the source code for the ROM?

I mean the REAL ORIGINAL commented source for the latest & greatest firmware version...

 

That would be great indeed. And I would add, that if somebody can convince Bob to release sources, he might very well release sources and schematics for other CSS products as well. Most were already reserve engineered to some degree. But, i.e, the only thing I've seen regarding the Bit Writer was just a picture

 

Now Ken, you in turn, might try to convice Steven to release the MIO firmware sources. And I mean, as you did, the original commented sources he has. You might get then, even more chances of other people improving the MIO firmware.

 

Yeah, I know, not exactly the same thing. Bob is the copyright holder for the BB ROM, and Steven is not for the MIO. Still ...

 

Theres alot of people who have various MIO source code versions... The ones Steve has dont even build stable working ROMs.. They do give some kind of idea how things are being done though..

 

Basically, a comolete rewrite of the firmware is gonna be necessary to do anything worthwhile..

[sup8pdct]

Drac030's RWTEST was used for all those tests. The benchmark test is at

 

http://drac030.krap.pl/en-inne-pliki.php

 

But a somewhat different test than you describe. Drac030 explained in the ICD Multi-I/O thread:

 

" The program works as this:

 

1) open the file for write

2) get clock state

3) write, write, write, write

4) get clock state

5) close

6) calculate & display the result

 

And the same for reading."

 

I can add that the benchmark dumps 4x16k from the memory to a file, and then reads the file back. And, obviously, a hard disk is (or at least should be) faster than the internal ramdisk, for the reasons explaine. Although the buffer, in fact, can be avoided, or strictly speaking reduced to 1 byte which fits in the accumulator. But the hard drive will (should) still be faster, because either no buffer or no bank switching is necessary.

 

The harddisk read/write speed all depends upon how the interface has been designed. if it has its own precessor then I would expect a fast interface but I don't know of any . A interface that uses the 6502 do do all the work will have a transfer overhead and device command generation and handshacking which takes time.

 

James

[sup8pdct]

1.) The 6551 UART (used in the MIO and BLACK BOX) is capable of 115kbps serial operation. If you dont believe this, look at the datasheet, and then ask Apple II users who do it all the time (Its implemented the exact same way in both of the apple IIc serial ports, as well as the Super Serial Card for the IIe/II+ as it is in the MIO and Blackbox. even clocked at the same exact frequency, but the Apple hardware doesn't even have the handshaking lines connected!). This amounts to a simple and minor change to the serial handler (ROM).. You totally cant compare a P:R connection, Rverter, 850 interface, or any other SIO connected serial port solution to the MIO or BLACK BOX serial ports..

 

Yea. what data sheet is that speed listed on? I have looked at 3 and max speed is 19200 with standard crystal.

the MIO has a 1.8xxx speed crystal so no speed advantage there. unless you plan to change the crystal either on the fly via hardware or install a different crystal in new versions.

 

James

 

Look at the baud rate setting... And look what happens if you set all 4 bits to zeros... The Apple II also uses a 1.8xxx crystal.. and Im here to tell you, it DOES work at 115k..

 

With bits 0-3 of the control register all set to zeros, the baud rate is the external clock (divided by) 16..

 

The MIo uses a 1.8432mhz crystal to clock the 6551.. (as does the Apple II)...

 

1,843,200 / 16 = 115,200... bits per second...

 

Ahhh, that end of the table. I was looking at the fast end, not the slow end.

I see it now. Must find those glasses I never owned and wear them..........

 

James

[drac030]

The harddisk read/write speed all depends upon how the interface has been designed. if it has its own precessor then I would expect a fast interface but I don't know of any . A interface that uses the 6502 do do all the work will have a transfer overhead and device command generation and handshacking which takes time.

 

Actually, I think that an interface with own CPU may actually be slower than the one without, because own CPU = (one more) intermediate buffer for data between the disk and the computer. Plus, you of course fall into temptation of tranferring data from that processor to 6502 in 8-bit portions (instead of 16-bit in case of IDE), and this also reduces the speed a bit. I don't know for SCSI, but for IDE there is little overhead in command generation, except that in CHS mode you have to do two divisions, and so to reduce the overhead imposed by this, your divide routine must be really fast. Using an interface with own fast CPU solves this, but other things I said above still apply (and there is no difference in handshaking in this case). To avoid divisions you can use LBA, but not every drive supports this mode (sure, new drives all have LBA, but relics like Seagate ST-225A do not).

 

Anyway, a disk that can read raw sectors (with minimum possible calculations) at 80-100 KB/s, and that can do 60-64 KB/s while reading a file (i.e. with the overhead imposed by DOS), is rather fast, i.e. the firmware reduces the overhead to absolute minimum.

[Mathy]

Hello Ken

 

Can you convince Bob Puff to un-ass the source code for the ROM?

 

I mean the REAL ORIGINAL commented source for the latest & greatest firmware version...

 

Commented source? ... From Bob Puff? Even the greatest geniusses (??) can't be great at everything.

 

Can't promise you I'll call him. I'm on a different continent, among other things.

 

Greetings

 

Mathy

[DamageX]

Anyway, a disk that can read raw sectors (with minimum possible calculations) at 80-100 KB/s, and that can do 60-64 KB/s while reading a file (i.e. with the overhead imposed by DOS), is rather fast, i.e. the firmware reduces the overhead to absolute minimum.

The I/O could be a good bit faster on a cleverly designed interface. Let's take something like the MyIDE cartridge as an example. It has a data register at $D500 IIRC, and you read it 256 times to get a sector. Normally one might use a routine like this:

 

LDX #0

foo:

LDA $D500

STA somewhere,X

INX

BNE foo

 

15 cycles per byte right?

 

Now imagine that the hardware was setup so that the data register was mirrored at $D511, with the opcode for a LDA immediate instruction preceding it at $D510. Then at $D512 you'd have a STA absolute/indexed instruction, followed by a 16-bit register that would be loaded with the destination address beforehand. After that, the INX and BNE instructions. Now we just do a JSR $D510 and the hardware presents the CPU with a routine that is effectively this:

 

$D510 LDA #data

$D512 STA somewhere,X

$D515 INX

$D516 BNE $D510

 

That saves 2 cycles per byte. It could still be better. If we make the address at $D513 increment by itself, we can lose the INX. For the branch we can use the overflow flag, and have the hardware toggle the oft-ignored SO pin on the CPU to change the flag when the I/O is complete.

 

$D510 LDA #data

$D512 STA somewhere

$D515 BVS $D510

 

Now we have 11 cycles per byte which is well over 100KB/s. Any of these loops could also be "unrolled" a bit to reduce the overhead of branching.