Can you help me with ASM?

[Sergioz82]

33 minutes ago, Asmusr said:

I think you need to store it in >83D4 and not >83DA.

 

http://www.unige.ch/medecine/nouspikel/ti99/ints.htm#blank

 

It works! 

Thank you very much!

 

In my defense, Compute!'s was really confident it was 83DA. 

 

[Sergioz82]

Hello! Some updates on the game.

I have to say i'm pretty satisfied about the results.

 

First of all, a big thanks to everyone for the support, I probably wouldn't have made so much progress in this short time without your help.

 

The game as you can see is almost complete. Some polishing here and there but I save it for the end.

Now I have to face the part I fear the most: sounds.

I already tried implementing one sound (pill eat) made with Mod2PSG2 and converted to raw bytes with Tursi's tools. It kinda works  through ISR but it makes the game unplayable because it halts the LIMI2 - LIMI0 loop until the sound is over. 

For what I understood I must feed the sound directly to the PSG @>8400 but this implies writing a "player" routine, is this correct?

 

So, about the game, it's a Pacman game, mine will be called Spac Man (Italian word Spac-care - to break/smash - plus man).

The twist is given by the big question mark at the center of the maze. When Spac man passes over it it gives the player a random bonus or a penalty.

 

EDIT: I noticed that 480p resolution doesn't show the correct animation, it looks like Spac Man randomly opens and closes the mouth. Please set video quality to at least 720p60 to fully enjoy the majestic animation 

 

In the videos you'll see some of them:

Boots (lots of them ) - Because everybody know that the best way to shoo a ghost is to throw a boot at him (well, not really.. but I liked the idea)!  They're sturdy and they come in pairs.

Boom! - Boots don't work? Try bombs!

Trap -  Dealing with three ghosts is always better than dealing with four

Energizer - Eat em all the old way. Because traditions are important! 

Madness! - Never make a ghost blood red.

Ice walls - I don't know how Pacman people actually move, but they lose grip when the walls are icy.

 

 

 

 

 

Edited October 12, 2022 by Sergioz82
Suggestion about playing videos at 720p60 quality

[+9640News]

Very nice work.  Very nice!!!

[Asmusr]

8 hours ago, Sergioz82 said:

Now I have to face the part I fear the most: sounds.

I already tried implementing one sound (pill eat) made with Mod2PSG2 and converted to raw bytes with Tursi's tools. It kinda works  through ISR but it makes the game unplayable because it halts the LIMI2 - LIMI0 loop until the sound is over. 

For what I understood I must feed the sound directly to the PSG @>8400 but this implies writing a "player" routine, is this correct?

You have many alternatives to writing your own sound player, for instance the standard sound list player in the ISR, which is described in the E/A manual. In any case you will need to call a player periodically rather than waiting for a sound to finish, since that would break up the game play.  The resources thread lists a number of tools for creating and playing sound.

[Sergioz82]

9 hours ago, 9640News said:

Very nice work.  Very nice!!!

Thank you! 

[Sergioz82]

1 hour ago, Asmusr said:

You have many alternatives to writing your own sound player, for instance the standard sound list player in the ISR, which is described in the E/A manual. In any case you will need to call a player periodically rather than waiting for a sound to finish, since that would break up the game play.  The resources thread lists a number of tools for creating and playing sound.

I'll check the thread. To me sound implementation looks almost like a programming language on its own 

Just one question: which solution do you think is better in terms of audio quality and execution speed? ISR or direct access? 

[Asmusr]

8 hours ago, Sergioz82 said:

I'll check the thread. To me sound implementation looks almost like a programming language on its own 

Just one question: which solution do you think is better in terms of audio quality and execution speed? ISR or direct access? 

If by 'direct access' you mean writing bytes directly to >8400 without any player or format, I think that would quickly become a mess.

 

If you're already enabling interrupts periodically, I think you should try the ISR sound player. You can use my Sound list ripper to rip some sounds from other games to get you started. Or maybe somebody could post a few sample sounds here?

