Daniel Everett, a linguist who studied the Piraha - a small tribe of hunter-gatherers in Brazil - reported that while the Piraha know of food preservation techniques, they don't actually preserve any food for their own use. Instead, tribe members immediately share and consume their catch with the rest of the tribe, as a sort of gift economy. Preserved food isn't needed because at any one time, one of the tribe is sharing their bounty.
As one of them explained, "I store meat in the belly of my brother".
You're probably wondering what the heck all of this has to do with 7800basic. I've been recently reminded that our retro development community has a similar economy of good will. Instead of hoarding some new technique or tool, developers openly share their discovery. Help received is paid forward in the forums. Those that can't code, test builds, create art, and offer advice.
7800basic hasn't been released yet, but already I've been receiving help. batari gifted his source code to the project. Eric Ball loaned me his irreplaceable CC2 so I could test 7800basic on real hardware. Bruce Tomlin gifted his sign7800 program. CPUWIZ assisted with bankswitching questions.
None of these guys benefit directly from 7800basic being created, but they've openly shared what they can to make it a reality.
I can't help but reflect on how cool it is to be a part of this tribe.
The title of the entry says "update", so I guess I should give a quick update on 7800basic progress.
This week I finished the first pass of documentation, added a built-in (optional) pause-button handler, and wrote the bankswitch code.
The elephant in the room that I've been ignoring until now is graphical ROM layout. I'm using DMA holes to avoid having to pad graphics with a bunch of zero bytes. This works great, but any time there are two or more graphic blocks in a ROM it makes it tricky to fill the hole between them in a useful and easy way. (keep the jokes clean, folks)
My first pass at a solution for using this space will probably be to take any "alphadata" character display data and throw it into any holes. This is low-hanging fruit because it can easily be measured before the resulting assembly code is sent to dasm, so I don't have to worry about overflowing the hole. The downside is, unless your game has a ton of character data the holes probably won't be 100% used.
I'm kicking around some ideas that would allow the basic coder to stick routines and regular data in holes, but none of them are likely to make it into the code before the beta release.
Which is a nice segue for the next bit of info. At the current rate of progress the beta release should be ready in weeks, not months, and I'm already looking forward to seeing what you guys do with it.