More Chipram

[Piru]

@KThunder

the os doesnt break under winuae

Because the WinUAE emulates chipset that works with > 2MB chip memory. WinUAE's custom chips don't ignore the uppers bits of 0x274000 pointer, but use 0x274000 as expected.

See?

[Piru]

@KThunder

you use a bus snoop chip do decode the uppeer bits and if anything over 2meg is being accessed it lets the custom chips know

And tell custom chips to do what? Don't do the operation? If they don't, the result is garbage, regardless.

Do or don't, the result is the same. Something is trashed.

[Piru]

@KThunder

yes exactly if you are trying to use above 2meg as ram you dont want the custom chips to do anything right, you want them to share the bus with the cpu. you dont need the custom chips to do anything with above 2meg do you you just want to use the ram for the cpu for programs

And this is: fast memory.

So what's the point in trying to make it chip memory, again?

[Piru]

@KThunder

some programs need chip memory for certain functions, amigaos loads certain things into chip ram yes.

But they load these things to chip memory for a reason: These things are to be processed using the custom chips.

if you are trying (like some people) to run too many programs and the os needs more chip ram you are stuck.

Tough. You're supposed to free some memory and try again. Or reboot.

what does the custom chips in winuae use the upper parts of 8meg for? not much id wager because the os commands those chips to do stuff right.

The OS sees absolutely no difference in the memory below or above 2MB, there is no special treatment. It's exactly the same as the lower parts, it's regular chip memory. It can be used for display, blitter, paula audio, floppy DMA etc.

This works in WinUAE because it a) has chipset emulation that can handle upto 8MB chip memory b) it has resident tag that AddMemList the additional chip memory to system.

[Piru]

@KThunder

wait... screens i see what you mean, im thinking in terms of programs but the os could put screens up there couldnt it

No it couldn't. Or at least it would be no different from fast memory. You'd still need to swap the memory in & out, which is really painfully slow with chip memory. And OS doesn't do this anyway, it assumes MEMF_CHIP is displayable.

[Piru]

@KThunder

your stack is in chip ram, so are major parts of the os

No way, they aren't. This stuff is in the fastest memory possible (highest priority).

, as are any old programs

Only some very very very old and buggy (I'd say -86 or so apps).

and all data concerning what programs are loaded and where they are, multitasking info etc.

No, nothing of this sort is in chip memory. This stuff is kept in fastest memory possible.

you can use mmu to remap rom to fast ram but alot of this stuff goes into chip

The only situation things like supervisor stack and exec.library can end up in chip memory is due to lame accelerator adding memory to system too late, so that the exec.library relocation code can't see it. And anyway, there are patches to fix this (FastExec, BK's LocalFast).

[Piru]

@KThunder

in winuae if you have 8megs chip and you start up a crapload of programs screens ight get put up above 2meg right?

Naturally.

that would cause problems right if you flipped screens or doesnt it work that way?

There is no problem in WinUAE, it handles 8MB just fine. It has chipset that is able to handle >2MB chip memory without any issues. I was commenting your idea.

[Piru]

@KThunder

so you guys have nothing in chip ram huh, nothing at all not a single byte used?

Some graphics.library arrays and buffers, native screenmode bitmap planes (if any native screen is open), floppy track buffers, AHI 14bit audio buffers.

Typically over 2 million bytes of chip memory was free (I don't have my A1200 set up anymore).

[Piru]

@KThunder

i was agreeing with you some stuff might get put in upper chip that the custom chips might need and that would cause problems. since my idea wouldnt fix the problem it would only partially bypass it.

Well, I don't see how this "chip memory" would be any different from having the extra areas available as fast memory. You could aswell just use FBlit, and/or MCP's patch to direct chipmem allocations to fastmem. And you wouldn't need the hw modifications... :-)

[Piru]

Agreed. :-)

Now, it's time to sleep a bit. Hopefully...

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

[Piru]

@KThunder

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.

of code? And you can tell this how?

Just because some app uses more chip memory than the display doesn't mean the extra chip is actually used for code. This memory is likely to be used with the custom chips in some other ways.

i checked ppaint also and it uses some chip beyond the amount used for screen.

You assume that this extra chip usage is somehow rogue, something that could use fast. How can you tell this is the case?