Topic: A virtual 1-bit hardware proposal, 1-BOY
Recently I was messing around with the tiny DIY consoles a lot, such as Gamebuino, Arduboy, and ESPboy (even made a tracker for the latter). This led me to thinking how much things feels wrong in most of these, or that I'd like to be done in a different way. For one, they're all tied to a proprietary hardware that gets modified or obsoleted as the time goes, and today it is quite difficult to make a correctly functioning Gamebuino or Arduboy without a kit, using of the shelf parts. Like, you have to burn a custom bootloader with an ISP programmer, and the bootloader is not compatible with the modern AVR chip revisions - does not exactly feel like an Arduino based project anymore.
Eventually I came up with the thought: why not design a platform like these the way I'd like to see it - I totally capable to do it. Hence this idea was born, to make a virtual platform that is strictly 1-bit in the media output (visuals, sound), much like Arduboy, but that is prone to the hardware compatibility issues, like CHIP8, and can be both interesting OR easy to program. I plan to design it as an emulator (virtual machine), then make my own custom hardware implementation (MCU based, emulation driven as well). All open source, of course.
I would call this thing 1-BOY and steal the 1-bit forum header design for its own logo. I'm totally sure not many outside our community will get interested with it, but whatever. We deserved to have our own 1-bit platform, after all.
The basics are:
128x64 1-bit display, can be LCD, OLED or TFT in the hardware implementation (unified frame buffer access only, no direct control)
1-bit stereo sound
8 buttons (D-Pad, A/B, L/R shoulders)
Z80 core at some higher-than-normal frequency
64K of RAM
Programmable interrupts
Some extras
Yep, much like ZX Spectrum or TI calcs, but in a portable console shape and DIY. It could be programmed directly in Z80 assembly, as we like it, or in C using SDCC and a custom library to handle sprites etc. It does not consider huge games, because no one is going to make those for such a basic device anyways (but an overlay loading is considered in the extras).
Now the interesting question is the sound system. I can see plenty of ways how to design it in a most interesting way to explore it later - we basically can have anything we couldn't with the real hardware. However, unlike the hardware that could go insane bit flip frequencies, it will be always affected by the sample rate, and considering the hardware version of it is going to run at a less than stellar cheap MCU at first (something like 160-240 MIPS), it won't be too high.
Possible ideas I've had. I'm not sure which one to stick to:
1) A register with 8 output bits, each acting as a beeper. Two additional registers to control each of the bits, to direct it to the left, right, center, or mute. Like, %BBBBBBBB (8 beeper output), %LLLLLLLL and %RRRRRRRR (routing to L/R outputs). This way we could have 8 channels without the need to mix them, they're summed at the output. That's the old PDP-1 inspired way that had 4 mono channels in the early 1-bit music experiments.
2) Just two output bits, L/R, but with an optional reset counters that will drop it back to 0 after a given number of ticks since writing an 1. Basically a hardware narrow pulse technique. That is, you write 200 in the Lcounter, write 1 to the L channel, and it stays 1 for 200 CPU t-states.
3) Alternative implementation to 2, instead of traditional output bits just write a value to a counter, and it'll set output level for the given amount of time. 255 to keep 1 indefinitely, 0 to force output reset.
4) A buffered beeper. L/R bits, but you can feed them with new bits at any rate, and they'll get played back at a fixed rate. That's probably the most robust system for an emulator-based implementation, as we can set that fixed rate to, say, 44100, matching the actual sample rate, and we can also have a modified Z80 core with all t-states reduced to 1. However, I can't get my head around it yet, how difficult it would be in the actual use.
5) Any other ideas that would move sound generation away from Z80 core. I believe this is less interesting approach, as it leaves not much to explore and exploit. Something like a 3-8 chained PITs, much like PC speaker, but multichannel and with ability to set pulse duration.
A programmable timer, like, NMI or IRQ, can be also set to the emulation output sample rate (that may be configurable), so the software sound synth could be interrupt-driven, given the virtual Z80 have enough time to run it that frequent. But it works more towards Squeeker and Phaser like engines, kinda leaving out the pin pulse ones (depends on the sample rate).
