Wakeup modes

[ijor]

As some already know, the ST has different “wakeup” modes. Honestly, I wasn’t aware until the issue was mentioned here some months ago. I find it almost fascinating, so I made a small investigation. This is what I have found so far, plus I attached a program to detect and show the current wake up.

The ST has one non-deterministic feature that is determined randomly (well, not exactly, see below) at power up. It is called “wakeup” mode. Depending on the current wake up mode, some programs might not run correctly, or not at all.

I found only two wakeup modes. And I don’t see much possibilities of more than two. If anybody knows about more, please let us know.

The two wakeup modes depend on which bus cycle slots are assigned to the CPU, and which to the MMU/Shifter, in relation to the GLUE video counter clock. It would be actually more accurate to say that they depend on the relation between two internal GLUE clocks.

Let’s assume the following model:

Code: Select all

GLUE has internally a 2Mhz clock (period equivalent to one NOP) for the video state machine. Plus another 4Mhz clock to round robin grant bus access to the CPU or to the SHIFTER.

The two clocks are in perfect phase. This means that the active edge of the 2Mhz clock coincides with the 4Mhz one. The 2Mhz clock toggles an internal flip-flop. But the initial state of the flip-flop is not deterministic at power up.

Then, in one wakeup mode, the CPU is granted access concurrently with the 2Mhz period. In the other, it is the SHIFTER.

Note that it is not really possible to determine if this is the actual hardware internals. This is just a model that explains the behavior. Internally it could be implemented in a few different ways, and still get the same behavior.

What I found very interesting is that in the case of my ST, the wakeup modes are not exactly random. I constantly get one when the machine is cold (after being turned off for several hours), and other when it is warm.

Attached is a small program that will show the current wakeup. Note that the wakeup is set at power-up. It won’t change after reset, not even after executing those “cold-boot” programs. Also note that I don’t know if the multiple wakeup exist on all the ST machines, such as in STe. It might vary depending on the exact GLUE part.

Assuming the cold/hot behavior is not unique to mine machine (which I really have no idea), the most interesting way to test this program is as following: Try it after your machine was turned for all the night. Take note of the shown wakeup. Then power cycle the computer (wait about half a minute), and run the tests again.

Would be interesting to see the results of others.

[DrCoolZic]

Hi Ijor

First some experiment results:

1. Machine: Atari STe, 4Mb memory, TOS 1.62 => Mode Color
• Cold boot over night : Wakeup 1 (cold), after reset: same
• Boot after 30sec, 15sec, 3sec: Wakeup 1 (cold), after reset: same
2. Machine: Atari STf, 4Mb memory, TOS 1.4 => Mode Mono
• Cold boot over night : Wakeup 1 (cold), after reset: same
• Boot after 30sec, 15sec, 3sec: Wakeup 1 (cold), after reset: same

Summary I always get the same result whatever I do.

Now I am trying to understand the "problem".

The Glue chip is responsible to generate the video timings: VSYNC, HSYNC, DE. for that matter is uses an internally generated clock of 2MHz clock (500ns). This clock is generated from an 8MHz input and the Glue has a 2MHz output (probably the same as the one used for video timing?) which is used for the sound chip. The MMU seats between the memory on one side and the CPU and shifter on another side (see diagram). Timing (for 50Hz machine) of DE = 28µs in mono and 64µs in color decomposed in active time of respectively 20µs and 40µs (rest of the cycle is used by the MMU to perform refresh cycle and CPU access) (see timing below). This implies that the shifter accesses the memory 40 times in 20µs for mono and 80 times in 40µs in color that is an access every 500ns in all cases.
As you mention the CPU and SHIFTER interleaves access to memory and therefore during these 20µs the shifter reads 40 words and the CPU accesses (read or write) 40 words [or 40µs 80 words in color].
From what I understand this "sharing" uses an interleave mechanism and not a DMA mechanism and I have never heard of a 4MHz clock that would be used to do an arbitration.
However I have no idea if the access is given first to the CPU or SHIFTER at the beginning of "video active time" and this may be the "problem" you refer to? If this is the case, what is wrong with one or the other accessing memory first?

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….

Jean

[ijor]

2. Machine: Atari STf, 4Mb memory, TOS 1.4 => Mode Mono
• Cold boot over night : Wakeup 1 (cold), after reset: same
• Boot after 30sec, 15sec, 3sec: Wakeup 1 (cold), after reset: same

