How CPC handles run"foo.bin: through MC BOOT PROGRAMHow firmware loads programs is not as simple as one might think because of cassette/disk/third-party ROMS/compatibility/memory-layout.
- Firmware offers CAS IN OPEN, CAS IN DIRECT and CAS IN CLOSE to load programs. Initially for CPC464 and cassette. Can be used from a BASIC or binary loader just fine.
- When introducing disc drives (CPC464 with DDI-1, CPC664, CPC6128), Amstrad chose to implement API-compatible calls in extra ROM, making BASIC and a number of programs instantly compatible with disks. Cool.
- Firmware loads executable binaries through MC BOOT PROGRAM which reinits system from the start, but without any extra ROM, effectively making any CPC behave like a CPC464 without expansions.
Why firmware disables all ROMs when on run"foo.bin?
- It is a fact that disc firmware reserves memory, which can conflict. Is it to minimize the memory footprint of the DDI-1/664/6128 firmware and make things somehow more uniform between CPC series?
- Other third-party ROMs may reserve memory, which can conflict. Is it to avoid conflict, considering that programs that want compatibility will re-enable wanted ROMs?
- Is it that Amstrad considers that third-party ROMs target a BASIC environment, where the firmware controls memory. By contrast binary programs would be supposed to decide which ROM they want to use or not?
Anyway those choices make thing complicated for a binary loader that wants to load more.
- One has to re-enable disc ROM, or perhaps all ROMs?
- Even on re-enabling disc firmware, one has to choose the correct drive again, because first run" command might have occurred on drive B, which means probing for traces of that in memory. This feels hackish. See example code on : http://www.cpcwiki.eu/index.php/Programming:An_example_loader
- For these reasons, a basic loader is the easiest way to run binaries without resetting firmware. One gets kind of more compatibility (and hackability).
What was the actual mindset/rationale for choosing to disable all ROMs on run"foo.bin ?Edit: fix markup
I'm not sure I get what you mean by disabling ROMs. This is how it works:
- There can only ever be one expansion ROM enabled at a time because they all get mapped into the same address range. As soon as an RSX command has
been called, the CPC will disable the currently mapped ROM and enable the ROM that contains that command.
- The memory reserved by the ROMs is an index table of bar commands (RSXs) and what ROM they can be found on, so that BASIC can go looking for the
command. ie: When I type |MAXAM, BASIC recognises the "|" symbol (ú on French systems) looks for the command in the RSX table which tells it which ROM
contains that command. It then enables that ROM and then the first section of that ROM has a second jump routine to go to that particular command.
The more commands a ROM contains, the more memory it needs to reserve for its command index. This is why some games won't run if you have too many ROMs installed as they take so much space for all the commands that there's no longer enough space for the game.
Bryce.
MC BOOT PROGRAM was probably intended around scenarios like booting CP/M where the software in question was basically taking over the entire machine. The design of ROM handling allows each ROM to reserve a portion of RAM for work space but there is no guarantee that it will be in the same position when ROMs are reinitialised. I suspect that is mostly because nobody really considered the need for stateful information like which disk drive was active when designing the original system.
Quote from: Bryce on 14:56, 25 May 20
I'm not sure I get what you mean by disabling ROMs.
Disabling here means "firmware runs as they were not there". No RSX, no buffer, no code executed from ROM.
Of course firmware performs bank and rom switching several times per frame to perform its job. The question is not about this micro-level but about overall policy and rationale.
Quote from: Bryce on 14:56, 25 May 20
- The memory reserved by the ROMs is an index table of bar commands (RSXs) and what ROM they can be found on, so that BASIC can go looking for the
command. ie: When I type |MAXAM, BASIC recognises the "|" symbol (ú on French systems) looks for the command in the RSX table which tells it which ROM
contains that command. It then enables that ROM and then the first section of that ROM has a second jump routine to go to that particular command.
The more commands a ROM contains, the more memory it needs to reserve for its command index. This is why some games won't run if you have too many ROMs installed as they take so much space for all the commands that there's no longer enough space for the game.
Bryce.
ROM can cause
code to run at start time which can do more, reserve buffers, etc. The disc buffer for example.
The question is about "why run"foo.bin calls MC BOOT PROGRAM which loses information?"The current design decision makes it somehow clumsy/hackish to access the proper drive inside a simple binary started with
run"foo.bin .
The decision could have been: let firmware and everything stay as is, the binary program can call some special entry point like "MC RESET FIRMWARE IGNORING ROMS" if they need so.
Then could even have been a flag in the AMSDOS header to tell what the binary producer prefers. Binaries ported from tape would by default have current behavior. Binaries that are loaders for other binaries would trigger the other "non-reset" behavior.
The question might be more clear now: since
run"foo.bas" and
load"bar.bin" preserve everything, why would
run"foo.bin" perform a complete firmware reset, excluding all roms (even amsdos)?
Ok, now I understand your question better. My answer... No idea. Maybe because a .BAS file can be placed wherever the computer prefers it to be, whereas a BIN may need to be at a particular address which could corrupt existing data?
Bryce.
Quote from: andycadley on 15:05, 25 May 20
MC BOOT PROGRAM was probably intended around scenarios like booting CP/M where the software in question was basically taking over the entire machine. The design of ROM handling allows each ROM to reserve a portion of RAM for work space but there is no guarantee that it will be in the same position when ROMs are reinitialised. I suspect that is mostly because nobody really considered the need for stateful information like which disk drive was active when designing the original system.
Given what I know about the people and process at the time, the people knew well what there were doing.
It could be a "ancillary" reason related to Bryce's suggestion:
Quote from: Bryce on 17:44, 25 May 20
Ok, now I understand your question better. My answer... No idea. Maybe because a .BAS file can be placed wherever the computer prefers it to be, whereas a BIN may need to be at a particular address which could corrupt existing data?
Well, on
load"foo.bin and run"foo.bin the firmware checks that the address range fits inside allowable range, yet they chose different strategies.
Perhaps they were "simply" short on time and observed that chosen behavior allowed more standalone CPC464 binaries to run unmodified in a 464-with-DDI-1/664/6128. For people who do not want to reset firmware, a BASIC loader still allows it, so they would focus on other, more urgent issues, than provide more flexibility?
Perhaps there is a more sound rationale, in case it's best to know it.
Notice that not resetting firmware means better compatibility with alternate filesystems (either ROM or in RAM) for example serial interface Universal Serial Interface for Amstrad CPC (a.k.a USIfAC) (https://www.cpcwiki.eu/forum/amstrad-cpc-hardware/universal-serial-interface-for-amstrad-cpc/).
This is the reason why the firmware provides indirection to patch CAS READ and CAS WRITE with custom routines.
Quote8.13 Low Level Cassette Driving.
To allow the user to produce a new filing system the record read and write routines, CAS
READ and CAS WRITE, are in the firmware jumpblock. There is a third routine at this
level, CAS CHECK, whose facilities are not used by the higher levels of the Casssette
Manager. It allows the data that has been written to tape to be compared with the data in
store. This could be used to perform a read after write check if so desired.
These possibilities that the engineers prepared and documented, with actual firmware behavior are possible in the case
run"foo.bas
but it gets broken when running
run"foo.bin.
Thread related to patching firmware to load files through a different mechanism: https://www.cpcwiki.eu/forum/programming/mc-startboot-program-without-reseting-firmware-jumpblock/
I'm pretty sure that the developers were under major pressure to get a stable release out. Optimising things for flexibility wouldn't have been at the top of their priorities list.
Bryce.
The disk system didn't even exist when they were writing the firmware. Lots of decisions had to be made on vague assumptions about future requirements (a common problem with building a platform) and to be honest I'm not sure there is a good solution that would have avoided it short of specifically reserving certain memory locations for the exclusive use of a disk system (though that would require guessing how much non-scratch RAM would be required)
Given the constraints at the time, I think they probably made a good decision and probably better than several contemporary platforms.