Blitter investigations and research from a software perspective

[mrbombermillzy]

As I no longer have access to a TT or F030 and actually DO have a Mega ST here, I've decided it's time to try to inverstigate the Blitter chip and see what possibilities are practical for graphics.

I also need to try to make practical use of the twin shifter board, which @sporniket was so very kind to build for me and for which I do not have any software of 'substance' with which to show it off. I would very much like to repay his patience with something special, but whether that is possible remains to be seen.

I have very little experience working on the 68000/ST computer, so have to learn the ways of the base 68000 architecture (I already know I will miss the bitshift instructions and the more forgiving memory alignment! :lol: )

So my plan of action and investigation will progress something like this:

1. Blitter write granularity tests (so that I can see exactly what I am dealing with on the maximum writes per raster front).
2. Possible optimisations for dealing with limitations in (1.) I may be able to transfer some of these from similar work on the TT previously.
3. Use of the above on the twin shifter board to achieve an enhanced image display or possible game sprite application.
4. Use of the above on a Megabus ET4000 VOFA board to achieve an enhanced image display or possible game sprite application.

As a 'by product' of the above research, I will have various types of visualisation and/or test code, which should help check if the timing credentials for the Phoenix Blitter are correct. Although they might not do much, or appear 'broken' from a application building point of view, I believe there is no such thing as broken when it comes to testing variances in blitters; they just need to exhibit the exact same behaviours in whatever manifests in the actual test code.

With that in mind, let us begin.

1. Blitter write granularity tests

Ok, so the best way to 'see' how fast the blitter can write (we are keeping if simple and doing a direct source>destination blit) is to blit a number of writes to the background colur palette register (colour 0) and actually see how long it takes (in pixels) to re-write the register:


So, like posted before, here is a group of 16, 2 and 9 writes respectively. (Note that I am using colour data from an image, rather than spending hours hand crafting some contrasting colours out of the fractured 9 bit STFM/MST palette. If someone has any RGB+mixes fading to black colour values formatted for the correct bitwise ST palette, let me know and I can insert them.) Also note screen colouring is just to make blit/pixel counting easier as there are cycles of 16 colour 'bands'.

Suffice to say, although the colours are not different for every write because of this, an 8px write time for each of the 16/2/9 writes can be seen. Bear in mind that if the palette stops being written in the middle of a line of the same colour, it will display the same colour through the rest of the screen (as is clearly the case in the last two pictures). You can see what is the case from reference to the first picture.

Like I said, not 100% ideal, but it's 'good enough' to show what's going on at least:

16 writes:

Picture1.JPG

2 writes:

Picture2.JPG

9 writes:

Picture3.JPG

Here is the program for the 16 blit example (Picture 1) together with a jitter of between 40px to just under 1 raster).

Like I said earlier, this isn't wrong, it just needs to do exactly the same on the Phoenix Blitter to prove that it is working to spec (i.e. as close to a real Blitter as possible). Having everything hunky dory and in perfect sync may not show up any faults where there may be some.

65KBLT08.zip

Moving on...

As we have produced code with jitter, I guess it's time we now moved onto having perfectly stable sync locked code. :D

A few caveats of having stable sync code though; We can't (unless there is a way I dont know about?) sync to any part of the background display, so I have had to sync to the beginning of the first line of the foreground display area. This also brings up the problems of 1. having to change the foreground colour display all to background colour, so the blit results can be seen and 2. the actual time the bit takes to prepare now starting the first write in the middle of the first raster.

This would put some of the otherwise visible writes into the border area, so whilst I was blitting small amounts, I added some delay NOPs to bring it to the start of the next line instead.

Anyway, after some mucking about with getting the blitter to re-write the whole 16 colour palette continuously (in HOG MODE, I might add), we can show the result of 50 full palette (x16) writes:

Picture4.JPG

And here is the program:

65KBLT11.zip

So, to conclude, (unless someone can enlighten me to any errors in my methods; please do!) as a last effort to see if there was any 'free blits' by writing more than one register at once, I can see that it makes no difference, as writing the full palette of 16 words result in the same amount of blit time. In the last picture that being (8x16=128) 128px lines per 16 colour blit. (Remember, only colour 0 can be displayed on the background, so it stays on that colour until all the other colours have been written).

That's probably enough for now (and probably enough material for someone to pick holes in my research methods!).

Unless there is a substantial fault in my findings, I will move on to goal (2.) next time.

