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

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

Re: MMU schematics WIP

Postby czietz » Fri Aug 19, 2016 7:30 pm

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


I'll do that tomorrow. My non-IMP ST still has all the original EMC metal shielding in place, so it takes some time to disassemble it.

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.


Interesting, I didn't know that! However, this is not the case for my 1040STfm with full IMP chipset. Pin 1 of the shifter still is connected to ground via a 10k resistor. Do you know why the IMP shifter has a BLANK signal input when it still works when this pin is this is permanently pulled to ground as in my machine?

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.


The 16 MHz signal originates from the output stage of the shifter, while the 32 MHz signal comes from a discrete amplifier. I suppose the IC's output stage is simply faster than the two transistor amplifier.

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

Re: MMU schematics WIP

Postby ijor » Fri Aug 19, 2016 11:43 pm

czietz wrote:Interesting, I didn't know that! However, this is not the case for my 1040STfm with full IMP chipset. Pin 1 of the shifter still is connected to ground via a 10k resistor. Do you know why the IMP shifter has a BLANK signal input when it still works when this pin is this is permanently pulled to ground as in my machine?


I don't have much info about that. I didn't decap an IMP chip yet. I gathered the information from the Mega documentation.

It is not completely clear what is the polarity of the BLANK input. The schematics are not 100% consistent. The GLUE output is low active. But I assume that Atari designed the IMP part to be backwards compatible, so that you could place the new shifter in older motherboards. For that purpose, they could make it high active. If that is the case, then SHIFTER will see the signal as always deasserted in old motherboards which would produce a harmless effect. Blank would still be processed outside the chip.

I wonder if such boards with BLANK connected to Shifter exist at all.

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

Re: MMU schematics WIP

Postby ijor » Sat Aug 20, 2016 12:06 am

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


But it would be quite different if you take the end of both falls (seems they are almost touching). Because as this new scope dump clearly shows, the slopes and the fall and raise times are completely different between both clocks. And I think the scope dumps posted by czietz show this even more. What's the bandwidth of that scope you are using?

That's why I don't consider very reliably to measure delays in relation to the external 32MHz clock. You just don't know where is the transition point inside SHIFTER.

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

Re: MMU schematics WIP

Postby czietz » Sat Aug 20, 2016 10:30 am

OK, this is my 1040STf with a (non-IMP) C025914-38A Shifter, again 32 MHz vs. 16 MHz. The first plot has the falling edges of both signals overlaid so that one can see that again the 16 MHz output is steeper than the 32 MHz input. Interestingly, there also isn't much difference delay-wise between the two Shifters.

It is not completely clear what is the polarity of the BLANK input. The schematics are not 100% consistent. The GLUE output is low active.


In the MegaST schematics containing the Shifter with /BLANK input I don't see any inverter, so I'd assume /BLANK is still low active.
However, I noticed that the Shifter with /BLANK input is designated C070713 in the schmatic. I checked again in my STfm: it really says C07013 on the Shifter. So, maybe this is yet another version, made by IMP but without /BLANK input?
You do not have the required permissions to view the files attached to this post.

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

Re: MMU schematics WIP

Postby ijor » Sat Aug 20, 2016 12:10 pm

czietz wrote:Interestingly, there also isn't much difference delay-wise between the two Shifters.


Shifter, at least the C025914-38 that I decapped, doesn't have a delay chain. If the IMP version doesn't have either, the difference should be smaller than the one between 16MHZ and 8MHZ.

I noticed that the Shifter with /BLANK input is designated C070713 in the schmatic. I checked again in my STfm: it really says C07013 on
the Shifter.


Ah, I missed that difference! Best Electronics lists both parts, so it doesn't seem to be just a typo. But it doesn't mention that C070713 can't be used on older boards. If it has a BLANK input an expect it to be low active, it shouldn't be compatible. I guess we won't know until checking a C070713 ...

Thanks both for the scope dumps! :)

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

Re: MMU schematics WIP

Postby czietz » Sat Aug 20, 2016 12:49 pm

For the sake of completeness here are some plots of 4 MHz and 8 MHz vs. 16 MHz, measured at the Glue. Upper two plots: IMP Glue, lower two plots: non-IMP Glue (C025912-38).
You do not have the required permissions to view the files attached to this post.

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

Re: MMU schematics WIP

Postby czietz » Sat Aug 20, 2016 6:13 pm

ijor wrote:Ah, I missed that difference! Best Electronics lists both parts, so it doesn't seem to be just a typo.


Definitely not a typo: Here is a photo of the shifter im my STfm: C07013-002
IMG_2007.JPG


And on one of Exxos' MegaST photos: C070713-002:
http://www.exxoshost.co.uk/atari/last/MEGAST/megast.jpg

All other markings are identical, except for the date code. So either IMP noticed between week 20 and week 30 of 1988 that they were producing their ICs with the wrong number and fixed this or there were two different versions.

