GLUE delay times

Troubles with your machine? Just want to speak about the latest improvements? This is the place!

Moderators: Mug UK, Zorro 2, spiny, Greenious, Moderator Team

ppera

GLUE delay times

Postby ppera » Sat Jun 14, 2008 10:02 am

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
Captain Atari
Captain Atari
Posts: 175
Joined: Thu Mar 13, 2008 3:29 am

Re: GLUE delay times

Postby Rat boy » Sun Jun 15, 2008 3:13 am

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?

User avatar
nativ
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 4089
Joined: Mon Jul 30, 2007 10:26 am
Location: South West, UK

Re: GLUE delay times

Postby nativ » Sun Jun 15, 2008 8:59 am

:lol: 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
Atari STFM 512 / STe 4MB / Mega ST+DSP / Falcon 4MB 16Mhz 68882 - DVD/CDRW/ZIP/DAT - FDI / Jaguar / Lynx 1&2 / 7800 / 2600 / XE 130+SD Card // Sega Dreamcast / Mega2+CD2 // Apple G4

http://soundcloud.com/nativ ~ http://soundcloud.com/nativ-1 ~ http://soundcloud.com/knot_music
http://soundcloud.com/push-sounds ~ http://soundcloud.com/push-records

ppera

Re: GLUE delay times

Postby ppera » Sun Jun 15, 2008 1:40 pm

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 ? :mrgreen:

CopperCAT
Atari freak
Atari freak
Posts: 71
Joined: Wed May 31, 2006 9:54 pm
Location: Belgium

Re: GLUE delay times

Postby CopperCAT » Sun Jun 15, 2008 1:50 pm

ppera wrote: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
Captain Atari
Captain Atari
Posts: 175
Joined: Thu Mar 13, 2008 3:29 am

Re: GLUE delay times

Postby Rat boy » Mon Jun 16, 2008 12:08 am

ppera wrote: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 ? :mrgreen:


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

ppera

Re: GLUE delay times

Postby ppera » Mon Jun 16, 2008 9:20 am

Rat boy wrote: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

Re: GLUE delay times

Postby ppera » Mon Jun 16, 2008 9:23 am

CopperCAT wrote: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.

User avatar
Greenious
Hardware Guru
Hardware Guru
Posts: 1205
Joined: Sat Apr 24, 2004 5:39 pm
Location: Sweden

Re: GLUE delay times

Postby Greenious » Mon Jun 16, 2008 9:29 am

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

http://www.fpgaarcade.com/
Updated my guides as of june 28th, 2016. Check'em out and feedback!
viewtopic.php?t=5040

User avatar
cb
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3048
Joined: Sat Apr 27, 2002 7:03 pm
Location: somewhere in time

Re: GLUE delay times

Postby cb » Mon Jun 16, 2008 10:55 am

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


Actually there is a 'friend & foes' option in the user panel.
AL-FGC
Heghlu'meH QaQ jajvam!
Image

CopperCAT
Atari freak
Atari freak
Posts: 71
Joined: Wed May 31, 2006 9:54 pm
Location: Belgium

Re: GLUE delay times

Postby CopperCAT » Mon Jun 16, 2008 12:20 pm

ppera wrote: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
Atari freak
Atari freak
Posts: 71
Joined: Wed May 31, 2006 9:54 pm
Location: Belgium

Re: GLUE delay times

Postby CopperCAT » Mon Jun 16, 2008 12:25 pm

CopperCAT wrote:
ppera wrote: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
Hardware Guru
Hardware Guru
Posts: 3419
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: GLUE delay times

Postby ijor » Mon Jun 16, 2008 8:12 pm

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

Re: GLUE delay times

Postby ppera » Tue Jun 17, 2008 8:59 am

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 .


Social Media

     

Return to “Hardware”

Who is online

Users browsing this forum: No registered users and 8 guests