ST Chipset decap

[ijor]

I will use this thread to post WIP details of my work on reverse engineering the ST custom chipset by layout inspection and analysis.

This is really a hardware topic. But coders will naturally be the most interested. Probably clone designers as well. May be it would be useful to create a link from that subforum ...

Again, unless specifically stated otherwise, this is WIP, partial, preliminary analysis.

[ijor]

SHIFTER shift registers reload control logic schematics:

ShifterReloadControl.jpg

This logic produces the signal to control the reload of the shift registers (IR => RR in Alien model).

Inputs are the pixel clock, hardware reset, and the LOAD signal coming from MMU.
There is also a 4-bit pixel counter. The logic that increments and resets this counter is not shown yet.

Basically the logic outputs a one cycle (at the pixel clock) pulse, every 16 pixels, but only if four LOADs have been performed since the last reload. In theory this should be one pulse every 16 CPU cycles.

[ijor]

I will try to write a more detailed description of the logic. But in the meantime I just want to mention that under the "wrong" conditions, this logic will produce the behavior known as "every other 16 pixel background".

Note that the LOAD counter is implemented as a shift register, every LOAD pulse shifts a '1'. After four LOAD pulses the output of the shift becomes logical 1. It will stay in that condition until the shift register is cleared, it doesn't overwraps automatically as a regular counter. In this implementation, it is cleared one pixel clock cycle after the Reload pulse.

The failure could happen when the Reload pulse is triggered too close to a LOAD pulse. The Reload pulse will reset the LOAD counter (implemented as a shift register), and then the new LOAD pulse will be ignored.

At mono, the next Reload will then happen one LOAD later. This is possible because at mono, the pixel counter reaches the reload condition every LOAD. At color, it will not happen at the next LOAD because the pixel counter needs another three more LOAD pulses to enable Reload. So the Reload will happen 4 LOADs later.

Under normal conditions, the logic that resets the pixel counter (not shown yet) aligns the counter in such a way that both pulses will never be too close. But changing resolution or opening borders could alter the alignment between the counter and the LOAD pulses.

[alien]

I will use this thread to post WIP details of my work on reverse engineering the ST custom chipset by layout inspection and analysis.

Cool! Looking forwards to reading this!

[ijor]

Below are simulation waveforms for the above circuit (SHIFTER Reload Control). Showing both correct and incorrect behavior in all three resolutions.

The signal in light blue is LOAD coming from MMU. The signal in red is Reload, the pulse generated by this logic that should normally be after every fourth LOAD pulse. I added two virtual signals to help the visualization. A LOAD pulse decimal counter, and "pixels16" that pulses every time the pixel counter overwraps. The actual pixel counter is included, but depending the resolution and zoom, it changes too fast and is unreadable.

Note that in all the three resolutions, the incorrect behavior produces Reload pulses 16 pixels later than it should. But the effect is different in each resolution.

Low-ok.png

Low-Bug.png

Mono-Ok.png

Mono-Bug.png

Med-ok.png

Med-bug.png

The last one, the buggy behavior at med rez, AFAIK, is theoretic at this time, nobody actually tried to provoke it.

Edit: Swapped the med rez comments

[ijor]

Still missing in the equation is the logic that increments and resets the pixel counter. Not yet ready to post schematics, but more or less it performs as follows:

The 4-bit counter runs free when display is active. It is stopped and initialized to 4 at the borders. This value is used precisely because it results in such alignment with the LOAD pulse that the incorrect behavior would not happen.

The counter starts when DE is active after the first LOAD arrives. And it stops when DE is deasserted, after one Reload pulse (coming from the circuit already shown). If no Reload happens after DE is low (because say, borders were opened and a fourth LOAD pulse never arrives), then the counter is not reset and keeps running.

Note that the 4-bit shift that counts 4 LOAD pulses is NOT reset at the borders automatically. Only a Reload pulse, or hardware reset, resets this shift register (that counts 4 LOADs)

[troed]

This is absolutely amazing Ijor. Many thanks for providing your insights into things we've only been able to model/hypothesize about before.

/Troed

[npomarede]

I second that, really great job you're doing there !!

Nicolas

[Zarchos]

I 'third' that : it's amazing and I more and more like this forum and you Atarian people : from hardware to software you guys are amazing (and this includes of course SS for the emulator).

