REMINDER - Stay logged in for at least 2 hours a week to get whitelisted.
Also it helps build a picture where our "good traffic" is coming from for detection scripts.
:o)
Also it helps build a picture where our "good traffic" is coming from for detection scripts.
:o)
Wanted: an old SILOS primitive library (pri150ww.lib)
-
exxos
- Site Admin

- Posts: 28619
- Joined: 16 Aug 2017 23:19
- Location: UK
Re: Wanted: an old SILOS primitive library (pri150ww.lib)
Curious what you meant by it being a problem back then though, what did you run into?
-
alexh
- Site sponsor

- Posts: 1363
- Joined: 17 Oct 2017 16:51
- Location: Oxfordshire
Re: Wanted: an old SILOS primitive library (pri150ww.lib)
I think ijor's talking about how designs like this could be susceptible to things such as process, voltage and temperature variations where one chip would work and another wouldn't?
The tools they had back then for timing digital circuits probably didn't yield meaningful results when you did things like this and rules had to be disabled hiding potential mistakes?
Netlists don't always contain the information about layout. Often timing fixes needed to be applied to digital designs during layout. They would change cell drive strength, modify track lengths, add buffers etc. to fix issues in the original design
The tools they had back then for timing digital circuits probably didn't yield meaningful results when you did things like this and rules had to be disabled hiding potential mistakes?
Netlists don't always contain the information about layout. Often timing fixes needed to be applied to digital designs during layout. They would change cell drive strength, modify track lengths, add buffers etc. to fix issues in the original design
Senior Principal ASIC Engineer - SystemVerilog, VHDL
Thalion Webshrine - http://thalion.atari.org
ST,STf,STfm,STe,MegaST,MegaSTe,Falcon060
A500+,A600,A4000/060,CD32,CDTV
Thalion Webshrine - http://thalion.atari.org
ST,STf,STfm,STe,MegaST,MegaSTe,Falcon060
A500+,A600,A4000/060,CD32,CDTV
-
ijor
- Posts: 836
- Joined: 30 Nov 2018 20:45
Re: Wanted: an old SILOS primitive library (pri150ww.lib)
I meant it generally, not specifically to Blitter. But it does also affect Blitter and the ST chipset as well. The small differences between Blitteer versions, or at least some of them, is due to to synchronization issues. Even some of the "bad DMA" issues are caused by MCU, or DMA, poor internal synchronization. Shifter bad Spectrum 512 artifacts, etc. And these are all off the top of my head. Some non Atari chips are even worse.exxos wrote: 30 Jul 2026 04:24 Curious what you meant by it being a problem back then though, what did you run into?
Note that you can't really blame them. At the time the whole issue wasn't well known or understood. And even if you would want to implement rigorous synchronous design practices, it would have been economically prohibitive back then.
http://github.com/ijor/fx68k 68000 cycle exact FPGA core
FX CAST Cycle Accurate Atari ST core
http://pasti.fxatari.com
FX CAST Cycle Accurate Atari ST core
http://pasti.fxatari.com
-
exxos
- Site Admin

- Posts: 28619
- Joined: 16 Aug 2017 23:19
- Location: UK
Re: Wanted: an old SILOS primitive library (pri150ww.lib)
That tracks with what I'm finding going through the gate level.. plenty of scope for it :roll: Yeah bad DMA with CPU can types can trigger all sorts of chaos.. oh lets not go down the DMA hole again :)ijor wrote: 30 Jul 2026 20:02 I meant it generally, not specifically to Blitter. But it does also affect Blitter and the ST chipset as well. The small differences between Blitteer versions, or at least some of them, is due to to synchronization issues. Even some of the "bad DMA" issues are caused by MCU, or DMA, poor internal synchronization. Shifter bad Spectrum 512 artifacts, etc. And these are all off the top of my head. Some non Atari chips are even worse.
It is really amazing, the more I look into this stuff, the more I stand by that its a miracle these machines ever even worked out the factory door in the first place. I'm really starting to hate the Atari chipset right now...
Makes sense too, they were clearly saving gates wherever they could (clock gating instead of proper enables, that kind of thing), and synchronous design costs silicon they didn't have to spare back then.Note that you can't really blame them. At the time the whole issue wasn't well known or understood. And even if you would want to implement rigorous synchronous design practices, it would have been economically prohibitive back then.
-
ijor
- Posts: 836
- Joined: 30 Nov 2018 20:45
Re: Wanted: an old SILOS primitive library (pri150ww.lib)
There were other chips worse than the ST chipset. What is unusual in the ST, is the clock division cascade (32 MHz -> 16 MHz -> 8 MHz ...)exxos wrote: 30 Jul 2026 20:14 It is really amazing, the more I look into this stuff, the more I stand by that its a miracle these machines ever even worked out the factory door in the first place. I'm really starting to hate the Atari chipset right now...
That was a bit extreme. The clock skew is so much between the 32 MHz SHIFTER clock and the main CPU/GLUE 8 MHz clock, that they can't be considered really synchronous. But that was taken into consideration, or so it seems. Most of the SHIFTER control logic complexity, is precisely to be immune to clock skew.
http://github.com/ijor/fx68k 68000 cycle exact FPGA core
FX CAST Cycle Accurate Atari ST core
http://pasti.fxatari.com
FX CAST Cycle Accurate Atari ST core
http://pasti.fxatari.com
Who is online
Users browsing this forum: ClaudeBot and 9 guests