BLITTER RE-CREATION THOUGHTS

[ijor]

There is very little space on the mega glitter other than literally behind it. Which would then require a custom board to fit that machine.

If you want a smaller board, we could use the smaller M153 MPGA packaging. You could even save a couple of bucks in comparison with the U169 package. Or the finer BGA pitch complicates routing too much?

It is also possible to use more compact level shifter parts. There are some parts with more channels and also with less power pins. But yes, the GTL parts we have been used are well tested. Different parts might require some additional testing.

Going back to the question about what boards the new blitter will be used on.. Primarily it is going to be of course the H4/H5 platforum as it will be all integrated in the new chip set. ... Problem becomes of what of other machines like the mega..

I agree with @mrbombermillzy. I would recommend working on a small batch just for the H4/H5, targeting core enthusiasts, as he call them, testers and interested developers. Forget about expensive stencils (are they really needed?) for achieving super precision or purchasing 200 FPGA chips.

I was specifically asking about the 10M02 as its going to be the smallest and cheapest. I may have to buy 200 to get a good price on them. But then it's unlikely anyone is going to buy 200 blitters.. The costs involved are not exactly going to be cheap.

As far as I can see the 10M02 on M153 packaging is just about U$8 on Mouser in single units. A couple of extra bucks if you want the U169. Price seems to be the same in USA or UK. Are you seeing something different?

A replica that is more expensive then the original (although hard to get) is not a viable solution.

Well, the original is hard to get, now already. Eventually, and probably sooner that later, it would become extremely difficult to get at a reasonable price. At some point you won't be able to repair STE boards without newer Blitter parts.

Will follow up the technical issues in a separate message ...

[ijor]

If we run the blitter double speed, we can actually do 2 accesses to RAM in the same time slot. Of course you need memory to keep up as well.
So if you have 32MHz blitter and 32mhz capable RAM, you can do 4 blitter RAM accesses instead of 1. So you have a 4x speed up by doing basically nothing.
I think what @ijor mentioned, is when the shifter is outputting the border colour, its not accessing RAM at all.

Exactly. Blitter, potentially, could drive the RAM at its maximum speed and perform one RAM access per cycle. The CPU always takes (at least) 4 cycles for any access, no matter what, even when accessing non-shared FAST RAM.

But this would require a Blitter closed coupled to the RAM. It won't be possible to do this with the standard chipset on a standard motherboard.

Which now makes me wonder about the video accesses @ijor as won't the shifter be only loading 1 word at a time from SDRAM ? That would be "expensive" (or "slow") if the SDRAM first access is going to take like 60ns.

Yes, but there are all sort of possible techniques to workaround the SDRAM latency, at least partially. I would need to review my notes and our email exchange. But since SHIFTER access is mostly sequential, it is possible, e.g., to use some kind of video RAM prefetch and buffering.

The faster you make the H5 system, the less need for a 'regular' or 'unenhanced' blitter ...

This is partially true. But even with a standard Blitter you get shifting for free and the CPU is extremely slow to perform shifts. Unless you would install a 68020 (that has its own barrel shifter) based accelerator, then Blitter could always be faster when shifting is involved.

[mrbombermillzy]

If we run the blitter double speed, we can actually do 2 accesses to RAM in the same time slot. Of course you need memory to keep up as well.
So if you have 32MHz blitter and 32mhz capable RAM, you can do 4 blitter RAM accesses instead of 1. So you have a 4x speed up by doing basically nothing.
I think what @ijor mentioned, is when the shifter is outputting the border colour, its not accessing RAM at all.

Exactly. Blitter, potentially, could drive the RAM at its maximum speed and perform one RAM access per cycle. The CPU always takes (at least) 4 cycles for any access, no matter what, even when accessing non-shared FAST RAM.

But this would require a Blitter closed coupled to the RAM. It won't be possible to do this with the standard chipset on a standard motherboard.

Hence my constant harping on about better logic operations or a multi source logic/ALU unit which could potentially double blitter work efficiency per operation.

The faster you make the H5 system, the less need for a 'regular' or 'unenhanced' blitter ...

This is partially true. But even with a standard Blitter you get shifting for free and the CPU is extremely slow to perform shifts. Unless you would install a 68020 (that has its own barrel shifter) based accelerator, then Blitter could always be faster when shifting is involved.

Of course, with a MC6800 or even 020, the standard blitter can outperform the CPU for general shifting work, or especially with a logical operation performed on the data (which is why we can accept having to share 64/64 cycle bus with CPU<>blitter, or even give the blitter a longer time to complete tasks and have the CPU basically twiddle its thumbs, or do something in TTRAM, when using HOG mode).

However, once we reach - and indeed surpass - shift speed parity (i.e. ~68030@32mhz) waiting for the blitter is no longer a viable alternative for the CPU, especially if nothing useful can be done working in TTRAM to perhaps offset the CPU 'down time'.