PS: Note that in Exxos' photo R144 is fitted, the 10 k resistor to ground, and not R145, the 0 ohms link to /BLANK.
You do not have the required permissions to view the files attached to this post.

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

Re: MMU schematics WIP

Postby ijor » Sun Aug 21, 2016 12:47 pm

czietz wrote:For the sake of completeness here are some plots of 4 MHz and 8 MHz vs. 16 MHz, measured at the Glue. Upper two plots: IMP Glue, lower two plots: non-IMP Glue (C025912-38).


Thanks. You mean MMU, of course, and not GLUE.

In this case, where the waveform is not a big issue, the traces I posted at the start of the thread might be more useful to measure the delays. They were done with a high bandwidth (1 GHZ) LA.

And on one of Exxos' MegaST photos: C070713-002: ... PS: Note that in Exxos' photo R144 is fitted, the 10 k resistor to ground, and not R145, the 0 ohms link to /BLANK.


Well spotted! :) Well, it confirms that both versions exist. But yet not clear exactly about the BLANK issue.

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

Re: MMU schematics WIP

Postby ijor » Sun Aug 21, 2016 12:55 pm

MMU logic for generating SHIFTER chip select pulse on write cycles (not yet complete for read cycles).

This is one of the internal MMU circuits I was most interested at this time. The timing of this pulse is critical for the SHIFTER, infamous, every other 16 pixels backgr, effect. More comments about this logic on the next message(s).

Mmu-Cmpcs.jpg


Descriptions of the signals:

nClk16 and pClk16, as shown at the clock generation schematics at the top of this thread, are the 16MHZ input clock to MMU, inverted and non inverted.

clk2, also on that same drawing, is the last stage of the clock division. It is a 2MHz clock, after dividing the 16MHZ clock three times. This signal is the one that set the timing of the main MMU process. Its phases establish the MMU slots allocated for the CPU or for Shifter and ram refresh. And the alignment of this clock with GLUE's own 2MHZ clock is our famous GLUE-MMU wakestate.

nPwrUp is supposed to be asserted during power up and initializes most flip-flops on the chip. I don't know for sure if the signal indeed works, every single power up. In the worst case, those flip-flops would come up on a non deterministic state at power up. Here is not very important.

nDEV and nRAM are the inverted signals of their respective input pins.

write Shifter is asserted when the address lines and control signals (xDS,RW,DEV) mark that the CPU is strobing a write cycle to Shifter. The signal is registered by MMU. The exact logic is not included yet, but it is not much relevant for the purpose of the end of the Chip Select pulse. And it is the end of the pulse, the raising edge, what triggers the actual write inside Shifter.

strobeRdShftr is the strobe pulse on a read cycle. Not yet detailed. The timing is slightly different than on a write cycle.
You do not have the required permissions to view the files attached to this post.

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

Re: MMU schematics WIP

Postby ijor » Sun Aug 21, 2016 8:36 pm

I edit the above post and added a description of the internal signals.

I'll expand some more comments later. But there is something quite significant on that logic. The timing of the active edge, the end of the pulse, doesn't depend at all on the 8MHZ clock. The timing is set internally (no when the CPU ends the cycle), and directly by the 16MHZ clock, plus combinatorial delays, of course. This means, that the 8MHZ clock skew, delay chain or not, is not relevant here!

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

Re: MMU schematics WIP

Postby ijor » Wed Aug 24, 2016 5:12 am

Trace showing the timing and the delay of this pulse.

Note that the pulse ends one cycle before the CPU deasserts the DS signal. MMU doesn't wait for the CPU. It ends the pulse on its own synchronous timing.

Note also the delay since the 16MHZ launching edge. The delay inside Shifter, which unfortunately we cannot trace, should be even bigger. This means that, at 32 MHZ (which is what Shifter will be running if rez was set at mono as when opening the left border), the signal will arrive at least one cycle later than it launched.
You do not have the required permissions to view the files attached to this post.

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

Re: MMU schematics WIP

Postby ijor » Wed Aug 24, 2016 5:35 am

I added some pics at the top of the thread!

I found who fabbed the non-IMP gate arrays: RICOH

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

Re: MMU schematics WIP

Postby czietz » Wed Aug 24, 2016 5:49 pm

ijor wrote:I added some pics at the top of the thread!


Nice. May I ask how you remove the epoxy so accurately?

I found who fabbed the non-IMP gate arrays: RICOH


Does it say so on one of the dice or did you find some matching technical data from RICOH?

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

Re: MMU schematics WIP

Postby ijor » Wed Aug 24, 2016 7:07 pm

czietz wrote:Nice. May I ask how you remove the epoxy so accurately?


Sorry, it's a family secret ... jaja
I didn't. I sent it to a lab to perform the actual decap.

