VDP scanline tricks

[Asmusr]

Do we *any* examples of games or demos that use VDP scanline tricks such as changing mode, colors or sprite attribute table while the VDP is drawing the screen?

[Tursi]

I'm not sure anything on the TI does.

 

I did a proof some years ago that it was possible, and posted the result to YouTube, but it's not a program I saved. (It just set up two touching sprites and used automotion to move them downward continuously. A CPU loop then polled the status register. When it saw end of frame, it set the screen color to green, when it saw collision, it set the screen color to blue. You could then watch the screen color change as the sprites moved.)

[Asmusr]

OK, thanks. If you don't know of any examples I'm sure nobody else will either. So nobody in 32 years has tried to use the 5th sprite flag to switch to another sprite table?

 

I think that would be the real practical use, to get more sprites on the screen - especially if you cannot use the top of the screen for other graphics, as in the Artrag mode.

[+nanochess]

Defender in the Colecovision uses a delay-trick to get a radar in the top screen and the in-game screen below.

 

I discovered that because when running in PAL version because of different timings the upper part (the radar) doesn't show points. I made a patch for that.

[Wildstar]

It might not be the case that it has never been attempted. It probably has but usually with some sort of demo scener but we have to find the demo scene of the TI-99/4A. It seems the TI folks are somewhat more fragmented than the Commodore 64 folks as it may seem.

 

As far as if any TI-99/4A demo sceners still existing... hmmm.... hard to say. In the 1980s, I'd say there was still quite an active group. TI had its own user base demographics. On the Commodore community, we done video tricks such as FLI on the VIC-II video chip. The technique of doing this should be possible on the 9918A chip provided you can A) read the raster line level and B) switch memory position for Screen memory at each scan line in an 8x8 character row. After all, it uses a character cell (like a tile) layout setup. A thorough and more accurate wordage can be easily found when googling up on FLI on Commodore 64 from some credible sources.

 

Doing a similar trick on the TI-99/4A would require expanded RAM for a full screen.

[Wildstar]

After reading, to do the FLI effect on the C64, a vertical scroll register is required so it can be done on upgrades which as the vertical scroll register. The F18A is one such upgrade. A plan I or someone (hint for anyone willing to approach the technique) might do is to use the FLI-like trick but to do palette swapping to make great use of the 4096 colors while in say 4bpp mode or what not. Expanded RAM is a necessity due to RAM footprint. A non-RAM Expanded system will have difficulty doing full screen but a 1/4" is doable like a logo while switching back to more normal video modes the rest of the way.

 

A real nice RAM upgrade would be a Hyper-AMS. A stock 32K plus Minimemory would be decent enough for a minimal system because we would want to have comparable RAM space to that of a C64 or close to it for footprint.

 

I don't know if that is the kind of VDP scanline trick that the OP is looking for.

[Omega-TI]

 

A real nice RAM upgrade would be a Hyper-AMS. A stock 32K plus Minimemory would be decent enough for a minimal system because we would want to have comparable RAM space to that of a C64 or close to it for footprint.

 

 

One quick question sort of related... Will a Hyper-AMS card and a PGRAM card get along together?

[+Ksarul]

They should--a P-GRAM doesn't have any issues with a standard AMS card, so it should work with a HyperAMS too.

[artrag]

so, something gorgeous in on the way...

[TheMole]

Do we *any* examples of games or demos that use VDP scanline tricks such as changing mode, colors or sprite attribute table while the VDP is drawing the screen?

 

The only thing that I routinely do is change the background color mid-frame as a sort of poor man's profiling tool to (visually) see how many scanlines a given routine takes (which today only works in the real deal and in MESS). But of course, that's not a game or demo effect...

[TheMole]

After reading, to do the FLI effect on the C64, a vertical scroll register is required so it can be done on upgrades which as the vertical scroll register. The F18A is one such upgrade. A plan I or someone (hint for anyone willing to approach the technique) might do is to use the FLI-like trick but to do palette swapping to make great use of the 4096 colors while in say 4bpp mode or what not. Expanded RAM is a necessity due to RAM footprint. A non-RAM Expanded system will have difficulty doing full screen but a 1/4" is doable like a logo while switching back to more normal video modes the rest of the way.

 

A real nice RAM upgrade would be a Hyper-AMS. A stock 32K plus Minimemory would be decent enough for a minimal system because we would want to have comparable RAM space to that of a C64 or close to it for footprint.

 

