You are not logged in. Please login or register.
The 1-Bit Forum → Sinclair → Shiru's 1-Bit Music Compilation Vol.2
Nothing special, just thought to share. Got all my Spectrum 1-bit stuff that has been made since 2016 and released as a compilation, in audio format and as a ZX Spectrum 48K program. No new songs here, everything has been released previously, it just got packed into a nice package.
That's a nice package indeed. Such kick-ass tracks all around. And this makes me realize once more what an absolute wiz you are when it comes to echoes. During DiHalt voting phase those are always a dead give-away, haha. Also, I think Geostorm might be my new all-time favourite of your tracks.
Excellent stuff Shiru, downloaded from Bandcamp the second I saw you’d released it.
My favs are Geostorm closely followed by High Orbit
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.
A small behind the scenes post about this release.
Thanks. Yeah some of the newer engines chew through RAM like crazy. I'm still surprised to hear that it was such a tight squeeze. Would you share some more details on how you pulled it off in the end?
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).
you probably write about Shrinkler but have you checked the ZX0? The decompressor is shorter, faster and more efficient than aPL (apultra)
Yes, that was Shrinkler, a few versions in fact. No, haven't tried ZX0, because there is a large test table for all Z80 packers, and ZX0 shows worse results for all test datasets there than apultra.
It is better to check for yourself because it strictly depends on the data. Shrinkler also has a NP (no parity) version which does not need as many buffers. In my tests valmost always ZX0 (ZX5 - mutation that remembers 3 ofsets) is better then APL, but I operate on very similar data (graphics) let's check on the example of music:
freezing point: 94 841 bytes
ZX0: 12 659
APL: 12 351
ZX5: 9 019
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).
APL: 2768
ZX0: 2735
ZX5: 2606
That's nice, 150 bytes here and there would make an extra K. How long does it take to decompress?
https://github.com/einar-saukas/ZX5
---
in the 6502 world it performs very well. on the Z80 it should be good too....
Thanks, I'll consider to use it in the future projects.
From what limited testing I've done, it also looked like apack is the better general purpose compressor, but zx0 seems to have a slight edge over the former when compressing beeper music data. Surprised to see that zx5 performs so much better than zx0 for Freezing Point.
Wow sounded like a massive amount of work to get all the tunes to fit into 48k 
Very impressive work.
For my 'On and Off' .tap I didn't even bother to try and get them to fit. Beeperman and Radio in the Rain are 32kb each !
I just had a multi-load .tap and assumed someone would make a .trd version
The 1-Bit Forum → Sinclair → Shiru's 1-Bit Music Compilation Vol.2
Powered by PunBB, supported by Informer Technologies, Inc.