Sync-tricks/fullscreen discussion

GFA, ASM, STOS, ...

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

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

Re: Sync-tricks/fullscreen discussion

Postby Steven Seagal » Sun Mar 20, 2016 10:46 pm

tin wrote:
Any demo code certainly experimented crash / bad video when setting bit 0 by mistake. I remember trying it in the 90's, expecting that it could give some kind of vertical hardscroll or similar by carefully setting bit to 1/0, but it mostly gave unstable picture. Results certainly depended on STF vs STE and the kind of CRT monitor.
I don't think it was ever used in any demo or allowed special tricks, so that's certainly why nobody cared to do more research on it as it has no usage in games/demos.

I did use external sync for sync scrolling back in the days. Unfortunately it wasn't only depending on the monitor, but even on the SCART cable :) A one line sync scroller was done this way - but after sending a screen using this around we quickly realized that it worked almost nowhere and there was no way to get it stable (except via hardware mods). So we scrapped it.
I guess I was lucky that my cable/monitor combinated allowed me to discover this.


If whatever may happen, it's not hard to emulate :)
I propose 0 byte lines while bit 0 of SYNC is set.

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

Re: Sync-tricks/fullscreen discussion

Postby Steven Seagal » Sun Mar 20, 2016 10:55 pm

troed wrote:However, while I'm positive you're correct in that the MMU and CPU can occupy one or the other of two possible 2-cycle slots respectively, which indeed is the original wakestate hypothesis - and one I think Steven has implemented in Steem SSE - it actually isn't what I have deduced from my black box reverse engineering. Of course, my hypothesis could be false, but the original only allows for two wakestates and we know that there are four.


About Steem SSE, it started with ijor's 2 "wakeups", then it became Dio and Paolo their 4 "wakestates", that's why in the options there's mention of DL, WU and WS. But AFAIK, both concepts are compatible.

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

Re: Sync-tricks/fullscreen discussion

Postby npomarede » Sun Mar 20, 2016 11:00 pm

Steven Seagal wrote:If whatever may happen, it's not hard to emulate :)
I propose 0 byte lines while bit 0 of SYNC is set.

You get pixels displayed when external sync is selected, so I don't think it should be emulated as 0 byte line. It's more like a mix of the screen bending you get when staying too long at 60 Hz during a 50 Hz screen, but with possible left/right and up/down move of the screen (think like what you get when the scart cable is not correctly plugged and the picture is completely unstable)

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

Re: Sync-tricks/fullscreen discussion

Postby ijor » Mon Mar 21, 2016 2:50 am

Cyprian wrote:by "rounding up to 4" we understand process when GLUE inserts wait states when CPU tries to access RAM/Hardware. Therefore in case of access REZ (shift) register, how GLUE can "gets the new value without waiting for the rounding up", when in the same time it inserts wait states for the CPU?


GLUE doesn't insert wait states, MMU does. But this doesn't really matter for this purpose. GLUE could still get the new value even if GLUE itself were the one inserting the wait states. Or for that matter, if MMU (the chip that does insert the wait state) would want to snoop writes to REZ if could do it without waiting.

Why do you think it is not possible? The procedure is roughly as following:

- CPU starts a bus cycle addressing shifter REZ
- CPU drives the data bus with the new value
- GLUE reads the value from the CPU data bus
- Possible wait states inserted here by MMU
- MMU connects the CPU data bus to the RAM data bus
- SHIFTER reads the value from the RAM data bus
- CPU finishes the bus cycle

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

Re: Sync-tricks/fullscreen discussion

Postby ijor » Mon Mar 21, 2016 3:10 am

npomarede wrote:For the inside work, I don't see how we could know if sync and res are combined into a signal internally into glue or if they're checked one after the other.


Trust me, they are combined ...

but unless someone could get a microscope shot of the chip and interpret it, it will be hard to tell.


That's exactly what I did. I already mentioned that: viewtopic.php?f=15&t=28504#p280744

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

Re: Sync-tricks/fullscreen discussion

Postby ijor » Mon Mar 21, 2016 4:26 am

