Load Address problem * SOLVED *

[ervin]

Hi everyone.

As I'm developing my game, I'm trying to create regular DSK files in order to test on my 6128.
My game will eventually need a lot of memory, so I'd like to load the BIN file at &200.

When I assemble directly to memory inside WinAPE, &200 works nicely.
But when I try to run it from disk, I'm getting a memory full error.

I'm using this BAS file to load the BIN file:

Code Select Expand

10 MEMORY 511
20 LOAD"cpc.bin",512
30 CALL 512

When I run that code, I get "Memory full in 20".

Thanks for any suggestions.

[EDIT] Solved!

After a bunch more searching, I found a thread where the solution presented itself (thanks to Axelay).
I'm now able to put an executable BIN file on disk, without faffing around with the BAS file, thanks to this code in WinAPE's assembler window:

Code Select Expand

org &200
run &200
write direct "a:may2012.bin"
incbin "c:\ccz80 3.x\chunky pixel collision\may2012\may2012.bin"

[Devilmarkus]

In other cases use:

Code Select Expand

10 OPENOUT"D":MEMORY 511
20 LOAD"cpc.bin",512
30 CALL 512

[Devilmarkus]

It's not always good to use executable binary files.
Especially, when you use Firmware-routines.

[ervin]

In other cases use:

Code Select Expand

10 OPENOUT"D":MEMORY 511
20 LOAD"cpc.bin",512
30 CALL 512

Interesting, I'll give it a go.
Thanks.

I don't know what OPENOUT does, but I'll find out shortly.

[ervin]

It's not always good to use executable binary files.
Especially, when you use Firmware-routines.

What kind of problems could occur by doing this?
This is all still all quite new to me, so every bit of information helps. 

[arnoldemu]

What kind of problems could occur by doing this?
This is all still all quite new to me, so every bit of information helps. 

Unofficial Amstrad WWW Resource

When RUN is done, MC BOOT PROGRAM is called. This calls SOUND RESET, KL CHOKE OFF, KM RESET, TXT RESET, SCR RESET. These reset the current state of the firmware.
In addition it resets the firmware jumpblock, meaning the disc functions are no longer patched in and you have to then re-enable the disc rom to do furthur loading.

If you use basic, everything remains as it is.

[arnoldemu]

Interesting, I'll give it a go.
Thanks.

I don't know what OPENOUT does, but I'll find out shortly.

Unofficial Amstrad WWW Resource

It effectively allows memory addresses lower than about &1173. In terms of what OPENOUT actually does... not sure exactly but it does effect HIMEM.
The MEMORY command tells BASIC the upper HIMEM value, and where redefineable characters can be.. see the programming thread about basic tips.

[ervin]

Unofficial Amstrad WWW Resource

When RUN is done, MC BOOT PROGRAM is called. This calls SOUND RESET, KL CHOKE OFF, KM RESET, TXT RESET, SCR RESET. These reset the current state of the firmware.
In addition it resets the firmware jumpblock, meaning the disc functions are no longer patched in and you have to then re-enable the disc rom to do furthur loading.

If you use basic, everything remains as it is.

Excellent - thanks for all the info.

[ervin]

Unofficial Amstrad WWW Resource

It effectively allows memory addresses lower than about &1173. In terms of what OPENOUT actually does... not sure exactly but it does effect HIMEM.
The MEMORY command tells BASIC the upper HIMEM value, and where redefineable characters can be.. see the programming thread about basic tips.

Thanks again.
Sounds like OPENOUT is the way to go.

[arnoldemu]

Thanks again.

you are welcome!

[Axelay]

Unofficial Amstrad WWW Resource

When RUN is done, MC BOOT PROGRAM is called. This calls SOUND RESET, KL CHOKE OFF, KM RESET, TXT RESET, SCR RESET. These reset the current state of the firmware.
In addition it resets the firmware jumpblock, meaning the disc functions are no longer patched in and you have to then re-enable the disc rom to do furthur loading.

If you use basic, everything remains as it is.

Having to re-enble the the disc rom aside, under what circumstances would any of the rest of it be a problem?  Just wondering as I've been using the first few lines of this for, um, a while. 

[tastefulmrship]

I beginning to get a little concerned, too. I have always started my "programs" with the following;

Code Select Expand


ORG &xxxx

LD HL,(&BE7D)
LD A,(HL)
LD (Disk_Drive+1),A

LD C,&FF
LD HL,Restart_ROMs
CALL &BD16

