F18A Zaxxon demo

[Asmusr]

This is how far a got trying to show the original Zaxxon graphics  on a TI-99/4A with F18A VDP replacement.

 

 

The graphics are using ECM3 mode with 8 colors per pattern or sprite from one of 8 palettes, in a resolution of 224x240 pixels.

The first challenge was to display the background, which is using 702 patterns - far more than the 256 patterns available. Luckily no single screen is using more than 251 patterns, which means I could dynamically load the new patterns after scrolling each column of 8 pixels. It also gave me just enough patterns (5) to add a tile layer 2 mask that covers the sides and the top/bottom slopes. There are no patterns left for text or anything else. The diagonal scrolling is no problem for the F18A, but it uses 4K VDP RAM for the name table (screen image table).

The next challenge was the sprites. They are generally 32x32 pixels (except for the rockets), so they are using a lot a resources. Since there was only VDP memory for 32 sprite patterns (8 32x32 patterns), I quickly ran out after picking just a few for the demo (no room even for the plane). I'm also running out of actual sprites (needing more than 32), which you can tell from some of the sprites blinking in the demo.

With a few KB extra VDP RAM for sprite patterns this could be turned into a game, but the graphics would probably have to be simplified in some cases. 

 

 

zaxxon8.bin

Edited March 2, 2021 by Asmusr

[+Schmitzi]

unbelievable what you do with this small computer

 

[+9640News]

Amazing!

[RedBaron]

As always you do a fantastic job getting Zaxxon going on the TI.  I still love my TI994a and would love to get a copy of the textured raycaster program from you ( I am willing to buy a copy from you when it becomes available).

[+arcadeshopper]

[broettger]

Impressive!

[jrhodes]

... Pardon me while i pick my jaw up from the floor ...
Why do we not have a "wow" reaction to posts?

Edited March 2, 2021 by jrhodes

[HOME AUTOMATION]

 Did, sort of...

[TheMole]

15 hours ago, Asmusr said:

The next challenge was the sprites. They are generally 32x32 pixels (except for the rockets), so they are using a lot a resources. Since there was only VDP memory for 32 sprite patterns (8 32x32 patterns), I quickly ran out after picking just a few for the demo (no room even for the plane). I'm also running out of actual sprites (needing more than 32), which you can tell from some of the sprites blinking in the demo.

With a few KB extra VDP RAM for sprite patterns this could be turned into a game, but the graphics would probably have to be simplified in some cases. 

 

Would it be possible to store the sprite patterns in the upper 2K of VRAM (0x4000 - 0x4800) in a simple compressed format and once per frame have a GPU program decompress and stream the compressed data to the sprite pattern table in regular VRAM depending on which sprite patterns are needed that frame? You'd still only be able to have 8 distinct 32x32 sprites on screen at the time, but you could conceivable have quite a few more patterns available compressed in the upper 2K to use throughout the level. You wouldn't be eating into the bandwidth available between CPU and VDP and I'm sure the GPU would be fast enough to decompress on the fly.

 

It could look something like this:

 - After the start of the HBLANK period, your main code uploads a full sprite list to VRAM, with pattern ids pointing to a virtual sprite pattern id containing all of the patterns used in a level.

 - At the start of the frame, a GPU program looks at the sprite allocation table to see which patterns are needed this frame

 - the GPU finds the compressed patterns and decompresses (max 8 32x32 patterns) them in the sprite pattern table in regular VRAM

 - the GPU updates the sprite allocation table so that each sprite entry points to the right decompressed pattern definition, depending on where in VRAM it ended up.

 

The big challenge will probably be writing a small enough GPU program to leave enough space for compressed pattern data.

[Asmusr]

3 hours ago, TheMole said:

Would it be possible to store the sprite patterns in the upper 2K of VRAM (0x4000 - 0x4800) in a simple compressed format and once per frame have a GPU program decompress and stream the compressed data to the sprite pattern table in regular VRAM depending on which sprite patterns are needed that frame? You'd still only be able to have 8 distinct 32x32 sprites on screen at the time, but you could conceivable have quite a few more patterns available compressed in the upper 2K to use throughout the level. You wouldn't be eating into the bandwidth available between CPU and VDP and I'm sure the GPU would be fast enough to decompress on the fly.

 

