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

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

RAM write wait states

Postby slingshot » Sat Mar 30, 2019 4:00 pm

Hi!

Anyone knows the exact number of wait states the GLUE applies for _writes_?
I know, the write data is latched ASAP (when exactly? At the first write cycle, when ASn and RWn goes low, or in the second, where UDSn and/or LDSn, too?), then when DTACKn is issued?
I mean, if the write cycle starts exactly at the start of the CPU memory cycle, then without wait states, a new CPU cycle could begin even if the data is not yet written, so the GLUE shouldn't assert DTACKn immediately after detecting the write. But if the CPU write cycle start at a shifter RAM cycle, then the data could be written to RAM without inserting any wait states.

So if I divide the full memory cycle (CPU + Shifter) to 4 8 MHz CPU cycles, I'd like to fill this table:

Code: Select all

RAM cycle    Wait states for ram write, if the CPU write cycle started here

0. CPU  - (2?)
1. CPU  - (1?)
2. Shifter - (0?)
3. Shifter - (0?)

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

Re: RAM write wait states

Postby ijor » Sun Mar 31, 2019 7:38 pm

slingshot wrote:Anyone knows the exact number of wait states the GLUE applies for _writes_?


Probably just for the record, it is not GLUE, it is MMU. I assume your question is related to the MiST core, so you probably don't care too much if it is GLUE or MMU.

Wait states for write and read RAM cycles are identical.

I know, the write data is latched ASAP (when exactly? At the first write cycle, when ASn and RWn goes low, or in the second, where UDSn and/or LDSn, too?), then when DTACKn is issued?
...
So if I divide the full memory cycle (CPU + Shifter) to 4 8 MHz CPU cycles, I'd like to fill this table:


RAM access is interleaved between CPU and Video cycles. Or more precisely, between cycles internals to the SHIFTER-RAM bus, and external cycles. Internal cycles are not only video load cycles but also ram refresh and, for the STe, sound DMA. External cycles, besides CPU, are DMA and Blitter cycles.

The exact phasing of this interleave is not so simple and can't easily be described in words. There are buffers and latches between the CPU and RAM. A waveform is needed if you really need to see the whole details. But again, for the MiST core you probably don't care. What you need to know is the following:

MMU assigns specific slots for each 4 8MHz cycles. A CPU cycle must start at the specific slot that it was assigned. Otherwise MMU inserts wait states forcing the CPU bus cycle to align to the slot. So, if you start counting 8MHz cycles from power up, CPU cycles must start at any cycle that is an exact multiple of 4, otherwise wait states would be inserted. The number of wait states would be one, two, or three cycles such as to force the ram access to start in the next 4 cycles boundary.

Read and write cycles are identical regarding the alignment and number of wait states.
Fx Cast: Atari St cycle accurate fpga core

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

Re: RAM write wait states

Postby slingshot » Sun Mar 31, 2019 9:00 pm

ijor wrote:.
.
.


Sorry, you're right, it's about MMU.
Yes, you guessed it, it's for the MiST core. I'm in a process to change of the TG68K CPU to your FX68K. So 3 wait states are normal, that was what I wanted to know. Something is a bit slow after the CPU change, since there are titles which don't work with the normal 8MHz clock, only with 16MHz (and worked with TG68k). I can make write cycles to a maximum of 2 wait states with a bit of hacking, but also didn't help. However Spectrum512 images are stable. I assume the fact that DMA and Blitter don't use the CPU's bus arbitration doesn't make a difference in these cases.
And then another thing: ROM read is always 0 wait states? Since it's directly connected to the CPU bus.

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

Re: RAM write wait states

Postby ijor » Mon Apr 01, 2019 12:45 pm

slingshot wrote:So 3 wait states are normal, that was what I wanted to know.


I would say 3 wait states are possible, may be normal if you want to use that term, but extremely uncommon. This is because the CPU works with a two cycles accuracy. So normally you would get two, or zero, wait states. One or three wait states would happen rarely.

Something is a bit slow after the CPU change, since there are titles which don't work with the normal 8MHz clock, only with 16MHz (and worked with TG68k)... However Spectrum512 images are stable. I assume the fact that DMA and Blitter don't use the CPU's bus arbitration doesn't make a difference in these cases.


Hard to tell what is going on. But if Spectrum 512 images are displayed ok (not just stable, but correctly), then timing should be accurate.

Wrong DMA implementation would affect cycle accuracy, of course. But most of the time it is not critical. Unlikely that this is the problem.

And then another thing: ROM read is always 0 wait states? Since it's directly connected to the CPU bus.


