BLITTER RE-CREATION THOUGHTS

Progress on our FPGA cores.
ijor
Posts: 549
Joined: Fri Nov 30, 2018 8:45 pm

Re: BLITTER RE-CREATION THOUGHTS

Post by ijor »

mrbombermillzy wrote: Sun Dec 25, 2022 1:58 pm 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.
http://github.com/ijor/fx68k 68000 cycle exact FPGA core
FX CAST Cycle Accurate Atari ST core
http://pasti.fxatari.com
User avatar
mrbombermillzy
Posts: 1631
Joined: Sun Jun 03, 2018 7:37 pm

Re: BLITTER RE-CREATION THOUGHTS

Post by mrbombermillzy »

ijor wrote: Mon Dec 26, 2022 2:26 pm
mrbombermillzy wrote: Sun Dec 25, 2022 1:58 pm 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: Mon Dec 26, 2022 2:26 pm 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.
User avatar
exxos
Site Admin
Site Admin
Posts: 24786
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: BLITTER RE-CREATION THOUGHTS

Post by exxos »

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.
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
User avatar
exxos
Site Admin
Site Admin
Posts: 24786
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: BLITTER RE-CREATION THOUGHTS

Post by exxos »

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.
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
ijor
Posts: 549
Joined: Fri Nov 30, 2018 8:45 pm

Re: BLITTER RE-CREATION THOUGHTS

Post by ijor »

FPGA Blitter cycle exact core running now on an H5 motherboard:
Blitter FPGA core on H5
Blitter FPGA core on H5
20241020_180906.jpg (580.65 KiB) Viewed 154 times
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:
Blitter test with weak pull up on BGACK
Blitter test with weak pull up on BGACK
20241020_180433.jpg (364.25 KiB) Viewed 154 times


So far so good, that was expected. But my core gave a different, even slower, result:
Blitter test with very weak pull up or large capacitance
Blitter test with very weak pull up or large capacitance
20241017_105633.jpg (338.38 KiB) Viewed 154 times


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.
http://github.com/ijor/fx68k 68000 cycle exact FPGA core
FX CAST Cycle Accurate Atari ST core
http://pasti.fxatari.com
ijor
Posts: 549
Joined: Fri Nov 30, 2018 8:45 pm

Re: BLITTER RE-CREATION THOUGHTS

Post by ijor »

Sorry, forgot to post a picture when configured in "fast" mode:
FPGA core "simulating" strong pull up time
FPGA core "simulating" strong pull up time
20241020_235510.jpg (611.05 KiB) Viewed 147 times
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.
http://github.com/ijor/fx68k 68000 cycle exact FPGA core
FX CAST Cycle Accurate Atari ST core
http://pasti.fxatari.com
User avatar
chronicthehedgehog
Site sponsor
Site sponsor
Posts: 345
Joined: Sun May 08, 2022 6:11 pm
Location: The Midlands
Contact:

Re: BLITTER RE-CREATION THOUGHTS

Post by chronicthehedgehog »

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

Congratulations

:2k2:
User avatar
alexh
Site sponsor
Site sponsor
Posts: 931
Joined: Tue Oct 17, 2017 4:51 pm
Location: Oxfordshire

Re: BLITTER RE-CREATION THOUGHTS

Post by alexh »

Blitastic
Principal ASIC Engineer - SystemVerilog, VHDL
Thalion Webshrine - http://thalion.atari.org
STf,STfm,STe,MegaST,MegaSTe,Falcon060
A500+,A600,A4000/060,CD32,CDTV
User avatar
Cyprian
Posts: 461
Joined: Fri Dec 22, 2017 9:16 am
Location: Poland

Re: BLITTER RE-CREATION THOUGHTS

Post by Cyprian »

Great.
Lynx I / Mega ST 1 / 7800 / Portfolio / Lynx II / Jaguar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
DDD HDD / AT Speed C16 / TF536 / SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
http://260ste.atari.org
User avatar
agranlund
Site sponsor
Site sponsor
Posts: 1194
Joined: Sun Aug 18, 2019 10:43 pm
Location: Sweden
Contact:

Re: BLITTER RE-CREATION THOUGHTS

Post by agranlund »

Wow, Awesome!
Post Reply

Return to “FPGA DEVELOPMENT”