I replaced some doubled up nops with pushes and pops again, saving two bytes. There was also a nop in a loop that didn't look necessary, since the jump back to the top of the loop is already 13 cycles, so way more than 80 cycles are spent in that loop anyway.
I reworked things a little in parseHexPair and saved 5 bytes and 6 cycles, with more cycles saved in error cases.
There were some doubled up nop's, so I replaced them with paired pushes and pops, saving 4 bytes and wasting 2-3 extra cycles over the original nop's, so there shouldn't be a problem with not waiting long enough.
* Optimised intoXX functions
Rewrote intoXX functions to mainly rely on intoHL, as the HL instructions are smaller and faster. Also removed some redundant push and pop instructions. I edited the given unit tests to test these, and they seem to work as expected.
* Doesn't use self-modifying code
The number of bytes is the same as my previous attempt, with 11 more cycles in intoHL, so although I don't feel as clever this time it's still a good optimisation. I found an equivalent method for intoDE, however relying on intoHL still allows for `ex (sp), hl` to be used in intoIX, which is smaller and faster.
* Update core.asm
* Tried harder to follow coding convention
Added tabs between mnemonics and operands, and replaced a new line I accidentally removed.
Sure, it's a bit slower, but it prevents a lot of hard to debug
problems. I don't have to want to remember "don't use IX if you
have any blk* calls". Let's optimize I/O later.
When there's a mismatch, retry up to a certain number of times.
This makes random problem related to assembling big kernels go away! But
it also make SD card reading much slower...
For now, this achieves nothing else than wasting cycles, but this is the
first step in enabling CRC verifications (CMD59).
I think that this is where my random problems with assembling large
kernels from SDC come from: bad data that isn't detected. If that
happens when PGM loads programs in memory, then anything can happen.
`sdct`, when ran often enough, will error out or corrupt away (go
crazy)...
