Amiga.org
Amiga computer related discussion => Amiga Hardware Issues and discussion => Topic started by: SpeedGeek on June 30, 2013, 12:22:28 AM
-
Here is a link to this thread:
https://eab.abime.net/showthread.php?t=69839 (https://eab.abime.net/showthread.php?t=69839)
-
** 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
-
Sorry my question is a little off topic, but, perhaps you know.
In an A2000 system with a 32-bit accelerator and 32-bit fast ram, is there any improvement in the A2091's performance by adding the 2 Megs of 16-bit Fast Ram to the card itself? Faster DMA? More buffer?
In a purely 16-bit A2000 (No 32-bit accel or mem), does the A2091 perform better when populated with those same 2 Megs of Fast versus having all the Fast Ram on a separate ram expansion?
-
In an A2000 system with a 32-bit accelerator and 32-bit fast ram, is there any improvement in the A2091's performance by adding the 2 Megs of 16-bit Fast Ram to the card itself? Faster DMA? More buffer?
In a purely 16-bit A2000 (No 32-bit accel or mem), does the A2091 perform better when populated with those same 2 Megs of Fast versus having all the Fast Ram on a separate ram expansion?
From my own experience, my A2000 had 16MB 32-bit fast on my GeForce 040, and there was a definite performance improvement when I added 8MB 16-bit fast (via a SupraRam card). Even with 3.9, BB1-4, and various other hacks & speedup patches, there are still some programs that look for 16-bit memory first. It was definitely worth it to me to add some. Your mileage may vary. ;)
-
From my own experience, my A2000 had 16MB 32-bit fast on my GeForce 040, and there was a definite performance improvement when I added 8MB 16-bit fast (via a SupraRam card). Even with 3.9, BB1-4, and various other hacks & speedup patches, there are still some programs that look for 16-bit memory first. It was definitely worth it to me to add some. Your mileage may vary. ;)
Interesting. I wasn't expecting that, I've heard a few times that mixing 16 and 32 bit memory slows the accelerator (not necessarily the transfer performance of the SCSI interface).
Your GE-Force has a SCSI interface included, right? So your 2000 doesn't have an A2091?
I asked because I have an A2500 with Commodore's 030 accelerator, 32-bit fast ram, A2091, and NO 16-bit Fast Ram anywhere (the Chip Ram is 16-bit, of course). It makes sense to me that some ram on the A2091 would improve its transfer rate, buffering, etc.
-
Interesting. I wasn't expecting that, I've heard a few times that mixing 16 and 32 bit memory slows the accelerator (not necessarily the transfer performance of the SCSI interface).
Your GE-Force has a SCSI interface included, right? So your 2000 doesn't have an A2091?
I asked because I have an A2500 with Commodore's 030 accelerator, 32-bit fast ram, A2091, and NO 16-bit Fast Ram anywhere (the Chip Ram is 16-bit, of course). It makes sense to me that some ram on the A2091 would improve its transfer rate, buffering, etc.
Correct, I'm using the SCSI interface on my GeForce card. As Ralph Babel noted on his own website, the transfer rates of SCSI on the accelerators is slower than that on the GVP HC8+ series of cards, dunno why but it is what it is. I've done everything in the book to speed it up, PFS file system, loads of buffers, latest 4.15 ROM (still looking for a Guru ROM), but for whatever reason adding that 16-bit fast really seems to have helped.
Your logic is sound, add memory directly to the controller to improve its buffering... from what I recall in my testing with a HC, I was getting somewhere close to 3MB/sec when loaded with memory, and only about 800KB/sec with zero memory. Using the GeForce SCSI controller I get about 1.7MB/sec, maxed out. Still quite usuable once you factor in all the patches. ;)
I'm running TLSFmem and most Amiga programs should use the 32-bit memory first, but I think some programs and bits of code are still "hard-coded" to use 16-bit, and thus adding that fast mem helps (otherwise data passes through the chip mem address range to get to the 32-bit fast).
This is all just from memory and it's 3am right now, so don't quote me 100%, lol. :drink:
-
Can this co-exist with the 14mhz a2091 mod?
-
Sorry my question is a little off topic, but, perhaps you know.
In an A2000 system with a 32-bit accelerator and 32-bit fast ram, is there any improvement in the A2091's performance by adding the 2 Megs of 16-bit Fast Ram to the card itself? Faster DMA? More buffer?
In a purely 16-bit A2000 (No 32-bit accel or mem), does the A2091 perform better when populated with those same 2 Megs of Fast versus having all the Fast Ram on a separate ram expansion?
It depends on where the 32 bit Fast RAM is located. If it's in 24 bit address space the A2091 can DMA directly to it but if it's in extended 32 bit address space then the A2091 must either use PIO (or a buffered DMA patch) to perform the transfer. The DMA buffer is either in MEMF_24 or Chip RAM so A2091 Fast RAM is important for extended 32 bit Fast RAM only systems.
The filesystem uses a fixed amount of memory for a buffer specified in the RDB or mountlist at boot time. Additional buffering is used when a buffered DMA patch is installed but not by the filesystem.
Yes, in a purely 16 bit A2000, the A2091 Fast memory is still a little faster than chip memory thus performance is improved.
Can this co-exist with the 14mhz a2091 mod?
A better question is why would it not co-exist?
-
@ Mike
I know there are several, what is your favorite util to determine HD transfer speeds?
@ Speedy
Thanks for the info. ;)
-
** 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
-
C= V8.0 (40.20) ROMs
Great. Where to find this v8.0 ?
-
Great. Where to find this v8.0 ?
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).
Hopefully, he will release it soon (some patience please).