Jump to content
IGNORED

Testing for current screen mode


Recommended Posts

Hi

 

Is there a way to establish the current screen mode and the location of assorted tables related to the screen? I mean...As I understand it, I can WRITE ONLY to the mode byte. But is there a copy of this byte somewhere else, so I can test it? The idea is to test my current understanding of writing MC code by writing a simple DISPLAY AT routine, that works in TEXT as well as standard mode without explicitly providing the location of tables and the width of the screen.

  • Like 1
Link to comment
Share on other sites

The byte (if I remember correctly, 83D4) is not a real copy of the video register 1. You can load a value into that memory location, and with the next interrupt (if it is enabled by LIMI 2) the interrupt handler copies that value into VR1. Programs do not have to use that way, they can directly set the video register. Hence, what you read from that address does not necessarily reflect the current setting.

Link to comment
Share on other sites

The value at >83D4 is copied to VR01 at the next keypress, not the next interrupt. With that value, you can only determine explicitly on the real iron whether the VDP is in Multicolor or Text mode. If neither of those bits is set, you can only say it is in one of the graphics modes: Graphics, Bitmap, hybrid (Split, Split2, ?).

 

When writing ALC, your code should be initializing all VDP registers relevant to the graphics mode you set. That way, you know the values you seek. Details for those values can be found in the Editor/Assembler manual.

 

If you are loading your program via the E/A cartridge, the VDP should be in Graphics mode with a screen width of 32. Otherwise, the last paragraph obtains.

 

...lee

  • Like 3
Link to comment
Share on other sites

3 hours ago, Lee Stewart said:

The value at >83D4 is copied to VR01 at he next keypress, not the next interrupt.

Ah yes, you're right, of course. The connection to the interrupt is the auto-blank feature.

Link to comment
Share on other sites

Hi

 

Thanks for the suggestions. It looks as if I may have to ditch the idea of self-adapting code in this case.

The good news is, of course, that writing a simple DISPLAY at routine without all the extras available in Extended Basic, is so much faster, when writing directly to VPD using VDPWA/VDPWD instead of VSBW. So, using CALL LINK("MYDISP",y,x,"This is a test") can outperform a standard DISPLAY AT(y,x):"This is a test". Possibly because I have no evaluation or error checking to hold me back 😀

  • Like 1
Link to comment
Share on other sites

The reason for that you can't see exactly which mode you are using, by inspecting the VDP R1 copy, if it's neither text nor multicolor is that the original VDP had no other option than Graphics mode if it wasn't any of those two. So there you could conclude that it must be Graphics mode if nothing else was explicitly declared.

But then came the A-version of the VDP and suddenly we got another Graphics mode, which isn't set inside VDP register 1. As well as the different memory usages inside bitmap mode which creates the split screen modes.

  • Like 1
Link to comment
Share on other sites

Hi

 

Ahh,yes...Split screen modes.... I know they exist, but I have never seen an example. As I understand it, a normal hires graphics mode is effectively three sets of character definitions 0-255, each of 2 Kb, that each covers one third of the display, and with matching tables for colours, also using 6 kb in total. But can you use regular 'print' methods to display characters on one of these three blocks. What is the preferred method?

Link to comment
Share on other sites

So, if the OP is saying the context is always BASIC or XB, does the >83D4 hold true? 

 

Oh, but of course in the BASICs you are only in the one screen mode, unless using one of the extensions like TML or Apesoft. But do they provide a way to detect their mode? Or use the same >83D4 shadow register?

Link to comment
Share on other sites

They use the shadow register to be able to restore the current screen mode after blanking the screen. Blanking is done by changing one bit in that register. When you want to return to showing the screen again, you can't just reset the blanking bit - you need to reload the whole register. Since you can't read out what's in the register, you have to keep track of what you loaded there, sans the blanking bit, so you can restore the content without blanking.

 

In a way you need to do the same when you enable blanking, but since you can't see anything on the screen then, it doesn't matter too much what kind of mode you set the screen to. Not until you restore it.

  • Like 1
Link to comment
Share on other sites

I am still toying with the different screen modes from Extended Basic on a machine with 32 K RAM. With a small MC program I can switch to TEXT mode. I have to reallocate the Screen Image table since parts of its default location overlaps addresses used by Extended basic. But where to put it? Currently I locate it at >2000 in VDP RAM, which seems to be a safe bet for smaller Basic programs, since parts of the code seems to be stored downwards from >37D8 and some other stuff upwards from >0958 (and some in high memory). So there is a big gap in the middle free for grabs. Since I am not actually modifying anything of the original Screen Image table at >0000, I can have a GFX1 (32 char) screen and a TEXT (40 char) screen and swap between them by modifying the VDP mode bytes. I also have to use small MC code routines for writing to the TEXT screen, replacing the CALL CLEAR and DISPLAY AT routine with code designed for the changed Screen Table location and screen width. But all this can be done using the CALL LINK command to call these MC routines. The question remains... Is this a good way of accessing TEXT mode as well as GFX1 mode from a Basic  program, or am I just lucky, that it hasn't blown up in my face?

