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

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

Re: RAM write wait states

Postby ijor » Mon Apr 08, 2019 5:38 pm

slingshot wrote:Yepp, just all was running on negedge, but the latch holding the load signal (PQ029) operated on positive edge


I'm not so familiar with this chip as I am with the ST version, but that doesn't sound right. I think you are misinterpreting the internal clock inversion in the LT2 cell. The clock is inverted because it feeds an input that in turn is also inverted. LT2 still runs on the positive edge.

Vertclk is always at 0 (when the vertical sync counter gets its clock).


That doesn't make much sense to me. Vertclk is normally the vertical sync counter clock and obviously toggles each time the horizontal counter overwraps. The mux is for simulation purposes. Or I am misunderstanding you?
Fx Cast: Atari St cycle accurate fpga core

slingshot
Atari God
Atari God
Posts: 1400
Joined: Mon Aug 06, 2018 3:05 pm

Re: RAM write wait states

Postby slingshot » Mon Apr 08, 2019 9:00 pm

ijor wrote:
slingshot wrote:Yepp, just all was running on negedge, but the latch holding the load signal (PQ029) operated on positive edge


I'm not so familiar with this chip as I am with the ST version, but that doesn't sound right. I think you are misinterpreting the internal clock inversion in the LT2 cell. The clock is inverted because it feeds an input that in turn is also inverted. LT2 still runs on the positive edge.

Maybe I misinterpreted LT2 schematic. The simulation gives the expected amount of cycles/line when LT2 is triggered at positive edge (but on the schematic, it's a latch and not so straightforward for me - the latch gate input gets the inverted value of the clock, that's why I assumed it works on the negative edge).
Vertclk is always at 0 (when the vertical sync counter gets its clock).


That doesn't make much sense to me. Vertclk is normally the vertical sync counter clock and obviously toggles each time the horizontal counter overwraps. The mux is for simulation purposes. Or I am misunderstanding you?


I think no misunderstanding here. After the horizontal counter overflows (binary value goes to 0), it triggers the preload for the counters, and this is also the clock of the vertical counter (more precisely the inverted value of the load signal).

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

Re: RAM write wait states

Postby ijor » Mon Apr 08, 2019 11:09 pm

slingshot wrote: ... but on the schematic, it's a latch and not so straightforward for me - the latch gate input gets the inverted value of the clock, that's why I assumed it works on the negative edge.


It gets the inverted clock, but that latch is low active. See that the name of the control signal of the latch is XG (or XC?). X being used as a prefix for inverted or negative. If you check the rest of the logic of the LT2 cell, you will see that the latch has to be low active or otherwise the cell will not work correctly.
Fx Cast: Atari St cycle accurate fpga core

slingshot
Atari God
Atari God
Posts: 1400
Joined: Mon Aug 06, 2018 3:05 pm

Re: RAM write wait states

Postby slingshot » Tue Apr 09, 2019 8:14 am

ijor wrote:
slingshot wrote: ... but on the schematic, it's a latch and not so straightforward for me - the latch gate input gets the inverted value of the clock, that's why I assumed it works on the negative edge.


It gets the inverted clock, but that latch is low active. See that the name of the control signal of the latch is XG (or XC?). X being used as a prefix for inverted or negative. If you check the rest of the logic of the LT2 cell, you will see that the latch has to be low active or otherwise the cell will not work correctly.

Yepp, everything is clear now. At the end, LT2 in Verilog:

Code: Select all

always @(posedge c, negedge xr) begin
    if (!xr) xq <= 1;
    else begin
        xq <= l ? ~dl : ~dc;
    end
end;

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

Re: RAM write wait states

Postby ijor » Wed Apr 10, 2019 1:38 am

slingshot wrote:Yepp, everything is clear now. At the end, LT2 in Verilog:

Code: Select all

always @(posedge c, negedge xr) begin
    if (!xr) xq <= 1;
    else begin
        xq <= l ? ~dl : ~dc;
    end
end;


Not exactly. Load is asynchronous, or more precisely, it seems to be partially synchronous, it is asynchronous in one phase of the clock and synchronous on the other. That's probably why they added the extra flip flop for the load control.

It is quite tricky to model something like that with behavioral Verilog. The result might depends on the specific compiler or simulator. Possibly Verilator doesn't support something like that.

But perhaps more important, if load is asynchronously, you lose back one cycle. The load is performed at the very same cycle that signal L is asserted.

GLUE (plain ST) counters are slightly different. Load is synchronous and there is no extra flip flop.
Fx Cast: Atari St cycle accurate fpga core