It could look something like this:

 - After the start of the HBLANK period, your main code uploads a full sprite list to VRAM, with pattern ids pointing to a virtual sprite pattern id containing all of the patterns used in a level.

 - At the start of the frame, a GPU program looks at the sprite allocation table to see which patterns are needed this frame

 - the GPU finds the compressed patterns and decompresses (max 8 32x32 patterns) them in the sprite pattern table in regular VRAM

 - the GPU updates the sprite allocation table so that each sprite entry points to the right decompressed pattern definition, depending on where in VRAM it ended up.

 

The big challenge will probably be writing a small enough GPU program to leave enough space for compressed pattern data.

It's a great idea, but the 3K data I have now zips down to 1.18K, so I don't know if 6K compressed would fit into 2K? I'm also not sure if 8 32x32 patterns at the same time would be enough? If the sprite pattern table could continue into the upper 2K that would solve it. But imagine if the GPU had something like 64K available, then we could do all kinds of crazy things.  

[Retrospect]

Very impressive!  

[fabrice montupet]

I really salute the challenge about the sprites. That said, I'm not impressed by these graphics on the 99/4A because the replacement VDP F18A offers anachronistic features and performances due to its years 2000 technology. I am more impressed by a program that pushes the limits of what the year 80 hardware can do than a modern FPGA based upgrade.
Take note that I don't say that the F18A is not a cool feature. Sure, Matthew made a very good work, I just say that I find the result less exiting due to the greater challenge using vintage hardware. It's just a personal opinion. No more.

Edited March 3, 2021 by fabrice montupet

[wierd_w]

the approach I would investigate first, is creative use of mirrored, or rotated data in the sprite definitions, to get "not easily noticed" edits of the graphic data, so that repetition/consolidation of the data can be increased.

 

 

Or, with realtime reconstruction of such patterns using bitwise manipuation to composite the needed data from a smaller subset of components. (4 unique glyphs can produce at least 64 composites, using just 2 of the 4 for each operation, assuming rotation and mirroring are permitted)

 

Such tricks are used to create tight tilesets for resource constrained systems, like the NES. (or at least, the sprite artists keep these kinds of things in mind; sprite-reuse in clever ways.)

 

The F18A has access to GPU function that could do bitwise stuff, iirc-- so it makes sense to try to make use of it.

[Asmusr]

14 hours ago, fabrice montupet said:

I really salute the challenge about the sprites. That said, I'm not impressed by these graphics on the 99/4A because the replacement VDP F18A offers anachronistic features and performances due to its years 2000 technology. I am more impressed by a program that pushes the limits of what the year 80 hardware can do than a modern FPGA based upgrade.
Take note that I don't say that the F18A is not a cool feature. Sure, Matthew made a very good work, I just say that I find the result less exiting due to the greater challenge using vintage hardware. It's just a personal opinion. No more.

Apparently you feel you have to say that every time I make something for the F18A. I can only guess about the reason... ?

 

But you're missing my point about displaying the original 1982 graphics. Not even a V9958 could do that. We don't have the 80s hardware that Sega used, which had features directly targeted at this game, but it's a good challenge for the F18A that pushes it to its limit.

 

https://segaretro.org/Sega_Zaxxon_hardware

Edited March 4, 2021 by Asmusr

[TheMole]

23 hours ago, Asmusr said:

It's a great idea, but the 3K data I have now zips down to 1.18K, so I don't know if 6K compressed would fit into 2K? I'm also not sure if 8 32x32 patterns at the same time would be enough? If the sprite pattern table could continue into the upper 2K that would solve it. But imagine if the GPU had something like 64K available, then we could do all kinds of crazy things.  

aPLib compression should be able to reduce sprite data to roughly 1 quarter of it's original size (though you might need to deinterleave the bitplane data for that), check out this implementation here: https://github.com/emmanuel-marty/apultra. That should turn those 6K of sprite data into roughly 1.5k. An aPLib decompressor on the Z80 is less than 200 bytes, so it could be feasible.

You could also take a look at exomizer, https://bitbucket.org/magli143/exomizer/wiki/Home, which also tries to provide an algorithm that can run well on retro-class hardware.

 