.Restart_ROMs
CALL &BB57
CALL &BCCB
CALL &BB54

.Disk_Drive
LD A,0
LD HL,(&BE7D)
LD (HL),A


Is there some other code that's required to make sure .BIN files run without any unforseen errors?

[arnoldemu]

I beginning to get a little concerned, too. I have always started my "programs" with the following;

Code Select Expand


ORG &xxxx

LD HL,(&BE7D)
LD A,(HL)
LD (Disk_Drive+1),A

LD C,&FF
LD HL,Restart_ROMs
CALL &BD16

.Restart_ROMs
CALL &BB57
CALL &BCCB
CALL &BB54

.Disk_Drive
LD A,0
LD HL,(&BE7D)
LD (HL),A


Is there some other code that's required to make sure .BIN files run without any unforseen errors?

that seems ok to me and it's what I have done in the past.
You're reenabling all roms so that should be ok, because they will all patch firmware. So I think it's ok.

[SyX]

I use that method too, and i prefer to reinitialize all the roms, instead of only the rom 7, because i have ParaDOS in the rom position 6.

[arnoldemu]

Having to re-enble the the disc rom aside, under what circumstances would any of the rest of it be a problem?  Just wondering as I've been using the first few lines of this for, um, a while. 

well, the only problem I could see is if you wanted the program to be runnable from alternative media (harddrive, cpcsd) as these would patch into the load routines to allow amsdos to load data.

So if you initialise just the disc rom you are missing out on this, in addition you are missing out on using extended formats (parados).

The loader code in that example allows loading from extended formats and which ever drive it was run from which is also nice. it's really annoying when a loader forces loading from drive a for example.

Generally, other patching (such as making the firmware use 6 pixel wide font for example) may not be preferable to you, so resetting stuff like this is ok so you ensure you get the firmware as you expect.


generally the main problem of running a binary program from basic is the well known one - disc loading is not activated and you must do it yourself to continue loading.

[tastefulmrship]

Just to clarify; am I right in saying that if you do not wish to load anything else (ie, a single file program), you do not really need to reset the ROMs at the beginning of the program? Most normal Firmware functions (MODE, INK, etc) will still work as documented!

I use that method too, and i prefer to reinitialize all the roms, instead of only the rom 7, because i have ParaDOS in the rom position 6.

That code I posted was, after all, your code... like 90% of the stuff I do! ^_^ The other 10% is from arnoldemu, axelay, redbox and many others here!

[Axelay]

well, the only problem I could see is if you wanted the program to be runnable from alternative media (harddrive, cpcsd) as these would patch into the load routines to allow amsdos to load data.

So if you initialise just the disc rom you are missing out on this, in addition you are missing out on using extended formats (parados).

The loader code in that example allows loading from extended formats and which ever drive it was run from which is also nice. it's really annoying when a loader forces loading from drive a for example.

Generally, other patching (such as making the firmware use 6 pixel wide font for example) may not be preferable to you, so resetting stuff like this is ok so you ensure you get the firmware as you expect.


generally the main problem of running a binary program from basic is the well known one - disc loading is not activated and you must do it yourself to continue loading.

Thanks for the explanation.  Booting from either A or B is the main reason I use that bit of source, because I find only working from the A drive pretty annoying too. 


Nothing I've released has left the firmware in place though, that's why I only initialise the disk ROM, and any ROMs I wanted to use would need to be supported specifically in the code.  Sometimes I need to remove the firmware before I've finished loading too, so supporting a variety of media that needs to patch the firmware load routines would seem to become pretty messy.  But in future I'll try and produce CPCSD compatible versions where that's the case because the driver on PushNPop looked pretty straight forward, though from what I can tell there's a file format that's still a WIP at this point.

[dragon]

up!

In other cases use:

Code Select Expand

10 OPENOUT"D":MEMORY 511
20 LOAD"cpc.bin",512
30 CALL 512

An what happend if your search load a cpc.bin  out of range of memory instruction?

Example: 10 OPENOUT "D": MEMORY  &6D ->returns memory full.
                20 LOAD"cpc.bin",&6E
                30 rem "I don't want run it", only store it at &6E.

Impossible from basic?. So the only way is execute the .bin in &4000 for example and made a ldir to copy the code  to &6e?

[Ast]

Or make a bin loader ... Better way to load this kind of file....
Or use the arkos rom which allows to use ùld,"my file.bin",&6e
But it's an other story, isn't it ?