Mucking around on the...ATW800/2

[mrbombermillzy]

A new branch of my 'Mucking around on the...' series.

Ok, so Ive finally found time to fix the palette problem and here is the first pics of my game engine progress on the ATW800/2 Seurat FPGA:

MK1.JPG

MK2.JPG

As like the ET4000 thread though, there is no support for the lower than 640x400 resolutions.

If thats the case, then so be it; I will have to adjust the assets for the larger 640x480 screen, but Im hoping there is a way.

Anyway, this build is pretty similar to the ET4000 onel i.e. at a fairly basic level... not much more than a proof of concept demo with some joystick movement, but its slowly progressing. Actually, its more 'wide screen' at 400px wide for now (same as the 'real' MK CPS arcade machine). :lol:

As its not clear in the current version of the manual, I will just mention that the Seurat colour look up table data needs to be in word size per palette index, with the colours set to: R5G6B5.

I can probably push things forwards a bit, but Im actually waiting for some information regarding the internal blitter (as well as the low res screenmodes), which will improve screen draw drastically. As you may know from my other thread, the ST blitter (in HOG) is doing all the pushing across the ST<>ISA bus in this build, so not really ideal.

More to come later, I guess.

[Darklord]

That's looking pretty good. :)

I've been following the pertinent thread
over at Atari-Forum as well.

Thanks for the work on this.

[mrbombermillzy]

That's looking pretty good. :)

I've been following the pertinent thread
over at Atari-Forum as well.

Thanks for the work on this.

No problem. Glad you like it. :)

However, its probably going to be a bit of a wait for the next post, as we will need to see when more tech info for the GFX HW materialises, as well as the fact that I need to learn some Occam *and* design some sort of subsystem to use it.

[mrbombermillzy]

Ok, so this is an update, which, rather than being any big steps in progress, is rather an explanation of the looming brick wall in the current methods employed with a look to future alternatives.

So to start with, a confirmation of blit speeds:

P1050164.JPG

This is a simple block shift, from ST RAM to Seurat screen VidMEM using the ST Blitter.

Whilst static images do it no justice, I have tried to gauge the biggest size block that can be moved before juddering sets in.

Oh and before I forget, I am syncing with a polled VBL flag which seems to work well 'as is' (i.e. executing the blit transfer as soon as the VBL is flagged, rather than adding xx amount of NOPs to wait for the absolute best raster position).

For the programmers out there, this VBL flag is part of the 2D Block Move Status Register at byte $dff911 (MegaST), $bff911 (MegaSTe) and $fedff911 (TT).

The relevant bit is bit[1]: 0 = on active display, 1 = on VBL

So, ST blit throughput affirmations...

P1050163.JPG

After several block size tests, I found that blitting a moving 400px wide image is smooth , up to around a ~100px image height, where beyond that value the image starts to exhibit a jerky movement (suggesting an overburdened blit for the frame time available.

This then assumes a ~40Kb/frame ST blitter throughput figure (400x100 bytes = 40Kb), which seems to tally with the ST frame completing in ~160256 cycles - the blitter taking 4cyc per pixel drawn (in direct copy mode; no ops): 160256/4 = 40064.

Therefore, with the blitters operators being thrown in the mix and halving the speed to ~20000 bytes per frame when drawing the characters, this would allow for (just over) a 128x140 blit for the MK demo characters. (We currently need 3 of those blits per frame AND per character for smooth animation/movement! For a 50/60FPS framerate anyway) :(


We therefore, at least as an option to circumvent the above limitations, need to look towards what the ATW800/2 Seurat blitter can do for us...


The current iteration (as of 1/9/25) of the Seurat blitter FPGA engine only allows for straight (but fast!) block copying; i.e. no 'cookie cutter' type logical operations are available for applying from source to destination transfers.

Whilst this point is constrictive, the limits can be minimised by some careful consideration.


For instance, the Seurat blitter can be used to blit character image blocks over the background, as well as performing a background restorative blit, meaning the ST blitter only needs to blit the background 'around' the character, as opposed to the three blits it would have to otherwise do. (Thats a 66% reduction in ST blitter throughput, offloaded to Seurat!)

This would require that both the ST and Seurat blitter have access to the same background graphical data.

Providing the restorative background area is limited to =<38Kb - which is possible with regards to the scope of the MK demo at least - it can be perhaps stored in the ATW 'shared RAM' area and prevent the background data from having to be stored in both the ST RAM and the ATW vid mem. In this case, the whole of the 2-4Mb ATW vidmem can be used for screen display purposes and to store just the character graphical data.

So while the screen uses - at the minimum 640x400 - 256Kb (at 8bpp), that would then leave 1792Kb (on a 2Mb firmware) or 3936Kb (on the 4Mb firmware) for character data.

This may sound sufficient, but considering that:

1.) Seurat cannot display a screen less than 640x400 and...
2.) There are no provisions (on either the ST or Seurat blitter) to either scale or 'smear' images; i.e destination step size can be doubled, but the 'in between' pixels will not be touched, there is still an issue here.