troed wrote:However, while I'm positive you're correct in that the MMU and CPU can occupy one or the other of two possible 2-cycle slots respectively, which indeed is the original wakestate hypothesis - and one I think Steven has implemented in Steem SSE - it actually isn't what I have deduced from my black box reverse engineering. Of course, my hypothesis could be false, but the original only allows for two wakestates and we know that there are four.


No. In first place, what I described here in this thread is not an hypothesis, it is a fact. I've seen the silicon. The GLUE and MMU processes, the counters that drive them, the flip-flops of the counters that are initialized by power-up logic. This is the actual hardware and this, by itself, predicts the four wakestates.

My original article describes two wakeups because I made a couple of mistakes at the time. At that time yes, it was an hypothesis partially based on speculation about the chip internals. That was before I reverse engineered the silicon. My main mistake was a naive oversimplification of the MMU ram slots interleaving process, which I thought it could be clocked by a single bit counter.

So my original model, indeed allows only two states. But that's only if you take my original model verbatim. Just modify slightly the MMU part of the model and you get all the four states.

... all four wakestates are explained by 0-3 cycle offsets between the GLUE and CPU (the table from the wiki I cited above).


Again. Yes, of course. But what produces that offset between GLUE and CPU? It's MMU. And that is regardless of the whole wakestates issue. The CPU has no choice but to align exactly (single cycle accuracy) to MMU timing.

Consider the following:

MMU RAM process timing (as seen with the 8 MHz clock):

Cycle 0: starts CPU 2-cycles slot
Cycle 1: ends CPU 2-cycles slot
Cycle 2: starts Video 2-cycles slot
Cycle 3: ends Video 2-cycles slot

Do you see? Any CPU access to the RAM side will align the CPU "NOP" cycle (bus cycles), with those 4 cycles in the above table.

Now GLUE video process timing (as seen with the 8 MHz clock):

Cycle 0: First quarter of the video 2 MHz cycle.
Cycle 1: Second quarter of the video 2 MHz cycle.
Cycle 2: Third quarter of the video 2 MHz cycle.
Cycle 3: Fourth quarter of the video 2 MHz cycle.

Lastly, align GLUE and MMU processes. You have 4 possibilities. Those are your four wakestates.

... and maybe something unexpected: One of the 1040s above (haven't tried the same with the others yet) _always_ - and I mean always - boots in WS3 if a mono monitor is


Interesting ...

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

Re: Sync-tricks/fullscreen discussion

Postby npomarede » Mon Mar 21, 2016 8:38 am

ijor wrote:
npomarede wrote:For the inside work, I don't see how we could know if sync and res are combined into a signal internally into glue or if they're checked one after the other.


Trust me, they are combined ...

but unless someone could get a microscope shot of the chip and interpret it, it will be hard to tell.


That's exactly what I did. I already mentioned that: viewtopic.php?f=15&t=28504#p280744

From your very detailed explanations, I always wondered if you did not do some kind of chip decapping to have all those infos about the inner work. I didn't see the above post, but it's very interesting to know. If you have time, maybe you could post a few pictures of the chip or the steps you used to remove the epoxy layers and so on.

Nicolas

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

Re: Sync-tricks/fullscreen discussion

Postby troed » Mon Mar 21, 2016 10:23 am

ijor wrote:No. In first place, what I described here in this thread is not an hypothesis, it is a fact. I've seen the silicon. The GLUE and MMU processes, the counters that drive them, the flip-flops of the counters that are initialized by power-up logic. This is the actual hardware and this, by itself, predicts the four wakestates.


... and for that I'm extremely happy. The table on the wiki (and the speculation of res being one cycle later than freq as seen from the CPU) was completely black-box reversed from studying the effects of the wakestates and now being able to understand from your investigation that it in fact is an accurate reflection of the actual hardware is extremely rewarding.

... all four wakestates are explained by 0-3 cycle offsets between the GLUE and CPU (the table from the wiki I cited above).


Again. Yes, of course. But what produces that offset between GLUE and CPU? It's MMU. And that is regardless of the whole wakestates issue. The CPU has no choice but to align exactly (single cycle accuracy) to MMU timing.


Alright, yes, as I wrote in the other thread I've come around to understanding that's how it originates. I'm fine saying both GLUE-MMU wakestates (hardware cause) and GLUE-CPU (how it's effecting a program running on the CPU).