Link to comment
Share on other sites

1 hour ago, jschultzpedersen said:

I am still toying with the different screen modes from Extended Basic on a machine with 32 K RAM. With a small MC program I can switch to TEXT mode. I have to reallocate the Screen Image table since parts of its default location overlaps addresses used by Extended basic. But where to put it? Currently I locate it at >2000 in VDP RAM, which seems to be a safe bet for smaller Basic programs, since parts of the code seems to be stored downwards from >37D8 and some other stuff upwards from >0958 (and some in high memory). So there is a big gap in the middle free for grabs. Since I am not actually modifying anything of the original Screen Image table at >0000, I can have a GFX1 (32 char) screen and a TEXT (40 char) screen and swap between them by modifying the VDP mode bytes. I also have to use small MC code routines for writing to the TEXT screen, replacing the CALL CLEAR and DISPLAY AT routine with code designed for the changed Screen Table location and screen width. But all this can be done using the CALL LINK command to call these MC routines. The question remains... Is this a good way of accessing TEXT mode as well as GFX1 mode from a Basic  program, or am I just lucky, that it hasn't blown up in my face?

 

XB uses the overlap area for the 128-byte Sprite Attribute Table (SAT) at >0300, the two halves of the random number seed (10 bytes) at >03A0, and probably some of rest of it, as well. Because the SAT cannot be used in Text mode, you might get away with saving/restoring the 192-byte overlap area (>0300 – >03BF) between mode changes.

 

...lee

Link to comment
Share on other sites

Ah, but is that needed? If I move the Screen Table for the TEXT mode to >2000, the original content of memory including the Screen Image Table for GFX1 remains in the interval up from >0000...Thus, when I return to GFX1 mode, everything is untouched. Sprites are only available in GFX1 mode anyway. As long as I only write to the new Screen Image Table using my own DISPLAY AT and CALL CLEAR routines, that writes to the new Screen Image Table the GFX1 area remains unaffected. I have tested by using a regular DISPLAY AT call, while in TEXT mode, and it writes text to the GFX1 screen as expected and the txt becomes visible once I set the mode bytes back to GFX1.

 

Ideally I would want to lower the top free address in VPD and create space for my Screen Image Table above that limit to avoid any collisions in larger Basic programs. I have not tried that yet. Is it as simple as writing a new value to >8340 (First free VDP RAM address)? Or how would I go about doing that?

 

PS. I must say, that I have a great deal of fun experimenting with these things now when I have the time as a retiree. 😀 The help I get from you guys is invaluable.

  • Like 1
Link to comment
Share on other sites

On 7/10/2024 at 1:15 AM, jschultzpedersen said:

Hi

 

Ahh,yes...Split screen modes.... I know they exist, but I have never seen an example. As I understand it, a normal hires graphics mode is effectively three sets of character definitions 0-255, each of 2 Kb, that each covers one third of the display, and with matching tables for colours, also using 6 kb in total. But can you use regular 'print' methods to display characters on one of these three blocks. What is the preferred method?

TI-FORTH showed this concept with a 64 column editor in the upper half of the screen and graphics 1 mode below.

Here it is running in Lee's FbForth.

 

 

  • Like 1
Link to comment
Share on other sites

5 hours ago, jschultzpedersen said:

I am still toying with the different screen modes from Extended Basic on a machine with 32 K RAM. With a small MC program I can switch to TEXT mode. I have to reallocate the Screen Image table since parts of its default location overlaps addresses used by Extended basic. But where to put it? Currently I locate it at >2000 in VDP RAM, which seems to be a safe bet for smaller Basic programs, since parts of the code seems to be stored downwards from >37D8 and some other stuff upwards from >0958 (and some in high memory). So there is a big gap in the middle free for grabs. Since I am not actually modifying anything of the original Screen Image table at >0000, I can have a GFX1 (32 char) screen and a TEXT (40 char) screen and swap between them by modifying the VDP mode bytes. I also have to use small MC code routines for writing to the TEXT screen, replacing the CALL CLEAR and DISPLAY AT routine with code designed for the changed Screen Table location and screen width. But all this can be done using the CALL LINK command to call these MC routines. The question remains... Is this a good way of accessing TEXT mode as well as GFX1 mode from a Basic  program, or am I just lucky, that it hasn't blown up in my face?

The fellow you want to ask about making XB bend to your will is @senior_falcon - he created the Missing Link for bitmap graphics in XB, and is still making new toys for it.

  • Like 3
Link to comment
Share on other sites

7 hours ago, jschultzpedersen said:

Ideally I would want to lower the top free address in VPD and create space for my Screen Image Table above that limit to avoid any collisions in larger Basic programs. I have not tried that yet. Is it as simple as writing a new value to >8340 (First free VDP RAM address)? Or how would I go about doing that?

 

At startup, the value at >8340 is the same as at >8370. The latter is updated with any CALL FILES(n). The next statement (which should probably be NEW) will update >8340 regardless of what you may have stashed there. You can change >8370, but that is likely trouble because the TI DSR checks values just above the pointed-to address. Of course, you might succeed by changing >8370 to a lower value and copying the 5 or 6 bytes above the VRAM address, pointed to by >8370 before the change, above the new address you stashed in >8370. That might keep the TI DSR happy.

 

Oh, yes—and what @Tursi said.

 

...lee

Edited by Lee Stewart
more info & a correction
  • Like 1
Link to comment
Share on other sites

The problem with having a VDP table at >2000 is that sooner or later Extended BASIC will use that area for string storage.

Extended BASIC uses VDP RAM for storage with a heap-style memory allocation strategy. It may store new string content in ever increasing addresses until it hits the end it knows about. Then it will do garbage collection across the available area and start over in the part of it that's found to be free.

Thus it may suddenly start trotting over your screen's face, literally!

  • Like 1
Link to comment
Share on other sites

Hi

 

I just tried to lower the top basic address in >8370 to >2FFF and then to put the Screen Image table at >3000 and finally to write an 'A' to VDP address >3000.

Running this code from Extended Basic (X3) seems to work. I get a clean return to Basic. Also, after doing this, other actions like saving and loading, listing and modifying the basic code works. The SIZE command reports a smaller size of VDP memory matching how much I lowered the limit. Of course the regular PRINT and DISPLAY AT commands do not work as they address the original Screen Image table. I have to use my own versions to get something on screen.

 

 


100 CALL INIT
110 CALL LOAD("DSK3.X1.O")
120 CALL LINK("START")
125 CALL KEY(0,K,S):: IF NOT S THEN 125
130 END

 

 

       DEF  START                       
VDPWD  EQU  >8C00                       
VDPWA  EQU  >8C02                       
MASK   DATA >4000                       
                                        
START  LI   R0,>2FFF     * TOP BASIC    
       MOV  R0,@>8370                   
                                        
       LI   R0,>0C82     * SCR IMG TBL  
       MOVB R0,@VDPWA    * AT >3000     
       SWPB R0                          
       MOVB R0,@VDPWA                   
                                        
       LI   R1,>3000     * WRITE 'A'    
       SWPB R1           * TO VDP       
       MOVB R1,@VDPWA    * ADRS >3000.  
       SWPB R1                          
       SOC  @MASK,R1                    
       MOVB R1,@VDPWA                   
       LI   R2,>A100                    
       MOVB R2,@VDPWD                   
       RT                               
       END                              
      *EOF (VERSION 1.2)                
 

Link to comment
Share on other sites

Further on this...

 

I think I could also reserve some RAM in VDP using the GPLLNK call >38. I won't know beforehand where the RAM will be reserved. But I could reserve enough memory to be sure to have an area of sufficient size on a >400 border. Then I could point the Screen Image table to this area. I suppose this would be an 'OS-friendly' approach.

 

 

Edited by jschultzpedersen
Ups! Pressed save too soon
Link to comment
Share on other sites

Classic99 is pretty forgiving when it comes to disk access. I suspect that your code above will not be able to access the disk drive system on a real TI99. There are ways to get around that. Other than that, it works fine.

Adding line 122 A$="HELLO WORLD" :: GOTO 122 causes no problems when the garbage collection occurs.

  • Like 1
Link to comment
Share on other sites

To see if you're breaking the disk system while Classic99 still works, just read the debug log. All the cases we've hit in the past are detected and complained about there. If it complains, you can expect it won't work.

 

You can test it by changing DSK1, DSK2 or DSK3 to the TI Controller and using a disk image on them - that runs as close to the hardware as Classic99 allows, running the whole DSR down to the sector access. You should always try this at least once when developing new disk code on Classic99, just to make sure it'll work for other people.

 

 

  • Like 3
Link to comment
Share on other sites

On 7/17/2024 at 9:10 AM, Tursi said:

To see if you're breaking the disk system while Classic99 still works, just read the debug log. All the cases we've hit in the past are detected and complained about there. If it complains, you can expect it won't work.

 

You can test it by changing DSK1, DSK2 or DSK3 to the TI Controller and using a disk image on them - that runs as close to the hardware as Classic99 allows, running the whole DSR down to the sector access. You should always try this at least once when developing new disk code on Classic99, just to make sure it'll work for other people.

I resemble that remark. :) 

 

  • Haha 1
Link to comment
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...
×
×
  • Create New...