GLUE delay times

[ppera]

As I see, GLUE chip by address decoding has relative big delay times, I assume in range about 30-50 nS.
Any info about it ? Can someone measure it with logic analyzer ? For instance delay between /AS and some ROM line activating when addressing ROM ?
P.S. STE has less delays by addr. decoding.

[Rat boy]

I analysed it, and it says GET OUT MORE, AND GET A LIFE translated from binary.

WTF do you go off on these bizarre missions? What are you trying to prove? What are you trying to do?

If you spent half your time on "NEW" concepts, then we might get somewhere...but to improve a design that is obsolete?

[nativ]

I have only got some Bluetack and a tape measure ?

Are you trying to produce a complete timing map of the St perhaps?

Are timing details available in the Atari Compenduim?

Thanks

[ppera]

Smartheads: why spamming this thread what is obviously above your knowledge and imagination ?

The reason why some need to know it: when designing some peripheral, for instance for cartridge port, GLUE delay time is important - in case of slower devices we can fast run out from some 250nS, what CPU has to fetch datas on bus.

Maybe some moderator action considering repeated rat bites ?

[CopperCAT]

As I see, GLUE chip by address decoding has relative big delay times, I assume in range about 30-50 nS.
Any info about it ? Can someone measure it with logic analyzer ? For instance delay between /AS and some ROM line activating when addressing ROM ?
P.S. STE has less delays by addr. decoding.

You might want to ask someone who's involved with an atari fpga implementation, like Wolfgang of experiment-s or the guy from fpga-arcade. They have already RTL descriptions of the GLU chip so they should know

viewtopic.php?f=15&t=13590
viewtopic.php?f=15&t=13342

[Rat boy]

Smartheads: why spamming this thread what is obviously above your knowledge and imagination ?

The reason why some need to know it: when designing some peripheral, for instance for cartridge port, GLUE delay time is important - in case of slower devices we can fast run out from some 250nS, what CPU has to fetch datas on bus.

Maybe some moderator action considering repeated rat bites ?

Yet another pointless personal attack at myself by the same person...they're adding up. Well done.

[ppera]

Yet another pointless personal attack at myself by the same person...they're adding up. Well done.

Little advice to avoid similar 'pointless personal attacks' : do not provocate. Do not post idiotic and sarcastic questions. Learn little about topic before post... etc.
Man, you are really shameless. Every second post is some stupid comment of someone's work or post, and then you complain about beeing attacked...
I will not respond on your posts more... Too bad we don't have option to ignore some people here...

[ppera]

You might want to ask someone who's involved with an atari fpga implementation, like Wolfgang of experiment-s or the guy from fpga-arcade. They have already RTL descriptions of the GLU chip so they should know

I don't think that concrete chip delay times are so relevant by designing some FPGA clone. What they need is cycle-accurate implementation. With modern, fast components delay times usually aren't problem.

[Greenious]

Ppera, have you looked at the ST analyzer traces that Mike put up at his fpgaarcade site?

http://www.fpgaarcade.com/

[cb]

Too bad we don't have option to ignore some people here...

Actually there is a 'friend & foes' option in the user panel.

[CopperCAT]

I don't think that concrete chip delay times are so relevant by designing some FPGA clone. What they need is cycle-accurate implementation. With modern, fast components delay times usually aren't problem.

That's true, but once you know the cycles, you also know the delay

[CopperCAT]

I don't think that concrete chip delay times are so relevant by designing some FPGA clone. What they need is cycle-accurate implementation. With modern, fast components delay times usually aren't problem.

That's true, but once you know the cycles, you also know the delay

Edit: now that I think of it, with all the logic so close on the fpga vs a real atari, the exact delay will be certainly less. Still, it would make a good first guess

[ijor]

I don't know the exact values, but for several reasons I wouldn't be surprised about considerable delays. You won't find any definitive answer, Atari never published datasheets for the custom chipset with that kind of info.

Measuring with a scope or a logic analyzer will only give you an estimate. The delay depends on many factors including the chip mask version, board revision, etc. Plus it is not exactly constant even on the very same hardware.

I don't think the fpga works would be useful here. An FPGA version doesn't need this level of info at all. Traces they did might be useful, but you would need a very high precision. Those traces usually target delays at the cycle level, or half cycle in the best case. And again, it wouldn't be a generic definitive answer.

You might get a clue by checking which speed-grade EPROMs Atari and third party cartridges used at the time.

I'd say that 250ns from CS to data output would probably work. But if you want to be safe, I'd try to target for 200ns.

[ppera]

I contacted Mike, he replied fast:

"Difficult to say to be honest.
All I can say for sure is the GLUE chip has a combinatorial bath between /AS
and the ROM select outputs, so it depends on the process.
The ST chips are on a very slow process by today's standards and there are
quite a few levels of logic. I think your guess is probably pretty close.
In my synchronous design I would clock them on the cpu clock, you know /AS
and ROM are going to be valid by the next clock - if you can afford the
delay.
The STE chips will be faster. Even making some measurements wouldn't really
help as you won't get worst/best case."

So, basically I was right. No real need to know exact delays - but is good to know aprox. worst case. Then we know what is max allowed (summed) delay of components what use in IF .