Wakeup modes

[alexh]

I can confirm that some Atari ASIC netlists are around. As to their viability, it is not yet known. A quick look at the Glue netlist a couple of months ago confirmed there is a high probability of them being real. The names of the placed gates match the technology in which the chips were made.

[DrCoolZic]

Do you know were to find these netlists?
Any pointer is welcome.
Thanks
Jean

[DrCoolZic]

I don't know why your machine seems to have a single wakeup. The initial refresh rate shouldn't have any relevance whatsoever. The wakeup is determined long before TOS sets the sync rate.

Yes of course you are right the problem seems to be related to some sort of HW ambiguity at powerup.
Thanks I therefore do not have to open my ST!

By the way I should receive soon an Atari Mega (sometimes next week) and I am curious to see how it behaves as it is in between STF and STE. Schematics shows an extra blitter but MMU/Glue looks the same.

Hope it is working as this is an imcomplete system (KB missing and therefore system not tested).

[DrCoolZic]

Just got feedback from my contact and unfortunately the story is more complex than I thought.
"Someone" (sorry no name) has access to the original ST Asic simulation results (this is quite amazing after more than 20 years!!!!!!!!!) but not to their netlists.
It is therefore a complex task to recreate them as some heavy reverse engeeniring needs to be done but the end results should be 100% accurate description. Of course this is assuming 100% good code coverage was done during simulation but this should be the case due to the ASIC cost...

Therefore Alexh if you have access to some netlists please let us know were we can find them.

[Cyprian]

The strange thing for me is still why did they choose these Sound DMA hardware frequencies that had nothing to do with the common Amiga and PC frequencies at the time.

May be Sound DMA hardware frequencies depend on main clock?
e.g 50066 * 160 gives 8010560 cycles ~= 8MHz.
Could someone check it?

[ijor]

However as Ijor mentioned the ST ASICs are certainly not a "gate replication" of the TTL boards. This is due to the fact that when you map (we would use the term synthesis our days) a behavioral model to a specific technology (TTL and ASIC in our case) you have to optimize to the mapping to the technology.

This is not what I meant. What you say is partially true for programmable logic. But ASIC and FPGA are very different beasts. You can implement a discrete TTL design into ASIC replicating at the gate level. And that would be very efficient and optimized.

What I meant is that the prototype might be (probably is) different than the final product. Not because of discrete TTLs vs. ASIC. The prototype might lack some features that were implemented later. Or also possibly the other way around.

[ijor]

May be Sound DMA hardware frequencies depend on main clock? e.g 50066 * 160 gives 8010560 cycles ~= 8MHz.

It doesn't run on the main clock. Sound on the STe (both DMA and YM) run on a separate crystal ... at 8.010613 MHZ.

[kilbaf]

For sure having the netlists will be great.
In case there is no access to the netlist, the way to reverse the physical database should be more accurate that rebuilding the FE netlist from simulation. Most probably your simulation do not probe all internal signals.

1)I do not know how it was done in 1984-85 but in case the physical database (layout) was a gds2 (if this format exist at that time) and with the Design Rule Manual of the technology, it is possible to get a transitor netlist extracted. And then possibly to transform it in gate netlist. What was the technology used (NMOS x.y um, CMOS), and the foundry ?
2)A second way but requesting a lot of mean would be to open the parts, take photos of the dies to get a whole picture and try to reverse the layout.

If 1) is achievable especially if gds2 format was used, 2) is certainly limited to organization specialized in spying chips (maybe mafia does that ?).

You certainly all, right when saying only prototypes were done in TTL, I've just had in memory that the 1st products was with TTL. So if not 520ST, do you think also 130ST/260ST which were the first models integrated ASIC for glue ... ?

[ljbk]

Hi !

I will try to make a status point on what i know regarding this matter as it is really a complex thing.
What i am writing is of course related to my machine (STF), but it is probably valid for many STs.