Correct, ROM access, including to the cartridge space, has no wait states. Note that most I/O chips do get wait states, even when connected directly to the CPU bus.
Fx Cast: Atari St cycle accurate fpga core

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

Re: RAM write wait states

Postby slingshot » Mon Apr 01, 2019 1:02 pm

ijor wrote:
slingshot wrote:So 3 wait states are normal, that was what I wanted to know.


I would say 3 wait states are possible, may be normal if you want to use that term, but extremely uncommon. This is because the CPU works with a two cycles accuracy. So normally you would get two, or zero, wait states. One or three wait states would happen rarely.

I could capture all the 4 wait states via SignalTap II - it doesn't give the probability of them of course.
Something is a bit slow after the CPU change, since there are titles which don't work with the normal 8MHz clock, only with 16MHz (and worked with TG68k)... However Spectrum512 images are stable. I assume the fact that DMA and Blitter don't use the CPU's bus arbitration doesn't make a difference in these cases.


Hard to tell what is going on. But if Spectrum 512 images are displayed ok (not just stable, but correctly), then timing should be accurate.

Wrong DMA implementation would affect cycle accuracy, of course. But most of the time it is not critical. Unlikely that this is the problem.

Some vertical line artifacts are present in them. I wonder if it's because of the CPU or shifter.
And then another thing: ROM read is always 0 wait states? Since it's directly connected to the CPU bus.


Correct, ROM access, including to the cartridge space, has no wait states. Note that most I/O chips do get wait states, even when connected directly to the CPU bus.


Always 0 for ROM is not very possible currently, since it's in the SDRAM, but 0 or 1 is done. Is there any info about the IO wait states? I could imagine the MFP will have quite a lot sometimes, since the 4 MHz clock, and 2 clock 'till it issues DTACK (in the datasheet), but shifter for example?

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

Re: RAM write wait states

Postby ijor » Mon Apr 01, 2019 3:22 pm

slingshot wrote:I could capture all the 4 wait states via SignalTap II - it doesn't give the probability of them of course.


You should see 0 or 2 wait states on almost every case. The only exceptions should be the very first access after reset, and after another access that in turn provoked an odd number of wait states (see below for one example).

Some vertical line artifacts are present in them. I wonder if it's because of the CPU or shifter.


It might be Shifter. You might need to add some pipeline cycles between shifting video data and addressing the RGB palette.

Always 0 for ROM is not very possible currently, since it's in the SDRAM, but 0 or 1 is done.


I see. I wonder if this is not related to the CPU seeming to be a bit slow.

Is there any info about the IO wait states? I could imagine the MFP will have quite a lot sometimes, since the 4 MHz clock, and 2 clock 'till it issues DTACK (in the datasheet), but shifter for example?


There is no simple, fully comprehensive available table that I am aware. From memory for plain ST (not so sure about the extra STE I/O chips) it should be something like this:

- Sound chip: One cycle. That in turn could provoke an odd number of wait states on a subsequent RAM access.
- MFP: It is a bit complex because there is a subtle interaction between both clocks. A very good approximation is 4 cycles.
- ACIA's: GLUE should assert VPA instead of DTACK and then the CPU would add a delay internally.
- FDC and DMA chip: Quite complex but not very important. Never seen a program that depends on this being accurate.
- Shifter: Exactly the same as a RAM access

Everything else has 0 wait states (unless I forgot something).
Fx Cast: Atari St cycle accurate fpga core

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

Re: RAM write wait states

Postby slingshot » Mon Apr 01, 2019 3:46 pm

ijor wrote:You should see 0 or 2 wait states on almost every case. The only exceptions should be the very first access after reset, and after another access that in turn provoked an odd number of wait states (see below for one example).

Will investigate it a bit more then...However it must be something else because the number of wait states are tightly coupled when the CPU started the cycle, no random factor in it.

Some vertical line artifacts are present in them. I wonder if it's because of the CPU or shifter.


It might be Shifter. You might need to add some pipeline cycles between shifting video data and addressing the RGB palette.

Yepp, have to dig into shifter. It's the original from Till, and it works very well.

Always 0 for ROM is not very possible currently, since it's in the SDRAM, but 0 or 1 is done.


I see. I wonder if this is not related to the CPU seeming to be a bit slow.

Well, not in the cases I've examined. But seems there's a common factor - STE DMA sound. However it doesn't steal cycles from the CPU.