[dml]

Yes its cool to finally see this - great stuff

[Steven Seagal]

Thx ijor
I have some trouble saving the full pics.
Is it because I'm a M$ IE11 sucker?

One question we have no answer to is how to explain the apparently different timing for DE on/off in GLUE and in Shifter.

In the ST schematic, there's a DE line between GLUE, MMU, Shifter and MFP.

In the MFP it triggers Timer B, when the Shifter toggles real pixels (not border) display.

Example :
GLUE DE off at emulator cycle 376 for a regular 50hz line.

Timer B triggers at cycle 404 = 376 + 28

28 = GLUE-MMU latency 8 + prefetch 16 + Shifter latency 4

[leonard]

Below are simulation waveforms for the above circuit (SHIFTER Reload Control).

This is awesome! As I'm not an hardware guy at all, I'm really fascinated how people like you can understand and even more "predict" weird shifter effects by just looking at a custom chip

Now I dream about a new emulator, working at low level (same level as you describe). Could be a bit slow but will emulate perfectly all ATARI video tricks (even "closure" demo by Sync) without any high level emulation hack.

[npomarede]

Below are simulation waveforms for the above circuit (SHIFTER Reload Control).

This is awesome! As I'm not an hardware guy at all, I'm really fascinated how people like you can understand and even more "predict" weird shifter effects by just looking at a custom chip

Now I dream about a new emulator, working at low level (same level as you describe). Could be a bit slow but will emulate perfectly all ATARI video tricks (even "closure" demo by Sync) without any high level emulation hack.

That's what the people of NoCrew are working on : https://github.com/nocrew/ostis
Might be slow in the end or require high spec PC to run, but would be interesting as a cycle exact model of the ST (but handling everything at the cycle level will require quite some work if you go as low as precise bus accesses and how the glue/mmu/shifter see data on the bus for example)

[Steven Seagal]

The next version of Steem SSE will also emulate the full system cycle by cycle.
In fact, because of distinct clocks (MFP...), microcycles will be used.
This will include statemachines for CPU, Shifter, GLUE, MMU, WD1772, etc.
There's already a working proof of concept (CPU load and speed are fine), but I'm waiting for some further details in ijor's schematics.
The great advantage is that "GLU/Shifter tricks" are handled at a very low level, and are emulated without the need to know anything about them, a bit like for MFM/SCP emulation and disk protections.
The source is not available at SF yet.

[npomarede]

The next version of Steem SSE will also emulate the full system cycle by cycle.
In fact, because of distinct clocks (MFP...), microcycles will be used.
This will include statemachines for CPU, Shifter, GLUE, MMU, WD1772, etc.
There's already a working proof of concept (CPU load and speed are fine), but I'm waiting for some further details in ijor's schematics.
The great advantage is that "GLU/Shifter tricks" are handled at a very low level, and are emulated without the need to know anything about them, a bit like for MFM/SCP emulation and disk protections.
The source is not available at SF yet.

April fool spotted

[ijor]

Hi Leonard!

This is awesome! As I'm not an hardware guy at all, I'm really fascinated how people like you can understand and even more "predict" weird shifter effects by just looking at a custom chip

Well, to be honest, it is much easier when you know what you are looking for. It is not that I discovered the effect myself. But yes, sometimes you can even predict a particular behavior. In this case it was just minor, only the med rez variant.

[ijor]

I have some trouble saving the full pics.

I think the trick is to open the image in a separate tab or window. If you still have troubles let me know and I'll send you a zip file.

One question we have no answer to is how to explain the apparently different timing for DE on/off in GLUE and in Shifter.
In the ST schematic, there's a DE line between GLUE, MMU, Shifter and MFP.
In the MFP it triggers Timer B, when the Shifter toggles real pixels (not border) display.

Not at all. Timer B depends only on the timing of signal DE. DE is produced by GLUE only. It is an input for the others. It doesn't matter at all, for this purpose, what MMU and/or SHIFTER do with DE and their delays processing it.

GLUE DE off at emulator cycle 376 for a regular 50hz line.
Timer B triggers at cycle 404 = 376 + 28
28 = GLUE-MMU latency 8 + prefetch 16 + Shifter latency 4

