RAM write wait states

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

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

czietz
Hardware Guru
Hardware Guru
Posts: 964
Joined: Tue May 24, 2016 6:47 pm

Re: RAM write wait states

Postby czietz » Thu May 09, 2019 3:51 pm

First and foremost: As ijor already said, we don't know if that's the exact circuit that was realized. But unless ijor applies his amazing reverse-engineering skills to an STE shifter, the schematic is the best info we have.

Regarding your question: I assume the symbol is simply misleading by looking like a regular NAND gate. Note that this is a "MAND" gate, where as regular NAND and AND gates with three inputs are called "NA3" and "AA3", respectively in the schematic. Without access to the cell library used by Atari one cannot say for certain, but a highly plausible guess is that this "MAND" (multiple(?) AND) works exactly as you say.

czietz
Hardware Guru
Hardware Guru
Posts: 964
Joined: Tue May 24, 2016 6:47 pm

Re: RAM write wait states

Postby czietz » Thu May 09, 2019 4:44 pm

As it turns out, we have access to the model of the "MAND" gate in form of a spice simulation/netlist:

Code: Select all

****************************************************************************
* Sub Circuit of Macro MAND
* Rev 1.0 on April 3, 1990
*
* NODE : OUTPUT(O), INPUT(A), INPUT(B), INPUT(C), VDD
*
.SUBCKT MAND  5 4 3 2 1
X1  6 4 1 1   PTRANS
X2  5 3 6 1   PTRANS
X3  7 4 1 1   PTRANS
X4  5 2 7 1   PTRANS
X5  8 2 1 1   PTRANS
X6  5 3 8 1   PTRANS
X7  5 3 9 0   NTRANS
X8  9 4 0 0   NTRANS
X9  5 2 10 0  NTRANS
X10 10 4 0 0  NTRANS
X11 5 3 11 0  NTRANS
X12 11 2 0 0  NTRANS


If you visualize this, you end up with:
IMG_3471.JPG

(Please excuse the crudity of the drawing; MOS transistor bulk connection to VCC/GND omitted for simplicity.)

As you can see, this is indeed a "at least two inputs out of three must be '1'" type of gate.
You do not have the required permissions to view the files attached to this post.

slingshot
Atari Super Hero
Atari Super Hero
Posts: 989
Joined: Mon Aug 06, 2018 3:05 pm

Re: RAM write wait states

Postby slingshot » Thu May 09, 2019 6:01 pm

czietz wrote:(Please excuse the crudity of the drawing; MOS transistor bulk connection to VCC/GND omitted for simplicity.)

As you can see, this is indeed a "at least two inputs out of three must be '1'" type of gate.


Wow! I completely don't understand this transistor-level circuit, but if it's really a "2 1's from 3", then it's the same as I expected. Now I just have to revisit other parts where I assumed the expected logic from the drawing. Thanks for the investigation!

Upd.: the only bug I found so far in the schematics is in RLC3: MCC04's SA input must be !XL, not !DL.

czietz
Hardware Guru
Hardware Guru
Posts: 964
Joined: Tue May 24, 2016 6:47 pm

Re: RAM write wait states

Postby czietz » Sun May 12, 2019 3:22 pm

slingshot wrote:Wow! I completely don't understand this transistor-level circuit, but if it's really a "2 1's from 3", then it's the same as I expected. Now I just have to revisit other parts where I assumed the expected logic from the drawing. Thanks for the investigation!


Think of the MOS transistors as switches, where the PMOS transistors (in the top half of my drawing) will close when they get a "low" on their input (gate) while the NMOS transistors (bottom half) close when their gate is "high". Then you can see that for every possible combination of two inputs on the one hand there is a path out connecting the output to ground when two inputs are high. I.e., the output will be "low" in that case. On the other hand, there is a path to Vdd whenever at least two inputs are low, i.e., the output will be high. Since it's not possible that two inputs (out of three) are high and two inputs are low at the same time, there's never a short-circuit.

Maybe CMOS transistor level circuits are easier to understand with a simple NAND gate: https://en.wikipedia.org/wiki/NAND_gate ... S_NAND.svg

Another interesting detail: The SPICE simulations contain transistor models for IMP chips, not just for typical transistors but also for the process corners slow/fast. Assuming that these models match the transistors inside the Atari ASICs, things like propagation delays etc. can be determined from this.

slingshot
Atari Super Hero
Atari Super Hero
Posts: 989
Joined: Mon Aug 06, 2018 3:05 pm

Re: RAM write wait states

Postby slingshot » Sun May 12, 2019 8:52 pm

czietz wrote:
Think of the MOS transistors as switches, where the PMOS transistors (in the top half of my drawing) will close when they get a "low" on their input (gate) while the NMOS transistors (bottom half) close when their gate is "high". Then you can see that for every possible combination of two inputs on the one hand there is a path out connecting the output to ground when two inputs are high. I.e., the output will be "low" in that case. On the other hand, there is a path to Vdd whenever at least two inputs are low, i.e., the output will be high. Since it's not possible that two inputs (out of three) are high and two inputs are low at the same time, there's never a short-circuit.