I don't know if that is the kind of VDP scanline trick that the OP is looking for.

 

The problem with trying to map C64 techniques on the TI is that the VDP does not use the same memory as the CPU. So we're not so much limited by RAM as we are by CPU-VDP transfer bandwidth. I don't think we have enough bandwidth to "race the beam" like on some other systems.

[Asmusr]

 

The only thing that I routinely do is change the background color mid-frame as a sort of poor man's profiling tool to (visually) see how many scanlines a given routine takes (which today only works in the real deal and in MESS). But of course, that's not a game or demo effect...

 

So it works with MAME, that's good to know. I think I will make some kind of sprite demo just so we have an example.

[TheMole]

 

So it works with MAME, that's good to know. I think I will make some kind of sprite demo just so we have an example.

 

Well, there are some examples of 32+ sprites for the Colecovision and MSX (Uridium by Atrax, for example), would be great to have the same on the TI.

Check this out: http://atariage.com/forums/topic/216268-my-first-test-on-the-tms9918/

[Willsy]

Software sprites is another technique worth exploring. For all those beautiful pretty games on the ZX Spectrum one should bear in mind that the spectrum has no hardware sprites at all. It only has a bitmap display fixed at 256x192. That's it. It doesn't even have a text mode! It's simply amazing what they squeezed out of that machine.

[artrag]

Try (on msx) the code in attach. The last 5 sprites of the first SAT trigger the swap to a second SAT. The loop tests for 5 sprites on a line.

 

This is the key fragment of the code commented (and in attach the useful files from the link)

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Interrupt service routine
;
    code @ 0x0038

    push   hl
    push   de
    push   bc
    push   af

    _setVdp 5,0x36 ;   SAT at 0x1b00 -> first sat, first 32 sprites
     
    _setVdp 7,0x0E ; 1st background color

    in  a,(0x99)   ; reset flags from previous interrupt

; do something here
; e.g. music or SAT update

    _setVdp 7,0x0C ; 2nd background color
 
1:  in  a,(0x99)       ; a = vdp status register
    and 0x1f+64         ; drop flags F and collision flag
    cp  0x1f+64         ; wait on 5th sprite condition on plane 31 
    jp  nz,1b

    _setVdp 5,0x37   ;   SAT at 0x1b80 ->  second sat, other 32 sprites
 
    _setVdp 7,0x00 ; 3rd background color
 
    pop    af
    pop    bc
    pop    de
    pop    hl
    ei
    ret

[edit]

I fixed a bug, the code in the link was a WIP with experiments. Refer to this latter version that is the sole correct.

splitdemo.rom

splitdemo.asm

Edited November 8, 2014 by artrag

[Wildstar]

 

The problem with trying to map C64 techniques on the TI is that the VDP does not use the same memory as the CPU. So we're not so much limited by RAM as we are by CPU-VDP transfer bandwidth. I don't think we have enough bandwidth to "race the beam" like on some other systems.

 

Perhaps but we can possibly due it with the F18A because it also incorporates a 100 MHz TMS9900-like "GPU" core which we could use instead of the 3 MHz TMS9900 for that. We should very easily outrace the raster beam and have enough clock cycles.

 

We did a similar FLI trick before on the VDC on the Commodore 128. Called the VDC FLI trick. In some ways the VDC is more similar to the VDP except it outputs to RGBI monitors instead of Composite video. The F18A would be more similar to the VDC in that it outputs to a SVGA monitor which is Analog RGB. While of course from a programming standpoint, it isn't that much different than the VDP as we know it. Just so people know... VDC means the 80 col. video chip found in the Commodore 128. VDC has its own dedicated RAM. Some was with 16K and some with 64KB upgrade. But you had a 1 maybe 2 MHz bus to interface through so it is amazing it was able to be done at all.

 

The VDP on the upgradeds like the Y9938 from Yamaha and upgrades to the TMS9900 that existed would provide some potential room. The F18A would have an interesting benefit because the 100 MHZ TMS9900-like "GPU" on the FPGA with the F18A VDP core has direct access to the same video memory and it will have the bandwidth to keep up. The 3 MHz TMS9900 would only have to handle low bandwidth or longer clock routines that are not for keeping up with the "raster beam". Technically the LCDs don't have raster beams per se but designed so as to process the video information the same general manner as the CRT VGA screens. I have a few of them which would allow use of light pens while a LCD screen would not. That's besides the point. We would be talking about digital inputting of information and setting of video 'registers' and what not to do what we need.

 

