8 Mb CHIP RAM on All Amigas

[Tricky]

Piru wrote:
The point of this thing is to allow one to run games after running lot of applications. So it would need to work with those nasty apps I'm afraid.

That's not how I interpreted the point of this thing, but nonetheless, I don't see how a game would cause any trouble that way, as usually the only way (if any) to get back to the system is to quit out, so you'd never get the chance to swap it out of the system anyway.

This onle works for OS friendly apps. You can't OwnBlit() if you have disabled or are in the middle of interrupt (OwnBlit() uses a semaphore locking).

The task manager won't be on interrupts.  It will be started probably from an AppIcon on the workbench.  It will also call Forbid() when it starts, so even if another program has started the blitter, it won't be able to start it again because it won't be running anymore.  Waitblit() will then suffice to ensure the blitter is no longer in use.

Actually it migth crash or at least stop the application from continuing if it uses audio interrupts (when swapping it back).

I might have to put a lot of disclaimers on this...

Also, as for interrupts, if an interrupt happens to be in Chip ram, I'll need to make sure its vector is removed from the Interrupt Server when swapping that chip ram out.  Although there's not usually much need to put an interrupt in chip ram, but of course the interrupt may access chip ram, and how to know this?  Interrupts may defeat me...

Nothing naughty about it. It's common practice to take over the system in OS fiendly way and then display your own hardware screen.

I know it's common, but the official commodore line was always that you weren't supposed to use the hardware directly.

Even still, as I already said, you'd need to be on the workbench screen to swap the app out anyway so this won't apply.

[Tricky]

Piru wrote:
Not quite. For example the blitter queue of the OS itself is run from interrupts. Forbid() + WaitBlit() doesn't guarantee that further blits won't happen.

So you are saying there is no way to wait until the blitter finishes?  I find that rather hard to believe.  Surely a lot of games rely on the OS not suddenly using the while its running.  At least nothing more will be added to the queue whilst you are in forbid mode.

You misunderstood. Audio interrupt occurs when the sample playing has finished, where the interrupt code is located is irrelevant.

No I think you misunderstood me.  I know what the problem is with audio interrupts, and I wasn't disagreeing with you.  I was saying that there may be a lot of other interrupts that also may access chip ram and cause a problem.

I know it's common, but the official commodore line was always that you weren't supposed to use the hardware directly.

It was? Where did they say that? If so, why did they publish hardware reference manual with examples on how to use the hardware directly?

That's what I was always led to believe, at least for O/S friendly applications.  I guess they publish the hardware details for games writers.

Even still, as I already said, you'd need to be on the workbench screen to swap the app out anyway so this won't apply.

I wouldn't consider this very usable solution then.

I don't see why, as you have to be on the workbench screen anyway to run another program.

[Tricky]

Piru wrote:
You say it is possible to write such "swap" program. I still think it's not very stable solution, various things can easily break it. Lets agree to disagree, shall we?

I don't even think we need to go as far as that.  You are exactly right, it wouldn't be fool proof, but it would be interesting to see if it could be done at all.  As I said, I'd have to write a lot of disclaimers in the readme!

I will hold my POV until you provide a working chipmem extender program. :-)

That's fair enough.  I have other things to write just now, but I'll write a memory tracker patch as a first step soon as I finish Mr Beanbag.