More Chipram

[Karlos]

On UAE its fine because UAE emulates custom chips that were never actually made in real life that are capable of using all 8MB of chip ram. So everything is just fine.

Of course setting 8MB of chip reduces your Z2 space as you might notice. On a real amiga this could be problematic as a lot of expansions want to live there.

[Karlos]

KThunder wrote:
so you guys have nothing in chip ram huh, nothing at all not a single byte used?
what is this thread here for then if noone uses chip ram

Yes we do have stuff in there, just not code. Graphics data, sound data all go there, where the custom chips can make use of it.

Although my graphics data tends to reside in the VRAM of my graphics card. It's only in chip ram when retrogaming ;-)

[Karlos]

@KThunder

BYW, if you really do have OS stuff in chip ram for any reason on your system, try to get a remapper tool to move it into fast ram where it should have gone in the first place. My very old Apollo1240 for instance didnt add the fast ram to the system until after exec was fully loaded and running, meaning exec and several other bits ended up in chip ram. Moving it to fast ram with first fastexec and later remapollo made a *huge* difference to the overall performance of the machine.

[Karlos]

It's almost as bad as Shaun the Bus Arch Troll :lol:

[Karlos]

@KThunder

if you are trying to load a whole bunch of programs that are all asking for chip ram you dont care if the custom chips use it.

Actually, have a look at the program examples he gave. They all allocate chip ram because they are using the custom chips to do stuff with data they store there, such as play sounds, display graphics etc. They don't allocate it for *any* other reason. No sensible program since OS 1.3 allocates chip ram for code when fast ram exists.

A few, very old, very badly written programs fail to work when running from fast ram.

[Karlos]

@Xeron

You might as well ask for an emulator that emulates a pizza oven but actually physically produces real pizza out of your floppy drive.

Yes, but let's face it, that'd be genius :lol:

[Karlos]

i was going to ask piru and karlos if there was a way to use the mmu to remap code that wants to use chip to fast but you would probably jump all over that too.

This shouldn't really be needed, certainly not for an application like Dpaint IV - after all it is 'new' in comparison to programs that actually don't already use fast ram for everything that it can.

If you look at a basic OS1.3 (maybe it is since 2.0) AmigaOS install and above, you can find a system tool called "NoFastMem". This was to assist very old programs (much older than DP IV) that for various reasons don't work if their code is loaded into fast ram. You ran NoFastMem, which temporarily 'hid' the fast memory, then you ran your troublesome application which was then forced to use only chip ram for its code and data. Then you could safely run nofastmem again to 'unhide' the fast memory.

DPaint uses lots of chip ram because of the type of application it is - an art package designed for native video modes. It uses chip memory for the screen, some hidden images, brushes, stencils, animation frames and lots of other stuff. These things are either displayed or operated on using the blitter, which is why they need to be in chip ram.

However, it really ought not to be using any chip ram for anything that can be safely put into fast. By which, of course, I mean anything the custom chips don't need access to, such as program code and data structures - even graphics data that is not presently 'in use' can be stored in fast ram if the program knows how to page it in and out.

What you really need is a paint package that does everything using the CPU and does it in fast ram. Only the display itself needs to be in Chip ram (or indeed video memory on a graphics card) and you would have to have a code that performs copies of the changed areas of the image from fast ram to the display area. This would remove your limit but has one overriding drawback - you likely need a much faster CPU to do everything with, more powerful than the average user would have had when the software was originally made.

The other alternative is to have a paint program that only uses graphics.library routines. This would mean FBlit could help a lot on basic AGA and also you could run it under RTG. The drawback here is that the graphics.library routines are frankly rather crap for making a decent paint package with.

[Karlos]

The 30K of stuff in chip probably isnt code though. It might be some of DPaint's user interface graphics. That and other stuff. I wouldn't be surprised if there were some permanently allocated bits of chip ram for undo buffers and stuff.

Also, looking at your free chip ram isnt the perfect scientific method. Stuff gets temporarily allocated and freed constantly during normal operation. That means your reported figures are subject to a degree of entropy.