How does Gembench asses Rom speed?

[guus.assmann]

Hello,

Think this is a simple question for Exxos.
How exactly does GB get the rom speed.
What does it compare against?

BR/
Guus

[exxos]

Its just reads the ROM area into the CPU registers... Comparison is done against whatever benchmark file you load..

[guus.assmann]

Thanks for the reply.
And yes, I know that there's not nearly any acurate measurement of speed for Rom -access
My reason for asking is, that I don't understand why something I've tried to do doesn't seem to work.
What I've done:
Take 2 diodes and connect the cathodes together and to the CS-line of the TT OS-Roms.
The anode goes to /DSACK0 and /DSACK1.
When not connected, Gembench gives 100% speed for Rom. (Reference TT)
And connected it gives 130%. Not Acurate, I know. But it's a positive difference.

Next, I make a GAL 20V8 (7ns, 15ns, 25ns, all 3 speed grades) and decoded address $00E00000-$00E7FFFF and $00E80000-$00EFFFFF. This should be where Tos lives.
Either address then generated the both /DSACK signals.
It has no effect on the speed indication. And I expected that it would.
So maybe I don't decode the correct address?
I did make sure that the GAL works. I put it in a breadbord and connected LED's to the outputs and set all input conditions with wires.
And this behaves exactly as I expect. Also, the computer boots when I connect the GAL.
I connected all wires on top of the ST-Ram-card, that's where all address lines and DSack and AS is available.

What I did learn from this:
1) Atmel WinCuPL is a terrible programm that gives wrong error codes if I make a mistake in syntacs. (# versus + and & versus * )
2) Making a PALCE22V10 to work has wasted a lot of time. (I did it because of the low power consumption and because I have them)
3) Not all output pins of a Gal20V8 can be used as input, pin 15 is a no-go.
4) An Atari program (Jedi) also behaves different that I expect if I try to feedback pin 15. (No Gal mode selected...)
5) I finally figured out how to get a Gal-out to Tri-state with both Jedi and WinCupl.
6) I find removing any IC or replacing one much easier than trying to get a GAL to work. But it should be much easier.

All in all, it's not a total waste of time. But it annoyes me I can't get the GAL to work.
So any advice is welcome.

[exxos]

Why are you over complicating a simple mod in the first place ?

Are you sure the address bus for the RAM is the same address bus as the CPU ?

[guus.assmann]

Hello Exxos,

Seems that way, doesn't it?

For one, I want to be able to switch between the both modes.
But the Chip-select signal on a switch, with wires, doesn't seem such a good idea.
So I think a GAL will do the switching better.

Second, because I learn a lot from this.
There may be another application as well.

And it's also proof of concept if I ever want to connect something else in the memory map.

Is it the same buss?
Good question.
It should be, if I read the schematics correctly. But I'll do some measuring this evening.

Another thing is, I expect to be able to gain some more speed.
In the working situation, the (slow) MCU generates the Chip-select for the ROM.
A Gal could be a little faster.
My Flash-roms are 90nS and the OTP-Eproms 45nS 27C010 or 55nS 27C020
So there may be a couple of % speed there. Still at very low cost and efford.

BR/
Guus

[exxos]

I understand your idea. I did almost try similar on a MSTE, but editing the MSTE GAL.. but I think the code online was bugged to start with so I gave up.

But also note that speeding up ROM access also needs CPU to keep up. If CPU runs at 16MHz then ROM access can never be faster than 125ns regardless of how fast you decode ROM.

Typically ROM decoding may take 20ns for example, CPU will start to latch data at 125ns... So ROM speed itself must be 125-20ns = 105ns. It means 100ns ROM IC must be used. But of course, using a GAL for 7ns decoding, 55ns ROM, CPU will still access ROM at 125ns...

I assume DTACK control is bad for the ROM logic, which is why the diode mod works. I think it was @frank.lukas who mention the same mod some months ago. I think it was the MSTE control of DTACK and ROM I tried to patch to solve the problem.

[guus.assmann]

On the Mega STE I've not tested with the diodes yet.
I only have 1 working Mega STE . But I'll do that test as well.
Should help a bit, the circuits around the CPU look similar to those on the TT.
My TT's have 32Mhz and a copy of the OS to fast ram has a lot of speed increase as well. It's not reset proof. (I have 3 working TT's to test with)

I also tested with diodes in the circuit around the 74F74, next to the CPU
But that's very tricky and is not reliable.
In fact, using any other than the 74F74 crashes the system. In theory, 74ALS74 should have worked, as should 74S74. 74HCT74 is also no good.

The diode mod on the TT, I posted that on a German site.
And we had some discussion there on the question of GB giving a correct picture of actual processing speed.
It was agreed that it doesn't. (in a scientific sense, as there's many variables)
But GB does offer some means of comparison, like before and after a mod to the same machine.

DTack on the TT, when Rom's are accessed, has a wait state. Hence 150nS Roms are sufficient for the TT.

[guus.assmann]

Had some time yesterday evening.
So I took the schematics and checked the TT-Ram connector against the ST-Ram connector.
And I measured all address lines.
A1 to A31 are the same bus.
While writing this, I realize I might have also tested the Eprom address lines. (Must be the same anyway, schematis confirm this)
Next will be to double check (again and ....) if all connections to my Gal are correct.

I know for sure the /DTACK0 and /DTACK1 are correct. The diode patch still works.
I see this by comparing my TT with the exact same settings, once with the diodes and once without.

BR/
Guus