MMU schematics WIP

Troubles with your machine? Just want to speak about the latest improvements? This is the place!

Moderators: Mug UK, Zorro 2, Greenious, spiny, Moderator Team

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

MMU schematics WIP

Postby ijor » Wed Aug 17, 2016 2:15 am

I'll post here my WIP with the MMU chip internal schematics. There are some minor variations between the different chip releases. Unless specified otherwise, I'll address version: C025912-38

C025912-Top.png


3D.JPG


Clock generation circuit:
MmuClock-075.jpg


Trace captures:
Clock-Skew-912.png


Clock-Skew-Zoom.png


Edit: Uploaded a different picture of the schematics that the Forum displays better.
You do not have the required permissions to view the files attached to this post.

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

Re: MMU schematics WIP

Postby ijor » Wed Aug 17, 2016 2:41 am

Now contrast with the same trace performed in a different version of the chip, C100109:

Clock-Skew-C100109.png


This chip shows huge clock skew. I don't know exactly why (would need to see the decap of one of these as well to confirm), but there are two main possibilities. Either this version doesn't include the buffer delay chain (even when this version is a later one?) for some reason. Or either this version is internally faster (may be a die shrink with a newer CMOS process) and Atari forgot to update the delay chain accordingly. Note that it still has a delay in relation to the 4MHZ output, only that it's much smaller. But this may be because of the higher fan-out of the 8MHZ signal?

Btw, this is one of the problems of using a delay chain. It is variable and not completely reliable. The delay would depend on the board temperature. I wonder if this is one of the reasons of the Shifter weird issues observed depending on the warming (wake substates, as Troed call them).
You do not have the required permissions to view the files attached to this post.

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

Re: MMU schematics WIP

Postby troed » Wed Aug 17, 2016 7:45 am

ijor wrote:The delay would depend on the board temperature. I wonder if this is one of the reasons of the Shifter weird issues observed depending on the warming (wake substates, as Troed call them).


Interesting! One of the findings of "every other 16 pixels blank" is that it's memory adress dependent - i.e, if a certain spot of video memory is currently blank and I shift the screen adress displayed that specific 16 pixels will move with it. It does seem like it would implicate the MMU.

/Troed

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

Re: MMU schematics WIP

Postby ijor » Wed Aug 17, 2016 11:12 am

A couple of comments:

The last stage of the output clocks before the buffers is an asynchronous latch, not a synchronous flip-flop. But in this case is not that bad. The latch enable is the clock signal, and the latch input data is coming from a flip flop clocked by the opposite edge. As a consequence of this, the input data should never change while the latch is open. I'm not sure though, exactly why they decided to use an async latch, and not just another sync flop.

Note that there is no delay chain at all on the 4MHZ. The two buffers after the latch are just power buffers for driving the external pin.

The three flip flops that divide the income clock are the ones that produce the current wake state. The two latter are involved in our (in) famous MMU-GLUE wake state. The first one, that produces the initial division from 16MHZ to 8 MHZ, is involved in SHIFTER wake states.

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

Re: MMU schematics WIP

Postby ijor » Wed Aug 17, 2016 11:17 am

troed wrote:Interesting! One of the findings of "every other 16 pixels blank" is that it's memory adress dependent - i.e, if a certain spot of video memory is currently blank and I shift the screen adress displayed that specific 16 pixels will move with it.


Interesting. I don't have any sensible explanation for that.

How are you shifting the screen? Changing the video base, or by some kind of sync scrolling? And 16-pixels blank on all the scan? Stable?

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

Re: MMU schematics WIP

Postby troed » Wed Aug 17, 2016 12:04 pm

ijor wrote:Interesting. I don't have any sensible explanation for that.

How are you shifting the screen? Changing the video base, or by some kind of sync scrolling? And 16-pixels blank on all the scan? Stable?


It's a "normal" 4 line sync scroll so using sync tricks to emulate lower address byte and then changing video base for the 256 byte steps. Three videos follow:

bands.mp4 - no screen address change, taken from a deliberate provocation (only one scanline manipulated) when I tried forcing the "every other 16 pixels blank" in my quest to also be able to figure out workarounds. As you can see, a single line of such provocation can cause disturbances lasting for many lines, also changing every VBL. There actually seems to be order to the madness ...

https://dl.dropboxusercontent.com/u/669647/bands.mp4

