Jump to content
VinsCool

RMT Hacking Ideas and Progress

Recommended Posts

2 hours ago, emkay said:

Btw. 

As now things have been changed tremendously. 

Could you suggest an Amiga Mod file to convert?

Sure:

 

checknobankh
https://modarchive.org/index.php?request=view_by_moduleid&query=36330

 

Vite and Plack
https://modarchive.org/index.php?request=view_by_moduleid&query=60535

 

wasteland
https://modarchive.org/index.php?request=view_by_moduleid&query=158236

 

all of them please, and maybe a newer Elysium update too 😀

  • Like 1

Share this post


Link to post
Share on other sites
30 minutes ago, ivop said:

I do a memcmp(previous_memory+0x3182, current_memory+0x3182, 2264), and detect that it has been altered in between 6502 emulation calls. Conclusion: bytes are changed within the player memory area in between calls to C6502_JSR(). Now find out which, and why :)

I just thought about it now (playing in the code right now just for fun)...
The program is asked to find the  'Tracker ' tag, and replace memory at that moment.
Doesn't that mean it will just try to replace it infinitely? Since the RMT.exe is not overwritten, after all.

Share this post


Link to post
Share on other sites
22 minutes ago, VinsCool said:

I just thought about it now (playing in the code right now just for fun)...
The program is asked to find the  'Tracker ' tag, and replace memory at that moment.
Doesn't that mean it will just try to replace it infinitely? Since the RMT.exe is not overwritten, after all.

I think I may be correct.
Got some mild success by adding the following at the start of the .c file:

int inject_done=0;

and changing the following:

#ifdef INJECT_TRACKER_OBX
    
    if (inject_done!=0) {
        fprintf(stderr, "%s: tracker memory already injected, skipping...\n", __func__);
    
    }
    else if (!strncmp(g_memory+0x3182, "TRACKER ", 8)) {
        fprintf(stderr, "%s: TRACKER tag found, loading file at $3182\n",
                                                                    __func__);
        load_raw("tracker.obx", g_memory+0x3182, 6);
        inject_done++; 
    }
#endif

Now the timing still somewhat off, but by doing this, and injecting the exact same 2270 bytes tracker binary, it does work okay, but I can tell things aren't quite right still :P 
Things sound a bit closer to what is expected now, at least :D 

Apologise for any bad code, I have no experience with C right now lol

tracker.obx sa_c6502.dll

  • Like 1

Share this post


Link to post
Share on other sites
1 hour ago, VinsCool said:

I think I may be correct.
Got some mild success by adding the following at the start of the .c file:

int inject_done=0;

and changing the following:

#ifdef INJECT_TRACKER_OBX
    
    if (inject_done!=0) {
        fprintf(stderr, "%s: tracker memory already injected, skipping...\n", __func__);
    
    }
    else if (!strncmp(g_memory+0x3182, "TRACKER ", 8)) {
        fprintf(stderr, "%s: TRACKER tag found, loading file at $3182\n",
                                                                    __func__);
        load_raw("tracker.obx", g_memory+0x3182, 6);
        inject_done++; 
    }
#endif

Now the timing still somewhat off, but by doing this, and injecting the exact same 2270 bytes tracker binary, it does work okay, but I can tell things aren't quite right still :P 
Things sound a bit closer to what is expected now, at least :D

That's useless code IMHO. After the injection (load_raw()) the strncmp() never matches the TRACKER tag again, and will always skip the loading code. It is only triggered once, but after that the memory still changes between calls.

 

I will investigate tomorrow. Been watching the full Zandvoort Grand Prix of 1963 right now :D The commentary is hilarious. The most safe circuit in the world. And people just walk along the circuit without any protection :) But, Jim Clark FTW!

 

  • Haha 1

Share this post


Link to post
Share on other sites
33 minutes ago, ivop said:

That's useless code IMHO. After the injection (load_raw()) the strncmp() never matches the TRACKER tag again, and will always skip the loading code. It is only triggered once, but after that the memory still changes between calls.

 

I will investigate tomorrow. Been watching the full Zandvoort Grand Prix of 1963 right now :D The commentary is hilarious. The most safe circuit in the world. And people just walk along the circuit without any protection :) But, Jim Clark FTW!

 

