Wakeup modes

[DrCoolZic]

I am still trying to figure out why and how the "wakeup" mode is happening.

For that matter I found the article from Alien on Overscan technique ( that I published at http://www.atari-forum.com/viewtopic.php?p=76804#76804 quite interesting and with a lot of useful information.

on page 10 he is mentioning:

0 Byte line by switching to 60Hz at position 14 (detection of the beginning of a line at 50Hz). This method is not recommended, because it doesn't work once out of every twenty times the ST is powered on. This happens when the timing of the GLUE and the MMU are offset in such a manner that the 68000 cannot access the bus on the precise cycle required to change the frequency. Recall that it is the MMU that decides which of every four cycles will be allocated to the 68000, and that at on power on circuits can receive parasitic noise on the clock signal that could potentially cause this offset.

and on page 14:

This actually occurs rarely (one time out of 20), depending on power up conditions causing the GLUE, MMU and SHIFTER to be slightly out of synch.

Therefore it seems that the "wakeup mode" as described in this document is more undeterministic/random (as confirmed by Paulo) than as described by Ijor to be related to temperature (when warm always the same wakeup mode). Note that the two are not antagonistic the temperature must definitively have some effect on a borderline behavior.

Unfortunately my STF does not have this randomness at wakeup. Otherwise I could have done some experiments (I have all the equipment to "freeze and/or to heat" the MMU and GLUE) ...

Actually to better understand what is happening I was wandering if anybody had analyzed the different signals involved with a logic analyzer?
Knowing exactly the relationship between the different clocks and signals would be invaluable in understanding the problem.

I have also updated the diagram that I have published at the beginning of this thread. It now shows the chain that generates the clocks (32Mhz input + 16MHz output of the shifter, 16MHz input + 8/4MHz output of the MMU, and 8MHz input + 2MHz/500KHz output of the Glue) as well as a more detailed presentation of the data/address busses (shows how the data busses are separated and latched/tri-stated under the control of the MMU). I have also shown the fact that the GLUE/MMU are connected to the DTACK signal and this is probably the signal used by the MMU to sometimes delay the 68000 (usually by by two cycles).

Therefore can someone provide detailed timing information for the different signals involved?

With the arrival of several USB Logic Analyzers the price has dropped and may be ....

Jean

[ijor]

Therefore it seems that the "wakeup mode" as described in this document is more undeterministic/random (as confirmed by Paulo) than as described by Ijor to be related to temperature (when warm always the same wakeup mode).

Paulo actually confirmed it is related to temperature, and not exactly random. Read the other thread and you will see that he cannot easily reach the cold wakeup.

But I never claimed it is purely a heating issue. The actual physical cause of the behavior is unknown and not really very important. It is possible that other machines have a different behavior. All it matters is that there are different wakeup that are determined at powerup.

Actually to better understand what is happening I was wandering if anybody had analyzed the different signals involved with a logic analyzer?
Knowing exactly the relationship between the different clocks and signals would be invaluable in understanding the problem.

It wouldn't be very helpful. The behavior of the wakeup is completely understood. The only point that is not known is what is the ultimate reason. The ultimate reason again, is not important and I doubt a logic analyzer would give you much clues.

All indicates that the wakeups depend on the initial state of one flip-flop that is not initiated at powerup. This could be in MMU, GLUE, or even both. So the ultimate reason is what exactly causes that flip-flop to be in one state or the other at power up. You would need an internal analysis of the chip(s), and not a logic analyzer.

[DrCoolZic]

Not sure lots of interest in this forum but talking about PC based logic analyzer / Scope ... here is my selection ...

Excellent Logic Analyzer + Sope + Generator +++
http://www.dynoninstruments.com/
$495 - 16Ch logic analyzer + 2 ch Scope +++ 80Ms/s - 32K samples/ch

Excellent Logic analyzer + Scope ++
http://www.usbee.com/ax.html
$445 - 8 Ch 24Msps + 2Ch Dig Scope 16Msps - 1 M samples/ch

My favorite .... best price/perf just missing scope ?
http://www.pctestinstruments.com/
$389 34Ch Logic Analyzer - 500Mhz(async) 200MHz(sync) 2K Samples/ch (++ compression)

Excellent but only 16 Ch for about same price as above
http://www.rockylogic.com/index.html
$377 16Ch, $244 8Ch - 500MHz - 2K samples/ch

Cant find any cheaper lots of integrated tools (analyzer, scope, generator, ...) but limited capability (Freq and buffer size)
http://www.hobbylab.us/USBOscilloscope/Home.htm
$169.50 16Ch - 128 samples/8Mhz 1500s/1Mhz + 2 CH SCOPE +++

Of course a lot more available more info provided at circuit cellar bbs
http://bbs.circuitcellar.com/phpBB2/vie ... hp?p=10667

[DrCoolZic]

...
The actual physical cause of the behavior is unknown and not really very important. It is possible that other machines have a different behavior. All it matters is that there are different wakeup that are determined at powerup.

Of course I fully agree that knowing the cause of the problem is of no interest and that, as I mentioned, the temperature has probably an influence on the wakeup mode.

Actually to better understand what is happening I was wandering if anybody had analyzed the different signals involved with a logic analyzer?
Knowing exactly the relationship between the different clocks and signals would be invaluable in understanding the problem.

It wouldn't be very helpful. The behavior of the wakeup is completely understood. The only point that is not known is what the ultimate reason is. The ultimate reason again, is not important and I doubt a logic analyzer would give you much clues....

As previously mentioned I do not care at all of the ultimate reason of the wakeup mode and of course a Logic Analyzer would certainly not help in that matter...
The reason to use a Logic Analyzer would be to better understand how the time slots of the data bus are sliced between the 68000 and the MMU and how (what mechanism/signal) the slicing is performed for both wakeup modes (also in respect with the DE signal). Note that this points back to your initial description of the problem at the very beginning of this thread and as far as I can tell it has not yet received any answer (even if you know how to deal with it).

Once out of every twenty times, when the ST is powered on, the timing of the GLUE and the MMU are offset in such a manner that the 68000 cannot access the bus on the precise cycle required to change the frequency. Recall that it is the MMU that decides which of every four cycles will be allocated to the 68000.

This is the information I am interested to look at (i.e. which time slot an how it is influenced by the wakeup mode).
If, as you mentioned, the “behavior of the wakeup is completely understood” the actual timing modification on the bus do not seems to be fully understood (or at least I did not found any description/diagram).

I started to look at the precise timing of the 68000, how it interacts with the STF/STE busses, and how the MMU can steal one time slot from the 68000 every 500 ns to feed the shifter. As I already mentioned, at this speed, this slicing can’t obviously be done by a bus request/grant mechanism and for that matter any sophisticated arbitration mechanism. What is happening is that the MMU has to steal a time slot from the 68000 every 500ns (at least during active display) and most probably this has to happen at the beginning of the 68000 bus access cycle (where data are not yet required) and somehow this mechanism has to be "secured" (probably by playing with the DTACK signal?). Stealing this time slot should be transparent to the CPU on 4 cycles boundary but may delay the 68000 on a 2 cycles boundary (depending of the addressed component/memory).
You also have to remember that the MMU is responsible for handling “bus stealing” for the “sound DMA” on an STE (contrary to the FD/HD DMA bus request which are handled by a regular bus request/grant performed by the glue chip).

There has been a lot of information exchanged in this thread (and in at least two other threads in this forum) about the execution time of 68000 instructions executed in an STE "environment" and the wakeup mode is definitively part of the story (even if marginally).

I personally think that a good diagram is better than many words… and therefore I still would love to see timing diagrams for critical signals/busses in an Atari. Of course most of the timings can be drawn on a piece of paper "by deduction" but, as some of the details of the MMU/Shifter/Glue/DMA are not known, using a Logic Analyzer would allow to remove any ambiguity.
I understand that this information is probably of little interest to most people, but beyond the satisfaction of fully understanding the behavior of the "gang of four" it would allow a better prediction of "subtle" behaviors.


Jean

[ijor]

The reason to use a Logic Analyzer would be to better understand how the time slots of the data bus are sliced between the 68000 and the MMU and how (what mechanism/signal) the slicing is performed for both wakeup modes (also in respect with the DE signal).

You might find it useful for yourself, but this is already known and perfectly understood. The slicing has no relation with the DE signal. That's the whole point of the wakeups.

Note that this points back to your initial description of the problem at the very beginning of this thread and as far as I can tell it has not yet received any answer (even if you know how to deal with it).

Everything was answered already. What exactly hasn't been answered yet?

Once out of every twenty times, when the ST is powered on, the timing of the GLUE and the MMU are offset in such a manner that the 68000 cannot access the bus on the precise cycle required to change the frequency.

Please stop quoting things that are wrong. We already know this is wrong, otherwise the new switches in the other thread wouldn't work.

If, as you mentioned, the “behavior of the wakeup is completely understood” the actual timing modification on the bus do not seems to be fully understood (or at least I did not found any description/diagram).

There are no modifications or changes in the bus timing. Bus timing is always the same.

I started to look at the precise timing of the 68000, how it interacts with the STF/STE busses, and how the MMU can steal one time slot from the 68000 every 500 ns to feed the shifter. As I already mentioned, at this speed, this slicing can’t obviously be done by a bus request/grant mechanism and for that matter any sophisticated arbitration mechanism. What is happening is that the MMU has to steal a time slot from the 68000 every 500ns (at least during active display) and most probably this has to happen at the beginning of the 68000 bus access cycle (where data are not yet required) and somehow this mechanism has to be "secured" (probably by playing with the DTACK signal?).

I'm not sure what you don't understand. It is very simple and almost obvious if you look at the schematics.

CPU controls the main bus. MMU controls the RAM data bus. Both are isolated by a couple of small TTL chips.

For accesing the RAM bus, MMU allocates 250ns for the main bus (CPU/DMA/Blitter) and 250ns for itself (video, STe sound and RAM refresh).

If the CPU performs an aligned bus cycle, then MMU can service it immediately and activates DTACK without delay. If the CPU attempts a misaligned access, then MMU inserts wait states by delaying DTACK.

The TTL chips buffer the data because CPU owns the main bus during both time slots.

[ljbk]

Hi !

Just about that stuff about the STE just having 1 wake up mode.
I just remembered something i already considered about this in the past that sounds logical to me.
As it seems that the sound dma does not slow down a bit the STE and that you can even do a fullscreen at the same time like in the Phaleon Demo (this was surprising for me at the time), then what is probably happenning is that out of the 4 time slots of the tipical 4 cycles taken for a "nop" for example you should have:
- 2 slots to access memory for the CPU, allowing effects like the ones described in the latest overscan techniques
- 1 slot for the Shifter to get the video data
- 1 slot for the Sound DMA
As that last one was not present in the STF, the Shifter may use 2 different time slots choosing one by an unknow process during a cold reset

That is just a theory of course.

[ijor]

Hi Paulo,

Just about that stuff about the STE just having 1 wake up mode.
...
- 2 slots to access memory for the CPU, allowing effects like the ones described in the latest overscan techniques
- 1 slot for the Shifter to get the video data
- 1 slot for the Sound DMA

No, it doesn't work like that. Each RAM access requires two machine cycles, and STe Sound DMA is performed during horizontal blank.

As it seems that the sound dma does not slow down a bit the STE and that you can even do a fullscreen at the same time like in the Phaleon Demo

Neither Sound DMA, neither fullscreen produces any slow down whatsoever. The time slots are allocated to them regardless.

The possible reasons for the STe having a single wakeup are multiple. For starters the MMU/GLUE chip is quite different than the ST ones. But it seems that latest STfm also have a single wakeup.

[ljbk]

Hi Ijor,

When i was refering 4 cycles, i meant 4 CPU cycles: 500ns.
With 32 MHz, these 4 CPU cycles are turned into 16 (32MHz) cycles.
I do not remember the access time limit for the memory used for the ST as well as i do not know how and how long it takes for the MMU to perform the memory refresh cycle.

Anyhow, i find it strange that the Sound DMA reads memory during the HBL as the DMA ouput frequencies are not multiples of the HBL frequency:

PAL 50Hz 512 CPU cycles/ line => HBL freq is around 15625 Hz
NTSC 60Hz 508 CPU cycles/line => HBL freq is around 15873 Hz

DMA frequencies are, as i remember: 50066Hz, 25033Hz, 12517Hz, 6258Hz with 2 bytes to be read each time. In the first case we would have sometimes 8 bytes and sometimes only 6 bytes, second case 4/2, third and fourth case 2/0.

[ijor]

I do not remember the access time limit for the memory used for the ST as well as i do not know how and how long it takes for the MMU to perform the memory refresh cycle.

MMU needs 250ns (2 CPU cycles) for each RAM access. While video is active, and for each NOP, 250ns are allocated to the CPU and 250ns for the Shifter. So sound DMA cannot be perfomed while video is active.

Anyhow, i find it strange that the Sound DMA reads memory during the HBL as the DMA ouput frequencies are not multiples of the HBL frequency:

HBL is not used as a counter or a clock. STe sound operates through a FIFO. What MMU does is to keep the FIFO full whenever possible. In turn the FIFO will output at the selected rate.

Btw, I used the term HBL but it is not exact. MMU doesn't know about HBL, it only knows when display is active or not according to the DE signal.

[ijor]

The reason to use a Logic Analyzer he DE signal).

