My idea of plugging a RC2014 bridge directly onto a Sega Master System
cartridge doesn't work. The SMS eats all I/O addr space, we can't use
it. Therefore, this naive idea, in the emulator, of reusing sdc.c in
sms.c as-is, doesn't work either.
I'll have to find another way of communicating to a SPI device on the
SMS. I'll probably do it through a controller port. Meanwhile, I need
to decouple SPI from SDC in the emulator code so that I can reuse
sdc.c. This is what is done here.
With KEY and EMIT being switch words, most of the high layer can
be defined before drivers.
In addition to this change, I've compacted core blocks which were
becoming quite sparse.
also, verify all 3 first bytes of SPI commands. I'm not sure why
I wasn't doing that, probably because I was getting a lot of AVR
err and thought that only 2 bytes of the cmd were echoed. But now,
with a reliable SPI setup, verifying 3 bytes seems to work.
The idea is to consider assemblers as "runtime" apps instead of
placing them in the "bootstrap" section of the blocks. These apps
will be used for much more than bootstrapping.
Moved its documentation to doc/asm.txt and made its code blocks
more compact.
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.
This allows us to move words like ABORT" to xcomp-core, which is
I think the last roadblock before being able to unify all drivers
into a single xcomp layer.
