Bootblock load address

[hop]

I know that when a disk boots, the bootblock "sectors are read into the system at an arbitrary position", but what position is this in practice? Is it a known range for an unexpanded A500 or one with half meg slow ram?

I get the impression that a common pattern in the bootblock of classic non-DOS games is to DoIO the next block of code to a hard-coded chip ram address then jmp into it. I suppose there is always a chance that the read will stomp the bootblock so the coder would have to hope for the best. I've seen this pattern which seems safe: PEA <entry point> : JMP DoIO to ensure the bootblock code is finished with. Would coders sometimes JSR DoIO : JMP <entry point> and hope the JMP didn't get stomped, or did they know "safe ranges"?

Thanks for any insight.

[phx]

Usually new memory blocks are allocated from lower to higher addresses. So the probability that high memory regions are in use is quite low during the boot phase (for example >

$70000

for a 512K A500).

But not impossible. A good coder uses

AllocAbs()

to confirm that the prefered region is available.

[Galahad/FLT]

Bootblock is usually in quite low memory, for instance on an A500 with 512k chip and 512k slow, the bootblock can be loaded as low as $1558, on other Amigas between that address and $59e8.

So usually on a clean booted system or just reset system, people have usually loaded code from the bootblock to something like $40000 or higher for safety, you could of course try and allocate that space, but typically, that memory is clean and free.

Then once loaded to that address and jumping to the code at say $40000, I usually then transfer my code back down to low memory and run from there.

[hop]

Thanks very much.

[hop]

Originally Posted by Galahad/FLT

Then once loaded to that address and jumping to the code at say $40000, I usually then transfer my code back down to low memory and run from there.

Thanks for this tip. I guess this is to reduce chip memory fragmentation and give a nice contiguous block to work with.

[hooverphonique]

Another thing to consider is where the stack(s) are located when loading to absolute adresses from the bb.

[Galahad/FLT]

Originally Posted by hooverphonique

Another thing to consider is where the stack(s) are located when loading to absolute adresses from the bb.

Main stack is always at the top of available chipmemory or top of slow/fast if installed.

User Stack is low in memory, near to where the bootblock is loaded.

So long as you load from $40000 or higher, then disable interrupts, relocate your code and set the stacks as you like, its never an issue.

[redblade]

I'm guessing the OS checks to see how much CHIP ram is available and loads it at some random location in CHIP compared to MSDOS which has a fixed memory address of $7C00?

[paraj]

Originally Posted by redblade

I'm guessing the OS checks to see how much CHIP ram is available and loads it at some random location in CHIP compared to MSDOS which has a fixed memory address of $7C00?

Much of the OS is up and running at this point (and chipmem is known for sure). Notably exec/expansion, but not dos. So in principle you could have an "evil" expansion board allocating a bunch of chipmem. The load address of the bootblock isn't "random" in the usual sense of the word (it's always the same for a given config cold-booted), but shouldn't be depended upon.
(And for DOS IIRC you can't rely on whether you're started at 0x0:7c00, 0x7c0:0 etc if you want to be compatible with all BIOSes )

[Galahad/FLT]

Bootblock allocation is done in system friendly way but bootblock is ALWAYS located in chip mem and as low as possible, simply because its one of the first things in the memory allocation list.

[ross]

Originally Posted by Galahad/FLT

Bootblock allocation is done in system friendly way but bootblock is ALWAYS located in chip mem and as low as possible, simply because its one of the first things in the memory allocation list.

No
From KS2.0+, bootblock code can be in any type of ram, and usually in fast-ram if available.

EDIT:
not that anything actually changes, the vast majority of those who use the bootblock to take control of the system expect that their code must also work on machines with KS1.x (the OCS releases) or with chip-ram only (base A500+/A600/A1200..).

[Galahad/FLT]

Originally Posted by ross

No
From KS2.0+, bootblock code can be in any type of ram, and usually in fast-ram if available.

EDIT:
not that anything actually changes, the vast majority of those who use the bootblock to take control of the system expect that their code must also work on machines with KS1.x (the OCS releases) or with chip-ram only (base A500+/A600/A1200..).

Ha, I stand corrected, I never knew that, just checked it out and you're right.

Doesn't make any real world difference as it still means bootblock will likely never be touched accidentally as its never near the safe area on a clean boot, but thats a new one for me!

[a/b]

Bootblock location depends on device driver's preferred memory type. That used to be chip memory for trackdisk device back in KS1.3 (the reason might be blitter assisted MFM decoding) but at some point, as Ross pointed out, it was changed to public memory.

[hooverphonique]

Originally Posted by Galahad/FLT

Main stack is always at the top of available chipmemory or top of slow/fast if installed.

User Stack is low in memory, near to where the bootblock is loaded.

I suppose main stack means supervisor stack? Anyway, my point is that you need to consider where these are.. When reading the suggestions here, one could easily be led to think it's fine to load into the top of chipram, which could overwrite the mentioned stack

Originally Posted by Galahad/FLT

So long as you load from $40000 or higher, then disable interrupts, relocate your code and set the stacks as you like, its never an issue.

That's true, with the exception that if you need to support A1000 with 256k chip, a lower address is better.

[Galahad/FLT]

Originally Posted by hooverphonique

I suppose main stack means supervisor stack? Anyway, my point is that you need to consider where these are.. When reading the suggestions here, one could easily be led to think it's fine to load into the top of chipram, which could overwrite the mentioned stack

That's true, with the exception that if you need to support A1000 with 256k chip, a lower address is better.

Nope, no consideration for 256k A1000's at all, in fact I doubt any A1000 that was sold stayed at 256k because it was unusable.

Lower than $40000 and you're inviting problems.

[Don_Adan]

From my memory kick 1.2 or 1.1 set stack at $40000, not at $80000, even for Amigas with 0.5MB chip RAM.

[Galahad/FLT]

Originally Posted by Don_Adan

From my memory kick 1.2 or 1.1 set stack at $40000, not at $80000, even for Amigas with 0.5MB chip RAM.

Definitely not kick 1.2 as that's what I had, and kick 1.1 is A1000 so I literally don't care about it lol

[hop]

Thanks very much for all the information.

[admiral]

Originally Posted by Galahad/FLT

Doesn't make any real world difference as it still means bootblock will likely never be touched accidentally as its never near the safe area on a clean boot, but thats a new one for me!

Why not just return from the bootblock?

Then you get to tell the system where to jump (generally dos.library init routine but can be anything you want), and the memory the bootblock used is already freed at that point.

[Galahad/FLT]

Originally Posted by admiral

Why not just return from the bootblock?

Then you get to tell the system where to jump (generally dos.library init routine but can be anything you want), and the memory the bootblock used is already freed at that point.

I dont get what you mean?