Ahh maybe you're right... I only blindly guessed over there, I saw the 'TRACKER tag found, loading file at $3182' line over and over in really quick succession so I assumed my idea to not do it again would help, but maybe not hehe.
for now I'm trying to improve my earlier code in the 'hijack' block of rmtplayr... I think I might be able to re-introduce the 16-bit code alongside the Distortion 2 hack now :D (yeah yeah totally pointless but I know at least 1 person who would like it anyway)

  • Like 1

Share this post


Link to post
Share on other sites
49 minutes ago, VinsCool said:

Ahh maybe you're right... I only blindly guessed over there, I saw the 'TRACKER tag found, loading file at $3182' line over and over in really quick succession so I assumed my idea to not do it again would help, but maybe not hehe.

Oh, but that's weird. I only see the 'TRACKER tag found, loading file at $3182' line once! After that, the tag is overwritten with the contents of tracker.obx (minus the first six bytes), hence the tag won't match anymore.

 

49 minutes ago, VinsCool said:

for now I'm trying to improve my earlier code in the 'hijack' block of rmtplayr... I think I might be able to re-introduce the 16-bit code alongside the Distortion 2 hack now :D (yeah yeah totally pointless but I know at least 1 person who would like it anyway)

Haha :)

  • Like 1

Share this post


Link to post
Share on other sites

I made a pretty interesting observation tonight with my hijack code in rmtplayr.
I noticed that while my method around v_audctl works pretty well, it is also 1 frame late when it is detected and handled!

That memory location will only be updated near the end of the Player execution, before being pushed into the actual AUDCTL register for the next frame, alongside the AUDC and AUDF ones.
Now, the issue is, the trackn_audc and trackn_audf contents will always be updated before v_audctl, which makes very quick changes between frames obvious if you keep an attentive ear to the sound output.


That is usually not a problem under normal situations, but when my own tables depend directly on the value in memory, this is a pretty big deal.
I have tried to do a couple tests, and I have come to the conclusion that, I would have to literally move a bunch of blocks around in memory, which is absolutely out of question since I will break too many things if I do that.

So I found a compromise for the time being looking like this:

hijack_start	
        lda trackn_audctl,x    ; workaround tentative... if not 0, it may have the wanted value...
        ora v_audctl           ; the old value will be combined to the new one, at worst, it will be 1 frame late
        tay                    ; backup to index y for quick transfer between steps

And while this appears to help for a bunch of things, such as 15khz or 16-bit when the instrument itself has the wanted values, anything else will still be 1 frame late like before.
Not ideal, but that seems like an acceptable workaround for the musicians who know what they are doing.
I see this rough compromise as an hybrid of my older method, and the Patch 16 Beta5 improvements, pretty much :P 
 

So to make it short:

if the instrument has the wanted AUDCTL value -> good, trackn_audctl has the value we need, go directly to the table hijack.

if the instrument does not have the wanted AUDCTL value -> no big deal, the next frame will cover your back with v_audctl instead.

 

Thank you for listening to my rambles, I just like to try dumb things out, if they work, I'm okay with that, hahaha :D 
 

  • Like 2

Share this post


Link to post
Share on other sites

It fits and sits :D This time I did not need to sacrifice all my 16-bit code... more on that later.

So yeah, that Distortion 2 hack can work with everything I did earlier, and fit in memory this time. :P 
There is only a few compromises over the code I have for the visual player, but it's really nothing major.

If that works, why not :D 

Generator Evening.obx

  • Like 7

Share this post


Link to post
Share on other sites

Remember how often I was suggesting this missing link with gen 2?

Finally someone was listening, see the result. 

The result needs less resources and leaves space for other stuff. Pitch correction is very timing friendly as well. 

 

Btw. Is the recording from the real thing?

Edited by emkay
  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