All you then need to do, is to place the address of the sound list in >83CC and the byte 1 in >83CE to start the sound.

 

 

The sound list format is not compressed at all, so if you want to play long, advanced tunes you should look at Tursi's VGM tools. But for a few sound effects and a bit of music, the ISR player and the sound list format should be fine.

 

Edited October 12, 2022 by Asmusr

[+TheBF]

1 hour ago, Asmusr said:

If by 'direct access' you mean writing bytes directly to >8400 without any player or format, I think that would quickly become a mess.

It can be done but it helps to abstract things into small routines. 

I am doing this in Forth, but one could do this in assembler with sub-routine creation and usage.

 

I have DB to set the volume, HZ to set the frequency (which calls FCODE to convert frequency to 9919 code)  MS to set the duration and MUTE.

( I should add that I use 16->32bit division to compute sound frequency value from the 9919 clock frequency but a table would be faster if you don't need every possible frequency)

 

The arguments for DB and HZ are ORed with the correct value to select the sound generator you want to use before you call them.

 

ON the surface you have the same problems as BASIC SOUND() but... because it is factored into pieces you can start a sound with DB and HZ and use the running code and a some carefully placed short delays to get the timing right before you call MUTE.

That's ok for a sound effect but not great for music.

 

I have toyed with code that moves the duration control to the VDP interrupt so that the program runs while the ISR is counting down a timer for each sound generator.

The ISR BLWPs to a new workspace that holds all the time values for each sound generator. The ISR continuously decrements the timers and when they hit zero they mute their respective channel.

Way less overhead in the ISR than playing the entire list I think.

 

Have not played with the ISR idea for a long time but i think I had working code. Now I have to dig it up.  

 

I know very few people want to use Forth but here is the code to control the 9919 without the interrupt duration part.

I should add that using a system like this to make complex sounds seems to use less space than sound lists because things like envelope control (volume) are sub-routine code loops not long data lists.

 

My 2 cents CAD  (1.4 cents USD)  

 

\ TMS9919 SOUND CHIP DRIVER and CONTROL LEXICON     Jan 2017 BJF
\ TMS9919 is a memory mapped device on the TI-99 @ >8400
\ SND! is in the CAMEL99 Kernel as  : SND!     8400 C! ;

\ frequency code must be ORed with these numbers to create a sound
HEX
  8000 CONSTANT OSC1      A000 CONSTANT OSC2   ( oscillators take 2 nibbles)
  C000 CONSTANT OSC3        E0 CONSTANT OSC4   ( noise takes 1 nibble)

\ Attenuation values are ORed with these values to change volume
( 0= max, 15 = off)
    90 CONSTANT ATT1         B0 CONSTANT ATT2
    D0 CONSTANT ATT3         F0 CONSTANT ATT4  ( OSC4 volume adjust)

\ f(clk) for sound chip is 111,860.8 Hz.
\ we round it up to 111,861 Hz. Seems to work ok.
DECIMAL
\ create a 32bit variable from primitives
0 0  S" 111861" >NUMBER 2DROP CREATE (CLK)  ,  ,

: f(clk) ( -- d)  (CLK) 2@  ;  \ fetch the clk variable, 32 bit integer

\ >FCODE re-arranges freq. value nibbles (4bits) for the TMS9919
HEX
 CODE >FCODE ( 0abc -- 0cab) \ version by Farmer Potato Atariage
           0B44 , \ TOS 4 SRC,    \ C0AB
           C204 , \ TOS W MOV,    \ DUP
           0948 , \  W 4 SRL,     \ 0C0A
           D108 , \  W TOS MOVB,  \ 0CAB
           NEXT,   \ 8 BYTES, 28 uS :-)
           ENDCODE

\ we set the "ACTIVE CHANNEL" with these variables
 VARIABLE OSC               \ holds the active OSC value
 VARIABLE ATT               \ holds the active ATTENUATOR value