- Sound chip: One cycle. That in turn could provoke an odd number of wait states on a subsequent RAM access.
- MFP: It is a bit complex because there is a subtle interaction between both clocks. A very good approximation is 4 cycles.
- ACIA's: GLUE should assert VPA instead of DTACK and then the CPU would add a delay internally.
- FDC and DMA chip: Quite complex but not very important. Never seen a program that depends on this being accurate.
- Shifter: Exactly the same as a RAM access

Everything else has 0 wait states (unless I forgot something).


Thanks, good to know. Currently it's not like this. So the CPU register interface of the shifter has the same delay as the 68000 accesses the RAM? E.g. is it only available at its RAM access slots? I guess it would be important for color palette.

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

Re: RAM write wait states

Postby ijor » Mon Apr 01, 2019 8:20 pm

slingshot wrote:
ijor wrote:You should see 0 or 2 wait states on almost every case. The only exceptions should be the very first access after reset, and after another access that in turn provoked an odd number of wait states (see below for one example).

Will investigate it a bit more then...However it must be something else because the number of wait states are tightly coupled when the CPU started the cycle, no random factor in it.


We might have a misunderstanding here. There is nothing random here, except again at power up and reset, and you don't have to "emulate" that non deterministic reset behavior.

Otherwise, and as you are saying, the number of wait states is a direct consequence of the alignment between the MMU slots and the cycle that the CPU starts the bus access.

Well, not in the cases I've examined. But seems there's a common factor - STE DMA sound. However it doesn't steal cycles from the CPU.


Strange. STE sound DMA, indeed, should not steal any CPU cycles no matter what. But might be for some reason it does steal cycles on the MiST core.

So the CPU register interface of the shifter has the same delay as the 68000 accesses the RAM? E.g. is it only available at its RAM access slots? I guess it would be important for color palette.


Yes. SHIFTER data bus is connected to the RAM bus, through the same latches and buffers. MMU then considers a SHIFTER access to be the same as a RAM access, in this regard. It can only happen on the same slot assigned to RAM access. It is for accessing the palette registers and the resolution register as well.
Fx Cast: Atari St cycle accurate fpga core

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

Re: RAM write wait states

Postby slingshot » Mon Apr 01, 2019 8:59 pm

ijor wrote:Otherwise, and as you are saying, the number of wait states is a direct consequence of the alignment between the MMU slots and the cycle that the CPU starts the bus access.

I think we agree on this.

Well, not in the cases I've examined. But seems there's a common factor - STE DMA sound. However it doesn't steal cycles from the CPU.


Strange. STE sound DMA, indeed, should not steal any CPU cycles no matter what. But might be for some reason it does steal cycles on the MiST core.

I'm sure it doesn't steal from CPU, since the code doesn't allow it. But maybe interrupts or whatever...hope I can sort it out.
So the CPU register interface of the shifter has the same delay as the 68000 accesses the RAM? E.g. is it only available at its RAM access slots? I guess it would be important for color palette.


Yes. SHIFTER data bus is connected to the RAM bus, through the same latches and buffers. MMU then considers a SHIFTER access to be the same as a RAM access, in this regard. It can only happen on the same slot assigned to RAM access. It is for accessing the palette registers and the resolution register as well.

Ah, that's a valuable information, currently shifter is accessed with 0 delay.

Great informations from you, thanks again, I'll try to implement this knowledge.

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

Re: RAM write wait states

Postby slingshot » Thu Apr 04, 2019 1:31 pm

I was able to implement the correct memory wait state, and this made me wonder about the 250ns CPU RAM cycle.
If a CPU does a read at the start of this time slot, then a following write can only happen at the second half of the RAM cycle (since the CPU sets up a read in 1 cycle, but a write in 2). How can a -15 DRAM process this, which has a minimum of random read or write cycle time of 250ns? Maybe it starts with asserting RAS as soon as it sees ASn and RWn, but finish with CASOH and CASOL only according to UDSn and LDSn?

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

Re: RAM write wait states

Postby ijor » Thu Apr 04, 2019 4:57 pm

Actual RAM chips access is performed exactly at the same cycle regardless if it is a read or a write cycle. A CPU read cycle can't be performed too early because at that point RAM would be still be busy at the "other" slot (Video, STe Sound DMA, or ram refresh).

For a CPU slot, RAS is always pulsed at S4, and CAS at S5. This is regardless of the bus cycle being a read or a write. The timing of the TTL buffers that connects both buses does is slightly different between a read and a write.
Fx Cast: Atari St cycle accurate fpga core

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

Re: RAM write wait states

Postby slingshot » Thu Apr 04, 2019 5:15 pm

Make sense. I assumed at S4 there must be valid data already available for a read, as DTACKn has to be asserted for a 0 wait state cycle.

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