slingshot
Atari God
Atari God
Posts: 1400
Joined: Mon Aug 06, 2018 3:05 pm

Re: RAM write wait states

Postby slingshot » Wed Apr 10, 2019 7:54 am

ijor wrote:
slingshot wrote:Yepp, everything is clear now. At the end, LT2 in Verilog:

Code: Select all

always @(posedge c, negedge xr) begin
    if (!xr) xq <= 1;
    else begin
        xq <= l ? ~dl : ~dc;
    end
end;


Not exactly. Load is asynchronous, or more precisely, it seems to be partially synchronous, it is asynchronous in one phase of the clock and synchronous on the other. That's probably why they added the extra flip flop for the load control.

It is quite tricky to model something like that with behavioral Verilog. The result might depends on the specific compiler or simulator. Possibly Verilator doesn't support something like that.

But perhaps more important, if load is asynchronously, you lose back one cycle. The load is performed at the very same cycle that signal L is asserted.

GLUE (plain ST) counters are slightly different. Load is synchronous and there is no extra flip flop.


I don't see a flip-flop in LT2, just that one latch. And I see it's a bit different between 4081.pdf and 4081org.pdf, the former is simpler. The extra flip-flop at the horizontal counter at the end of the chain ensures that the load will happen after the overflow state (e.g. there will be 127, 0, load value, ... states in the counter, not just 127, load value, ...). For me, it seems load of LT2 is just selecting the latch input between L and DC with L.

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

Re: RAM write wait states

Postby ijor » Wed Apr 10, 2019 12:26 pm

slingshot wrote:I don't see a flip-flop in LT2, just that one latch.


The whole LT2 cell works like a flip-flop. Or you mean that there is no flip-flop INSIDE LT2? If so, Agree. What I meant by the extra flip flop is the one after the counter that pipelines the LOAD control signal.

And I see it's a bit different between 4081.pdf and 4081org.pdf, the former is simpler.


Seem different standard cell technology. In one case the flops require both the inverted and the non inverted clock, in the other they don't. I don't remember for sure why one has the "ORG" prefix. Christian?

We don't know for sure exactly which version, if at all, is the one on that is actually on the silicon. And there are multiple chip releases as well.

The extra flip-flop at the horizontal counter at the end of the chain ensures that the load will happen after the overflow state (e.g. there will be 127, 0, load value, ... states in the counter, not just 127, load value, ...).


But you don't need that strictly, not as long as load is synchronous. You could overflow on 127 and avoid that extra flip flop. Just compensate with an extra cycle on the reload values. This is exactly what ST GLUE does (see below). OTOH, if load is asynchronous, the extra flip flop must be present or you will get a combinational loop.

For me, it seems load of LT2 is just selecting the latch input between L and DC with L.


Not exactly. Yes, of course that at the end L selects between DC and DL. But because the way it is implemented, DL input is not fully synchronous.

When C is high (positive phase of the clock) and L is asserted as well, the following happens inside LT2 (sory for being too lazy to perform a simulation):

Bottom mux outputs DL.
Top mux outputs the output of the bottom mux (DL).
Then the D input of the latch will be NOT DL.
And because the latch is low active, latching would be enabled and the XQ output will be DL.

So the final Q output of the LT2 cell is DL. The DL input propagates to the output asynchronously, on the same cycle. This is contrary to the DC input that is fully synchronous.

This is ST GLUE logic (extracted from my code, developed from decap analysis):

Code: Select all

   logic [6:0] hsLoad;
   always_comb begin
      unique case( freq)
      2'b00:      hsLoad = 7'h01;      // 60 Hz 508 cycles
      2'b01:      hsLoad = 7'h00;      // 50 Hz 512 cycles
      2'b10,
      2'b11:      hsLoad = 7'h48;      // 70 Hz 224 cyles
      endcase
   end

   reg [6:0] hsCntr;
   wire hsReload = (& hsCntr);

   always @( posedge clk2) begin
      if( hsReload)   hsCntr <= hsLoad;
      else         hsCntr <= hsCntr + 1'b1;

   end
Fx Cast: Atari St cycle accurate fpga core

slingshot
Atari God
Atari God
Posts: 1400
Joined: Mon Aug 06, 2018 3:05 pm

Re: RAM write wait states

Postby slingshot » Wed Apr 10, 2019 12:50 pm

