Allocating 0xC00000 memory - Page 2

hitchhikr · 13 March 2018, 17:02

That's what i made to check if there's any memory above the 512k of chip, it needs a valid execbase structure (you can typically cram this at the start of your bootblock):

Code:

MaxLocMem equ 62
MemList equ 322

 ; check if we have enough memory available
 move.l  4.w,a6
 move.l  MaxLocMem(a6),d1 ; top of chip memory
 move.l  MemList(a6),d2
 cmp.l   #$80000,d2
 blt.b   top_chip
 move.l  d2,4.w           ; this is the new extra mem start address
 bra.b   init_work
top_chip:
 cmp.l   #$80000,d1       ; only 512k of chip and nothing else
 ble.w   goto_512k_failure
 move.l  #$80000,4.w      ; at least 1mb chip is the new extra mem start address
init_work:

ross · 13 March 2018, 17:30

Quote:

Originally Posted by NorthWay

And it could also be that chipram is 1M or 2M so don't fall over if you don't find another chunk.

My snippet take care of it

jotd · 13 March 2018, 22:33

a lot of games (Team 17, Rich Aplin) do this AllocMem stuff + masking to get hold of the memory locations. Some also wrongly assume $C00000 (supercars II) or write into $200000 to see if there's some memory here (wrong as well, as AGA mirrors chip to 0: lotus II)...

As long as you're not planning to revive the system afterwards, do what you want, take advantage of a machine with physical memory layed out for you

alpine9000 · 13 March 2018, 23:20

Quote:

Originally Posted by jotd

a lot of games (Team 17, Rich Aplin) do this AllocMem stuff + masking to get hold of the memory locations. Some also wrongly assume $C00000 (supercars II) or write into $200000 to see if there's some memory here (wrong as well, as AGA mirrors chip to 0: lotus II)...

As long as you're not planning to revive the system afterwards, do what you want, take advantage of a machine with physical memory layed out for you

No the system can only be revived with a reboot

I have a fully system friendly version of the program if people want to keep the OS running in the background, but this requires more ram than 1mb.

jotd · 14 March 2018, 07:20

ah a reboot always works

[ Show youtube player ]

dissident · 14 March 2018, 08:21

Quote:

Originally Posted by alpine9000

Cool thanks, yeah this version is system takeover, so no need to waste ram for dead OS data structures.

Also how low can I go with chip ram? The size of the vector table? 256?

Well, RSI in their Megademo used $000c0 - $7ffff. It covers all interrupt autovectors and also the trap #0-15 instruction vectors. And since everyone knows this famous demo this method works on most OCS machines.

Galahad/FLT · 14 March 2018, 10:20

Quote:

Originally Posted by hooverphonique

And also make sure, you're not overwriting your own running code which may or may not be at some arbitrary address chosen by the os, depending on how you bootstrap

I get around this as I have always done by having a very small bootup code, which I let EXEC allocate and relocate to wherever it likes, and then I then transfer that boot code to address $C0, and I either run it from that low address, or if its going to cause problems for other code, I then transfer it again to another address higher in memory.

But I do all my memory checking/processor checking and anything else that needs EXEC or AmigaDOS before I do the transfer to low mem.

Photon · 18 March 2018, 22:33

Just Alloc the largest chunk of the two memory types and add intelligence.

For Fastmem you shouldn't take liberties, there could a mapped ROM there or anything else resident that the user needs for his accelerator. If the chunk is smaller than 512K, you could fairly safely assume that you could grab anything below it, but not the area above it, then again expansions could load hw drivers into low fastmem before you boot, so.

For chip memory, more things are known so that again, you could grab the memory below it but not above it, unless of course you check the two stack pointers first and they both point to fastmem. It's your choice if you want to be that close to overwrite vectors near $200000 from a slight bug in your code, like a bob overlapping the bottom right corner of a screen buffer.

Most memory will be free at boot anyway, so Exec's Alloc will give you a very good idea of the total size of the hardware memory available to you, and you can show an information box if it's too little for your spec.

I.e. it's needless to be greedy when your stuff can work on so many configs without the greed. For example, my choice for low chip start is $200, which should give enough wiggle room for current and future accelerator zero page storage. When would you need the extra $100 or $140 bytes? If the answer is, "in cases so rare they're not even worth considering", then be sensible not greedy.

alpine9000 · 05 April 2018, 12:41

Quote:

Originally Posted by Toni Wilen

Also make sure you don't accidentally overwrite supervisor stack (which is usually located at the end of $c00000 RAM if system does not have any real fast RAM), or move it to better place.

So I discovered that kickstart 2.04 with 512chip and 512slow puts the supervisor stack pointer in low slow ram, so I had to move that to a known good location (back to the end of my allocated ram).

Is this a safe way to set the ISP ? Seems to work ok, the very next thing that happens is the OS is turned off.

Code:

.setisp:
        lea     .setit(pc),a5
	jsr     -30(a6)               ; SuperVisor()