Fixed some oversights from last night in my memory change detection code (I'll probably backport the unified return to the main sa_c6502.dll).

 

C6502_Initialise: memory is zeroed

C6502_JSR: tracker memory changed (0)
loc 3182  cur: 54  prev: 00
loc 3183  cur: 52  prev: 00
loc 3184  cur: 41  prev: 00
loc 3185  cur: 43  prev: 00
loc 3186  cur: 4b  prev: 00
loc 3187  cur: 45  prev: 00
loc 3188  cur: 52  prev: 00
loc 3189  cur: 20  prev: 00
loc 35fc  cur: 60  prev: 00
C6502_JSR: TRACKER tag found, loading file at $3182
load_raw: read tracker.obx and skip 6 bytes
load_raw: injected 2264 bytes
C6502_JSR: $35FC = 4c

 

Look, there's our $35FC again. Your stripped Rmt.exe does not contain that RTS instruction (its all zeroes after the TRACKER tag), but Rmt.exe overwrote it. It used to be $4C which is a JMP.

 

I'll see with a different initial memory fill, if some bytes are set to zero, too. Otherwise, this could be our solution!

 

Edit:

 

C6502_Initialise: memory is zeroed

C6502_JSR: tracker memory changed (0)
loc 3182  cur: 54  prev: ff   T
loc 3183  cur: 52  prev: ff   R
loc 3184  cur: 41  prev: ff   A
loc 3185  cur: 43  prev: ff   C
loc 3186  cur: 4b  prev: ff   K
loc 3187  cur: 45  prev: ff   E
loc 3188  cur: 52  prev: ff   R
loc 3189  cur: 20  prev: ff   space
loc 35fc  cur: 60  prev: ff
C6502_JSR: TRACKER tag found, loading file at $3182
load_raw: read tracker.obx and skip 6 bytes
load_raw: injected 2264 bytes
C6502_JSR: $35FC = 4c
 

It seems it's the only byte overwritten by Rmt.exe.

 

 

Edit 2:

 

New version at https://github.com/ivop/rmt-sa-libs/tree/main/real/sa_c6502_inject

It now patches the RTS back in after loading the tracker.obx binary. Does it sound better to you? It does to me :)

 

 

Edit 3:

 

If this fixes the previous problem, then I will implement a proper FFFF loader instead of the raw loader that's in place right now. That way, besides the current rmtplayr memory space, you can load new code or data anywhere you want, and make calls to that :)

Edited by ivop
  • Thanks 1

Share this post


Link to post
Share on other sites
3 hours ago, ivop said:

Fixed some oversights from last night in my memory change detection code (I'll probably backport the unified return to the main sa_c6502.dll).

 

C6502_Initialise: memory is zeroed

C6502_JSR: tracker memory changed (0)
loc 3182  cur: 54  prev: 00
loc 3183  cur: 52  prev: 00
loc 3184  cur: 41  prev: 00
loc 3185  cur: 43  prev: 00
loc 3186  cur: 4b  prev: 00
loc 3187  cur: 45  prev: 00
loc 3188  cur: 52  prev: 00
loc 3189  cur: 20  prev: 00
loc 35fc  cur: 60  prev: 00
C6502_JSR: TRACKER tag found, loading file at $3182
load_raw: read tracker.obx and skip 6 bytes
load_raw: injected 2264 bytes
C6502_JSR: $35FC = 4c

 

Look, there's our $35FC again. Your stripped Rmt.exe does not contain that RTS instruction (its all zeroes after the TRACKER tag), but Rmt.exe overwrote it. It used to be $4C which is a JMP.

 

I'll see with a different initial memory fill, if some bytes are set to zero, too. Otherwise, this could be our solution!

 

Edit:

 

C6502_Initialise: memory is zeroed

C6502_JSR: tracker memory changed (0)
loc 3182  cur: 54  prev: ff   T
loc 3183  cur: 52  prev: ff   R
loc 3184  cur: 41  prev: ff   A
loc 3185  cur: 43  prev: ff   C
loc 3186  cur: 4b  prev: ff   K
loc 3187  cur: 45  prev: ff   E
loc 3188  cur: 52  prev: ff   R
loc 3189  cur: 20  prev: ff   space
loc 35fc  cur: 60  prev: ff
C6502_JSR: TRACKER tag found, loading file at $3182
load_raw: read tracker.obx and skip 6 bytes
load_raw: injected 2264 bytes
C6502_JSR: $35FC = 4c
 

It seems it's the only byte overwritten by Rmt.exe.

 

 

Edit 2:

 

New version at https://github.com/ivop/rmt-sa-libs/tree/main/real/sa_c6502_inject

It now patches the RTS back in after loading the tracker.obx binary. Does it sound better to you? It does to me :)

 

 

Edit 3:

 

If this fixes the previous problem, then I will implement a proper FFFF loader instead of the raw loader that's in place right now. That way, besides the current rmtplayr memory space, you can load new code or data anywhere you want, and make calls to that :)