Makes sense now, thanks for explaining. About the propagation delays: I hope a clock-level simulation of the circuits are enough, and these delays are only considered when they made those "interesting" circuits with lots of double negations (I guess most of them are just a delay chain).
Upd.: I revisited some pages, and I would be really interested in the I1 and I4 primitives function. They're 2 inverters after each other in many places. Are they used for some kind of amplification or the delay introduced by them is important?
Upd2.: How is it possible to view those WAV files?

slingshot
Atari Super Hero
Atari Super Hero
Posts: 989
Joined: Mon Aug 06, 2018 3:05 pm

Re: RAM write wait states

Postby slingshot » Mon May 27, 2019 2:53 pm

Processing the ST4081S.PDF: seems it's some upgraded design to the original GST MCU. I found a new chip enable signal, which is not in the original one: KSND. It decodes to FFE8XX-FFEFXX. Is there any known peripheral in this address?

czietz
Hardware Guru
Hardware Guru
Posts: 964
Joined: Tue May 24, 2016 6:47 pm

Re: RAM write wait states

Postby czietz » Mon May 27, 2019 4:01 pm

KSND goes to pin 104 which is left unconnected in the STE/MegaSTE. Note that there is yet another unconnected/undocumented pin, pin 14, ROMP which -- iirc -- is decoded to 0xFE0000 - 0xFE1FFF.

From the existence of the GAMECART register (see my forum thread) we know that Atari implemented more features into GSTMCU than are actually used. I assume that they planned to put the GSTMCU into another machine, as well, and that KSND and ROMP would have been used there.

slingshot
Atari Super Hero
Atari Super Hero
Posts: 989
Joined: Mon Aug 06, 2018 3:05 pm

Re: RAM write wait states

Postby slingshot » Sun Jul 14, 2019 3:54 pm

Finally I've managed to wire the GST MCU model into a real FPGA. However it doesn't work (well, not surprised...). I'm suspecting RAM access problems, but not sure what's the real issue (got several overlapping line of bombs). I've made a capture of a read cycle:

readcyc.png


1. AS activated at 0 (976)
2. DTACK_N asserted at the CPU RAM cycle, at +3 (not too early?)
3. RAS_N goes down at +4 (starting the SDRAM read cycle)
4. SDRAM returns the correct data (00FA) at +6
5. Read cycle ends at +10.

AFAIK the 68000 should latch the incoming data at the end of the read cycle (+10). However I've noticed the FX68K latches it several times during the cycle (before the correct data is latched at the end). Should it work like this? (in the previous - working - core, DTACK_N is not asserted until the incoming data is stable, that's a main difference I guess). However the data is read much faster than from a real DRAM here, so shouldn't be an issue.

Upd.: there were bugs at somewhere else, now ROM/RAM passes the STe diagnostic test cartdrige with original timings (at least if I translated the schematics to Verilog correctly).
http://gossuin.be/index.php/archives/2- ... t-atari-st
You do not have the required permissions to view the files attached to this post.

ijor
Hardware Guru
Hardware Guru
Posts: 3790
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: RAM write wait states

Postby ijor » Wed Jul 17, 2019 2:00 am

slingshot wrote:2. DTACK_N asserted at the CPU RAM cycle, at +3 (not too early?)
(in the previous - working - core, DTACK_N is not asserted until the incoming data is stable, that's a main difference I guess).


Yes, MMU asserts DTACK before ram is actually ready, and that is the correct behavior. According to the 68K bus protocol specs, DTACK assertion doesn't (necessarily) means that data is already ready. It just means that it would be ready at the correct time. DTACK is not a latch enable signal, it is processed synchronously. The CPU latches data at S7, but DTACK is checked at S5. It is useful to log the machine state busControl:busPhase with SignalTap to visualize the phases.

AFAIK the 68000 should latch the incoming data at the end of the read cycle (+10). However I've noticed the FX68K latches it several times during the cycle (before the correct data is latched at the end). Should it work like this?


Yes, this is how the original CPU actually works. When the microcode signals a bus read operation, data is latched every cycle. But the data, of course, is ignored until the correct cycle. It was probably implemented like this to simplify the data input logic.
Fx Cast: Atari St cycle accurate fpga core

slingshot
Atari Super Hero
Atari Super Hero
Posts: 989
Joined: Mon Aug 06, 2018 3:05 pm

Re: RAM write wait states

Postby slingshot » Wed Jul 17, 2019 7:42 am

ijor wrote:Yes, this is how the original CPU actually works. When the microcode signals a bus read operation, data is latched every cycle. But the data, of course, is ignored until the correct cycle. It was probably implemented like this to simplify the data input logic.


Thanks for the clarification! Nice to see the internals of the 68000 in your core.


Social Media

     

Return to “Hardware”

Who is online

Users browsing this forum: No registered users and 3 guests