More Chipram

[Karlos]

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

[Thomas]

I find it funny how people try to create the theory of "chip memory that cannot be accessed by the custom chips".

The definition of chip memory is "memory that can be accessed by the custom chips". That's what its name comes from and that's the only pupose why it exists.

"Chip memory which cannot be accessed by the custom chips" cannot exist simply because it is the opposite of the definition of chip memory.

It's also quite simple to understand that the currently existing custom chips are designed and built to access not more than 2MB of memory. People not knowing the technical internals of the chips just have to believe it, but it is a fact. All existing chips cannot access more than 2MB of memory. In order to have the custom chips access more than 2MB of memory, you have to build new chips.

That's what WinUAE's authors did. They built new chips. It's easy to do if the entire machine is built in software. But for a real (hardware) Amiga it would mean to develop an entire new set of custom chips. And motherboards.

And I fully agree with Zac67 that people saying to keep away technical facts from a technical discussion should deal with theology or philosophy but please keep away from computers and mathematics.

Bye,
Thomas

[stopthegop]

The only Threologans here are the hard-headed ones who know for absolute certainty that they -- and only they -- have all the answers.

[Flashlab]

Let's quit the religious tone of this topic. Whether people believe in God/supernatural or not is their own business.

This is about technology and hence it is perfectly explainable; after it is all man made.

There have been people responing here that KNOW what they talk about. They program the machine and know its inner workings.

I for one am getting a bit tired of this bogus.

No-one said that it's impossible. It is theoretically possible to create an 8Mb ChipRAM Amiga. But that would require a lot a  work. I'm not going into details; you can read them in the topic. There's also something like economically sensible; the effort to create this would just not be worth it...

[KThunder]

Thomas wrote:

I find it funny how people try to create the theory of "chip memory that cannot be accessed by the custom chips".

you are missing the point of what leirbag wanted. 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. only that the cpu does. dont make fun of somebody if you are missing the entire point of the arguement.
some people still run programs that want chip ram, we all know that fast is better and most new programs dont need much chip, about the only program that i use that does is dpaintIV, if i wanted that running with several other programs that needed chip id be out of luck and would have to unload dpaint for another prog or whatever.

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

[Thomas]

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.

That's what is so entertaining about it. A memory area can either be declared as chip RAM or not. If it is declared as chip RAM, it is expected to be accessed by the chips. If a program allocates chip memory it expects the chips to be able to access this memory. If the chips cannot access it, the program will crash or create corruption.

You certainly can fake chip memory in any memory area, just by declaring this area as chip memory. You don't need new chips or anything.  The OS will at once start to use it for bitmaps, sounds, floppy disk caches etc.
And will immediately crash. Because the chips which are told to access this area, can't. They just cut off the upper bits of the address and overwrite areas in (real) chip memory instead.

If you have programs which allocate chip memory although they could use any memory instead, you should rather patch these programs instead of trying to argue about non-exitant (or should I say impossible) hardware features. If a program allocates chip memory although it does not need it, the program is buggy, not the hardware bad. And the programs mentioned above surely need chip memory because they use the chips to do something with this memory. So they don't run with faked chip memory.

Bye,
Thomas

[KThunder]

"entertaining" as if we are stupid or something, thats increadibly arrogent of you.
the one program that i use that makes lots of use of chip ram is dpaint IV. it was written after fast ram began to be used extensively. according to the manual 140k or something like that is used by the program even if you have fast. the manual also states that with certain fuctions in some screen modes you might run out even if you have 2megs chip. dpaintIV uses as mich fast ram as possible and still uses some chip. even dpaint 2 loaded as much into fast as possible (acording to dan silva the guy who wrote it) and the rest into chip.
now if i had 8megs chip in dpaint IV i could say open a hires overscanned screen with stensils and animation controles etc etc with no trouble,
if i had 2megs chip and some "chip" all the stuff the custom chips need: screens stensil etc could concevably fit in the 2megs with the program that is requesting chip ram going into "chip" and still working. dpaint is modular so if you use a function like 3d rotations and stuff it loads that into ram. if it needs chip it could possibly use "chip"
we have agreed that it is not possible and the reasons for it and i was wrong on part of that, if you want to come in and make people seem stupid thats your perogitive but i think its pretty low class of you
i havent done much programming for amiga and id like to do more. i dont know why a program would need code in chip ram. piru does or knows why it doesnt he seems to know quite a bit about this thats why im asking him. you i dont need