Agreed though, more memory on the F18A would open up a whole new world of possibilities!

[+mizapf]

7 hours ago, Asmusr said:

Apparently you feel you have to say that every time I make something for the F18A. I can only guess about the reason... ?

I believe that Fabrice just wanted to express our latent concern that with all those exciting new features, we gradually lose contact to our good old TI-99/4A, with its potentials and its limitations.

 

Since we have had quite many developments for the normal console, in particular from you, my personal concern is not as high today as it was when the F18A showed up.

[TheMole]

9 minutes ago, mizapf said:

I believe that Fabrice just wanted to express our latent concern that with all those exciting new features, we gradually lose contact to our good old TI-99/4A, with its potentials and its limitations.

 

Since we have had quite many developments for the normal console, in particular from you, my personal concern is not as high today as it was when the F18A showed up.

I guess Rasmus' point (although I probably shouldn't speak on someone else's behalf) is that these concerns have been expressed over and over again in the past and nothing new has been added to this discussion in quite a while. Some of us simply want to experience what it would've been like if the TI's architecture had continued to be developed for much longer than it has, and initiatives like the F18A or the StrangeCart are designed to address that need.

 

It's perfectly fine for people like yourself and Fabrice to not experience that same need, but it's really really hard to see the added value of repeating that very same position over and over again in each thread that discusses F18A implementations.

 

I mean this with the sincerest and deepest respect to you and others that feel the F18A detracts from the pure retro TI experience, but could we agree to disagree on the matter and just let this thread continue as an on-topic discussion of what can be done on the F18A for those of us that want to explore that avenue? If any of us feels the need to continue the discussion, perhaps we can create a new thread for it, or resurface one of the older discussions on the topic?

[+mizapf]

I do appreciate Rasmus' work, and the achievements with the F18A are really stunning. As I said, my concerns are much smaller today than in the past when some people already claimed this to be the "new standard".

[Asmusr]

5 minutes ago, mizapf said:

I do appreciate Rasmus' work, and the achievements with the F18A are really stunning. As I said, my concerns are much smaller today than in the past when some people already claimed this to be the "new standard".

Luckily no games of significance have been developed for the Geneve, or we could really have lost contact with our good old TI-99/4A ? 

[+mizapf]

26 minutes ago, Asmusr said:

Luckily no games of significance have been developed for the Geneve, or we could really have lost contact with our good old TI-99/4A ? 

While you're talking about it, I should really continue on my Arkanoid clone. ?

 

[Asmusr]

2 hours ago, TheMole said:

aPLib compression should be able to reduce sprite data to roughly 1 quarter of it's original size (though you might need to deinterleave the bitplane data for that), check out this implementation here: https://github.com/emmanuel-marty/apultra. That should turn those 6K of sprite data into roughly 1.5k. An aPLib decompressor on the Z80 is less than 200 bytes, so it could be feasible.

You could also take a look at exomizer, https://bitbucket.org/magli143/exomizer/wiki/Home, which also tries to provide an algorithm that can run well on retro-class hardware.

 

Agreed though, more memory on the F18A would open up a whole new world of possibilities!

By deinterleave, do you mean to store one bit from each plane after each other in a byte? Why would that be better for compression?

If go down the compression route, I would try lz4 first, because Tursi has already written a decompressor.

I actually have around 1.6K of the normal VDP RAM free as well (so 3.6K in total). But because of the bit planes I cannot use it for sprite patterns.

 

Here is the VDP RAM layout. The 640 bytes would be fine for storing the GPU code. If you can think of some clever way it could be rearranged to allow for more sprite patterns, let me know.

