An open source flicker fixer for Amiga 500/2000

[talybont]

Doesn't seem like this has been mentioned here.


https://github.com/niklasekstrom/flickerfixer

An open source flicker fixer for Amiga 500/2000

This is the first stage in the construction of a flicker fixer/scan doubler that mounts internally in an Amiga 500 or Amiga 2000.

In order to rapidly prototype the FPGA logic I designed a small adapter board that connects pins on Denise to a DE10-Lite FPGA development board via a 5V-tolerant buffer. The KiCad files for the board are available in Hardware.

After ordering, receiving and soldering the PCB I then wrote Verilog code that samples CSYNC (composite sync) and the 12-bit RGB signals, and outputs the sampled pixels to VGA. The logic handles both non-interlaced and interlaced output from the Amiga. The Quartus project is available in HDL.

The next stage is to design a stand-alone board that contains an FPGA chip and an SDRAM chip.An open source flicker fixer for Amiga 500/2000

This is the first stage in the construction of a flicker fixer/scan doubler that mounts internally in an Amiga 500 or Amiga 2000.

In order to rapidly prototype the FPGA logic I designed a small adapter board that connects pins on Denise to a DE10-Lite FPGA development board via a 5V-tolerant buffer. The KiCad files for the board are available in Hardware.

After ordering, receiving and soldering the PCB I then wrote Verilog code that samples CSYNC (composite sync) and the 12-bit RGB signals, and outputs the sampled pixels to VGA. The logic handles both non-interlaced and interlaced output from the Amiga. The Quartus project is available in HDL.

The next stage is to design a stand-alone board that contains an FPGA chip and an SDRAM chip.

[seb132]

Interesting project.
Me following

[nickwest]

Excellent work so far!


So is your plan to use a single PCB, with just the FPGA, voltage buffer (and probably some glue logic, headers, decoupling etc)... to replace the dev board, ribbon cable and adapter board in the photos?

[Fastdruid]

I would personally be tempted rather than keeping the Denise to replace it entirely with an FPGA.

The HDL for Denise already exists in the Minimig-AGA_MiSTer project.

It would offer the opportunity not only for scan doubling but also add the possibility of additional screenmodes to the A500/A2000 without going RTG.

[Niklas]

Originally Posted by nickwest

So is your plan to use a single PCB, with just the FPGA, voltage buffer (and probably some glue logic, headers, decoupling etc)... to replace the dev board, ribbon cable and adapter board in the photos?

That was indeed the plan.

Originally Posted by Fastdruid

I would personally be tempted rather than keeping the Denise to replace it entirely with an FPGA.

And then that is what happened At some point I realized that having a somewhat large FPGA connected to the Denise socket, without doing something more with it, seemed slightly wasteful.

So I made a V2 of the adapter PCB, available here, that routes all pins from the Denise socket to the FPGA. Unfortunately the second version of the adapter PCB has some signal integrity issues, and I haven't taken the time to debug that yet, so that's where things stand. But when I have a working adapter that routes all signals to the FPGA then I should be able to get to work on implementing Denise in the FPGA. As you point out, there are already several open Verilog implementations of Denise available.

[Pyromania]

Cool project, how does it compare to OSSC? I just got one of those today.

[Stedy]

Originally Posted by Niklas

That was indeed the plan.



And then that is what happened At some point I realized that having a somewhat large FPGA connected to the Denise socket, without doing something more with it, seemed slightly wasteful.

So I made a V2 of the adapter PCB, available here, that routes all pins from the Denise socket to the FPGA. Unfortunately the second version of the adapter PCB has some signal integrity issues, and I haven't taken the time to debug that yet, so that's where things stand. But when I have a working adapter that routes all signals to the FPGA then I should be able to get to work on implementing Denise in the FPGA. As you point out, there are already several open Verilog implementations of Denise available.

Nice project, the video output looks quite good on the V1 board. How well does it handle moving video?

For the FPGA issues, set all inputs to Schmitt trigger inputs, the Amiga's logic may be too slow for the FPGA and for outputs, try 4mA LVTTL Slow slew rate, the 4mA fast slew rate I/O.

Good luck with the project, keep posting updates.

[Fastdruid]

Originally Posted by Pyromania

how does it compare to OSSC?

Well that kind of depends where the project goes. At its simplest it's basically doing exactly the same as an OSSC but internally.

In *theory* however if you replace Denise with an suitable sized FPGA you could then do all sorts of clever stuff that the OSSC wouldn't even come close to. The OSSC can only rework what is already there, a Denise replacement could potentially include having some AGA functionality (or better) on an A500/A2000.

I'm not even going to pretend to understand how to write Verilog (I looked at it, I understand about 5% at most ) but the MiSTer has the code for the hardware emulation of Lisa/AGA so again this isn't someone needs to start from scratch programming a Lisa replacement.

