F18A programming, info, and resources

[Asmusr]

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 October 4, 2019 by Asmusr

[+FarmerPotato]

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.

 

 

[+FarmerPotato]

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?

 

[Asmusr]

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.

[ralphb]

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?

 

[Asmusr]

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.

[ralphb]

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:

 

 

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

 

 

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 June 15, 2020 by ralphb

[Asmusr]

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:

 

 

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

 

 

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?

[ralphb]

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

[matthew180]

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.

 

[ralphb]

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

[ralphb]

My F18A experience deteriorated further, right now I only have red left (and the image doesn't sync right):

 

 

But this is not why I post here.

 

While debugging an issue, the TI 99 yielded a very interesting error "message": ?

 

 

I suppose that is the F18A's doing, but I had a good laugh.  Unfortunately, I didn't press any key to see how far it would've gotten me. ?

 

[+mizapf]

99 Shades of Red ...

[ralphb]

9 minutes ago, mizapf said:

99 Shades of Red ...

Hey, it's like a slighly-off amber screen ... totally appropriate for the 80s. ?

[+mizapf]

Remember ... when we wondered whether to get that green or the amber monitor - with a bit of melancholy when thinking about all the colors we already had on the TI and other home computers - or rather that expensive "VGA monitor" with "MultiSync" ...

[+Ksarul]

On 12/6/2020 at 10:20 AM, mizapf said:

Remember ... when we wondered whether to get that green or the amber monitor - with a bit of melancholy when thinking about all the colors we already had on the TI and other home computers - or rather that expensive "VGA monitor" with "MultiSync" ...

Don't forget the "Paper White" monitors. . .I used several of those at work back then.

[Tursi]

On 12/6/2020 at 4:17 AM, ralphb said:

My F18A experience deteriorated further, right now I only have red left (and the image doesn't sync right):

 

 

But this is not why I post here.

 

While debugging an issue, the TI 99 yielded a very interesting error "message":

 

I suppose that is the F18A's doing, but I had a good laugh.  Unfortunately, I didn't press any key to see how far it would've gotten me. ?

 

hehe, it's actually stable, too, I can't remember which bit combination causes it, but that's a full VGA screen, if you can just figure out the timing on the GPU to switch patterns for each quadrant

 

(Spoiler: I don't think it can be done reliably )

 

[Asmusr]

Does it work to set your 6K ECM3 sprite pattern table at >3000 and let it extend into the extra 2K at >4000 to >47FF?

[Asmusr]

1 hour ago, Asmusr said:

Does it work to set your 6K ECM3 sprite pattern table at >3000 and let it extend into the extra 2K at >4000 to >47FF?

Unfortunately the answer to my question is no. The address seems to wrap around to 0 instead of proceeding into the extra 2K. @matthew180 would it possible to fix this in a firmware update?

 

I'm working on a project that requires 30 ROWS, ECM3 tiles (6K), ECM3 sprites (6K), 2D scrolling (4K), TL2 (1K) plus 256 bytes for tile attributes and 128 bytes for sprite attributes. Without the extra 2K I can only store 32 sprites patterns, which is simply not enough. All 256 tiles are also needed.

[ralphb]

1 hour ago, Asmusr said:

Unfortunately the answer to my question is no. The address seems to wrap around to 0 instead of proceeding into the extra 2K. @matthew180 would it possible to fix this in a firmware update?

While I don't know anything about the advanced graphics modes of the F18A, extending VDP RAM beyond 16K might cause problems if you try to read that directly with conventional methods, since writing any address larger than >3FFF to VDPWA would set the write bit in the VDP. 

 

You'll have to read from >3FFF all the way to the address you're interested in.

[Asmusr]

9 minutes ago, ralphb said:

While I don't know anything about the advanced graphics modes of the F18A, extending VDP RAM beyond 16K might cause problems if you try to read that directly with conventional methods, since writing any address larger than >3FFF to VDPWA would set the write bit in the VDP. 

 

You'll have to read from >3FFF all the way to the address you're interested in.

I'm talking about the F18A reading its own RAM to display sprites. It already has RAM at >4000->47ff. You need GPU code to place data in that RAM.

[ralphb]

3 minutes ago, Asmusr said:

I'm talking about the F18A reading its own RAM to display sprites. It already has RAM at >4000->47ff. You need GPU code to place data in that RAM.

My apologies, I shouldn't only read the very last post! ?

[matthew180]

@ralphb Sorry I missed all the posts about the amber screen.  I really don't think that is the F18A directly, but rather the VGA pigtail cable.  I have come to learn that the pigtails are not very well made and the connections break easily.  If the problem is on the F18A board, then almost certainly it will be with the resistors that make up the DAC.  All of these problems are pretty easy to test / troubleshoot if you are comfortable with a multimeter and / or soldering iron.

 

The 4x display is possible on the F18A by setting the mode bits to a value > 9, IIRC (I'll have to check the HDL again).  It is not intentionally supported by the hardware, so anything that happens in this mode is not guaranteed.

[matthew180]

6 hours ago, Asmusr said:

Unfortunately the answer to my question is no. The address seems to wrap around to 0 instead of proceeding into the extra 2K. @matthew180 would it possible to fix this in a firmware update?

Yeah, I think we started talking about this as something I would have to address with the MK2, and then unfortunately I was side-tracked with the whole "H", "D", "M", "I" issue.

 

So, it was pretty short-sighted of me when I made the VRAM over 4K private to the GPU.  That will probably change, even with the original F18A firmware, to make what is "private" GPU VRAM accessible via the VDP Address Register, but only when the F18A is unlocked (for compatibility reasons).  I also want to try to squeeze a little more VRAM out of the original F18A by not being so casual with the Block-RAM I used for line buffers (it might provide an additional 2K of VRAM, but no promises).

 

Also, mapping the VDP registers into the VRAM address space was also short-sighted, and something will have to change in the MK2 related to that.  I think I worked it out a few years ago (holy shit it has been a long time!), but I did not write it down, so I'll have to go through the mental process again.

[ralphb]

3 minutes ago, matthew180 said:

@ralphb Sorry I missed all the posts about the amber screen.  I really don't think that is the F18A directly, but rather the VGA pigtail cable.  I have come to learn that the pigtails are not very well made and the connections break easily.  If the problem is on the F18A board, then almost certainly it will be with the resistors that make up the DAC.  All of these problems are pretty easy to test / troubleshoot if you are comfortable with a multimeter and / or soldering iron.

 

The 4x display is possible on the F18A by setting the mode bits to a value > 9, IIRC (I'll have to check the HDL again).  It is not intentionally supported by the hardware, so anything that happens in this mode is not guaranteed.

Thanks for getting back.  I figured as much about the cable, since it's not really straight, but gets twisted inside the TI quite a bit.  I haven't bothered to fix it yet, since the shaking is gone, and I also got varying levels of green back. ?

 

The 4x image was quite funny, since the TI 99 just crashed, and I didn't make use of any F18A features at all ...