mrk

@phaeron, @ilmenit I was playing a bit recently with remote debugging of 6502 with `lldb`(I have little draft PR for llvm-mos). I created very simple 6502 simulator https://github.com/mrk-its/sim6502 (compatible with `mos-sim` but with remote gdb support). Full source-level debugging is working (source / assembly listing, RW access to memory / registers / variables): This way emulator needs to expose only memory / registers via gdb remote protocol, ELF / DWARF parsing is done by lldb client. In my simulator I'm using rust gdbstub library, but there are similar C libraries too, like: https://github.com/mborgerson/gdbstub

Ha, interesting, never noticed that. What browser / OS?

2-tone support and reset via SKCTL is still missing, I'll try to add it as needed I'm very glad to hear that, thanks again for help, tests and first contribution

Merged!

Sure. But please include only this Poly5 / Poly9 change in this PR - is always better to create few simpler PRs instead of single big one. Or I can simply cherry-pick your commit if everything looks sounds good

Fixed (I hope I didn't break other things this time) Debugging it was quite fun. I started with creating rmt instrument with square, 50%-fill envelope and 2-element table changing in sync with envelope. This way I was able to instantly hear the difference between web-rmt and rmt And I think this is best way to simplify future debugging - let's create very simple rmt files clearly showing difference (unfortunately I'm tone deaf so I can easily miss difference in real tunes ) table_env_desync.rmt table_env_sync.rmt

Ha, it is super helpful, thanks! I see you are starting mastering this JS thing, hehe I was really frustrated by these Poly4 and Poly5 generators (I copied / derived these formulas from Altirra Hardware Reference Manual, but they didn't sound good and I ended with copying them from Atari800 I think). Can you create PR for it? Poly9 / Poly17 looks the same after your changes (I think, taking a look again) BTW what time zone are you in? Cannot determine looking on posts timestamps :]

First I'm going to mimic original RMT as well as possible (with all his bugs / weird vibrations) - to be able to play all these rmt tunes created by original RMT as close as possible (I was even thinking about comparing sapr streams, but probably your eyes ears guys will be enough This way we can also find bugs in Web Pokey itself. If it is done I'm open for implementing all these improvements / patches you made for RMT or extending this format in any direction.

Your workaround will be definitely helpful in bughunting, thanks! And I'm really glad you like this toy :]

Heh, thanks, It is possible I broke something recently, will take a look.

Not sure if I understand what 'everything' above means - could you point me some rmt (for standard, not patched player) that sounds wrong after this commit (comparing to original, not patched rmt 1.28)? Maybe something included in 1.28 example songs? I can investigate it.

Hmm, the bug is still there? I was sure I fixed it recently here: https://github.com/mrk-its/web-rmt/commit/98ecde40983615abf832702cf0a12013d705b612

Something like: diff --git a/rmt.js b/rmt.js index 450e396..8641736 100644 --- a/rmt.js +++ b/rmt.js @@ -626,6 +626,8 @@ export class RMTPlayer { this.channelTone[i].postPlay(this, i < 4 ? prev_audctl : prev_audctl_r) } } + this.savedAudCtl = [this.getPokeyAudctl(0), this.getPokeyAudctl(1)] + this.sendRegs(this.pokeyRegs) } or for mono only simply: this.savedAudCtl = this.getPokeyAudctl(0) ??? This way it will be stored in player property and available all the time EDIT: or simply do your stuff at very begin of step() method, before Audctl is zeroed (this.getPokeyAudctl() should return correct value there)

Ok, I took a look again on player assembly: rmt_play rmt_p0 // update pokey registers computed in previous frame (rmt_play call) jsr SetPokey // do the rmt stuff and compute pokey registers rmt_p4 lda trackn_audctl+0 ora trackn_audctl+1 ora trackn_audctl+2 ora trackn_audctl+3 tax stx v_audctl // apply filters / BASS16 stuff and update X register (audctl value) if necessary stx v_audctl ... rts SetPokey ldy #$ff v_audctl equ *-1 ... sty $d208 ret So you are right, there is a one frame delay - rmt_play starts with setting pokey registers to values computed in previous frame. And this is for a reason: this way pokey registers are always set in very precise points of time (exactly on start of each frame, independently of number of cycles of rmt_play routine). But audclt is always reseted in each frame (at rmt_p4 label), so I think I'm doing very similar thing in rmt.js. I'm sending pokey regs to pokey backend directly after computing all they values, but it should not matter because registers are timestamped and also will be applied (by pokey backend) in very precise point of time (after short latency period)

Be patient, it will click finally My code is probably over-engineered a bit - maybe whole RMTTune object is not necessary and everything should be implemented directly in RMTPlayer.