Recipes contain bits and pieces of hardware-related knowledge, but
these bits feel sparse. I've been wanting to consolidate hardware-
related documentation for a while, but always fell at odds with the
recipes organisation.
We don't have recipes anymore, just a /doc/hw section that contains
hardware-related documentation which often translate to precise
instructions to run Collapse OS on a specific machine.
With this new organisation, I hope to end up with a better, more
solid documentation.
Theoretically, it works. I can access an emulated SD card on it.
Will it work on real hardware?
I've also made SMS emulation faster. It was unbearably slow for SDC
access.
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.
This would be useful, for example, to allow the assembler to write
straight to an AT28 EEPROM without going to RAM. This would be a
life saver in machines with tight RAM such as the SMS.
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.
I think that when I added NL, I had troubles having access to CRLF's
address at boot time, which is why I had this system. But now that
CRLF is easily accessible during BOOT, we can simplify.
(and that will help us in the hopefully-upcoming change, which is
quite nice...)
Running a ROM on an everdrive is one thing, but running a ROM
directly is another: my hacked up sega.bin didn't have a proper
checksum, so the ROM didn't run.
This new tool transforms a binary into a properly-headered ROM.
Has been tested on an actual SMS.
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.
After many trials and errors in reliably accessing AVR chips through
my SPI relay design, I resigned myself to accepting 125kHz communication
speed with it. I find the complexity of solutions allowing to keep 250kHz
speeds to be excessive.