faery_bands.mp4 - no screen address change. This is a fullscreen hicolor screen from {Closure} grabbed from when an STF in WS2 moves from "cold" to "warm". It's one of the failures of my "new" fullscreen lines - while I have code that works in WS1/3/4 and STE there's an issue in WS2. The code that works in "cold" produces "every other ..." when "warm" - and vice versa*. When the computer moves from "cold" to "warm" I can thus see how the problem starts with a single such 16 pixels instance at some part of the screen, flickering "on/off", and then more and more of them appear until it's stable in the banded or unbanded mode.

https://dl.dropboxusercontent.com/u/669 ... _bands.mp4

cdist_bands.mp4 - screen address changes. This is the infamous fullscreen 4 bitplane dist from {Closure}, which does use sync scrolling. Same status as above, in between moving from cold to warm. The screen scrolls up and the various 16 blank pixels scrolls "with" it. My only explanation for that is that its memory address related, but I haven't thought too much about it.

https://dl.dropboxusercontent.com/u/669 ... _bands.mp4

/Troed

*) And since I, so far, cannot detect this substate the code will predictably "fail" in one of the modes.

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

Re: MMU schematics WIP

Postby troed » Wed Aug 17, 2016 12:14 pm

ijor wrote:Now contrast with the same trace performed in a different version of the chip, C100109:

This chip shows huge clock skew.


This would be the IMP MMU right? @exxos has documented serious issues with the IMP chipset when he's been designing his boosters. This looks to be complete confirmation, with cause, as to why that is.

/Troed

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

Re: MMU schematics WIP

Postby exxos » Wed Aug 17, 2016 2:56 pm

troed wrote:
ijor wrote:Now contrast with the same trace performed in a different version of the chip, C100109:

This chip shows huge clock skew.


This would be the IMP MMU right? @exxos has documented serious issues with the IMP chipset when he's been designing his boosters. This looks to be complete confirmation, with cause, as to why that is.

/Troed



Was going to ask what the C100109 was, if thats the IMP number then that explains that then..

I've been sent some info, which is being translated currently, but my findings of the IMP was its actually faster, but the speed isn't actually the issue as such, its that because its faster, it can respond to noise on the pulse and it results in false signals being "read", thus IMP = bad. Though it really depends how you look at it.

The info which was sent basically says the same thing. The diode which is often seen on the IMP shifter is there to drop the voltage, so the IMP chip runs slower, aka, not registering false signals.

I've unlikely checked IMP MMU timings, Though its pretty much confirmed they are faster, though as to phases of the clocks, I can't say myself currently. I will try and check it next time I have a STFM plugged in.
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

czietz
Hardware Guru
Hardware Guru
Posts: 469
Joined: Tue May 24, 2016 6:47 pm

Re: MMU schematics WIP

Postby czietz » Wed Aug 17, 2016 4:14 pm

The IMP MMU is not just faster (die shrink, different CMOS process, whatever), but a substantial redesign.

From my work on the MMU address decoding (CPU address lines => DRAM address lines) I know that the IMP MMU simply ignores the memory configuration (in memconf register at 0xFFFF8001) for bank 1 and always uses the bank 0 setup for bank 1, as well. As the IMP MMU and the "non-IMP" MMU (who did manufacture these BTW?) behave differently, there must have been a design change / redesign.

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

Re: MMU schematics WIP

Postby exxos » Wed Aug 17, 2016 4:38 pm

czietz wrote:The IMP MMU is not just faster (die shrink, different CMOS process, whatever), but a substantial redesign.

From my work on the MMU address decoding (CPU address lines => DRAM address lines) I know that the IMP MMU simply ignores the memory configuration (in memconf register at 0xFFFF8001) for bank 1 and always uses the bank 0 setup for bank 1, as well. As the IMP MMU and the "non-IMP" MMU (who did manufacture these BTW?) behave differently, there must have been a design change / redesign.


So we could agree for the time being that the IMP MMU uses CMOS. It could explain the higher speeds. If there is clock skew then it could mean Atari "forgot" about the buffers, and/or knew about it and just left them out. Possible as the chips are faster that it might not have needed the buffers. If Ijor is saying the buffers are not there on the IMP, then it suggests a re-deisgn, possibly Atari were just trying to limit the gates used to get costs down.

I guess that could be tested if I measure the current on the 5V rail with IMP and non-IMP chips. Might not be enough current change to conclude, but I could try it.
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

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

