The H5 roadmap

[mrbombermillzy]

I don't know much about Blitter coding.. I did read your other blitter post, but still no wiser of course I'm always open to improving things if it's simple and not likely to break anything..

I dont mind elaborating, if you dont mind slight topic derailment...for a little moment!


So, lets look at how to display a typical 'sprite' or more correctly (as we are not using a C64 and the subject matter is relevant) blitter object - BOB - over a non blank background.

This is how it works for most 'frame buffer' type computer systems with no custom/game optimised sprite/BOB hardware. That includes the ST/F030/TT/MegaST/e of course!

Also, Im describing things from a chunky (otherwise known as 'packed pixel') screen arrangement, as this is also part of the speedup process and avoids confusing matters with planar complications.

Anyway, lets get to it...

We have to do 3 blits:

1. The BOB single colour mask:

As the ST doesnt have the operation I am proposing to add, we have to add a mask to draw any image over the background that isnt a square shape. (This is also known as a cookie cutter mask). What this is, is a single mask colour of the BOB/sprite.

[THIS IS THE STEP THAT CAN BE REMOVED WITH THE PROPOSED EXTRA OPERATION ADDED!]

2. The BOB image:

This is the actual 'full colour' version of the above image. Same shape, but now with colours. We can apply this without also drawing the square shaped BOB border because we do infact have a blit operation (the AND op.) that says 'copy data if the source AND destination are true.

Of course, as long as the mask (step 1) had all the actual pixels to display set to the value that would cause both source and destination to flag as both being set (or true), this would then draw *just* the pixels inside the square BOB block (and not the borders).

3. The background restore image:

This is only needed if the overlaid BOB image is either moved, or changes its animation frame and just basically restores the background (and essentially makes the BOB disappear!)

We then rinse and repeat steps 1-3 ad infinitum...

Hope that makes sense?

Obviously, Ive missed out draw timing, as you want to keep step 2 on screen as long as possible and only do the rest at the appropriate screen raster position to avoid the image flickering, but lets not go overboard with the unnecessary (from an explanation of the blit cycle perspective) details.

[ijor]

I was chatting to @ijor some months ago about speeding up the blitter. I think it was giving the blitter direct access to RAM without having to do bus cycles.. but really can't remember now

I think mostly my thoughts were trying to reduce the amount of time the blitter "hogs" the bus for, because it takes time away from the CPU for starters. If we have the bandwidth to RAM, the blitter doesn't have to be "locked" into 8MHz or 32mhz even. Its all internal in the FPGA, so it can go as fast as RAM will allow. I'm just pulling numbers out of my a$$, but think like 100MHz blitter even if the CPU can only manage 16MHz kind of thing.

But you would have to convince @ijor about adding new functions into the blitter. I think @Cyprian was also asking similar a while ago.

There are two different types of possible improvements for Blitter. Or two very different scenarios, if you want. One is for a standard ST/STE board replacing an original Blitter (but possibly with enhancements). The other is for a future Phoenix hardware using some kind of combined FPGA chipset.

What we talked with @exxos at that time was for the second case. The idea is that with Blitter closely coupled with the RAM, it can operate as fast as the RAM allows. Using, say, SDRAM, as the ST536, you can easily transfer from/to RAM at 64 MHz or even 128 MHz. And as long as the RAM can be used exclusively during the Blit (say, during Vertical Blank), and as long as the Blit is large enough to be able to use bursts, you can transfer one full word per cycle. At 64/128 MHz that would be 32/64 times faster than a standard Blitter working at 8 MHz and using 4 CPU clocks per bus transaction.

You can do the math yourself to compute how fast you could copy a full screen ...

But you would have to convince @ijor about adding new functions into the blitter.

Yes, indeed. But somebody first would need to convince @Exxos or @Icky , or somebody else, to build the hardware because otherwise the new Blitter functionality will be available only for the Phoenix Blitter prototypes we have

[alexh]

To get anyone use "new blitter functionality" I think it has to be targeted at a drop in replacement for ST/STe Blitter. Ideally with updates to STeEm/Hatari/SainT emulators and MiST/MiSTer cores at the same time.

I do regularly see people say "I wish the ST/STe Blitter was more like the Amiga Blitter". While I cannot give a technical reference today (I'll look it up) if anyone who uses the blitter on both systems (Leonard of Oxygene? KK of Altair?) could comment that would be the best feedback.

[ijor]

To get anyone use "new blitter functionality" I think it has to be targeted at a drop in replacement for ST/STe Blitter.

Well, yes. The idea of an "enhanced" combined chipset platform doesn't excludes smaller enhancements to the classic ST as well. But note that even for a drop in Blitter replacement there is still need to build the hardware. Of course, this is much simpler hardware to build than a combined chipset.

I do regularly see people say "I wish the ST/STe Blitter was more like the Amiga Blitter".

I have (or at least, had) no idea about how the Amiga Blitter works. I took a quick look to a couple of online references. From what I can see, Amiga can do such things as to operate in two separate source blocks, while Atari Blitter can only read from a single source memory area per blit. Amiga Blitter can also draw diagonal lines, etc. But, if I understand correctly, possibly the most important capability is that the performance can be as fast as almost twice than the Atari Blitter. And again, this is because it is integrated in the main chipset.

This contrasts with Atari Blitter that operates completely independently from the chipset, and works as a standard 68000 DMA device. The advantage of this approach is that can access any device in the bus. E.g., Atari Blitter can read from ROM, which is very useful for accessing TOS data. I understand that Amiga Blitter can only access chip RAM.

[exxos]

@ijor I will post back in the blitter thread about it all..