I guess the optimal solution is to have a fast enough blitter to surpass 68030 @32Mhz CPU basic shifting speeds at least, so it will always be relevant to use.

[Icky]

If you want a smaller board, we could use the smaller M153 MPGA packaging. You could even save a couple of bucks in comparison with the U169 package. Or the finer BGA pitch complicates routing too much?

It is also possible to use more compact level shifter parts. There are some parts with more channels and also with less power pins. But yes, the GTL parts we have been used are well tested. Different parts might require some additional testing.

Yeah, we don't get much gain with that smaller package as you mention we still have the GTLs that are needed for 5V to 3V3 that take up the majority of the space. I think the layout I have is about as small as you can get with the components. Incidentally we use that smaller package M153 on the Phoenix Shifter.

[exxos]

'.
I guess the optimal solution is to have a fast enough blitter to surpass 68030 @32Mhz CPU basic shifting speeds at least, so it will always be relevant to use.

Not sure I follow...

The blitter and cpu clocked at 8mhz, the blitter will out perform the CPU..

A 50mhz cpu and 8mhz blitter.. The cpu can do some stuff faster. But results are also a bit skewed if running GB6 from alt-ram and using faster ROM. But without getting into all that, The CPU at 50mhz in most cases outperforms the blitter. BUT even a 8mhz blitter is still 50% faster at accessing RAM for example. Then there's caches generally in the mix as well..

So if you jump from 8mhz to 32mhz, the blitter will still outperform the cpu as it would if both blitter and CPU were still running at 8mhz. Basically the CPU is terrible slow at accessing RAM compared to the blitter regardless of cpu clock speed.

[exxos]

Yeah, we don't get much gain with that smaller package as you mention we still have the GTLs that are needed for 5V to 3V3 that take up the majority of the space. I think the layout I have is about as small as you can get with the components. Incidentally we use that smaller package M153 on the Phoenix Shifter.

Yeah it's the buffers. I used the GTL chips as they were the only ones I could get working.. Other than using dedicated mosfets.

*IF* there was demand for the blitter it maybe would be worthwile testing and converting to smaller chips.. But at this point in time, it would just be a huge distraction.

A replacement blitter isn't that attractive for original machines. My only thought is if the bliter does internal shifts, it could run at higher speeds. But no idea what boost that would give. New functions may be attractive but with the lack of users, it's not worth spending the time on it.

If there's massive interest and development on the H5 blitter then it may be worth it.. But for now there's just better things to spend the time on.

[Cyprian]

If we run the blitter double speed, we can actually do 2 accesses to RAM in the same time slot. Of course you need memory to keep up as well.
So if you have 32MHz blitter and 32mhz capable RAM, you can do 4 blitter RAM accesses instead of 1. So you have a 4x speed up by doing basically nothing.
I think what @ijor mentioned, is when the shifter is outputting the border colour, its not accessing RAM at all.

Exactly. Blitter, potentially, could drive the RAM at its maximum speed and perform one RAM access per cycle. The CPU always takes (at least) 4 cycles for any access, no matter what, even when accessing non-shared FAST RAM.

I saw the ST memory access diagram a few years ago and if I remember correctly, all of the SHIFTER cycles were occupied by either SHIFTER itself or memory refresh DMA during in the border area (e.g. on the top/bottom border all 128 cycles of the scan-line were used by the memory refresh process).
The question is whether it is true, and how to deal with the BLiTTER access cycles vs memory refresh cycles.

[mrbombermillzy]

'.
I guess the optimal solution is to have a fast enough blitter to surpass 68030 @32Mhz CPU basic shifting speeds at least, so it will always be relevant to use.

Not sure I follow...

The blitter and cpu clocked at 8mhz, the blitter will out perform the CPU..

A 50mhz cpu and 8mhz blitter.. The cpu can do some stuff faster. But results are also a bit skewed if running GB6 from alt-ram and using faster ROM. But without getting into all that, The CPU at 50mhz in most cases outperforms the blitter. BUT even a 8mhz blitter is still 50% faster at accessing RAM for example. Then there's caches generally in the mix as well..

So if you jump from 8mhz to 32mhz, the blitter will still outperform the cpu as it would if both blitter and CPU were still running at 8mhz. Basically the CPU is terrible slow at accessing RAM compared to the blitter regardless of cpu clock speed.

If Im reading this right... if the blitter is able to run at 32Mhz...then yeah, thats great.

I think you are trying to explain that the blitter is definitely faster at a like for like clock rate than any of the 68000/20/30.

We are both on the same page here then. I completely agree.

All I will addis if this speed was difficult to achieve (for whatever reason), then there is also a (possibly easier to implement) plan b available.

[exxos]

If Im reading this right... if the blitter is able to run at 32Mhz...then yeah, thats great.

The H5 blitter will be able to effectively burst at like 128mhz or maybe higher . It just depends on logic and ram delays etc at that point.

[mrbombermillzy]

Great stuff.

I misconstrued what Igor was explaining about the initial SDRAM access as a problem.