Allocating 0xC00000 memory

[alpine9000]

So my current project requires the "gold standard" 1mb of ram. In the trackloaded/system unfriendly version I use AllocMem to work out where any additional ram might be before I take over the system.

The problem is, on a KS1.3 machine the returned address will be something like 0xC04AD0. I am guessing this is due to the OS using the ram at 0xC00000 for itself?

Is it safe to convert that number (or things in a similar range) to 0xC00000 so I can use the full 512kb ?

I think in any other ram configuration I should probably be safe with the returned address as it will likely be > 512kb ?

[StingRay]

Why not just checking Exec's MemList for the largest available block (either chip or fast) during boot?

[alpine9000]

Originally Posted by StingRay

Why not just checking Exec's MemList for the largest available block (either chip or fast) during boot?

Well it's not so much of a problem if the largest available block is >= 512kb, only when the largest available block is *almost* all of the slow ram, but I want ALL of it

[Galahad/FLT]

Originally Posted by alpine9000

Well it's not so much of a problem if the largest available block is >= 512kb, only when the largest available block is *almost* all of the slow ram, but I want ALL of it

So long as you are dropping system friendly programming, then yes, using all of ram is fine.

As youve worked out, execbase offsets and pointers are located in that memory space at the start of $c00000, once you know you are finished with interrogating system resources, disable all interrupts and use $c00000 as your base address and use it all up.

[alpine9000]

Originally Posted by Galahad/FLT

So long as you are dropping system friendly programming, then yes, using all of ram is fine.

As youve worked out, execbase offsets and pointers are located in that memory space at the start of $c00000, once you know you are finished with interrogating system resources, disable all interrupts and use $c00000 as your base address and use it all up.

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?

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

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

0. Just make sure exception vectors you really need contain values you want them to contain

[ross]

even $0 if you make some slalom between vectors

EDIT: ops.. Toni first

[alpine9000]

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.

0. Just make sure exception vectors you really need contain values you want them to contain

Thanks!

Yeah, I have the supervisor stack under control. It’s not such a big deal as it doesn’t grow too big.

[ross]

However, do not assume that the memory is at $c00000.

Like suggested make use of Exec before destroying it

My discoverer of 512KB mem chunks:

_LVOSuperState		EQU	-150
;A6=ExecBase

	lea	$somewhere_in_low_mem,a1
	movea.l	a1,a2
	clr.l	-(a1)           ;two chunks
	clr.l	-(a1)           ;but you can use as many as you want
	moveq	#8,d1
	swap	d1              ;#$80000
	
	lea	$142(a6),a0	;a0=ExecBase->MemList
_ml1	movea.l	(a0),a0		;a0=next Node
	move.l	$18(a0),d0	;mh_Upper
	add.l	#$ffff,d0	;skip over possible SSP
	clr.w	d0		;pad to real chunk Upper
	move.l	$14(a0),d2	;mh_Lower
	clr.w	d2		;pad to real chunk Lower
_ml2	sub.l	d1,d0		;512KiB from Mem chunk
	ble.b	_mlex		;<=0? end of list (first 512 KiB chip RAM)
	cmp.l	d2,d0		;check end of Node
	blo.b	_ml1		;next Node
	move.l	d0,(a1)+	;fill my 512KiB blocks memlist
	cmpa.l	a1,a2		;enough?
	bne.b	_ml2		;else more
	
_mlex	jmp	_LVOSuperState(a6)

[alpine9000]

Originally Posted by ross

However, do not assume that the memory is at $c00000.

Like suggested make use of Exec before destroying it

My discoverer of 512KB mem chunks:

Nice!!

I currently use AvailMem asking for the largest fast ram available, then allocate it to get the location. Note this happens only on boot (track loaded program).

For this to work my assumption must hold that the largest available ram will be either:

(1) 512kb at $C00000 -or-
(2) >512kb somewhere else

Is it possible to have a 512kb expansion somewhere other than $C00000 ?

[ross]

Originally Posted by alpine9000

Nice!!

I currently use AvailMem asking for the largest fast ram available, then allocate it to get the location. Note this happens only on boot (track loaded program).

For this to work my assumption must hold that the largest available ram will be either:

(1) 512kb at $C00000 -or-
(2) >512kb somewhere else

Is it possible to have a 512kb expansion somewhere other than $C00000 ?

Yes, everywhere.

On 24 bit machine (A1000/500/600/2000) you can have memory from $200000 to $A00000 or also from $c00000 to $D80000.
On 32 bit machine also from $01000000 to .. $80000000

EDIT:in any case normally on the A500 in the trap door is at $c00000

[alpine9000]

Originally Posted by ross

Yes, everywhere.

On 24 bit machine (A1000/500/600/2000) you can have memory from $200000 to $A00000 or also from $c00000 to $D80000.
On 32 bit machine also from $01000000 to .. $80000000