The F18A would however be able to keep up and the F18A "VDP" would be seen from the F18A "GPU" in a similar manner as the 6510 is to the VIC-II because the GPU would be on the same bus as the VDP component. While the F18A and TMS9900 are on seperate buses and would be more like the C128's 80-col. because the 8502 (C-128's "6510") and the VDC being on separate buses just as the TMS9900 and the F18A and other VDPs including the 9918A.

 

We would be able to do this quite effectively with F18A but not necessarily as easily on other VDP upgrades because we can use F18A's unique "GPU" and make "GPU routines" to process such FLI like tricks.

[+mizapf]

 

Perhaps but we can possibly due it with the F18A because it also incorporates a 100 MHz TMS9900-like "GPU" core which we could use instead of the 3 MHz TMS9900 for that. We should very easily outrace the raster beam and have enough clock cycles.

 

...

We would be able to do this quite effectively with F18A but not necessarily as easily on other VDP upgrades because we can use F18A's unique "GPU" and make "GPU routines" to process such FLI like tricks.

 

These are certainly some compelling visions, and they may be well feasible, but on the bottomline, I get mixed feelings with that - it's the ultimate concession that our good old standard TI is simply not good enough.

 

I'd prefer to see more attempts to get things going by the limited, standard features (thinking of the recent, great games Road Racer, Titanium and more, which taught us that we stopped far too early).

Edited November 8, 2014 by mizapf

[carlsson]

How is it, can you modify the VDP at any time as long as you haven't enabled the interrupt? While I never programmed the TI-99/4A, during my experiments with the 2 MHz 6502 based Creativision, I found that without interrupts enabled, it seems like you can bang the VDP registers as desired but with interrupt enabled, you can only safely update the chip during vertical blank, which is when the interrupt kicks in.

[artrag]

 

These are certainly some compelling visions, and they may be well feasible, but on the bottomline, I get mixed feelings with that - it's the ultimate concession that our good old standard TI is simply not good enough.

 

I'd prefer to see more attempts to get things going by the limited, standard features (thinking of the recent, great games Road Racer, Titanium and more, which taught us that we stopped far too early).

 

I'm sure that sprite split can safely work on the TI as it is working on the msx and on the coleco.

All you need is in the VDP status register.

Just read it in the ISR and wait until you get the right value.

Than swap the SAT and you get 64 sprites on the screen.

Nothing more, nothing less

Edited November 8, 2014 by artrag

[+OLD CS1]

How is it, can you modify the VDP at any time as long as you haven't enabled the interrupt? While I never programmed the TI-99/4A, during my experiments with the 2 MHz 6502 based Creativision, I found that without interrupts enabled, it seems like you can bang the VDP registers as desired but with interrupt enabled, you can only safely update the chip during vertical blank, which is when the interrupt kicks in.

 

The interrupt service routine does things with the VDP which assume it is the only process messing with VDP registers. As a result, the VDP is not in the same state as before the ISR.

 

As far as messing with the scan line, what about just a couple of service routines running in the F18A which trigger an interrupt for certain events. For instance, the F18A GPU triggers an interrupt when the scan line reaches line 128. The monitor ISR does not flake if IRQs are outside of the regular jiffy (1/60 second) interrupt, right? Maybe some pseudo-registers provided and serviced by an F18A GPU routine to do this.

[Asmusr]

The F18A already has a scanline interrupt, see here.

[+OLD CS1]

The F18A already has a scanline interrupt, see here.

 

Well, then! But then again, the question is about doing it on a real 9918A. At least until we can get the F18A declared a human right

[Tursi]

I've done tests of mid-screen modification of the 9918A registers on the TI, so yes, it works. You would need to use either polling or cycle counting from the vertical blank.

 

Polling has the potential of missing the update due to the internal status register races we detected previously, but as long as your method (5 sprites or collision bit) spans more than one scanline, you will not have any problems there.

 

Vertical blank always works, but you'll have to count cycles carefully and probably not be able to do much work while you're waiting (unless you're clever! )

 

There is generally a jitter of 2-3 scanlines in my experience. It's a little unclear whether this is just the timing of the CPU (in theory it's fast enough to catch a scanline though), or some internal lag on the VDP, or a combination of both. But if you can afford to leave a character row blank for whatever your change is, that will easily mask it. If you need a precise scanline change -- I'd love to see it but I have my doubts.

 

