[Feature Request] Add special eReader Z80 Mode

[FexCollects]

I know this is a lot of effort listed below but mainly I'm curious if its something that would even be considered. I thought about just making my own assembler but its such a daunting task when something already exists that's 98% of the way there. Feel free to just close this if it doesn't make sense.

rgbds is surprisingly useful for developing and reverse engineering eReader Z80 applications but there are a few hurdles that must be hacked around. The addition of a flag like -ereader along with the following changes would be a huge boost to productivity and code cleanliness.

Opcodes supported by eReader but missing from gb

https://github.com/FexCollects/pokecarde/blob/master/macros.asm#L4

• Load Indirect HL: ld [nn], hl
• Load HL Indirect: ld hl, [nn]
• Load Indirect HL A: ld [hl], a
• Load Indirect HL B: ld [hl], b
• Load Indirect HL C: ld [hl], c
• Load A Indirect: ld a, [nn]
• Load A Indirect DE: ld a, [de]
• Load Indirect A: ld [nn], a
• Load A Indirect HL: ld a, [hl]
• Load B Indirect HL: ld b, [hl]
• Load C Indirect HL: ld c, [hl]
• Load D Indirect HL: ld d, [hl]
• Load E Indirect HL: ld e, [hl]
• Load L Indirect HL: ld l, [hl]
• Add A Indirect HL: add a, [hl]
• Exchange DE HL: ex de, hl

Opcdoes not supported by eReader but present in gb (should be an error)

• https://ereader.miraheze.org/wiki/Z80_Emulator_Limitations
• https://problemkaputt.de/gbatek-gba-cart-e-reader-program-code.htm (Under Z80/8080 Format)

Nice way to extract just the machine code

While the first two items are significantly more important, it would be really nice if there was a way to dump just the assembled machine code. Right now a lot of effort is put into stripping out all the gbc stuff added.

[Rangi42]

Basically "support the Z80 CPU as an alternative to the SM83 CPU". That sounds at least possible; however, what about the final ROM structure? Are the section types (ROM0, ROMX, WRAM0, WRAMX, etc) applicable to the e-Reader, or would we need to support different ones? It might have to wait for #524.

[FexCollects]

The final ROM structure is very basic for the eReader Z80 emulator. There is just a single section that starts at address $100 and iirc everything is ram. The final resulting output (that goes into special ereader tools) is just machine code that assumes org $100

There are actually a bunch of non-trivial z80 eReader projects that use rgbds as the toolchain with a few hacks slapped on top to make it work. Its pretty much just 1. define macros to fill in the missing opcodes 2. run some python code to strip off all the extra gb bits from the rom 3. hope you didn't accidently use an unsupported op code

I'm more than happy with the answer being no btw, not trying to cause stress or headaches. Just thought if it was something that made since here before trekking off into the wilderness to make my own and then have to port over all the code

[Rangi42]

Just to clarify, re: "a single section that starts at address $100", is this sufficient for e-Reader?

SECTION "Code+Data", ROM0[$100]
...

SECTION "RAM", WRAM0[$c000]
...

Assembling and linking this would produce a ROM with $100 padding bytes at the beginning of the file, before all the actual content; and it would still produce ROMs in multiples of $4000 bytes.

If that's fine for e-Reader purposes, then I think this could just be an rgbasm feature, to support Z80 opcodes and not support SM83 ones. (Suggestion: call it -z/--z80, then have -Z/--sm83, and support opt z and opt Z so you could mix both instruction sets in the same ROM.) And it wouldn't even break any backwards compatibility, it's purely a new opt-in feature.

[FexCollects]

Yep, sorry!

Actually the vast majority of programs will only ever use the ROM0[$100] section for the following reasons.

• that section is writable on the eReader (TBH I don't think there is any read only memory in the eReader's z80 emulator)
• The single most important thing for the eReader is total binary size. Every ~2k bytes (after compression) requires a new dotcode strip so padding is avoided like the plague
• Looks like ROM0 is 16KiB which is about 8 dotcode strips, and honestly 2 is really what most programs see as the upper limit (since 2 strips fit nicely on a single printed card, 3 strips requires another card)

I'm working right now, but I throw together a minimal working eReader project this evening for you to take a look at. For the most part its fairly straight forward

[FexCollects]

https://github.com/FexCollects/minimal-ereader-z80 as promised!

[Rangi42]

I see you trim the first $100 bytes after assembling+linking. At least for now we won't have a way to avoid that, since they're necessary for making the subsequent addresses correct. Same goes for building into the smallest multiple of $2000 bytes. Unclear what nevpk and nedcmake do, and if rgbds can or should be doing any of that (maybe it's the sort of thing rgbfix could be handling?).

[FexCollects]

Unclear what nevpk and nedcmake do, and if rgbds can or should be doing any of that

nevpk applies a custom compression algorithm that the eReader natively understands
nedcmake converts the binary to the format that actually gets printed on to the card, lots of metadata stuff in there for the eReader and I think that is also the step that chunks everything out and adds checksums/error recovery

IMO neither of those make sense to add to rgbds, they are quite complex tools and very specific to the eReader.

For me the biggest wins are supporting the opcodes and stripping the binary. Stripping $100 from the front is honestly a super easy task so that doesn't need anything special but stripping the back has been an annoying process. If rgbds must do the $2000 byte padding is there any way it could signal the address where the padding started? Anything that could be used by later tools to more easily stripped the back padding.

[Rangi42]

You can read the .map file to see where sections actually cover. Although that's a nontrivial parsing job. It might be feasible to add as an rgblink feature.