English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Asm / Hardware

 
 
Thread Tools
Old 13 March 2018, 01:55   #1
alpine9000
Registered User

 
Join Date: Mar 2016
Location: Australia
Posts: 592
Allocating 0xC00000 memory

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 ?
alpine9000 is offline  
Old 13 March 2018, 07:32   #2
StingRay
move.l #$c0ff33,throat

StingRay's Avatar
 
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,026
Why not just checking Exec's MemList for the largest available block (either chip or fast) during boot?
StingRay is online now  
Old 13 March 2018, 07:34   #3
alpine9000
Registered User

 
Join Date: Mar 2016
Location: Australia
Posts: 592
Quote:
Originally Posted by StingRay View Post
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
alpine9000 is offline  
Old 13 March 2018, 09:01   #4
Galahad/FLT
Going nowhere

Galahad/FLT's Avatar
 
Join Date: Oct 2001
Location: United Kingdom
Age: 45
Posts: 6,977
Quote:
Originally Posted by alpine9000 View Post
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.
Galahad/FLT is offline  
Old 13 March 2018, 09:11   #5
alpine9000
Registered User

 
Join Date: Mar 2016
Location: Australia
Posts: 592
Quote:
Originally Posted by Galahad/FLT View Post
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?
alpine9000 is offline  
Old 13 March 2018, 09:19   #6
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 21,762
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.

Quote:
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
Toni Wilen is offline  
Old 13 March 2018, 09:20   #7
ross
Omnia fert aetas

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 1,044
even $0 if you make some slalom between vectors

EDIT: ops.. Toni first
ross is online now  
Old 13 March 2018, 09:25   #8
alpine9000
Registered User

 
Join Date: Mar 2016
Location: Australia
Posts: 592
Quote:
Originally Posted by Toni Wilen View Post
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.
alpine9000 is offline  
Old 13 March 2018, 09:46   #9
ross
Omnia fert aetas

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 1,044
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:

Code:
_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)
ross is online now  
Old 13 March 2018, 10:01   #10
alpine9000
Registered User

 
Join Date: Mar 2016
Location: Australia
Posts: 592
Quote:
Originally Posted by ross View Post
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 ?
alpine9000 is offline  
Old 13 March 2018, 10:08   #11
ross
Omnia fert aetas

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 1,044
Quote:
Originally Posted by alpine9000 View Post
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
ross is online now  
Old 13 March 2018, 10:24   #12
alpine9000
Registered User

 
Join Date: Mar 2016
Location: Australia
Posts: 592
Quote:
Originally Posted by ross View Post
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.
alpine9000 is offline  
Old 13 March 2018, 10:30   #13
hooverphonique
ex. demoscener "Bigmama"
 
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 786
Quote:
Originally Posted by Galahad/FLT View Post
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
hooverphonique is offline  
Old 13 March 2018, 10:37   #14
alpine9000
Registered User

 
Join Date: Mar 2016
Location: Australia
Posts: 592
Quote:
Originally Posted by hooverphonique View Post
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.
alpine9000 is offline  
Old 13 March 2018, 11:00   #15
StingRay
move.l #$c0ff33,throat

StingRay's Avatar
 
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,026
Quote:
Originally Posted by alpine9000 View Post

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.
StingRay is online now  
Old 13 March 2018, 11:03   #16
alpine9000
Registered User

 
Join Date: Mar 2016
Location: Australia
Posts: 592
Quote:
Originally Posted by StingRay View Post
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.
alpine9000 is offline  
Old 13 March 2018, 12:17   #17
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,163
Quote:
Originally Posted by alpine9000 View Post
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.

Code:
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) }
}
phx is offline  
Old 13 March 2018, 12:22   #18
alpine9000
Registered User

 
Join Date: Mar 2016
Location: Australia
Posts: 592
Quote:
Originally Posted by phx View Post
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.

Code:
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
alpine9000 is offline  
Old 13 March 2018, 13:12   #19
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,163
LOL. Sorry, I forgot.

But when it was a private email, then maybe others feel inspired now.
phx is offline  
Old 13 March 2018, 14:25   #20
NorthWay
Registered User
 
Join Date: May 2013
Location: Grimstad / Norway
Posts: 455
And it could also be that chipram is 1M or 2M so don't fall over if you don't find another chunk.
NorthWay is offline  
 


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

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

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 15:48.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.
Page generated in 0.23474 seconds with 14 queries