exxos's Atari, Amiga & retro forum

mrbombermillzy wrote: 25 Dec 2022 13:58 While we are on the blitter features wish list, I'm just started working on something interesting, but cannot vouch if it will be useful after I've properly tested, but just in case... would extending the HTRAM matrix size be completely out of the question?

It is certainly possible. Just out of curiosity, why you need this? I'm asking because if you would like some kind of video "sprite", then it would probably be more efficient to implement this in an "enhanced" Shifter instead.

In theory everything is possible. Scaling, tracing, 3D, etc. But some operations are expensive for an FPGA. It might require a more expensive part, and of course development won't be trivial.

ijor wrote: 26 Dec 2022 14:26

mrbombermillzy wrote: 25 Dec 2022 13:58 While we are on the blitter features wish list, I'm just started working on something interesting, but cannot vouch if it will be useful after I've properly tested, but just in case... would extending the HTRAM matrix size be completely out of the question?

It is certainly possible. Just out of curiosity, why you need this?

Well, it's too early to say conclusively, but after getting quite far in this direction with a TT and essentially having to restart the process on the ST... blitter or not; one of the things that is always a big factor is trying to harness whatever process that uses the least cycles to get the job done.

The "job" being finding practical applications for high 'per line' colour content displays (any sprite/BOB/block image, if it can be done at a later stage, is a bonus).

And the "least cycles" in this case (as far as I have managed to find so far on a 8Mhz MST) is a 4 cycle write speed to the screen RAM area using (you guessed it) the Blitter's limited HTRAM area, so the more/wider the better, as far as I'm concerned...*BUT* only if my testing proves positively conclusive in this respect.

ijor wrote: 26 Dec 2022 14:26 I'm asking because if you would like some kind of video "sprite", then it would probably be more efficient to implement this in an "enhanced" Shifter instead.

Currently, my goal is to minimise bus use (for obvious reasons) by use of write avoidance techniques and then write speed optimisations for when that cannot be achieved.

Of course, bolting on extra fancy enhancements on the shifter would be very nice thank you, but until then, I'm trying to respectfully stay close to the original HW, stay compatible and enhance what is already there (if it can be mapped to any empty/unused memory map locations, or can be elegantly augmented or spliced into the architecture then I believe this is an ideal scenario if compatibility is desired; love them or hate them, the Vampire team seem to have done a good job of doing this with AGA/SAGA).

On that note (and seeing as you mentioned the shifter, so I will shift topic focus slightly), I did briefly mention to @Icky at the Cyberlegends show (I also brought a working Amiga based system to possibly illustrate the point if I had a chance to do so) about what I believe is a very good HW implementation option to prevent bus contention caused by higher/deeper video modes - like e.g. F030 in 16bpp mode - on a slower system speed. I am quite happy to discuss a possible solution if you are at all interested, but this is going a bit off topic now.

I've cleaned up this topic as there is a new thread about the shifter related stuff. viewtopic.php?f=80&t=6057

Back to the blitter... Also drifting off topic.. I wonder if a audio volume control could be done in the blitter faster than the CPU can do it ? Won't go into the particulars in this thread but its relating to adding more sound channels for playing tracker music.

Just as a "small" update. We have not given up on this project and the delays are generally because of FPGA shortages. As people know the original blitters are basically non-existent and I hope we can make them with FPGA chips at somewhat of a sane price in the near future.

FPGA Blitter cycle exact core running now on an H5 motherboard:
This was using the same Qmtech FPGA board and adapters described in this MMU thread:
viewtopic.php?f=80&t=7312

The core itself has been already tested by @Icky using his "Sparkalaphobia" board on an original STFM computer (See his post #95868 on this thread). Even when that board used a different FPGA (MAX10 vs Cyclone IV), I expected the port to be quite simple, almost trivial. It worked, but some tests didn't show 100% accuracy and it wasn't easy to find out what was going on.

You might remember that the exact Blitter timing in some circumstances depends on the pull up on the BGACK line. A weaker pull-up might produce, again, in some cases, a slower timing. See this thread for details:
viewtopic.php?f=29&t=6030&start=30

I was, obviously, well aware about that. I knew that the results on this H5 might be different to the results on other computers depending on the pull up installed in this board. But on the very same computer, the FPGA core and the original Blitter should get exactly the same timing. But they didn't, my core behaved slower.

This H5 board has a weak pull-up. So the test posted in the thread mentioned above gave the slower result with the original Blitter:


So far so good, that was expected. But my core gave a different, even slower, result:


After many tests I realized that I measured the pull-up wrong before. It is even weaker. It's a 4.7K pull up as as standard on the ST. This still doesn't explain why the result is different than with the original Blitter. Well, the difference wasn't the core vs the original chip. The difference was that I was testing the core with a logic analyzer attached for diagnosis. And it seems that this was enough to produce an extra load on the signal that made the BGACK raising edge even slower. And as a matter of fact, when I tested the original Blitter with the LA still attached, I do get the same (slow) results!

To solve the pull up mess for good, I implemented special logic in the core to "ignore" the on board pull up and and a configurable option to select the exact BGACK timing. Now it can behave and produce the same timing as if there was a stronger or weaker pull up, independently of the actual pull up fitted on the motherboard.

Sorry, forgot to post a picture when configured in "fast" mode:
See the Blitting time here is 3.570, while as shown in the previous post, in this particular computer the original Blitter gets 3.575 time. The original slower time is, again, because this computer has a weak pull up on the BGACK signal. But the FPGA core can now be configured to behave as if there was a strong pull up instead. This is how we get a faster "strong pull up" timing even with a weak pull up.

I can't think of anything intelligent to say :lol: but this is an awesome achievement.

Congratulations

:2k2:

Blitastic

Great.

Wow, Awesome!