Re: RAM write wait states

Postby ijor » Thu Apr 04, 2019 5:57 pm

slingshot wrote:Make sense. I assumed at S4 there must be valid data already available for a read, as DTACKn has to be asserted for a 0 wait state cycle.


MMU asserts DTACK even earlier. But the CPU doesn't require data to be actually ready as soon as DTACK is asserted. The CPU latches the data at the end of the bus cycle, long after DTACK was detected.
Fx Cast: Atari St cycle accurate fpga core

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

Re: RAM write wait states

Postby slingshot » Sun Apr 07, 2019 1:09 pm

ijor wrote:MMU asserts DTACK even earlier. But the CPU doesn't require data to be actually ready as soon as DTACK is asserted. The CPU latches the data at the end of the bus cycle, long after DTACK was detected.


Don't want to open another thread, and would like to ask: is there any public info available about the counters in GLUE? Especially the horizontal ones, e.g. when vertical counter is progressing and so on. I could deduce the vertical ones somewhat from demos (so top and bottom border open effects are working), but the horizonal ones are more tough.

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

Re: RAM write wait states

Postby czietz » Sun Apr 07, 2019 1:50 pm

The schematic of the STE GSTMCU (combining GLUE and MCU) is available: https://www.chzsoft.de/asic-web/ (scroll down for the download).

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

Re: RAM write wait states

Postby slingshot » Sun Apr 07, 2019 3:29 pm

czietz wrote:The schematic of the STE GSTMCU (combining GLUE and MCU) is available: https://www.chzsoft.de/asic-web/ (scroll down for the download).

Thanks! I guess it couldn't be more authentic source for information.

I started to process these schematics, I wonder why they have two counters/H/V - one for sync, one for DE. And the DE counters are reset by sync.

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

Re: RAM write wait states

Postby ijor » Mon Apr 08, 2019 1:00 am

slingshot wrote:Thanks! I guess it couldn't be more authentic source for information.


I'm not sure studying the schematics is the best starting point. Yes, it is probably the most authoritative source. But it will probably be quite difficult to follow and understand, let alone extract the necessary timing information, without being familiar with the architecture. Also note that those schematics are for the STE chip. The logic and then the timing is slightly different than the ST (not STE) version of GLUE.

I would recommend checking other sources. For example see Troed's wiki article about GLUE's state machine. Note that the article is written from a software programmer point of view:

https://temlib.org/AtariForumWiki/index ... _Scanlines

I started to process these schematics, I wonder why they have two counters/H/V - one for sync, one for DE. And the DE counters are reset by sync.


The ST can be configured to use external sync, and then the designer probably decided that Sync and DE/BLANK should be separate processes. They both still need to synchronized somehow because DE and BLANK must always be aligned with SYNC.
Fx Cast: Atari St cycle accurate fpga core

tzok
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 121
Joined: Fri Jun 30, 2017 7:22 pm
Location: Bielsko-Biala, PL
Contact:

Re: RAM write wait states

Postby tzok » Mon Apr 08, 2019 6:03 am

ijor wrote:I'm not sure studying the schematics is the best starting point. Yes, it is probably the most authoritative source. But it will probably be quite difficult to follow and understand, let alone extract the necessary timing information, without being familiar with the architecture.
I don't want to be malicious, but observing a sky in the antique ages led to creating an overcomplicated... geocentric model ;) Don't follow that mistake. If you have the source - analyze it; don't relay on observing only effects if you can access to the mechanism behind them.

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

Re: RAM write wait states

Postby slingshot » Mon Apr 08, 2019 10:34 am

ijor wrote:I would recommend checking other sources. For example see Troed's wiki article about GLUE's state machine. Note that the article is written from a software programmer point of view:

https://temlib.org/AtariForumWiki/index ... _Scanlines


Thanks! It's more human-consumable for sure. But I've started to make some experiments with the schematic. I made a Verilog model of the HSync generator, and simulating it in Verilator. And started to wonder if the schematics are valid. The counter is easy, after you understood those blocks: it's a 7 bit binary counter, clocked by 2MHz clock, and when it overflows, it reloads itself into a pre-defined value. However there's the problem:
MDE1 = 0 NTSC = 0: reload to 53
MDE1 = 0 NTSC = 1: reload to 54
but when MDE1=1, it always reloads itself to 125. Then goes to 126, 127, reload, and so on. Seems not legit for the Mono mode. Also the others are strange.

