Search options (Page 1 of 20)

I expected the challenge to be the flexible channel layouts and PWM drums, but in fact yeah, I forgot I already handled such configurations. However, there is a less expected issue, both ulasyn and phaserF use a macro to calculate their filter tables. My assembler is certainly not up to parse that, so I guess, I'll have to offload table generation into the engine script. Anyways, seems to be doable.

Still, it is very impressive. I wouldn't say the sound quality is any bad, we've had worse, and it is certainly on a new level.

This one feels to be tough to make into 1tracker, but anyways, I'll try.

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.

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.

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.

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 msb

Oh, sorry, here's the text dump. You can dump any module like that with File > Export command stream > Export text.

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 2

Sorry, guys, was sick the whole holidays, and skipped the compo altogether. Congrats everyone for keeping it alive!

Promoted the current version to v1.11 with minor changes and fixes, as I have a number of bigger ones in the works.

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.