SHIFTER reimplementation on FPGA

GFA, ASM, STOS, ...

Moderators: simonsunnyboy, Mug UK, Zorro 2, Moderator Team

User avatar
Smonson
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 125
Joined: Sat Feb 20, 2016 9:45 am
Location: Canberra
Contact:

Re: SHIFTER reimplementation on FPGA

Postby Smonson » Mon Aug 06, 2018 10:01 am


mlynn1974
Captain Atari
Captain Atari
Posts: 210
Joined: Mon Mar 03, 2008 10:33 pm
Contact:

Re: SHIFTER reimplementation on FPGA

Postby mlynn1974 » Mon Aug 06, 2018 8:20 pm

Hi Smonson,
On this forum we have seen a number of STs over the years with Shifter chips that have failed. I don't know why chips like that fail over time - can semiconductor junctions fail? What causes that? Since the Shifter is a custom chip do you think an FPGA version would be available for general use soon? How many gates are required?

Over the years I have personally seen 2 sets of approximately 10 years old Samsung and Lenovo DDR memory chips fail, a C64 VIC chip fail and a Philips 7179 chip fail in a Rombo video digitizer. STs lasting 30 years without major component failure is actually really impressive.
Still got, still working: Atari 4Mb STe, 520STFM, 2.5Mb STF.
Hardware: Cumana CSA 354, Ultimate Ripper, Blitz Turbo, Synchro Express II (US and UK Versions).

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

Re: SHIFTER reimplementation on FPGA

Postby ijor » Mon Aug 06, 2018 9:17 pm

