So this is a bit of a weird rant maybe, but what exactly makes 6502 code density so bad?
So there is a lz4 -> vram implementation that came with some version of neslib that I used to use. It compiled to 380 bytes, which seemed pretty good considering the amount of ROM it saved. When I started some GBdev, my first project was to make a lz4 decompression routine. My first (very rough) attempt was 250 bytes! Granted there is a bunch of complexity in the NES version to deal with PPU memory, but not *that* much. I then discovered gblz4 which touted a ~70 byte decompression routine although it used a modified lz4 format. I spent some time crunching my routine down, and eventually got a vanilla lz4 decoder in 67 bytes by by relaxing the "no memory use" constraint of gblz4.
380 bytes seemed like a lot compared to 67 bytes... Of course I had to try and reduce the size of the NES version now. :p After discussing compression in a different thread, I was inspired to whittle a few more bytes off tonight. It's now down to ... 250 bytes. (sad trombone) Not exactly fair to compare them 1:1 since the NES version has a pair of trampoline functions to allow it to work with either regular RAM or VRAM, and the VRAM. (Gameboy has no need for this, RAM is RAM) Still... it's almost 4 times larger.
My NES lz4 code is here for reference:
https://github.com/slembcke/critical-ma ... xler/lz4.s
https://github.com/slembcke/critical-ma ... _to_vram.s
So what is it that makes 6502 code so low density? I find GBZ80 much more frustrating to program. No indexing, a maddening lack of instruction orthogonality, etc. On the other hand, it has 16 bit registers, load + increment instructions, 16 bit increment instructions, conditional return, etc.
So there is a lz4 -> vram implementation that came with some version of neslib that I used to use. It compiled to 380 bytes, which seemed pretty good considering the amount of ROM it saved. When I started some GBdev, my first project was to make a lz4 decompression routine. My first (very rough) attempt was 250 bytes! Granted there is a bunch of complexity in the NES version to deal with PPU memory, but not *that* much. I then discovered gblz4 which touted a ~70 byte decompression routine although it used a modified lz4 format. I spent some time crunching my routine down, and eventually got a vanilla lz4 decoder in 67 bytes by by relaxing the "no memory use" constraint of gblz4.
380 bytes seemed like a lot compared to 67 bytes... Of course I had to try and reduce the size of the NES version now. :p After discussing compression in a different thread, I was inspired to whittle a few more bytes off tonight. It's now down to ... 250 bytes. (sad trombone) Not exactly fair to compare them 1:1 since the NES version has a pair of trampoline functions to allow it to work with either regular RAM or VRAM, and the VRAM. (Gameboy has no need for this, RAM is RAM) Still... it's almost 4 times larger.
My NES lz4 code is here for reference:
https://github.com/slembcke/critical-ma ... xler/lz4.s
https://github.com/slembcke/critical-ma ... _to_vram.s
So what is it that makes 6502 code so low density? I find GBZ80 much more frustrating to program. No indexing, a maddening lack of instruction orthogonality, etc. On the other hand, it has 16 bit registers, load + increment instructions, 16 bit increment instructions, conditional return, etc.