Jump to content
matthew180

F18A programming, info, and resources

Recommended Posts

36 minutes ago, FarmerPotato said:

So, to keep sprites from floating over the BML, I must zero out their pattern bytes. This is do-able.

You could use the GPU and the HSYNC trigger to set VR51 (number of sprites processed) to 0 when it reaches a certain scan line, and set it back again when it reaches the bottom of the screen. I'm doing something similar in the Mario demo where I'm preventing the top part of the screen from scrolling using the HSYNC trigger, so I have some code to share:

 

*      GPU code
INIGP1 XORG GPUPRG
       LI	R15,>47FE			       ; Set up stack pointer
*	   Set the HSYNC trigger
       MOVB @>6032,R0
       ORI  R0,>4000                   ; Set GPU_HTRIG
	   MOVB	R0,@>6032
RETURN IDLE
*	   HSYNC routine
	   CLR	R0
	   MOVB	@>7000,R0			       ; Get scanline no
	   SWPB	R0
	   INC	R0
	   CLR  R1                         ; Scroll reg value at top
	   LI   R2,>0800                   ; Name table reg value at top
	   CI	R0,32				       ; Check scanline
	   JLT	GPU1                       ; At top
	   CI	R0,239				       ; Check scanline
	   JGT	GPU1                       ; Below bottom
       MOV  @GSCRLX,R1                 ; Scroll offset at bottom
       MOV  R1,R3                      ; Copy
       ANDI R1,>00FF                   ; Isolate scroll reg value
       SWPB R1                         ; To MSB
       ANDI R3,>0100                   ; Isolate page bit
       SOC  R3,R2                      ; OR >0800
GPU1   MOVB R1,@>6019			       ; Set scroll register 2
       MOVB R2,@>600A			       ; Set name table register 2
       JMP  RETURN
GSCRLX DATA >0000
       AORG
INIGP2

Edit: In GPU code you can get the current scanline at >7000. The VRs are directly accessed from >6000->603f. To copy the GPU code to the VDP you can use:

*      Copy program to VDP RAM
       LI   R0,GPUPRG
       LI   R1,INIGP1
       LI   R2,INIGP2-INIGP1
       BL   @VMBW
*     Set the GPU PC which also triggers it
      LI   R0,GPUPRG/256+>3600
      BL   @VWTR
      LI   R0,>3700
      BL   @VWTR

 
Edited by Asmusr

Share this post


Link to post
Share on other sites
9 minutes ago, Asmusr said:

You could use the GPU and the HSYNC trigger to set VR51 (number of sprites processed) to 0 when it reaches a certain scan line, and set it back again when it reaches the bottom of the screen.

 

Oh, that's a good idea! Simple solution. I'll see what other effects this leads to.

 

 

Share this post


Link to post
Share on other sites

Question: can a BML span 256 pixels wide? Or is 255 the limit? This is relevant to hiding 4 rows during scrolling and provide a non-scrolling status area with a little video running (not tile based).
Or should I just use the scanline / GPU to turn off TL1 and 2?

 

Share this post


Link to post
Share on other sites
5 minutes ago, FarmerPotato said:

Question: can a BML span 256 pixels wide? Or is 255 the limit? This is relevant to hiding 4 rows during scrolling.
Or should I just use the scanline / GPU to turn off TL1 and 2?

 

Yes, setting VR35=0 means width=256.

  • Like 1

Share this post


Link to post
Share on other sites

I'm not sure if the answer to my question is already buried in some thread, but I noticed today that if you unlock the F18A and then use normal text mode (i.e., 40 columns mode), some random sprites may show up.  This does not happen in non-F18A mode, since textmode cannot use sprites (at least according to the E/A manual).

 

I guess the fix is just to write one >D0 at the right place, but should this really happen?

 

Share this post


Link to post
Share on other sites
6 minutes ago, ralphb said:

I guess the fix is just to write one >D0 at the right place, but should this really happen?

Yes, you can use sprites in text mode if the F18A is unlocked.

  • Like 4

Share this post


Link to post
Share on other sites
Posted (edited)

Is there also a way to deactivate an unlocked F18A?  For a while I checked for an F18A in the SDD 99 power-up routine, which involved unlocking the F18A. 

       ; check for F18A
       li   r0, >391c         ; unlock potential F18A
       bl   @vwtr
       bl   @vwtr
       li   r0, >01c0
       bl   @vwtr

       movb @vdpsta, r1       ; check if F18A present
       li   r0, >0f01
       bl   @vwtr
       movb @vdpsta, r2
       dec  r0
       bl   @vwtr
       cb   r1, r2
       jeq  powerup_cart

       li   r0, sys_f18a_en   ; mark F18A available
       mov  r0, @x_sys

With F18A active, however, the TI BASIC output is totally garbled:

 

scrambled.thumb.jpg.4e79d69eb98271a6710e223beb5c57be.jpg

 

This should look like below, and the only difference between both shots is the presence of above snippet in the DSR.

 

normal.thumb.jpg.52849752e9a85d64bc825480495c0ea8.jpg

 

Note that the DSR does not modify any VDP registers except for F18A detection.  I have no idea how this can even happen ...  Are some default register values different?  Maybe some F18A experts know?

 

