8 Mb CHIP RAM on All Amigas

[Kronos]

There are only exactly 2 ways of getting more than 2MB chip:

a) emulate it, problem is, even a A4000-CSPPC+Voodoo3 running MorphOS or an OS4-beta will hardly reach A500-speeds(as you would need to run a full version of UAE).

b) create your own uber-Agnus/Alice out of a programable chip, remove the onboard Agnus/Alice, place a piggyback-PCB with the  new chip and 6 extra MB into the free space. This might work, this might also end in the need of recreating Denise,Gary and Paula too.

None of them makes really sense.

But since I'm in the mood:

c) use a PC + UAE and somehow hack a PCI_2_Zorro-adaptor and a VGA_2_VideoSlot-adaptor. Now that sounds like a fun project, and should even be able to the toaster. But then just buying a the PC-Toaster might be easier.

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

[motorollin]

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

--
moto

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

[jdiffend]

Not a bad idea, but still the answer is no. The trouble is that Agnus/Alice has many different DMA channels and stores different addresses for each one. When Agnus/Alice accesses chipmem, there is no way for any other piece of hardware to know which DMA channel is being served, so there is no way for any other piece of hardware to provide relevant additional address bits.

Actually, that's not entirely true.  As long as the OS set up the DMA it would be possible to block all bank switches until all DMA transfers finish.  For a lot of things it's possible.

The problem is, the OS isn't always aware of how the hardware is setup.  When you setup the copper, it just keeps trying to do it's thing without the OS.  Imagine what happens if the copper is stepping through a copper list and suddenly it's replaced with some other data because you swapped RAM banks.

In *theory* you could stop the copper, save the state it's in, switch banks, setup the alternate copper list, etc...
In reality, you don't set up the hardware strictly through the OS and some hardware registers are read only.  It makes it impossible to save/restore the state of the hardware for a CHIP RAM bank swith.

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.

The whole CHIP/FAST mem thing was really sort of a hack to get around the slow buss speed of the day.  Now you could design a new chipset that uses 1 buss and all RAM could be CHIP or FAST.  Minimig or something like it is the only way you will ever see this happen.

[Zac67]

I really didn't want to do this, but I just checked the A4k schematics to make sure I'm not telling crap.

- Alice is actually connected to all 32 address bits - this surprises me
- Alice has 10 DRAM address bits, 11 with the '8 MB' jumper set - that's enough for 8 MB (no surprise here)
- Paula just has a register address bus of 8 bits, no data address lines
- Lisa likewise

Like in OCS/ECS there's no bus arbitration for the chips. Alice knows who wants what and uses the static (prioritized) 'DMA channel' scheme to ensure timely data delivery. It generates the addresses and Lisa/Paula read the data.

It was possible to expand a 1st generation A500 to 2 MB chipmem by exchanging Agnus, and the A4k schematics talk about a '8 MB Alice'. I see no reason why you'd need anything more than a new (non-existant) Alice and RAM.

[motorollin]

@Tricky
So you're saying if you are running low on chip mem and want to run an application which requires more chip mem than you have free, you could MANUALLY put an application which is using chip mem to sleep, which would suspend its execution and move all of its memory from chip mem to fast mem?

That might work, but the problems will start when you want to wake the application up again and something has filled the chip mem with data. 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

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

[Piru]

@Tricky

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.

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.

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.

Won't work, there's more to this than just memory allocation. How can you know if blitter isn't currently working on the memory? How can you tell that audio hardware isn't playing sample from the memory? How can you tell that custom display (poking hardware directly) isn't using the memory for planes and copper list? How can you tell that floppy DMA isn't currently reading to or writing from the memory?

The only way to have this working would be to have full virtualization of the system. Then you'd need to emulate much of the hardware anyway (at least copper), so in the end it would be much easier with full emulation.

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

[Piru]

@Tricky

When do these things happen?

Example of OS use: Various structures are allocated and passed to library/device. Other processes use the structures when they call the library functions. This is common practice in most libraries/devices. Chip memory is less likely to be used like this, but it can happen if some chip memory buffers are needed.

Do they go through the OS to do it?

Some do, some don't. There is no way to patch these since you have no way of knowing where and when these things are used.

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.

OwnBlit()

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

it's only of aesthetic, rather than functional, consequence. (Might make unexpected noises but it isn't going to crash).

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

That's a bit naughty isn't it? "Proper" applications wouldn't do this.

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

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

[leirbag28]

motorollin wrote:

1. The custom chips are physically only able to see a maximum of 2MB of chip RAM.
----------------------------------------------------------

I don't believe that...........if this were True, how is it that an A500 wich was created before 2mb CHipRAM existed is able to see the 2mb ChipRAM from a MegaCHIP add-on without changing any of the customs chips?


Also how is Workbench 1.3 able to see it?

Neither Workbench 1.3 nor the custom chips needed to be told there was extra ChipRAM...........it just detected it.

[Zac67]

Read my post - max amount of chipmem depends on Agnus/Alice and nothing else.
AmigaOS doesn't really care how much chipmem there is and where - it detects the first 2 MB as chipmem and additional RAM can very easily be flagged MEMF_CHIP.

[Matt_H]

I don't believe that...........if this were True, how is it that an A500 wich was created before 2mb CHipRAM existed is able to see the 2mb ChipRAM from a MegaCHIP add-on without changing any of the customs chips?

Those expansions did change custom chips - they swapped the old 512K or 1MB Agnus with the then-new 2MB version that had been built for A3000s, A600s, and A500+s.

In the case of the 4000, at the *very least* the 2MB Alice would have to be replaced with an 8MB Alice (which does not exist).