By default, it changes nothing, but it allows interesting
setups, such as using AT28! for directly uploading to EEPROM.
I've also updated the EEPROM recipe to upload directly to 0x2000.
I'm not sure what has changed, but it's working fine now.
Working on programming AVR chips exposes a glaring omission in my
first design of the SPI Relay: not allowing multiple devices make
this task hard. I constantly have to unplug my SD card before, plug
the AVR chip holder, then play a bit, then unplug the AVR holder,
then replug the SD card...
My prototype for a SPI relay design is built, but I haven't tested
it yet. I need to adapt the code first, which is what I do here.
When the prototype is tested, I'll update the SDC recipe with a new
schema.
AVR chips often run at less than z80's system clock. This means that
our SPI relay needs to have its own clock to properly communicate
with it. This means that the delay between OUT and IN can't be
hardcoded to 2 NOPs anymore. It needs to be configurable.
Although the SPI Relay driver is RC2014-specific, the SD Card driver
is generic enough to be a subsystem. That's the second subsystem we
add and this warrants, I think, the formalization of a new concept:
protocols.
Previously, it could never write more than a few bytes before pingpong
getting a mismatch error. Now, I can pingpong Collapse OS binary
without a mismatch.
Previously, recipes that began spitting binary contents before
loading block 282 would end up with VARIABLE code in their binary,
thus breaking them. We fix this by making this loading process
2-part.
I'm not sure yet where I'm going, but I'm not going to build the
8086 port from the ground up like I did with the z80, that is,
making is sustain itself and eventually merge its forth code with
core words. That would be too much work which would then be thrown
out (all those words I'll initially have to implement in asm which
are already implemented in Forth).
What I *think* I can do is build a mirror version of z80 boot code
and cross-compile it from the z80. This means it has to follow z80
stable ABI.
Nope, I'm not sure where I'm going...