In the case of MDE1, NTSC=0, the D pins of the blocks gets the values [6:0] = 1111101
D6 = MDE1 or INTERLACE (1)
D5,4,2 = 1 (VSS)
D3 = MDE1 (1)

I must misunderstood something, or this circuit won't work (examined the 4081/, not 4081.ORG/)

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

Re: RAM write wait states

Postby czietz » Mon Apr 08, 2019 11:00 am

Note that Vss is ground = 0, not 1.

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

Re: RAM write wait states

Postby slingshot » Mon Apr 08, 2019 11:21 am

czietz wrote:Note that Vss is ground = 0, not 1.

With 0, it's much better!
PAL - 1-127 = 508 CPU clocks
NTSC - 2-127 = 504 CPU clocks
Mono - 73-127 = 220 CPU clocks

Somewhere 1 clock is lost (+4 cpu cycles).

Upd.: assumed the LT2 module changes its output on falling edge. But using rising edge will allow the counter output to 0 after 127, then pre-loaded. Still wondering why, since the latch in LT2 gets inverted clock in its gate. However I must change the implementation from circular logic to "normal" register, because Verilator complained about it cannot converge and such. So maybe using only posedge is OK. At least it gives the numbers.

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

Re: RAM write wait states

Postby ijor » Mon Apr 08, 2019 12:32 pm

slingshot wrote:D6 = MDE1 or INTERLACE (1)


Note that the interlace logic has a bug and interlace is always disabled. See this thread for more details:
http://www.atari-forum.com/viewtopic.php?f=15&t=30303

Upd.: assumed the LT2 module changes its output on falling edge. But using rising edge will allow the counter output to 0 after 127, then pre-loaded. Still wondering why, since the latch in LT2 gets inverted clock in its gate. However I must change the implementation from circular logic to "normal" register, because Verilator complained about it cannot converge and such. So maybe using only posedge is OK. At least it gives the numbers.


All the counter bits change on the same edge of the clock. The cells for the other bits, CB1 and CBN, in turn have an LT2 cell inside.
Fx Cast: Atari St cycle accurate fpga core

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

Re: RAM write wait states

Postby ijor » Mon Apr 08, 2019 12:40 pm

Bolding is mine:

tzok wrote:I don't want to be malicious, but observing a sky in the antique ages led to creating an overcomplicated... geocentric model ;) Don't follow that mistake. If you have the source - analyze it; don't relay on observing only effects if you can access to the mechanism behind them.


Of course that the source should be analyzed. You don't have to tell that to me. I spent an insane amount of time, and even quite some money, producing reverse engineered schematics from actual chip micro photographies. I didn't say to relay ONLY on the effects. But, IMHO, it is not wise to not be familiar with the "effects" beforehand.
Fx Cast: Atari St cycle accurate fpga core

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

Re: RAM write wait states

Postby slingshot » Mon Apr 08, 2019 1:09 pm

ijor wrote:Note that the interlace logic has a bug and interlace is always disabled. See this thread for more details:
viewtopic.php?f=15&t=30303

I'm running the simulations with interlace = 0 currently. Is it always 1?



All the counter bits change on the same edge of the clock. The cells for the other bits, CB1 and CBN, in turn have an LT2 cell inside.


Yepp, just all was running on negedge, but the latch holding the load signal (PQ029) operated on positive edge. And it missed the "0" HSC state. Another interesting thing, if I'm right: reset is really reset, it sets the counter outputs to "0", also the load is "0". So the first line after rest always 0-127, in every mode.

My final results of the simulation:
PAL color - 0-127, HSync at 102
NTSC color - 0, 2-127, Hsync at 102
Mono - 0, 73-127, Hsync at 122
Vertclk is always at 0 (when the vertical sync counter gets its clock).

DE counter is simpler, it doesn't have preload, just gets a reset from hsync (however it's clocked by the inverse of the hsync clock).

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

Re: RAM write wait states

Postby ijor » Mon Apr 08, 2019 2:02 pm

slingshot wrote:I'm running the simulations with interlace = 0 currently. Is it always 1?


I'm never 100% sure, just from memory, about the polarity of the signals without double checking. But usually it is trivial to find out the correct polarity under simulation :)

Another interesting thing, if I'm right: reset is really reset, it sets the counter outputs to "0", also the load is "0". So the first line after rest always 0-127, in every mode.


The sync counters keep running on reset. That reset signal, RESBL, is asserted at power up only, and the power up logic is not very reliable. The counter start value is really not fully deterministic.
Fx Cast: Atari St cycle accurate fpga core


Social Media

     

Return to “Hardware”

Who is online

Users browsing this forum: No registered users and 4 guests