Help to compile a source file

[beel1]

The software reads the video address at $ffff8207 and $ffff8209 ("d2d3"), performs magic tricks, then reads the registers again ("d4d5") and substracts them to get the result
I will display all intermediate values in a single program tomorrow hopefully

[beel1]

OK it's past midnight, here it is

[exxos]

OK it's past midnight, here it is

Yeah almost 1am

Thanks.

Some new results to ponder...

I still mostly get WS?,WS1,WS2. mostly not WS2 much at all.

IMG_4902.JPG (49.63 KiB) Viewed 5139 times

IMG_4903.JPG (56.94 KiB) Viewed 5139 times

[beel1]

Here is the source code: https://github.com/beel1/WSDETECT/blob/ ... WSDETECT.S

[czietz]

How about tackling this issue from a pure HW perspective, for a change? Another way to determine the wake state is measuring the delay between DE getting high and the first pulse on LOAD. The attached scope shots show examples for WS1 (750 ns, 6 cycles) and WS4 (500 ns, 4 cycles). See http://www.atari-wiki.com/index.php/ST_ ... _Wakestate for the full mapping. Another thing to compare between your MMU reimplementation and an original MMU is the timing between DE being deasserted and the last LOAD pulse.

After you got both of these things sorted out for normal operation at every power-up, you can still check whether additional fixes are needed for the special timings on DE that Troed's WSDETECT program creates.

DS1Z_QuickPrint2.png (29.81 KiB) Viewed 5099 times

DS1Z_QuickPrint1.png (30.82 KiB) Viewed 5099 times

[exxos]

Thanks, see I don't know whats going on with hardware either.. but now I know about phase between DE & LOAD I can scope that out. The cycle delay per WS doesn't make sense as its not in order? In effect I probably have WS?,WS0, WS1,WS2. So if the cycle delay is 3,4,5,6, then I either have 1,2 cycles, or 7,8 cycles.. eitherway suska is "outside" what is documented, other than it mostly going into WS1 and sometimes WS2. But I dont see how it ends up jumping from 3 cycles (WS1) to 6 cycles (WS2). But also cycles of what 8MHz clock ? 16MHz clock ? 2MHz clock ?

Looking at the results (0x80A0) there doesn't seem to be any delay (or difference) in the numbers.. If @Icky is back home, maybe you can measure the timing difference ? I would assume the cycle delay is zero. If so I may route the GLUE to MMU signals via a GAL to slow them down to the FPGA to simulate the timings you posted.

[czietz]

The important thing is that with an original MCU in the ST you can only ever have 3, 4, 5 or 6 cycles (@ 8 MHz clock = 125 ns) delay between DE and LOAD. Yes, the mapping of delay to the numbers WSn of the wake states is not logical, but it's like it is. In the end, the WSn designators are only arbitrary names; Troed could have numbered/called them however he wanted.

[exxos]

I wonder if 500ns delay is down to ram setup time. Data has to be valid to load the shifter. So there would need to be a delay. Though with no reset on the MMU , a flipflop delay chain could be easily half , 250ns. So it would need more flip flops to help combat a delay which is to short.

Yeah I know ram is more like 120ns but the logic in the MMU and much older slower ram might have just lead to a typical 500ns figure. But be because those flip flops can't be reset, Atari might have just doubled the amount of them which means there will be different load times to the shifter. Ordinarily it probably wouldn't have mattered if the load time was delayed ( more than 500ns)

Even so, based on flip flops, load to the shifter would glitch until ( assuming ) DE is clocked directly into the delay chain. Unless Atari ANDed every flipflop to combat that issue that is..

I'm just thinking out load trying to understand this random wakeup time...

EDIT:

I guess they could have used DE to reset the flip flops, unless it used more gates in the chip and they were really trying to keep things down..but even so, having a reset on 2 flip flops and having a fixed delay would just make more sense I think if that was the case.

EDIT2:

Also possible that since the GLUE is basically out of sync with the MMU regarding DE.. The shifter load could just be simply held off because the MMU is doing ram refresh cycles or something and it has to wait. So there could be a fixed 2 clock delay on load, plus the delay of finishing ram refresh or something.

[stephen_usher]

It's probably more due to a (mathematically) chaotic behaviour of a feedback in the system within the chip. The final state being determined by which specific transistors etc. came on-line first.

This would be similar to many (all?) modern processors which, depending upon the initial internal power-up sequence, can vary in speed by up to a few percent from power cycle to power cycle.

[czietz]

MMU loads data into the Shifter every 4 cycles (= 500 ns). There's no mechanism to synchronize Glue to the MMU's internal cycles.¹ Therefore, there are four different possible timings of Glue-generated signals (such as DE) in relation to the MMU-generated signals (such as LOAD). Troed et al. explained it really well, please go look up their work if you're interested in more details.

Footnote 1: The CPU on the other hand is synchronized to the MMU's cycles as soon as it accesses RAM.