Does it say so on one of the dice or did you find some matching technical data from RICOH?


I think it happened to me something similar that it happened to you with the schematics you found. You told me they exist but they are not possible to decode. Seems that by itself motivated you to try again harder, and you find how to read them. Well, there is one mark present on the gate array dies:

MMU-Mark1.jpg


I googled that but didn't find anything. Then you asked. So I guess it motivated me, and yesterday googled again, and found a few references. Now I found the datasheet:

Ricoh-5GH-Datasheet.pdf
You do not have the required permissions to view the files attached to this post.

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

Re: MMU schematics WIP

Postby czietz » Sun Oct 09, 2016 1:37 pm

ijor wrote:
czietz wrote:Interesting, I didn't know that! However, this is not the case for my 1040STfm with full IMP chipset. Pin 1 of the shifter still is connected to ground via a 10k resistor. Do you know why the IMP shifter has a BLANK signal input when it still works when this pin is this is permanently pulled to ground as in my machine?


I don't have much info about that. I didn't decap an IMP chip yet. I gathered the information from the Mega documentation.

It is not completely clear what is the polarity of the BLANK input. The schematics are not 100% consistent. The GLUE output is low active. But I assume that Atari designed the IMP part to be backwards compatible, so that you could place the new shifter in older motherboards. For that purpose, they could make it high active. If that is the case, then SHIFTER will see the signal as always deasserted in old motherboards which would produce a harmless effect. Blank would still be processed outside the chip.


Some time ago, we wondered how the IMP shifter with its /BLANK input could work in a board designed for non-IMP shifters, where this input (pin 1) is pulled down by a 10k resistor. Today, I happened to look into the IMP shifter a little bit and found what looked like an internal pull-up resistor. A voltage measurement on pin 1 (in my STfm with IMP chipset and 10k resistor) confirms this: it's about 2.7 V and thus /BLANK is always seen as deasserted by the shifter.

Pulling pin 1 directly to ground also shows that it indeed acts as a /BLANK input on the IMP shifter. (Recall that in the non-IMP shifter pin 1 was part of the never used internal oscillator, thus, the 10k resistor there.)

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

Re: MMU schematics WIP

Postby ijor » Sun Oct 16, 2016 11:09 pm

czietz wrote:Some time ago, we wondered how the IMP shifter with its /BLANK input could work in a board designed for non-IMP shifters, where this input (pin 1) is pulled down by a 10k resistor. Today, I happened to look into the IMP shifter a little bit and found what looked like an internal pull-up resistor. A voltage measurement on pin 1 (in my STfm with IMP chipset and 10k resistor) confirms this: it's about 2.7 V and thus /BLANK is always seen as deasserted by the shifter.


Very interesting. Thanks for following this up.

Wonder why they didn't make it active high in the new chip. Older chips can't work in the newer boards (that don't have external BLANK logic) anyway. Just some waste of power solving this with a pull-up connected to a pull-down?

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

Re: MMU schematics WIP

Postby Steven Seagal » Fri Oct 06, 2017 8:49 pm

Hello,
As promised I have some MMU questions just in case they made sense and you (ijor) had some answers already:

Does the MMU fetch video memory and present it to the Shifter in one go?
If a read from memory takes 2 cycles, does LOAD happen on the 3rd cycle?
Or is LOAD quasi instant, compared with reading memory?

When is the video counter incremented? During LOAD? It is computing, it could take some cycles.
Could the computing take place between reads, during CPU ram access cycles?
In that case, which value is read by the CPU, before or after incrementing?
I ask this because according to graphs, the DE-LOAD latency is about 6 cycles, but the DE-Video counter start is 8 cycles in emulation (on video counter read as used in many demos).

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

Re: MMU schematics WIP

Postby ijor » Sat Oct 07, 2017 3:44 am

Steven Seagal wrote:Does the MMU fetch video memory and present it to the Shifter in one go?
If a read from memory takes 2 cycles, does LOAD happen on the 3rd cycle?


MMU doesn't fetch any RAM at all. It controls RAM but can't actually read from RAM because it is not connected to the RAM data bus. MMU just setups a RAM access and Shifter reads it directly,

When is the video counter incremented? During LOAD? It is computing, it could take some cycles.


Yes, during LOAD. No, it is incremented all at (about) the same time on the same cycle.

I ask this because according to graphs, the DE-LOAD latency is about 6 cycles,...


It depends on the wakestate.

...but the DE-Video counter start is 8 cycles in emulation (on video counter read as used in many demos).


I'm not sure how you could reach that conclusion. In first place, this also depends on the wakestate. In second place, this exact delay is not relevant to the CPU. The CPU can know at which cycle writes to GLUE affect DE or not, but this doesn't mean at all that the DE edge happens at that cycle because GLUE has all sort of internal delays. Say, GLUE could take the decision to open the border at cycle 4, but the DE edge might happen a couple of cycles later at cycle 8 (just an example). And the CPU can't really detect that delay.

So what you call DE-Video counter start delay is probably something else.

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

Re: MMU schematics WIP

Postby Steven Seagal » Sat Oct 07, 2017 5:56 am

ijor wrote:Yes, during LOAD. No, it is incremented all at (about) the same time on the same cycle.


OK, I thought it would be slower. And so there is no interference with 'read video counter'.

I'm not sure how you could reach that conclusion. In first place, this also depends on the wakestate. In second place, this exact delay is not relevant to the CPU. The CPU can know at which cycle writes to GLUE affect DE or not, but this doesn't mean at all that the DE edge happens at that cycle because GLUE has all sort of internal delays. Say, GLUE could take the decision to open the border at cycle 4, but the DE edge might happen a couple of cycles later at cycle 8 (just an example). And the CPU can't really detect that delay.

So what you call DE-Video counter start delay is probably something else.


It's no conclusion, it's pure speculation. :)