Interesting. It starts to blow my head off.
I've made an experiment when the load is async (the load delay flip-flop at the end of the counter chain is unchanged): the difference is that after overflow, it doesn't reset to 0, but the first value will repeat twice. So the number of steps are not changed. Also VERTCLK kicks in at the same place. Example:
Sync load:
126 127 0 73 74
async load:
126 127 73 73 74

As I see, you reset to 72. Same result at the end.

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

Re: RAM write wait states

Postby ijor » Wed Apr 10, 2019 2:45 pm

slingshot wrote:I've made an experiment when the load is async (the load delay flip-flop at the end of the counter chain is unchanged): the difference is that after overflow, it doesn't reset to 0, but the first value will repeat twice. So the number of steps are not changed.


If that's the behaviour then everything is fine. But, if I interpret LT2 schematics correctly, load is not really fully async. It is partially asynchronuos (for lack of a better term). For LOAD to be fully asynchronous, the LOAD signals would also need to reach the latch itself (as the XR signal does).

During the second phase of the clock, when C is low, the top mux ignores the output of the bottom one and outputs the DC input unconditionally. So at the next cycle, bit 0 should toggle and counting should start immediately. Again, if I'm reading this correctly.

Truth is that it's not very important. We know how many cycles it is supposed to count on each frequency. And the exact behaviour of the reload is not very important. It should not affect normal overscan. It might only be relevant for some rarely used syncscroll switches that are performed exactly when this sync counter overwraps.

As I see, you reset to 72. Same result at the end.


Yes, exactly. Just to be clear, it is not just "me". I posted code from my HDL. But the reload values I used, and the synchronous load are actually in GLUE (again, plain ST GLUE).
Fx Cast: Atari St cycle accurate fpga core

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

Re: RAM write wait states

Postby czietz » Wed Apr 10, 2019 4:20 pm

ijor wrote:Seem different standard cell technology. In one case the flops require both the inverted and the non inverted clock, in the other they don't. I don't remember for sure why one has the "ORG" prefix. Christian?


I can also only speculate for the most part. We know for certain from the dates in the drawings that 4081.ORG is older. So "ORG" could mean "original". Also looking at the -- sadly incomplete -- simulation data that I also recovered, I see that 4081.ORG is configured for a "C20" vendor cell library, while 4081 is configured for a "STYRA15" library. This indicates that your assumption about different technology might be correct. Could be 2 µm vs. 1.5 µm?

Also interesting: Dated between "4081.ORG" and "4081" there is the data in the "TXL" folder, also containing a GSTMCU design. The simulation for this references a SCX6B library. SCX6 was a family of gate arrays by National Semiconductor. Also, the numbers next to components in that schematic ("Cxxx") match the macros that were available for the SCX6 family, according to its datasheet.

Could 4081.ORG and 4081 be full-custom designs and TXL a design where Atari explorer the possibility of using a gate array?

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

Re: RAM write wait states

Postby czietz » Thu Apr 11, 2019 5:30 pm

PS: The 4081.ORG is definitively and old version, considering that it lacks the sound DMA capabilities that are present in the GSTMCU.

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

Re: RAM write wait states

Postby ijor » Sat Apr 13, 2019 1:58 pm

czietz wrote:Also interesting: Dated between "4081.ORG" and "4081" there is the data in the "TXL" folder, also containing a GSTMCU design. The simulation for this references a SCX6B library. SCX6 was a family of gate arrays by National Semiconductor. Also, the numbers next to components in that schematic ("Cxxx") match the macros that were available for the SCX6 family, according to its datasheet.


Interesting. Yes, looks like they were, at least, considering a gate array build.

The 4081.ORG is definitively and old version, considering that it lacks the sound DMA capabilities that are present in the GSTMCU.


Seems like a work in progress design. I think that we must be careful about all these schematics. We don't know for sure in any version matches the actual silicon product exactly. Seems "4081", is very close in the worst case though.
Fx Cast: Atari St cycle accurate fpga core

slingshot
Atari God
Atari God
Posts: 1400
Joined: Mon Aug 06, 2018 3:05 pm

Re: RAM write wait states

Postby slingshot » Wed Apr 24, 2019 10:18 am

Progressed a bit with my simulation. I wonder why at
https://temlib.org/AtariForumWiki/index ... hine.2C_ST
says 184 IF(71) BLANK = TRUE
but no BLANK reset.
In my sim, BLANK reset (or set if I think about BLANK is negated) always active, and set is never active when MDE1 = '1'. So basically HBLANK is always active in mono mode (I read something about this in the undocumented high-res color thread).

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

Re: RAM write wait states

Postby ijor » Wed Apr 24, 2019 1:21 pm

