Assembly on the 99/4A

[Airshack]

18 hours ago, apersson850 said:

Yes, I was mainly referring to the VDP setup. But if you rely on the EA support routines, you have to manage them too.

As per recommendations on this thread (for game speed), I’m avoiding interrupts and rolling my own in lieu of the EA support routines, in order to preserve the integrity of the scratchpad RAM. 

[Airshack]

On 6/26/2020 at 2:41 AM, GDMike said:

On 6/26/2020 at 12:02 AM, Tursi said:

So when you BLWP @VSBW, for instance, there IS no VSBW, and you jump off to empty code and crash

As per this threads recommendations I’m rolling my own VSBW routine but not BLWP.

[Airshack]

On 6/26/2020 at 12:02 AM, Tursi said:

easy fix is just to load the EA routines as an extra source file, so you have (for instance) your three program files plus one to low RAM for the utilities. There are a few copies of a pre-made file for that floating around the forums

Looks promising! I’ll search for this approach sample.

[Airshack]

On 6/26/2020 at 12:02 AM, Tursi said:

Make sure your program sets every register in the VDP and initializes any memory it uses to appropriate values (ie: don't assume they are zero).

I have placed the registers into the pad at >8300 and zeroized everything with my One Time Init routine. Is this what you suggest?

[apersson850]

I'd rather say it's a rule for all memory you use. Set it to what it should be at startup, if that's important. In some cases, you don't need memory to contain any specific data to begin with, since that will be given as the program runs. But if you have a score you just increment at certain times, you have to set it to zero to begin with, to avoid having a random starting value.

But if you load a counter with 5, to set the number of retries a player has, then you don't need to zero it first. You aren't going to use the value zero anyway, but start from five.

VDP registers are special locations inside the video processor. They define how the VDP will use VDP RAM, and some other settings. They must be set up to conform with what your program expects. Here the caveat is that if you make a program that runs when started via Load and run from E/A, you get a certain VDP register configuration from E/A. But if the same program is started from another module/program, then the VDP configuration can be different. If you don't set it yourself, then your program will work when started from one loader, but not from another.

[HOME AUTOMATION]

On 6/25/2020 at 5:23 PM, Airshack said:

I got all excited when I used EA Option-5 to launch DSK4.ENKA. Everything ran as expected via the EA Option-5 Prompt. 

 

Upon restarting Classic99 and re-selecting EA Option-5, the program launched but seemed to be graphically distorted and didn't seem to run properly. 

 

Here's how it should look upon launch:

 

 

 

 

 

 

 

Here's how it looks after I reset Classic99 and selected EA Option-5, entered DSK4.ENKA, then pressed enter.

 

 

 

 

 

Is it possible EA5 is only launching the first 8K segment named "DSK4.ENKA?"

 

The program is non-responsive and just hangs. Strange because it runs fine via the EA5 option immediately after using the SAVE program. Only after resetting Classic99 will EA5 with Option-5 result in the black screen of death above?

EA3 vs. EA5, may also use a different WS, not sure.

 

I would... run both versions to the point where the above conditions result...  than open a debugger, and  check for differences in WS, VDP registers, CHARACTER/COLOR tables.

[Airshack]

9 hours ago, HOME AUTOMATION said:

I would... run both versions to the point where the above conditions result...  than open a debugger, and  check for differences in WS, VDP registers,

I will give this a try.

[Airshack]

16 hours ago, apersson850 said:

Set it to what it should be at startup, if that's important. In some cases, you don't need memory to contain any specific data to begin with, since that will be given as the program runs. But if you have a score you just increment at certain times, you have to set it to zero to begin with, to avoid having a random starting value.

But if you load a counter with 5, to set the number of retries a player has, then you don't need to zero it first. You aren't going to use the value zero anyway, but start from five.

Thank you. This much I do understand. 

 

 

[Airshack]

16 hours ago, apersson850 said:

VDP registers are special locations inside the video processor. They define how the VDP will use VDP RAM, and some other settings. They must be set up to conform with what your program expects.

I am with you 100% here. Well aware of this much. I had to study up on this topic in order to get my game started some time ago.

 

 

16 hours ago, apersson850 said:

f you make a program that runs when started via Load and run from E/A, you get a certain VDP register configuration from E/A. But if the same program is started from another module/program, then the VDP configuration can be different. If you don't set it yourself, then your program will work when sta

   I want to believe we’re honing in on MY problem now! Your patience is appreciated by looks like I need feedback on my own VDP register configuration? 

 

  What I do have in my code is a routine called GMODE which sets the VDP registers.

 

   Here’s my data I used to feed into GMODE:

 

* VDP GRAPHICS MODE DATA for VDP Write Only Registers #0-7
*                   - Eight 16-bit words
*                   - MSB = VDP Register # (0-7)
*                   - LSB = mode descriptors

* VDP Register 0 = Bitmap Mode OFF
GMDATA DATA >0000             * M3 is bit 6 and is off for Graphics I
*                                - VDP register-0: bit 6 = "M3" Mode bit 3
*                                - M3 = 1 for bit map mode, 7o otherwise

* VDP Register 1 = Memory, Screen and Graphics Mode Setup
       DATA >01E2             * VDP register-1:
*                                   bit0=1, 16K VRAM not 4K,
*                                   bit1=1, screen on not blanked;
*                                   bit2=1, enable VDP interrupt);
*                                   bit3=0, not text mode, "M1" bit;
*                                   bit4=0, not multicolor mode, "M2";
*                                   bit5=0, reserved always zero;
*                                   bit6=1, double sprite size;
*                                   bit7=0, unmagnified sprites.
*                                      - default >E0 in: E/A, BASIC, XB