Re: MMU schematics WIP

Postby ijor » Wed Aug 17, 2016 7:18 pm

exxos wrote:Was going to ask what the C100109 was, if thats the IMP number then that explains that then..

I've been sent some info, which is being translated currently, but my findings of the IMP was its actually faster, but the speed isn't actually the issue as such, its that because its faster, it can respond to noise on the pulse and it results in false signals being "read", thus IMP = bad. Though it really depends how you look at it.


Yes, C100109 is an IMP chip. Makes sense. Newer, smaller & faster CMOS process; more sensitive to noise and small glitches.

In the case of the ST chipset, small glitches, if not ignored, can be pretty critical because it has quite some ripple logic.

The info which was sent basically says the same thing. The diode which is often seen on the IMP shifter is there to drop the voltage, so the IMP chip runs slower, aka, not registering false signals.


Very interesting. I have a machine with the full IMP chipset, except Blitter. Wonder if Atari tried to avoid IMP SHIFTER parts at some point.

So we could agree for the time being that the IMP MMU uses CMOS.


All the releases, even the older ones are CMOS. At least the ones I've seen, all from the C02591X-038 generation, are all CMOS gate arrays. I haven't seen any of the chips marked with the -020 suffix, which I believe are the first generation. But I doubt very much they are NMOS.

If Ijor is saying the buffers are not there on the IMP ...


I don't know that. I didn't see yet IMP dies. I only see from the traces that the delay produced by the buffers is much smaller. As I said above, either there are no buffers, and the small delay that it is still seen in comparison to the 4MHZ output is just a consequence of the higher fan-out on the 8MHZ signal. Or either the same buffers produce a much smaller delay on the newer, faster, IMP silicon.

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

Re: MMU schematics WIP

Postby ijor » Wed Aug 17, 2016 7:28 pm

czietz wrote:From my work on the MMU address decoding (CPU address lines => DRAM address lines) I know that the IMP MMU simply ignores the memory configuration (in memconf register at 0xFFFF8001) for bank 1 and always uses the bank 0 setup for bank 1, as well. As the IMP MMU and the "non-IMP" MMU (who did manufacture these BTW?) behave differently, there must have been a design change / redesign.


There are small design changes in all the different releases, not just between IMP and non-IMP. Some differences are well known, such as the top border PAL position in different GLUE versions. For each chip there are 3 or 4 releases, with minor changes in the logic.

Interesting what you found about the bank configuration. I didn't yet complete that part of the chip. It is probably the most complicated, a very deep combinational tree. You could save quite some logic if you reduce the combinations.

I don't know who produced the non-IMP parts. I found a datasheet from NEC, circa 1985, which shows a similar gate array design. But that doesn't mean too much, because may be most gate arrays of the era were very similar.

czietz
Hardware Guru
Hardware Guru
Posts: 469
Joined: Tue May 24, 2016 6:47 pm

Re: MMU schematics WIP

Postby czietz » Wed Aug 17, 2016 7:55 pm

About the CPU to DRAM address line mapping: This is what I found:
https://ocean.czietz.de/index.php/s/eeae6bc782508bf77fcee6afe03d379e#pdfviewer. Maybe this helps with your schematic creation.

Additional notes not included in the PDF: IMP and non-IMP MMUs have the same mapping; the big difference is -- as already mentioned -- that the non-IMP MMU can be configured to different memory sizes for each bank, while the IMP MMU will apply the configuration for bank 0 also for bank 1. While row and column address 9 are not used for 512 kByte/bank configurations, MAD9 is not fixed to 0 or 1 then but follows MAD8, at least for the IMP MMU.

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

Re: MMU schematics WIP

Postby alien » Thu Aug 18, 2016 3:01 pm

ijor wrote:Btw, this is one of the problems of using a delay chain. It is variable and not completely reliable. The delay would depend on the board temperature. I wonder if this is one of the reasons of the Shifter weird issues observed depending on the warming (wake substates, as Troed call them).


Might be. There clearly are temperature related effects on the Shifter. In fact that was one of the difficulties developing stable hardscrollers, particularly when most of the screen is not in overscan: code that was stable at low temperature would prove unstable at higher temperatures only after some hours of work. Ajrarn, ATM & I were writing a shoot-them-up, but I wanted to use more line-lengths to reduce the total number of scan-lines needed. Verifying stability for every wakestate at every temperature required a lot of time & patience.
Alien / ST-Connexion

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