[Thomas]

Yes, it is arrogant and it is arrogant for a good reason. You just don't want to understand. There are about 120 postings in this thread and in every second posting Piru repeats that chip memory is chip memory for a reason and programs allocate chip memory for that reason. Things allocated in chip memory belong into chip memory. Things allocated in chip memory belong into chip memory because the chips need access to it. You cannot define fake chip memory because the custom chips don't have access to faked chip memory. You cannot define chip memory outside of the address space of the custom chips because memory outside of the address space of the custom chips is no chip memory.

if i had 2megs chip and some "chip" all the stuff the custom chips need: screens stensil etc could concevably fit in the 2megs with the program that is requesting chip ram going into "chip" and still working. dpaint is modular so if you use a function like 3d rotations and stuff it loads that into ram. if it needs chip it could possibly use "chip"

So what is the difference between '"chip"' and 'fast' ? If anything DPaint allocates in 'chip' could go into '"chip"', why shouldn't it go into 'fast' ? The only difference between 'chip' and 'fast' is that 'fast' cannot be accessed by the custom chip. So what is the difference between '"chip"' and 'fast' ?

DPaint allocates as much as possible into 'fast'. Everything else goes into 'chip'. Neither 'fast' nor '"chip"' will do, it needs to be 'chip'. Because the custom chips need to access it.

You give screens, stencils, animation controls etc. as examples. These are all either displayed (which needs 'chip', not '"chip"') or ready to be copied into the graphics buffer (using the Blitter which is a custom chip which needs 'chip', not '"chip"').

I don't get your point. There is either chip memory or non-chip memory. You cannot have "chip memory that is no chip memory". (Remember: chip memory is the memory accessible by the custom chips.)

Bye,
Thomas

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

[KThunder]

again you miss my freaking point: i do understand i have agreed with the others. and you completely missed what i was saying with dpaint too.
if a program is loading code into chip as well as stuff that does need to be displayed and there was a way to get the code into something other than chip there would be more room for stuff that needs to be in chip.
you are arrogant and dont  want to understand

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.

[Piru]

@KThunder

if a program is loading code into chip as well as stuff that does need to be displayed and there was a way to get the code into something other than chip there would be more room for stuff that needs to be in chip.

Which programs put code to chip memory explicitly? At least not DPaint, that's for sure.

Normally the only condition code can get into chip memory is: a) the program explicitly requests chip for the code. Usually this is some lame old app or most of the code hunk is actually data, and really is accessed by the custom chips. b) system runs out of fast memory and hunk is not requesting to be put to fast memory explicitly. In this case hunk is loaded to chip memory as last chance measure, instead of failing to load the executable.

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

[KThunder]

ok here are the actual number i got from the dpaint manual:

dpaintII with no fast uses 200k for the program and with fast can free up 170k so leaving 30k in chip. this is code of some type not including screen. 320x200x32 uses 40k. i checked this all and its pretty close, so not bad even for an old program.

dpaintIV uses 282k for the bare program. i couldnt find what fast frees up in the manual anywhere.
i ran it bare on my 3000 and checking ram came out with 99.8k used minus 40k for 320x200x32 screen leaves about 60k left in chip of code.

so in otherwords this is a huge problem!!!!   :-D
it is 60k for the bare prog. i assume that that has to be there. the dpaintII manual says that it loads as much as it can into fast leaving about 30.
that 60k would only be a problem if i had all animation stuff on and something running in the background. i usually run dpaint alone though.

[KThunder]

i checked ppaint also and it uses some chip beyond the amount used for screen. i tried it with a bunch of different screen resolutions and program settings but i couldnt find out how much it uses. i dont know if you can turn workbench off with ppaint. it seems to use about as much as dpaintIV. rtg uses a bit at least with my video cards.

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