slingshot wrote:Progressed a bit with my simulation. I wonder why at
https://temlib.org/AtariForumWiki/index ... hine.2C_ST
says 184 IF(71) BLANK = TRUE
but no BLANK reset.
In my sim, BLANK reset (or set if I think about BLANK is negated) always active, and set is never active when MDE1 = '1'. So basically HBLANK is always active in mono mode (I read something about this in the undocumented high-res color thread).


Seems a mistake at the Wiki. Wiki's behaviour is correct for the ST, not for the STE. That's one of the differences between ST and STE.

Please note again that we don't know for sure if those STE schematics match the silicon 100%. Myself I reverse engineered the ST only. My guess is that it is mostly correct at the very least. But from the issues we commented before in this thread, I would be careful.

Also remember that the wiki was written by a programmer from a software point of view.
Fx Cast: Atari St cycle accurate fpga core

slingshot
Atari God
Atari God
Posts: 1400
Joined: Mon Aug 06, 2018 3:05 pm

Re: RAM write wait states

Postby slingshot » Wed Apr 24, 2019 2:52 pm

Yes, I should be careful, but mostly the sim seems legit (and I could make errors in it easily - those tons negations always confuse my mind).

Another strangeness (at least for me) - vsync length is only 1 line in mono mode? (in color it's 3 lines, which is perfect).

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

Re: RAM write wait states

Postby ijor » Wed Apr 24, 2019 3:54 pm

slingshot wrote: ... those tons negations always confuse my mind).


Not only yours :)

Another strangeness (at least for me) - vsync length is only 1 line in mono mode? (in color it's 3 lines, which is perfect).


Yes, that's correct.

Btw, I forgot to mention, although you probably already figured out it by yourself. The absolute numbers at the Wiki are purely conventional and for historical reasons. They don't have any direct relation to the hardware.
Fx Cast: Atari St cycle accurate fpga core

slingshot
Atari God
Atari God
Posts: 1400
Joined: Mon Aug 06, 2018 3:05 pm

Re: RAM write wait states

Postby slingshot » Wed Apr 24, 2019 4:41 pm

ijor wrote:
slingshot wrote: ... those tons negations always confuse my mind).


Not only yours :)

Good to see, I'm not alone :)
Another strangeness (at least for me) - vsync length is only 1 line in mono mode? (in color it's 3 lines, which is perfect).


Yes, that's correct.

Btw, I forgot to mention, although you probably already figured out it by yourself. The absolute numbers at the Wiki are purely conventional and for historical reasons. They don't have any direct relation to the hardware.


Of course. And it's in CPU clock units, not in the 2MHz counter clock. Also it counts from 0, when the MCU/GLUE counts from a load value to max. But as the hardware counters are not exposed, what only matters is the proper relation and event timing. However it'll be more straightforward to use the hardware values in the FPGA core.

slingshot
Atari God
Atari God
Posts: 1400
Joined: Mon Aug 06, 2018 3:05 pm

Re: RAM write wait states

Postby slingshot » Thu Apr 25, 2019 1:24 pm

Another question about hardware scroll: on STE, DE always activated 16 pixels earlier? Because on the 4081S schematic, if the scroll register set to 0, then it's delayed by 4 cycles (=16 pixels), so it'll be 80 cycles long, as supposed to be on the original ST. If scroll != 0, then DE starts 4 cycles earlier.

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

Re: RAM write wait states

Postby ijor » Thu Apr 25, 2019 7:10 pm

slingshot wrote:Another question about hardware scroll: on STE, DE always activated 16 pixels earlier? Because on the 4081S schematic, if the scroll register set to 0, then it's delayed by 4 cycles (=16 pixels), so it'll be 80 cycles long, as supposed to be on the original ST. If scroll != 0, then DE starts 4 cycles earlier.


I'm not an expert on the STE ...

But as far as I understand, yes, DE starts 4 cycles earlier when scroll is enabled. And if you think about it, there is no other way that it could work. When you scroll you combine the current and the previous word, so you need two words of data when the displays starts.
Fx Cast: Atari St cycle accurate fpga core

slingshot
Atari God
Atari God
Posts: 1400
Joined: Mon Aug 06, 2018 3:05 pm

Re: RAM write wait states

Postby slingshot » Thu Apr 25, 2019 9:02 pm

I see. Meanwhile I've finished with the sync, blank and DE generators, uploaded there:
https://github.com/gyurco/gstmcu
I couldn't upload the waveform output, because it's 10MB zipped. But it's easy to run if Verilator is already installed. Just make, and run ./gstmcu (it'll generate about a dozen frames of data with various display modes). Then it's possible to investigate the resulting VCD file in gtkwave for counters, the internal signals, and so on. Just have to make a synthesizable code now from it.

