Question about Sound_Bytes

[roro]

Context:

Im currently work on CMOC 0.1.67 to implement all the missing bios calls to be par with gcc.

Question:
I'm not very experienced in 6809 assembler but so far all is working, except Sound_Bytes.
Whenever I call it, it plays the sound, but after I have an incosistent state in the emulator (Invalid opcode)
I've seen in the gcc implementation, that some registers are added to the clobber list. I don't do that
in my implementation and I think cmoc doesnt event support that? 

Maybe i'm also on the wrong path, but any idea how I can fix this?

My code:

void sound_bytes(const void* sound_block) {
asm {
LDU sound_block
JSR Sound_Bytes
}
}

and the sound:


static const uint8_t hit_sound[] = {0x00,0x00,0x01,0x00,0x02,0xc0,0x03,0x00,0x04,0x00,
0x05,0x00,0x06,0x00,0x07,0x3d,0x08,0x00,0x09,0x1f,
0x0a,0x00,0x0b,0xff,0x0c,0x0c,0x0d,0x00,0xff};


Thanks a lot for any help or info!

[Peer]

Hi there,

I do not know anything about CMOC and its internals, but when I wrote (the several versions of) my gcc6809 interface I found gcc's register clobbering to be the only safe way to ensure that compiler register allocation never ever conflicts with calling the Vectrex BIOS/RUM routines.

In my first version, I explicitly coded all the register saves-and-restores before and after the subroutine calls by hand, and that in general did not work, because gcc (sometimes) uses the stack and/or the U-reg as frame-pointers. It was also bad in terms of performance.

In the next version, once I had understood how the clobbering mechanism works, I switched to using it and managed to solve all my problems that way. Clobbering basically ensures that gcc6809 adds all (and only) the necessary register saves-and-restores, which is good, as only the compiler knows which registers are truly being used by the code and the context surrounding the intended subroutine call.

As I said, I do not know CMOC, and if such information is available there, and if CMOC can do similar things as gcc.

How do you do the saving and restoring of registers which contents are destroyed by the BIOS routines? I cannot think of any way how calling those subroutines can work without doing this before and after the call?

Your sample code set (and thus destroys) the U-reg, and Sound_Bytes() additionally destroys the D-reg and X-reg. There are more routines which do this (destroying U,D and X), e.g. Rot_VL_Mode(). Do those really work for you? Even inside some complicated context code, which also uses those registers? Meaning, are you sure that your problem is related to Sound_Bytes() only?

Cheers,
Peer

[D-Type]

I looked it my Forth to BIOS interface and I found the same as Peer, sound_bytes is quite different to the other sound routines in that it trashes the U register, I stash it before calling the routine. The print string routines are similar.

Note, there are a few bugs in the alternative documentation of the BIOS routines. I found some of these by looking at the BIOS code and some by cross referencing the alternative docs to the official GCE RUM documentation.

My BIOS/RUM cross-ref Excel in the Vfu file area includes the corrections.

[roro]

Hi Peer,
thanks for the detailed feedback.
Im so stupid... I forget that after searching all night for an issue in the sound buffer itself

After restoring the registers in sound_bytes (PULS) it works now 🙈.
That's the typical "Don't see the tree in the woods" problem.
Because in all other calls I've done this....

Of course I now also have to verify what that means performance wise.


Thanks for giving my the hint in the right direction
Cheers,
Roger

[roro]

Dec 9, 2020 7:15:30 GMT -5 D-Type said:

I looked it my Forth to BIOS interface and I found the same as Peer, sound_bytes is quite different to the other sound routines in that it trashes the U register, I stash it before calling the routine. The print string routines are similar.

Note, there are a few bugs in the alternative documentation of the BIOS routines. I found some of these by looking at the BIOS code and some by cross referencing the alternative docs to the official GCE RUM documentation.

My BIOS/RUM cross-ref Excel in the Vfu file area includes the corrections.

Yes I realised now what was going wrong, thanks for the feedback! But at least it's great to learn and understand better the Vectrex bios