Moderators: simonsunnyboy, Mug UK, Zorro 2, Moderator Team
Wow, nice set of features and cool non native interface.
It would be excellent if it could support the standard trackers copy/paste/block/transpose keyboard shortcuts (those present in PC FastTracker 2).
Just for the heck of it, I started converting the z80 code line by line, trying to accommodate for small changes but not seeing the big picture yet.
Targhan wrote:Also, do you think the AKY format can have a use on ST, on a game/demo? I hope so. It's must better than YM in term of compression, but it's a bit slower of course, since data has to be decoded.
Targhan wrote:Wow! That's great! HOWEVER: you should have asked me before starting, you should NOT convert the "stabilized" player, because it only means something on an Amstrad CPC (each instruction always takes the same cycles, so it's rather easy for us to have "stable" code. Too bad we don't have timers). But the code is uglier and slower because of this.
Targhan wrote:So you should convert only the "PlayerAky.asm", and that's it. Do not bother with the other players (AKG, Lightweight)! I don't think they are relevant on Atari ST.
Targhan wrote:Don't hesitate if you have any question, I'll glad to help.
Targhan wrote:Also, do you think the AKY format can have a use on ST, on a game/demo? I hope so. It's must better than YM in term of compression, but it's a bit slower of course, since data has to be decoded.
Targhan wrote:Thanks again!
when you say YM format do you mean leonard's STSound YM files, and if yes how do you compress the file, wont the file still be to big for a 8bit machine?
Okay, I understand your concern. But really I wouldn't worry about slower/uglier code as from what I've seen so far the code will definitely require an optimisation pass regardless which source is used. For now the real goal is to get something working really. Then we can look into optimising it.
By the way, what do you mean by "stable" here? That it takes a fixed amount of clock cycles so people can synchronise with the CRT beam easier? This is actually a thing that ST people also do so it's also of interest.
To be honest the thing that matters to me here is that the player and tune format is stabilised and there won't be major changes to it. I assume that's the case?
Can you outline the differences in a bit more detail? Are the other players missing features?
In the source archive I also see an "accurate" player. Does this take a lot more time than the normal player?
Maybe the release of AKY format file would help.
Targhan wrote:My format (AKY) treats the whole music, not as a "dumb" YM list, but as small sequences of notes. Since I created the tracker, it is easy for me to split the sound stream into smaller streams. There is no "packaging" like LZ, only a smart (I hope) organization of data. So the compression ratio is much higher than some compression format we use on CPC (AYM), or MXM (on MSX), plus the player is very fast, and requires no buffer. To give you an example, a complex song of 5 mns, without any repetiting patterns, can be encoded within 16kb.
Code: Select all
ld a,11 ;Next regiser
ld b,d
out (c),a ;f400 + register.
ld b,e
out (c),0 ;f600.
dec b
outi ;f400 + value.
ld b,e
out (c),c ;f680
ex af,af'
out (c),a ;f6c0.
ex af,af'
Code: Select all
move.b #register,$ffff8800.w
move.b #value,$ffff8802.w
Might I suggest here that you add an option to export values as hex as well?
Also, on ST assemblers instead of db and dw it's customary to use dc.b and dc.w, so something else to consider there
the exporter seems to require that the base address of the tune is a hardcoded absolute address, user selectable.
Of course from the above I can think of another issue: the tunes are restricted to "only" 64k. How easy or difficult is it to hit that hard limit would you say? Do you need hours of tune data till this is reached? Or (for example) 10? Would it make sense to consider raising that limit to more than that?
Users browsing this forum: No registered users and 5 guests