ST Chipset decap

GFA, ASM, STOS, ...

Moderators: exxos, simonsunnyboy, Mug UK, Zorro 2, Moderator Team

ijor
Hardware Guru
Hardware Guru
Posts: 3142
Joined: Sat May 29, 2004 7:52 pm
Contact:

ST Chipset decap

Postby ijor » Thu Mar 31, 2016 2:11 am

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
Hardware Guru
Hardware Guru
Posts: 3142
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: ST Chipset decap

Postby ijor » Thu Mar 31, 2016 2:23 am

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.
You do not have the required permissions to view the files attached to this post.

ijor
Hardware Guru
Hardware Guru
Posts: 3142
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: ST Chipset decap

Postby ijor » Thu Mar 31, 2016 3:34 am

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.

User avatar
alien
Atari maniac
Atari maniac
Posts: 85
Joined: Sat May 01, 2004 4:01 am
Location: USA
Contact:

Re: ST Chipset decap

Postby alien » Thu Mar 31, 2016 5:10 am

ijor wrote: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!
Alien / ST-Connexion

ijor
Hardware Guru
Hardware Guru
Posts: 3142
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: ST Chipset decap

Postby ijor » Thu Mar 31, 2016 8:21 pm

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
You do not have the required permissions to view the files attached to this post.

ijor
Hardware Guru
Hardware Guru
Posts: 3142
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: ST Chipset decap

Postby ijor » Thu Mar 31, 2016 8:41 pm

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)

User avatar
troed
Atari God
Atari God
Posts: 1213
Joined: Mon Apr 30, 2012 6:20 pm
Location: Sweden

Re: ST Chipset decap

Postby troed » Thu Mar 31, 2016 9:03 pm

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

/Troed

User avatar
npomarede
Atari God
Atari God
Posts: 1178
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: ST Chipset decap

Postby npomarede » Thu Mar 31, 2016 9:17 pm

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

Nicolas

Zarchos
Captain Atari
Captain Atari
Posts: 220
Joined: Wed May 09, 2012 7:38 pm
Location: FRANCE

Re: ST Chipset decap

Postby Zarchos » Thu Mar 31, 2016 9:21 pm

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).
Atari 1040 STE+SATAN, 520ST, 800xl, xegs, Amiga 500, 2000 with 68020, Archimedes, RISC PCs + Iyonix, Omega, BBC B, Atom, Electron, ZX 81, Spectrum 48/128/+2/+3, Speccy2010, Russian clones, Sam Coupe, V6Z80P, QL with accelerators, Enterprise 128, Einstein inc 256, Oric Atmos, MSX 1, 2, Thomson MO5, Amstrads inc CPC+, C 16, 64, 128, VG5000, Apple IIGS and more ! Yes I want to create a museum when I retire.


User avatar
Steven Seagal
Atari God
Atari God
Posts: 1982
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: ST Chipset decap

Postby Steven Seagal » Fri Apr 01, 2016 7:33 am

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

User avatar
leonard
Moderator
Moderator
Posts: 640
Joined: Thu May 23, 2002 10:48 pm
Contact:

Re: ST Chipset decap

Postby leonard » Fri Apr 01, 2016 9:31 am

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

User avatar
npomarede
Atari God
Atari God
Posts: 1178
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: ST Chipset decap

Postby npomarede » Fri Apr 01, 2016 9:37 am

leonard wrote:
ijor wrote: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)

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1982
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: ST Chipset decap

Postby Steven Seagal » Fri Apr 01, 2016 10:28 am

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.

User avatar
npomarede
Atari God
Atari God
Posts: 1178
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: ST Chipset decap

Postby npomarede » Fri Apr 01, 2016 10:33 am

Steven Seagal wrote: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
Hardware Guru
Hardware Guru
Posts: 3142
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: ST Chipset decap

Postby ijor » Fri Apr 01, 2016 12:02 pm

Hi Leonard! :)

leonard wrote: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
Hardware Guru
Hardware Guru
Posts: 3142
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: ST Chipset decap

Postby ijor » Fri Apr 01, 2016 12:08 pm

Steven Seagal wrote: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
Atarian
Atarian
Posts: 1
Joined: Sat Apr 02, 2016 7:58 pm

Re: ST Chipset decap

Postby laxer3a » Sat Apr 02, 2016 8:26 pm

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
Hardware Guru
Hardware Guru
Posts: 3142
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: ST Chipset decap

Postby ijor » Tue Apr 05, 2016 1:16 am

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.
You do not have the required permissions to view the files attached to this post.

User avatar
larsbrinkhoff
Atariator
Atariator
Posts: 25
Joined: Fri Mar 18, 2016 3:03 pm
Contact:

Re: ST Chipset decap

Postby larsbrinkhoff » Wed Apr 06, 2016 5:54 am

leonard wrote: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

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

User avatar
larsbrinkhoff
Atariator
Atariator
Posts: 25
Joined: Fri Mar 18, 2016 3:03 pm
Contact:

Re: ST Chipset decap

Postby larsbrinkhoff » Wed Apr 06, 2016 6:57 am

ijor wrote: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
Hardware Guru
Hardware Guru
Posts: 3142
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: ST Chipset decap

Postby ijor » Wed Apr 06, 2016 1:45 pm

larsbrinkhoff wrote: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
Hardware Guru
Hardware Guru
Posts: 3142
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: ST Chipset decap

Postby ijor » Wed Apr 06, 2016 1:56 pm

larsbrinkhoff wrote: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
Atarian
Atarian
Posts: 4
Joined: Wed Mar 23, 2016 10:48 am

Re: ST Chipset decap

Postby stefanberndtsson » Wed Apr 06, 2016 8:02 pm

ijor wrote: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
Hardware Guru
Hardware Guru
Posts: 3142
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: ST Chipset decap

Postby ijor » Wed Apr 06, 2016 8:58 pm

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


Social Media

     

Return to “Coding”

Who is online

Users browsing this forum: No registered users and 1 guest