* VDP Register 2 = Screen Image Table base = >0000 (in VDP memory)
       DATA >0200             * 00 = Screen Image Table range >0000 - >02FF (768 bytes)
*                                   Zeros = Screen Image Table base at >0000
*                                   otherwise address at LSN value times >400
*                                      - default >00 for E/A, BASIC, and XB

* VDP Register 3 = Color Table base = >0380
       DATA >030C             * 0C= Color Table to >0380 - >>03FF (32 bytes)
*                                   >OE * >40 = >380  (the E/A default, p.327)
*                                   >0C * >40 = >300 (TI BASIC default)
*                                   >20 * >40 = >800 (XB default)

* VDP Register 4 = Pattern Descriptor Table base = >2000
       DATA >0404             * 04 =Pattern Descriptor Table >2000 - >27FF (2048)
*                                   >01 * >800 = >800 (E/A default= >01)
*                                   >00 is default for TI BASIC and XB

* VDP Register 5 = Sprite Attribute List base = >0300
       DATA >0507             * 07 = Sprite Attribute List  >0380 - >03FF (128)
*                                   >06 * >80 = >300 (default in E/A, B, XB)

* VDP Register 6 = Sprite Pattern Table base = >2800
       DATA >0605             * 05 =Sprite Pattern Table >2800 - >3000 (2048)
*                                   >05 * >800 = >2800 (default >00)

* VDP Register 7 = Screen Color Information
       DATA >07F1             * F3 = Text color and background (border) color
*                                   bits 4-7 = F = white foreground N/A, text mode only, INOP!
*                                   bits 0-3 = 1 = Black background, ALL modes

 

 

Here's the GMODE routine I'm using to read the GMDATA and initialize the VDP Registers:

 

*********************************************************************
*
* GMODE: Set up the VDP registers and disable all sprites,
*         and set character colors to white on dark blue
*
*                             * Bit value 128 64 32 16  8  4  2  1
*                             * Bit order   0  1  2  3  4  5  6  7

GMODE
       MOV  R11,*R10+         * Push return address onto the stack

       LI   R1,GMDATA
       LI   R2,8
GMODE1 MOV  *R1+,R0
       BL   @VWTR
       DEC  R2
       JNE  GMODE1

*      Disable all sprites until ready to use them.
       LI   R0,SPPCTB         * Disable all sprites
       LI   R1,>D000          * >D0 (208) to the vertical positions
*                                Vert position = 1st byte in Sprite Atribute Table
*                                We're writing >D0 to ALL bytes in the table out of laziness
       LI   R2,128            * 32 sprites, 4 bytes each entry
       BL   @VSMW             * writes >D0 128 times;  ALL Sprites killed now!



*      Set colors to an initial setting of White on Dk Blue; this gets changed immediately, not needed
       LI   R0,COLRTB         * Start of color table
       LI   R1,>F400          * White on dark blue
       LI   R2,>0200          * All color table entries (32 bytes)
       BL   @VSMW             * set ALL sprites tothe same colors

       DECT R10               * Pop return address off the stack
       MOV  *R10,R11
       B    *R11
*// GMODE

Perhaps this will reveal some obvious shortcomings and/or problems?   
 

   

[HOME AUTOMATION]

1 hour ago, Airshack said:

BL @VSMW

Hmm, you may be right!

 

VDP SINGLE MULTI WRITE???

 

also, should that be BLWP vs. BL?

 

or did you roll these yourself?

 

The comparison of the two screens reminds me very much of what happened here...

 

 

Edited June 29, 2020 by HOME AUTOMATION

[Airshack]

I rolled my own (after stealing them from Matthew180) as per the conclusions drawn earlier in this thread regarding: game speed, efficiency, and scratchpad integrity. 

 

from earlier posts...

 

”

First notice that there are no REF statements for the normal VDP routines. This is because I don't like using the console based routines for a couple of reasons:

 

1. They are slow since they were designed to save ROM space instead of being fast to execute