Incredible!
Will give it a go a bit later today once I'm done with few things I need to do at home, and that improved Distortion 2 hack I will finish, after I showed it working alongside the currently in progress hijack improvements I rambled about last night.
Being able to get all of the addresses under control should make all of everything working, and cross compatible with the more ambitious changes I wanted to do for some time now regarding the entire memory map involving the Visual Player prelimineray tests I was able to confirm were good.

Remember the rmtplayr.a65 mentioning the memory addresses MUST be exactly what they were shown there? I can tell you this is not absolutely necessary, it is a recommendation more than a limitation, as far as I could tell, and I will prove it some time soon with a new re-arranged layout.
Being able to use much larger memory pages will benefit a TON for a lot of things, mainly, the notes tables.
No more getting stopped by the 256 bytes limitation (+128 bytes of my own from optimised volume table), I could easily point to any memory page and their respective high/low bytes if I wanted to :) 

  • Like 1

Share this post


Link to post
Share on other sites
7 hours ago, emkay said:

Remember how often I was suggesting this missing link with gen 2?

Finally someone was listening, see the result. 

The result needs less resources and leaves space for other stuff. Pitch correction is very timing friendly as well. 

Thanks! I'm really happy how well this has been working so far.
Much much better than anticipated when I began from very rudimentary hex edited tables without any real improvement compared to the RMT2LZSS results.
Things have definitely branched outside of the original RMT code now, and maintaining backwards compatibility will become difficult as a result, but we will see.


I have to say, manually setting the 1.79mhz clock for Distortion 2 worked very well already, but this hack really shows the power.
Now if we had a way to literally create a new envelope specifically for AUDCTL, we'd be in absolute control, much like the .erti parameters from RMT2LZSS, except in a much more friendly music tracker interface with real time response.

7 hours ago, emkay said:

Btw. Is the recording from the real thing?

Nope, It was from Altirra emulator, but I am very confident this should sound much of the same.
I can get a hardware recording for the sake of it later tonight just to see how that compares, but as far as I know, this will be very close to it :) 
That will also give me another shot at testing my custom Visual Player code on hardware and see if what I did is working correctly on Hardware, I believe it will be fine, but we never know.

  • Like 1

Share this post


Link to post
Share on other sites

Here's the XEX loader: (we need it anyway :) )

 

C6502_Initialise: memory is zeroed

C6502_JSR: tracker memory changed (0)
loc 3182  cur: 54  prev: 00
loc 3183  cur: 52  prev: 00
loc 3184  cur: 41  prev: 00
loc 3185  cur: 43  prev: 00
loc 3186  cur: 4b  prev: 00
loc 3187  cur: 45  prev: 00
loc 3188  cur: 52  prev: 00
loc 3189  cur: 20  prev: 00
loc 35fc  cur: 60  prev: 00
C6502_JSR: TRACKER tag found, load tracker.obx
load_xex: load tracker.obx
load_xex: load 3182 - 3a59
load_xex: injected 2264 bytes
load_xex: load 0600 - 060b
load_xex: injected 12 bytes
load_xex: load 0680 - 0693
load_xex: injected 20 bytes
load_xex: load 3182 - 3a59
load_xex: injected 2264 bytes

 

The tracker.obx in the git repo is Vinscool's player, "HELLO, WORLD" at $0600, "GOODBYE, CRUEL WORLD" at $0680, and the player again. Some segments are FFFF strt enda, and some later skip the FFFF marker, which is not needed anymore. Just feed it a proper Atari .xex file and it all should work ;)

Edited by ivop
  • Thanks 1

Share this post


Link to post
Share on other sites

Alright so here's this Distortion 2 hack updated:

- Optimised a bunch of the main hijack code, now there is Distortion 2 1.79mhz, Distortion A and C 15khz and 16-bit code fitting!*

- Replaced the 16-bit bass tables for the Clarinet Reverse-16 setup, because this one especially harmonises nicely to the Distortion 2.

 

* There were a few compromises in order to fit everything into the smaller possible binary (MONO player).

- The 16-bit code was reduced to only check for Join1+2 or Join3+4 bits, but as long as the combination of Join and 1.79mhz is enabled in instruments, it will work just as good for Reverse-16 sounds.
- v_audctl is still used alone for the main checks, so there will be a few occasions where a frame may be skipped, but this is barely noticeable in most situations anyway :P 

 