There are 2 main wake up states as we have discussed. The reasons have already been explained.
But on top of that, at least for wake up 2, there are some sub-wakeup states that have influence on the displayed image.
Things like, the motor of the disk drive A running or not can have influence on the stability of the pic depending on the cases.
In some cases, we get a stable picture, but we notice that for some lines or the complete screen, we get 16 pixels of bitmap, then 16 pixels of border color, 16 pixels of bitmap ... Heat might lead to this situation in some cases.
Another common case is also, the Spectrum 512 case: funny color dots when displaying a Spectrum 512 picture. Again this is a general machine sync problem: Spectrum expects a logical color to change at a certain pixel like logical color 1 at pixel 5: until pixel 5 you get one value displayed, from pixel 6 on you get another one. If you use logical color 1 at pixel 5 and also may be at pixel 6, you might see the wrong color or a flashing color if your machine is out of sync, that is for some of the sub-wake up states. If logical color 1 is not in use for those pixels, you will see always the same color. That is why you only see "some" funny color dots.
In all those cases, i think we are talking about sync problems between the several chips at the level of the 32 MHz video clock, like small delays, heat effects, radio effects, ...

As you see, this is really a complex business ...

[DrCoolZic]

Hi !
I will try to make a status point on what i know regarding this matter as it is really a complex thing.
What i am writing is of course related to my machine (STF), but it is probably valid for many STs.

Hi Paulo
You have already provided a lot of extremely useful information on that matter but, since you now seems to be the best expert, it would be fantastic if you could write an article, similar to what Alien did long time ago (even if it is a short version), with some code examples !!!

[MiggyMog]

I think you could get a few articles out of this thread?

...or at least update a few old ones when you consider the different ways the information could be used?

Border removal,sync scrolling,extended picture formats,,etc

[ijor]

Hmm, too late now to elaborate, but we should agree on some terminology or we won't understand each other.

Stable/stabilization/unstable/etc. We seem to use it in to different senses. One thing is to reset SHIFTER to correctly align the bitplanes (not really a stabilization). Another thing is to avoid a truely unstable situation as Paulo describes.

Wakeup. Conceivable there could be more than two wakeups. But one thing is a wakeup, another thing is an unstable behavior. A wakeup is a defined power up state. An unstable behavior doesn't neccessarily means another wakeup.

Also, additional wakeup might be on the same, or on a different "category". The wakeups we are(were) talking about are based on different phasing between MMU time slots and GLUE video processing. Conceivable, but not very likely, there might be more than two phases. Another possibility is additional wakeups originated from something different, like SHIFTER.

What Paulo describes suggests some true syncing issues between Shifter and MMU/GLUE. Looks like Shifter makes some processing triggered by its own 32Mhz clock, without being syncronized with MMU and GLUE signals. The 16 pixels alternated with background are probably because Shifter is receiving the data a few nanosecs too late.

[ljbk]

Hi again !

Well, i will then propose different words for the different situations.

There are 2 "Glue wake up states" and there are several "Shifter wake up states".

Glue is the one that is going to read data from registers $FF820A and $FF8260 to generate the VSYNC, HSYNC and DE signals.
Based on the time slot given to the CPU to write on those registers and to access the MMU and on the time that the contents of those registers (internal to Glue i believe) are checked, you will get the desired effects or not on the VSYNC, HSYNC and DE signals.

Shifter wake up states are much different: they have to do mainly on the delay between the Shifter and the CPU/MMU/Glue chips.
CPU and Glue work at 8 MHz.
MMU works at 16 MHz.
Shifter works at 32 MHz.

CPU needs 2 CPU cycles (8 Shifter cycles) to write to memory.
Glue needs minimum 1 CPU cycles (4 Shifter cycles) to read the contents from its internal registers.
The granularity of DE signal will be then of 1 CPU cycle(4 Shifter cycles), the Glue clock.
As the reading from memory depends on the DE signal and on the MMU, it will occur synchronized with the CPU.
As a conclusion, i think that CPU, Glue and MMU are always synchronized.
What is changing and that we can call "Glue wake up state" is the memory access time slots between the CPU access and the Shifter access.
For my STF i get more than 90% of the time the same state.
So we have all the data and signals available to the Shifter synchronized with a granularity of 1 CPU cycle: 4 Shifter cycles. That is exactly the time it takes to draw 1 pixel in low resolution, 2 pixels in medium resolution and 4 pixels in high resolution.
4 Shifter cyles correspond to 8 cycles transitions. So depending on the HW and synchronization mechanisms, we can have up to 8 Shifter wake up states !
What are the consequences:
1- The Spectrum 512 case: The Shifter is 1 pixel late /4 cycles late related to the CPU/MMU/Glue. The screen is shifted by 1 pixel to the right and you see some stable funny dots on the screen.
2- Same as above but with a variable delay and so you get flashing dots and sometimes you see the bitmap moving to the left or to the right by 1 pixel.
3- The handling of the internal bitmap registers (please check Alien doc) is different from state to state affecting the start of the screen if the fundamental data for the Shifter is changed: the video resolution inside $FF8260.
That is why for some simple fullscreens you get sometimes an unstable picture even if no sync scroll is used: left border resolution switch is enough.

