ACA500 plus?

[honx]

a question: on amiga 500 plus with aca500plus sysinfo shows 6.7mb fast ram, 2.0mb chip ram and 512kb slow ram.
where does slow ram come from? in trapdoor there is additional 1.0mb chip ram which makes 2.0mb chip ram complete.
aca500plus itself adds fast ram, there should not be any slow ram i assume. so where does this slow ram come from?
and what happened to 1.3mb missing fast ram (that's the difference between 8mb and 6.7mb shown in sysinfo)?
i know, mapped rom needs a part of ram to be loaded. but original amiga roms should take max. 512kb as far i know.
so what else does need 0.8mb ram which remains missing after i consider mapped rom? i have no clue...

[Photon]

Originally Posted by honx

a question: on amiga 500 plus with aca500plus sysinfo shows 6.7mb fast ram, 2.0mb chip ram and 512kb slow ram.
where does slow ram come from? in trapdoor there is additional 1.0mb chip ram which makes 2.0mb chip ram complete.
aca500plus itself adds fast ram, there should not be any slow ram i assume. so where does this slow ram come from?
and what happened to 1.3mb missing fast ram (that's the difference between 8mb and 6.7mb shown in sysinfo)?
i know, mapped rom needs a part of ram to be loaded. but original amiga roms should take max. 512kb as far i know.
so what else does need 0.8mb ram which remains missing after i consider mapped rom? i have no clue...

Probably 300K for updated IDE driver and 0.5MB for slowmem (you should be able to disable slowmem if you don't want it?) but also the OS, programs and buffers take some memory.

[demolition]

Yes, the slow ram comes from the ACA. It can be disabled in the ACA menu but it can be nice to have for compatibility purposes. Since it has lower priority than the regular fast mem, the system will not use this until it runs out of fast mem so there is not really any negative effect to keeping it on I would say.

[Toni Wilen]

Again, ACA500plus "slow" RAM is not slow, it is real fast ram. Only exception is 7MHz mode where it becomes true slow ram for compatibility purposes.

6.7M is actual total amount of usable fast RAM. 512k goes to "slow" ram, 512k goes to maprom (even if maprom is off), about 128k goes for firmware internal use. 6.7M+512k+512k+128k=~8M.

[E-Penguin]

That confused me as well at first!

honx the A500 trapdoor RAM was put at 0xC0 000
and many games expected to find memory there. It was "slow" in that wasn't "fast" mem as used on CPU boards and the like. The ACA500plus "slow RAM" option puts some memory in this space so that games & demos that expect it there can run OK.

In other words, it's a good thing, leave it on.

Amiga memory map:
http://amigadev.elowar.com/read/ADCD_2.1

[NorthWay]

OT: Wasn't the very first Ranger mem actually fast fastmem.

[honx]

ranger ram is slow ram as far i know.

[E-Penguin]

It had the same bottlenecks as chip ram, so was slow.* The aca500plus puts a block of fast ram at the memory address of the trapdoor ram.

*bit foggy on the details

[Toni Wilen]

"Original" A2000 (the one with A1000 chipset) had real fast memory at $c00000. Also some A1000 expansions added real fast "slow" memory.

[alpine9000]

I am writing a non OS friendly game that uses pretty standard OS startup/shutdown routines. With the APA500plus it does not work correctly with the ACA500 plus VBR move option enabled.

Obviously without an 010+ my code doesn't detect the moved VBR, is there a way I can make it work ?

[Toni Wilen]

Originally Posted by alpine9000

I am writing a non OS friendly game that uses pretty standard OS startup/shutdown routines. With the APA500plus it does not work correctly with the ACA500 plus VBR move option enabled.

Obviously without an 010+ my code doesn't detect the moved VBR, is there a way I can make it work ?

Don't enable VBRMove in normal use? Nothing that takes over interrupt vectors will work with it. (Note that vbrmove is not needed for freezer/hrtmon support, NMI vector is always "moved" in 68000 mode)

Also it is only enabled in cloaking mode (because there is no way to software switch it on after cloaking mode is enabled), in normal mode vbrmove option only means "vbrmove is available and can be changed via aca.resource API" (whdload uses this for 68000 quit key support).

[Photon]

Originally Posted by Toni Wilen

Don't enable VBRMove in normal use? Nothing that takes over interrupt vectors will work with it. (Note that vbrmove is not needed for freezer/hrtmon support, NMI vector is always "moved" in 68000 mode)

Also it is only enabled in cloaking mode (because there is no way to software switch it on after cloaking mode is enabled), in normal mode vbrmove option only means "vbrmove is available and can be changed via aca.resource API" (whdload uses this for 68000 quit key support).

Interesting information...

Outside WHDLoad, is normal CF card operation with VBR Move supported?

Because this config gives repeated LED-blinks and resets forever and changing to KS1.3 gives this garbled disk hand graphic and no boot to CF.

[Toni Wilen]

Originally Posted by Photon

Interesting information...

Outside WHDLoad, is normal CF card operation with VBR Move supported?

Because this config gives repeated LED-blinks and resets forever and changing to KS1.3 gives this garbled disk hand graphic and no boot to CF.

This is a bug but nothing to do with VBR Move: PAL/NTSC force option puts the patch code in reserved memory location that goes away in cloaking mode.. Will be fixed in next update.

KS 1.x corruption is a bug in KS code (missing blitter wait most likely), it happens when CPU is too fast. (Same can be seen in emulation)

Your config is cloaking device mode: IDE hardware disappears.

[Photon]

So it's for special handling of the NMI vector I guess, and not actual VBR Move. CPU detected as 68000 + vectors not at 0 = disaster for compatible AND incompatible software

[alpine9000]

Originally Posted by Toni Wilen

Don't enable VBRMove in normal use? Nothing that takes over interrupt vectors will work with it. (Note that vbrmove is not needed for freezer/hrtmon support, NMI vector is always "moved" in 68000 mode)

Also it is only enabled in cloaking mode (because there is no way to software switch it on after cloaking mode is enabled), in normal mode vbrmove option only means "vbrmove is available and can be changed via aca.resource API" (whdload uses this for 68000 quit key support).

I guess I was assuming most people would run with VBR move enabled by default as the ACA500plus is so well suited to WHDload and people would want quit key support ?

Can I detect an ACA500plus and then take over the vectors ?

[idrougge]

Wait, does this mean that VBR may be moved even if the CPU is a 68000?

[Photon]

No. It would be a nice feature - if the CPU supported it (and wouldn't cause all software to crash because they don't know about the new check to make). Now, these are not 1979 68000 chips, so possibly something could have been done inside - but it seems I guessed correctly that it's only the NMI and only for WHDLoad and only supported via the aca.resource and only if there's a WHDLoad version with the call to support it.

[Toni Wilen]

It is not full VBR move, only interrupt vectors (and NMI) can be moved. It is possible in hardware level (with 68000) because interrupt vector fetches use special cycle sequence that hardware can detect and return vector pointer data from other memory location.

ACA500plus always moves NMI (used for button options) in all 68000 modes, other interrupt vector move is optional.

Non-cloaking mode VBR Move means: VBR move is available and can be enabled via aca.resource (if also enabled). It has simple API. (I can explain how it works if needed, this is what whdload uses to enable/disable it on the fly)

Cloaking mode enabled VBR Move means: enable it, redirected vectors (0x400000+vector offset) by default redirect execution back to original vector pointers. In other words it is quite useless. (This may do something more in the future)

[alpine9000]

Originally Posted by Toni Wilen

It is not full VBR move, only interrupt vectors (and NMI) can be moved. It is possible in hardware level (with 68000) because interrupt vector fetches use special cycle sequence that hardware can detect and return vector pointer data from other memory location.

ACA500plus always moves NMI (used for button options) in all 68000 modes, other interrupt vector move is optional.

Non-cloaking mode VBR Move means: VBR move is available and can be enabled via aca.resource (if also enabled). It has simple API. (I can explain how it works if needed, this is what whdload uses to enable/disable it on the fly)

Cloaking mode enabled VBR Move means: enable it, redirected vectors (0x400000+vector offset) by default redirect execution back to original vector pointers. In other words it is quite useless. (This may do something more in the future)

OK, so after reading this I figured my game should work with "VBR Move" enabled as it shouldn't do anything, and it did indeed work.

It seems the scenario which causes it to hang is having both "VBR Move" enabled and having the Freezer set to "Action Replay MK III".

If I disable either of those, my game works.

[Photon]

Originally Posted by Toni Wilen

It is not full VBR move, only interrupt vectors (and NMI) can be moved. It is possible in hardware level (with 68000) because interrupt vector fetches use special cycle sequence that hardware can detect and return vector pointer data from other memory location.

ACA500plus always moves NMI (used for button options) in all 68000 modes, other interrupt vector move is optional.

Non-cloaking mode VBR Move means: VBR move is available and can be enabled via aca.resource (if also enabled). It has simple API. (I can explain how it works if needed, this is what whdload uses to enable/disable it on the fly)

Cloaking mode enabled VBR Move means: enable it, redirected vectors (0x400000+vector offset) by default redirect execution back to original vector pointers. In other words it is quite useless. (This may do something more in the future)

Hehe, all clear Thx for the explanation. As dev, *brr* I wouldn't want to 'detect ACA500Plus just to move VBR to fast - for 68000'. I'm sure you know what I mean. There's no performance gain and if you make other vectors work all software will break... :P well I'm sure you know this.

Sorry for even mentioning it, it was some desperate try to see the 4.5MB/s I saw once and once only instead of 4MB/s for IDE...

Keep it like it is, it's perfect for WHDLoad and the Quit key works great, only 1 game so far and it was probably the slave. MUCH better than the Matrix 1230 that I tried many years ago and probably lots of other possible Amiga setups...

And if it's like it is now yep Alpine9000, ACA500Plus will behave as plain A500 whether 7 or 42 MHz... you can trust it for development even more than the ACA500 that I also have.