I posit "Spectrum 512 black pixels" (et al) to be "MMU-Shifter" wakestates - but haven't finished thinking everything through just yet. Any insight you have from your silicon reversing would speed things along greatly.

... and maybe something unexpected: One of the 1040s above (haven't tried the same with the others yet) _always_ - and I mean always - boots in WS3 if a mono monitor is


Interesting ...


Yes :) It's on my todo to see if it's the same on the other machines.

/Troed

User avatar
exxos
Hardware Guru
Hardware Guru
Posts: 4933
Joined: Fri Mar 28, 2003 8:36 pm
Location: England
Contact:

Re: Sync-tricks/fullscreen discussion

Postby exxos » Mon Mar 21, 2016 10:32 am

ijor wrote:That's exactly what I did. I already mentioned that: viewtopic.php?f=15&t=28504#p280744


Did you ever finish up the MMU internals fully ? The MMU is whats always holding up my CPU boosters as it seems to conflict with a faster CPU, unless the MMU runs faster itself :roll:
4MB STFM 1.44 FD- VELOCE+ 020 STE - Falcon 030 CT60 - Atari 2600 - Atari 7800 - Gigafile - SD Floppy Emulator - PeST - various clutter

http://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
http://www.exxoshost.co.uk/atari/last/storenew/ - All my hardware mods for sale - Please help support by making a purchase.
http://ataristeven.exxoshost.co.uk/Steem.htm Latest Steem Emulator

User avatar
Cyprian
Atari God
Atari God
Posts: 1404
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

Re: Sync-tricks/fullscreen discussion

Postby Cyprian » Mon Mar 21, 2016 11:31 am

ijor wrote:
Cyprian wrote:by "rounding up to 4" we understand process when GLUE inserts wait states when CPU tries to access RAM/Hardware. Therefore in case of access REZ (shift) register, how GLUE can "gets the new value without waiting for the rounding up", when in the same time it inserts wait states for the CPU?


GLUE doesn't insert wait states, MMU does. But this doesn't really matter for this purpose. GLUE could still get the new value even if GLUE itself were the one inserting the wait states. Or for that matter, if MMU (the chip that does insert the wait state) would want to snoop writes to REZ if could do it without waiting.

Why do you think it is not possible? The procedure is roughly as following:

- CPU starts a bus cycle addressing shifter REZ
- CPU drives the data bus with the new value
- GLUE reads the value from the CPU data bus
- Possible wait states inserted here by MMU
- MMU connects the CPU data bus to the RAM data bus
- SHIFTER reads the value from the RAM data bus
- CPU finishes the bus cycle

ok, it's clear now. I just lost that point "- CPU drives the data bus with the new value"
Jaugar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
SDrive / PAK68/3 / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
Hatari / Aranym / Steem / Saint
http://260ste.appspot.com/

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

Re: Sync-tricks/fullscreen discussion

Postby ijor » Mon Mar 21, 2016 12:22 pm

troed wrote:I'm fine saying both GLUE-MMU wakestates (hardware cause) and GLUE-CPU (how it's effecting a program running on the CPU).


Yes, but again, keep in mind that the GLUE-CPU shift depends on being aligned to MMU. If say, you are running code from Rom, you could access GLUE with a different shift.

I posit "Spectrum 512 black pixels" (et al) to be "MMU-Shifter" wakestates - but haven't finished thinking everything through just yet. Any insight you have from your silicon reversing would speed things along greatly.


I'm afraid I don't know much about it. That's an issue I never studied. But possibly, it is a similar issue. Similar in the sense that they might be the effect of the alignment between two processes that depend on power-up initialization. And likely there is no feedback to be able to detect those wakestates by software. But I didn't (yet) analyze Shifter silicon enough to be able to be more helpful at this point.

Can you point me to a detailed description of the effect?

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

Re: Sync-tricks/fullscreen discussion

Postby ijor » Mon Mar 21, 2016 12:41 pm

npomarede wrote:From your very detailed explanations, I always wondered if you did not do some kind of chip decapping to have all those infos about the inner work.