I don't believe you could do any RTG (feel free anyone who actually knows what they're talking about to tell me I'm talking crap at any point) without a new processor however because the drivers need an '020 or better but you might be able to do some other stuff.

If anyone is clever enough to write Verilog then you could experiment now. As far as I can see it's a single wire definition in the MiSTer code base each to enable ECS or AGA in "Denise" so a bit of config and you could have MiSTer running a virtual A500 with the rest of the ECS chipset, a 68k and AGA Denise!

[Gorf]

Originally Posted by Fastdruid

I don't believe you could do any RTG (feel free anyone who actually knows what they're talking about to tell me I'm talking crap at any point) without a new processor however because the drivers need an '020 or better but you might be able to do some other stuff.

something like the "Piccolo" "Graffiti" pseudo-chunky mode should be possible, like the Indivision supports as well.

If anyone is clever enough to write Verilog then you could experiment now. As far as I can see it's a single wire definition in the MiSTer code base each to enable ECS or AGA in "Denise" so a bit of config and you could have MiSTer running a virtual A500 with the rest of the ECS chipset, a 68k and AGA Denise!

Besides the missing support from Agnus the main problem would be the 16bit single-fetch on a ECS machine. AGA Lisa has 32 bit wide access to the chipram and can do two fetches per 280ns time-slot. That is simply not possible on pre-AGA hardware.

(the Minimig is actually doing AGA in 16Bit ... but with faster RAM that allows even four consecutive fetches per time-slot)

So the only benefit would be 256 color registers instead of 32 .. but no gfx-mode to support 8 bitplane fetches! But you could go for 64 registers, to allow 64 real colors in "EHB" or allowing a super fast switch between register banks, eliminating the need for the black line between different screens.

Nevertheless: I would love to have a FPGA-replacemant for Denise (and possibly all other chips) on a real mainboard!
Sure it is inefficient and and more expensive than just a Minimig, but there is something to it....

PS: one could also try to implement "HAM-e" and "DCTV" in such a FPGA-Denise:

http://amiga.resource.cx/exp/hame
http://amiga.resource.cx/exp/dctv

[bwldrbst]

Originally Posted by Gorf

Nevertheless: I would love to have a FPGA-replacemant for Denise (and possibly all other chips) on a real mainboard!

Yeah, the first thing that crossed my mind was "Full ECS, Including 2MB Agnus, For Everyone!"

[Fastdruid]

Originally Posted by bwldrbst

Yeah, the first thing that crossed my mind was "Full ECS, Including 2MB Agnus, For Everyone!"

It also adds an option for the various "replacement" motherboards as there is an ever decreasing number of original Denise chips.

I would personally love to see the option for all the custom chips to be replicated in individual FPGA's, alongside the RAM boards using newer chips and the vidot replacement(s) it would let you build a new Amiga from all new components. Not to mention while also adding functionality that wasn't there in the first place.

[Fastdruid]

Originally Posted by Gorf

something like the "piccolo" pseudo-chunky mode should be possible, like the Indivision supports as well.

I did actually wonder if it might be able to do similar to Akiko.

Originally Posted by Gorf

Besides the missing support from Agnus the main problem would be the 16bit single-fetch on a ECS machine. AGA Lisa has 32 bit wide access to the chipram and can do two fetches per 280ns time-slot. That is simply not possible on pre-AGA hardware.

Ah. I did say *potentially* having *some* AGA functionality.

[Gorf]

Originally Posted by Fastdruid

I did actually wonder if it might be able to do similar to Akiko.

hmm - Akiko helps to do c2p: write something to it's registers and get the result from other registers... that is probably not what we would want from Denise..
So it would be more like pointing to a block of chunky pixels in ChipRAM and let Denise fetch it and (maybe) transform it to planar internally ...

this is very close to a "pure" chunky mode ... with the advantage, that sprites and copper-effects would still work.

The "Piccolo" "Graffiti" method is the other way around: we have chunky pixels in ram, but they are treated as planar by Denise and the "mess" that this output generates is cleaned up afterwards ...

The first method (internal Akiko) makes more sense i think ... but on the other hand: there is already existing software for the PiccoloGraffiti-mode...

Ah. I did say *potentially* having *some* AGA functionality.

I know.

I was just boiling it down, to what that probably means. To what AGA-features we we can actually use in an ECS/OCS machine. There are not that many.

I guess chunky-pixel support, and tricks like HAM-E or DCTV have more potential to be useful, since they did work with pre-AGA Amigas and there is already some software using it...

[robinsonb5]

Originally Posted by Gorf

So it would be more like pointing to a block of chunky pixels in ChipRAM and let Denise fetch it and (maybe) transform it to planar internally ...