The results on the STe are not too surprising. It is possible that the STe doesn't has multiple wake up modes. But please try again with your STf. I gave wrong directions for the test. If your machine behaves like mine, then you need some "warm up" to get the other wakeup.

So make sure your ST is turned on for some time (probably an hour should be enough). Turn it off for half a minute. And now try the test again. But yes, it is possible that some STf machines, perhaps the lattest ones, do not have the multiple wake up modes.

As I said, reset has no effect. The wakeup mode is established at powerup.

From what I understand this "sharing" uses an interleave mechanism and not a DMA mechanism and I have never heard of a 4MHz clock that would be used to do an arbitration.

Some kind of arbitration must be implemented. Otherwise the CPU might attempt a bus access concurrently with the SHIFTER. It is of course not a formal bus grant mechanism (as it is used for DMA), that would be too slow. GLUE simply inserts wait states delaying the CPU for two cycles.

Regarding the 4Mhz clock. As I said, that is just a model. GLUE might implement this with several other ways. The effect would be the same as described in the model.

However I have no idea if the access is given first to the CPU or SHIFTER at the beginning of "video active time" and this may be the "problem" you refer to? If this is the case, what is wrong with one or the other accessing memory first?

The problem (well, it is not exactly a problem). Is that in one wakeup CPU bus accesses are concurrently with the GLUE 2Mhz clock (video state machine). And in the other not. This means that using the very same code, the CPU bus accesses under one wakeup will be two cycles earlier than the other, in relation to the GLUE 2Mhz clock.

So a given piece of code that can remove one border under one wakeup, it won't under the other. This is what the code in the test does. This is not something that I invented. This was known long ago by the full screen coders.

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.

[DrCoolZic]

So make sure your ST is turned on for some time (probably an hour should be enough). Turn it off for half a minute. And now try the test again. But yes, it is possible that some STf machines, perhaps the lattest ones, do not have the multiple wake up modes.

Tried after 1H and still getting the same result (i.e. wakeup 1 cold)!? Same after 1H 30mn
I originally thought that the problem could have been with a capacitor keeping its charge before you power up again but from your description (wait an hour) it sounds more like a "thermal" bahavior and if this is the case it is unlikely to be reproducible on other machine?

FYI: My Atari is petty old 87, but memory and TOS has been updated by B&C computer in california in 90-91. I strongly suspect that they have exchanged the main board at this time (although they did not told me!). The 4MB memory extension they have added is the JRI RAM extension board that also adds a second shifter circuit (that is 2 Shiters!) which allows your STf to have a 4096 pallete as on a STe...

Some kind of arbitration must be implemented. Otherwise the CPU might attempt a bus access concurrently with the SHIFTER. It is of course not a formal bus grant mechanism (as it is used for DMA), that would be too slow. GLUE simply inserts wait states delaying the CPU for two cycles.

If you look at the diagram I have provided, you will see that there is really no need for arbitration as this something that happens all the time (one slot for the CPU one slot for the Shifter, or one slot for the CPU one slot for the refresh). This is not like the Shifter (or the CPU) suddenly saying "I need the bus". Of course this is speculative but interleaving makes more sense than arbitration (as you say much too slow).

Is that in one wakeup CPU bus accesses are concurrently with the GLUE 2Mhz clock (video state machine).

How do you know about this internal clock? Are you refering to the 2MHz clock produced for the sound chip?

So a given piece of code that can remove one border under one wakeup, it won't under the other

I though this had to do with overscan and yes if you want to remove borders (specially left and right) you need very precise timing!

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

Yes and no. In fact new chips in the STe provide more than just integration and interleave is most certainly affected!
The new video circuit of the STe (see figure) is more powerful than that of the STf and in addition to extended graphic possibilities, it ensures also the management of the DMA. The GST Shifter is equipped with two data buses of 16 bits one is connected on the data bus of the machine (68000), whereas the other is connected directly to the RAM. On the preceding models, the link between the two buses was made by four TTL circuits which were controlled by the MMU. The fact that the two busses are separated is one of the strong points of STe. Indeed, when the Shifter needs to access the RAM, the insulation is effective, and during this time the 68000 still has its own data bus and can work with the peripheral circuits. When it needs to access of RAM the two buses are connect together by the MMU which avoids this connection during a cycle to read the RAM by Shifter (400000 times a second!).