Re: MMU schematics WIP

Postby ijor » Fri Aug 19, 2016 1:35 am

alien wrote:Might be. There clearly are temperature related effects on the Shifter. In fact that was one of the difficulties developing stable hardscrollers, particularly when most of the screen is not in overscan: code that was stable at low temperature would prove unstable at higher temperatures only after some hours of work. Ajrarn, ATM & I were writing a shoot-them-up, but I wanted to use more line-lengths to reduce the total number of scan-lines needed. Verifying stability for every wakestate at every temperature required a lot of time & patience.


No doubt there are temperature effects on Shifter. I'm just no sure how much the buffer delay chain delay affects this.

The problem is that Shifter isn't really fully synchronized to the rest of the system. With or without that delay, you still have the clock skew when Shifter performs the 32MHz to 16MHz division. This affects among other things, the exact timing when the CPU (at the 8MHZ clock) writes to Shifter to change the resolution. Depending on the temperature, the write might reach on this, or the other 32MHZ cycle.

An additional issue, in your case, is Shifter wakestates. Those can't be detected by software.

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

Re: MMU schematics WIP

Postby exxos » Fri Aug 19, 2016 7:36 am

Easy enough to try troed's full screen demo and make use of a hairdryer to try it out ? IIRC 32MHz to 16MHz delay was only 3ns.
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

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

Re: MMU schematics WIP

Postby ijor » Fri Aug 19, 2016 1:18 pm

exxos wrote:Easy enough to try troed's full screen demo and make use of a hairdryer to try it out ?


That could be an interesting experiment. Would be useful to test the effect on individual chips separately.

IIRC 32MHz to 16MHz delay was only 3ns.


How you measured that? It is normally quite difficult to capture the ST 32MHz edges reliably. On most STs the external clock circuit is not fully squared. The circuit is completed inside shifter. My captures show quite a distorted waveform, with extremely slow edges, not sharp at all. The exact transition point varies a lot depending on which voltage threshold you specify. Very difficult to know at which point exactly Shifter internally detects the clock transition.

May be even this, the relative length of the low vs the high phases of the 32 MHZ clock, it's also affected by the temperature.

Anyway, it is not just that delay, it is a summatory of all the delays. On top of the clock skews, each chip has internal and external combinatorial delays. To make things worse, the chips deal with the external interface mostly asynchronously, they don't synchronize them internally.

This is a capture of the Shifter CS pulse:

Shifter-Cs-Delay.png


There are 37 ns from the 8MHZ clock edge to the SHIFTER_CS one !!! That's more than a whole 32MHZ cycle. And this is completely disregarding the clock skews. And the story doesn't end there. Shifter will add internally quite some delay before processing the write strobe pulse. I count something like 10 gates between the external CS pin and the point where the resolution change will be relevant (and there is no clock syncrhonization in between)!

So it's not surprising at all the temperature effects. The reason that normally doesn't matter, is because normally you don't change resolution in the middle of a scan line (and if you do just by chance, you don't care if it arrived one cycle earlier or later). The rez change between mono and color is the most critical, because only then the internal 32MHZ clock is involved.
You do not have the required permissions to view the files attached to this post.

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

Re: MMU schematics WIP

Postby exxos » Fri Aug 19, 2016 1:32 pm

I capture 16mhz and 32mhz direct on the shifter pins and overlay them on my scope. I look for when the signals start to rise , and fall, and measure in between. In some cases if rise and fall times are the same, then I can measure the "gap" in between. So when I measure I use various "methods" to "sum up" a conclusion. Just need to see when signals start to rise and fall and take that as start end end point. Actually really easy.

The scope can even monitor timings automatically, but I just capture and freeze and adjust the cursors manually. I do that a few times taking new samples each time to be sure.

Of course there is margin for error if you really wanted to get down to the wire. Could be anything from 0ns to 6ns. Though I was happy at the time to conclude 3ns was the delay. I'm sure I posted some images some time ago somewhere already.
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
troed
Atari God
Atari God
Posts: 1197
Joined: Mon Apr 30, 2012 6:20 pm
Location: Sweden

Re: MMU schematics WIP

Postby troed » Fri Aug 19, 2016 1:41 pm

