I've noticed that under certain conditions, such as a stack overflow,
I would segfault, something I though was impossible because my memory
size is 0x10000 and all my integer variables are uint16_t.
After having re-read my C handbook, it seems I wasn't sufficiently
knowledgeable about type conversion rules.
If a line has a char below 0x20, we consider the line ended, we
stop the EMIT loop for this line and spit our NL.
This makes LIST stop wasting rows in environments with a tight
screen.
This allows us (in the following commit), to stop unvariably
spitting 64 chars by line in LIST. This way, short lines don't use
3 rows per line (the line number uses 3 chars, which brings us to
67 chars per line).
If we don't do that, we end up with the old contents of the line
being kept at the right of the printed line.
The '2' key on my PS/2 keyoard never worked on Collapse OS, I
wasn't sure why. I thought the keyboard was broken, but then I
tried another one, still broken. But it's only the '2'!
The KC sent is 0x1f. Is it a timing problem with the ATtiny? I
have yet to wire my prototype for logic probing. Meanwhile, let's
apply a band-aid.
Add _TRA!, _THA!, _TRB!, _THB! routines to easily handle those pins'
value without stepping on other pins like the drivers previously
did. For SDC driver, it's going to be important soon because it turns
out that I can't get away with "always on" CS, so I'll need a scheme
where it's important that TH/TR pins have stable values.
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...)
Virgil Dupras