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 (288.95 KiB) Viewed 1577 times
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 (266.38 KiB) Viewed 1577 times
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.
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.
I will include the list here: (in order of effectiveness IMHO):
