Amiga.org
Amiga computer related discussion => Amiga Hardware Issues and discussion => Topic started by: Matt_H on May 03, 2012, 12:06:21 AM
-
You may have seen my thread about the A2000 fire button problem, and the lesson there is to try the most damn obvious thing first. Could have saved a lot of headache if I'd just plugged in a damn joystick! Ugh.
Other observations:
The Algor Pro and One-Stop Music Shop do not play nice together. Could get the machine to boot maybe 1 out of 30 times with both of them plugged in, but no problem whatsoever with just one of them. With both of them, the machine would either hang on the Algor bootloader (with Flash empty) or immediately afterwards. Since this machine is to be a music workstation, I opted for the One-Stop, but it would be nice to get them both working...
The A2091 driver will use whatever memory has the highest priority. In my case, that's the non-DMA memory on the 2632 board, leading to horrendously slow speeds - even with the full 2MB of RAM on the A2091 itself. Solution? Reduced the priority of the 2632 RAM below that of the native Zorro II Fast RAM. Sure, that'll probably reduce speeds on other RAM operations, but the 15-fold increase in drive speed is worth it. The numerous speedup patches on Aminet seem to be intended for a 4000/040, so I haven't tried those yet.
More to come as I think of it...
-
The A2091 driver will use whatever memory has the highest priority. In my case, that's the non-DMA memory on the 2632 board, leading to horrendously slow speeds - even with the full 2MB of RAM on the A2091 itself. Solution? Reduced the priority of the 2632 RAM below that of the native Zorro II Fast RAM. Sure, that'll probably reduce speeds on other RAM operations, but the 15-fold increase in drive speed is worth it. The numerous speedup patches on Aminet seem to be intended for a 4000/040, so I haven't tried those yet.
More to come as I think of it...
You know... its been a long time, but I had a 2000 with PP&S 040/28 & GVP 4008 and I think that is primary reason I bought a Guru Rom for the GVP controller...
-
You know... its been a long time, but I had a 2000 with PP&S 040/28 & GVP 4008 and I think that is primary reason I bought a Guru Rom for the GVP controller...
I had an A2091 with a PP&S 040 as well and it was damn slow. Took 3 minutes or more to load a 3.5 minute stereo song into Samplitude for editing.
I eventually got a GuruROM but it didn't help much.
On the other hand, I never knew anything about changing memory priority. How then heck do you even do that?
-
I had an A2091 with a PP&S 040 as well and it was damn slow. Took 3 minutes or more to load a 3.5 minute stereo song into Samplitude for editing.
I eventually got a GuruROM but it didn't help much.
On the other hand, I never knew anything about changing memory priority. How then heck do you even do that?
I had 32MB 32bit RAM on the PP&S 040, 4 on the GVP card and 4 on the CV643D... that system was really sluggish initially with a stock 3.1 install, but after many days and month spent tweaking the setup, it was quite fast... I seem to recall the issue being that the ram was not autoconfig, so a lot of libraries ended up in 16BIT fast ram.
I also recall it getting about 3.5MB/sec SCSI with the Guru ROM and 400K/sec on the Hydra Ethernet. ShapeShifter really flew on it... I ended up having a HD crash and did not have the system partition backed up and it took a few days to figure everything out again. I seem to remember getting the Guru Rom because I was struggling to get the CD-ROM to work but being really happy with speed increase.
Yes, 3.5MB sec is not fast in modern terms, but in Amiga terms its not bad. My A1200 with FastATA gets 5.1 for example. Its a heck of a lot better than the stock IDE controller in the newer machines.
-
On the other hand, I never knew anything about changing memory priority. How then heck do you even do that?
The 2632 is doubly annoying because it doesn't autoconfig. It has its own addmem tool which has a few extra options, one of which is adjusting the memory priority.
For other cases, there's ChangeMemPri (http://aminet.net/package/util/cli/ChangeMemPri). Worked great on my CS Mk3 a number of years ago (wanted to have the system use motherboard RAM first in order to have a larger free block on the accelerator for Mac emulation - back in the days when I had a mere 32MB onboard).
-
The 2632 is doubly annoying because it doesn't autoconfig. It has its own addmem tool which has a few extra options, one of which is adjusting the memory priority.
For other cases, there's ChangeMemPri (http://aminet.net/package/util/cli/ChangeMemPri). Worked great on my CS Mk3 a number of years ago (wanted to have the system use motherboard RAM first in order to have a larger free block on the accelerator for Mac emulation - back in the days when I had a mere 32MB onboard).
Oh. I used ROMTAGMEM to configure the RAM on the PP&S accelerator. Then there was the conflict with the A2091 which would not DMA with the ram on the accelerator.
I remember that before getting the GURU-ROM, the utility vbak2091 on Aminet helped a lot with this configuration. Maybe you should try that.
-
The A2091 driver will use whatever memory has the highest priority. In my case, that's the non-DMA memory on the 2632 board, leading to horrendously slow speeds - even with the full 2MB of RAM on the A2091 itself. Solution?
Everything will you highest priority RAM first. Have you configured the mask value correctly?
-
Everything will you highest priority RAM first. Have you configured the mask value correctly?
Probably not. Do you know what it should be? This might be a better workaround.
-
Do you know what it should be?
No, but it's not too hard to figure out. If the A2091 memory autoconfigs to $200000 to $3FFFFF and the A2630 (non-DMAable) RAM goes to somewhere beyond that (doesn't really matter if it's $600000, $20000000 or whatever) you can simply use a mask of $3FFFFC. (The two least significant bits set to 0 make sure a buffer is longword aligned, speeding up the '030's access somewhat.).
In a nutshell, you use the highest address DMA works at and set the lowest nibble to $C: $3FFFFC for a 2 Meg RAM board and some below $FFFFFF 32-bit RAM, or $9FFFFC to use any Z2 RAM but no extended memory, or even $FFFFFC if you've got Ranger or slowfast mem.
However, if the A2630 RAM configures before (=below) the A2091 RAM we'll need to get more creative. Post the memory locations and we can work it out.
btw: the A2630 RAM should autoconfig (J303 open)
-
No, but it's not too hard to figure out. If the A2091 memory autoconfigs to $200000 to $3FFFFF and the A2630 (non-DMAable) RAM goes to somewhere beyond that (doesn't really matter if it's $600000, $20000000 or whatever) you can simply use a mask of $3FFFFC. (The two least significant bits set to 0 make sure a buffer is longword aligned, speeding up the '030's access somewhat.).
In a nutshell, you use the highest address DMA works at and set the lowest nibble to $C: $3FFFFC for a 2 Meg RAM board and some below $FFFFFF 32-bit RAM, or $9FFFFC to use any Z2 RAM but no extended memory, or even $FFFFFC if you've got Ranger or slowfast mem.
However, if the A2630 RAM configures before (=below) the A2091 RAM we'll need to get more creative. Post the memory locations and we can work it out.
btw: the A2630 RAM should autoconfig (J303 open)
Thanks for the help. Looks like the RAM on the 2091 and 2630 autoconfigs as a contiguous block from $200000 to $7FFFFF, but the 2091 seems to start at $600000 according to ShowConfig.
-
Thanks for the help. Looks like the RAM on the 2091 and 2630 autoconfigs as a contiguous block from $200000 to $7FFFFF, but the 2091 seems to start at $600000 according to ShowConfig.
Stay on target. Almost there..!
Looks like your A2000 system will be schmako in no time. So the joystick problem was physical?
-
Makes sense that the A2630 RAM configures first. So the 'bad' addresses to avoid for the A2091 is $200000-5FFFFF, 'good' mem is $600000-7FFFFF.
Hmm - hate to tell you, but the mask scheme is too simple to solve this:
$20 = %0010 0000
$5F = %0101 1111
$60 = %0110 0000
$7F = %0111 1111
The mask value 'forbids' address bits to be set for allocated buffers. The logic is to clear a mask bit when you don't want it present in the buffer address. But you can't force them set which you'd need here.
Since the very same 3 bits are used to count from 2 through 7 you can't make any use of that. If some more RAM would be present from $800000 that would be easy to address ($8FFFFF or $9FFFFF masks would do that). Since we don't have it here you can either
- not autoconfig the A2630 RAM and AddMem it later on - leaves you with the OS structures in 16-bit RAM
- get yourself some 2 MB RAM board and configure it before the A2091 (closer to CPU)
- restrict A2091 DMA to chipmem only (mask $1FFFFF) - I would try that, it's probably faster than DMA to 32-bit.
:(