\ convert freq. to 9919 chip code
DECIMAL
: HZ>CODE  ( freq -- fcode ) f(clk) ROT UM/MOD NIP >FCODE ;

HEX
\ **for testing**  print sound data to screen AND make sound
\ : SND!  ( c -- )  ." >"  BASE @ >R  HEX DUP U. 8400 C! R> BASE ! ;

\ Set the sound "GENerator that is active.
: GEN! ( osc att -- )  ATT !  OSC ! ;

\ ================================================================
\ S C I E N T I F I C   S O U N D   C O N T R O L   L E X I C O N
\ sound generator selectors
: GEN1    ( -- )  OSC1  ATT1  GEN! ;
: GEN2    ( -- )  OSC2  ATT2  GEN! ;
: GEN3    ( -- )  OSC3  ATT3  GEN! ;
: GEN4    ( -- )  OSC4  ATT4  GEN! ;

HEX
: NOISE   ( n -- ) 0F AND  GEN4  OSC @ OR  SND! ;

: (HZ)    ( f -- n)   HZ>CODE  OSC @ OR  ;          \ convert freq. add OSC
: (DB)    ( level -- c)  ABS 2/  0F MIN  ATT @ OR ; \ DB to attenuation

: HZ      ( f -- ) (HZ) SPLIT SND!  SND! ;
: DB      ( level -- ) (DB)  SND! ; \ Usage: -6 DB
: MUTE    ( -- )  -30 DB ;
: SILENT  ( --)  9F SND!  BF SND!  DF SND!  FF SND! ;

 

[+TheBF]

Addendum to ISR duration control:

 

I found my old code and it works (uses an array of timers rather than a workspace) but the experienced hands here no doubt saw the flaw in the concept.

 

It works fine for one blast of sound that runs in the background.

 

To be practical the routine that feeds the 8400 needs be through a queue so you can stuff a bunch of commands at it and go away.

The ISR needs to read the queue as well as decrement the timers so it becomes a new sound player.  Wow! I re-invented the wheel.  

 

I have a sub-routine that feeds a byte to the 8400 so in theory if it became queue feeder and the ISR took bytes from the queue it might work... 

[Sergioz82]

4 hours ago, Asmusr said:

If by 'direct access' you mean writing bytes directly to >8400 without any player or format, I think that would quickly become a mess.

 

If you're already enabling interrupts periodically, I think you should try the ISR sound player. You can use my Sound list ripper to rip some sounds from other games to get you started. Or maybe somebody could post a few sample sounds here?

All you then need to do, is to place the address of the sound list in >83CC and the byte 1 in >83CE to start the sound.

 

 

The sound list format is not compressed at all, so if you want to play long, advanced tunes you should look at Tursi's VGM tools. But for a few sound effects and a bit of music, the ISR player and the sound list format should be fine.

 

I meant writing a player to send bytes to PSG through >8400 vs. writing a player that works with ISR and >83CC + >83CE.

