BLITTER RE-CREATION THOUGHTS

[Icky]

My eyes are going crazy tonight with all these lines and boxes. Working through the schematics :)

IMG_4521.jpeg

[slingshot]

Meanwhile I found the issue why the blitter from Suska is slow, and even fixed the FC output from user to supervisor data (that allows write to the Shifter palette registers). Hell, it runs some demos now (like 20 years megademo, the Happy Birthday scene)!
Just need a bit more work on the state machine, and will upload the code soon.

[exxos]

Meanwhile I found the issue why the blitter from Suska is slow, and even fixed the FC output from user to supervisor data (that allows write to the Shifter palette registers). Hell, it runs some demos now (like 20 years megademo, the Happy Birthday scene)!
Just need a bit more work on the state machine, and will upload the code soon.

Nice! Not sure if Icky mentioned, though he sort-of had it running last night... got a bit more in speed, but still 42% which is still running half speed basically than it should.

C7168846-E393-4F46-A744-F7FCF1C2DC86_1_105_c.jpeg

[slingshot]

Nice! Not sure if Icky mentioned, though he sort-of had it running last night... got a bit more in speed, but still 42% which is still running half speed basically than it should.

Good, it could be integrated then. The speed problem is basically the state machine have some extra states besides the bus cycles (S0-S7 in terms of 68000, also written similarly in the VHDL code - that's exactly 4 clock ticks), and when the Blitter is in these states, it will miss the next CPU cycle of the MMU - then it has to wait for the next. That's why the effective performance is only about 50% - the blitter loses every second memory access opportunity.

[exxos]

Good, it could be integrated then. The speed problem is basically the state machine have some extra states besides the bus cycles (S0-S7 in terms of 68000, also written similarly in the VHDL code - that's exactly 4 clock ticks), and when the Blitter is in these states, it will miss the next CPU cycle of the MMU - then it has to wait for the next. That's why the effective performance is only about 50% - the blitter loses every second memory access opportunity.

We did fiddle with all sorts in the code, including the state machine. I removed a lot of changed states, we got around 80% speed, but everything was corrupted. We have no idea about FPGA stuff, but we tried :) So thanks for your efforts so far :cheers:

[slingshot]

I've started to look at the schematics more thoughtfully.
Anybody has an idea if a Blitter interrupt is generated when it's restarted in non-hog mode? It should because of how the busy bit implemented: it's cleared when the operation finishes _and_ when the register containing the busy bit is selected. So when the CPU writes a '1' to busy to re-start it in non-hog mode, it should create a high->low edge on the INT output.
2nd question: 4082.pdf is much more readable than 4051.pdf. Is there any known difference between the timings of this presumably newer blitter? (functionality wise I assume it's the same).

[exxos]

2nd question: 4082.pdf is much more readable than 4051.pdf. Is there any known difference between the timings of this presumably newer blitter? (functionality wise I assume it's the same).

4021 is the basic blitter chip. 4051 just has bunches of "double inversions" to fix noise on some lines. So no different than 4021 really.

4082 I believe is part of the STE combel or some other versions of it, so its of no use to use really.

https://www.exxosforum.co.uk/forum/viewt ... =29&t=2302

[slingshot]

4082 I believe is part of the STE combel or some other versions of it, so its of no use to use really.

https://www.exxosforum.co.uk/forum/viewt ... =29&t=2302

Just asked because seems it uses a more modern ASIC library, just compare the first pages (which is the most important part - the state machine). No negative clocks for each flip-flop, much more human consumable.
That was the same with the GSTMCU, there were 2 PDFs, looked similar in functionality, but the older was more cluttered, with normal and inverted clocks everywhere. I've chosen the more modern one for my Verilog implementation, and turned out it was a good decision. So maybe 4082 is just as good as 4021/4051. At it's surely not part of a combo chip in this form, all the ordinary input/output pads are there.

[exxos]

That was the same with the GSTMCU, there were 2 PDFs, looked similar in functionality, but the older was more cluttered, with normal and inverted clocks everywhere. I've chosen the more modern one for my Verilog implementation, and turned out it was a good decision. So maybe 4082 is just as good as 4021/4051. At it's surely not part of a combo chip in this form, all the ordinary input/output pads are there.

Yeah I go into the negative logic in various places in this thread already. Though we are not using the 4082 as we don't know if its even a working design. 4082 is a "BLIT CELL" likely for 4081 combel ... from the other thread..

Oddly the 4081ORIG file mentions "ST GAME COMBO" 1989 so maybe its not even a STE chipset.

It is known that Atari wanted to use the STE's combo chip in an ultimately cancelled game console codenamed "Robin". Remnants of that project are inside each STE, see the ominous "GAMECART" register that I found.

[Cyprian]

Is there any known difference between the timings of this presumably newer blitter? (functionality wise I assume it's the same).

regarding timings, the only known difference is Mega STE, where each blit pass takes one more bus cycle for bus mastering (cache management is suspected of that delay).
regarding functionalities - no differences, no one has tried yet to explore that are. But would be cool to verify that.