Trying to make some PoKEY music!

VinsCool · August 15, 2021

6 hours ago, emkay said:

Very nice. I'm missing the dying cats, which is a great thing

Good to know, that would mean my tuning is giving nice results.

I remember this tune sounded quite out of tune in the original rmt version, which I have uploaded on youtube sometime around 2019.

VinsCool · August 16, 2021

it's all fun stuff

By the way, the colours are all decided by the mighty RANDOM register, so every time a binary is loaded, it's always a different combination :3

RMT Visual Player 0.1 + 3 Soundracks.zip

ivop · August 17, 2021

Also made a dummy sa_c6502.dll

#include <stdint.h>
#include <stdio.h>

void __declspec(dllexport) C6502_Initialise(uint8_t *memory ) {
    fprintf(stderr, "%s: memory pointer set\n", __func__);
}

int __declspec(dllexport) C6502_JSR(uint16_t *adr,
                                    uint8_t *areg,
                                    uint8_t *xreg,
                                    uint8_t *yreg, int *maxcycles) {

    fprintf(stderr, "%s: PC=%04x A=%02x X=%02x Y=%02x maxcycles=%i\n",
            __func__, *adr, *areg, *xreg, *yreg, *maxcycles);
    return (*maxcycles)/2;
}

void __declspec(dllexport) C6502_About(char** name,
                                       char** author,
                                       char** description ) {
    *name        = "Dummy CPU";
    *author      = "Dummy";
    *description = "Doing nothing";
}

Output:

C6502_JSR: PC=340c A=00 X=00 Y=00 maxcycles=35568
C6502_JSR: PC=3406 A=00 X=00 Y=00 maxcycles=35568
C6502_JSR: PC=340c A=00 X=00 Y=00 maxcycles=35568
C6502_JSR: PC=3406 A=00 X=00 Y=00 maxcycles=35568
C6502_JSR: PC=340c A=00 X=00 Y=00 maxcycles=35568
C6502_JSR: PC=3406 A=00 X=00 Y=00 maxcycles=35568
C6502_JSR: PC=340c A=00 X=00 Y=00 maxcycles=35568
C6502_JSR: PC=3406 A=00 X=00 Y=00 maxcycles=35568
C6502_JSR: PC=340c A=00 X=00 Y=00 maxcycles=35568
C6502_JSR: PC=3406 A=00 X=00 Y=00 maxcycles=35568
C6502_JSR: PC=340c A=00 X=00 Y=00 maxcycles=35568
C6502_JSR: PC=3e00 A=00 X=00 Y=00 maxcycles=35568
C6502_JSR: PC=3e00 A=00 X=01 Y=00 maxcycles=35568
C6502_JSR: PC=3e00 A=00 X=02 Y=00 maxcycles=35568
C6502_JSR: PC=3e00 A=00 X=03 Y=00 maxcycles=35568
C6502_JSR: PC=3e00 A=00 X=04 Y=00 maxcycles=35568
C6502_JSR: PC=3e00 A=00 X=05 Y=00 maxcycles=35568
C6502_JSR: PC=3e00 A=00 X=06 Y=00 maxcycles=35568
C6502_JSR: PC=3e00 A=00 X=07 Y=00 maxcycles=35568
C6502_JSR: PC=3406 A=00 X=00 Y=00 maxcycles=35568
C6502_JSR: PC=340c A=00 X=00 Y=00 maxcycles=35568

Observations:

- No matter how many cycles you burn, C6502_JSR() is always called with maxcycles=35568

- 35568 is exactly 312*114, which is a PAL frame

- Even in NTSC mode, it uses the PAL amount of cycles

Result, combined with sa_pokey and apokeysnd:

PAL tunes are played at PAL clock speed?, audio is resampled with NTSC parameters.

NTSC tunes are played at PAL clock speed?, audio is resampled with NTSC parameters.

Neither seems correct, and PAL certainly isn't.

