4MB Upgrade & 16MHz Booster progress

[exxos]

Assume the MMU is still running double speed there ?

Yes. It's Stephan's patch with the 3 74xx ICs and I'm using the 2nd FF for generating 4MHz (MFP).
This morning I switched the 520 on and got a perfect picture.
But only one time. I was watching the memtest running as suddenly the picture scrambled again.
Switching on/off a dozen times didn't change anything. Used ice-spray to cool MMU/CPU down but to no avail.
I wasn't moving anything while the memtest ran - just watched. Okay, I didn't stop breathing...

Probably clock timing issues. I have had similar problems like that before.

I will order some IC's tomorrow and see if I can do some testing here. I think first step, is what you seem to have now. Just MMU running at 32mhz input. Though will need some attention on the 8mhz & 4mhz outputs as they will become 16mhz & 8mhz. What I will do is use some F74s to down the clock speeds back to proper speeds, then the only thing running faster the the MMU. I think they are about 12ns delay so should be fine. How I understand it, that should work, but give problems with video. But should be visible enough to try the floppy loading Gembench4.

Next step would be to cut the 8mhz line to the CPU and run at 16mhz constantly. If it boots (again with problem video) I can run GB4 and see if the RAM speeds boost in speed.

Both those tests seems impossible to work with what is currently known with the current booster projects. Though its possible if the MMU runs at double speed, its possible it could solve the 16mhz CPU problem. If both those tests work, then I can work on the DE patch.

Though if I understand correctly, you just have the MMU with 32mhz input ? CPU & GLUE have default stock speeds ? If that is the case, see if you can run GB4 and see what the scores are. You can save results to file with GB4. So if you make note of the keys to press you can save the results to file instead.

[Arne]

Got it!
I compared DE-IN with DE-OUT. They were identical! That could only mean that 2MHz wasn't 2MHz but constantly Vcc. Checked it and it was at least more than 2V.
Ran QUINDEX16 and it gives me 204% for the CPU benchmarks including CPU memory. SPEDMET closes immediately after starting.
Can anyone point out a decent Screencopy program for the ST's screen resolutions?

[Arne]

GEMBench 4.03 results.

[exxos]

GEMBench 4.03 results.

AWESOME!!!! [smilie=greencolorz4_pdt_01.gif]

So what exactly do you have running there ? That must be 16mhz CPU (IE 16mhz constantly) MMU would be doubled clocked with 32mhz input, assume the F74's to downclock back to 8mhz for GLUE etc. ROM must also be running at 16mhz speeds, so you end up with a 200% across the board , that is further than I have got with my booster tests so far as I only managed to boost TOS and CPU to 16mhz so far. With RAM being boosted to double speed, 16mhz CPU and TOS really gives a boost.

So is the video just the thing to fix now then or have you sorted that ?

[Arne]

- 16MHz CPU running at 16MHz
- complete hack as described in Stephan's doc
- using the 2nd FF of the 74LS74 for generating 4MHz and feeding the MFP with this signal.
- currently c't IDE-Interface with TOS 2.06 i.e. no HDD
- 70ns PS/2 SIMM 4MB
- Glue running at stock clocks i.e. no new 2MHz/500kHz
I don't know why it wouldn't start with KAOS. Can try that later again. I don't know why ROM is accelerated. As I understand it the non-accelerated Glue asserts /DTACK for all /ROMn accesses. It probably has internal pre-calculated (by Atari engineers) wait-states.

Yes, sometimes the Atari Logo (when booting 2.06) is shifted to the right on my Multisync CRT. This is probably what I described as "bent-around-feature" on the SM124. Switch off/on (a couple times) and it's normal.

You should really trust German engineering a bit more...

[Arne]

This is the shift I was referring to:


The vertical stripes are due to the extrapolation on the TFT.



I counted the pixels and it seems to be 40 pixels (=bit) to the right.

[exxos]