alien wrote:Might be. There clearly are temperature related effects on the Shifter. In fact that was one of the difficulties developing stable hardscrollers, particularly when most of the screen is not in overscan: code that was stable at low temperature would prove unstable at higher temperatures only after some hours of work. Ajrarn, ATM & I were writing a shoot-them-up, but I wanted to use more line-lengths to reduce the total number of scan-lines needed. Verifying stability for every wakestate at every temperature required a lot of time & patience.


When I wrote LoSTE in 2013 (my first 1+3 line sync scroller) it was a complete nightmare to get stable. Normally a fullscreen stabilizes itself after the sync scroll, but LoSTE was non-fullscreen. I ended up concluding that MED-LO ("ULM") stabilizers are less affected by heat effects than HI-LOW ("L16") - but even then I had to "blacklist" many line combinations because they produced banded/striped/bitplane errors (all Shifter effects) depending on wakestate and cold/warming/warm.

I estimate having done more than a thousand power cycles while testing. Most certainly more.

Anyway - I think the persistent Shifter wakestate Ijor is documenting might be different from the heat-affected "substate" I researched when I wrote {Closure}. It's interesting research and when I get time I will look more into it.

/Troed

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

Re: MMU schematics WIP

Postby ijor » Fri Aug 19, 2016 4:56 pm

exxos wrote:Just need to see when signals start to rise and fall and take that as start end end point. Actually really easy.


But in this case this is not very accurate. The transition point is not at the start, neither at the end of edge. It is somewhere at the middle, and it is difficult to know exactly where. If the edges are very sharp, or if at least both waveform are very similar, then that would be ok. But here they are very different.

Could be anything from 0ns to 6ns. Though I was happy at the time to conclude 3ns was the delay.


For a 32 MHz signal, 3ns more, or 3ns less, the difference is quite significant. Obviously 3ns delay is not realistic for the technology of the time, not even 6ns. What you are seeing is the delay at the next edge, or might be even at the next cycle. So the delay is actually MUCH larger, and a few ns variation could easily make the difference between a signal reaching at one cycle, or at the next one.

I'm sure I posted some images some time ago somewhere already.


Would like to see the them if you can find the post. I don't have a high bandwidth scope, let alone a dual channel one. I do have a high bandwidth LA, but it is not the same thing here.

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

Re: MMU schematics WIP

Postby ijor » Fri Aug 19, 2016 4:59 pm

troed wrote:I ended up concluding that MED-LO ("ULM") stabilizers are less affected by heat effects than HI-LOW ("L16")


It certainly should be less sensitive. A MED-LO switch doesn't engage Shifter's 32MHZ clock.

czietz
Hardware Guru
Hardware Guru
Posts: 469
Joined: Tue May 24, 2016 6:47 pm

Re: MMU schematics WIP

Postby czietz » Fri Aug 19, 2016 6:25 pm

Hm, my usual scope with 100 MHz BW is limited -- by rule of thumb -- to rise times of about 3.6 ns. That could already be borderline when measuring the clock signals. So it's time to get the good stuff out of the storage rack. Here are some scope shots (with different timebases) taken with my 400 MHz bandwidth scope.

Upper trace is the 16 MHz signal measured directly at the shifter of my 1040STfm, lower trace is the 32 MHz signal also measured directly at the shifter. The shifter is a IMP C07013-002, datecode 8820. I also have a 1040STf with a non-IMP chipset, if anyone is interested.

From the traces I agree with ijor that it's hard to say where the transitions are, especially for the 32 MHz signal, which has rather slow rise and fall times.
You do not have the required permissions to view the files attached to this post.

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

Re: MMU schematics WIP

Postby exxos » Fri Aug 19, 2016 6:29 pm

ijor wrote:But in this case this is not very accurate.


Don't see why you would say that, high sampling scope can see very accurately all aspects of the wave and measure. use same method to verify the speeds of the GAL's I use in my boosters. I can find out if they are 25ns, 15ns, 7ns parts easily.

The only difference with the shifter is the possibility of variations on rise and fall times which could give different results depending on what you class as a logic 1. Its why I don't use a LA for this type of measuring, to much skew and jitter etc.


ijor wrote:The transition point is not at the start, neither at the end of edge. It is somewhere at the middle, and it is difficult to know exactly where. If the edges are very sharp, or if at least both waveform are very similar, then that would be ok. But here they are very different.


If you are talking about the logic levels, while there may be some variation, it would be negligible. Even if you take 2 volts edge to edge providing the rise and fall times are basically the same, then the result wouldn't be any different from measuring the edge start.