Edit: the value 35568 does not mean it is called 50 times per second insted of 60 in NTSC mode, but is does specify the maxcycles per PAL frame, which is larger than 262*114 for NTSC.

Edited August 17, 2021 by ivop

_The Doctor__ · August 17, 2021

32 minutes ago, ivop said:

Also made a dummy sa_c6502.dll


#include <stdint.h>
#include <stdio.h>

void __declspec(dllexport) C6502_Initialise(uint8_t *memory ) {
    fprintf(stderr, "%s: memory pointer set\n", __func__);
}

int __declspec(dllexport) C6502_JSR(uint16_t *adr,
                                    uint8_t *areg,
                                    uint8_t *xreg,
                                    uint8_t *yreg, int *maxcycles) {

    fprintf(stderr, "%s: PC=%04x A=%02x X=%02x Y=%02x maxcycles=%i\n",
            __func__, *adr, *areg, *xreg, *yreg, *maxcycles);
    return (*maxcycles)/2;
}

void __declspec(dllexport) C6502_About(char** name,
                                       char** author,
                                       char** description ) {
    *name        = "Dummy CPU";
    *author      = "Dummy";
    *description = "Doing nothing";
}

Output:


C6502_JSR: PC=340c A=00 X=00 Y=00 maxcycles=35568
C6502_JSR: PC=3406 A=00 X=00 Y=00 maxcycles=35568
C6502_JSR: PC=340c A=00 X=00 Y=00 maxcycles=35568
C6502_JSR: PC=3406 A=00 X=00 Y=00 maxcycles=35568
C6502_JSR: PC=340c A=00 X=00 Y=00 maxcycles=35568
C6502_JSR: PC=3406 A=00 X=00 Y=00 maxcycles=35568
C6502_JSR: PC=340c A=00 X=00 Y=00 maxcycles=35568
C6502_JSR: PC=3406 A=00 X=00 Y=00 maxcycles=35568
C6502_JSR: PC=340c A=00 X=00 Y=00 maxcycles=35568
C6502_JSR: PC=3406 A=00 X=00 Y=00 maxcycles=35568
C6502_JSR: PC=340c A=00 X=00 Y=00 maxcycles=35568
C6502_JSR: PC=3e00 A=00 X=00 Y=00 maxcycles=35568
C6502_JSR: PC=3e00 A=00 X=01 Y=00 maxcycles=35568
C6502_JSR: PC=3e00 A=00 X=02 Y=00 maxcycles=35568
C6502_JSR: PC=3e00 A=00 X=03 Y=00 maxcycles=35568
C6502_JSR: PC=3e00 A=00 X=04 Y=00 maxcycles=35568
C6502_JSR: PC=3e00 A=00 X=05 Y=00 maxcycles=35568
C6502_JSR: PC=3e00 A=00 X=06 Y=00 maxcycles=35568
C6502_JSR: PC=3e00 A=00 X=07 Y=00 maxcycles=35568
C6502_JSR: PC=3406 A=00 X=00 Y=00 maxcycles=35568
C6502_JSR: PC=340c A=00 X=00 Y=00 maxcycles=35568

Observations:

- No matter how many cycles you burn, C6502_JSR() is always called with maxcycles=35568

- 35568 is exactly 312*114, which is a PAL frame

- Even in NTSC mode, it uses the PAL amount of cycles

Result, combined with sa_pokey and apokeysnd:

PAL tunes are played at PAL clock speed?, audio is resampled with NTSC parameters.

NTSC tunes are played at PAL clock speed?, audio is resampled with NTSC parameters.

Neither seems correct, and PAL certainly isn't.

Edit: the value 35568 does not mean it is called 50 times per second insted of 60 in NTSC mode, but is does specify the maxcycles per PAL frame, which is larger than 262*114 for NTSC.

this is also a problem in games, the pal programmer doesn't realize the extra frames are available for their code. the coder says it's out of cycles but it isn't... there is still more to go in the same time period but they need to use it and adjust accordingly. less code in each run of stitches, but more runs of stitches for 60. more code in each run of stitches, but less runs of stitches for 50. Both execute nearly the same amount of information in the same time period.

