4MB Upgrade & 16MHz Booster progress

[exxos]

I just thought a binary counter won't work to replace the clocks as one is inverted.

What I plan on doing is, buffering the 32mhz clock first of all, then inverting it for the MMU input. So that means lifting the 16mhz output of the shifter and replacing that line with the new inverted 32mhz clock. That should match what you have.

Then the 4mhz output of the MMU will have to be cut, I am assuming here that the only thing on the 4mhz line is the MFP. So I will probably lift that pin on the MFP itself and feed that via a flip flop to downclock it back to 4mhz.

I have ordered some 2mhz ACIA's, though not arrived yet Possible the one on the board will overclock, but even so, I should still be able to get to desktop even if those go a bit wonky (I hope).

The last mod will be the DE mod. There it looks like a track cut needed to the MMU and as you pointed out, it must be pin 54 not 52. So we feed in the GLUE 2mhz clock.

I have a ST *somewhere* with a 4MB simm adapter all ready to go. So Hopefully in a few days I can have this mod built so I can do some testing If all goes well, I will work on adding Fast-TOS to it aswell. Then we should be able to push way past those 200% figures

Incidentally, my Lattice programmer has come, so "at some point" I will program my clock sync circuit to see if I can get out of sync clocks working to try any mhz speeds. Though this is a lot of work so will take some weeks to complete overall.

[Arne]

Some benchmarks:







All done with TOS 2.06 (German), not Auto-Folder/ACCs. Same setup as the GEMBench4 results I posted earlier.

@exxos: you take the /AS line away from Glue and do the /DTACK by GAL? Then please take care that you do not change the timing for /ROM3 and /ROM4. Otherwise old cartridge ROMs may not work anymore. I guess these are mostly +200ns EPROMs. My testkit uses 100 or 120ns, so that's probably no problem.

[exxos]

Some benchmarks:

All done with TOS 2.06 (German), not Auto-Folder/ACCs. Same setup as the GEMBench4 results I posted earlier.

@exxos: you take the /AS line away from Glue and do the /DTACK by GAL? Then please take care that you do not change the timing for /ROM3 and /ROM4. Otherwise old cartridge ROMs may not work anymore. I guess these are mostly +200ns EPROMs. My testkit uses 100 or 120ns, so that's probably no problem.

GLUE is only isolated on TOS ROM range nothing more. Any other address ranges GLUE will decode as normal

I am still amazed that mod works at all. A lot of people on here were trying to figure out why the CPU wouldn't run at 16mhz all the time. As the only difference is RAM access at 16mhz, then that must be the problem. Some odd clash between the CPU at 16mhz and MMU at stock speeds. As to what is till unclear, but the solution is in sight now

I will defiantly order those IC's tomorrow, so they will come tuesday, Might be thursday before I get chance to work on it. Hopefully I can replicate your results without too much going wrong. thanks of course go to you for pointing that document out and getting your ST fixed so quickly Speeding up the ram has been the bottleneck for the booster work I have done so far. So if I can mash the RAM mod with the current CPU booster project, then that booster will seriously kick-ass

[rpineau]

We have some free pins on the ATF1504 that we wired to the expansion connector so once the whole 16MHZ MMU / DE stuff has been figured out we should be able to add it to the CPLD and run the needed wire to the STF board. As we can use buried node we can do a lot of it inside the CPLD without losing any pins besides the actual input and output.
Rodolphe

[exxos]

We have some free pins on the ATF1504 that we wired to the expansion connector so once the whole 16MHZ MMU / DE stuff has been figured out we should be able to add it to the CPLD and run the needed wire to the STF board. As we can use buried node we can do a lot of it inside the CPLD without losing any pins besides the actual input and output.
Rodolphe

Yes, looking at this new RAM project, I think we made a good choice to move to larger device Once I have this working in logic you can expect a email to program it into a GAL to test

[Arne]

Memtest:



I will have a look at the Overscan doc Steven mentioned earlier. Perhaps I get a clue what the reason for the screen shift is.
Just put an IMP Shifter in and it's worse. Now and then I get vertical 16bit wide bars on the screen. Looks like a jail window.
I just pulled out Pin39 (CLK16_OUT) from the socket. This was done before with the Non-IMP-Shifter, too. But it was pulled to GND with 1K Ohms. This might work with IMP, too. Too lazy to spend more time on IMP stuff...

[exxos]

Memtest:

I will have a look at the Overscan doc Steven mentioned earlier. Perhaps I get a clue what the reason for the screen shift is.
Just put an IMP Shifter in and it's worse. Now and then I get vertical 16bit wide bars on the screen. Looks like a jail window.
I just pulled out Pin39 (CLK16_OUT) from the socket. This was done before with the Non-IMP-Shifter, too. But it was pulled to GND with 1K Ohms. This might work with IMP, too. Too lazy to spend more time on IMP stuff...

That DE mod might need another gate to AND the Reset line to it. So it ignores the DE pulses during reset. Also assume you have some ceramic caps 220nF or more across the supply rail pins of your logic chips ? You could try tweaking the reset time like it suggests in that doc. Letting the ST reset quicker/sooner with a lower resistor value might help with the problem.

[Arne]

That DE mod might need another gate to AND the Reset line to it. So it ignores the DE pulses during reset.

Can do.

Also assume you have some ceramic caps 220nF or more across the supply rail pins of your logic chips ?

Only one for all three I have to admit.

You could try tweaking the reset time like it suggests in that doc. Letting the ST reset quicker/sooner with a lower resistor value might help with the problem.

That's already done with 560 Ohms.

[joska]

Extremely interesting thread! I will probably attempt to do this mod on my Mega ST just to see if it works with it's graphics card.

[exxos]

That's already done with 560 Ohms.

In that case, try putting the default value back and see if that changes anything ?

[exxos]

Extremely interesting thread! I will probably attempt to do this mod on my Mega ST just to see if it works with it's graphics card.

That would be awesome if more people tried this mod on more machines

[Arne]

In that case, try putting the default value back and see if that changes anything ?

No change.

I tried this (instead of the 74LS00):

Code: Select all

                          /RESET
                             |   __
                     __      +--|  \
    DE (Glue) ------|  \        |   )--- DE (MMU)
                    |   )-------|__/
         CLK2 ------|__/

                        1/2 74F08

No change.

[exxos]

Probably will have to look at the problem here once I get mine working. I would put the reset circuit back to default and see if that does it. If not, it looks like it could be a pain to solve

[Arne]

PullUp on /RESET is back to 1K and screen is still shifted sometimes.

What I don't understand in regards to Glue:
It has to blend $FC0000..$FC0007 to $00..$07 when the /RESET line switches to Vcc.
And this should not depend on the TOS ROMs being present or not.
Regardless if they are present or not Glue shall pull /DTACK low and after a given number of 8MHz clock release it (due to open-collector output).
But I don't see any activity on /ROM2 (which is the /OE of the TOS ROMs) when no ROMs are present.

[joska]

Demo coders talk about different "start up states" that's messing with their overscan- and synscroll-routines. These routines are manipulating the DE signal indirectly by confusing the GLUE. Could it be something similar that's causing your problem?

[Cyprian]

Extremely interesting thread! I will probably attempt to do this mod on my Mega ST just to see if it works with it's graphics card.

That would be awesome if more people tried this mod on more machines

I'd also try this mod and I have a spare short 520 ST.

actually this part is also very interested:

Small progress.
I removed the 6 EPROM KAOS and put in another TOS 2.06/IDE card (DIY project from German magazine c't).
With the P16 CPU and 16MHz and with the Motorola P8 CPU at 8MHz I get this picture:

With a EF68000P8 (stamp on top is "8547 8" so I guess it's manufactured 47th week of 1985) I don't get a picture at all,
but this CPU runs in my 1040.

doubled shifter means 640x200 in 16 colors or 1280x200 in 4 colors

[exxos]

PullUp on /RESET is back to 1K and screen is still shifted sometimes.

What I don't understand in regards to Glue:
It has to blend $FC0000..$FC0007 to $00..$07 when the /RESET line switches to Vcc.
And this should not depend on the TOS ROMs being present or not.
Regardless if they are present or not Glue shall pull /DTACK low and after a given number of 8MHz clock release it (due to open-collector output).
But I don't see any activity on /ROM2 (which is the /OE of the TOS ROMs) when no ROMs are present.

Maybe there should be a auto folder program to reset the video counters after power on ?

There isn't much going on with the DE line, its more like a delay line type thing, so the shifter could only really be a block of what, 16 pixels out each count ? If you see about 40, then thats 16+16=32 or +16 48 pixels. Which means DE is being pulsed 3 times when it isn't supposed to be.

Out of interest, why not try that RESET pin on your AND gate, put a switch on it, pull down resitor 1K to 0v, and switch it HI manually after turn on and see what happens then ?

[Arne]

Don't you think that switch will bounce disturbing more than curing?

[exxos]

Don't you think that switch will bounce disturbing more than curing?

No clue, but can't think think of anything else to try currently. I was just trying to think of a way to make things worse to see if DE was directly related to the problem or not.

[exxos]

I been thinking about this a little more. Could you try swapping that inverter out for a buffer to see what happens ?

My original idea for speeding RAM was to switch the MMU into double speed only when CPU is talking to MMU, or MMU is talking to RAM. This way that DE mod probably wouldn't be needed and would probably cure the screen problems. I could do with you putting your logic sniffer on the /RAM pin on the MMU, and the DE pin on the MMU and GLUE.. My idea was to use /RAM pin as a switch to select normal or double clock speeds.

Really its just a matter of finding some signals so that when MMU is talking to shifter, it must switch back to 16mhz input to the MMU. So far we should assume that when GLUE set DE HI, that MMU must run in 16mhz input. Maybe even monitor DE on GLUE. We just need to know some way to determine what MMU is talking to . If it shifter, we should switch back to 16mhz MMU input. If its talking to CPU or RAM itself, then we switch to 32mhz MMU input. This way, everything shifter related works at stock speeds.

[troed]

Demo coders talk about different "start up states" that's messing with their overscan- and synscroll-routines. These routines are manipulating the DE signal indirectly by confusing the GLUE. Could it be something similar that's causing your problem?

The every-other 16 pixels showing background color instead of graphics is indeed a Shifter state that's possible to reach by manipulation of the internal registers in the Shifter vs what's expected by the MMU. Basically any changes as to how much data the Shifter has been able to shift out when the MMU signals LOAD can end up in that.

The GLUE wakeup states are something else and I don't think they are influencing anything here from what I've read so far.

/demo coder

[Arne]

I been thinking about this a little more. Could you try swapping that inverter out for a buffer to see what happens ?

Had a look at my IC spare box: no 74F07.

[exxos]

I been thinking about this a little more. Could you try swapping that inverter out for a buffer to see what happens ?

Had a look at my IC spare box: no 74F07.

You could try linking it out, feed MMU direct from osc 32mhz. Though it might kill the 32mhz as it isn't very "strong", but I think it does work.. just..

[SteveBagley]

Really its just a matter of finding some signals so that when MMU is talking to shifter, it must switch back to 16mhz input to the MMU. So far we should assume that when GLUE set DE HI, that MMU must run in 16mhz input. Maybe even monitor DE on GLUE. We just need to know some way to determine what MMU is talking to . If it shifter, we should switch back to 16mhz MMU input. If its talking to CPU or RAM itself, then we switch to 32mhz MMU input. This way, everything shifter related works at stock speeds.

I'm not sure how viable this would be.

Remember the MMU doesn't really talk to the shifter separately from RAM -- it generates the address on the MADDR lines but the shifter picks the data up directly from the MDATA lines (in the STE the processor even talks to the RAMS through the shifter, at least on the non-STE machines the buffers are external) -- it's why most RAM upgrades resocket the shifter, all the data lines are in easily accessible place.

Also, I'm not sure slowing the MMU bus to 16MHz during shifter RAM reads would help with the display since they would still happen too frequently, without stopping DE. Normally, the MMU rigidily splits access between the CPU and shifter (although usually in a way that hides most of the Shifter inside the CPUs thinking time). I can't remember the exact time but let's say each get 4 cycles at 16MHz. This gives the following pattern:

0C 4S 8C 12s 16C 20S 24C

If we switch the MMU to 32MHz during CPU acces, it's the same as reducing the cycle count to 2 for the CPU so you get:

0C 2S 6C 8S 12C 14S 18C 20S 24C

By 24 16MHz cycles, you've gained a complete extra shifter cycle which would again give a different display pattern.

Steve

[exxos]

Also, I'm not sure slowing the MMU bus to 16MHz during shifter RAM reads would help with the display since they would still happen too frequently, without stopping DE. Normally, the MMU rigidily splits access between the CPU and shifter (although usually in a way that hides most of the Shifter inside the CPUs thinking time). I can't remember the exact time but let's say each get 4 cycles at 16MHz. This gives the following pattern:

But if the MMU is slowed to default speeds, thats the "stock ST" so can't see it would still effect DE in anyway ? GLUE is running at stock speed. So if MMU is downclocked back to default 16mhz input, then there is no need to mess with DE surely as its all running at stock speeds again.

My initial thought is to just tie DE to the 16mhz/32mhz switch. So when GLUE wants to increase the counters in the MMU, it does it all back at default speeds. There might be other issues with clocking the MMU at double speed while loading the shifter registers, but that can probably be downclocked aswell. I don't see a problem with the shifter registers being loaded twice as fast ?

Whatever resets the counters in the MMU can't be working correctly as arne sees some 40pixel shift problem. I am assuming also its those counters causing the problem.