First I wrote a simple player (basically the code example in Compute!'s but with a sound of mine) and it worked. I implemented it in Spac man and as suggested in the manual I looped around LIMI 2 - LIMI 0 as long as value in >83CE was not zero but that way the game of course hanged to execute the whole sound first (a short one for eating the pills, similar to the classic "collect coins" trilling sound).

 

I made the sound by messing with Mod2Psg2 program. I created one instrument and then exported a single C-4 note in vgm format. Then  used the VgmComp2 suite to convert the sound in raw bytes. I don't know if it's the right method but it worked

The ripper however looks like a good way to learn how to make better sounds. I'm going to download it.

 

 

 

[Tursi]

My toolset isn't really intended for generating sound lists, but if it's working for you all the power to you!

 

That said, don't loop until >83CE is 0. In fact, using the console ISR (as it looks like you are), all you have to do is start it and then make sure you call LIMI 2/LIMI 0 regularly. You don't need to check >83CE again unless you care when the sound is finished, which for a sound effect in a game, you really don't. Just start the sound and then keep running the game.

 

[Tursi]

For what it's worth, I have also adapted a sound effect generator to make sounds for the TI/Coleco : https://harmlesslion.com/sn_sfxr/

 

The download is a VGM... using the VGMcomp2 toolchain you can convert it to the TI's soundlist format with vgm_psg2psg, followed by psg2soundlist on the intermediate file.

 

[Sergioz82]

15 hours ago, Tursi said:

My toolset isn't really intended for generating sound lists, but if it's working for you all the power to you!

 

That said, don't loop until >83CE is 0. In fact, using the console ISR (as it looks like you are), all you have to do is start it and then make sure you call LIMI 2/LIMI 0 regularly. You don't need to check >83CE again unless you care when the sound is finished, which for a sound effect in a game, you really don't. Just start the sound and then keep running the game.

 

 

I tried but if I don't loop the sound gets corrupted: it doesn't play at all and after some seconds I hear a constant tone that doesn't go away and I have to reset the TI (Classic99 to be precise but I think it makes no difference).

My player is the simplest I could make to understand how it works (please see code below).

In the game it goes like this:

1) During general initialization of the game load the sound list in VDP and SOCB H01,@>83FD to tell PSG sound table is in VDP

2) in the Pacman movement routine at "eat pill" case I BL @PLAYSN 

3) last routine in game loop is "UPDVDP" where I update sprite attribute list and I enable interrupts with LIMI 2 - LIMI 0

 

 

My idea was to have a cut off sound during the costant pill eating and hearing it completely after the last pill before the "pill free" area of the maze. To give the idea I'd like it to sound the same of "collecting items at fast pace" you hear in many games. 

I don't know if it will be the definitive sound but I'd like to try it.

 

SNDLOC EQU >1302 *1000-1300 White screen for bomb effect                                       
SNADDR EQU >83CC                                                                
SNBGIN EQU >83CE                                                                
SNVRAM EQU >83FD                                                                
                                                                                
LOADSN LI R0,SNDLOC                              *       I BL to this routine after graphics initialization and before the game loop                    
       LI R1,SNDPLL                                                             
       LI R2,76                                                                 
       BLWP @VMBW                                                               
       SOCB @H01,@SNVRAM                                                        
       RT                                                                       
                                                                                
PLAYSN LI R0,SNDLOC                           * I BL to this routine in Pacman movement after I read that character below the sprite equals to a pill and must be replaced with a blank space.                                  
       MOV R0,@SNADDR                                                                                                           
       MOVB @H01,@SNBGIN                                                        
       RT                                                                       
                                                                                
*Eat Pill 76 BYTES                                                         
SNDPLL BYTE >03,>90,>82,>0E,>01,>03,>98,>89                                     
       BYTE >0F,>01,>01,>91,>01,>03,>99,>82                                     
       BYTE >0E,>01,>03,>92,>8A,>0C,>01,>03                                     
       BYTE >9A,>83,>0B,>01,>01,>93,>01,>03                                     
       BYTE >9B,>8A,>0C,>01,>03,>94,>82,>0E                                     
       BYTE >01,>03,>9C,>89,>0F,>01,>01,>95                                     
       BYTE >01,>03,>9D,>82,>0E,>01,>03,>96                                     
       BYTE >8A,>0C,>01,>03,>9E,>83,>0B,>01                                     
       BYTE >01,>97,>01,>01,>9F,>11,>04,>9F                                     
       BYTE >BF,>DF,>FF,>00 

 

 

 

 

 

[Sergioz82]

16 hours ago, Tursi said:

For what it's worth, I have also adapted a sound effect generator to make sounds for the TI/Coleco : https://harmlesslion.com/sn_sfxr/

 