FYI: May be it is not related to your problem but if you are trying to do overscan you may be interested to know that:
At 60 Hz, the picture starts at line 34 and ends at line 234.
At 50Hz, the picture starts at line X and ends at line X+200.
The value X depends on the genation of the GLUE:
For older STs: X = 63-16 = 47 for "newer" STs: X = 63.
In other words, on older STs, the picture is shifted upwards by 16 lines at 50Hz: this explains why some obtains only 249 lines whereas others get 271 lines for a simple Low-Border Overscan.

[ijor]

Tried after 1H and still getting the same result (i.e. wakeup 1 cold)!? ... it sounds more like a "thermal" bahavior and if this is the case it is unlikely to be reproducible on other machine?

Again, it is not something specific of my computer. The wakeup modes were found many years ago. It was already mentioned in french magazines back in the old days. Of course, it is very possible that they are not present in all ST machines, but surely it is not specific to mine.

If you look at the diagram I have provided, you will see that there is really no need for arbitration as this something that happens all the time (one slot for the CPU one slot for the Shifter, or one slot for the CPU one slot for the refresh). This is not like the Shifter (or the CPU) suddenly saying "I need the bus". Of course this is speculative but interleaving makes more sense than arbitration (as you say much too slow).

But the CPU doesn't perform any interleaving by itself. The CPU "thinks" he owns the bus all the time. And it will try to access the bus whenever he wants. So GLUE forces the interleaving by inserting two wait states. And it will do it only when the CPU attempts a bus access in a Shifter slot.

So you may call it a "forced interleaving" if you want instead of arbitration. But it is still GLUE who stops the CPU for two cycles. It is not a natural interleaving.

How do you know about this internal clock? Are you refering to the 2MHz clock produced for the sound chip?

Hmm, seems like you are not reading what I write. I said it is a model. I have no idea if GLUE indeed has that 2Mhz clock or not. Although it does make a lot of sense to have it. This doesn't change anything, all that it matters is if the models applies or not.

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

Yes and no. In fact new chips in the STe provide more than just integration and interleave is most certainly affected!
The new video circuit of the STe (see figure) is more powerful than that of the STf and in addition to extended graphic possibilities, it ensures also the management of the DMA. The GST Shifter is equipped with two data buses of 16 bits one is connected on the data bus of the machine (68000), whereas the other is connected directly to the RAM. On the preceding models, the link between the two buses was made by four TTL circuits which were controlled by the MMU. The fact that the two busses are separated is one of the strong points of STe.

Not at all. The two data buses (as you call them) are present in all STs. The only difference is that here the TTL buffers and traces are integrated in the new Shifter. This doesn't make any further or better insulation, nor it affects the interleaving.

If you would want to avoid the interleaving you would need dual ported ram, not just two data buses. And that the interleaving (and GLUE wait states) is present in all ST models is very well known and obvious. Otherwise the famous issues of rounding up to 4 the CPU instruction cycles wouldn't be present.

And once again, that why the TT has fast RAM. Fast RAM is not accessed by the Shifter, and then the CPU can access it without any interleaving (which has a worse effect in the 68030 due to the 3 machine cycles per bus access instead of 4, as in the 68000).

[DrCoolZic]

Tested again after 9 hours on and weather condition rather hot today in France!
Still the same wakeup 1 cold!

[DrCoolZic]

Apparently our two last posts were done at the same time…

It is not something specific of my computer. The wakeup modes were found many years ago.

I beleive you! I never said that the problem is specific to your computer or that it does not exist, I just mentioned that if it is related to thermal conditions it is probably going to be difficult to reproduce on different machines… lets wait for others to come and see the percentage of machines that have the problem ...

Not at all. The two data buses (as you call them) are present in all STs. The only difference is that here the TTL buffers and traces are integrated in the new Shifter. This doesn't make any further or better insulation, nor it affects the interleaving.

Yes you are perfectly right this is my mistake (I checked on an STe article) no improvement here for the STe.

No comment on the arbitration ...

[ljbk]

Hi ijor !

Just made your tests.

Most of the time i get:

Wake up: 2 (Warm)

From time to time i get:

Wake up: 1 (cold)


Hi Leonard !

Remember our previous talks via email ?

Nostalgic Main Menu works fine with wake_up_1 but not with wake_up_2 due to that right border removal for some of the lines ...

[MiggyMog]

I will need to try this on my STE at some point, I would bet that mine is at one state around 19 out of 20 times as I get the spec 512 speckles bug discussed in the other thread!

[Lando_C]