Now I'm going to try out that new .dll for the .obx loader and see how it goes :D 

 

RMT Distortion 2 Hack v2.zip

  • Like 1

Share this post


Link to post
Share on other sites
15 minutes ago, ivop said:

Here's the XEX loader: (we need it anyway :) )

 

C6502_Initialise: memory is zeroed

C6502_JSR: tracker memory changed (0)
loc 3182  cur: 54  prev: 00
loc 3183  cur: 52  prev: 00
loc 3184  cur: 41  prev: 00
loc 3185  cur: 43  prev: 00
loc 3186  cur: 4b  prev: 00
loc 3187  cur: 45  prev: 00
loc 3188  cur: 52  prev: 00
loc 3189  cur: 20  prev: 00
loc 35fc  cur: 60  prev: 00
C6502_JSR: TRACKER tag found, load tracker.obx
load_xex: load tracker.obx
load_xex: load 3182 - 3a59
load_xex: injected 2264 bytes
load_xex: load 0600 - 060b
load_xex: injected 12 bytes
load_xex: load 0680 - 0693
load_xex: injected 20 bytes
load_xex: load 3182 - 3a59
load_xex: injected 2264 bytes

 

The tracker.obx in the git repo is Vinscool's player, "HELLO, WORLD" at $0600, "GOODBYE, CRUEL WORLD" at $0680, and the player again. Some segments are FFFF strt enda, and some later skip the FFFF marker, which is not needed anymore. Just feed it a proper Atari .xex file and it all should work ;)

Man this is PERFECT!
Now I cannot even tell anything is wrong in the playback! It's a perfect match to what is expected as far as my 5 minutes test seem to show me there :D
Now I will finally be able to move some memory map around and use larger tables, fuck YES

Thank you so much, this is a HUGE breakthrough!

Soon I will no longer have to make stand alone versions like the Distortion 2 hack back, just swap in and out the .obx to use 😻

Edited by VinsCool
  • Like 2
  • Thanks 1

Share this post


Link to post
Share on other sites

Good news everyone.

I've done some preliminary tests moving tables (notes, notes map, vibrato, volume, etc) to the $B000 location in memory, and so far it's working using the .obx loader.

I've only got a small issue related to the AUDCTL values related to all of this, but I will figure it out a later time.
For now it would just get stuck on FF, and manually setting 00 in the code makes it just stay 00... which is thankfully better than garbage for the time being, hehe

That is pretty much the first thing I wanted to do for a while, and it does work, with few things broken, but I'll figure it out, hopefully.

[Edit] Actually I just remembered I could just look at an earlier version .lst and go with the same addresses...

This was the output from Patch 16 Beta 5, maybe I can try to get these addresses back?, hmmmm

 1538                           	ELI STEREOMODE==1		; L1 L2 L3 L4 R1 R2 R3 R4, STEREO (Mode 1)
 1539 39C2 A0 FF                	ldy #$ff
 1540 =     39C3                v_audctl2 equ *-1
 1541 39C4 AD 64 31             	lda trackn_audf+0+4
 1542 39C7 AE 60 31             	ldx trackn_audf+0
 1543 39CA 8D 10 D2             	sta $d210
 1544 39CD 8E 00 D2             	stx $d200
 1545 39D0 AD 6C 31             	lda trackn_audc+0+4
 1546 39D3 AE 68 31             	ldx trackn_audc+0
 1547 39D6 8D 11 D2             	sta $d211
 1548 39D9 8E 01 D2             	stx $d201
 1549 39DC AD 65 31             	lda trackn_audf+1+4
 1550 39DF AE 61 31             	ldx trackn_audf+1
 1551 39E2 8D 12 D2             	sta $d212
 1552 39E5 8E 02 D2             	stx $d202
 1553 39E8 AD 6D 31             	lda trackn_audc+1+4
 1554 39EB AE 69 31             	ldx trackn_audc+1
 1555 39EE 8D 13 D2             	sta $d213
 1556 39F1 8E 03 D2             	stx $d203
 1557 39F4 AD 66 31             	lda trackn_audf+2+4
 1558 39F7 AE 62 31             	ldx trackn_audf+2
 1559 39FA 8D 14 D2             	sta $d214
 1560 39FD 8E 04 D2             	stx $d204
 1561 3A00 AD 6E 31             	lda trackn_audc+2+4
 1562 3A03 AE 6A 31             	ldx trackn_audc+2
 1563 3A06 8D 15 D2             	sta $d215
 1564 3A09 8E 05 D2             	stx $d205
 1565 3A0C AD 67 31             	lda trackn_audf+3+4
 1566 3A0F AE 63 31             	ldx trackn_audf+3
 1567 3A12 8D 16 D2             	sta $d216
 1568 3A15 8E 06 D2             	stx $d206
 1569 3A18 AD 6F 31             	lda trackn_audc+3+4
 1570 3A1B AE 6B 31             	ldx trackn_audc+3
 1571 3A1E 8D 17 D2             	sta $d217
 1572 3A21 8E 07 D2             	stx $d207
 1573 3A24 A9 FF                	lda #$ff
 1574 =     3A25                v_audctl equ *-1
 1575 3A26 8C 18 D2             	sty $d218
 1576 3A29 8D 08 D2             	sta $d208