The download is a VGM... using the VGMcomp2 toolchain you can convert it to the TI's soundlist format with vgm_psg2psg, followed by psg2soundlist on the intermediate file.

 

Thanks a lot, I'll try your sound effects generator.

 

I already used your very useful toolchain to create the pill sound, but starting from Mod2Psg2.

A note about this: since I was messing around I decided to create a "bonus plate" sound through the tracker. A basic metallic sound using noise generator mid and high noises that I placed as "song" and then exported to VGM. 

I get the "bonusplate.vgm_noi00.60hz" but when I launch psg2soundlist it doesn't create the soundlist.

 

On the other hand, with the pill sound (only one tone) the chain worked perfectly. 

I also used bin2inc then made some search&replace to quickly transform the output in E/A 5 syntax.

[Asmusr]

You could try to place a breakpoint in the sound player at >09f2 to see if it gets called. Also watch your sound list in VDP RAM to see if it becomes corrupted.

[Sergioz82]

13 hours ago, Asmusr said:

You could try to place a breakpoint in the sound player at >09f2 to see if it gets called. Also watch your sound list in VDP RAM to see if it becomes corrupted.

I tried it.

09F2 is called later when sound goes nuts but not as I expected @PLAYSN call.

Data in VDP seem ok, they don't get corrupted.

 

I'm at work right now so I can't test more, I'll try later.

 

 

[+FarmerPotato]

Examining your code to see what I can see:

 

It sounds like the ISR is not following your sound list. I checked your list and the length and duration bytes all make sense, so it’s not off the rails. 
 

1. Why 1302? If you made a screen image table from 1000 to 12FF your sound list can start at 1300

 

Im worried that your assembler may interpret

 

SNDLOC EQU >1302 *1000-1300

 

as one equation. If so, the sound player is way off the rails! 

See if that is the issue!

 

You can use the List option of the assembler to check the value of SNDLOC. List is your friend. 
 

The TI assembler stops parsing the value at a space , so the * begins a comment. Star is optional for an end of line (trailing) comment, but it says “comment” to readers. Good idea to start  trailing comments with text:

 

SNDLOC EQU >1302 After the screen at 1000-1300

I think Ralph’s xas99 is greedy and keeps parsing after a white space. You can use the strict option to make it work only like TI’s assembler. 
 

I think that TI’s assembler does operations left to right only , other assemblers may use precedence of operators! So

 

EQU BUFRS+10*BUFSZ 

 

could be ambiguous. use parentheses if your assembler allows!

 

EQU BUFRS+(10*BUFSZ)

 

(This is a gotcha in the GeneveOS source which has something like that in one place, with a *256. GenAsm != xas99 there) 

 

 

 

 

2. One good practice is to calculate lengths of lists, not hard code them. 
Instead of 

 

LI R2,76            

                            

Let the assembler calculate it for you. Write:

LI R2,SNDPL#                                        

and

 

SNDPLL BYTE …

…

SNDPL# EQU $-SNDPLL

 

3. This is a crazy trick that probably doesn’t gain you anything but:

 

PLSND

 LWPI >83C0 aka INTWS

 LI R6,SNDLOC This R6 is 83CC

 MOVB @H01,R7 This R7 is 83CE. 

* alternately MOVB @H01,R7

LWPI MYWS get back to mine

 

Another way to borrow INTWS is:

 

INTWS EQU >83C0

PLSND DATA INTWS,PLSND1

PLSND1 MOV *R13,R6 the callers R0 to 83CC

 MOVB @H01,R7

 RTWP

Call it with : 

 LI R0,SNDLOC

 BLWP @PLSND

This clobbers the workspace R13-15 so make sure interrupts are OFF. I dunno if thats ok, but presumably they get clobbered every 1/60th second so…

 

As I said, crazy tricks, better to leave them be. 

 

 

 

 

 

[Asmusr]

44 minutes ago, FarmerPotato said:

m worried that your assembler may interpret

 

SNDLOC EQU >1302 *1000-1300

 