Edited August 17, 2021 by _The Doctor__

VinsCool · August 17, 2021

49 minutes ago, ivop said:

Observations:

- No matter how many cycles you burn, C6502_JSR() is always called with maxcycles=35568

- 35568 is exactly 312*114, which is a PAL frame

- Even in NTSC mode, it uses the PAL amount of cycles

Result, combined with sa_pokey and apokeysnd:

PAL tunes are played at PAL clock speed?, audio is resampled with NTSC parameters.

NTSC tunes are played at PAL clock speed?, audio is resampled with NTSC parameters.

Neither seems correct, and PAL certainly isn't.

Edit: the value 35568 does not mean it is called 50 times per second insted of 60 in NTSC mode, but is does specify the maxcycles per PAL frame, which is larger than 262*114 for NTSC.

LMFAO
Amazing findings!

So what I suspected from the beginning was indeed happening for real! hahahaha ?
That's indeed, a pretty cursed set of combinations, but I'm happy to know things still did work regardless!

I knew there was something this odd, things definitely were all PAL stuff with a strange flow going, and now I see you proved this was indeed true!
I suppose just like the CPU clock speed, there is a constant somewhere in the EXE that defines the cycles too?

At last, being able to adjust both would finally give the correct clock and pitch between regions, at the cost of having to edit the executable to then have 2 versions with the correct parameters?
I'm legitimately surprised something like this was overlooked, and never given any additional thought until you started doing that cool debugging stuff. ?

ivop · August 17, 2021

The maxcycles calling variable is indeed a 32-bit LE constant in the binary, but decreasing that to 262*114 will not make any difference. The rmtplayr code will most likely always take way less cycles. Even if the pokey backend always resamples with NTSC parameters, it does matter how many times C6502_JSR() is called per second. I will check with a timer fprintf. Tomorrow. Not now

rensoup · August 17, 2021

15 minutes ago, ivop said:

The maxcycles calling variable is indeed a 32-bit LE constant in the binary, but decreasing that to 262*114 will not make any difference. The rmtplayr code will most likely always take way less cycles. Even if the pokey backend always resamples with NTSC parameters, it does matter how many times C6502_JSR() is called per second. I will check with a timer fprintf. Tomorrow. Not now

That's probably right, I guess he just set the cycles per frame to PAL because it doesn't matter how many cycles are available as long as there are enough to run a full iteration of the RMT player. I guess it could be set to 100000000 cycles and make no difference (except perhaps slowing down your PC!)

ivop · August 17, 2021

35 minutes ago, rensoup said:

That's probably right, I guess he just set the cycles per frame to PAL because it doesn't matter how many cycles are available as long as there are enough to run a full iteration of the RMT player. I guess it could be set to 100000000 cycles and make no difference (except perhaps slowing down your PC!)

No, it always stops at the last rts which is way before the maxcycles value. Even sooner than maxcycles/4

ivop · August 17, 2021

Okay, I couldn't resist. Here's a timer sa_c6502.c

#include <stdint.h>
#include <stdio.h>
#include <sys/time.h>

int prev = 0;

void __declspec(dllexport) C6502_Initialise(uint8_t *memory ) {
    fprintf(stderr, "%s: memory pointer set\n", __func__);
}

int __declspec(dllexport) C6502_JSR(uint16_t *adr,
                                    uint8_t *areg,
                                    uint8_t *xreg,
                                    uint8_t *yreg, int *maxcycles) {

    struct timeval  tv;
    gettimeofday(&tv, NULL);

    fprintf(stderr, "%s: PC=%04x A=%02x X=%02x Y=%02x maxcycles=%i\n",
            __func__, *adr, *areg, *xreg, *yreg, *maxcycles);

    fprintf(stderr, "%s: ms=%u\n", __func__, (tv.tv_usec - prev)/1000);

    prev = tv.tv_usec;
    return (*maxcycles)/2;
}