So what you're saying is that the DE signal we see on traces is changed some 4 cycles after the 'decision'.
That's a complication for the model.

Thx for those explanations, it's great help.

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

Re: MMU schematics WIP

Postby ijor » Sat Oct 07, 2017 7:59 pm

Steven Seagal wrote:So what you're saying is that the DE signal we see on traces is changed some 4 cycles after the 'decision'.
That's a complication for the model.


I don't remember if it's 4 cycles, I would need to check. It was just an example to illustrate that there is a delay.

But I'm not sure you should care. For emulation purposes what matters is the delay since GLUE takes the decision until video counter starts, as seen by the CPU. The exact edge of the DE signal is not much relevant for you.

And again, it is not fixed because it depends on the wakestate and also on which GLUE/SHIFTER register is written.

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

Re: MMU schematics WIP

Postby Steven Seagal » Sat Oct 07, 2017 10:15 pm

ijor wrote:I don't remember if it's 4 cycles, I would need to check. It was just an example to illustrate that there is a delay.


And again, it is not fixed because it depends on the wakestate and also on which GLUE/SHIFTER register is written.


Don't worry, I'm not obsessing on exact #cycles now, guess this may be tuned to cases too (using some parameter to see what works). Just trying to understand how it works.

But I'm not sure you should care. For emulation purposes what matters is the delay since GLUE takes the decision until video counter starts, as seen by the CPU. The exact edge of the DE signal is not much relevant for you.


Well, I was thinking of a model where GLUE sets DE true, when the MMU sees that signal, it starts reading video memory, now we can't do that that way.
Do you think the delay is the same for all GLUE video signals?

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

Re: MMU schematics WIP

Postby ijor » Sun Oct 08, 2017 4:59 am

Steven Seagal wrote:Well, I was thinking of a model where GLUE sets DE true, when the MMU sees that signal, it starts reading video memory, now we can't do that that way.


Functionally that is correct. When GLUE asserts DE, MMU starts the video process. But because of the internal delays, the timing as seen by the CPU won't match exactly what you see in the traces.

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

Re: MMU schematics WIP

Postby Steven Seagal » Sun Oct 08, 2017 12:52 pm

ijor wrote:Functionally that is correct. When GLUE asserts DE, MMU starts the video process. But because of the internal delays, the timing as seen by the CPU won't match exactly what you see in the traces.


Yes, I wasn't complete. In my vision (as in Troed's efforts for the Glue), we had something like that:

Code: Select all

Glue:

IF (POSITION==X) && (FREQUENCY==60) THEN
  DE.H = TRUE

MMU:

IF (DE) THEN
  SHIFTER_LOAD(&VIDEO_MEMORY)
  VIDEO_MEMORY+=2;


With DE=DE.V && DE.H.

Could it be the delay in GLUE? That DE is "composed" every 4 cycles for example, and not instantly? This would be easy to implement. :)

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

Re: MMU schematics WIP

Postby ijor » Sun Oct 08, 2017 2:06 pm

Steven Seagal wrote:Yes, I wasn't complete. In my vision (as in Troed's efforts for the Glue), we had something like that:

Code: Select all

Glue:

IF (POSITION==X) && (FREQUENCY==60) THEN
  DE.H = TRUE

MMU:

IF (DE) THEN
  SHIFTER_LOAD(&VIDEO_MEMORY)
  VIDEO_MEMORY+=2;



As I said, functionally the concept is correct. But if this attempts to be cycle accurate, it is not, among other things because of the internal delays.

Could it be the delay in GLUE? That DE is "composed" every 4 cycles for example, and not instantly?


There are all sort of internal delays, both in GLUE and MMU. There is also an issue of 4 cycles granularity, yes. But that's besides the delays.


Social Media

     

Return to “Hardware”

Who is online

Users browsing this forum: No registered users and 2 guests