Boosting STFM: 16MHz bus, 64MHz Shifter

[troed]

So what happens is:
- At power on the reset circuit will release the RESET line
- The CPU starts executing the TOS
- One of the first commands to be executed is "RESET"
- Then the CPU will activate the RESET line in order to reset all circuits connected to this line (except the CPU itself)
- After a certain number of clock cycles (was it 64?) the CPU will release the RESET line again and will continue to execute the TOS
- BUT: Since your GAL is actually stopping the clock during reset, the CPU is got stuck with the RESET line activated (Low)
- And since there is no clock, the CPU will wait forever to finish those 64 cycles...

Thanks!! I knew there had to be something about the RESET that I overlooked

[troed]

Thanks!! I knew there had to be something about the RESET that I overlooked

A quick fix to still run the GAL, the MMU and CPU clock with RESET only affecting GLUE and MFP brings no improvement. I think it's the MMU and CPU that go into a "deadlock wakeup" on some boots. Will keep pondering.

(So yesterday before dozing off to sleep I seem to have ordered some 48MHz oscillators and GAL22V10 ... )

I do believe a DE duty cycle of XXXX..XXXX..XXXX..XXXX..XXXX for a 32MHz MMU and Shifter clocked at 48MHz would work.

Not sure why I believed I needed a 22V10, but I've got the oscillators and added support for this inbetween-mode to the GAL. One obvious thing is of course that using two different oscillators brings about some skew in the signal, or at least I think that's why there's horizontal jitter atm. Otherwise it seems to work, mostly, where I need to add the software support now. Or it doesn't work and I only think it's something I can fix in software Since I'm no longer working on four word blocks between DE going low/hi I have either gaps (medium) or lost pixels (hi) right now.

edit: Maybe it's not obvious. What I'm trying to achieve is 960*400*2, 960*200*4 and 480*200*16 ...

[troed]

So the above test was completely wrong, DE didn't get the correct duty cycle. I've rewritten the GAL once again (had to go to a truth table since it became too complicated .. ) and the simulation looks fine now. Will try to find time in the next few days to test it in the real machine (and to patch my overscan-fork to handle the new video modes).

However. The code now became too complex to support all new video modes in one GAL16/20V8 - the MMUDE output reached maximum number of product terms just supporting two out of the four. My 22V10 should arrive next week and there the number of product terms is greatly expanded ..

(Also more outputs which might simplify the truth table or even remove it completely. It wasn't easy creating the correct XXXX..XXXX..XXXX.. duty cycle since it's not a simple 2MHz AND like the "stefan" XXXX....XXXX....XXXX.... one)

I've also thought about the skew using different oscillators. Modern clock generators are not something I've studied, but to generate both a 64 and a 48MHz in sync it seems you'd need a 192MHz source clock that's then taken every 3rd and 4th pulse respectively from, or something. Not sure about pulse length.

[exxos]

So are you running the shifter on 96Mhz to get the MMU at 48MHz ? Or just running the MMU at 48Mhz on its own clock ?

Did you get anywhere with the shifter overheating in mono mode ?

[troed]

So are you running the shifter on 96Mhz to get the MMU at 48MHz ? Or just running the MMU at 48Mhz on its own clock ?

Did you get anywhere with the shifter overheating in mono mode ?

MMU at 32MHz, Shifter at 48MHz, pulsing DE at a 4/6 duty cycle which will cause them to get back in sync. However, since there are two physically different oscillators I get some visible skew (at least on the one test I've done so far).

Shifter overheating is still at heatsink + increased voltage. I think next up to socket the Shifter making it easier for me to test with more chips and then maybe test the power regulator idea you had from 12V.

Of course, one of the reasons for my 48MHz Shifter tests is that it should not have those issues And 960x400, 960x200 and 480x200 are still really nice resolutions. All of these can of course be extended with "regular" border-removing overscan as well since I control DE fully.

[exxos]

Did I suggest linking the blitter clock to the CPU one ? In effect running the blitter at 16mhz... I mean with 16mhz access to ram you should get a 200% boost on blitting power...

[troed]

Did I suggest linking the blitter clock to the CPU one ? In effect running the blitter at 16mhz... I mean with 16mhz access to ram you should get a 200% boost on blitting power...

Yeah I have a socket and a blitter ready but haven't installed it yet Am a bit sidetracked making mods to a 520STM atm.

However, I've spent some more time on the 32/48MHz stuff. I need to study the signals with the LA, but it's not looking good, as in, it seems the timing doesn't work out as nicely as I thought. I have really weird Shifter effects. I'll probably await the 22V10 which will give me a bit simpler GAL code to work with I think, but it's possible it just doesn't work.

[troed]

(I never got the 48MHz thing to work, MMU-Shifter doesn't seem to like to run on non-4 word aligned modes)

However, you probably have read about Czietz' software discovery where he figured out how to run the GLUE and Shifter in separate videomodes. For example, GLUE believing it's in high res (71Hz, 224 cycle scanlines) but the Shifter decoding data in color.

Combining that sw trick with the doubleST video modes gives us the following new options:

640x200x16 becomes 320x400x16
1280x200x4 becomes 640x400x4
(and 1280x400x2 becomes 2560x200x2 ... uhm )

As you can see, those are some very attractive modes. I've just enabled them in my patched Overscan1.6 on my modified 16MHz "doubleST":

doublest_czietz2_s.JPG (179.42 KiB) Viewed 7548 times

doublest_czietz_s.JPG (139.41 KiB) Viewed 7548 times

As you can see, this is basically the normal ST high resolution mode, but in glorious color Also, since these are in ST high timing you don't need a 15KHz capable flatscreen to see them. Any VGA-capable monitor will do.

[exxos]

Now just need 256 colour version

[Cyprian]

awesome,

I see that fonts are 8x8 instead of 8x16 and gadgets are a bit too wide.
Maybe something else should be patched in that patched Overscan1.6,