void __declspec(dllexport) C6502_About(char** name,
                                       char** author,
                                       char** description ) {
    *name        = "Dummy CPU";
    *author      = "Dummy";
    *description = "Doing nothing";
}

It's very crude, my rounding is off, but it does the job. I needed to copy /usr/lib/gcc/i686-w64-mingw32/8.3-win32/libgcc_s_sjlj-1.dll to my local wine rmt test directory at ~/.wine-rmt-test/drive_c/rmt/. to get gettimeofday() to work.

PAL:

C6502_JSR: PC=3406 A=00 X=00 Y=00 maxcycles=35568
C6502_JSR: ms=20
C6502_JSR: PC=340c A=00 X=00 Y=00 maxcycles=35568
C6502_JSR: ms=0
C6502_JSR: PC=3406 A=00 X=00 Y=00 maxcycles=35568
C6502_JSR: ms=19
C6502_JSR: PC=340c A=00 X=00 Y=00 maxcycles=35568
C6502_JSR: ms=0
C6502_JSR: PC=3406 A=00 X=00 Y=00 maxcycles=35568
C6502_JSR: ms=20
C6502_JSR: PC=340c A=00 X=00 Y=00 maxcycles=35568
C6502_JSR: ms=0
C6502_JSR: PC=3e00 A=00 X=00 Y=00 maxcycles=35568
C6502_JSR: ms=19

NTSC:

C6502_JSR: PC=3406 A=00 X=00 Y=00 maxcycles=35568
C6502_JSR: ms=16
C6502_JSR: PC=340c A=00 X=00 Y=00 maxcycles=35568
C6502_JSR: ms=0
C6502_JSR: PC=3406 A=00 X=00 Y=00 maxcycles=35568
C6502_JSR: ms=17
C6502_JSR: PC=340c A=00 X=00 Y=00 maxcycles=35568
C6502_JSR: ms=0
C6502_JSR: PC=3406 A=00 X=00 Y=00 maxcycles=35568
C6502_JSR: ms=16
C6502_JSR: PC=340c A=00 X=00 Y=00 maxcycles=35568
C6502_JSR: ms=0
C6502_JSR: PC=3406 A=00 X=00 Y=00 maxcycles=35568
C6502_JSR: ms=17
C6502_JSR: PC=340c A=00 X=00 Y=00 maxcycles=35568
C6502_JSR: ms=0

As I said, very crude, but it's clear enough that the CPU emulation is called at circa 16.6 ms intervals for NTSC and at circa 20ms intervals for PAL, which seems OK.

Edited August 17, 2021 by ivop

rensoup · August 17, 2021

1 hour ago, ivop said:

No, it always stops at the last rts which is way before the maxcycles value. Even sooner than maxcycles/4

No as in it will not slow down your PC ?

Of course if it terminates with a RTS (instead of using some form of sync method which is unnecessary here) but your previous message seemed to imply it was a bug to call the 6502 emu with the same number of cycles for PAL & NTSC:

5 hours ago, ivop said:

- No matter how many cycles you burn, C6502_JSR() is always called with maxcycles=35568

- 35568 is exactly 312*114, which is a PAL frame

- Even in NTSC mode, it uses the PAL amount of cycles

...But we're agreeing that it's irrelevant I think ?

this one at least should be fine:

5 hours ago, ivop said:

NTSC tunes are played at PAL clock speed?, audio is resampled with NTSC parameters.

?

ivop · August 17, 2021

57 minutes ago, rensoup said:

No as in it will not slow down your PC ?

Yes, it will not slow down your PC, as the emulation stops if the init or play routine ends with an RTS.

Quote

Of course if it terminates with a RTS (instead of using some form of sync method which is unnecessary here) but your previous message seemed to imply it was a bug to call the 6502 emu with the same number of cycles for PAL & NTSC:

...But we're agreeing that it's irrelevant I think ?

Yes, we agree. The maxcycles value is irrelevant in regard to the eventual playback speed.

Quote

this one at least should be fine:

[NTSC tunes with NTSC resampling]

?

Yes, I think so. My latest experiment shows that the 6502 player is indeed called circa 60 times per second in NTSC mode, and its writes to Pokey registers are sampled at least at that rate, and then the final audio signal is resampled with NTSC clock speed resampling parameters, so that should be fine. Sort of

Edit: BTW it's not entirely clear yet how apokeysnd resamples. Previous remarks are all about sa_pokey. apokeysnd doesn't set its CPU clock speed in any way, but I have not yet checked which is the default it uses. It will be wrong for either NTSC or PAL, depending on which resampling it uses.

Edited August 18, 2021 by ivop
typoo

VinsCool · August 20, 2021

I have something I guess.

Not really a finished thing so I can always edit it again another day.
I was actually going to work on something different, but was not feeling it and started to sketch random patterns, and this was the result after a few hours tonight lol

sketch 58.obx

VinsCool · August 21, 2021

I forgot to post this one yesterday for some reason, so here's some grating sounds with some bass and drums.
Another messy project I started pretty much.

No visual player because I did not bother, and no LZSS since my RMT code is handling 16-bit in a totally different way.

Sketch 59 v1.xex

+MrFish · August 21, 2021

Nice combination of instruments.

VinsCool · August 27, 2021

Major improvements with both the visual player project and the rmtplayr that is tightly bonded to it!

Spring - Phasebass + rmtplayr 15khz New Hijack Test

Now 100% AUDCTL based, that makes switching between modes absolutely painless.
Not shown on this one, my new 16-bit code took the same approach and works just as well.

The rmtplayr code should work in the actual tracker, in theory.
I have yet to try making it fit, after I'm done optimising what I did change and add.

Also showcased: major improvements in the visual player code, cleaned up a lot of the graphic routines, fixed many nasty bugs I did not even know were there until I started to get accurate informations displayed on screen (still unfinished, so there may be some incorrect things here and there).
I've been learning 6502 ASM slowly over the last month, but surely, things are going somewhere.

Original module by Spring.

Phasebass.obx

VinsCool · August 29, 2021

My next major RMT hack version is getting pretty good now.
I can confirm pretty much all of the new code I introduced and compacted as much as possible to fit within the limits of the binary size held into the .exe
Stereo support isn't yet done but that shouldn't take very long to adjust.

So now all the 15khz tuning for Distortion A and C is handled automatically based on the global v_audctl variable, no extra tracking work required.
As long as something has the correct AUDCTL bit, effects will be for all the channels regardless of the instrument used.

I also made an interesting observation.
I found out the trackn_outnote variables may be hardcoded specifically for the tracker side too.
I literally don't use them at all in my new code, nor are they called anywhere since I removed the BASS16 code entirely.
But for some obscure reason, the simple fact of commenting out the code and initialisation in memory is enough to break the tracker side!
It baffled me since I could already confirm all my code worked perfectly fine in SAP and XEX exports, and the visual player project has been using the same code for some time too.
I simply worked around it for now with a global define, so when FEAT_IS_TRACKER is 1, the extra code is also assembled.
The unused code wasted around 8 bytes, something I really was not able to afford for the MONO player, but I worked around it
So I guess I can now confirm there are indeed 3 different binaries in the program: PLAYER, MONO then STEREO, and so far they all work with that workaround.

So anyway here's a test tune I made during the day, it doesn't look like much, but the automatic handling of 16-bit, and 15khz, really makes the workflow infinitely more comfortable.
This is still being tested and edited, since the stereo support is incomplete, but as far as my testing goes, pretty much everything appears to work correctly

PAL 50hz

Sketch 60 v2.xex

VinsCool · August 31, 2021

Revisited this test tune now that I have the newer 16-bit code mostly functional in RMT Patch 16 Beta5