my 1040STF (1.02 UK TOS, PAL, with SM125) said mode 1 cold about 30 minutes after (physically cold) boot, but it fsck:ed up my mono display (a lot of vertical black lines), even after the program terminated, so i had to reset.

after powercycle it says wake up 1 cold, but does not destroy the screen..

after another powercycle wake up 2 warm - and shifted the display around the corner, so the
last 16 pixels or so to the right was actually in the left. i can move the mouse off eth right edge and come back into the left.. but it stopped responding to clicks..

fourth powercycle says wake up 1 cold, so it may be pseudo random..

[ijor]

my 1040STF (1.02 UK TOS, PAL, with SM125) said mode 1 cold about 30 minutes after (physically cold) boot, but it fsck:ed up my mono display

Sorry Lando_C. I should have noted that the test wasn't designed for mono monitor/high rez. All sort of strange things are possible, and even expected with a mono monitor. I should actually enhance the test and check for this.

Btw, a few of my comments above are not accurate. GLUE doesn't produce the wait states or assigns the time slots. MMU does.

So the following I wrote at the beginning of the thread:

Code: Select all

GLUE has internally a 2Mhz clock (period equivalent to one NOP) for the video state machine. Plus another 4Mhz clock to round robin grant bus access to the CPU or to the SHIFTER.

Should be changed to:

Code: Select all

GLUE has internally a 2Mhz clock (period equivalent to one NOP) for the video state machine. MMU has a 4Mhz clock to round robin grant bus access to the CPU or to the SHIFTER.

[Lando_C]

No harm done with the mono problems. I was going to reboot/powercycle anyway for seeing if i got different results for you =)

[DrCoolZic]

Humm ... interesting if I remember correctly all my tests were done in Mono HiRez. This could explain why I was always getting the same result?
Jean

[ijor]

Humm ... interesting if I remember correctly all my tests were done in Mono HiRez. This could explain why I was always getting the same result?

Might be, but I don't think so. I would need to check it, but I think that the program should find the current wakeup disregarding the monitor. It might corrupt the display later, so I don't sure if you will get a readable result, and what you'll get when returning to the desktop. But if you do can see the result, it is likely correct.

I do think that some STs simply don't have two wakeups. They have only one. And they are probably the later ST (non-STe) and STe models.

Now, could you please test Paulo's program here:

http://www.atari-forum.com/viewtopic.php?p=75784#75784

It would be very interesting to see what you get. Because your machine might be the "closest" generation to STe models.

[DrCoolZic]

I have tested the Hard16e program on my 1040STF and I am getting a black border. Not sure if it has importance but it seems that the sweeping frequency received by the monitor (a multisynch monitor) is changed by the program resulting in an image slightly shifted and shrinked.

Also tried on a 1040 STE and I am getting complete flickering.


FYI my 1040STF is detected as NTSC @ 32.04.

A little bit of story on my machine: I bought it in Belgium in 89 then I moved to California and in 91 or 92 my machine was upgraded by B&C computer to 4 MB (see below on the upgrade). They were supposed to just add the memory and upgrade the TOS (The TOS of the machine has been upgraded to 1.4) but it is only recently that I actually found that they had in fact exchanged the main board to an US ?newer? version!!!


Upgrade:
The memory upgrade kit is composed of two boards developed by “John Russel innovations (Pittsburg CA) and is called the JRI-RAM+. The main board which receives the SIMM modules is connected to the power lines, to the data bus, to the address bus, and to several control signals. For that matter, a certain number of individual wires (control signals) are soldered directly on the motherboard. Then, a first bus is connected to the board by soldering a “connector" directly onto one of the original DRAM. And finally the original Shifter circuit (C025914-38A), which is located in a shielded trap, is removed and replaced by a small board containing 2 Shifter circuits (this provide a 4096 colors pallete) and a bus cable that goes to the main memory upgrade board.

But this should not have an impact ?

[DrCoolZic]

By the way I rechecked the wakeup program on my 1040STF
... and still getting consistantly cold 1 boot.

After reset the program reboot my machine without displaying anything (tested several times).

After reset consistantly get cold boot 1

[leonard]

Hi Leonard !

Remember our previous talks via email ?

Nostalgic Main Menu works fine with wake_up_1 but not with wake_up_2 due to that right border removal for some of the lines ...

Oh I just see that old thread !! Yes I remember !! Very interesting. I use add.l (ax)+,ay in the mainmenu to optimize register usage, and this is not a 4 cycles boundary instruction.

