8 Mb CHIP RAM on All Amigas

[Tricky]

If you had an MMU I guess you could use the Fast ram as "virtual" chip ram in the same way it would normally use HD space as virtual memory, swapping blocks of fast ram into chip ram when needed.  Although what with the custom chips having direct access to it (do they even go through the MMU?) it would be too difficult to know what chip ram was already in use.  Swapping out chip ram the hardware was using might result in some weird happenings.

It would be ok if you were to only use the processor on the extra chip ram, but why the hell would anyone want to do that?

Maybe the OS could be updated so there were extra Exec library functions for declaring chip ram as "asleep" and ok to swap out.  But that would mean all the software would have to be rewritten to use it.

[Tricky]

leirbag28 wrote:
Ok then, it is time to create UAE for Amiga....to emulate the 32 bit needed for the chipRAM and have the rest of the emulation for everything else run natively since it is a real Amiga.............keeping everything still running smooth :-)

You can't do that... because the emulator would be using Fast ram to store graphics and sound, which is what chip ram is for.  The graphics and sound hardware only has access to chip ram, not fast ram, so you wouldn't be able to use the native hardware, you'd have to emulate that as well.  VERY slow.  If at all possible on standard ECS/AGA chipset.  You'd have to emulate the processor as well to trap accesses to the hardware registers.

You can't emulate just one part of the system, because it's all interconnected, in hardware.