slingshot
Atari God
Atari God
Posts: 1400
Joined: Mon Aug 06, 2018 3:05 pm

Re: RAM write wait states

Postby slingshot » Mon Apr 29, 2019 12:13 pm

I'm currently struggling with the clock generators: expected waveforms are at the end of ST4081S.PDF.
The easiest case: MHZ16 (the input clock) should be in phase with MHZ8.
But in page7, both the divider flip-flop (P7019) and the latch gating it (P7008) operates on negative clock. How the hell can they be in sync then?
I tried to model this as:

Code: Select all

mhz8 = ~clk ? lp7019 : mhz8
always @(negedge clk)
   lp7019 <= ~lp7019
end

And mhz8 is shifted by 180 degrees to clk16 in the simulation, as I expect "running in head". Actually I don't understand the purpose of the second gating latch.
Anyone can shed the light?

Upd.: found it, this negation of negation made me stupid again. The second gating is active at the positive period of clk.

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

Re: RAM write wait states

Postby ijor » Mon Apr 29, 2019 5:25 pm

slingshot wrote:I'm currently struggling with the clock generators: expected waveforms are at the end of ST4081S.PDF.
...
Actually I don't understand the purpose of the second gating latch.


The flip-flop latch combination is probably an attempt to reduce clock skew. Not sure how well this actually works in practice, I haven't seen many STE traces. On the STF this depends a lot on the particular chipset version.

Code: Select all

mhz8 = ~clk ? lp7019 : mhz8
always @(negedge clk)
   lp7019 <= ~lp7019
end


You are trying to infer a latch indirectly from a combinational loop. I think it is better to model a proper latch:

Code: Select all

always @( clk)
      if( clk)
         mhz8 <= lp7019;
Fx Cast: Atari St cycle accurate fpga core

slingshot
Atari God
Atari God
Posts: 1400
Joined: Mon Aug 06, 2018 3:05 pm

Re: RAM write wait states

Postby slingshot » Tue Apr 30, 2019 6:30 am

Yes, of course, it'll be a latch. I think how to express it is personal taste :) It's ugly anyway, and unusable for FPGA, but I don't want to make this simulation model to run in an real device, not just because of the latches, but the tons of clocks in it.
First I want to fully understand how the whole thing works with perfect timings, then I'll convert it to "proper" code.
As I see, these latches are used to shift the signal by half a clock. Maybe you're right, and gives better signal than just one flip-flop at the other edge.

slingshot
Atari God
Atari God
Posts: 1400
Joined: Mon Aug 06, 2018 3:05 pm

Re: RAM write wait states

Postby slingshot » Wed May 08, 2019 11:22 am

Video address generator in action:

gstmcu.png


It's a bit crazy how many phases they're using. I wonder if it was due to planning, or just tossed the signals left and right until everything worked.
You do not have the required permissions to view the files attached to this post.

slingshot
Atari God
Atari God
Posts: 1400
Joined: Mon Aug 06, 2018 3:05 pm

Re: RAM write wait states

Postby slingshot » Thu May 09, 2019 11:59 am

There's one thing I cannot make work: the horizontal offset register. It supposed to add a fixed number of words to the video address counter after each line. However I don't understand how the cells used here can do it correctly:
rlc3.png

Here's 'R' goes high after the line end, effectively closing MBC04 latch, which will sent to the output later on. The MBC04 latch's output is AI^DR^Q, where AI comes from the previous cell, as a carry, DR is the appropriate bit from the horizontal offset register, Q is the existing output. So Q will be AI+DR+Q effectively. That's OK. However AO should create a carry to the next level, but it will be '1' only if all three input to the adder is '1' (AND). But it doesn't work as I expect, to provide a proper carry, it should be '1' when two '1's are present in the input. Anyone has an idea where am I in error? The simulation shows this issue, e.g. after an address of 0000A8, and a horizontal offset value of 0F, the resulting next address should be 0000A8+2*0F = C6. With the current cell config, it's 0000B6.
Using

Code: Select all

assign ao = (dr & q) | (dr & ai) | (q & ai);

brings the expected address shift.
You do not have the required permissions to view the files attached to this post.


Social Media

     

Return to “Hardware”

Who is online

Users browsing this forum: No registered users and 10 guests