To work around this problem, any source assets sized for a (e.g.) 320x200 game will either need to be physically doubled in horizontal as well as vertical size and blit at that size, hence quadrupling the needed VRAM space and the blit size requirements, or (perhaps a better option) the blit operation(s) will need to be done four separate times on the Seurat blitter (four identical blits, each being displaced 1px in the H and then V axis' respectively) and the ST operational blit will need to be done once, but quadrupled in size (reducing both the ST and Seurats graphical blit throughput to 25% of their maximum potential). As the Seurat blitter is quite fast, the extra overhead will have less of an impact; the ST blitter being the concern here.

Hence there is a (hopefully obvious) choice between VRAM expenditure and blitter throughput expenditure OR just blitter throughput expenditure.


Ultimately, the best solution will be to stop mucking around in the ST facing world and traverse 'through the looking glass' into Transputerland, where we can use any number of parallel chips to process the logical operations - amongst other things - which can then rely solely on the Seurats super fast block transfer to do the rest.

The ST blitter is then free of its screen transfer duties and can be used for additional (relatively smaller) blits, sample playback or something else.

So finally, if the next update is a while away, its because:

1.) I have a computer show to organise/ family to tend to/ job to work. :lol:
2.) I am learning Occam (slowly).
3.) I am designing a system based on the above discussed issues and points, which makes the best use of the Transputer card for the manipulation of 2D objects in real time.
4.) I am coding a similar framework for several other 65xx/680xx systems.

Watch this space I guess. :coffee:

[agranlund]

Ultimately, the best solution will be to stop mucking around in the ST facing world and traverse 'through the looking glass' into Transputerland, where we can use any number of parallel chips to process the logical operations - amongst other things - which can then rely solely on the Seurats super fast block transfer to do the rest.

That does indeed sound like the best way forward. I assume the internal Transputer has quite fast access to vram?

Or ask very nicely if they plan to implement a source-transparency option for the Seurat blitter :)
For the most part I don't think it would even have to be a full-blown user configurable thing.
You can make most scenarios work even if it was hardcoded to skip source pixels of value 0 (when transparency option is enabled).

[mrbombermillzy]

That does indeed sound like the best way forward. I assume the internal Transputer has quite fast access to vram?

Ultimately, this is relative and it all depends on whether 'feature x' is implemented, or not. But to answer your question, yes, its fast.

Or ask very nicely if they plan to implement a source-transparency option for the Seurat blitter :)
For the most part I don't think it would even have to be a full-blown user configurable thing.
You can make most scenarios work even if it was hardcoded to skip source pixels of value 0 (when transparency option is enabled).

I have infact drawn up and sent to the relevant parties a short-list of 'must have' updates for to the FPGA firmware - the no.1 item being exactly what you describe above. For any other fellow blitter designers out there ;) I will include the list here: (in order of effectiveness IMHO):

1.) Add a 'S>D IF S !=' logic operation to the Seurat blitter. (See C64DTV blitter specification).
2.) Add a scaling operation to the Seurat blitter (can have fractional scaling). (See C64DTV blitter specification).
3.) Integrating a S&H (sample and hold) or 'Smear' function onto the ATW display HW or blitter. (See Atari TT Shifter specification).