.setit:
       	move.l  d0,sp                 ; d0 is new ISP location
	andi.w  #$dfff,sr             ; Back to user mode

ross · 05 April 2018, 14:57

At the end you need a system takeover so why not just stay in supervisor mode?

Anyway with Supervisor() you do not have to touch SP if you want to return to usermode (RTE at the end is due).

Code:

.setisp:
        lea     .setit(pc),a5
	jsr     -30(a6)            ; Supervisor()
        bra     main

.setit:
       	movec   vbr,d0             ; some supervisor stuff
	rte                        ; back to user mode

Logically you can also make a new stack frame in a new location with a proper usermode return
(pushing SR/RTS and setting USP -> move.l a0,USP).

Different thing if you think to use SuperState()/UserState().

alpine9000 · 05 April 2018, 23:10

Quote:

Originally Posted by ross

At the end you need a system takeover so why not just stay in supervisor mode?

Anyway with Supervisor() you do not have to touch SP if you want to return to usermode (RTE at the end is due).

Code:

.setisp:
        lea     .setit(pc),a5
	jsr     -30(a6)            ; Supervisor()
        bra     main

.setit:
       	movec   vbr,d0             ; some supervisor stuff
	rte                        ; back to user mode

Logically you can also make a new stack frame in a new location with a proper usermode return
(pushing SR/RTS and setting USP -> move.l a0,USP).

Different thing if you think to use SuperState()/UserState().

Because my usermode stack is changed a few lines later and I was concerned about potentially the stack frame being incompatible between processors I figured it was easier not to bother returning to user mode with rte.

I use the rte method when I get the VBR.

hooverphonique · 06 April 2018, 10:44

Quote:

Originally Posted by alpine9000

Because my usermode stack is changed a few lines later and I was concerned about potentially the stack frame being incompatible between processors I figured it was easier not to bother returning to user mode with rte.

I use the rte method when I get the VBR.

And you're right in doing so, because the stack frames ARE different between processors. Note that you need to do move.l d0, USP when changing the user mode sp from supervisor mode. Also note that e.g. 68040 has a separate interrupt stack pointer:

Code:

Stack Pointers
ISP Supervisor/Interrupt Stack Pointer
MSP Supervisor/Master Stack Pointer
SP  Active Stack Pointer
SSP Supervisor (Master or Interrupt) Stack Pointer
USP User Stack Pointer

alpine9000 · 06 April 2018, 10:54

Quote:

Originally Posted by hooverphonique

And you're right in doing so, because the stack frames ARE different between processors. Note that you need to do move.l d0, USP when changing the user mode sp from supervisor mode. Also note that e.g. 68040 has a separate interrupt stack pointer:

Code:

Stack Pointers
ISP Supervisor/Interrupt Stack Pointer
MSP Supervisor/Master Stack Pointer
SP  Active Stack Pointer
SSP Supervisor (Master or Interrupt) Stack Pointer
USP User Stack Pointer

Ah so I need to detect 040 and set both privileged stack pointers? What about 060?

I currently set the USP in user mode.

Toni Wilen · 06 April 2018, 11:18

No need to care about MSP/ISP difference if you never manually set M-bit in SR.

alpine9000 · 06 April 2018, 11:22

Quote:

Originally Posted by Toni Wilen

No need to care about MSP/ISP difference if you never manually set M-bit in SR.

Great! Many thanks for everyone’s help!

I seem to finally be able to use every last byte of my trapdoor ram expansion

hooverphonique · 06 April 2018, 21:50

Quote:

Originally Posted by Toni Wilen

No need to care about MSP/ISP difference if you never manually set M-bit in SR.

so the master supervisor mode is only used when the M-bit is set, and we know that LVOSupervisor() doesn't use master supervisor mode?

ross · 06 April 2018, 22:55

Quote:

Originally Posted by hooverphonique

so the master supervisor mode is only used when the M-bit is set, and we know that LVOSupervisor() doesn't use master supervisor mode?

Yes.

ross · 06 April 2018, 23:05

Quote:

Originally Posted by hooverphonique

And you're right in doing so, because the stack frames ARE different between processors.

You are right, but i think that code similar to this can work in every situation:

Code:

	move.w	#$4000,$dff09a
	movea.l	$4.w,a6
	lea	super(pc),a5
	jsr	-30(a6)
	
	
super	lea	$80000,sp       ; set to your top stack memory address
	lea	-$400(sp),a0    ; too little? make it bigger :)
        clr.w   -(sp)           ; short format (010+)
	pea	main(pc)
	clr.w	-(sp)           ; SR usermode
	move	a0,USP
	rte
	
main	bra.b	main

Untested

EDIT: tested in WinUAE from bare 68k to 060.

All is working properly:
000 -> SSP to $7fffe, USP to $7fc00, main in usermode (2 bytes lost, not a problem the misalign)
010+ -> SSP to $80000, USP to $7fc00, main in usermode (stack aligned for 020+)

