rensoup

nice! Level up again 😀

so what's the original like ?

Alright I'll take a look... It should be simple enough. And if it enables you or anybody else to push the HW a little more, it seems worth it 👍 Remember though, your tunes wouldn't be compatible with -any- RMT version if you go that path 😎 (but I agree it's still worth a shot, if anything, additional tables seem to be a very popular request) it's pretty simple which makes it fast to decompress. Basically there is a buffer which remembers the last 256 values (for LZSS16) sent to each Pokey channel. so there are 9 buffers * 256 bytes.. 256 values = 5 sec at 50hz (4 sec at 60hz). In other words, the decompressor remembers the last 5 sec played. So compression benefits occur when the newly played sequences are still present in the 5 sec buffers. If there is, for instance, a 50 bytes sequence that is identical to one that was played less than 5 secs ago, the compressor just writes the offset in the buffer and the byte counter instead of writing the same 50 values. So no, there aren't any tricks to reduce the size in its current implementation. Yeah, it's one feature that NRV mentioned, pattern based compression instead of full tune compression. It's something that we all thought about and it's a big unknown. It's an obvious area to research but it isn't high on the priority list unless LZSS becomes more popular... right now it's good enough 🙂 There are 2 caveats though: 1. As mentioned above, the LZSS decoder remembers the last 5 secs but every time you start a new tune, the 5sec buffer is empty so the beginning of a tune will in theory not compress as nicely. It's ok if you have 2 song parts (intro+loop) but if you have 50 patterns and as many song parts ? 2.My optimized player takes a few more scanlines when a new song part starts (you'll notice it if you enable raster time), which is ok if it occurs every minute or so... but again with patterns, it could occur every couple of seconds and that means you can pretty much consider you've lost that CPU time permanently). Dmsc wrote his own version of the optimized player which is pretty much the same speed but uses a bit more of the precious zero page memory. But on the other it may be faster to start a new song. A new tracker would be a better investment 😀 Well I guess it's possible to modify the player to override the volume commands but that would bloat it and then it would just remain silent ? It's also possible to to create a 3rd song part which would only last as long as the fade out time and play it at the right time, but it just seems useless 😏

But that means you wouldn't be able to listen to your tunes in RMT right? you'd have to convert them to LZSS every time 🤨 I imagine you'd want a note table per instrument ? It may be possible to have a file that contains all the notes (always 61 entries or something, right ? ) and just point to it at conversion time. If an instrument is skipped, it uses the default table Something like this: (anything after ';' is a comment) It's so clunky... but doable. Impressive and disappointing at the same time 😀 Crazy quality for 50hz, file size is about the same as .RMT (but perhap .RMT could be trimmed down ?) but then I'm a little disappointed that 100hz didn't make that much of a difference!

Yeah the loading sound is turned off, I have no idea how I did that though and I'd like to undo it! shadow register or something ? does not apply here! I want to finish this more than anybody here I think but I'm working with temp presentation assets, so while waiting I'm working on peripheral stuff which needs to be done at some point anyway...

I want to match the original A2 specs and I want the authentic experience although I don't have a real machine anymore, I'm hoping I'll get to witness it some day... So ATR for that. CAR makes sense for high speed devices for those who own one and it also helps for debugging. Hopefully xxl will release the tool to create CARs from ATRs that use xbios as that might help convince developers to choose to use xbios in the first place.

Although I've converted the RMT player, I'm not 100% sure how that table stuff works 😮 So do you select a Pokey setting, then play all possible frequencies with Pokey explorer and figure out which ones correspond to a note? Then the table is just a compilation of all the valid notes ? With RMT2LZSS it's pretty easy to add tables and patches and even have them all available together although obviously there's no interface (tracker) to select them so it's kind of useless.

But I did some tests and that wasn't conclusive... the thing is I can't even hear the problem, so unless I can get a simple and clear example, it's hard to investigate.

But that's played with pokey.dll, not Altirra so the problem could also be with the dll, does it occur if you produce a xex from RMT and play it Altirra ?

Sure I'd like to keep it too, I guess I just need to set the 4th channel's volume or something like that ? There will be ATR and CAR...

While that's good news, I still don't see any significant difference between the way LZSS and RMT send the data to Pokey... I added an option to remove the Pokey data simplification but @VinsCool said it wasn't the problem

Yes xxl posted a video which proves it can be done but he didn't give any detail how this is achieved. I'd already inquired about this here: xxl's answer: I still need to try that... I have no idea what US is (ultraspeed?) and I don't know what devices support it. Supporting all devices requires switching the OS on and off (which requires more memory) and after rereading that thread it just seems like a major pain in the butt... if anyone disagrees, please provide the full code to do it (saving and restoring any memory that needs to as well chips state).

I'm not sure if higher than 1x SIO speed is always available with xbios... I certainly don't know how to enable it but again it's not that important since it should be easy to make a cart version from the disk one.

A few people have asked for a ROM based 64KB RAM version... (Like the C64 version basically) That's a tad more tricky. Or perhaps a lot more... I don't really know. So if I ever attempted that, it would be after the final disk release. Once you go that road though pretty much everything has to be left uncompressed in ROM, which also means it is possible to start cheating a little by preshifting/premirroring sprites for instance. The main issue is that I sprinkled self modifying code all over the place (plus the original code has some too) so it's really about shuffling around all the code that does and doesn't require self modifying. The best tool to help me with that would be my virtual PoP which I neglected when the A8 port started working. So I'd have to get that working again first... So I don't really have a final answer on that.

I don't know under what conditions xbios supports higher speeds but I don't really know anything about all the devices mentioned in the last few pages. (I just remember Happy and its blazing loading speed from back in the day!) But yeah it's a bit of a moot point since it's easy to stream from a cart (not sure why xxl didn't do it before!)

Regarding disk support: The game is disk based because I wanted the port to match the original' specs: 128KB RAM + floppies as well as push the A8 (and I didn't know carts were such a big thing nowadays 🙂) A cart version blurs the line and people unfamiliar with the tech might say that the A8 version is better because it uses ROM. A ROM version would actually free up some RAM because xbios uses 1024 bytes + 256 bytes for the disk buffer. The way xxl did it, I suppose, was to replace xbios OpenFile/ReadFileData functions with the equivalent functions that read data from ROM instead of disk, based on a ROM directory instead of a disk one. I wouldn't be surprised if that saved 1KB overall. I may release such a version because it's not a lot of work but it may not fit in a 128KB ROM. I recall that once you switch to 512KB/ 1MB ROMS, the bank switching scheme is non standard and not all are supported by every device. In theory though, because the data is streamed from ROM, it should be trivial to support a bunch of them... So my question: which 512KB/1MB banking schemes are worth supporting ?

I initially thought that xbios loaded slower than stock 1050 speed... but that's not the case. It would be nice if it supported Happy speed if the user has one... not sure if it does ?

My bad, Xbios speed is fine... Did a quick compare with a bunch of ATRs and all speed patches disabled in Altirra and it's the same (I even attempted a quick optimization test of the Xbios load function and got 0 benefit). 😅 Seems like I had forgotten how slow the 1050 was!

Don't worry, there will be a nice loading icon too! (but a fix for the loading speed would be even better 😏)

So what's the difference between this version and the previous cart version you did ? Why no autoboot ? Btw I now compress everything with APL (previously it was just the main executable)... my target was a 127KB disk but since it couldn't fit, I switched to 180KB one... some files are smaller, some bigger but I'm not sure I'm losing that much space compared to zopfli. Anyway, it'll be much faster to decrunch and the decompressor is 200 bytes smaller. I'm using Elmer's version which takes a few bytes less (but uses ZP) compared to yours.

It's all lazer and synth sounds and then... it's just a a few seconds over 3 mins of goodness😀

Awesome! Hopefully it'll get the views & likes it deserves!! (c'mon people, like that post above!) What's reassuring is that the .rmt takes 14KB (probably some unused stuff) but that means a 50hz LZSS might still be in the same ball park...

Your version sounds pretty cool even though it's nothing like the original... Nobody was ever sure if it was a sample! https://codetapper.com/amiga/interviews/martin-pedersen/

Ok but it's rough... I much prefered the hybris one, although I don't know why you insist on having those super loud percussions (I actually added the volume control option in RMT2LZSS so that I could lower it) Now that I'd like to hear 😮

I'll repeat myself for each new release: AWESOME WORK! Now allow me to complain a little 😀 There's just one sound that doesn't fit, I've recorded it because my damn player doesn't have a clock (proportional fonts are costly)! battlesound.mp3 Of course I'll still enjoy it very much even if nothing can be done about it!