(No.3 becomes obsolete if no.2 is available).

To be fair, Axel has actually taken note of some of my ramblings, so hopefully we may see some exciting developments prevail in the future.

And if not, there already plenty of scope left for other ways to alleviate the problem. They just take more time, planning and knowing they are the only option available. :)

[Cyprian]

Jaguar's blitter could be used as a reference (as far as I remember Richard Miller was somehow involved into both Jaguar and ATW800's Blossom blitter). It can scale the image and also it supports sprites with transparency.

https://www.hillsoftware.com/files/atar ... jag_v8.pdf

[mrbombermillzy]

Jaguar's blitter could be used as a reference (as far as I remember Richard Miller was somehow involved into both Jaguar and ATW800's Blossom blitter). It can scale the image and also it supports sprites with transparency.

https://www.hillsoftware.com/files/atar ... jag_v8.pdf

The Jag blitter does look good. (Im hoping we get something good for the H5 soon. I wonder if there has been any progress?)

And similarly (just to highlight the differences), the DTV blitter will allow my 65xx based version of the game engine to outperform the ST/Amiga just through having (amongst other features) 2 extra things: The transparency option (as discussed above) and chunky pixels. Its a shame its a bit broken in the v2 version. :(

In the case of the ATW800/2, Im confident that the lack of blitter features can be made up for with the Transputer(s) ability to manipulate the VRAM, but Im just making the point that little additions can save lots of extra work and for specific features increase performance levels significantly.

IMHO, the ideal 'holy grail' game system would have a feature rich blitter fed by a co-processor, neither of which steal cycles from the main CPU or saturate the bus.

With the ATW card, I think we are *nearly* there (providing TRAM<>VRAM data bandwidth is good enough - do we have concurrent/multi-port VRAM access here?).

It would be smashing to just have the - even one - extra feature(s) from the list in the post above.

But like I said, even if nothing more is updated, Im sure we have a rich enough scope with the card even now to allow something special with just some good design and hard work. :)

[mrbombermillzy]

Ok, so considering what was discussed above - and due to being asked for a demo - here is a slightly more fixed/polished version of the ATW800 Seurat display build MK Demo:

TBLIT014.zip

MKdemo.jpg

Dont expect too much though. In fact, dont expect anything, as its an abandoned build, just chucked out in its (more or less) raw unfinished state.

Ive just tidied it up a bit and put it here as a courtesy. Its the end of the line for this particular direction, so there wont be any more progress with the current HW used in this particular way.

With that in mind, you have the following caveats:

* This version is for the Mega ST with 4mb (2mb may work, but Ive not tested) + ATW800/2 (If enough people are interested, I can probably knock up an STe and/or TT VME version, if asked nicely).

* The GFX assets are not optimised whatsoever, so the .PRG will take a hefty ~1.7Mb footprint on your Atari; (~100Kb zipped :lol: )

* Its a 400x240x8bpp game screen, but due to limitations, must be run at 640x480x8bpp mode from GEM and will be in a smaller window/area in upper left.

* Character is VBL synchronised with blit execution, but alas (due partly to the above resolution) the poor ST blitter can only cope with just over a third of the required data per frame, so we have a very stable tear/flicker on the main character (see earlier post of mine with the pictures for more detail).

* I havent included a character boundary, so he can walk off the side of the screen. (Did I mention, it isnt a full game? ;) )

* It requires a 'real' Atari Keyboard, or one that emulates it accurately (such as the new ImpoSTer FW), as it makes extensive use of a reprogrammed Hitachi 6301.

* It requires a Joystick/pad in Port 1.

* While the FIRE button exits to GEM, its in no way clean; palette is messed, mouse input deranged.



Other than that, you can use the L/R positions to walk, up to punch and down to kick.

I hope someone likes it. Have fun. :D

[Darklord]

I understand that it's not specifically for the Mega STe but will it still run on it?

Thanks much.