P.S. Apologies for not having everything 100% perfect. I have enough time to get things 'good enough' to prove, but if I tried to get everything perfect, none of this would even see the light of day. :(

[Steve]

I think the best software-related person to ask about blitter is perhaps Anima, He is on Atari-Forum, not sure if he is here though.

[dml]

The blitter timing is mostly straightforward, in that it is based mainly on the number of memory accesses required per 'word' processed - the internal logic for the word operations are free. e.g. if you are blitting from internal halftone memory this doesn't count as a memory access so the word is processed in less time.

However it gets more complicated when you take into account the patterns of words involved in a blit task, if there is a fetch at the begin or end of a line (for a scrolled blit) and which masks are active and so on.

You can get a clearer picture of these corner cases by reading source for one of the emulators (e.g. Hatari source) but in short, the timing complexity is hidden in the configuration of the blit task - the pattern of words involved - and not so much about what happens per word transferred.

The actual per-word cost is +4 cycles to read a real memory source +4 cycles to read the destination (for logic combine cases) +4 cycles to write the destination. That's a max of 3 sources but it can be as few as 1 source (for a fill or clear).

Then you have endmask registers, which can turn off a read if the net effect (when masked) would be a no-op for that word. And there are 3 of these (begin, middle, end of a scanline). And when scrolling a line, there can be an additional (single word) source pre-fetch and an optional (single word) source final fetch, configured by more register bits. And then you have other details like a bus arbitration delay on a blit start. And bus-sharing mode which time slices between CPU and blitter access to the bus. Anyway no point in detailing everything here in a confusing blob - but probably enough to get the general idea of where to look for differences.

[Cyprian]

great topic
I did in the past some tests regarding interaction the BLiTTER with the CPU: https://exxosforum.co.uk/forum/viewtopi ... &start=190

Below one of them, the BLiTTER runs in blit mode (nonHOG). In that mode the bus is shared between the BLiTTER and the CPU.
Both tests below have the same the BLiTTER code interleaved with :


1) MOVE.W instructions:

BLiT_H6a4g.png

2) DIVS.W instructions:

BLiT_H6a4c.png

Black lines - the BLiTTER, white/gray/red the CPU

We can see there that the CPU can delays the BLiTTER activity, because it counts the bus usage (64 or 63 - @ijor can explain it in detail) which is very low in case of DIVS, and waits if needed.

[mrbombermillzy]

Thankyou for the timing example @Cyprian

@dml Thanks for chipping in here to give a general overview of the timings. :)

I'm curious about the practical applications for the halftone RAM.

So, in effect, (I assume after a quick study) it can be used a bit like a fast 16 word cache RAM?

[dml]

So, in effect, (I assume after a quick study) it can be used a bit like a fast 16 word cache RAM?

Yes you can store 16 words in there and blit from them - or combine them in logic operations with another memory source. It is intended for 16x16 pixel pattern fills on a single bitplane but you can find other uses.

[mrbombermillzy]

... but you can find other uses.

Oh, that's definitely going to be attempted here. :twisted:

So, it appears that the faster throughput examples are achieved by using halftone RAM exclusively without a logic combine operation (from source or destination)?

[dml]

So, it appears that the faster throughput examples are achieved by using halftone RAM exclusively without a logic combine operation (from source or destination)?

Yes. There are up to 3 distinct data sources or memory accesses for each word processed.

All 3 can be real memory for a RMW style combine (e.g. dst = dst AND src)
...or you can use halftone as a source which means only 2 memory accesses (dst = src AND halftone)
...or you can select a logic op which does not combine at all, meaning only 1 memory access (e.g. dst = halftone)

And for a simple set or clear, you can select a logic op which is all 0's or all 1's and bypasses halftone. Although it not quicker, since no memory sources have been removed.

Halftone has an automatic addressing index, which is based on the y counter. If you exchange x/y counters around and fix the src/dst inc's accordingly you can pretend it is indexed by the x position instead of the y position. You can also set the halftone index position via a register (line field) but that takes time to write the register, so automatic address indexing is the only really effective use I think when you want to use multiple halftone words.

[mrbombermillzy]

Halftone has an automatic addressing index, which is based on the y counter. If you exchange x/y counters around and fix the src/dst inc's accordingly you can pretend it is indexed by the x position instead of the y position. You can also set the halftone index position via a register (line field) but that takes time to write the register, so automatic address indexing is the only really effective use I think when you want to use multiple halftone words.

Thank you Doug. This is food for thought right here and definitely worthy of further research in this direction.

I will have a little play (at some point) and see what prevails.

[mrbombermillzy]

.

So after diving down the rabbit hole that was HT RAM as per @dml's posting above, I tried it out: (Notice, I've been busy, creating some 'proper' test colours this time? lol)

Picture6.JPG

...and true enough, eliminating any unneccessary extras (like reading a source address!), gave a blit granularity of 4 cycles (or pixels in the visuals above).

However, after the initial excitement of the double blit speed, the reality set in on the horrendous HT RAM reload penalty; (around 168 cycles by my calculations). I even tried a funky cheat method from my TT colour optimisations, but due to one thing or another, that brought the re-load down to a (still completely impractical) 132 cycles.

Anyway, I thought perhaps it may be worth a look, but as it stands, I can use it to blit 32 colours, with changes being made a very long distance apart. If you consider, just using the CPU can manage that, with the spacing between writes being far more regular, it sort of becomes useless for what I am trying to achieve.

I guess you could use it for some sort of 16 colour 'low res' * full overscan display on a demo or something.

If anyone has any further insights into how the HALFTONE RAM can be better harnessed, I'd love to hear them.

Otherwise, it's back to looking into the more conventional source>destination blit (at 8px/blit).

(I may at some point have to start some new thread concerning other areas of the ST video hardware that may crossover into this area of research).

Here's the code:

65KBLT13.zip

(Like I said before, I will supply all code snippets, if anyone wants to try it on the Phoenix blitter to check it's displaying the same as the picture above. There is a bit of exact setup/re-load and NOP delay to get the perfect colour blit pillars, so it could be useful from a timing point of view).

* 'Low Res' meaning 104px per raster line

.