Timer B interrupt lattency is related to GLUE, MFP and CPU delays. Again, MMU and SHIFTER are not involved. Anyway ...
It has jitter, it is not fixed. Will try to elaborate in a separate thread. Doesn't belong here, not much related to the thread topic.

[laxer3a]

Hi !

Going back to the ST after many many years, I looked around, heard about the Closure demo from Troed (Thanks to Leonard !) and saw you talk about the decap and analyzing the ST chipset. Read a few lines and hear about those weird side effect (black 16 pixel block), wouaw !!!

Very well done !

While the SHIFTER should logically be quite small and easy to emulate, it is indeed very good to be able to look at the real implementation in silicon and see if the logic people thought about is indeed the real implementation. It is real hard work to look at the track and find back which kind of gate it is, logic etc...etc... Real Kudos !

I was wondering if you could upload the pictures you are seeing of the chipset and may be in a coordinated effort, could have multiple person (I would be glad to help, if my skill to do that can improve to look at it and document it, I bet it takes a bit to recognize a AND or OR) working on it in parallel or double check the work.

[ijor]

SHIFTER shift registers reload control logic schematics (now complete):

ShifterReloadControl.jpg

This logic produces the signal to control the reload of the shift registers (IR => RR in Alien model).
See previous posts for further comments on this logic.

Edit: Fixed missing QBAR (!Q) symbol.

[larsbrinkhoff]

Now I dream about a new emulator, working at low level (same level as you describe). Could be a bit slow but will emulate perfectly all ATARI video tricks (even "closure" demo by Sync) without any high level emulation hack.

Your dreams are coming true. We're working on making "oSTis" emulate many things clock-by-clock.

The current implementation of the shifter isn't correct, but it will be updated according to this new information.
https://github.com/nocrew/ostis/blob/ma ... ter.c#L303

handling everything at the cycle level will require quite some work if you go as low as precise bus accesses and how the glue/mmu/shifter see data on the bus for example

We have started updating the 68000 instructions to do precise bus accesses. Yes, that's a lot of work. The GLUE/MMU/Shifter are small and contained; the only problem is knowing exactly how they work.

[larsbrinkhoff]

SHIFTER shift registers reload control logic schematics (now complete):

Thank you! This is so yummy! Only, I'm a hardware illiterate, so I can't read this.

It's clear to me that the bottom part outputs a reload signal every four LOADs. But I guess this reload must somehow be synchronised with the contents of the RR registers, so that it only reloads when the RRs go empty. I suppose that's what the upper part does? And what's DE doing there?

EDIT: Oh, pixCntr! Right? Still, DE?
Is pixCntr involved in the pixel output from RR?

[ijor]

EDIT: Oh, pixCntr! Right? Still, DE?
Is pixCntr involved in the pixel output from RR?

Yes, the pixel counter counts 16 pixel shifts since the last reload. This by itself synchronizes with the RR state. I'll try to write some seudo code later.

DE helps detecting the borders and the initial synchronization. The pixel counter is restarted after the first LOAD pulse coming from MMU. That's how you synchronize the exact position at the start of each line. When DE is off, SHIFTER knows it's at the borders, and the counter is reset.

As I was saying years ago, SHIFTER could actually get along without DE. By simply detecting that no LOAD pulse arrives after so many cycles, you can detect the borders. It is somewhat easier with DE, but I'm not so sure it deserves using the last pin available in SHIFTER.

[ijor]

Is pixCntr involved in the pixel output from RR?

Sorry. Forgot to explain that. Both the pixel counter and the RR registers are clocked by the same clock (the pixel clock). So anytime RR shifts, the pixel counter is incremented as well. And they are further synchronized, because the whole purpose of this logic is to produce the Reload pulse that actually controls the transfer from IR to RR.

So, if you count 16 pixels and 4 LOAD pulses since the previous reload (of the RR registers), that's the exact point where the RR registers are empty and need to be reloaded again.

[stefanberndtsson]

SHIFTER shift registers reload control logic schematics (now complete):

Nice. I'm guessing the lower Q's on the DFF's up on top are really the !Q's, but what's the role of the pxCtrLoad signal?

[ijor]

I'm guessing the lower Q's on the DFF's up on top are really the !Q's ...

Oops. Yes, for some reason the overline was missing when exporting the schematics!

I edited the post with an updated schematics. Please re download.