If on the otherhand, it was comparing 2 different speed rise and fall times, then that may increase margin for error. Though the slopes would have to be a fair amount out to warrant any real variations in results.


ijor wrote:For a 32 MHz signal, 3ns more, or 3ns less, the difference is quite significant.


Correct.

ijor wrote:Obviously 3ns delay is not realistic for the technology of the time, not even 6ns. What you are seeing is the delay at the next edge, or might be even at the next cycle. So the delay is actually MUCH larger, and a few ns variation could easily make the difference between a signal reaching at one cycle, or at the next one.


Yes, this is why I said there must be a delay chain ages ago. Its possible technically the 3ns could be a advance timing rather than a 3 ns delay. If you have a 30ns wave (for arguments sake) and delayed that by 27ns, you will see a 3ns different, technically the delayed waveform would be 3ns ahead of the next original transition, it depends how you want to look at it.

So I shall re-pharse what I said before, and say there is a 3ns difference, as delay isn't actually a totally accurate description. Possible it could be +3ns or -3ns.

ijor wrote:Would like to see the them if you can find the post. I don't have a high bandwidth scope, let alone a dual channel one. I do have a high bandwidth LA, but it is not the same thing here.


I can't just see a 32m vs 16 on my stick, I have found 32 vs 8, and 8 vs 4 though.

4mst.png

32f.png


EDIT1:

Quickly hooked up a STF board, see different delays on that again. This one I get 6.8ns on the start of both falls. If you take the "mid point transition" then I get 6.4ns.

In fact I am sure when I re-tested another board there was zero phase difference. So how this looks to me is the 32-16 delay seems to vary between chips.

3216.png


EDIT2: Also heated up the shifter to "burn your finger hot" and saw no difference in timings.
You do not have the required permissions to view the files attached to this post.
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

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

Re: MMU schematics WIP

Postby ijor » Fri Aug 19, 2016 7:07 pm

czietz wrote:Here are some scope shots (with different timebases) taken with my 400 MHz bandwidth scope.

Upper trace is the 16 MHz signal measured directly at the shifter of my 1040STfm, lower trace is the 32 MHz signal also measured directly at the shifter. The shifter is a IMP C07013-002, datecode 8820. I also have a 1040STf with a non-IMP chipset, if anyone is interested.


Thanks very much!

If you can scope the 1040, yes, that would be nice. Not only because I expect a possible different delay between both signals, but also because the IMP part should have a different clock circuit inside, even the pinout is slightly different.

If you check the schematics, you can see the non-IMP part has a xtal feed back on pin 1 (normally connected with a pull down). The IMP part has no feed back, and pin 1 is used for the BLANK signal coming from GLUE.

exxos wrote:Don't see why you would say that, high sampling scope ... If on the otherhand, it was comparing 2 different speed rise and fall times, then that may increase margin for error.


That's exactly my point, they are quite different. See czietz capture at the highest timebase (5ns). The 32 MHZ signal rise and fall time are almost twice the time than the 16 MHZ ones. Also the shape of the wave is quite different. The 16 MHZ is pretty much a square wave, but the 32 MHZ is much more sinusoidal.

See that you do need a very high bandwidth scope and a very small timebase too see this clearly.

ijor wrote:So I shall re-pharse what I said before, and say there is a 3ns difference, as delay isn't actually a totally accurate description. Possible it could be +3ns or -3ns.


I wasn't trying to make a point of you being wrong with the value. But there is a huge difference in the expected variation with the temperature. If the total delay is 3ns, the temperature effect can't probably reach a single extra ns. On the other hand, if the total delay was more something like 20 or 30 ns, then the temperature ramp would certainly make a big difference, and even more if there is a delay chain.

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

Re: MMU schematics WIP

Postby exxos » Fri Aug 19, 2016 7:09 pm

ijor wrote:But there is a huge difference in the expected variation with the temperature. If the total delay is 3ns, the temperature effect can't probably reach a single extra ns. On the other hand, if the total delay was more something like 20 or 30 ns, then the temperature ramp would certainly make a big difference, and even more if there is a delay chain.


I just edited my previous post. I didnt see any variation in clocks when cooking the shifter. So if there is a variation, its not clock related.
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


Social Media

     

Return to “Hardware”

Who is online

Users browsing this forum: Atari030 and 6 guests