this is very close to a "pure" chunky mode ... with the advantage, that sprites and copper-effects would still work.

I think it would have to be arranged so that the virtual Denise fetches as though from four high-res bitplanes, then reads a complete chunky pixel (or maybe pair of pixels) from each in turn?

The "Piccolo" method is the other way around: we have chunky pixels in ram, but they are treated as planar by Denise and the "mess" that this output generates is cleaned up afterwards ...

Indeed - that's the "Graffiti", I think? Available both as a standalone external A520-like box, and as part of the Indivision ECS scandoubler. (Piccolo was an actual RTG graphics card.)

The first method (internal Akiko) makes more sense i think ... but on the other hand: there is already existing software for the Piccolo-mode...

I agree. On the other hand, most of the software that supports Graffiti has modular video drivers, so writing new ones shouldn't be beyond the bounds of possibility.

[Gorf]

Originally Posted by robinsonb5

I think it would have to be arranged so that the virtual Denise fetches as though from four high-res bitplanes, then reads a complete chunky pixel (or maybe pair of pixels) from each in turn?

yes. for 8bit-pixels the arrangement would be like this:

         pixel #
plane1: 0000000011111111  8888888899999999  ....
plane2: 2222222233333333  AAAAAAAABBBBBBBB  ....
plane3: 4444444455555555  CCCCCCCCDDDDDDDD  ....
plane4: 6666666677777777  EEEEEEEEEFFFFFFF  ....

Indeed - that's the "Graffiti", I think? Available both as a standalone external A520-like box, and as part of the Indivision ECS scandoubler. (Piccolo was an actual RTG graphics card.)

you are right of course - i mixed that up!
"Graffiti" it is!

I agree. On the other hand, most of the software that supports Graffiti has modular video drivers, so writing new ones shouldn't be beyond the bounds of possibility.

as long as it can be fixed with a patched driver it should be ok.

[Fastdruid]

Originally Posted by Gorf

I was just boiling it down, to what that probably means. To what AGA-features we we can actually use in an ECS/OCS machine. There are not that many.

I guess chunky-pixel support, and tricks like HAM-E or DCTV have more potential to be useful, since they did work with pre-AGA Amigas and there is already some software using it...

If you add RAM to the board there are some other potential options as well.

How about UHRES aka "Super ultra resolution mode" to drive a higher (1024x1024) resolution?
http://eab.abime.net/showthread.php?t=77091

The registers are there but it's not really ever been used which may limit things.

Also although greyscale only could implement a 1024x1024 output by simulating the A2024, again you'd need some RAM for it as it has it's "own" framebuffer. The A2024 worked on any Amiga though so the software is there already.

[PurpleMelbourne]

The Chrontel CH7026 looks like a Super AGA Amber with 2MB built in frame buffer.

CH7026 Datasheet
http://www.chrontel.com/upFiles/imag...26bs%201.1.pdf

It just needs voltage conversion to get down to 3.3v

It could be combined with Spartan 3e CBG132 (8mm square), voltage regulator, Xilinx PROM and a pair of 24bit QuickSwitch voltage converters could do the job in the size of the original Denise chip.

Yeah my prototype comes along slow, so I might as well see if someone else can implement my ideas faster than me.
As long as Amiga grows stronger

[Gorf]

Originally Posted by PurpleMelbourne

The Chrontel CH7026 looks like a Super AGA Amber with 2MB built in frame buffer.

CH7026 Datasheet
http://www.chrontel.com/upFiles/imag...26bs%201.1.pdf

How much is the fish chip?

its not available via mouser or digikey ... obsolete part?

[Gorf]

Originally Posted by Fastdruid

If you add RAM to the board there are some other potential options as well.

How about UHRES aka "Super ultra resolution mode" to drive a higher (1024x1024) resolution?
http://eab.abime.net/showthread.php?t=77091

The registers are there but it's not really ever been used which may limit things.

As far as we know, the registers are there and a timer is there ... but setting it up does not do anything on the bus...

And it would be in Agnus anyways.

Also although greyscale only could implement a 1024x1024 output by simulating the A2024, again you'd need some RAM for it as it has it's "own" framebuffer. The A2024 worked on any Amiga though so the software is there already.

Sure, the 'Hedley' device would be an obvious feature for an advanced flickerfixer. The resolution of 1024x1024 makes no sense anymore, but the concept of stitching together 4 screens of lower resolution into one big is still valid. Today we would just aim for a more widescreen aspect ratio.

[Gorf]

Originally Posted by Gorf

How much is the fish chip?

its not available via mouser or digikey ... obsolete part?

some other IC that might be doing the same:
https://www.analog.com/media/en/tech...ts/ADV7604.pdf


just a quick search, "Analog Devices" has a wide variety of ICs ... some other might be a better fit