Actually almost all the explanations you are talking about are before I analyzed the silicon, and they are product of "regular" reverse engineering. Using LA traces in some cases.

I reverse engineered the ST silicon rather recently. I did first the 8-bit chipset (published the schematics long ago).

If you have time, maybe you could post a few pictures of the chip or the steps you used to remove the epoxy layers and so on.


I didn't perform the actual physical decap myself. I sent the chips to a lab to do that.

Meet GLUE:
You do not have the required permissions to view the files attached to this post.

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

Re: Sync-tricks/fullscreen discussion

Postby npomarede » Mon Mar 21, 2016 1:05 pm

ijor wrote:I didn't perform the actual physical decap myself. I sent the chips to a lab to do that.

Meet GLUE:

Great ! At least we meet :-)

Are there some kind of chip-to-vhdl or similar language programs, where you would give the chip schematic as input and it would perform some kind of analysis to do a map of the chip (for example, this area is memory, this area is some add/counter logic, ...) or do you have to follow each input pin by hand and see where the signal goes and through which components to determine the "pseudo program" associated with it ? (I guess it's the later, which requires quite some work)

User avatar
Cyprian
Atari God
Atari God
Posts: 1404
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

Re: Sync-tricks/fullscreen discussion

Postby Cyprian » Mon Mar 21, 2016 1:47 pm

BIG WOW!!
Jaugar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
SDrive / PAK68/3 / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
Hatari / Aranym / Steem / Saint
http://260ste.appspot.com/

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

Re: Sync-tricks/fullscreen discussion

Postby larsbrinkhoff » Tue Mar 22, 2016 11:11 am

ijor wrote:If say, you are running code from Rom, you could access GLUE with a different shift.


I envison a future where all the hottest cutting-edge demos are running out of cartridges. Gotta get that two-cycle precision!

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

Re: Sync-tricks/fullscreen discussion

Postby ijor » Tue Mar 22, 2016 3:41 pm

npomarede wrote:Are there some kind of chip-to-vhdl or similar language programs, where you would give the chip schematic as input and it would perform some kind of analysis to do a map of the chip (for example, this area is memory, this area is some add/counter logic, ...) or do you have to follow each input pin by hand and see where the signal goes and through which components to determine the "pseudo program" associated with it ? (I guess it's the later, which requires quite some work)


There are some tools, but I didn't use any except my own ones. There is no tool that I know that will save you from the bulk of the work. Yeah, it is such a huge task. There is an enormous amount of time spent before you can have schematics, or netlist, or hdl code, or anything else that is machine readable.

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

Re: Sync-tricks/fullscreen discussion

Postby alien » Wed Mar 23, 2016 3:43 am

ijor wrote:Each one of these chips has a two bits counter that clocks its respective process. The counters are not affected by hardware reset. This is by design because the processes are not completely stopped during Reset. The counters then are initialized at power up time only.

There is no board level power up logic. Each chip implements its own power up detection. Power up timing is not fully deterministic and partially random. Depending on environmental and voltage factors, power up logic will end, and then let the counters run free, at a different cycle.

The end result is that the two counters, and then the processes, are not aligned. Even when they are synchronized by the same master clock, the relation between the values of each counter will vary across power up cycles.


Another hypothesis would be that the counters are not initialized at powerup, and therefore can be in one of 4 states. Since they are not connected to the RESET line (which is usually how one initializes flops to zero for instance), this seems quite possible, depending on the actual circuit used. Given that you're translating the decapped Glue into a schematic (congratulations! :cheers: ), I'm curious whether you have evidence for either hypothesis.
Alien / ST-Connexion

User avatar
AdamK
Captain Atari
Captain Atari
Posts: 234
Joined: Wed Aug 21, 2013 8:44 am

Re: Sync-tricks/fullscreen discussion

Postby AdamK » Wed Mar 23, 2016 8:34 am

ijor wrote:Meet GLUE:

Could you publish all chips somewhere (maybe visual6502.org is a good place), so other interested people could work on them.
Atari: FireBee, Falcon030 + CT60e + SuperVidel + SvEthlana, TT, 520ST + 4MB ST RAM + 8MB TT RAM + CosmosEx + SC1435, 1040STFM + UltraSatan + SM124, 1040STE 4MB ST RAM + 8MB TT RAM + CosmosEx + NetUSBee + SM144 + SC1224, 65XE + U1MB + VBXE + SIDE2, Jaguar, Lynx II, 2 x Portfolio (HPC-006)

Adam Klobukowski [adamklobukowski@gmail.com]

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

Re: Sync-tricks/fullscreen discussion

Postby ijor » Wed Mar 23, 2016 12:10 pm

alien wrote:Another hypothesis would be that the counters are not initialized at powerup, and therefore can be in one of 4 states ... I'm curious whether you have evidence for either hypothesis.


Hi Alien,

That was mi initial hypothesis as well. Mainly because I HAD NO IDEA that those chips implement power-up logic.

GLUE does reset the flops at power-up, I can confirm 100%.

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

Re: Sync-tricks/fullscreen discussion

Postby ijor » Wed Mar 23, 2016 12:31 pm

AdamK wrote:Could you publish all chips somewhere (maybe visual6502.org is a good place), so other interested people could work on them.


I will publish everything, of course. Need to make some cleanup first. If you or anybody else needs something in the meantime, you can contact me by email.

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

Re: Sync-tricks/fullscreen discussion

Postby troed » Sun Mar 27, 2016 10:09 am

FYI thanks to Ijor's great input I will update the wiki with updated models shortly, after having done some manual verification of timings in 60Hz and mono.

In the meantime I've documented my hypothesis for "Every 16 pixels black" on the wiki. If IR is a FIFO it works as a conceptual model at least.

/Troed

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

Re: Sync-tricks/fullscreen discussion

Postby Steven Seagal » Sun Mar 27, 2016 10:43 am

troed wrote:In the meantime I've documented my hypothesis for "Every 16 pixels black" on the wiki. If IR is a FIFO it works as a conceptual model at least.


Just semantics, but we know it's border, not black.

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

Re: Sync-tricks/fullscreen discussion

Postby troed » Sun Mar 27, 2016 11:03 am

Steven Seagal wrote:
troed wrote:In the meantime I've documented my hypothesis for "Every 16 pixels black" on the wiki. If IR is a FIFO it works as a conceptual model at least.


Just semantics, but we know it's border, not black.


I know, thus the scare quotes :) I describe on the wiki that palette 0 is displayed (zeros shifted out)

/Troed

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

Re: Sync-tricks/fullscreen discussion

Postby ijor » Mon Mar 28, 2016 3:42 am

troed wrote:In the meantime I've documented my hypothesis for "Every 16 pixels black" on the wiki.

In high resolution it's every fifth group of 16 pixels...


I am trying to look into the Shifter layout, and because I am not really familiar with this, I will ask some questions about it below. But first, I am very surprised to read that it exists in mono as well ... If it happens in mono as well, then I have my doubts it is a Shifter wakeup issue, in the strict sense.

I will appreciate if somebody takes the time to answer the questions:

- What's exactly the behavior? It's every other 16 pixels are displayed at background color?
- It has some relation to the GLUE-MMU wakestates? It happens in all of them?
- I thought the issue happens only when implementing Spectrum 512 effects. But I see it's not the case. That is another different Shifter wakeup issue?
- It happens only when opening the borders?
- Does it really have wakeup behavior? Which means that is not affected by hardware reset. Only by power cycling.

Please forgive my ignorance on the issue ...

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

Re: Sync-tricks/fullscreen discussion

Postby ijor » Mon Mar 28, 2016 12:22 pm

troed wrote:In the meantime I've documented my hypothesis for "Every 16 pixels black" on the wiki. If IR is a FIFO it works as a conceptual model at least ...


I don't understand why a FIFO model would explain the effect. If the problem is indeed that sometimes RR is not reloaded with IR, then it is probably a failure in, precisely, the RR reload logic. That should be the same regardless of IR being a FIFO or not. Or I am missing something?

Btw, do we know what happens exactly when both bits of the REZ registers are set?
I am pretty sure GLUE doesn't care, it mostly ignores REZ bit 0. But I'm unsure what SHIFTER does. What happens with the mono display?


Social Media

     

Return to “Coding”

Who is online

Users browsing this forum: No registered users and 1 guest