Search options (Page 15 of 21)

I thought we had one, but I wasn't able to locate, and this one has my post with mention of Galaxy Force and few other interesting old engines. Better to split it to a separate thread anyways.

I was totally sure 3 was Wham. It sounds exactly like Wham, pure square, the carrier hiss, the echo trick at the beginning. Then the drums kick in, typical LS ones. Maybe it is the third version of his engine? Going to investigate.

Edit: more likely that's the first LS engine, or maybe an engine that inspired Lyndon to make his own (music credited for Barry Leitch). Main sound loop looks very similar to Wham, but with some changes in registers usage.

Great stuff, more the merrier, especially with new ideas on tracker internal architectures and UI design.

One bug report so far - when I closed program, Windows error occured, 'the program was stopped, close it?' (not sure how it is in english, I'm on localized Windows).

Default settings for drum is 20 (slide) and 2 (pitch).

On a side note, yeah, there is a little mess with lack of zero value in 1tracker. I didn't thought it could be important when I started the project, now it would be quite difficult to add it, all engine scripts would need a fix to support that. But I'll get to it eventually, as it makes things more obvious (0 to disable something).

Vortex Tracker II actually needs an alternative (there is few already, but not very popular). The reason is that VT2 basically a Pro Tracker 3 (Zx Spectrum's) clone, limited by its original, slightly expanded format. While it is really good for music in general, there were even better formats on ZX (ASC Sound Master, for one), and there is also specific requirements for music in games that needs it to be as compact as possible, but PT3 format isn't much effective in this regard (a song takes 5K easily). There is no need to replace VTII, but providing alternative to handle specific cases would be nice.

Cursor following song while it is playing would be pretty convinient, but unfortunately it is pretty tricky (not impossible) to implement it due to the multi-engine concept itself. Tracker would need to somehow get actual playing position, but that needs to be reported by each engine, and not all engines actually use rows and speed concept internally (some just store delays between events). Another idea is to just move cursor approximately, depending on play time, but this needs very precise speed-to-time translation, which is again very tricky, because beeper engines tend to have major tempo fluctuations. So yes, at the time being we have to live without it.

Proteus that costs like $1000 is certainly an overkill for this.

For this particular application I didn't need to know exact cycle count or do assembly optimization. If I was to write AVR assembly code by hand, I sure would know how many cycles it takes - it is common practice to memorize opcode cycles (super easy on AVR), and count them in time critical parts when writing for 8/16 bit systems in assembler.

What I needed was just to see compiler generated code, to check if particular changes in C code makes resulting code longer or shorter, which is totally enough to estimate efficiency of edits - another common practice when writing for 8/16 bit systems in C. It is super simple task, I don't see why it should be overcomplicated like that with all that porting to other environments, using simulators, debuggers, and stuff like that. All it really takes is just a quick glance at the compiler output, which is normally fully exposed to the user. It is just an Arduino IDE's quirk that it hides the intermediate assembly.

In general we can have Atari 8-bit and C64 stuff in 1tracker, as Game Music Emu supports both SAP and SID. For better convinience we'd need to make a 6502 assembler in AngelScript, to be able to use source assembly code instead of precompiled binaries, but at first it can be done with just binary (used to be like that before adding Z80Ass).

In particular for this synth, yes, first step would be to reverse it into a compilable 6502 source and data format description. I'm also not sure, maybe it would be easier to just make a new one from scratch, unless it has some unique hard-to-replicate features.

We can have fun and do an AY-3-8910 alternative, too. People were asking if it possible to do something like that for years.

The list slowly getting longer. Meanwhile, I had thoughts on the matter (not looking to the code, though), and here is what I think so far.

For oldest PCs that runs pure DOS, like XT/AT/386 maybe, the usual timed code approach may be viable, with a delay in the main loop that automatically gets adjusted at startup by measuring actual CPU speed. What is possible to do is limited by the speed of the slowest targeted system with shortest possible delay. So basically a little bit less than a 4.7 MHz 8088 can do, which is the same ballpark as ZX Spectrum. Engine types would be not limited in this case, all approaches should work. Music playing would stop everything else.

However, considering how vastly different PCs and their speeds are, plus the possiblity to run something in background, and that every PC has 8253 PIT to generate interrupts, more universal apporach would be to utilize the interrupts. Now we can have quite good sound loop sample rate (when it runs on a PC that is fast enough), but sound generation methods gets limited. We can either use one-change per loop engines, such as Squeaker or Octode, or PWM like with one pulse at a time (basically the PCM playing trick, just without PCM).

One issue with developing this field is that DosBox isn't terribly accurate in regards of timings and PC Speaker emulation. Considering that Pinball Fantasy sounds reasonable while many of the games listed above is not, I think that the second approach is more accessible at the moment - unless you want to work strictly with old hardware and old tools.

Good. Updated the download with halved output gain version, just in case.

Radio-86RK should be even worse. It controls the speaker with DI and EI commands, and has DMA bursts constantly running in background to refresh screen and memory (so tape routines only works while display is disabled).

I guess Apple II's inability to set speaker state directly renders Phaser-like engines undoable, but on the other hand Apple II coders often use PWM techniques to get like ~8 'volume' levels, in Fuzz Click fashion.

6502 assembly is actually super easy, the trick is to switch the thinking patterns after x86/8080/Z80, i.e. from register-oriented to memory-oriented programming.