|
|
|
@@ -9,24 +9,34 @@ either for another RC2014 or for an OS upgrade. |
|
|
|
* stage3 from `sdcard` recipe. If you want to write to EEPROM as the final step, |
|
|
|
you'll need a hybrid stage3 that also includes stuff from the `eeprom` recipe. |
|
|
|
|
|
|
|
## Building stage 1 |
|
|
|
## Building the binary |
|
|
|
|
|
|
|
Build Collapse OS' stage 1 from within Collapse OS is very similar to how we do |
|
|
|
Build Collapse OS' from within Collapse OS is very similar to how we do |
|
|
|
it from the makefile. If you take the time to look at the base recipe |
|
|
|
`Makefile`, you'll see `cat xcomp.fs | $(STAGE2)`. That's the thing. Open |
|
|
|
`xcomp.fs` in a text editor and take a look at it. |
|
|
|
`Makefile`, you'll see `cat xcomp.fs | $(STAGE)`. That's the thing. Open |
|
|
|
`xcomp.fs` in a text editor and take a look at it. You'll see that it loads |
|
|
|
B618, which contains the meat, and then spits stuff to port 2, which is a |
|
|
|
special signal for the `stage` binary. |
|
|
|
|
|
|
|
To assemble from RC2014, all you need to do is load B618. This will |
|
|
|
yield a binary in memory. To know the start/end offset of the binary, you'll |
|
|
|
type the same two commands and in `xcomp.fs`, but replace the `/MOD 2 PC! 2 PC!` |
|
|
|
words with `.X`. Then, write that binary between those offsets on your target |
|
|
|
media. That binary should be the exact same as what you get in `os.bin` |
|
|
|
when you run `make`. |
|
|
|
|
|
|
|
To assemble stage 1 from RC2014, all you need to do is to type those commands |
|
|
|
in the same order, and replace the `/MOD 2 PC! 2 PC!` words with `.X`. |
|
|
|
Those commands will inform you of the begin/end offsets of the assembled binary. |
|
|
|
Go ahead, run that. However, one thing you should know is that because the SD |
|
|
|
card driver is a bit slow, some of these commands take a long time. Multiple |
|
|
|
minutes. Be patient. |
|
|
|
|
|
|
|
I'm not going to explain in detail what each command do, but only give you an |
|
|
|
overview of what is happening. You are encouraged to read the in-system |
|
|
|
Is that it? Yes. But for your own enlightenment, open B618 and look at it, I'll |
|
|
|
give you an overview of its contents. I'm not going to explain in detail what |
|
|
|
each command do, however. You are encouraged to read the in-system |
|
|
|
documentation for more information. |
|
|
|
|
|
|
|
The first part is configuration of your new system. When RAM starts, where RSP |
|
|
|
starts, what ports to use for what device, etc. These configuration declarations |
|
|
|
are expected in the boot code and driver code. |
|
|
|
and PSP start, what ports to use for what device, etc. These configuration |
|
|
|
declarations are expected in the boot code and driver code. |
|
|
|
|
|
|
|
Then, we load the Z80 assembler and the cross compiler (xcomp for short), which |
|
|
|
we'll of course need for the task ahead. |
|
|
|
@@ -41,41 +51,15 @@ close the binary with a hook word. We're finished with cross-compiling. |
|
|
|
|
|
|
|
We're at the offset that will be `CURRENT` on boot, so we update `LATEST`. |
|
|
|
|
|
|
|
Then, we spit the source code that will be interpreted by stage 1 on boot so |
|
|
|
that it bootstraps itself to a full interpreter. Not all units are there |
|
|
|
because they don't fit in 8K, but they're sufficient for our needs. We also |
|
|
|
need the linker so that we can relink ourselves to stage 2. |
|
|
|
|
|
|
|
Finally, we have initialization code, then a spit of the ending offset. |
|
|
|
|
|
|
|
Go ahead, run that. However, one thing you should know is that because the SD |
|
|
|
card driver is a bit slow, some of these commands take a long time. Multiple |
|
|
|
minutes. Be patient. |
|
|
|
|
|
|
|
Once all your commands are run and that you have your begin/end offset (write |
|
|
|
them down somewhere), you're at the same point as you were after the `make` |
|
|
|
part of the base recipe. The contents between your start and end offset is the |
|
|
|
exact same as the contents of `stage1.bin` when you run `make`. Continue your |
|
|
|
deployment from there. |
|
|
|
|
|
|
|
Good luck! |
|
|
|
Then, we spit the init source code that will be interpreted on boot. |
|
|
|
And... that's it! |
|
|
|
|
|
|
|
### What to do on SDerr? |
|
|
|
|
|
|
|
If you get `SDerr` in the middle of a LOAD operation, something went wrong with |
|
|
|
the SD card. The bad news is that it left your xcomp operation in an |
|
|
|
inconsistent state. If your at the beginning of it, it's easier to restart it |
|
|
|
entirely. |
|
|
|
|
|
|
|
If you're towards the end, you might want to repair it. To do so, you'll have to |
|
|
|
bring your `XCURRENT` and `HERE` values to where they were before the LOAD |
|
|
|
operation. You could have thought ahead and printed them before the LOAD, but if |
|
|
|
you didn't, you'll just have to dig in your memory with `DUMP`. |
|
|
|
|
|
|
|
You're looking at the offset of the last wordref of the *previous* LOAD |
|
|
|
operation. That offset is going in `XCURRENT`. Then, you're looking at the end |
|
|
|
of that word. That offset goes in `HERE`. Once you've done that, relaunch your |
|
|
|
LOAD. |
|
|
|
inconsistent state. The easiest thing to do it to restart the operation from |
|
|
|
scratch. Those error are not frequent unless hardware is faulty. |
|
|
|
|
|
|
|
### Verifying |
|
|
|
|
|
|
|
|
Virgil Dupras
4 years ago