MEGA ST BLITTER PATCH - Discussion thread

General discussions or ideas about hardware.
User avatar
Badwolf
Site sponsor
Site sponsor
Posts: 2562
Joined: Tue Nov 19, 2019 12:09 pm

Re: MEGA ST BLITTER PATCH

Post by Badwolf »

exxos wrote: Fri Oct 07, 2022 10:58 am
Badwolf wrote: Fri Oct 07, 2022 10:26 am So, if someone were being *really* anally retentive about wanting all their blitters to return $3f in your test case, would delaying the blitter's BR line by one 8MHz clock cycle be sufficient?
I can say just a few ns on the 8Mhz clock on the CPU "does the trick". So I would imagine delaying BR would have the same effect. But it also begs the question if it is already 003F and you delay further with it further screw up the results @ijor ?
I was thinking it'd push the S2 assertions into S4 and ensure nothing asserts in S0. I don't think there should be a difference between S2 and S4 assertion as it's not sampled until S7, if I've read Ijor's post correctly.
There probably will not be any future H5 series boards.
Ah, fairy nuff.

BW
DFB1 Open source 50MHz 030 and TT-RAM accelerator for the Falcon
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
FrontBench The Frontier: Elite 2 intro as a benchmark
ijor
Posts: 549
Joined: Fri Nov 30, 2018 8:45 pm

Re: MEGA ST BLITTER PATCH

Post by ijor »

Badwolf wrote: Fri Oct 07, 2022 10:26 am So, if someone were being *really* anally retentive about wanting all their blitters to return $3f in your test case, would delaying the blitter's BR line by one 8MHz clock cycle be sufficient?
Yes, pushing BR assertion to S2/S4 would work, in the sense that all Blitters would get the same result, both when running this test and with typical Blitter code. Guess some may argue that it is not really good because "most" Blitters on a standard ST/STE would return $40 when running the test. Also note that you would still get different behavior depending on the Blitter part, if the bus is idle for more than two clock cycles.

Btw, I just realized that S0/S2 technically might be incorrect terminology here because the bus is, or might be, idle at what I called S0. A more accurate accurate (but too long) wording might be perhaps:

A fast Blitter (CPU combination) asserts BR at the next raising edge of the clock after the bus cycle that sets BUSY, at the phase that would be S0 if there are no idle states and the next bus cycle starts immediately. While a slow Blitter (CPU combination) asserts BR one cycle later, at the phase that would be S2 if the next bus cycle starts immediately without any idle states.
http://github.com/ijor/fx68k 68000 cycle exact FPGA core
FX CAST Cycle Accurate Atari ST core
http://pasti.fxatari.com
Post Reply

Return to “HARDWARE DISCUSSIONS”