[Edit2] okay nevermind, it's fixed, I literally just ORG'd the 2 v_audctl values in the zero page, then loaded them directly o.o
Well guess that's pretty much it, everything works, now I can go on the real fun: adding tuning tables! Finally :D 

Edited by VinsCool
  • Like 1

Share this post


Link to post
Share on other sites
2 hours ago, VinsCool said:

Now I cannot even tell anything is wrong in the playback!

I was hoping for that! It took a few days to figure it out, and in the end it was just that single byte at $35FC :)

 

29 minutes ago, VinsCool said:

Well guess that's pretty much it, everything works, now I can go on the real fun: adding tuning tables! Finally :D 

Looking forward to that! Most of the 6502 address space is free to use now :D

  • Like 1

Share this post


Link to post
Share on other sites
1 minute ago, ivop said:

I was hoping for that! It took a few days to figure it out, and in the end it was just that single byte at $35FC :)

 

Glad this worked out indeed!

1 minute ago, ivop said:

Looking forward to that! Most of the 6502 address space is free to use now :D

I am in a really good mood right now with this stuff!
So far everything works, I'm now loading all the RMT tables (used to be at $3182 to $33FF basically!) from $B000 without any problem as far as I could tell.

  • Like 1

Share this post


Link to post
Share on other sites

BIG update right there!
 

RMT Patch 16 Beta6:

- Brand new sa_c6502.dll by ivop, featuring a built-in Tracker binary loader, simply drop a tracker.obx in the .exe folder and run!
- Moved all tables to $B000, this will much more data to be available in memory, and future proof the space when it will be needed later
- Rewrote the entire hijack code again, this time hopefully for a long with the current memory map
- ALL modes can now have their own set of tables, making a LOT of the hijacked shit very easy to handle now, at a cost of extra memory
- Currently, 64khz (default), 15khz, 1.79mhz and 16-bit (via AUDCTL $50 or $28) will have their respective tables handled automatically, with as many slots as necessary
- All tables can FINALLY use the full 64 bytes when the tuning allows it, since the memory page is a new one between modes
- Added a handful of new tables as a test, many will need retuning, but as a proof of concept, they seem to work perfectly
- Preliminary support for these tables added: Distortion 2 64khz, Distortion A 1.79mhz, Distortion C 1.79mhz, Distortion E 1.79mhz 
- Improved the Distortion A and C 15khz tables to make the full 64 bytes of tuning available, that will get rid of the disappointing cut around C-5 to the next table in memory, making that one note unavailable
- Improved the Distortion A and E 64khz to use the full 64 bytes of tuning each, with the best possible frequencies in the highest pitch, so there shouldn't be any random silence now
- 16-bit currently only has 1 table as an example, the nice Reverse-16 Clarinet, like the earlier Patch 16 versions, use with the Join+1.79mhz AUDCTL bits, they will use the correct table automatically in the respective channels
- Made several table slots dummy entries, due to missing data, but these will be added later, there is a bit of retuning to do for many combinations, aaarghhhh XD
- Virtually, the user might not see any difference between this version and the Patch 16 Beta5 release, which is in my opinion, a good thing!

I must say again, massive thanks to @ivop for the binary loader.
None of this would have been possible without this breathrough!

RMT Patch 16 Beta6.zip

  • Like 6
  • Thanks 1

Share this post


Link to post
Share on other sites
13 hours ago, VinsCool said:

I am in a really good mood right now with this stuff!

So was I when I finally found out how to get things working correctly. It was a real disappointment when it didn't work at first.

 

Now I'm thinking about Pokey again ;)

  • Haha 1

Share this post


Link to post
Share on other sites

Looking forward to what you are going to do with the new XEX loader. In the end it should sync with RMT2LZSS I suppose?

 

As for Pokey, here are some options:

 

1. try to apply all patches since 2003 to sa_pokey.dll

2. start over with current atari800 pokey.c and pokeysnd.c

 

About the same level of difficulty, and you'll end up, with circa 2014 atari800 pokey emulation. Considering the code base changes @Wrathchild already mentioned, I think option 2 is less work.

 

3. reimplement apokeysnd in C instead of Cito? Or learn Cito ;)

4. try to extract the pokey emulation and resampling from Altirra. Extremely hard, and C++.

5. start all over from scratch, and use Altirra source code and hardware manual as a guide as to how implement everything.

 

Or, something I have been pondering over for years, implement a "pokey bridge" to a running emulator, either atari800 or Altirra. Well, at first I thought about a full blown API to run code in the emulator, too, but that's not needed anymore. So just pokey. I imagine a "pokey bridge" as a local socket which receives commands to change the pokey registers. Like packets of 10 registers. $D200-D208 and $D20F. Once the emulator is running with pokey bridge enabled, you can connect to that socket from sa_pokey.dll, and send packets as soon as Process() is called. Process() itself returns a silent buffer, to not disturb the sound of the emulator.

 

I can add this to atari800, but it would be better if @phaeron chipped in and implemented this in Altirra :D

 

Edit: and it would need a way to accommodate for stereo. Perhaps the easiest "protocol" over the pokey bridge would be just FFFF start end, and then data. Could be FF FF  00 D2 08 D2 and nine bytes of data, but also SKCTL, or a second pokey. Always start with FFFF, on which you can sync, et cetera...

Edited by ivop
  • Like 1

Share this post


Link to post
Share on other sites

I think an updated sa_pokey.dll would be a really good start.
I'm actually curious to compare how it performs vs 2003 sa_pokey.dll vs Altirra vs Hardware

Share this post


Link to post
Share on other sites
1 minute ago, VinsCool said:

I think an updated sa_pokey.dll would be a really good start.
I'm actually curious to compare how it performs vs 2003 sa_pokey.dll vs Altirra vs Hardware

You can hear how it would perform by running an RMT player binary, or an RMT2LZSS binary, on the current atari800. It is not as good as Altirra. Not by a long shot. @emkay says Altirra still doesn't match real hardware in some cases, but you have to ask him to explain where and when :)

  • Like 1

Share this post


Link to post
Share on other sites
6 minutes ago, ivop said:

You can hear how it would perform by running an RMT player binary, or an RMT2LZSS binary, on the current atari800. It is not as good as Altirra. Not by a long shot. @emkay says Altirra still doesn't match real hardware in some cases, but you have to ask him to explain where and when :)

I've personally done hardware vs Altirra comparisons with my stuff, it's INCREDIBLY close as far as I am concerned.
Atari800 I've only used a crappy free mobile port and it was pretty poor indeed, but I blamed this on the mobile port being poor more than the emulation itself.
Now I'm actually curious to compare...

  • Like 1

Share this post


Link to post
Share on other sites
11 minutes ago, VinsCool said:

I've personally done hardware vs Altirra comparisons with my stuff, it's INCREDIBLY close as far as I am concerned.
Atari800 I've only used a crappy free mobile port and it was pretty poor indeed, but I blamed this on the mobile port being poor more than the emulation itself.
Now I'm actually curious to compare...

Well, clone https://github.com/atari800/atari800, install the proper SDL development libraries with apt-get, run ./configure, (check errors and install more libraries and -dev packages :) ), and run make.

 

Or download a package from https://github.com/atari800/atari800/releases, although I won't just install one of them .deb packages. It might F-up your distro. If you don't want to compile from source and install in /usr/local/., I'd go for the win32 packages and run it in a wine sandbox.

 

OR, perhaps your distro already has a pretty recent atari800 in its repo already. Likely. apt-get install atari800, and after that put the proper OS and BASIC ROMS in the right directory :)

 

Edited by ivop
  • Like 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...