Side note, SjAsmPlus actually has support for 8080 with Z80 syntax, it basically limits valid supported opcodes to the 8080 subset. Activated with --i8080 flag. As there isn't many (if any) good modern 8080 cross assemblers, it comes very handy.
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.
Wow, that's unexpected. Some of my engines guilty with the same thing, though. Squat, for one. Easy to fix, though, but it'll reduce the internal sample rate a bit.
Re: Any reason for using both 3rd and 4th bits of #fe port? (3 replies, posted in Sinclair)
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.
A guy reported a very weird issue with this engine. It is completely messed up on the ZX Spectrum +3. Not too sure what causes it, but the result looks like it runs in the slow memory. Booting in 48K mode does not help, I suppose it should have a fast RAM page at 8000 in the default configuration anyways?
There is export for this SquatM engine, but it only exports an assembly source with DBs. I sure would like to eventually get to a proper support, with a built-in 6502 assembler and XEX export.
As for porting other engines, we'll see. I think it is a good to bring some more of the finest ZX developments to the Atari platform.
No, I barely managed to get this basic on/off stuff to work properly in time for the compo, so I didn't investigate it further than that. I guess there can be more, and in general Atari XL/XE platform is worthy enough to pay more attention in regards of the 1-bit stuff.
Yeah, better to keep 1tracker up to date to use newer engines. Not that it changes terribly, but it does get updates and fixes time to time (now as I'm using it by myself more often).
Here it is, the source code for CA65 assembler, my song from Silly Venture 2K20+1 in 1tracker format, and SquatM engine for 1tracker that has an option to export CA65 compatible data (but Z80 version plays in the tracker).
More unnecessary details at Patreon, like (now) usual. Don't be afraid to visit it, it is not behind a paywall, I'm just running a public blog there.
Sent my GTIA entry to SV, Grey responded it is the only one so far. So if anyone up to it, would be nice to have more!
Spoiler, it is a Squat tune, so there is a 6502 port now, and you can have it. Looking at you, utz!
Can also port some other engine if someone got a tune for an engine that hasn't been ported yet, but there is too little time, so hurry up.
Pretty good one. It sounds kinda oldschool, not filled with fast movements or tiny details that is typical for modern compositions, so it sets up the proper classic mood, although with much improved melodic content and sound quality of (not so) modern engine(s).
Yes, it has been done a long while ago, can't even remember how long. A decade or longer. The thing is that it is not an improved Z80 engine, it is just a PC based rendition that uses original music data and recreates original synthesis algorithms. MATLAB powered even, if I remember correctly.
Re: Xorex: Requiem for a Space Bug - an album by ec2151 (3 replies, posted in Other Platforms)
Yeah, sounds much like it.
Topic: Xorex: Requiem for a Space Bug - an album by ec2151 (3 replies, posted in Other Platforms)
A new 1-bit music album has been released digitally a couple weeks back (took me that long to post here). Some quite nice authentic sounding stuff from an author I've never heard of before. Made with Beepola, with some extra post-processing at places, but without going too far from the pure 1-bit aesthetics.
I did implement the viznut waveforms for the VIC-20. It was full of nasty surprises for sure, given the difficulty of making well timed 6502 code (added cycles here and there depending on code/vars locations), and really lacking debug tools. Even worse, VICE has some weird audio filtering going on, and MAME does not support expanded RAM for VIC (5K default model only), so I was not able to hear the sound properly, and my test code didn't fit to run in MAME.
It worked in the end, however, it wasn't much suitable for music. The thing is that these waveforms always contains 8 zeroes and 8 ones, just arranged in different ways. So it can't do the usual 50-25-12-7 duty cycle, or arbitrary bit patterns of PET, it just adds high pitched harmonics into square wave. So a special arrangement for music is a must, that would mostly rely of square wave and emphasize some parts using waveforms.
Here is the key part of the code (waveform_table there is to attempt to arrange waveforms in order from regular bold square to the thinest one):
set_pitch_and_wave: pha tya bne :+ sta <PV_WAVE_PREV,x lda #$7e sta VIC20_LOW,x pla rts : asl a tay lda waveform_table,y iny cmp PV_WAVE_PREV,x beq @skip_wave sta PV_WAVE_PREV,x sta PV_WAVE_PTN lda #$7e sta VIC20_LOW,x lda waveform_table,y ldy #100/5 ;delay t-states/5 : dey bne :- tay @loop: lda <PV_WAVE_PTN ;3 and #$80 ;2 ora wavecnt_table,x ;4+ sta VIC20_LOW,x ;4+ asl <PV_WAVE_PTN ;5 lda <PV_WAVE_PTN ;3 nop ;2 nop ;2 nop ;2 dey ;2 bne @loop ;2/3=32t @skip_wave: pla tay lda (PV_NOTE_TABLE),y sta VIC20_LOW,x rts wavecnt_table: .byte $7d,$7b,$79 waveform_table: .byte %11000000,3 ;00 .byte %10010000,6 ;14 .byte %10100000,5 ;09 .byte %10100000,4 ;12 .byte %10110000,6 ;11 .byte %10110000,5 ;07 .byte %10000000,2 ;01 .byte %10000000,3 ;04 .byte %11010000,5 ;08 .byte %10101000,6 ;13 .byte %10010000,5 ;06 .byte %11100000,4 ;03 .byte %10110000,4 ;02 .byte %11000000,5 ;10 .byte %10000000,4 ;05 .byte %00000000,0 ;15
In fact, I think I'll release the whole sound code sometime later. Released album code contains most of it anyways, it only missing VIC-20, C64 and NES dependent parts.
I did finish code for PET, VIC, and C64, but integration failed on the last mile - something conflicted or glitched, and my code didn't work in PET and C64 versions inside actual game by reasons unknown. As the integration was done on binary level (not source level), and I don't have a real PET or C64, and available debuggers leave a lot to be desired, and the game was already released anyways (first copies were done without sound), we're ended up with only using VIC-20 part for sound effects. David opted to do his own sound code and even a native tracker for PET instead.
As for music, initially it was supposed that I'll compose it all, to the strengths of my sound code, but as its development was lagging behind a lot, it was decided that Noelle will do SID music in goattracker, and I'll have to convert it for PET/VIC, which didn't work well, of course. So none of my music was used, and that's why I decided to release it as a standalone album.
I covered up the story in my Patreon blog, there is a few posts, you can follow it up by the 'pet robots' tag. Planning to do two more, one on the music editing process (1tracker this time) and data format (pretty compact, the songs 1000-1500 bytes large each), and another one on making of the album itself.
Long story short, I made a 8-song album for Commodore PET. It works kinda like PC Speaker music, just a single channel, but with wave shaping capabilities (different bit patterns) instead of regular square wave. No multichannel synthesis there, although it is sure possible on this beast.
Those were mostly produced by the Battle of the Bits gang, when beeper stuff was a novelty to them. I guess they're tired of it, and we're still not provided them with good enough tools to spark interest for newer engines. Like, both 1tracker or bintracker certainly isn't as easy to use as Beepola, and more recent engines don't have an XM converter either.
It is just matter of personal taste. There are dozens of popular trackers in the history that didn't follow the line. There are sequencers in the history that didn't display anything at all, yet was very handy to create music.
It is impossible to do with this design, anyways.
Thanks for report. Yeah, just noticed there is still issues with that, even though it does not do segfault to me. Damnit. Alright, more work to do!
Robin of the Wood game is from 1985, Follin started to do his stuff including Vectron the same year, so it is difficult to say, but it is sure one of the earliest. Also features kinda unusual channel mixing with a single out per loop, take a look (guess that's where ZX-3/10 and Squeeker roots are?).
v0.31 is out. Many fixes in the front-end and many engines. Minimal examples and docs for each and every engine. The classic two-channel engine from Robin Hood is added, in all of its original glory.
hellraver is Alexey Krivtsov of ZX BITLES group, they're actually have a website that was name of one of the entires: http://zxbitles.com/. As I understand, the guys are just recently come the the scene, and is not known by prior works, besides their 2020 game.
My congratulations, utz, and Tufty, on stealing my imminent victory once again! Took me some time to figure out who is behind these amazing tracks, it wasn't too obvious this time, even though I did have clues that engines likely were used and your preferences.
As I understand, the amount of bits involved into an LFSR directly affects to the length of evolutions of the sound in time, while bits change density per second (like, how fast LFSR is counting) affects to the richness of the harmonic content. So here we have 6144*8 bits large LFSR, even though these bits may be used not the most efficient way. Overall it is just like a regular LFSR-based noise generator like in all old sound chips, but with tricky looped sub-periods (noise harmonics?) in it.
I'm not a BK user, I think I've never seen one working, so I have about as much clues as you do. Even knowing Russian does not help much there, it all looks extremely cryptic.
Don't put your expectations high, this was only supported by hobbyists who just did their first steps in software development. What you can expect from a computer with a keyboard that looks like it came straight up from a cartoon? In fact I think it is part of the puzzle, it had a ton of cryptic named keys.