as one equation. If so, the sound player is way off the rails! 

Well spotted, that's probably it. I always use a semicolon to mark the start of an inline comment, and tab it to position 40.

[Sergioz82]

2 hours ago, FarmerPotato said:

Examining your code to see what I can see:

 

It sounds like the ISR is not following your sound list. I checked your list and the length and duration bytes all make sense, so it’s not off the rails. 
 

1. Why 1302? If you made a screen image table from 1000 to 12FF your sound list can start at 1300

 

Im worried that your assembler may interpret

 

SNDLOC EQU >1302 *1000-1300

 

as one equation. If so, the sound player is way off the rails! 

See if that is the issue!

 

You can use the List option of the assembler to check the value of SNDLOC. List is your friend. 
 

The TI assembler stops parsing the value at a space , so the * begins a comment. Star is optional for an end of line (trailing) comment, but it says “comment” to readers. Good idea to start  trailing comments with text:

 

SNDLOC EQU >1302 After the screen at 1000-1300

I think Ralph’s xas99 is greedy and keeps parsing after a white space. You can use the strict option to make it work only like TI’s assembler. 
 

I think that TI’s assembler does operations left to right only , other assemblers may use precedence of operators! So

 

EQU BUFRS+10*BUFSZ 

 

could be ambiguous. use parentheses if your assembler allows!

 

EQU BUFRS+(10*BUFSZ)

 

(This is a gotcha in the GeneveOS source which has something like that in one place, with a *256. GenAsm != xas99 there) 

 

 

 

 

2. One good practice is to calculate lengths of lists, not hard code them. 
Instead of 

 

LI R2,76            

                            

Let the assembler calculate it for you. Write:

LI R2,SNDPL#                                        

and

 

SNDPLL BYTE …

…

SNDPL# EQU $-SNDPLL

 

3. This is a crazy trick that probably doesn’t gain you anything but:

 

PLSND

 LWPI >83C0 aka INTWS

 LI R6,SNDLOC This R6 is 83CC

 MOVB @H01,R7 This R7 is 83CE. 

* alternately MOVB @H01,R7

LWPI MYWS get back to mine

 

Another way to borrow INTWS is:

 

INTWS EQU >83C0

PLSND DATA INTWS,PLSND1

PLSND1 MOV *R13,R6 the callers R0 to 83CC

 MOVB @H01,R7

 RTWP

Call it with : 

 LI R0,SNDLOC

 BLWP @PLSND

This clobbers the workspace R13-15 so make sure interrupts are OFF. I dunno if thats ok, but presumably they get clobbered every 1/60th second so…

 

As I said, crazy tricks, better to leave them be. 

 

 

 

 

 

 

I removed the comment at SNDLOC EQU >1302 but unfortunately the problem persists.

About why I used 1302.. I made a mistake I had >300 in mind so I just added it to >1000. I set sound list address to >1300 now.

 

With Classic99 I noticed  that address @>83CC changes on its own.. is it supposed to happen? Address becomes >1305 but I don't do any further manipulation, all I do is moving the address in R0 to>83CC in PLAYSN routine.. 

Below you can see the moment >83CC gets modified.  I don't know what routine I'm looking at. A system routine I suppose..

 

 

 

About your other suggestions I use Editor/Assembler and I'm not sure it can use parenthesis.

I'll definitely use lenght calculation when I'll add other sounds, that's a neat solution.

Third suggestion is a "very assemly" trick.. mapping registers on addresses.. I'm intrigued. However first I have to make this damn thing play

 

 

[matthew180]

You might be interested in this thread:

 

 

The code can be easily used in an assembly program (as opposed to being called from XB), and provides a more flexible/enhanced sound-list player inspired by the console ROM sound list player.

 

[+Lee Stewart]

7 hours ago, Sergioz82 said:

With Classic99 I noticed  that address @>83CC changes on its own.. is it supposed to happen? Address becomes >1305 but I don't do any further manipulation, all I do is moving the address in R0 to>83CC in PLAYSN routine.. 

Below you can see the moment >83CC gets modified.  I don't know what routine I'm looking at. A system routine I suppose..

 

The code you were viewing is, indeed, a system routine. It is part of the sound player in the console ROM. You should see >83CC change because the sound player walks the VRAM sound table by changing >83CC as it reads and plays each sound list in the table.

 

...lee

[Sergioz82]

An update: 

I switched to "Munch man solution": I noticed they disable interrupts only inside their V*BR,V*BW routines: LIMI 0 when they communicate with VDP then LIMI 2 before RT instruction. In sound routine instead there's only LIMI 2 before RT.

In short they disable interrupts only in the moment there's an actual communication with VDP.

 

This way my sound now is played, however there's another problem: after it played once the game hangs. The problem is caused by the routine that waits for vertical synchronization, it gets stuck at TB 2 returning 0. If I set CPU Overdrive in Classic 99 it works (slowly) and in the debugger I get a wall of "Reading VDP with LIMI 2" ad RT address. The culprit I assume is MOVB @VDPSTA,R12

 

WVDP   CLR R12                                                                  
       TB 2                                                                     
       JEQ WVDP                                                                 
       MOVB @VDPSTA,R12                                                         
       RT  

 

My first try was of course to add LIMI 0 as first instruction and LIMI 2 before RT but now sound is played badly once then completely disappears.. 

 

At least I can affirm that one LIMI 2 - LIMI 0 call each game loop isn't enough to play the sound. Is this correct?

 

 

10 hours ago, matthew180 said:

You might be interested in this thread:

 

 

The code can be easily used in an assembly program (as opposed to being called from XB), and provides a more flexible/enhanced sound-list player inspired by the console ROM sound list player.

 

Thank you. I had a quick read and I find it interesting.

At the moment I need to understand how basic sound generation works, that is, why mine does not and what I'm doing wrong.. then I can explore better solutions like yours.

 

 

[Asmusr]

Maybe put LIMI 2/LIMI 0 before MOVB @VDPSTA,R12? When you clear the VDP status I don't think the ISR will execute.

[Sergioz82]

2 hours ago, Asmusr said:

Maybe put LIMI 2/LIMI 0 before MOVB @VDPSTA,R12? When you clear the VDP status I don't think the ISR will execute.

I tried but still freezes the game

 

The good news is that I finally made it work: 

 

-  "Munch man solution" with LIMI 0 - LIMI 2 for my VSBR e V*BW routines but no LIMI 2 in PLAYSN routine (it "saturates" the sound after a while)

-  Replaced WVDP routine with a simple delay loop

 

This way the sound is fine.

 

The bad news is that without waiting for VSYNC I get glitches during the sprite position swapping in VDP attribute list to overcome the 4 sprites per row limit.. 

 

Just for trying, disabling the swapping makes the game work fine except of course the sprites limit. 

 

 

 

 

 

 

 

[+FarmerPotato]

I see, I had never imagined the situation where you want the console to do interrupt handling , but also wait on VDPSTA yourself. 
 

VDP is not the only interrupt source which the console has to handle. Therefore it tries to identify the source. Your loop read VDPSTA (clears the interrupt so TB 2 is clear)  so the console thinks it can’t be VDP , and doesn’t advance the sound list. 

 

If you leave VDPSTA alone, the console routine will act. 
 

I think you could do this:

 

LIMI 0

… everything else

* wait for VSYNC:

TB 2

JNE $-2 really tight loop

* VDP interrupt has now arrived

* leave VDPSTA alone!

* do your screen updates

LIMI 2  now console handles  the interrupt

 

My preference is to leave interrupts off mostly. You never know when you might get smacked otherwise. 
 

For instance, if you were updating 83CC and 83CE you want to eliminate the risk of interrupt happening in between. (seems harmless though)