As for doing scanline tricks on the F18A, I did release a "true color" image display which changes the palette every scanline, and just last week I was experimenting on how tightly the GPU can work with the display of a single scanline. The GPU can manage a register change about every 8 pixels in a tight loop, but there are four gotchas to keep in mind:

 

First is that the F18A is displaying double the scanlines of the TI. So the end of line shows up twice for each TI line if you are polling. In theory we could use this for higher resolution graphics but I'm unclear where to store the data. You just need to be aware of this.

 

Second is that the F18A generates the line in two passes. First, it generates the line buffer, which contains lookups into the internal 64-color palette. After this is done, then the horizontal notification is triggered, while the F18A shifts the line out to the monitor. The point you have to remember about this is that you can change anything you want to at this point EXCEPT the actual color palette, because that will affect the image being displayed. (My high color display uses two 16-color palettes and trades them back and forth to avoid this being a problem - 64 colors on a 16-color display means lots of flexibility.)

 

Third is that any VRAM access by the host 9900 disrupts the timing of the GPU program. It's slight and probably won't be noticeable if you are only worried about scanlines, but if you want to do mid-scanline effects you must not allow the host 9900 to access the VDP during timing-critical points.

 

Fourth and final is that the VGA scanlines scan out VERY quickly, meaning the slightest hiccup in timing is very noticeable onscreen. Even a tight timing loop like I suggested above, running in GPU memory at 100MHz, had a jitter of about 6-8 pixels just based on where in the loop the actual screen event happened. There's no way I can see right now to tightly couple the GPU timing to the actual display, polling with 30-40 cycles of uncertainty is about the only thing we've got.

 

Of all of those, NONE of them are an issue for scanline-based effects. The GPU is more than fast enough and all the jitter added together doesn't come close to being a problem. The F18A could easily be programed to trigger screen, color, and sprite changes several times down the screen, meaning fantastic effects should be possible for zero cost to the 9900 CPU.

 

I should note too, that the horizontal interrupt on the F18A works great, but you have to program carefully since all interrupts come into the 9900 the same way. You need to figure out whether it was a horizontal or a vertical interrupt that triggered, and you probably should disable the console interrupt routine (means no LIMI 2) and poll via the CRU manually. Partially because the console interrupt will process for every VDP interrupt, regardless of which type it was, and partially because that will probably take so long the h-interrupt isn't useful by the time you get control. I'd say the GPU is a better approach anyway.

[Wildstar]

Definitely, an F18A VDP equipped TI using the GPU is the better approach for sure because it provides the tight loop and the GPU has matched clock frequency to the VDP and shares the same memory bus. So an FLI like trick to swap pallettes say every 16hx1v pixels (after all we would have the 4bpp bitmap mode IIRC) so we can swap the colors out of the 4096 color palette. It would give similar color palette to say a 12bpp color screen with caveats per 16x1 pixel attribute area. Not sure the available clock cycles left on the GPU for sprites for their layers but it can be very interesting nonetheless.

 

Whatever the case may be, the GPU of the F18A VDP would provide benefits very useful for advance graphics mode techniques.

[Tursi]

Definitely, an F18A VDP equipped TI using the GPU is the better approach for sure because it provides the tight loop and the GPU has matched clock frequency to the VDP and shares the same memory bus. So an FLI like trick to swap pallettes say every 16hx1v pixels (after all we would have the 4bpp bitmap mode IIRC) so we can swap the colors out of the 4096 color palette. It would give similar color palette to say a 12bpp color screen with caveats per 16x1 pixel attribute area. Not sure the available clock cycles left on the GPU for sprites for their layers but it can be very interesting nonetheless.

I don't think you will get it stable enough to do this -- this is in fact almost exactly what I was trying to do (except I was going for the tighter goal of every 4 pixels.) I updated my image converter to generate a 4 color image that changed 1 palette register every 4 pixels, sort of an Amiga HAM approach, and the results were great (AND the image fits in the 18k available)! BUT, you just can not sync accurately enough to the beginning of a scanline with the GPU to line up the color changes correctly. Even though my test suggested you could change about every 8 pixels, there was 4-6 pixels of jitter on every frame.

 

If you can come up with a way around that and just generate a test app that gives a stable dynamically updated image, we could probably run a long way with that!