Now what is instability.
You get instability when you have a different number of internal registers filled in the Shifter when it starts to draw a frame than you have when it has ended drawing it.
If you have 0 registers filled, the screen will start at the normal PAL start.
If you have 1 register filled or use the NTSC fooling trick, the screen will start 4 pixels early.
If you have 2 registers filled, the screen will start 8 pixels early.
If you have 3 registers filled, the screen will start 12 pixels early.
It is also possible to have the screen starting 16 pixels early combining with the NTSC fooling trick but that is not so important.
What is important is that the Shifter only draws groups of 16 pixels and that the memory accesses occur always at the same time, reading always the same amount of bytes, only depending on the DE and do not depending on when the Shifter decides to start drawing the bitmap.
With some of the Shifter wake up states you can get to some intermediate states like something between the 0 and the 1, 0 with bands, 2 with bands and 3 with bands.
The most important thing is that there is no way for the CPU, and so the program running, to know what is the current Shifter wake up state. You need the user human eye with the help of test programs to tell you.
Only the Spectrum case can be avoided by the program not using the logical color changing for the pixel where it is supposed to change.
All stuff available to the CPU like the DE triggering timer B or Video Screen counter testing are Shifter independent.
If you have one displacement to the left for one frame and a different one for the next one you get instability.
Shifter itself depending on the wake up mode may have a variable delay: like if you have a disk on the disk drive A or not or if there is some heat or some radio interferences (please don't forget we are talking about a 32 MHz chip: 1 clock cycle is around 30ns long) . This itself is enough to see the screen going to the right and left by 1 pixel from time to time and sometimes consequently different shifts to the left by 4,8,12,16 pixels, bands that are changing from frame to frame ...

Why is all this stuff important ?
When you use synscroll, you are forcing the Shifter to read different amounts of data from the memory, sometimes with a value that is not multiple of 4 words. On top of that you are affecting the resolution register, both to get the borders out or to get the required amount of data to be read or to have the "stabilizer". All this affects the way the Shifter works.
Shifter will behave then like a state machine for each line with:
- an input (number of inter registers filled and probaly some other stuff i do not know yet to explain the bands and the state between the 0 and 1 and the 16 pixels shift)
- working conditions (number of words read from memory / number and timing of the resolution switches during the line / Shifter wake up state)
- an ouput (similar data as in the input leading to a screen shift value)

If you want to do a "normal" sync scroll, the goal is to get a 0 words value as the final output value after all your sync lines.
If you want to try to get a shifted screen then you want to get a constant value at the end no matter of the value entering on the first line.
Please don't forget that the words too much you have inside the Shifter at the end of drawing 1 frame, will be used to draw the next frame.

All this information is based on my experience with my STF mainly with Glue wake up state 2 and on the existing knowledge like the article from Alien. It does not mean that it is 100% accurate, but it should be close to that.


Sorry for the long text, but it is quite a complex subject.


Paulo.

PS: i think i just found a way to get Glue wake up state 1 in a more frequent way: i need to switch on and off very quickly for 2/3 times.
After the next cold reset i get Glue wake up 1 with the screen bitmap shifted 2 or 4 pixels (it is dificult to tell) to the right and i get Nostalgic to work.

[ijor]

The granularity of DE signal will be then of 1 CPU cycle(4 Shifter cycles), the Glue clock.

You don't know that. If that would be true (it might, we just don't know yet), then you would have 4 (GLUE) wakeup states, and not 2.

As the reading from memory depends on the DE signal and on the MMU, it will occur synchronized with the CPU. As a conclusion, i think that CPU, Glue and MMU are always synchronized.

They are certainly not fully synced, otherwise you wouldn't have wakeups. They behavior isn't completely async either, after all they all are clocked by the same crystal.