Smonson wrote:I will soon (it's midnight here) but it's definitely working at 50 and broken at 60. Maybe they released different versions of the program, or someone modified the copy I have...Here's the disk:


Indeed, this version is the other way around than the one I know, that works correctly only on 60Hz. Interesting that instead of releasing a universal fix that would work on both frequencies, they released a 50 Hz "only" version.

User avatar
Smonson
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 125
Joined: Sat Feb 20, 2016 9:45 am
Location: Canberra
Contact:

Re: SHIFTER reimplementation on FPGA

Postby Smonson » Mon Aug 06, 2018 11:24 pm

mlynn1974 wrote:Hi Smonson,
On this forum we have seen a number of STs over the years with Shifter chips that have failed. I don't know why chips like that fail over time - can semiconductor junctions fail? What causes that? Since the Shifter is a custom chip do you think an FPGA version would be available for general use soon? How many gates are required?


Not a lot of gates, I don't remember the exact number, but I tried compiling it for one of the smaller MAX V CPLDs and it fit easily. You could probably make a drop-in replacement at low cost. They work at 5v so I guess it'd just be the CPLD, a 32MHz oscillator, and a two rows of pins on a PCB.

Alternatively, a shifterless machine could install the HDMI out mod which is under development, which would make the original video out socket unusable, but allow a modern TV or LCD monitor to be connected instead. That's going to be a considerably more expensive option when it becomes available.

User avatar
Smonson
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 125
Joined: Sat Feb 20, 2016 9:45 am
Location: Canberra
Contact:

Re: SHIFTER reimplementation on FPGA

Postby Smonson » Mon Aug 06, 2018 11:25 pm

ijor wrote:
Smonson wrote:I will soon (it's midnight here) but it's definitely working at 50 and broken at 60. Maybe they released different versions of the program, or someone modified the copy I have...Here's the disk:


Indeed, this version is the other way around than the one I know, that works correctly only on 60Hz. Interesting that instead of releasing a universal fix that would work on both frequencies, they released a 50 Hz "only" version.


If I can find a copy of the 60Hz version somewhere, I'll download a copy and see if there are any timing discrepancies.

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

Re: SHIFTER reimplementation on FPGA

Postby ijor » Tue Aug 07, 2018 9:42 pm

Smonson wrote:If I can find a copy of the 60Hz version somewhere, I'll download a copy and see if there are any timing discrepancies.


I can send you an image if you want. But this is really not related to SHIFTER. It is just that the code assumes a fixed scan line length, 508 or 512 cycles in each case, when keeping sync with the video display. That's why you get that "slanted" diagonal distortion. Each scan line it gets another 4 cycles off.

In general terms, Spectrum 512 doesn't perform any overscan effects or resolution changes. So as far as the main load and reload SHIFTER logic, it behaves as standard display.

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

Re: SHIFTER reimplementation on FPGA

Postby ijor » Tue Aug 07, 2018 9:45 pm

Smonson wrote: ... but I tried compiling it for one of the smaller MAX V CPLDs and it fit easily. You could probably make a drop-in replacement at low cost. They work at 5v ...


Are you sure the MAX V family is 5V tolerant?

rpineau
Atari Super Hero
Atari Super Hero
Posts: 511
Joined: Wed Jun 29, 2011 6:39 am
Location: California / USA
Contact:

Re: SHIFTER reimplementation on FPGA

Postby rpineau » Tue Aug 07, 2018 10:01 pm

MAX V 5M1270Z and 5M2210Z are 5V tolerant : https://www.intel.com/content/dam/www/p ... -table.pdf
Falcon + AB040 + Eclipse PCI + ATI Rage VGA card + NE2000 Ethernec + HxC Floppy Emulator
MegaSTE 4MB + CosmosEx / 1040 STF for hardware dev
http://www.rti-zone.org/atari.php

User avatar
Smonson
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 125
Joined: Sat Feb 20, 2016 9:45 am
Location: Canberra
Contact:

Re: SHIFTER reimplementation on FPGA

Postby Smonson » Tue Aug 07, 2018 10:53 pm

ijor wrote:Are you sure the MAX V family is 5V tolerant?


Ah, you guys are right, only a couple of the huge ones are. Just pick basically any small 5v device. Off the top of my head I think 35 IOs are needed, plus a clock input.

One that would physically fit inside the PDIP-40 outline would be ideal.

User avatar
Smonson
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 125
Joined: Sat Feb 20, 2016 9:45 am
Location: Canberra
Contact:

Re: SHIFTER reimplementation on FPGA

Postby Smonson » Tue Aug 07, 2018 10:59 pm

ijor wrote:I can send you an image if you want. But this is really not related to SHIFTER. It is just that the code assumes a fixed scan line length, 508 or 512 cycles in each case, when keeping sync with the video display. That's why you get that "slanted" diagonal distortion. Each scan line it gets another 4 cycles off.

In general terms, Spectrum 512 doesn't perform any overscan effects or resolution changes. So as far as the main load and reload SHIFTER logic, it behaves as standard display.


I mean a test of the FPGA model shifter to confirm that the palette writes are synchronised to the pixel that they're intended to affect. I have seen some corruption also in 50Hz mode, I assume it's wakeup state related. I haven't confirmed whether the same corruption happens on a physical shifter, yet. But it's definitely caused by the timing of palette writes coming one pixel too early or late.

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

Re: SHIFTER reimplementation on FPGA

Postby ijor » Wed Aug 08, 2018 3:09 am

rpineau wrote:MAX V 5M1270Z and 5M2210Z are 5V tolerant :...


Interesting, I didn't know. But note that they aren't really 5V tolerant, they are PCI compliant, which is not exactly the same thing. Among other things, they still need some minimal external logic for operating at 5V. And one I/O bank only, out of four, is PCI compliant. So depending on the application you might end wasting most of the I/O pins that you won't be able to use because they are not 5V tolerant.

User avatar
Smonson
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 125
Joined: Sat Feb 20, 2016 9:45 am
Location: Canberra
Contact:

Re: SHIFTER reimplementation on FPGA

Postby Smonson » Wed Aug 08, 2018 3:24 am

How about MAX 7000 EPM7064
- TQFP-44
- 5v operation
- 36 user IOs
- 175MHz max
- 64 macrocells / 1250 gates

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

Re: SHIFTER reimplementation on FPGA

Postby ijor » Wed Aug 08, 2018 3:25 am

Smonson wrote:I mean a test of the FPGA model shifter to confirm that the palette writes are synchronised to the pixel that they're intended to affect. I have seen some corruption also in 50Hz mode, I assume it's wakeup state related. I haven't confirmed whether the same corruption happens on a physical shifter, yet. But it's definitely caused by the timing of palette writes coming one pixel too early or late.


I will send you the "60 Hz" version. But I doubt the timing of the actual palette register writing is any different.

The corruption you see is constant, or it changes across power up cycles? If it's constant then it is probably a wrong pipeline in your model. Otherwise it is indeed probably related to the wakeup. Not to the GLUE wakeup, but to the SHIFTER wakeup. GLUE wakeup shouldn't matter, at least not in Spectrum 512, although it might be relevant in some demos. You probably can control the SHIFTER wakeup, it might be worth implementing.

But again, you must compare with a real SHIFTER. Some demos do have problems with a real SHIFTER depending on the wakeup. So your implementation is not necessarily wrong.

User avatar
Smonson
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 125
Joined: Sat Feb 20, 2016 9:45 am
Location: Canberra
Contact:

Re: SHIFTER reimplementation on FPGA

Postby Smonson » Wed Aug 08, 2018 3:37 am

ijor wrote:But again, you must compare with a real SHIFTER. Some demos do have problems with a real SHIFTER depending on the wakeup. So your implementation is not necessarily wrong.


Yeah, I don't think there's a problem with the model, but I like to rule it out. I have no way of seeing which wake-up state the machine is in when using a real shifter which makes it hard to test.

The corruption in Spectrum 512 is fixed dots of the wrong colour, especially visible in the palette display. They show up in columns, aligned with where the palette writes are occurring.

What's the theoretical problem with the shifter wake-up? Is that when the pixel clock is aligned with the wrong edge of the 16MHz clock? I don't think it'll be a problem.

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

Re: SHIFTER reimplementation on FPGA

Postby ijor » Wed Aug 08, 2018 4:04 am

Smonson wrote:I have no way of seeing which wake-up state the machine is in when using a real shifter which makes it hard to test.


You can measure the wakeup with a Logic Analyzer as I described in the other thread. It is also possible to "visualize" (more or less) the wakeup with a screen that mixes low and med rez.

The corruption in Spectrum 512 is fixed dots of the wrong colour, especially visible in the palette display. They show up in columns, aligned with where the palette writes are occurring.


But always on every power up cycle?

What's the theoretical problem with the shifter wake-up? Is that when the pixel clock is aligned with the wrong edge of the 16MHz clock? I don't think it'll be a problem.


Not with the 16 MHz clock, not in your case, but with the 8 MHz clock. You don't get the 8 MHz clock directly, but all the control and address signals are aligned with it. It is not that it is a "problem", it is that the relation between LOAD, CS and the low rez pixel clock is changed. This is critical in a real SHIFTER because writes to the palette aren't synchronized with the clock.

A real SHIFTER has two extra wakeup states that do depend on the relation between the low rez pixel clock and the 16 MHz clock (actually the med rez pixel clock, but both are always aligned). That shouldn't happen in your case as long as you perform proper power up reset.

User avatar
Smonson
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 125
Joined: Sat Feb 20, 2016 9:45 am
Location: Canberra
Contact:

Re: SHIFTER reimplementation on FPGA

Postby Smonson » Wed Aug 08, 2018 4:22 am

ijor wrote:You can measure the wakeup with a Logic Analyzer as I described in the other thread. It is also possible to "visualize" (more or less) the wakeup with a screen that mixes low and med rez.

I don't have a logic analyser, so I can't measure it. I have a scope, but that's a pretty unwieldy solution if it has to be measured repeatedly. It's probably not worth the effort actually - unless further information comes to hand that suggests there's a problem that needs to be solved.

But always on every power up cycle?

I haven't extensively investigated it yet - I've only recently observed a known working build become non-working after being powered off for a while.

Not with the 16 MHz clock, not in your case, but with the 8 MHz clock. You don't get the 8 MHz clock directly, but all the control and address signals are aligned with it. It is not that it is a "problem", it is that the relation between LOAD, CS and the low rez pixel clock is changed. This is critical in a real SHIFTER because writes to the palette aren't synchronized with the clock.


That should be OK, because while RESET is asserted the clock counter will be cleared - so the low-res pixel clock will become aligned with the RESET signal, which I'm assuming has a fixed relationship to the 8MHz clock (that's an assumption I'm making that may be wrong...).

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

Re: SHIFTER reimplementation on FPGA

Postby ijor » Wed Aug 08, 2018 2:45 pm

Smonson wrote:That should be OK, because while RESET is asserted the clock counter will be cleared - so the low-res pixel clock will become aligned with the RESET signal, which I'm assuming has a fixed relationship to the 8MHz clock (that's an assumption I'm making that may be wrong...).


Hmm, it is complicated. How exactly are you doing that? I don't see something like that on your published code.

In first place there are two types of resets. There is hardware reset, at power up or when the user presses the reset button. And there is (let's call it) software reset when the CPU performs a RESET instruction.

Software reset is, more or less (see below), synchronized with the clock. Hardware reset is not synchronized with anything at all. It is true that after every hardware reset TOS takes control and early during boot it executes a RESET instruction. So you should never get an isolated hardware reset. But the whole thing then, depends on a software feature. Don't know ...

Software reset is asserted by the CPU, of course synchronized with the 8 MHz clock. But SHIFTER doesn't get the RESET signal directly, or are you taking it externally? If you are using the reset mechanism of the chipset, then you will get quite some delay and skew. This is because the reset SHIFTER gets, it's only after a very long combinatorial path passing from the CPU to GLUE and then to MMU. It is very possible that this will produce synchronization issues. Even if you synchronize with your own clock (IMHO, you certainly should), the delay might still provoke a non constant relation with the clock. This won't be exactly a wakeup in the strict sense because it might change with every reset, but with the same or similar effect.

User avatar
Smonson
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 125
Joined: Sat Feb 20, 2016 9:45 am
Location: Canberra
Contact:

Re: SHIFTER reimplementation on FPGA

Postby Smonson » Thu Aug 09, 2018 3:25 am

I haven't published the latest one yet. It's done like this:

Code: Select all

    // Generate 16MHz and 8MHz pixel clocks from 32MHz clock
    always @(posedge CLOCK_32) begin
       if (reset) begin
            speed_divider <= 0;
        end else begin
            speed_divider <= speed_divider + 2'b1;
        end
    end

User avatar
Smonson
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 125
Joined: Sat Feb 20, 2016 9:45 am
Location: Canberra
Contact:

Re: SHIFTER reimplementation on FPGA

Postby Smonson » Thu Aug 09, 2018 10:28 am

Oh man, I was completely wrong about fitting this into a MAX 7000 CPLD. It does fit into a 100-pin MAX V, but that's the only Altera CPLD architecture supported by Quartus-II that it's able to fit into (421 LEs). They're not 5v devices, and the TQFP-100 is a big package (14x14mm).

So to make a stand-alone shifter with the Altera parts I can access in this old version of Quartus, I guess it would basically need all the same hardware as the HDMI board: 16 pins of bidirectional level shifters, 9 pins of downward level shifters and 10 upward level shifter for the clock and RGB (as well as the 32MHz oscillator).

I also compiled it for Cyclone-II to get an approximation of its size and it requires 487 LEs for that architecture.

(Edited to fix the level shifter numbers)
Last edited by Smonson on Thu Aug 09, 2018 11:22 am, edited 1 time in total.

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

Re: SHIFTER reimplementation on FPGA

Postby ijor » Thu Aug 09, 2018 11:07 am

Smonson wrote:

Code: Select all

    // Generate 16MHz and 8MHz pixel clocks from 32MHz clock
    always @(posedge CLOCK_32) begin
       if (reset) begin
            speed_divider <= 0;
        end else begin
            speed_divider <= speed_divider + 2'b1;
        end
    end


This can certainly produce wakestate effects. You can confirm this by applying reset when you see the pixel corruption after being powered off for a while. But even if the effect can't be confirmed by a hardware reset, there is still no guarantee what would be the behavior on a different computer. Especially this will significantly affected by the chipset generation.

Btw, it might be wise to perform tests on different computers with different chipsets. And not only because of this wakestate effect. At least you should probably test the two main MMU variations, IMP and not IMP.

User avatar
troed
Atari God
Atari God
Posts: 1436
Joined: Mon Apr 30, 2012 6:20 pm
Location: Sweden

Re: SHIFTER reimplementation on FPGA

Postby troed » Thu Aug 09, 2018 2:48 pm

(I will help test this on different chipsets when I'm back from vacation)

User avatar
Smonson
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 125
Joined: Sat Feb 20, 2016 9:45 am
Location: Canberra
Contact:

Re: SHIFTER reimplementation on FPGA

Postby Smonson » Fri Aug 10, 2018 3:01 am

Thanks Troed, I only have the one machine. I'm still not understanding what the problem is though. If the chipset reset skew is related to the MMU/GLUE, then won't it just be another symptom of the wakeup states we already have to compensate for?

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

Re: SHIFTER reimplementation on FPGA

Postby ijor » Fri Aug 10, 2018 4:19 am

Smonson wrote:If the chipset reset skew is related to the MMU/GLUE, then won't it just be another symptom of the wakeup states we already have to compensate for?


If I understand exactly what you mean, then no. There is no relation whatsoever between the wakestates (of any type) and the mentioned reset skew.

The GLUE/MMU wakeup state (which I understand that's what you are already compensating) is a synchronous issue that can be measured in cycles. In your case, it is the delay in cycles since the active DE edge, up to the first LOAD active edge. It is constant for the current power up cycle.

The reset skew is a completely asynchronous issue. It can't (or it shouldn't) be measured in cycles. It can be measured only in absolute time units (say, nanoseconds). For a given computer, the jitter (the variation of the skew) depends mainly on the voltage and the temperature. It can then perfectly change without power cycling the computer.

Note that the problem is not the skew itself. The problem is that the skew, being quite significant, might produce timing violations. And even if it doesn't, the jitter might result in the skew to translate to a different number of cycles.

You are capturing the reset with a clock that has a 31.25 ns cycle. If the skew is, say 30ns, and the jitter is, say, plus minus 2 ns. Then sometimes you will capture in "this" cycle, sometimes you will capture in the "next" one. So this method can't be used as a reliable way to align your clock divisor with the launching clock (the main 8 MHz clock).

Edit: The SHIFTER wakeup state, in case you were talking about it, is also a synchronous issue. The reset skew is not a consequence of the wakeup, if that's what you were thinking. Again, they are completely unrelated.

User avatar
Smonson
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 125
Joined: Sat Feb 20, 2016 9:45 am
Location: Canberra
Contact:

Re: SHIFTER reimplementation on FPGA

Postby Smonson » Fri Aug 10, 2018 4:38 am

Hmm, I see. I'll leave that problem for later since it seems quite intractable.

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

Re: SHIFTER reimplementation on FPGA

Postby ijor » Fri Aug 10, 2018 12:49 pm

Smonson wrote:Hmm, I see. I'll leave that problem for later since it seems quite intractable.


It is difficult to workaround the reset skew. But you can still align the pixel clock using a regular LOAD edge. Not as straightforward as using reset though. You obviously can't do it on every LOAD pulse. You must do it only once after power up, may be once after every reset in the best case. And you must make sure the edge you are using is from a regular LOAD pulse and not as a consequence of RESET.


Social Media

     

Return to “Coding”

Who is online

Users browsing this forum: No registered users and 4 guests