8 Mb CHIP RAM on All Amigas

[Piru]

Why is it possible to have 8mb ChipRAM on WinUAE but not on a Regular Amiga?

Emulation of a chipset is not bound to physical limitations of the original.

As far as I am concerned I belive its possible without even using a gfx card.............

No it is not.

I think All an Amiga needs is a WinUAE ChipRAM emulator.

By that I mean surely even a Plain Amiga can emulate the code or instructions that WinUAE uses to be capable of having 8mb ChipRAM..............as long as one has more than 8mb FastRAM to be used as ChipRAM.

It means running full UAE on your amiga. Ever tried that? Hint: It is slow. Very slow. Even the fastest classic is way too slow to reach even fraction of A500 speed.

You can't just fork out "chipram emulator", because there isn't one. The whole UAE is required.

Im so sure its possible in one way or another. If not that way...then maybe with an external gfx card kinda like a SUPER Graffitti or DCTV. and of course it being 100% compatible with all software

No, it is not possible in HW.

Its Possible!

No, it isn't.

[Piru]

@Tricky

Although what with the custom chips having direct access to it (do they even go through the MMU?)

Nope, only CPU accesses use MMU. Custom chip accesses always access the physical mapping.

[Piru]

@utri007

fblit what it does? would it be possible to to assign more memory to graphics with it ?

No.

FBlit just makes all non-displayable bitmaps to reside in fast memory and replace hardware blitting with CPU operations. It doesn't give you any more chip memory, but it reduces usage of it, leaving it for other purposes, and speeding up system (fast memory is, err, faster).

So in a sense FBlit is the best you can get without replacing the whole hardware.

And really, fast gfxcard is much better option, you get truecolor modes aswell.

[Piru]

Then if it is not possible without a gfx card. it is possible with one as we already know so my solution in hardware would be create a gfx card thats accessed through RTG I suppose, but isnt a gfx card but only the ChipMem part of it and how it is accessed.

This is not possible. External hardware cannot take over the custom chips inside the amiga.

The only way would be to replace the whole amiga motherboard and chipset.

[Piru]

@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?

[Piru]

The fake GPU idea is a good one, tricking the Amiga into using GFX card memory as ChipMem - maybe with some sort of FBlit/Hardware combo. The board could have lightning fast DDR memory.

It's a very bad idea, reading graphics card memory is even slower than chip memory.

Ok I don't mind people having their dreams, but when the ideas conflict with reality I feel obliged to comment.

[Piru]

Ok, it's been said that the A4000's ChipMem resides on a removeable 72-pin SIMM right?

So what if a larger SIMM was used, possibly of a higher nanosecond rating then a piggy-back chip placed over Agnus?

The system would still only see 2MB of chip memory. The memory speed would not be faster.

For any benefits all custom chips would need to be adjusted, not just agnus. Also, it is likely that various address lines are not even physically connected, considering the maximum memory is 2MB. Basically you'd end up replacing the whole motherboard and chipset anyway.

Surely GFX card memory is only slower than the crap 80ns ChipMem memory because it has to go through the Zorro bus

Actually this is generic. Graphics card memory access speed is highly asymmetric (writing is fast, reading is very slow). This is the same for modern gfxcards aswell.

[Piru]

@leirbag28

Someone here said even with a Gfx card the limit is only 2mb Chip. hmmmm Im pretty sure I have read you can have 4mb with a CyberVision64 or Picasso and having a Gfx card benefits the Video Toaster as it uses the extra chipMEM from the Card to run.

No.

For example Compact Flash cards and Memory Sticks and SD cards and such were said to be not possible

Can't remember anyone saying these would be impossible. It was just lack of drivers, obviously possible.

Same with USB

Was always possible if someone just created the HW. Someone did. The only way to get more than 2MB chip memory is by full hw emulation or total recreation of all hardware (minimig could have more than 2MB, but it won't. It will be A500 compatibility device).

ECS Amigas were said to display a Max of 16 colors in hires Interlaced, yet Broadcast Titler 2.0 displays 320 at once using a trick

Obviously possible since you can change palette registers with copper. This never was impossible.

But:

this same concept has been applied to games and can be applied even more if we had more ChipMEM

No, it can't.

I have ran out of ChipMEM trying to display a large JPEG.

Use a program that reduces the picture size to fit the screen.

But maybe there is a way through software telling the Systems and OS that the rest of the ChipRAM is somewhere else and is Virtual Memory redirection invisible to all Applications and games.

No, there is not.

Really there isn't.

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

[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

[Piru]

@Tricky

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.

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.

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

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

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?

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.

[Piru]

@leirbag28

I don't believe that.

Believe it.

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?

Oh really? Well what is this Agnus 8375 chip doing on the board then?

Also how is Workbench 1.3 able to see it?

Workbench calls AvailMem(MEMF_CHIP). Kickstart 1.3 has always supported upto 2MB chip memory.

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

Wrong. Workbench just reports what exec library tells it via AvailMem. Depending on the revision of the agnus it can only see 512KB, 1MB or 2MB chip memory. However, it can not see more than 2MB. Even if you plugged in a new agnus that would do more than 2MB it would still not work.

Further even if you did, kickstart ROM would not see the chip memory above 2MB (it only scans upto 2MB).

Even if you fixed this, the 8MB chipmem would break all Zorro II autoconfig devices having memory.

[Piru]

@leirbag28

Replacing the Agnus is obvious....Im only replying to those that suggested it needed Denice and other chips replaced with the MegaCHIP doesnt have and still works! correct?

...to get more than 2MB.

Naturally upto 2MB doesn't need total chipset replacement, because the whole system was designed to have maximum of 2MB.

So your saying Commodore knew they would eventually invent the ECS that would have 2mb ChipRAM so allowed wb 1.3 and up to support it?

Yes.

sounds unlikely to me.

Since you're not believing anything I say anyway: Take kickstart 1.3 image and disassemble it from offset $208. You find this:

Code: [Select]


lbC000208 lea    (0).w,a0
          lea    ($00200000),a1
          lea    (lbC00021A,pc),a5
          bra.w  lbC000592

A0 contains the start address for memory scan, A1 the end address. $200000 is 2097152 in decimal, or 2MB.

[Piru]

@B00tDisk

"more chip memory" with the MiniMig - how's that possible?

It emulates all the custom chips in software, so it could easily be adjusted to support more chip memory, just like UAE.

[Piru]

@Tricky

So you are saying there is no way to wait until the blitter finishes?

Sure there is, but your proposals are not working.

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

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 will hold my POV until you provide a working chipmem extender program. :-)