I think the table of contents needs regenerating, ATX format isn't listed, but is in section 14.4.
Personally, I would keep the how-to stuff, it's nice if I can go from, "I need to do this", to copy/paste code that does what I need doing (or something close to it), and it's also sometimes easier to get the principles from working code than a text description.
Yeah, I have to remember to update the TOC manually in LibreOffice Writer and forgot to do so.
The thing about code examples is that they very quickly get too big to keep inline in the document, and I don't have most of them written. Also, subjects like P/M graphics multiplexing and music I don't have much experience in. It feels like this might be too much going down the rabbit hole of rewriting stuff that has already been covered in a lot of books and other practical examples (e.g. demo source and MADS samples). But it might be a good place to dump reusable code I've had lying around like the TIA sound emulator.
I noticed there is a miss-match between central-io and character-io (I think it is central IO, CIO). Also, I think it would be useful to include the summary table of math functions (like the one in De Re), and a little bit on page zero usage (what is available in different environments).
Maybe a chapter listing all the current development environments (if only briefly mentioning each one, e.g. cc65, Atasm, Wudsn, mads Pascal)? Maybe organised by interpreted, compiled, assembled?
Derp, I realized a while back that I had gotten the name of CIO wrong but hadn't finished correcting it, thanks. Current environments might be a bit much to cover, plus I haven't actually used most of them. I'll probably stick to mostly MADS assembly while trying not to use too many esoteric MADS features so the 6502 assembly is recognizable.
A few comments:
- In page 6, the "MIN" example writes an erroneous value into A+1, a possible fix could be:
- In page 7, the table at top should say "Takes one stack byte" for the PHA/PLA and PHP/PLP combos.
Derp, thx, fixed. The problem with code fragments in the document is that you can't directly execute them to test them.
You could add the technique for testing if a value is between two numbers, instead of:
This is specially useful when you already know the state of the C flag, as the "sec" can be omitted.
Yeah, I need to add that one. For some ranges the SBC can be swapped with EOR, which is more convenient flags-wise -- I think I used that in an isdigit() routine.
And at last, I have seen big code to convert ATASCII to screen-codes many times, I think this could be added to the examples:
I've only learned of this trick recently and hadn't had time to analyze it. Don't want to just copy and paste other people's code in without understanding it, that's kind of janky. It's a neat trick, though, I might be able to save some bytes and cycles in AltirraOS with it.
One quick comment, you might want to include a section on interfacing Basic (and other languages) with assembler, e.g., how arguments are pushed/pulled from the stack, and values returned (I think via FP0?).
Also a list of different antic display types, e.g. bytes/line, colours (and registers used), etc.
I'm deliberately keeping BASIC stuff in the BASIC manual instead. At one point I started including it and then realized it would fill several chapters by itself. The Altirra Extended BASIC manual might be able to become an all-encompassing BASIC book, once I actually finish it. Same with the Hardware Manual, though it's more of a problem there as there's no how-to in that book.