- 16MHz CPU running at 16MHz
- complete hack as described in Stephan's doc
- using the 2nd FF of the 74LS74 for generating 4MHz and feeding the MFP with this signal.
- currently c't IDE-Interface with TOS 2.06 i.e. no HDD
- 70ns PS/2 SIMM 4MB
- Glue running at stock clocks i.e. no new 2MHz/500kHz
I don't know why it wouldn't start with KAOS. Can try that later again. I don't know why ROM is accelerated. As I understand it the non-accelerated Glue asserts /DTACK for all /ROMn accesses. It probably has internal pre-calculated (by Atari engineers) wait-states.

Yes, sometimes the Atari Logo (when booting 2.06) is shifted to the right on my Multisync CRT. This is probably what I described as "bent-around-feature" on the SM124. Switch off/on (a couple times) and it's normal.

I never used KAOS. Could just be bad ROMs ? Actually you have a point. If GLUE is doing the TOS decoding, then those results are actually slower than they should be. When TOS is boosted, it gets something around 20%-40% speed boost. That isn't actually happening in your case (as expected actually). If TOS is boosted, then we should see 220% to 240% speeds at least. But that is still a great start. Its probably as CPU is running faster with RAM, its reporting 200% TOS speed, but its actually still 100%. So I think those figures can be improved with faster TOS decoding (which has already been done with the current booster project).

You should really trust German engineering a bit more...

If I re-hash my booster prototype board, That has TOS decoding and 16mhz CPU. If I do the mods you have done to the MMU, and fiddle the GAL code just to run CPU 16mhz all the time, then this should be the next step. Thinking further ahead, 16mhz / 32mhz CPU switch

[exxos]

This is the shift I was referring to:

The vertical stripes are due to the extraploation on the TFT.

I counted the pixels and it seems to be 40 pixels (=bit) to the right.

hmm, does this mod work with ST-med-res ?

[Arne]

I never used KAOS. Could just be bad ROMs ?

Naahh... they run perfectly in my 1040.
Same issue with that EF68000 CPU (made by Thomson?). It wouldn't run in the 520 @ 8MHz. The Motorola P8 does @ 8MHz.
But the EF68000 runs in my 1040.

But that is still a great start. Its probably as CPU is running faster with RAM, its reporting 200% TOS speed, but its actually still 100%. So I think those figures can be improved with faster TOS decoding (which has already been done with the current booster project).

As we don't have the source code for these benchmarks...

Any idea where I can find a screencopy program that redirects Alt-Help to a file?

[Arne]

hmm, does this mod work with ST-med-res ?

Don't have a RGB CRT at hand.
But I guess so as ST start with ST-LOW HSync/VSync and the switch to ST-HIGH is done by TOS at a later time when the MFP reports /MONO_DET being low.
But surely one will see the screen-shift, too.

[exxos]

Any idea where I can find a screencopy program that redirects Alt-Help to a file?

Yes, but I am not at home right now to check what program I used. I know I got it from floppyshop cds, but a lot of them did not work. I will check when I get home later..

Do the docs for that mod mention normal resolutions work ? I think it does mention something but it does not translate very well. Though as GLUE runs at stock speeds, I would assume normal resolutions work.

I might order a binary counter to generate the clocks initially. Probably start with 64mhz osc, then it would output buffered 32,16,8,3,2mhz. May save some effort in doing the clock patches.

[Arne]

A 74F164 might be a good idea. Anyway: the 74F04 and 74LS00 seem to be necessary.

[exxos]

A 74F164 might be a good idea. Anyway: the 74F04 and 74LS00 seem to be necessary.

I think the F04 is down to delays in the clocks, so it shouldn't be needed. I will have to try it out. I was looking towards the 74LV4040, seems the fastest which I can get locally here.

[Arne]

Do the docs for that mod mention normal resolutions work ? I think it does mention something but it does not translate very well. Though as GLUE runs at stock speeds, I would assume normal resolutions work.

He mentions "add-ons" if you feed the Shifter with 64MHz (video-sequencer).
But I wouldn't spend any time on this. Better to aim for Megabus compatibility so ET4000 etc. won't stop working.

[Arne]

I think the F04 is down to delays in the clocks, so it shouldn't be needed.

The 04 is an inverter.
http://mil.ufl.edu/3701/pinouts/index.html

Forgot to mention: PullUps of address-lines are now 3K3

As I do have the Logicport at hand:
do you want recordings of certain signals?

[exxos]