EDIT:in any case normally on the A500 in the trap door is at $c00000

yeah - I think I was confused by my emulator not accepting a 512kb fast ram configuration into thinking that most fast ram was > 512kb.

Guess I will need to find a more robust way to find that start address.

[hooverphonique]

Originally Posted by Galahad/FLT

So long as you are dropping system friendly programming, then yes, using all of ram is fine.

As youve worked out, execbase offsets and pointers are located in that memory space at the start of $c00000, once you know you are finished with interrogating system resources, disable all interrupts and use $c00000 as your base address and use it all up.

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

[alpine9000]

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 bootstrap into chip ram, then load/relocate code into slow/fast or top 512kb of chip ram, so doesn't seem to be any problems there.

I mean, this code seems to work fine, it's just that I am now almost running out of slow/fast ram for the first time ever, so really trying to make sure I get access to every last byte available.

[StingRay]

Originally Posted by alpine9000

For this to work my assumption must hold that the largest available ram will be either:

(1) 512kb at $C00000 -or-
(2) >512kb somewhere else

Is it possible to have a 512kb expansion somewhere other than $C00000 ?

Don't assume any fixed memory locations at all! Properly detect the available memory and use that info for your memory consumption. Align the memory pointer if necessary but please do not assume any fixed memory locations at all.

[alpine9000]

Originally Posted by StingRay

Don't assume any fixed memory locations at all! Properly detect the available memory and use that info for your memory consumption. Align the memory pointer if necessary but please do not assume any fixed memory locations at all.

No, I don’t assume the location, I was just only aligning at c00xxxx. Looks like this was a bad assumption and I might also need to check for <512kb allocations elsewhere and also align those.

[phx]

Originally Posted by alpine9000

I bootstrap into chip ram, then load/relocate code into slow/fast or top 512kb of chip ram, so doesn't seem to be any problems there.

How did you do that? Did you write your own hunk-format relocator?

Otherwise, there is a little known feature of vlink, which I used in all of my games to output relocation tables: you have to use the "rawseg" output format and define segments with a linker script (e.g. a "chip" and a "fast" segment).

The linker will output a raw binary file for each segment, so you can load "chip" and "fast" binaries into different locations. Additionally, when specifying the -q (emit relocs) option, it writes a relocation tables for all segment combinations (usually only fast-fast and fast-chip).

These tables are simple to process for your loader: first longword is number of entries, followed by all the relocation offsets.

Example linker script from my latest game, which defines those two segments, and assigns the sections CODE, DATA, BSS and __MERGED (small data) to "fast" and chipmem to "chip". The base addresses, 0x400 and 0x1000000, are ignored.

PHDRS {
        fast PT_LOAD;
        chip PT_LOAD;
}

SECTIONS {
        . = 0x400;
        .chip: {
                *(chipmem)
                . = ALIGN(2);
                _FREECHIP = .;
        } :chip

        . = 0x100000;
        .text: {
                _START = .;
                *(CODE)
        } :fast
        .data: { *(DATA) }
        .sdata: {
                _LinkerDB = . + 0x7ffe;
                _SDA_BASE_ = . + 0x7ffe;
                *(.sdata __MERGED)
        }
        .bss: { *(BSS) }
}

[alpine9000]

Originally Posted by phx

How did you do that? Did you write your own hunk-format relocator?

Otherwise, there is a little known feature of vlink, which I used in all of my games to output relocation tables: you have to use the "rawseg" output format and define segments with a linker script (e.g. a "chip" and a "fast" segment).

The linker will output a raw binary file for each segment, so you can load "chip" and "fast" binaries into different locations. Additionally, when specifying the -q (emit relocs) option, it writes a relocation tables for all segment combinations (usually only fast-fast and fast-chip).

These tables are simple to process for your loader: first longword is number of entries, followed by all the relocation offsets.

Example linker script from my latest game, which defines those two segments, and assigns the sections CODE, DATA, BSS and __MERGED (small data) to "fast" and chipmem to "chip". The base addresses, 0x400 and 0x1000000, are ignored.

PHDRS {
        fast PT_LOAD;
        chip PT_LOAD;
}

SECTIONS {
        . = 0x400;
        .chip: {
                *(chipmem)
                . = ALIGN(2);
                _FREECHIP = .;
        } :chip

        . = 0x100000;
        .text: {
                _START = .;
                *(CODE)
        } :fast
        .data: { *(DATA) }
        .sdata: {
                _LinkerDB = . + 0x7ffe;
                _SDA_BASE_ = . + 0x7ffe;
                *(.sdata __MERGED)
        }
        .bss: { *(BSS) }
}

Actually I use your “vlink little known feature” with my own relocation code ;-)

I am pretty sure you helped me get it all working via email last year

[phx]

LOL. Sorry, I forgot.

But when it was a private email, then maybe others feel inspired now.

[NorthWay]

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