(NOTE: Neither image looks really that normal.  That's because my F18A or the VGA connector or the connecting cable has some "issues".  If you watched my SDD 99 video, you know that there was a green tinge and some fuzz to the screen.  After "rerouting" the cable inside my TI, I now have NO green at all! 🤪)

 

EDIT: I looks a little bit like bitmap mode ...

Edited by ralphb

Share this post


Link to post
Share on other sites
3 hours ago, ralphb said:

Is there also a way to deactivate an unlocked F18A?  For a while I checked for an F18A in the SDD 99 power-up routine, which involved unlocking the F18A. 

       ; check for F18A
       li   r0, >391c         ; unlock potential F18A
       bl   @vwtr
       bl   @vwtr
       li   r0, >01c0
       bl   @vwtr

       movb @vdpsta, r1       ; check if F18A present
       li   r0, >0f01
       bl   @vwtr
       movb @vdpsta, r2
       dec  r0
       bl   @vwtr
       cb   r1, r2
       jeq  powerup_cart

       li   r0, sys_f18a_en   ; mark F18A available
       mov  r0, @x_sys

With F18A active, however, the TI BASIC output is totally garbled:

 

scrambled.thumb.jpg.4e79d69eb98271a6710e223beb5c57be.jpg

 

This should look like below, and the only difference between both shots is the presence of above snippet in the DSR.

 

normal.thumb.jpg.52849752e9a85d64bc825480495c0ea8.jpg

 

Note that the DSR does not modify any VDP registers except for F18A detection.  I have no idea how this can even happen ...  Are some default register values different?  Maybe some F18A experts know?

 

(NOTE: Neither image looks really that normal.  That's because my F18A or the VGA connector or the connecting cable has some "issues".  If you watched my SDD 99 video, you know that there was a green tinge and some fuzz to the screen.  After "rerouting" the cable inside my TI, I now have NO green at all! 🤪)

 

EDIT: I looks a little bit like bitmap mode ...

You can reset and lock the F18A with:
LI   R0,>3280
BL   @VWTR

Did you try you code in js99er?

  • Like 1

Share this post


Link to post
Share on other sites

Thanks, Rasmus!  No, this is running on real iron; it'd be some work to port this to an emulator.

  • Like 1

Share this post


Link to post
Share on other sites
On 6/14/2020 at 8:43 AM, ralphb said:

I guess the fix is just to write one >D0 at the right place, but should this really happen?

It is assumed that once a program unlocks the F18A then it is "F18A aware", and therefore the program knows it will have new features to deal with, like sprites enabled in the text modes.  However, the F18A *does* try to have sensible defaults, so there should not be too much extra to deal with.  Sprites being disabled is one of those extra details, since disabling them depends on the sprite attribute table in VRAM, and not VDP registers.

 

On 6/15/2020 at 8:22 AM, ralphb said:

Is there also a way to deactivate an unlocked F18A?

Yes, as Rasmus mentioned, writing to VR50 will reset the F18A's default power-on register values and relocks the F18A.  Note that the palette registers are *not* reset.

 

On 6/15/2020 at 8:22 AM, ralphb said:

Note that the DSR does not modify any VDP registers except for F18A detection.  I have no idea how this can even happen ...  Are some default register values different?

I do not know why TI BASIC would be garbled with the F18A unlocked.  The default register values are designed to keep the F18A looking like the 9918A until they are changed.  However, there is a *LOT* of bad software out there, which is why I had to incorporate locking the F18A in the first place.

 

The problem is that the VDP register to write is specified with 6-bits (10 RRR RRR) of the byte written to the VDP.  The 9918A would just ignore the top 3-bits of the 6-bits (and the datasheet specifies they are to be zero), so only VR0..VR7 can be specified.  When the F18A is locked it does the same thing.  However, when the F18A is unlocked, all 6-bits are used to specify the additional VDP registers, i.e. VR0..VR63 (not all exist, but many do).  In a lot of legacy software, there is junk (due to sloppy coding) in the 3 extra bits that are usually ignored, however they cannot be ignored by the F18A when it is unlocked.  So when such software is run on an unlocked F18A (or 9938/59, which do not have a lock feature) it will cause all kinds of problems.  It took me a long time to figure this out when testing the F18A, and I have found offensive software on *all* systems that use the 9918A VDP.

 

So basically, any legacy software that writes to VDP registers over VR7 will have negative consequences when the F18A is unlocked.  I do not know specifically if TI BASIC in an offender, but it would not surprise me if it is.

 

On 6/15/2020 at 8:22 AM, ralphb said:

After "rerouting" the cable inside my TI, I now have NO green at all!

The VGA pig-tail that comes with the F18A is not the greatest quality (they were the best I could find), and the wires inside the VGA shell break easily.  The shell slides easily down the ribbon cable, so you should be able to inspect and repair any broken wires.

 

  • Like 1

Share this post


Link to post
Share on other sites
9 hours ago, matthew180 said:

So basically, any legacy software that writes to VDP registers over VR7 will have negative consequences when the F18A is unlocked.  I do not know specifically if TI BASIC in an offender, but it would not surprise me if it is.

Well that makes sense!  I decided to not test for the F18A in the power-up code and instead leave that to the programs, as it probably should be.

 

Also thanks for the hint about the connector.  I'll try that, as the picture keeps getting worse ...

Share this post


Link to post
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.

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...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...