I think the F04 is down to delays in the clocks, so it shouldn't be needed.

The 04 is an inverter.
http://mil.ufl.edu/3701/pinouts/index.html

Forgot to mention: PullUps of address-lines are now 3K3

As I do have the Logicport at hand:
do you want recordings of certain signals?

I did change them on my booster but later it worked with the default values, so might have to look into that again also.

It would be interesting to see what the clocks are going. Mainly the 32mhz input to the MMU , and the clocks output, plus both sides of the F04. Just to see whats going on with that inversion on the clock.

[Arne]

Here we go:
CLK32_IN: clock from the 32MHz oscillator before inversion
CLK32_OUT: 32MHz clock after inversion (this goes into MMU)
CLK16: 16MHz generated by MMU (org 8MHz)
CLK8: 8MHz generated by 74LS74
CLK2: 2MHz by Glue
DE_IN: DE generated by Glue
DE_OUT: DE generated by hack (74LS00)

Get the software to view the LPF files here: http://www.pctestinstruments.com/downloads.htm

[exxos]

Thanks. Its hard to make out whats going on there. I wonder if you can run in 8 bit instead of 32bit mode if you would get better resolution on the signals ? 32mhz does look inverted, but not really sure why that is being done yet. Possible Shifter inverts the 32mhz clock to 16mhz. So that might explain what the F04 is for.

[Arne]

Thanks. Its hard to make out whats going on there. I wonder if you can run in 8 bit instead of 32bit mode if you would get better resolution on the signals ?

Naahh don't think so. It's got 2048 sample points per channel. Leaving some out doesn't seem to add that memory to the used channels.
At least I haven't seen a setting for that option so far. It uses some kind of on-the-fly compression though.

[Arne]

Possible Shifter inverts the 32mhz clock to 16mhz. So that might explain what the F04 is for.

Seems so:



If he'd used a 74F00 for the DE stuff he could have inverted the clock with that one, too. Why using that 74F04? Hope the DE thing is not relying on the propagation delay of LS devices.
IIRC some PAK68/3 GALs rely on the propagation delay. Using faster ones crash the whole design.

[exxos]

Possible Shifter inverts the 32mhz clock to 16mhz. So that might explain what the F04 is for.

If he'd used a 74F00 for the DE stuff he could have inverted the clock with that one, too. Why using that 74F04? Hope the DE thing is not relying on the propagation delay of LS devices.
IIRC some PAK68/3 GALs rely on the propagation delay. Using faster ones crash the whole design.

That is my concern about the F04, is it acting simply as a inverter, or it uses as a delay for the clock. I will order LS and F types of chips then I can swap between them. Though It is my main concern if this project gets pushed over to GAL code as GAL speeds will vary from F or LS logic. As you can see from you scope, the 32mhz does need buffering, Though you might want to check phase relationship more from the 32mhz osc to the output of the shifter (16mhz line) to see if its inverted via the shifter or not. That is what I assume the F04 is compensating for, and assume that is the image you took already.

[Arne]

Forgot to write: I took the scope pic on a stock 1040 with IMP Shifter!
I can rework the hack so that it uses the unused 74LS00 gates if I can find and exchange it for a 74F00 or 74ALS00. Have to dig through my IC spares.

[exxos]

Forgot to write: I took the scope pic on a stock 1040 with IMP Shifter!
I can rework the hack so that it uses the unused 74LS00 gates if I can find and exchange it for a 74F00 or 74ALS00. Have to dig through my IC spares.

So far it does look like the shifter is inverting the 32mhz clock internally. So that will be why the inverter is there to go to the MMU 32mhz line. In theory the 16mhz output of the shifter, should be exactly in phase with the clock outputs of the MMU.

[Arne]

In theory the 16mhz output of the shifter, should be exactly in phase with the clock outputs of the MMU.

Can check that tomorrow. Now it's time for dinner.

[exxos]

In theory the 16mhz output of the shifter, should be exactly in phase with the clock outputs of the MMU.

Can check that tomorrow. Now it's time for dinner.

[smilie=greencolorz4_pdt_01.gif]

I just got home, so here is the file to allow saving with ALT-HELP..

SNAP.zip

Just bung it in your auto folder!