I'm certainly up to try to implement the 1tracker version, just waiting until it get settled down with the features.
27 2024-02-01 18:03:45
Re: A virtual 1-bit hardware proposal, 1-BOY (9 replies, posted in Other Platforms)
The cheapest I found locally as a DIY module is $7.7, and it is about the same at AliExpress, from China. Yeah, a bit on the expensive side, but luckily, it is easy to replace with the classic S series (a regular ESP32 with the Xtensa LX core), which is cheaper. The 1 euro is likely was a bulk order price for bare chips, not modules.
Anyways, I got a couple to try it out and see how fast they are for this application. There are two resource heavy things: LCD/TFT/OLED screen update, which is done via SPI (serial), and the VM/emulation core, which is going to be simpler than for a proper emulator, but still, lots of RAM fetches. It will define how fast the virtual Z80/6502 is going to be, and I guess it needs to be at the least a double-triple of the regular Spectrum speed to make the idea feasible, more the better.
28 2024-02-01 04:01:25
Re: A virtual 1-bit hardware proposal, 1-BOY (9 replies, posted in Other Platforms)
Here is an updated draft v03. I picked up some ideas from conversations with friends, so the thing shapes up nicely, into something that can offer not just internal architecture, but some interesting external gimmicks as well. For the user it is dual D-Pad, stereo sound, light effects, and cartridge.
Also, started to consider to use a RISC V powered MCU (ESP32-C3 has RISC V and WiFi in a single package). That would be a nice feature to feature an open core in an open console.
29 2024-02-01 00:53:06
Re: A virtual 1-bit hardware proposal, 1-BOY (9 replies, posted in Other Platforms)
Sure, I'll keep it reasonably powered, not too powerful - at least some challenge will be there.
The thing with VM is that any MCU and screen can be used. Arduboy and most of the crowd is tied to once picked type of MCU (particular revision even!) and screen (also of a specific revision!). It is only possible to change the components by modifying all the games in the wild. VM allows to untie the platform from the hardware. Basically it starts the life as a specification that can then be implemented in many different ways. If one MCU gets obsoleted, the VM itself can just be ported to a newer one, and all software will work - just like we're playing Spectrum games with emulators.
WiFi for uploading games and backing up the stuff is easy on the ESP8266 or ESP32 MCUs, they're made exactly for this purpose. If other MCU is picked, 8266 can just be added as a secondary chip to handle the task. It is also can be done for a particular implementation, and dropped in another.
Now the between-units connectivity, like a multiplay of sorts, is a whole different matter, I'm avoiding to get into it at the moment. I know it is doable with the ESPs as well, but the exchange rate isn't too fast, like 0.1 seconds lag at best.
30 2024-01-31 21:39:06
Re: new engine: ulasyn (9 replies, posted in Sinclair)
Oh my, now that is definitely some forbidden black magic. I can't wrap my head around it at the moment, but it sounds totally unbelievable for the beeper.
31 2024-01-31 21:15:51
Re: A virtual 1-bit hardware proposal, 1-BOY (9 replies, posted in Other Platforms)
To clarify, the point of picking an existing command set is the possibility of hooking up an existing C compiler (or a BASIC compiler, perhaps, like Boriel ZX Basic), which would make it much easier to use for those who aren't into the assembly code programming.
AVR is a good idea, but there are some minor hiccups with it. One is that it is a (modified) Harvard architecture system, with code and data split into separate spaces, and not intended to be self-modified. Another is that while I can easily re-target Z80 or 6502 C compiler to this design, modifying a modern gcc seem to be much more difficult. Another thing with Z80 is that it has the I/O space, but anything else will require to have memory mapped registers, and it makes the architecture less clean. Like, the regs has to have a reserved memory area.
I considered 6502 at first, because it is much easier to emulate, thus VM would be much faster. I believe it is a good pick, but I kinda felt that 1-bit stuff is more related to Z80.
Another crazy idea I had was to actually have a few VM cores to run different binaries within the same specs. Maybe it is actually a good idea, like, just imagine - you can pick Z80 or 6502 or AVR instruction set, and implement the same code for the otherwise same platform in either of the instructions. What a test bed for direct comparisons (sans the reduced T-states). Also enables a wide choice of the existing tool chains.
As for the sound system design, I can actually join a few approaches into the same setup. I drafted the 8x 1-bit system, but I can also just drop in 8 registers to auto reset each channel, it is very easy and will look just as clean.
32 2024-01-31 02:19:54
Re: A virtual 1-bit hardware proposal, 1-BOY (9 replies, posted in Other Platforms)
A preliminary vision of the possible hardware implementation. It may vary, depending on the MCU and the screen types, but it is likely a horizontal layout, and built around an SPI or parallel interface LCD/OLED/TFT screen of reasonable dimensions (not extremely tiny).
On-board Flash memory and WiFi connectivity are likely. A standardized shape/slot/loader for external SPI memory is a must, because all modern DIY devices like this missing any footprint in the history, and it is a cool thing older platforms had, but is optional for use.
The design is aimed to the acrylic laser cutting and PCB routing rather than 3D printing, as it gives it nice clean look and it is accessible enough.
33 2024-01-31 01:27:44
Re: A virtual 1-bit hardware proposal, 1-BOY (9 replies, posted in Other Platforms)
A crude draft of the system specs I envisioned so far:
virtual cpu
z80 with 1-state opcodes
the system will have a cap of X opcodes per frame, depending on how many
ops can be performed on a reasonable MCU for the initial hardware
implementation
memory
whole 64K is RAM, some part of it can be configured as video memory
overlays
everything is loaded as an overlay file, either from internal device
memory or PC file (in PC emulator), or from an external storage
the overlays are stored as a number of *.1bo files, the primary one
is *000.1bo, that is loaded first, and *001.1bo to *255.1bo can be
requested from the code
a file may contain any number of blocks of any size. a block has a
header that is 16-bit length, 16-bit loading address that is followed
by the [length] bytes
last block is length=0 and starting address (if 0, ignored for requested
overlays, otherwise control transferred to the address)
this way overlay can contain only a small piece of memory, like level
data
video
128x64 monochrome, very basic system that allows double buffering, scrolls,
resolution doubling and screen splits
video memory bytes are vertical oriented, 0 at the top
there are 64 line that are represented with 128 sequential bytes in the RAM,
one of bits in each one (e.g. bit 0) contains the pixel state
all 64 lines can be configured to point to any RAM location, and a bit mask
can be set to pick the bits that will set screen pixel if any of the pixels
in the mask are set. bit mask also allows to make varied effects, like,
dynamic vertical resolution decrease
video configuration is done by selecting a line with an out, then outing the
three bytes to their respective ports. the new configuration will only be
applied at the beginning of a new frame, so no mid-frame changes will take
effect (for varied HW implementation compatibility reasons)
one possible configuration is to set each line to a 256 byte boundary,
this gives 256x64 (or taller) buffer
by changing the bit mask it is possible to scroll vertically
by changing the address it is possible to scroll horizontally
in the Z80 code, inc l to go the next pixel horizontally
in the Z80 code, inc h to go the next pixel vertically
alternatively, the lines can be packed tighter, set to a 128 byte boundary,
so inc l is still useful, but add hl,128 is needed to go the next line
i/o
everything is mapped to the ports, no memory mapped registers
00 screen control, write set config (reserved at the moment), read
allows to sync up to the screen update, a 8-bit counter gets incremented
at beginning of a new frame
10 buttons state %10YXUDLR (0 and 1 are main buttons
XY are left/right shoulders)
PAD_R=#01
PAD_L=#02
PAD_D=#04
PAD_U=#08
PAD_X=#10
PAD_Y=#20
PAD_0=#40
PAD_1=#80
20 raster line number, changes get applied at beginning of the next frame,
no multicolor techniques allowed
21 raster line lsb
22 raster line msb
23 raster line bit mask
30 sound output
31 sound output fifo, write set length 1..256 (0) bits, read returns actual
current length of the buffer, to detect if it is the time to feed some more
32 sound output sample rate lsb, in hz, something about 8000..16000, maybe higher
33 sound output sample rate msb
34 sound mixer left
35 sound mixer right
40 timer nmi config
41 timer nmi lsb, freq in hz
(not in t-states to avoid issues if overclocking is applied)
42 timer nmi msb
50 timer irq config
51 timer irq lsb
52 timer irq msb
e0 overlay loading (not banking, takes some time), basically out an overlay
number to request loading
f0 in-device save/load, for game saves
write 1 to request load
write 2 to request save with the parameters below
f1 save slot (a few slots)
f2 save area lsb
f3 save area msb
f4 save length lsb (probably limited to a few K)
f5 save length msb34 2024-01-30 13:32:34
Topic: A virtual 1-bit hardware proposal, 1-BOY (9 replies, posted in Other Platforms)
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).
35 2024-01-22 14:58:59
Re: Quad tone engine (10 replies, posted in Sinclair)
Oh, sorry, here's the text dump. You can dump any module like that with File > Export command stream > Export text.
36 2024-01-22 09:50:26
Re: Quad tone engine (10 replies, posted in Sinclair)
Wow. Sounds reasonable!
In meanwhile, I found one actual FUR module for the QuadTone engine. May come handy for tests.
37 2024-01-19 17:40:02
Re: Quad tone engine (10 replies, posted in Sinclair)
Furnace does feature some kind of debug stream dump, which may be used for conversion purpose, although I'm not really understand what's going on there. For QuadTone it looks like this:
# Furnace Command Stream
[Information]
name:
author:
category:
system: ZX Spectrum (beeper only, QuadTone engine)
[SubSongInformation]
name:
tickRate: 60.000000
[SysDefinition]
[Stream]
>> TICK 0
0: HINT_ARPEGGIO 0 0
0: NOTE_ON 45 2
1: HINT_ARPEGGIO 0 0
1: NOTE_ON 40 2
2: HINT_ARPEGGIO 0 0
2: NOTE_ON 24 2
3: HINT_ARPEGGIO 0 0
3: NOTE_ON 31 2
4: HINT_ARPEGGIO 0 0
4: NOTE_ON 24 2
>> TICK 12
0: NOTE_ON 57 2
1: NOTE_ON 52 2
2: NOTE_ON 24 2
3: NOTE_ON 31 2
>> TICK 24
0: NOTE_ON 43 2
1: NOTE_ON 41 2
2: NOTE_ON 24 2
3: NOTE_ON 31 2
4: NOTE_ON 24 2
>> TICK 36
0: NOTE_ON 55 2
1: NOTE_ON 53 2
2: NOTE_ON 24 2
3: NOTE_ON 31 2
>> TICK 48
0: NOTE_ON 41 2
1: NOTE_ON 43 2
2: NOTE_ON 24 2
3: NOTE_ON 31 2
4: NOTE_ON 24 238 2024-01-17 06:46:11
Re: Quad tone engine (10 replies, posted in Sinclair)
Yep, this one if from Furnace. The description says: 'another ZX Spectrum beeper system with full PWM pulses and 3-level volume per channel. It also has a pitchable overlay sample channel'.
A problem with Furnace, though, is that is has support for a lot of chips and platforms that is implemented inside the tracker only, i.e. you can't export some data/code and play it on the real hardware. I don't know about this engine, how exactly it has been designed (my bet it is does not exist as Z80 code and is not really within the actual possibilities), but for example, it has a PET support with the notes lower than 245 Hz, but without a proper exporter. So my guess is they're assuming it is possible, but at the moment it is a mis-named virtual target. Either engine has WAV export only.
39 2024-01-09 10:38:12
Re: upcoming beeper compos (135 replies, posted in Sinclair)
Sorry, guys, was sick the whole holidays, and skipped the compo altogether. Congrats everyone for keeping it alive!
40 2023-11-19 11:05:12
Re: EBT - ESPboy tracker (16 replies, posted in Other Platforms)
v1.2 is up. It got a single step Undo, a file manager, and instrument pairing. That is, you can pair any instrument with any other, getting modulation effects. It increases polyphony to 8 voices, because why not - we don't often have a chance to do it in our 8-bit implementations.
41 2023-11-12 23:37:27
Re: EBT - ESPboy tracker (16 replies, posted in Other Platforms)
Promoted the current version to v1.11 with minor changes and fixes, as I have a number of bigger ones in the works.
42 2023-11-10 23:46:52
Re: EBT - ESPboy tracker (16 replies, posted in Other Platforms)
Wow, sounds sick!
Not too sure about the number keys, maybe a specific scenario to reproduce the issue? Does it happens all around, or at a particular screen such as order or pattern editor?
43 2023-11-10 21:07:23
Re: EBT - ESPboy tracker (16 replies, posted in Other Platforms)
You need to have /fonts/ and /data/ in the same directory with the executable, if they're not found, it won't be able to load fonts and will close. Missing ebt.cfg is just a warning, it will report it and continue to work. When you'll change something in the CONF for first time, it'll create the config file and stop giving this warning.
44 2023-11-09 23:10:36
Re: EBT - ESPboy tracker (16 replies, posted in Other Platforms)
I haven't tried it with Linux just yet, but it should be trivial, as it does not use any third-party components besides SDL2. So this untested makefile may work. Please try it if it is not too much hassle. I'll get to it eventually, but I don't have an easy to access Linux environment at the moment.
I also have a report it works just fine with WINE.
Edit: Actually, attempted to make it work. It compiles and starts, although it crashes on me right away, but so does 1tracker in the same install (lubuntu in VirtualBox). I uploaded the WIP in place of the release, you may try it out.
Edit: fixed it up some more, now it fully works under Linux.
45 2023-11-08 22:13:04
Re: EBT - ESPboy tracker (16 replies, posted in Other Platforms)
EBT has been updated to v1.1. It is easier to use on a PC now, as it uses a different control layout, and supports PC keyboard. A custom made keyboard technically can be also attached to the device, and it is possible to support it, which opens up interesting possibilities too.
Changes are:
- Play option removed from SONG screen
- Name and author fields are added to the song file, can be set from the SONG screen
- Squeeze function added to optimize song data
- Some waveforms tuned up to match the original wtbeep, to allow easy conversion between two
- Stereo panning reworked a bit, allowing 9 positions left-to-right instead of 3
- Default panning settings are added
- An option to swap the LFT/RGT buttons
- A crash course section added into the manual
- Two cursor colors swapped to make it more visible with blinking off
- Play/Stop info line is only shown while the RGT button is held down
- 32 extra waveforms added, including various noise and modulation effects
- Sound synthesizer and music player separated into two independent entities
- A standalone player code that stores data in the program memory
Hardware-specific:
- LovyanGFX display library supported
- 2.0 inch TFT display support (ST7789V) for a custom built EBTboy
SDL build specific:
- Irrelevant config options such as sound output device are not displayed
- 128x128 and 240x340 modes support, with 8x8 and 15x16 fonts
- Main control keys are remapped
- Direct keyboard support added, for entering numbers, letters, and better navigation
46 2023-11-01 22:50:03
Re: EBT - ESPboy tracker (16 replies, posted in Other Platforms)
While a new version in the works, a small demo of what it is capable of (at least). I tuned up the sound synthesis code to match up the wtbeep's waveforms closely, so it was easy to port Freezing Point.
47 2023-10-24 04:53:21
Re: EBT - ESPboy tracker (16 replies, posted in Other Platforms)
Sure, I'm working on getting some demos made, as well as improving it even further. Don't have much time myself, but hopefully will do some music using it eventually.
48 2023-10-21 00:01:49
Topic: EBT - ESPboy tracker (16 replies, posted in Other Platforms)
A new project of mine. A LSDJ-inspired tracker for a portable DIY device called ESPboy. The device is based on a cheap IoT microcontroller ESP8266, which is quite powerful (up to 160 MIPS), yet limited in the resources compared to many other similar devices. It uses a 128x128 color TFT screen, so the interface s even more crammed than the LSDJ's.
The software sound engine is vaguely connected to our 1-bit stuff: it is based on the wtbeep engine. It takes the best of it, and improves the sound quality using the device's power. It features four channels with a clean sound. It also features an actual volume and stereo left/center/right controls, so it is not really 1-bit anymore, but there are 4 volume levels only, and no volume envelopes, so it still sounds similar to the 1-bit stuff.
The tracker engine features single-channel patterns of variable lengths (you can mix up different lengths in an order position), and MOD-like effects with up to two effects per note.
The package includes the ESPboy binary, a Windows SDL build (should be easily portable to Linux and such, but not ready-to-use yet), the source code of course, and a detailed PDF instructions. Released under WTFPL.
No demo songs yet.
Also, there is github, but it will be lagging behind I bit, I think.
49 2023-10-02 02:11:14
Re: Commodore PET music (5 replies, posted in General Discussion)
Furnace tracker it is. It supports a gazillion of platforms. Not sure how did they get the low notes, tho, can't find a low level export there. Perhaps it is in-tracker only at the moment.
50 2023-09-25 14:07:29
Re: Loading music sound (3 replies, posted in Sinclair)
I think (not really sure) I've seen an editor that has been used to make this demo, but I can't recall where it potentially could've get it. Perhaps it was on a forum back in the day.
Edit: oh yeah, it is actually mentioned in the comments. The link is dead, but archive.org saves the day: https://zx-pk.ru/threads/5577-redaktor- … uzyki.html