2. They use BLWP which is slow and designed primarily for context switching in a multi-tasking system like TI's mini computers where the TMS9900 CPU was designed to be used

3. The routines use a workspace in 8-bit RAM! This in of itself should be a sin!

 

Also, I don't like to use the GLP routines because they require a workspace pointer in the 256 bytes of scratch pad RAM. Since there is only 256 bytes of 16-bit RAM in the machine, it is highly prized memory and I don't like some other console routines chewing up 32 bytes of that RAM. Anyway, the VDP routines provided in the E/A cartridge are slow, slow, and slow, and I'm a speed freak.”

 

   - Matthew 1:80

[Airshack]

2 hours ago, HOME AUTOMATION said:

VDP SINGLE MULTI WRITE???

Correct. Safe to assume my VDP registers are not the issue then?

[senior_falcon]

It seems likely, but there is no reason to assume. You should run this in Classic 99. Use the debugger to look at the VDP registers when running in EA3 and when running in EA5 to see if they are the same.

[+Lee Stewart]

Without seeing the relevant code, I am flying blind here. A couple of obvious things you probably already have covered:

• Be sure interrupts are off whenever you write anything to the VDP.
• If you use the console’s KSCAN anywhere in your program for input, be sure you write the value for VR01 to >83D4 before writing it to VR01.

...lee

[Airshack]

21 minutes ago, senior_falcon said:

It seems likely, but there is no reason to assume. You should run this in Classic 99. Use the debugger to look at the VDP registers when running in EA3 and when running in EA5 to see if they are the same.

Wilco! You’ve been helpful in the past so going to try that now.

[Airshack]

47 minutes ago, senior_falcon said:

It seems likely, but there is no reason to assume. You should run this in Classic 99. Use the debugger to look at the VDP registers when running in EA3 and when running in EA5 to see if they are the same.

Here's while running the game under EA3

 

While running via EA5, and before a Classic99 Cold Reset.

Note: I used the EA disk SAVE utility to convert it from EA3 to EA5.

The game ran fine here as if the EA5 conversion was successful.

 

While running via EA5, after a Cold Reset of Classic99.

The game locked up into a black screen with a few seemingly random characters.

 

 

Is this what you mean by looking at the VDP registers?

 

 

 

 

 

[Airshack]

40 minutes ago, Lee Stewart said:

• Be sure interrupts are off whenever you write anything to the VDP.
• If you use the console’s KSCAN anywhere in your program for input, be sure you write the value for VR01 to >83D4 before writing it to VR01.

Interrupts are turned off and left off the entire game.

 

KSCAN is not used. Wanting to preserve the scratchpad. Not using any console routines. 

[Airshack]

Perhaps I need to return the conversation towards the notion of headers? I have not tried PeteE's header initiative. Will in the AM...

[PeteE]

57 minutes ago, Airshack said:

Perhaps I need to return the conversation towards the notion of headers? I have not tried PeteE's header initiative. Will in the AM...

I guess you missed my message on the previous page?  The headers are only required if you're making a cartridge ROM that runs in the >6000 memory space.  It's not needed when making an EA5...

 

Since your VDP registers all appear the same, have you tried setting breakpoints in your program at initialization points to see if the VDP memory changes as expected?

[HOME AUTOMATION]

VDP regs. look right.

 

Did you make the first line of the loaded code start with a B @>xxxx(entry address)?

[Airshack]

8 hours ago, PeteE said:

I guess you missed my message on the previous page?  The headers are only required if you're making a cartridge ROM that runs in the >6000 memory space.  It's not needed when making an EA5...

I’m only making an EA5 as an intermediary step towards making a cartridge ROM.

 

Basically, I want to test my game using FinalGROM99. It’d also be a kick to cut a cartridge when it’s finished.

[Airshack]

9 hours ago, PeteE said:

same, have you tried setting breakpoints in your program at initialization points to see if the VDP memory changes as expected?

   Hmm...not sure what I’d be looking for here. What exactly would one expect to change? 

[PeteE]

13 minutes ago, Airshack said:

I’m only making an EA5 as an intermediary step towards making a cartridge ROM.

 

Basically, I want to test my game using FinalGROM99. It’d also be a kick to cut a cartridge when it’s finished.

Ok, understood.  Still I don't think you need to worry about the cart header at this point, as the tool used to create the cartridge will add the header for you automatically.

[PeteE]

2 minutes ago, Airshack said:

   Hmm...not sure what I’d be looking for here. What exactly would one expect to change? 

In the classic99 debugger, click the VDP radio button and then type the address you want to view.  Try looking at the address for the screen image table to see if your map is being drawn correctly.  Check the color table address to see if some entries are getting set to black on black.

[Asmusr]

5 minutes ago, Airshack said:

   Hmm...not sure what I’d be looking for here. What exactly would one expect to change? 

You need to check if the name table at >0000 and the pattern table at >2000 contain the expected data.