MMU obviously won't start fetching video data until GLUE raises DE. But it doesn't start syncronously with the DE rasing edge (again, because otherwise you wouldn't have wakeups). So DE is more like an enable signal than a trigerring one.

What is changing and that we can call "Glue wake up state" is the memory access time slots between the CPU access and the Shifter access.

Yes, but changes in relation to the GLUE signals. So it changes the time between DE edges and video data fetching.

So we have all the data and signals available to the Shifter synchronized with a granularity of 1 CPU cycle: 4 Shifter cycles ... 4 Shifter cyles correspond to 8 cycles transitions. So depending on the HW and synchronization mechanisms, we can have up to 8 Shifter wake up states !

Hmm, no. In the best case you could have 4 "Shifter wakeup states", not 8. Shifter (and also GLUE and MMU) could make some processing in either clock edge (raising or falling). But it is almost impossible that this would depend on the wake up.

Furthermore, the fact that one chip is clocked at 32 MHz and other at 8 MHz doesn't necessarily mean you have 4 wakeups. For wakeups to exist you need something more. You need "something" in the hardware to be undeterministic at power-up.

What are the consequences:
1- The Spectrum 512 case: The Shifter is 1 pixel late
2- Same as above but with a variable delay

They are probably two completely different situations. If it is stable (in the sense that the behavior is constant on each power-up), then it might be a wakeup issue. But the second case is not a wakeup issue, it is a syncing/timing problem. Syncing problems might possibly show up in some wakeup(s) only, but they are not just a wakeup isse.

Now what is instability. You get instability when you have a different number of internal registers filled in the Shifter when it starts to draw a frame than you have when it has ended drawing it.

I wouldn't call this "instability". Not sure what would be the best term, but for me unstable means something else. What you described before that things depend on, for example, the floppy motor, that would be unstable.

Unstable should be something that behaves randomly and you can't control. I'm not trying to make a semantic arguing. Just trying to agree on terminology so that we could all understand each other. Because as I said in the previous post, we are talking about instability in at least two completely different senses.

The most important thing is that there is no way for the CPU, and so the program running, to know what is the current Shifter wake up state. You need the user human eye with the help of test programs to tell you.

Absolutely right. Shifter doesn't give any feedback to the system whatsoever. This makes this issue much more complicated to study ... without special hardware. A logic analyzer would certainly be extremely helpful here.

Shifter will behave then like a state machine for each line with:

I don't think the ST Shifter has any concept of line or frame at all. That's precisely why you can implement bitmap sync-scrolling across scans and frames.

This should be very different in the STe. Both MMU and Shifter need some awareness about scans for implementing hardware scrolling.

Shifter itself depending on the wake up mode may have a variable delay: like if you have a disk on the disk drive A or not or if there is some heat or some radio interferences ...

The main problem for understanding Shifter behavior is what exactly Shifter does with the DE signal. After all Shifter could perfectly work without it.

PS: i think i just found a way to get Glue wake up state 1 in a more frequent way: i need to switch on and off very quickly for 2/3 times.
After the next cold reset i get Glue wake up 1 with the screen bitmap shifted 2 or 4 pixels (it is dificult to tell) to the right and i get Nostalgic to work.

Great! This confirms that Shifter is not syncronous at all with DE. The shift should be 2 cycles (2 pixels in low rez). Because what the wakeups produce is a 2 cycles (at the 8 Mhz clock) displacement between HSYNC and the time Shifter gets its data.

[leonard]

PS: i think i just found a way to get Glue wake up state 1 in a more frequent way: i need to switch on and off very quickly for 2/3 times.
After the next cold reset i get Glue wake up 1 with the screen bitmap shifted 2 or 4 pixels (it is dificult to tell) to the right and i get Nostalgic to work.

Great ! so you can see nostalgic mainmenu working without I change anything

One day I should fix the mainmenu , trying to remove efvery or.l (an)+,dn

[ljbk]

PS: i think i just found a way to get Glue wake up state 1 in a more frequent way: i need to switch on and off very quickly for 2/3 times.
After the next cold reset i get Glue wake up 1 with the screen bitmap shifted 2 or 4 pixels (it is dificult to tell) to the right and i get Nostalgic to work.

Great ! so you can see nostalgic mainmenu working without I change anything

One day I should fix the mainmenu , trying to remove efvery or.l (an)+,dn

Great excuse !!!

Btw, i just found out a curious thing that might help explain why the Shifter has a different behaviour also depending on the GLUE wake up states and also probably why the 4 bit hardscroll for "320 pixels pics" seems to be only possible in GLUE wake up state 2.
We knew that the CPU had to update $FF820A.w 2 cycles earlier in Glue wake up state 1 compared to wake up state 2.
Well i just found out that for $FF8260, it is not 2 cycles but 4.

What a strange GLUE ...

[simbo]

first replace capacitor c2 c7 in stf/m machines
c3 10uf in mega st

this is usualy a small orange one and they dry up fast these ones becouse of where in the stf they are
in the mega its worse becouse its a small value
as they dryup the reset /halt cpu pulse width time gets less and less
becouse there is a smaller value of stored charge with less fluid in them {usualy none and they wobble about}

then the system reset vector becomes too short a time for every chip type {each has its own and some longer than others}

and the chipset will init at all different times

so... try this on a wierd machine
also some of the other mods in the hardware section thread

[Dio]

Thread resurrection time...

I've had the logic analyser out again and the different wakeup modes are clearly visible there in the DE asserted to first MMU LOAD latency. This varies when powered off and may take any value between 3 and 6 CPU cycles. The 3 and 4 cycle latency leads to the one that ijor's tester denotes as wakeup mode 2; the 5 and 6 cycle latency lead to wakeup mode 1. My machine appears to have the strongest bias towards the 5-cycle case: 20 runs showed 3-6 cycles respectively as 15%, 5%, 50%, 20% at an ambient temperature of 22 degrees.

In the 3-cycle case, DE is negated during the last load on each line; in the other three cases, the last load occurs after DE ends.

So I can confirm there are definitely 4 wakeup states, but (most likely because of the quantisation of the video and CPU accesses to the 4MHz clock) they do not all have individual effects on the programming model.

Presumably, it would be possible to shift the wakeup state along as desired by interrupting the 8MHz clock at Glue for single cycles. I tried a randomised version of this using a thin sliver of plastic but was unable to generate enough force to break the electrical contact.

[ijor]

Yes, there are 4 wakeup modes here. But for most purposes they are two. This is because the exact alignment between DE and LOAD is not important. Much more important is the relation between the CPU bus cycles and the GLUE video process. But it should be possible to detect all four ones (I need to find the time to work on this) by software.

Yes, of course, you could change wakeup states by interrupting GLUE input clock.

Note that there are some more wakeup "types" unrelated to this one. But I'm not sure if they have any impact at the software level.

[Dio]

So after a bit of sliding windows around the MMU makes the decision about whether the MMU DRAM phase is a video or refresh phase based on the state of DE at about the start of the preceding CPU phase; an obvious-looking candidate is the negative or (half-8MHz-cycle-later) positive edge of the first cycle in the CPU phase, but the window varies from just before the negative edge of that phase for the full cycle (since DE always changes at around that point).

[dml]

I see I posted this in the wrong thread...

http://www.atari-forum.com/viewtopic.ph ... 15#p223115

Anyway one of the strangest things I saw in my tests was a 'drifting' wakeup mode, where the machine would start in one mode and over time would migrate to the other, via something like random noise. I don't know if it was temperature related - probably was.

This seems more like a fault in the hardware - maybe dry caps or a grounding issue (it was an old, heavily used machine even at the time). But if it can happen on one machine it will probably surface in others with age.

Interesting discussion.

[calimero]

Note that of course this does not apply to latest STe with GST-MCU (equivalent to Glue+MMU) and GST SHIFTER which has two data bus to isolate the RAM from the 68000 bus….

The issue has no relation to the custom chip integration or the number of data buses. The CPU/SHIFTER access interleave is present in all STs. That's why the TT has fast RAM.

The wakeup issue might be present on all STs or not. This has strictly no direct relation to the GLUE integration. It of course depends on the exact GLUE part, because this kind of behavior might be different with slight differences in the chip mask. But not exactly because it is integrated with other chip or not.

maybe someone find this interesting: fine description of STe but in french - http://hxc2001.free.fr/yaquoidedans/ata ... index.html

[Cyprian]

maybe someone find this interesting: fine description of STe but in french - http://hxc2001.free.fr/yaquoidedans/ata ... index.html

and almost the same in english
http://info-coach.fr/atari/hardware/STE-HW.php

[larsbrinkhoff]

You get instability when you have a different number of internal registers filled in the Shifter when it starts to draw a frame than you have when it has ended drawing it.
If you have 0 registers filled, the screen will start at the normal PAL start.
If you have 1 register filled or use the NTSC fooling trick, the screen will start 4 pixels early.
If you have 2 registers filled, the screen will start 8 pixels early.
If you have 3 registers filled, the screen will start 12 pixels early.
It is also possible to have the screen starting 16 pixels early combining with the NTSC fooling trick but that is not so important.

What is this NTSC fooling trick, and how does it make the screen start 16 pixels early?