You might find it useful for yourself, but this is already known and perfectly understood.

By re-reading this thread I realized that I migh expressed myself wrong. What I mean is that traces won't be too useful for wakeup analysis purposes. Traces however are always nice to have, and if you were considering performing some traces, then please do and post them.

Personally I think that memory access traces are not the most interesting though. I think that I've seen a couple of time diagrams already. There some other aspects that seem to be more interesting to me. For example, DMA and interrupt timing.

[Cyprian]

I do not remember the access time limit for the memory used for the ST as well as i do not know how and how long it takes for the MMU to perform the memory refresh cycle.

MMU needs 250ns (2 CPU cycles) for each RAM access. While video is active, and for each NOP, 250ns are allocated to the CPU and 250ns for the Shifter. So sound DMA cannot be perfomed while video is active.

MMU to assign 128 RAM accesses per line for video and refreshing ram. From this 128 RAM slots, shifter takes only 80, and 48 are free (I don't know how many slots takes refreshing of RAM). 48 slots could be enougth for SDMA...

[kilbaf]

Sorry, I am out of the subject, but interested by all these hardware discussions.
All this, make me think it is a pity that we do not have the logic description of the glue,MMU,DMA,shifter ?
I know there are some hardware project to reproduce an ST on FPGA. How do you think they do ? Same way as an emulator, looking for functionality ?
If I remember well the 1st ST in 1985 doesn't have glue, all the logic were in TTL. I have no idea of how many gates this means but then a reverse of the logic from hardware to schematic is possible even if painful. I have no idea if they directly implement this in the glue, probably they adapt it.
What are the glue,MMU,DMA,shifter ? PLA/PLD/CPLD... ? how many gates ? only gates or with flip-flop also ?
By the way does somebody has an architecture description of the ST, data sheet of used chips ?

[ijor]

MMU to assign 128 RAM accesses per line for video and refreshing ram. From this 128 RAM slots, shifter takes only 80, and 48 are free (I don't know how many slots takes refreshing of RAM). 48 slots could be enougth for SDMA...

Of course that there is enough free time per scanline. That was never a question. Otherwise it couldn't work at all.

But there is no time for DMA in the middle of the scan while display is active. It is done at the borders (whenever DE is not active).

[ljbk]

MMU to assign 128 RAM accesses per line for video and refreshing ram. From this 128 RAM slots, shifter takes only 80, and 48 are free (I don't know how many slots takes refreshing of RAM). 48 slots could be enougth for SDMA...

Of course that there is enough free time per scanline. That was never a question. Otherwise it couldn't work at all.

But there is no time for DMA in the middle of the scan while display is active. It is done at the borders (whenever DE is not active).

Please note that in case of fullscreen, Shifter does not get 80 but alt least 115(STF)/116(STE).
Anyway the remaining 12 are more than enough.
The strange thing for me is still why did they choose these Sound DMA hardware frequencies that had nothing to do with the common Amiga and PC frequencies at the time.

[unseenmenace]

Of course that there is enough free time per scanline. That was never a question. Otherwise it couldn't work at all.

But there is no time for DMA in the middle of the scan while display is active. It is done at the borders (whenever DE is not active).

Just a thought but if you are doing a fullscreen DE is on for a fair while longer in each scanline so would there still be enough cycles left in the borders to play DMA at 50KHz for example?

[ijor]

If I remember well the 1st ST in 1985 doesn't have glue, all the logic were in TTL. I have no idea of how many gates this means but then a reverse of the logic from hardware to schematic is possible even if painful.

Only early prototypes were built with discrete TTL components. Schematics of those prototypes could be indeed very interesting. But recreating those schematics it would mean a lot of work, and you can't take anything for granted. The final product might be different than the prototype.

And I would guess you can't find a protoytpe so easily. May be Curt possibly has one.

What are the glue,MMU,DMA,shifter ? PLA/PLD/CPLD... ? how many gates ? only gates or with flip-flop also ?

No programmable logic, that would be too expensive. They are all ASIC chips.

No idea about how many gates, but for sure they use flip-flops.

[ijor]

Just a thought but if you are doing a fullscreen DE is on for a fair while longer in each scanline so would there still be enough cycles left in the borders to play DMA at 50KHz for example?

There is still enough time. At least for a "standard" full screen. If you were going to use something like the Enchanted Land whole overscan (see the other thread), then obviously not.

There might be a problem with the FIFO not being big enough. Does somebody know for sure if max rate with stereo works of with full-screen? The problem is not the amount of free time slots on each scan. The problem is that the period where SDMA can't be performed (because DE is activated) could be too long for the small FIFO.

It seems the FIFO should still be enough, even with full-screen. But this actually depends on exactly how everything is implemented. And ATARI might have not considered the possibility of full-screen together with max sound DMA frequency.

[DrCoolZic]

Please stop quoting things that are wrong.

Promise I will try.

There are no modifications or changes in the bus timing. Bus timing is always the same.
…
I'm not sure what you don't understand. It is very simple and almost obvious if you look at the schematics.
…
Everything was answered already. What exactly hasn't been answered yet?

I guess I must have been confused by some early information discussed in this thread

The ST has one non-deterministic feature that is determined randomly (well, not exactly, see below) at power up. It is called “wakeup” mode. Depending on the current wake up mode, some programs might not run correctly, or not at all.

Code: Select all

GLUE has internally a 2Mhz clock (period equivalent to one NOP) for the video state machine. MMU has a 4Mhz clock to round robin grant bus access to the CPU or to the SHIFTER (modified version)

The two clocks are in perfect phase. This means that the active edge of the 2Mhz clock coincides with the 4Mhz one. The 2Mhz clock toggles an internal flip-flop. But the initial state of the flip-flop is not deterministic at power up. 

Then, in one wakeup mode, the CPU is granted access concurrently with the 2Mhz period. In the other, it is the SHIFTER. 

…
Some kind of arbitration must be implemented. Otherwise the CPU might attempt a bus access concurrently with the SHIFTER. It is of course not a formal bus grant mechanism (as it is used for DMA), that would be too slow. GLUE simply inserts wait states delaying the CPU for two cycles.
…
But the CPU doesn't perform any interleaving by itself. The CPU "thinks" he owns the bus all the time. And it will try to access the bus whenever he wants. So GLUE forces the interleaving by inserting two wait states. And it will do it only when the CPU attempts a bus access in a Shifter slot.
…
So you may call it a "forced interleaving" if you want instead of arbitration. But it is still GLUE who stops the CPU for two cycles. It is not a natural interleaving.

All the above information made me wrongly believe that the GLUE (or more probably as you mentioned the MMU) was inserting wait states to the CPU at different time slots based on the wakeup mode!
But of course I now realize that this was a wrong assumption and that the MMU always still times in slots in the s0-s4 range from the CPU which should be transparent to the CPU on any 4 cycles align bus access. The attached diagram taken from a logic analyzer (with the 68000 states annotated) shows the relationship of the load/rdat/wdat/latch/dtack with the CPU slots/signals.

Therefore seems like the only thing that changes in different wakeup mode is the "phase" of the GLUE internal clock in relationship with CPU bus access.

I am also wandering why my STF machine is different from the others???
In the “68000 clock cycles thread” I mentioned that the program from Paulo was changing the scan frequency of my machine from 60Hz to 50Hz . This is because even if the original machine is a European model I am currently using a TOS version updated in California to the US TOS 1.4 (Rainbow TOS). While the TOS version should not have any influence, it might be that the initial 60Hz bootup frequency set by the TOS might prevent the “wakeup” problem to happen? I finally found my original UK TOS V1.0 (not bad after all these years!). As soon as I find some time (pretty busy right now) I will try to install these ROM so that my machine bootup at 50Hz and test if after that the machine can wakeup in the 2 different modes?
As temperature seems to influence the wakeup mode what would be your best guess for the chip to “freeze” (so I do not have to wait over night)? Personnaly I would bet for the Glue?

[ijor]

Therefore seems like the only thing that changes in different wakeup mode is the "phase" of the GLUE internal clock in relationship with CPU bus access.

That's correct. Or more precisely, it changes the phase between GLUE video processing and MMU time slots. This in turns produces a shift between GLUE and both the CPU and Shifter.

I am also wandering why my STF machine is different from the others???...
While the TOS version should not have any influence, it might be that the initial 60Hz bootup frequency set by the TOS might prevent the “wakeup” problem to happen?

I don't know why your machine seems to have a single wakeup. The initial refresh rate shouldn't have any relevance whatsoever. The wakeup is determined long before TOS sets the sync rate.

As temperature seems to influence the wakeup mode what would be your best guess for the chip to “freeze” (so I do not have to wait over night)? Personnaly I would bet for the Glue?

That's a good question, and I don't know the answer. The wakeup might be originated by GLUE, by MMU, or by both. It is very difficult to tell. But I suspect it won't help anyway. It seems that some machines have (for some reason) a single wakeup. Probably a newer/different GLUE or MMU part. Things like these could change just by minor differences in the chip mask.

Measuring the phases of the external clocks with a Logic Analyzer under both wakeups might offer some clues about the chip that originates the wakeup. This is assuming the external clocks produced by GLUE and MMU are the same (or at least derived from) as the ones used internally. It doesn't have to be like this, but it would make sense.

[DrCoolZic]

I know there are some hardware project to reproduce an ST on FPGA. How do you think they do ?

I am aware of at least two projects. One of them is actually well advance as most of the complex chips are already done apart from the 68000 which is well under devellopment. The resulting system should fit in an Altera Cyclone I.
To develop the complex chips different people use different technique. For the most advance project, each of the chips to emulate where removed from the ST board and replaced by an Altera FPGA and the chip were programed in VHDL using Quartus SW until the same behavior was obtained...
You should be able to find reference to this project in the HW forum

If I remember well the 1st ST in 1985 doesn't have glue, all the logic were in TTL. I have no idea of how many gates this means but then a reverse of the logic from hardware to schematic is possible even if painful.

Actually all the Atari ASIC where realized as TTL boards for the first prototypes see http://www.bambi.net/atari/atari_st_prototype.html
But of course never realeased!!!
Having the original TTL boards would help to understand the behavior of ST ASICs but would certainly not be used for th VHDL models. Models would be too low level description => would be too slow, and would use too many ressources on the FPGA. Therefore all models are described as high level behavioral blocks (several blocks sructuraly connected for each complex chip) and the FPGA backend tools are used to map to the FPGA.
Jean

[ijor]

Actually all the Atari ASIC where realized as TTL boards for the first prototypes see http://www.bambi.net/atari/atari_st_prototype.html

Wow so Leonard Tramiel still owns one of those prototypes (may be the only one)!

[alexh]

Having the original TTL boards would help to understand the behavior of ST ASICs but would certainly not be used for the VHDL models.

Erm.. Why not?

Models would be too low level description => would be too slow, and would use too many ressources on the FPGA.

Not true, not true at all. In fact while researching how the Atari chips work, the closer you get your VHDL to how it actually works the smaller the design gets. They were under a considerable gate budget back then, everything had to be as optimised as possible. They were MUCH smarter engineers back then because they had to be. Today we are very lazy.

Therefore all models are described as high level behavioral blocks (several blocks sructuraly connected for each complex chip) and the FPGA backend tools are used to map to the FPGA.

If the people replicating the ST in an FPGA had access to the netlists they would be MUCH smaller than any VHDL we could come up with, and of course more accurate.

[ijor]

If the people replicating the ST in an FPGA had access to the netlists they would be MUCH smaller than any VHDL we could come up with, and of course more accurate.

Getting the netlist of the chipset would be fabulous. But the prototype would not give you the ASIC netlists. It is very likely that the prototypes have considerable differences with the final product. Yet, I would still love to see schematics of those prototypes.

It is also possible that you wouldn't want to replicate the netlist exactly. Perhaps not the case for the ST, but the chipset in 8-bit computers and consoles used a lot of async and ripple features. In some cases they even have analog components in the chip.

Actually, several of the standard chips in the ST have async designs and the sound chip has an integrated DAC.

[DrCoolZic]

Models would be too low level description => would be too slow, and would use too many ressources on the FPGA.

Not true, not true at all. In fact while researching how the Atari chips work, the closer you get your VHDL to how it actually works the smaller the design gets. They were under a considerable gate budget back then, everything had to be as optimised as possible. They were MUCH smarter engineers back then because they had to be. Today we are very lazy.

You are right in saying that the designers must have been under a lot of pressure to get the gate count to a minimum and that the ASIC must have been very well optimized for the targeted behavior and the targeted ASICs technology used at that time.

If the people replicating the ST in an FPGA had access to the netlists they would be MUCH smaller than any VHDL we could come up with, and of course more accurate.

As I mentioned having the netlist would be very usefull to have a very accurate description in order to make sure the behavior matches the original.
However as Ijor mentioned the ST ASICs are certainly not a "gate replication" of the TTL boards. This is due to the fact that when you map (we would use the term synthesis our days) a behavioral model to a specific technology (TTL and ASIC in our case) you have to optimize to the mapping to the technology. I remember that mapping a specific behavior to a set of TTL gates available at that time was an "art" and indeed quite some fun. If you gave the same behavior to realize to a bunch of designers you were getting quite different results (quite different but often equivalent in number of packages). Mapping simple behaviors to ASICs used at this time was somewhat easier as only low level basic gates/latches were avaiable. Mapping the same behavior to modern FPGA is far more complex (and probably not even feasible by "hand"). The reason is that the "ressources" available on a complex FPGA are high level blocks (some FPGA provides full CPU blocks e.g. Altera CPU equivalent to an ARM) and therefore it is actually better to provide abstract models so that the backend synthetisis tools can optimized the mapping to the targeted FPGA ressources (this is not to be confused with PLA/PLD/CPLD ...)

[DrCoolZic]

By the way I totally forgot to mention that I learn recently that the netlists for the ST ASICs may be available somewhere....

Of course until I personally see these netlists I am sceptical, but I am actually following on this information with a contact…

Jean