alpine9000 · 07 April 2018, 00:34

Quote:

Originally Posted by ross

You are right, but i think that code similar to this can work in every situation:

Code:

	move.w	#$4000,$dff09a
	movea.l	$4.w,a6
	lea	super(pc),a5
	jsr	-30(a6)
	
	
super	lea	$80000,sp       ; set to your top stack memory address
	lea	-$400(sp),a0    ; too little? make it bigger :)
        clr.w   -(sp)           ; short format (010+)
	pea	main(pc)
	clr.w	-(sp)           ; SR usermode
	move	a0,USP
	rte
	
main	bra.b	main

Untested

EDIT: tested in WinUAE from bare 68k to 060.

All is working properly:
000 -> SSP to $7fffe, USP to $7fc00, main in usermode (2 bytes lost, not a problem the misalign)
010+ -> SSP to $80000, USP to $7fc00, main in usermode (stack aligned for 020+)

What’s the advantage of doing this rather than just clearing the S bit?

ross · 07 April 2018, 00:49

Quote:

Originally Posted by alpine9000

What’s the advantage of doing this rather than just clearing the S bit?

All-in-one solution to be in a definite state (both user and super stack set, user mode on)
and a (dumb) way to use RTE without fear of different stack frames.

Well, only an example, but actually never used.
Like I've said for a system take-over I use S=1 and I never return to user mode.

But you are right, my code is overbloated

, better:

Code:

super	lea	$80000,sp       ; set to your top stack memory address
	lea	-$400(sp),a0    ; too little? make it bigger :)
	move	a0,USP
        andi    #$dfff,sr
	
main

05 April 2018, 14:57	#30
ross Defendit numerus Join Date: Mar 2017 Location: Crossing the Rubicon Age: 54 Posts: 4,488	At the end you need a system takeover so why not just stay in supervisor mode? Anyway with Supervisor() you do not have to touch SP if you want to return to usermode (RTE at the end is due). Code: .setisp: lea .setit(pc),a5 jsr -30(a6) ; Supervisor() bra main .setit: movec vbr,d0 ; some supervisor stuff rte ; back to user mode Logically you can also make a new stack frame in a new location with a proper usermode return (pushing SR/RTS and setting USP -> move.l a0,USP). Different thing if you think to use SuperState()/UserState(). Last edited by ross; 05 April 2018 at 15:15. Reason: example

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
AmiDEVcpp: Allocating gfxdata in chip mem	tolkien	Coders. C/C++	9	22 April 2013 20:21
Listing files, loading files and allocating all available chip ram.	h0ffman	Coders. System	16	04 April 2013 21:24
Problem allocating some memory	CmdrVimes	Coders. General	4	03 September 2010 23:23
Allocating Fast RAM as Chip?	Fingerlickin_B	support.Hardware	22	20 November 2008 22:15
A600 Not allocating full 1mb	FOL	support.Hardware	24	18 October 2008 13:02

13 March 2018, 22:33	#23
jotd This cat is no more Join Date: Dec 2004 Location: FRANCE Age: 52 Posts: 8,360	a lot of games (Team 17, Rich Aplin) do this AllocMem stuff + masking to get hold of the memory locations. Some also wrongly assume $C00000 (supercars II) or write into $200000 to see if there's some memory here (wrong as well, as AGA mirrors chip to 0: lotus II)... As long as you're not planning to revive the system afterwards, do what you want, take advantage of a machine with physical memory layed out for you

14 March 2018, 07:20	#25
jotd This cat is no more Join Date: Dec 2004 Location: FRANCE Age: 52 Posts: 8,360	ah a reboot always works [ Show youtube player ]

18 March 2018, 22:33	#28
Photon Moderator Join Date: Nov 2004 Location: Eksjö / Sweden Posts: 5,652	Just Alloc the largest chunk of the two memory types and add intelligence. For Fastmem you shouldn't take liberties, there could a mapped ROM there or anything else resident that the user needs for his accelerator. If the chunk is smaller than 512K, you could fairly safely assume that you could grab anything below it, but not the area above it, then again expansions could load hw drivers into low fastmem before you boot, so. For chip memory, more things are known so that again, you could grab the memory below it but not above it, unless of course you check the two stack pointers first and they both point to fastmem. It's your choice if you want to be that close to overwrite vectors near $200000 from a slight bug in your code, like a bob overlapping the bottom right corner of a screen buffer. Most memory will be free at boot anyway, so Exec's Alloc will give you a very good idea of the total size of the hardware memory available to you, and you can show an information box if it's too little for your spec. I.e. it's needless to be greedy when your stuff can work on so many configs without the greed. For example, my choice for low chip start is $200, which should give enough wiggle room for current and future accelerator zero page storage. When would you need the extra $100 or $140 bytes? If the answer is, "in cases so rare they're not even worth considering", then be sensible not greedy.

06 April 2018, 11:18	#34
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,553	No need to care about MSP/ISP difference if you never manually set M-bit in SR.

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)