mirror of
https://github.com/hsoft/collapseos.git
synced 2024-12-24 14:18:06 +11:00
rc2014: move xcomp unit's contents to blkfs
This commit is contained in:
parent
a8e8204eba
commit
b606dbf9af
2
blk/580
2
blk/580
@ -4,4 +4,4 @@ Support code for the RC2014 recipe. Contains drivers for the
|
||||
ACIA, SD card and AT28 EEPROM.
|
||||
|
||||
581 ACIA 590 AT28 EEPROM
|
||||
600 SD card
|
||||
600 SD card 618 Xcomp unit
|
||||
|
15
blk/618
Normal file
15
blk/618
Normal file
@ -0,0 +1,15 @@
|
||||
0x8000 CONSTANT RAMSTART
|
||||
0xf000 CONSTANT RS_ADDR 0xfffa CONSTANT PS_ADDR
|
||||
0x80 CONSTANT ACIA_CTL 0x81 CONSTANT ACIA_IO
|
||||
4 CONSTANT SDC_SPI
|
||||
5 CONSTANT SDC_CSLOW 6 CONSTANT SDC_CSHIGH
|
||||
RAMSTART 0x70 + CONSTANT ACIA_MEM
|
||||
212 LOAD ( z80 assembler )
|
||||
262 LOAD ( xcomp ) 270 LOAD ( xcomp overrides )
|
||||
282 LOAD ( boot.z80 ) 393 LOAD ( xcomp core low )
|
||||
582 LOAD ( acia )
|
||||
420 LOAD ( xcomp core high )
|
||||
(entry) _
|
||||
( Update LATEST )
|
||||
PC ORG @ 8 + !
|
||||
," : _ ACIA$ RDLN$ (ok) ; _ "
|
@ -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 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.
|
||||
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`.
|
||||
|
||||
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
|
||||
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.
|
||||
|
||||
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
|
||||
|
||||
|
@ -1,23 +1,3 @@
|
||||
0x8000 CONSTANT RAMSTART
|
||||
0xf000 CONSTANT RS_ADDR
|
||||
0xfffa CONSTANT PS_ADDR
|
||||
0x80 CONSTANT ACIA_CTL
|
||||
0x81 CONSTANT ACIA_IO
|
||||
4 CONSTANT SDC_SPI
|
||||
5 CONSTANT SDC_CSLOW
|
||||
6 CONSTANT SDC_CSHIGH
|
||||
RAMSTART 0x70 + CONSTANT ACIA_MEM
|
||||
212 LOAD ( z80 assembler )
|
||||
262 LOAD ( xcomp )
|
||||
270 LOAD ( xcomp overrides )
|
||||
|
||||
282 LOAD ( boot.z80 )
|
||||
393 LOAD ( xcomp core low )
|
||||
582 LOAD ( acia )
|
||||
420 LOAD ( xcomp core high )
|
||||
(entry) _
|
||||
( Update LATEST )
|
||||
PC ORG @ 8 + !
|
||||
," : _ ACIA$ RDLN$ (ok) ; _ "
|
||||
618 LOAD
|
||||
ORG @ 256 /MOD 2 PC! 2 PC!
|
||||
H@ 256 /MOD 2 PC! 2 PC!
|
||||
|
Loading…
Reference in New Issue
Block a user