nametb equ  >0000                      ; Name table base
namet0 equ  >0000                      ; Name table page 0 
(64 bytes free)
namet1 equ  >0400                      ; Name table page 1 
(64 bytes free)
namet2 equ  >0800                      ; Name table page 2 
(64 bytes free)
namet3 equ  >0C00                      ; Name table page 3 
(64 bytes free)
ptrntb equ  >1000                      ; Pattern table base
ptrnt0 equ  >1000                      ; Pattern table plane 0
ptrnt1 equ  >1800                      ; Pattern table plane 1
ptrnt2 equ  >2000                      ; Pattern table plane 2
nam2tb equ  >2800                      ; Name table 2 base 
(64 bytes free)
tilatb equ  >2c00                      ; Tile attribute table
spratb equ  >2d00                      ; Sprite attribute table 
(640 bytes free)
sprptb equ  >3000                      ; Sprite pattern table base
sprpt0 equ  >3000                      ; Sprite pattern table plane 0
sprpt1 equ  >3400                      ; Sprite pattern table plane 1
sprpt2 equ  >3800                      ; Sprite pattern table plane 2
(1024 bytes free)

 

[+FarmerPotato]

1 hour ago, Asmusr said:

By deinterleave, do you mean to store one bit from each plane after each other in a byte? Why would that be better for compression?

If go down the compression route, I would try lz4 first, because Tursi has already written a decompressor.

I actually have around 1.6K of the normal VDP RAM free as well (so 3.6K in total). But because of the bit planes I cannot use it for sprite patterns.

 

Here is the VDP RAM layout. The 640 bytes would be fine for storing the GPU code. If you can think of some clever way it could be rearranged to allow for more sprite patterns, let me know.

nametb equ  >0000                      ; Name table base
namet0 equ  >0000                      ; Name table page 0 
(64 bytes free)
namet1 equ  >0400                      ; Name table page 1 
(64 bytes free)
namet2 equ  >0800                      ; Name table page 2 
(64 bytes free)
namet3 equ  >0C00                      ; Name table page 3 
(64 bytes free)
ptrntb equ  >1000                      ; Pattern table base
ptrnt0 equ  >1000                      ; Pattern table plane 0
ptrnt1 equ  >1800                      ; Pattern table plane 1
ptrnt2 equ  >2000                      ; Pattern table plane 2
nam2tb equ  >2800                      ; Name table 2 base 
(64 bytes free)
tilatb equ  >2c00                      ; Tile attribute table
spratb equ  >2d00                      ; Sprite attribute table 
(640 bytes free)
sprptb equ  >3000                      ; Sprite pattern table base
sprpt0 equ  >3000                      ; Sprite pattern table plane 0
sprpt1 equ  >3400                      ; Sprite pattern table plane 1
sprpt2 equ  >3800                      ; Sprite pattern table plane 2
(1024 bytes free)

 

That's already a neat VDP layout.

 

The sum of the holes would be enough to hold 64 more sprite patterns...

 

But I don't see a way to rearrange it. The stumbling block is that Name Table 2 must have a contiguous 1K block.

To get more sprite patterns, you need 2K boundaries. When using just 192 of the patterns, there are two 512 byte holes. No contiguous 1K for the Name Table 2.

 

So you'd have to give up having Name Table pages 0-3. 

 

Could your scrolling be adapted to use just  two pages? I would mask off the top row, and refill it after 8 pixels scrolled.

 

 

[Asmusr]

18 minutes ago, FarmerPotato said:

Could your scrolling be adapted to use just  two pages? I would mask off the top row, and refill it after 8 pixels scrolled.

That's a great idea, but using two vertical pages would be better since I'm already masking 2 columns on each side of the screen. I would have to scroll the name table for every 8 pixels, but the GPU could do that.    

Edit: I was originally working towards showing all 32 columns, so I didn't consider this options. Later I found that 32 columns would require too many patterns, so I added the masking.

Edited March 4, 2021 by Asmusr

[Asmusr]

15 minutes ago, Asmusr said:

I would have to scroll the name table for every 8 pixels, but the GPU could do that.

Or actually I would scroll the name table for every 16 frames, 2 characters left and one down, at which point I would move reset the scroll registers. If I masked the top row I could get away with a single page name table, but I won't go down that road until I need the extra RAM.

[ti99iuc]

I really like everything done for the TI99/4A, in F18A or not. With the AlexKidd game that had a dual game version, one for an F18A and another for the standard /4A, I also had a lot of fun trying both to see the differences. Same thing was happened with the TI-Scramble game. I am also always curious for a Super Mario Bros on the stock TI99/4A standard ? 

Anyway Zaxxon for the F18A seems to be very interesting challange.

Edited March 5, 2021 by ti99iuc