Search options (Page 7 of 20)

Well, Freezing Point data is certainly not 94K large. You're packing the source text file for some reason.

The binary data is 16714 bytes large, 2768 bytes after packing with the apultra. You can try ZX5 on this data (attached).

I used apultra to pack everything, including players. Players and music data were packed separately, so players get reused. I also tested some even better packers, but they would take like half a minute to decompress in the worst case, which is unacceptable.

Even with the best packing, I needed a large buffer for the largest unpacked song, it was nearly 19K. At this point it couldn't fit at all.

I had to:

- Place my code as low as #5b00, disabling the BASIC interrupt handler completely
- Overwrite the screen drawing code with the song buffer
- Decrease the two largest songs

In order to decrease the largest songs size, which happened to be Freezing Point and Geostorm, I first made a function that optimizes out the empty rows by reducing the speed of a row before (recursively, as long as row speeds allows). This optimization can be applied to any song in 1tracker now. This helped a bit, but still wasn't enough. So I also had to modify wtbeep and SquatM formats.

In the wtbeep, I now omit the 0 byte for rows without a drum (it is now triggered by the bit 6 of the control word). Saves a bit of room.

In the SquatM, I reworked the way how the dividers stored. Instead of the normal LSB/MSB order that is easy to read with POP I stored them in the MSB/LSB order, and used bit 7 of the MSB as the note rest flag. The LSB is omited for note rests. This of course made the song data parser very suboptimal, but the Sqeeker-like design does not suffer from row transition noise much, and I gained the remaining bits of the RAM.

The largest songs remained the same, but I saved a couple K this way. Freezing point is 16714 now, and Geostorm is 15809 (2768 and 2500 packed).

Thanks, guys!

Interestingly, both Geostorm and High Orbit started as NES tracks, they were half finished sketches (half length of the finished versions) written for a game that never happened, lying around since 2017 I think. I thought they won't translate into 1-bit well, because the NES of course used volumes, duty cycle, slow attacks, samples, and so on. But it turned out to be the case when moving a song sketch that is just stalled in one format into another format made it shine.

Sure, you can upload it. WTFPL/CC0 it is.

v0.32 is out, with many improvements. Relatively major changes in the front-end code here and there. wtbeep and Squat family support got updates. Most importantly, Velvet engine has been added.

The full results are up, here are the beeper ones:

ZX Spectrum Beeper Music

1.   7.51   Freezing Point by Shiru
2.   7.11   Geostorm by Shiru
3.   7.03   March Of The BioMech by Tufty ^ 1bit Forum
4.   5.97   drum'n'halt by utz ^ irrlicht project
5.   5.76   Rekcart by AER
6.   5.61   babka_dance by AER

I was thinking to get it working on the 2600, too, using a trick to get a reasonably well tuned notes, but left it out for possible future updates, otherwise it could stay in the unreleased limbo for even longer.

I think it is just fine, it has everything that is needed and the schematics can contain just a battery, chip, and piezo speaker. It has just a half of the ATtiny10 power, but for much lower price. The only problem is that 150 has OTP memory, i.e. it is can be programmed only once. There is 154 that features Flash memory instead, the price is tad higher.

I'm still trying to figure out the actual LFSR implementation to get proper pitches.

The arrangement of the chunks in the song ROM is likely visually linear - basically first 64 bits of the data is bit 0 of the whole song, then next 64 bits are bit 1, and so on (there is binary decoder to the left from the mask ROM field, and its control lines seem to be parallel). So it should look more like:

1000001001111101000000100111110100000100111110111100010001000001
1101010110100100110101011010011010101011010011000011101110111110
1000000110000010100000011000001000000011000001000011010011011110
0111110011010000111111001101001011111001101001011010100101101010
1111111110111111011111111011111111111111011111101111111111110110
1111111111110111111111111111011111111111111011110111011101111111

This way it really looks like the duration is encoded in the two bottom rows (two top bits).

A note on this issue regarding to 1tracker. Most engines will survive a quick and dirty fix. You can open a *.1te file with a text editor, find there 'out (#fe),a' line, and add a 'and 16' line just before it. It will work in most cases, although a couple of engines may break. The downside of this fix will be a bit reduced pitch and play speed.

Some engines can have pitch issue corrected, although not all of them - find a definition of 'cpuTime', and subtract 7 from the value. If there was a few 'out (#fe),a' lines, add 'and 16' to each of them, and subtract 7 for each one as well.

This is a temporary solution, as it is uncertain if/when we will be fixing the issue. At least I'll add a note for each engine that is currently not compatible with +3, I guess.

I recall some years back there was a guy who was talking a lot about this possibility of getting four output levels on the classic 48K beeper, and proposed to use it somehow in a beeper engine. However, as they're pretty close to each other on the extreme ends, no one figured out any useful application for such a feature.

Actually, even if there was a true 2-bit DAC with proper evenly spread levels, I'm not too sure what advantage it could have over 1-bit - a two-channel engine with 'lazy' mixing perhaps, but that wouldn't give a major speed advantage, or extra opportunities for more unusual synthesis techniques. Maybe I'm wrong.

Curious little quirk, nevertheless.