Swapping chip ram into fast ram could be done, as I said, but it would need a new OS to handle it, and an MMU (which isn't standard), and all the programs would have to be rewritten to tell the OS it doesn't need to use that bit of chip ram just now... plus copying large blocks of RAM is slow... especially chip ram... your computer would crawl if it did this on every task switch.

But then you could write programs that work like that anyway, and copy their chip ram into and out of fast ram when needed, without any changes to the OS or hardware.

What you COULD do, however, is make a new OS that can basically run four "virtual amigas" that you can switch between.  They wouldn't all be able to run at once though, each one would have its own 2meg chip ram allocation, which gets swapped out when you switch manually from one to the other.

With an MMU maybe it could be made that all four run simultaneously, but you'd only be able to see or hear one at a time.

[Tricky]

Piru wrote:
@Tricky
Nope, only CPU accesses use MMU. Custom chip accesses always access the physical mapping.

I thought they might.  This doesn't affect the four virtual amigas scenario though, as on switching you'd turn off the display and sound, copy the entirety of Chip ram into Fast ram, copy the new Chip ram block out of Fast ram, and restore the display.  The MMU can map access to the hardware registers though, I take it, so it would just point the previous virtual machine's DFF000 range into some reserved fast ram, where it will happily carry on without doing anything... as long as it doesn't try to use the blitter, of course!  But then there's FBlit.

It would also rely on software being fully system friendly in order to work properly.

[Tricky]

Piru wrote:
@leirbag28

Before continuing with this debate, would you be kind enough to explain what would one use the 8MB chip memory for? What benefits does 8MB chip memory offer?

Hahahaha!  I was thinking exactly this, but I'm more interested in just solving the problem!  I'm addicted to thinking.

It's driving me crazy!

[Tricky]

KThunder wrote:
any software to remidy the situation would result in an enormously slow bloated mess. as in probably 10 to 12 megs of fast ram being used and data being shifted back and forth from actual chip to fast.

Depends how often you have to switch between frames.  It takes 31/50 of a second to copy 2megs of chip ram to fast ram, or back again (I just timed it!! although that's on my 25MHz '060 but I'd expect chip ram to be a bottleneck anyway).  I guess that's acceptable if it only happens when you switch between one app and another (or one set of apps and another), if you don't have to switch all that often.

[Tricky]

@Zac67
That's not what I just suggested.

I'm suggesting a scheme where you can MANUALLY switch between completely different 2Mb banks of chip RAM, that are used by entirely independed sets of programs.  When you switch, all the programs in your current frame stop.

The MMU only comes in if you want the programs to still run in the background.  You remap the custom chip hardware register address range (which is written to by the processor, not the hardware) to an area of fast ram, so the other programs aren't accessing the hardware anymore, even though they don't know this.  You also map the chip ram into fast RAM.  The hardware NEVER ACCESSES this fast RAM while the program is in the background, because the hardware registers are mapped to empty space for these processes, although the program itself can still write to what it thinks is chip ram.  You only see or hear the frame you're working on at the time.

[Tricky]

@Zac67
The program will have to patch the OS memory allocation functions.  Although each "page" will have its own set of programs running, you won't be able to mix programs from one page with programs from another.  So if you drag the screen down, you'd get nothing!  (Or another program that was running on the same page.)  There would be some other method of doing it, maybe a key combination.

Chip registers won't be written to by the copper lists of programs that are in a background page, because their copper lists will not be active.  Besides, programming the blitter from there is not a very OS friendly thing to do... OS friendly blits, however, could be taken over by FBlit, and the fast-ram mirror of the blitter busy bit could be held at 1 to ensure any programs that do try to access it the naughty way have to wait until you look at them again.

The MMU would just divert writes to hardware registers elsewhere so they don't actually do anything, it doesn't try to simulate their behaviour in any way.  (At least not the "write" registers anyway, the readable ones could be updated periodically.)  Although when a page is switched back, the values there could be loaded into the real registers.

Why do I want to do this?  I don't really... just sounded like an interesting problem to solve!

[Tricky]

@Zac67

It is possible to track memory resources on the Amiga.  You could patch the memory management functions in exec.library.  Normally AmigaDOS doesn't keep track of any memory reserved, it only keeps track of what's left.  But you could insert a patch that before reserving the memory, gets the current process handle, and stores that somewhere in a table along with the address and amount of memory reserved.

I was considering writing such a patch, not to expand chip RAM, but just so that you can free up any memory reserved by programs that they forgot to free up when they exited.

However, if you can do this, then when the chip memory gets full, we can look at this table and see what programs we can "swap out".  You'd have to put the entire process to sleep (including taking its screen out of the screen list), as it would have no way to access any chip memory it reserved while it was swapped out.  So you wouldn't have full multitasking anymore, but you could get back to the old program when the new one frees up its chip memory.

Realtime switching with full multitasking obviously isn't an option as a program's chip memory can still be accessed by the hardware even when it isn't the current process, and furthermore, it takes far too long to copy memory around like that (it would have to be physically copied into and out if chip/fast ram on every process switch).

But maybe there is a compromise option, that allows you to effectively use more than 2Mb of chip ram, but only a maximum of 2Mb at any one time.  We could do it manually with some sort of "task manager" like Windows has.  You see a window with a list of all the current programs and how much chip ram they are using, and can put individual processes to sleep in fast ram when you want to, and bring them back later.

[Tricky]

@moto

3. it is possible, but only by physically copying it from one to the other, which can take some time.  (about 31/50 of a second for the full 2Mb on my machine.)

[Tricky]

motorollin wrote:
@Tricky
How would existing software know how to swap memory out of chip RAM to free up space?

--
moto

Well it wouldn't.  I'm beginning to wonder if anyone's actually reading my posts.

There would be some sort of "Task manager" that lets you manually swap out an entire program to sleep in fast ram until you manually bring it back.  You could also use this to close a program that had crashed but left its window open.

I'd like to write a whole load of error trapping for AmigaDOS - many more things are possible once you can keep track of which process reserved which bits of memory.

[Tricky]

jdiffend wrote:
Even if it were possible the computer would waste a lot of clock cycles on the context switch and everything else comes to a hault just so someone can say "look what I can do".  Even if it were possible, it's not practical since it would require an OS rewrite.

It would require patching of a few Os functions.  I know exactly which ones, and how to do it.  I might even actually do it one day, but I'm kind of busy at the moment.  Shouldn't take long once I get my head to it though.

It would take time to switch contexts, obviously, but not unbearably so, in my opinion, as long as you didn't have to do it often.  It would be useful, too - instead of closing one program to open another, you'd be able to get back to your original work without having to save and reload it each time.  That's got to be worth the occasional 1/2 second wait (takes longer than that to load a program and your work into it anyway).

[Tricky]

motorollin wrote:
Even if there were enough bytes free to move the sleeping application back in to chip mem, because there is no memory management, how could you guarantee that the re-awoken app would be able to find all of its data in RAM again, once it had been moved back to a different location in chip RAM?

--
moto

Hmm, that's a good point.  You'd have to put it back exactly where you got it from.  Which might mean putting any other program to sleep that happened to occupy that area.  Either that, or it's back to my original idea of switching between complete 2Mb banks of chip ram.  But it may be possible to write an "intelligent" memory allocation algorithm that tries to make sure that it is possible to switch as many sleeping programs back as possible.

But obviously if you had to put A to sleep to run B, it stands to reason that you have to put B to sleep to run A again.

[Tricky]

Piru wrote:
Actually there are several problems here. Processes pass memory between each other, and there even is concept of orphan memory in AmigaOS. Also, various memory is accessed by multiple processes at the same time. Thus, this doesn't work.

When do these things happen?  Do they go through the OS to do it?  If so, could patch those functions too.  Of course only shared Chip RAM is a problem - fast ram would be unaffected.  Don't know why programs would communicate via chip ram, unless they're sharing graphics or sound.

"How can you know if blitter isn't currently working on the memory?"

Call Ownblit() and Waitblit().

"How can you tell that audio hardware isn't playing sample from the memory?"

You're supposed to tell the OS you want to use it, but I guess not everyone bothers (I don't).  In any event, it's only of aesthetic, rather than functional, consequence.  (Might make unexpected noises but it isn't going to crash).

"How can you tell that custom display (poking hardware directly) isn't using the memory for planes and copper list? "

That's a bit naughty isn't it?  "Proper" applications wouldn't do this.  Games do, but you'd have to be on the workbench screen anyway to run the task manager, and the workbench manages its own copper lists.  Must remember not to put the workbench to sleep...

"How can you tell that floppy DMA isn't currently reading to or writing from the memory?"

I'll have to look into that.

[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.