exxos's Atari, Amiga & retro forum

Maybe a useful feature could be logic to deal with horizontal scrolling. The cpu doing the math with slow access to RAM is painfully slow.

Cyprian wrote: 02 Jul 2025 13:31

ijor wrote: 02 Jul 2025 02:04 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.

Of course it is true. Not only that, even if any SHIFTER slot would be not used for ram refresh, the chipset is still not designed for allowing the CPU to use them ...

As I said already, precisely after the paragraph you quoted:

ijor wrote: 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.

Now, in theory it should still be possible to implement this, but it would be complicated. You could, e.g., build a board with Blitter and its own RAM that would "replace" the on board ram, and that it would bypass the chipset control over the RAM. You would need to somehow connect to the RAM data bus (say, at the Shifter socket), and you would also need to snoop some MMU signals.

So, it is doable on a standard ST with standard chipset, if you insist. I'm posting that just for completion and for the fun of considering the idea :)

Does anyone of the pinout overlay on the 10M02SCU169A7G ?

I have the pinlist, plus templates for schematics.. BUT.. There is nothing on the lib to indicate what pin is what on the PCB... its just a slab of pins.. So trying to right out what pins are on the right side from top to bottom is hard going unless I highlight each pin on the schematic and see which pins on the PCB light up.. its a nightmare with 100+ pins.

EG:


Whats the top right pin called ? No idea. I need a drawing like above but with the pins named so I can see what pin goes where on the schematic.. but can I find one anywhere..

All I have is..


I don't know what it is with Intel datasheets. Pretty much ever datasheet i've seen has a proper pin overview.. but not Intel stuff ?! Pinout should be the first thing in the datasheets.. but can I find it anywhere... maybe I am blind ?!

exxos wrote: 02 Jul 2025 22:09 Does anyone of the pinout overlay on the 10M02SCU169A7G ?

I have this. Not sure where you got that one from.

Icky wrote: 02 Jul 2025 22:23 I have this. Not sure where you got that one from.

Think my lib came from mouser.

exxos wrote: 02 Jul 2025 22:09 I have the pinlist, plus templates for schematics.. BUT.. There is nothing on the lib to indicate what pin is what on the PCB... its just a slab of pins.. So trying to right out what pins are on the right side from top to bottom is hard going unless I highlight each pin on the schematic and see which pins on the PCB light up.. its a nightmare with 100+ pins.

They provide the pinout in Excel spreadsheets here:
https://www.intel.com/content/www/us/en ... it-dp.html

Package and footprint information is here:
https://www.intel.com/content/www/us/en ... ckage.html

Quartus outputs a specific pinout file, that according to the documentation, can be read by commercial software like Cadence. Don't know if Eagle or Kicad can read those files. You can also see a graphic pinout representation at the Quartus pin planner.

I understand they don't provide footprint libraries anymore.

I don't know what it is with Intel datasheets. Pretty much ever datasheet i've seen has a proper pin overview.. but not Intel stuff ?!

Not trying to justify Intel. But I understand that this is typical for most modern FPGA devices, not just from Intel/Altera. The datasheet covers too many device parts and variations, each one having too many pins. It probably wouldn't be practical to include all the pinouts in the datasheet.

I found this last night, will do the job :)

:AI:

Some of you will remember this thread and the attempts over the years to recreate the Blitter from the leaked Atari schematics. That work stalled out for good reasons at the time. The schematics are in an ancient FutureNet DASH format, the logic is drawn in Atari's double polarity style where every signal travels around the sheets as a true and inverted pair, and half the cell types have no definition anywhere on the drawings. Trying to hand translate that into Quartus was death by a thousand inverters, so it got shelved as unfinished business.

Recently I decided to have another crack at it, mostly out of curiosity to see whether AI could actually finish the job. Not by asking it to "write me a blitter", but by feeding it the original Atari material and having it do the grunt work properly, with everything verified by simulation rather than taken on trust. So I fixed it, because apparently that's what I do now instead of sleeping.

The first problem was reading the schematics at all. Rather than trying to reverse engineer the DASH binary format, the trick that worked was running Atari's own netlister program from 1988 under emulation, exactly as their engineers would have done, which spits out a proper netlist of every gate and connection. That output was even verified against a netlist Atari themselves generated back in the day, which matched, so we knew the extraction was sound before building anything on top of it.

The missing cell definitions turned out to exist after all. Atari's own simulation library was in the archive and defines most of the flip flops, latches and buffers, so those could be written from Atari's own descriptions rather than guessed. The last few unknowns were the complex AND-OR gates in the control logic, and the answer to those was sitting in the cell definition symbols on the schematic pages all along, readable once the pages were rendered at silly resolution.

From there the netlist was transcribed literally into Verilog, all 1300 odd gates of it, and this is where simulation earned its keep. It caught a string of genuine errors in the translation that would have been absolute misery to find on real hardware. The input pad receivers turned out to be inverting, which had the whole chip held in reset with the polarity backwards. One output buffer cell being an inverter rather than a buffer had a pair of internal clock phases swapped, which broke the counters in ways that looked like three different bugs. And at one point an audit found that over a hundred storage latches had been silently dropped during generation, meaning every register in the chip had no actual storage. The blit ran, it just remembered nothing, which is a mood.

The halftone RAM was its own adventure, as the RAM array is a custom layout block that simply is not in the schematic netlist at all, so that had to be modelled from the surrounding decode logic, with each design choice tested rather than assumed. Even the bit lines carry inverted data, because of course they do.

Verification is the part I am actually pleased with. The archive includes Atari's own factory test vector file for the chip, which is effectively the answer sheet their test equipment used on real silicon. The core was run against all of it, including the full set of BLT test cases, the smudge mode tests and the bit alignment tests. On top of that I wrote small test programs and ran them on real Atari hardware to settle the genuinely obscure corners, and the recreated core matches the real chip's behaviour, including the weird stuff. The NFSR mode in particular does something quite surprising internally that falls straight out of the transcribed gates, and the real chip does exactly the same thing.

The final stage was converting the whole design into a properly synchronous version suitable for an FPGA, since the original relies on gated clocks, transparent latches and, as it turns out, gate delays. That was genuinely the hardest part of the entire project. The original design quietly depends on signals racing each other by a few nanoseconds in at least two places, where the correct behaviour only happens because one gate is slightly slower than another. Those had to be found by comparing the two versions cycle by cycle, understood properly, and then designed in explicitly with comments explaining why, rather than left to luck. The synchronous version now produces bit identical results to the gate level version across the entire test programme, including all of Atari's factory test cases.

So the short version is that the unfinished business is finished. What started as schematics nobody could read is now a fully verified, commented, synchronous Verilog core that behaves like the real chip down to its quirks, ready for a Quartus build. What did I learn overall? That simulation before hardware is worth its weight in gold, that Atari's engineers leaned on analogue behaviour in a digital design more than you would believe, and that the AI did get there in the end, provided every single claim was tested and it was never allowed to assume anything. Which, to be fair, is also good advice for humans.