Finally I can make really phat 16-bit drums and bass

NTSC 60hz, but will run just fine in PAL too.

Phat Phuk v2.obx

VinsCool · September 2, 2021

Something because it's fun right

I like to pretend I can make demoscene-like effects lol

NTSC 60hz, will run in PAL just as well.

A Taste of Frustration.obx A Taste of Frustration.rmt

VinsCool · September 8, 2021

RMT Visualizer is getting pretty nice now

current work in progress rmtplayr code is also integrated to it very nicely

so what works in the tracker works exactly the same in what could be the new export format someday, who knows...

VinsCool · September 10, 2021

Ok that was a lot more frustrating than anticipated but I finally got my 'clear volume bars' code fully working!

At the bottom of the screen, the lighter blue colour (used there for the clear screen stuff) was so heavy before it used to fill the entire VBI area, and even leak at the top of the screen during the next frame!
Next step is naturally the "high pass filter, Join (16-bit and Two-Tone) tiles, using much of a similar approach.

Not shown there yet but I've been busy rewriting the entire graphic code since Monday, it's finally paying off!
I'm getting much better performances and less bloated code, as I still learn how all this stuff works, I can finally get it do what I want
The VBI time wobbles less and less at the top of the screen, and I may be able to improve things a lot more since there are many things that need to be redone.
At this point I've changed the code so much it's hardly the same it was when I started poking at it now

So what I am doing now is rewrite a lot of the routines, and make it so it only draws (or clear) portions of the screen when it is actually necessary.
So far I got most of the 'drawn' stuff optimised pretty loosely, and that was quite a massive improvement already, so there's good amount of hope for even better

VinsCool · September 11, 2021

Fully rewrote most of the graphic routines now!
The performance boost is massive.
This is running with respectable speed and stability in NTSC for first time too!

_The Doctor__ · September 11, 2021

can you load the player with one of your other recent sketches so we can compare? this generic does not sound like your other generic

VinsCool · September 11, 2021

33 minutes ago, _The Doctor__ said:

can you load the player with one of your other recent sketches so we can compare? this generic does not sound like your other generic

Sure I can load a bunch and drop a bunch of binaries in here later if you want.
They will pretty much all play back very nicely now, on par to the RMT Patch version since they use the exact same code.

The only player that will perform a lot better is the LZSS converter, however

VinsCool · September 27, 2021

Wow been a while since I posted in this thread.

Here's a WIP of a cover I am working on using many of the recent RMT patch features I was able to get working.

Having a total control over the AUDCTL with Command 7 simulating an envelope, it becomes seriously powerful in good hands.

Also not so obvious but the .obx is actually my recreation of the .xex export format player, with some of my own changes to make it easier to edit, but overall should behave almost exactly the same

This also uses some of the code from the more graphically appealing Visualizer, but this one isn't yet ready to be released

The tune is currently incomplete but it's on a good start, I thought it was worth sharing since I haven't made much tunes in a while, being mostly busy with either life or learning how to code in 6502 ASM, haha

Personal Jesus WIP.obx

+Stephen · September 27, 2021

7 hours ago, VinsCool said:

Wow been a while since I posted in this thread.

Here's a WIP of a cover I am working on using many of the recent RMT patch features I was able to get working.

Having a total control over the AUDCTL with Command 7 simulating an envelope, it becomes seriously powerful in good hands.

Also not so obvious but the .obx is actually my recreation of the .xex export format player, with some of my own changes to make it easier to edit, but overall should behave almost exactly the same

This also uses some of the code from the more graphically appealing Visualizer, but this one isn't yet ready to be released

The tune is currently incomplete but it's on a good start, I thought it was worth sharing since I haven't made much tunes in a while, being mostly busy with either life or learning how to code in 6502 ASM, haha

Personal Jesus WIP.obx 8.22 kB · 1 download

That's great - will definitely want to hear the final version of this.

Trying to make some PoKEY music!

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation

Recently Browsing 0 members