Well, now we can detect boot up mode (1 or 2) (thanks to Ijor program), do you think it's hard to change my mainemnu to work in both mode? Should I shift my border-setup 1 nop earlier or later (4cycles)? Or do I have to carefully put some paired instruction to shift of -2 or 2 cycles?

[leonard]

Oh Ijor, the fact my mainmenu always worked on my STE means my STE has only one wakeup state. Maybe it can help statistics.

[ljbk]

Hi Leonard !

Remember our previous talks via email ?

Nostalgic Main Menu works fine with wake_up_1 but not with wake_up_2 due to that right border removal for some of the lines ...

Oh I just see that old thread !! Yes I remember !! Very interesting. I use add.l (ax)+,ay in the mainmenu to optimize register usage, and this is not a 4 cycles boundary instruction.

Well, now we can detect boot up mode (1 or 2) (thanks to Ijor program), do you think it's hard to change my mainemnu to work in both mode? Should I shift my border-setup 1 nop earlier or later (4cycles)? Or do I have to carefully put some paired instruction to shift of -2 or 2 cycles?

If i remember right, this was only happenning for some of the lines.
To make it work, you just have to make sure that your last instruction before the right border removal switch to 60 Hz can not be paired.
When building your fullscreen rout, you have to update your algorithm, if possible, to avoid these adds before the sync switch by changing some instructions order for example.
Then it will work in both wake up states.
Only you can say if that is possible and/or a big job or not by looking at your builder.

Paulo.

[ijor]

Oh I just see that old thread !! Yes I remember !! Very interesting. I use add.l (ax)+,ay in the mainmenu to optimize register usage, and this is not a 4 cycles boundary instruction.

If your move that writes to GLUE is right after that instruction, then yes, you are making the write to be misaligned.

Well, now we can detect boot up mode (1 or 2) (thanks to Ijor program), do you think it's hard to change my mainemnu to work in both mode?

You don't have to detect the wake up. This is needed only for the new switches/scan lengths. For the others you can use a timing that works as is in both wakeups.

Or do I have to carefully put some paired instruction to shift of -2 or 2 cycles?

Actually, the opposite. You should not use a pairing combination when removing the right border. Or more precisely, the bus cycle that writes to the freq. register when removing/modifying the right border, must be aligned to a 4 cycles boundary. Otherwise it won't work with both wakeups.

I can't be more specific without seeing your code, or analyzing the effect. But if I remember correctly the exact order of the wakeups (which one is earlier and which one is later), then you need to make the bus cycle two cycles later.

As Paulo recommends, probably all that is needed is to change the order of the instructions. If you make a normal bus cycle in between the ADDA above and the MOVE, then all should be fine.

Say, if you have something like this:

NOP
ADDA (An)+,An
MOVE D0,(An) => writes to freq. register

Replace with:

ADDA (An)+,An
NOP
MOVE D0,(An) => writes to freq. register

Both cases have identical total execution time. The difference is where the two wait states after the ADDA are inserted. In your case they are after MOVE write cycle, on the MOVE prefetch cycle. On the second case, in the NOP prefetch cycle, so MOVE write cycle becomes aligned.

[leonard]

I just checked my code again under SainT debugger. I don't enderstand anything...

I can't find any "add.l (ax)+,ay" in the code anymore. there is tons of "add.l (an)+,dn", but this is not pairable, am I right?

Paulo, did you remember where the pairable instruction were located?

[ijor]

I just checked my code again under SainT debugger. I don't enderstand anything...

Don't worry, something similar happens to me manytimes.

I can't find any "add.l (ax)+,ay" in the code anymore. there is tons of "add.l (an)+,dn", but this is not pairable, am I right?

It is. Both instructions have identical timing.

[leonard]

ok so I'm very tired

is or.l (an)+,dy a paired instruction or not? (don't have accurate cycle table, only a "4 cycles rounded one"

[ijor]

is or.l (an)+,dy a paired instruction or not?

It is. Again, has identical timing as the ADD.L/ADDA.L above.

(don't have accurate cycle table, only a "4 cycles rounded one"

That's one of the reasons I was recommending to use Motorola docs. An instruction table that is already "rounded" has several limitations.

Will reply to your PM after this post. I guessed the answer to this one was more urgent for you

[leonard]

oh ok so I can't easyly change my mainmenu Well, I can add "nop" if a add.l is just before the right border switch, but it will take some CPU time. (but maybe I have enough time left )