A2091ToFast: Even more A2091/A590 speedup possible!

SpeedGeek

Member
AmiBayer
Joined
Jan 21, 2011
Posts
934
Country
USA
Region
Wisconsin
A2091ToFast V2.5
Original code by Chris Weber 1998 (Aminet). Updated and enhanced by SpeedGeek 2015.

INTRODUCTION:
A2091ToFast copies the A2091/A590 ROM code into Fast memory similar to the CPU FastROM command but does not require an MMU. This allows it to work with many other CPUs which don't have an MMU or free the MMU to perform other tasks. More importantly, it can speed up the execution of the SCSI driver code by SEVERAL HUNDRED percent!

Note: Zorro2 Fast memory and Zorro2 ROMs operate at the same bus speed so there is no benefit to using A2091ToFast on a "Bog Standard" 7 MHz 68000. However, unlike the Zorro2 ROMs the Zorro2 Fast memory can be cached so the L2 cache on some 68000 accelerators (or the L1 cache on 68020+ accelerators) may still realize some benefit.

I've uploaded RSCP images showing PIO speed on my system is now a little faster than original DMA speed (and much faster than ROM based PIO speed). Enjoy!

P.S. If I were AndyLandy I would not be surprised it's possible to squeeze a few more drops of performance from our trusty old C= SCSI controllers! ;)

Here is the link to images and downloadable files:

http://eab.abime.net/showthread.php?t=69839
 
Last edited:
Excellent mod.... you should change your name to Dave Haynie :LOL:
 
Haven't checked what the code actually does, but the os does not execute driver code on zorro2 cards from their rom.

The content is copied into system memory at boot and ends up in whatever fully autoconfig memory that has the highest priority, which should be your fastest ram unless you have a quirky mem-expansion. Just check under devices in say sysinfo to see what's the case.

If you have a quirky expansion the driver could end up I'm chipmem though.
 
P.S. If I were AndyLandy I would not be surprised it's possible to squeeze a few more drops of performance from our trusty old C= SCSI controllers! ;)

With guys like you around, the sky really is the limit! It wouldn't surprise me if one of these days you'll have an Amiga running a 500MHz 68k CPU core and a custom Zorro bus that runs at 1:1 with it! :LOL:

Awesome stuff on the mods there. It never ceases to amaze me what folks (you in particular) seem to be capable of making our old hardware do!

(y)
 
@Paul_s
I might be able to pull that off in U.K. but here in U.S.A. I could easily get sued for defamation of character, slander, theft of intellectual property, etc.! :LOL:

@mfilos
I didn't even know you had an A2091/A590 my friend! But I'm happy to see your full report: mfilos = Beta tester par excellence! :)

@Patrikax
Sorry, most expansion ROM drivers don't get copied into any memory (the Guru ROM being a notable exception here). What does get copied in memory is the ConfigDev info for the device and a jump table for any libraries or task structures used by that particular driver.

@Thread
Here is some interesting info from the Amiga RKRM:
"The A2091, A590 and A3000 drivers always do programmed I/O for data transfers under 256 bytes or when the DMA chip doesn't support the required alignment."
 
Last edited:
Are you sure about them not being copied to system ram in the general case?

It's very long time since I messed with that stuff, but I remember that there were provision even for supplying the driver rom as 4-bit wide rom (indicated somehow via autoconfig) and the 68000 could not run code directly from such a rom.

So got the impression that in the general case stuff was copied. Of course you should be able to do solution where you point to the rom instead in a small init code (if it is presented as 16-bit on the bus), letting the CPU execute directly from it and save a little bit of memory.
 
Last edited:
Are you sure about them not being copied to system ram in the general case?

Yes, I'm quite sure. In post #1 I've uploaded an RSCP image for ROM based PIO on the same system. It takes several minutes to run the test and the results speak for themselves!

Also, it appears as though you have confused Auto-Config ROM with expansion driver ROM. ;)
 
Not saying that the A2091 doesn't run the code directly from the rom - it is after all a card with double eproms (odd/even) design which would be a quite unecessary if the rom data is just copied to ram.

However, the general case - zorro2 cards usually only have one 8-bit rom with very slow access time (200ns). Even with the logic to deliver it 16-bit at a time to the cpu to allow execution to even take place, it would result in slow execution times of the driver code even on a plain 68000 and should be a well known performance problem of cards with cpu-intensive code, say PIO-only cards.

I found the rkrm libraries part I remembered about the copying (DiagArea):
http://gega.homelinux.net/AmigaDevDocs/lib_32.html#32-3-3-1
 
interesting.. so according to that, there is no general answer to this, as it depends on the expansion board in question how much is copied to ram..

There may not be a general answer for all expansion boards but there maybe one for specific board manufacturers (i.e. many C= boards have 2 ROMs and many GVP boards have 1 ROM so it's much more likely that the single ROM boards will copy their drivers into RAM rather than operate at 1/2 speed).

But this thread is about C= boards and ROMs which don't copy their drivers into RAM. So as far as I'm concerned, it's neither relevant nor necessary to discuss those which do.
 
** NEWS UPDATE **

V2.1 released - even more improvements!
- Added code to scan ROMs for driver size
- Removed Debug symbols to make smaller executable
- Added version string
- Error messages updated
 
** 2ND NEWS UPDATE **

V2.2 released - new feature speeds up direct calls to scsi.device!
- Added code to patch scsi.device resident structure vectors
to FastMem image
- Fixed size calculation of ROM driver size scan
- Removed 2 lines of redundant code
 
** 3RD NEWS UPDATE **

V2.3 released - minor update
- Added code for 2nd.scsi.device resident structure patching
since V2.2 was useless to A4000 owners
 
** 4TH NEWS UPDATE **

V2.4 released - A2091ToFast can now be installed before other programs which patch scsi.device
- Added code to update checksum after resident structure patching
- Added code to patch SCSI interrupt vector to FastMem image
- Replaced Disable() - Enable() pairs with Forbid() - Permit() pairs
- Some more code optimizations done

Update:
*V2.4 can now be installed before other programs which patch
scsi.device. This means vbak2091 can benefit from patching it's code to
the FastMem image. It also means OS3.5+ users who NSDpatch
scsi.device will need to run vbak2091 before Setpatch. So A2091ToFast
will need to be installed before Setpatch with the above configuration.
 
** 5TH NEWS UPDATE **

V2.5 released - Added support for C= V8.0 (40.20) ROMs
- Added new code to support both V7.0 and V8.0 ROM stack offsets
- Removed all task busy error handling code which really wasn't needed
- Reduced executable size with more PC relative code
 
Great work SpeedGeek!
i will try it as soon as i return home from work (first days of August) i'm very curious to see how it work on my Microbotics VXL-30 32bit fast ram
 
Had no idea 8.0 ROMs existed even ?. Is it an official release, or what is the story about them?
 
No, it's not an official release. It's based on some buggy v40.xx versions of scsi.device from 1993 which were never released by C=.

Some v8.0 have already been released by Matze (with a patch for the Aztec Monster). But the latest v8.0 is not for the Aztec Monster, it's to make the device faster and add a new feature (support for RDBF_SYNCH).

I hoped he would release the latest version with his earlier releases but I have not heard anything from him recently. ;)
 
Last edited:
Back
Top Bottom