Shifter/MMU/GLUE timings

[stefanberndtsson]

@larsbrinkhoff

From what I've been able to figure out, this seem to be a reasonable approach (GLUE line cycles):

 56c GLUE sets DE
 62c MMU sets LOAD
 62c Shifter loads IR1
 66c MMU sets LOAD
 66c Shifter loads IR2
 70c MMU sets LOAD
 70c Shifter loads IR3
 74c MMU sets LOAD
 74c Shifter loads IR4
 76c Shifter has copied IR1-4 into RR1-4 and shifted out the first pixel
 78c MMU sets LOAD
 78c Shifter loads IR1
 ...
 92c Shifter loads IR4
 92c Shifter has copied IR1-4 into RR1-4 and shifted out the 17th pixel
 ...
364c Shifter has copied IR1-4 into RR1-4 and shifted out the 289th pixel
366c LOAD IR1
370c LOAD IR2
374c LOAD IR3
376c GLUE kills DE
378c LOAD IR4 (nothing more is loaded now)
380c Copied IR1-4 into RR1-4 and shifted out 305th pixel
395c 320th pixel shifted out

Of course, with removed borders, things will be different, but as the normal case, could this work?

[larsbrinkhoff]

Yes. I guess internal states such as loading IR or RR could move around a bit, as long as the delay from DE to LOAD, and from LOAD to first pixel is the same. E.g. it might be the case that the shifter loads IR one cycle after seeing LOAD, and RR one cycle after having loaded IR4. Maybe no one knows. But it shouldn't matter.

Also, if you take wakestates into account, the DE-to-LOAD delay could be anything from 3 to 6 cycles.

[larsbrinkhoff]

I'm not sure whether it's more correct to say that the MMU sets LOAD once and keeps it active, or whether there are multiple events as per your description.

[stefanberndtsson]

Multiple. The data bus is the same for both memory access from CPU and shifter loading, and they're interleaved, so it has to be multiple.

[larsbrinkhoff]

I'm not sure it's exactly the same bus. There's a buffer or bridge or something between the main bus and the MMU internal memory bus, to which the shiftter is connected.

But maybe you do know. I just haven't checked in detail. But now I'm gonna.

[stefanberndtsson]

It's the same bus. The buffer/latches are to isolate the cpu from the mmu, not the mmu from the memory.

And please do not emulate wakestates. Pick one :)

[larsbrinkhoff]

The buffer isolates the CPU (and other devices) on one side, and MMU and RAM and shifter on the other, right?

[larsbrinkhoff]

Do you have something against wakestates?

[stefanberndtsson]

Yes, the MMU is still responsible for accessing the actual RAM (not the ROM), and stores it in/reads it from the buffer/latch area, so half the time MMU reads from RAM for the CPU and half the time for the shifter (and does refresh of RAM when shifter does not need it).

As for wakestates, there is no point in introducing a semi-undeterministic (lovely word) model in something that by definition will be deterministic.

[larsbrinkhoff]

What you describe is what I had in mind. I still don't see why this would necessitate LOAD being continuously toggled when DE is active. In my mind, LOAD could be kept active as a signal to the shifter to keep fetching data. Of course, it would only look at LOAD every four cycles.

But I'm not a hardware expert, so I'm happy to learn more!

[stefanberndtsson]

Shifter does not care about anything regarding "four cycles". Shifter loads when LOAD-signal goes active (not when it is active). MMU dictates completely when Shifter will load new data. DE on the other hand is a signal telling things to remain active.

So DE tells MMU that it can tell shifter to load, hence it's active the whole time. LOAD tells Shifter that it should load, hence it serves no purpose keeping it active once load has been performed.

DE then also tells Shifter that it should move IRx to RRx (something shifter "decides" on its own when to do).

Was that understandable at all? :)

[larsbrinkhoff]

It's understandable, I just don't see that's the only way it could work.

The shifter is a clocked device, right? How do you know it doesn't have some internal state that tells it to load from the bus every four cycles if LOAD is active?

[troed]

@stefanberndtsson GLUE-CPU wakestates are completely deterministic :) I'd suggest a default option of "random" wakestate (which is the accurate way to emulate an ST) and the possibility to force it to one of the four.

TCB SNYD1 "TV-snow screen" should have a disting logo that's only centered in WS2 and offset to the left in the other three.

I would also, but I haven't finished documenting how it works yet, suggest emulating "Spectrum 512 black pixels" etc (MMU-Shifter wakestates, I think)

[larsbrinkhoff]

@troed The following is my current understanding. Please correct me if I'm wrong!

The CPU and the MMU are synchronized and usually in phase with each other. Due to frequent RAM accesses from the CPU which the MMU controls.

The CPU and the GLUE are synchronized to the same 8 MHz clock, but need not be in the same phase. Since timing is viewed with respect to bus accesses, which takes four clock cycles, there are four possible phase shifts.

So, in our current simulator model (which is not fully there yet), all that it would take to get different wake states is to set the initial GLUE clock to one of 0, 1, 2, or 3. That's hardly a big complication.

I have no idea what the shifter wakestates are abort.

[troed]

@larsbrinkhoff Yes. An offset of 0-3 cycles between GLUE and CPU - and also make sure that the GLUE "picks up" writes to ff8260 one cycle later than writes to ff820a.

[stefanberndtsson]

Regarding the shifter and load. Sure it's not technically the only way it could work, but it's the way it does work. :)

http://www.atari-forum.com/viewtopic.php?f=16&t=24855&start=363

See the second image there, you can see LOAD being pulsed while DE is kept active.

[larsbrinkhoff]

Thanks @stefanberndtsson, that's exactly the kind of detailed information I would like to get about the components. Case closed. (But not this issue.)

[larsbrinkhoff]

I would also, but I haven't finished documenting how it works yet, suggest emulating "Spectrum 512 black pixels" etc (MMU-Shifter wakestates, I think)

@troed I hope that this would fall out naturally from a faithful simulation of the hardware. I have now updated the MMU and verified that that, indeed, there is a variable 3-6 cycle delay between DE and LOAD which depends on the initial state of the GLUE clock. Without any special treatment for wakestates.

Secondly, please finish documenting that! I know it would probably be done quicker if you weren't pestered with questions. ;-)

[larsbrinkhoff]

It's now possible to set the GLUE wakestate with the WS environment variable. It can be set to any integer, but of course only the 0-3 range is interesting. (Or is it...?... )

[larsbrinkhoff]

I have now verified the timings. There are 3-6 cycles from DE to LOAD, and 18 cycles from LOAD to pixel.