New Universal Agnus 8372, 75 etc

[kipper2k]

Originally Posted by Niklas

If the board that has been built is based on this schematic then it is missing a PLL, which is probably needed for the logic to work (I pointed this out to nonarkitten earlier).

The board has 2 PLL's. PDF needs update

[Niklas]

Which chip has the PLLs? Did you change the FPGA, or add a discreet PLL?

[nonarkitten]

Originally Posted by Niklas

If the board that has been built is based on this schematic then it is missing a PLL, which is probably needed for the logic to work (I pointed this out to nonarkitten earlier).

More precisely it's needed for the pSRAM to work. I thought about just doing a delay chain, but we opted for the version that has PLLs. I can DM you more details on Discord. No need to get into the weeds on EAB.

[boemann]

Sounds really exciting, however the extended chipram being used by workbench doesn't sound compatible.

Programs write to chipram to render as well. Could a fake memory expansion that provides provides cpu access be constructed ?

[nonarkitten]

Originally Posted by boemann

Sounds really exciting, however the extended chipram being used by workbench doesn't sound compatible. Programs write to chipram to render as well. Could a fake memory expansion that provides provides cpu access be constructed ?

Xander (Custom Gary) can unlock up to 8MB of CPU accessible chip RAM.

[QuikSanz]

Programs write to chipram to render as well. Could a fake memory expansion that provides provides cpu access be constructed ?[/QUOTE]


See post #95 for extended info..

[Gorf]

Originally Posted by boemann

Sounds really exciting, however the extended chipram being used by workbench doesn't sound compatible.

Programs write to chipram to render as well. Could a fake memory expansion that provides provides cpu access be constructed ?

As far as I understand this: as long as WB and programs use Agnus/Blitter functions to write on the screen this would work ... maybe some small patch like "anti-fblit" will be needed to make sure graphics.library is never using CPU.

[Samurai_Crow]

Originally Posted by Gorf

As far as I understand this: as long as WB and programs use Agnus/Blitter functions to write on the screen this would work ... maybe some small patch like "anti-fblit" will be needed to make sure graphics.library is never using CPU.

Graphics.library needs a rewrite anyway. The drawing routines don't use the setup/shutdown hooks on QBlit to preserve the one trashed write caused by the barrel-shift alignment bug in the blitter hardware. Instead it uses a much slower hardware hack that requires all 3 DMAs be active when only 1 or 2 are needed otherwise.

[kipper2k]

I am reflowing Paula, Denise and Willoe boards by hand in one go. Cannot get them assembled without expensive mailing/brokerage/time etc. The price would pretty well climb exponentially adding all those steps. It takes about 20 minutes to make a board. (chips are not Chinese knock offs)

[utri007]

Originally Posted by kipper2k

I am reflowing Paula, Denise and Willoe boards by hand in one go. Cannot get them assembled without expensive mailing/brokerage/time etc. The price would pretty well climb exponentially adding all those steps. It takes about 20 minutes to make a board. (chips are not Chinese knock offs)

Any estimated prizes or delivery time? You are going to sell these? Or anyone willing?

[Pyromania]

No big delays like the A1200 keyboards right? Perhaps that was a learning experience?

[kipper2k]

Originally Posted by Pyromania

No big delays like the A1200 keyboards right? Perhaps that was a learning experience?

Nope, there was a reason why i didnt want to build those things, massive time consuming, plus the fact that it was AOTL that bought the keycap sets. Best thing i done was to hand it off, obviously it has had a lot of bad feelings with extremely slow distribution. Jeff, who actually builds them is pretty well stressed out

[kipper2k]

Originally Posted by utri007

Any estimated prizes or delivery time? You are going to sell these? Or anyone willing?

We will approach people for resale, i will not directly sell except for local only. There will be testing required as the FPGA used will need to have the 5v tolerant banks tested thoroughly.

[kipper2k]

I have received messages thet the chip we are using is not 5v tolerant.

Initially we were going to use the Ice65 and then discovered that is was missing a PLL that was needed for the logic. We then discovered in August that the Ice40 is from reports in eevblog and an old Silicon Blue datasheet that the Ice40 is 5v tolerant. so for all intents and purposes the picture and design shown in the first post is pretty well the same with a couple of changes. Whether this design is 100% we dont know until it is coded and stress tested but tests by other people have shown that it is compatible. If there are issues then we will address them.

Welcome to the world of Amiga

[kipper2k]

The Ice40 i believe has 2PLLs, so the upgraded board is set for the ICE40 as stated above

[nonarkitten]

Originally Posted by kipper2k

I have received messages thet the chip we are using is not 5v tolerant.

Initially we were going to use the Ice65 and then discovered that is was missing a PLL that was needed for the logic. We then discovered in August that the Ice40 is from reports in eevblog and an old Silicon Blue datasheet that the Ice40 is 5v tolerant. so for all intents and purposes the picture and design shown in the first post is pretty well the same with a couple of changes. Whether this design is 100% we dont know until it is coded and stress tested but tests by other people have shown that it is compatible. If there are issues then we will address them.

Welcome to the world of Amiga

To be fair, we probably could have made the iCE65 work without a PLL. A simple 2X multiplier would be perfect for ECS and 4X would work for AGA. SPI is fairly robust with SPI clock jitter as long as we're within the min/max timing. The rest of the chip would not need this; it should all work on 28MHz global clock.

[nonarkitten]

Originally Posted by Gorf

Luckily I have got two A3000s
Really looking forward to putting a full set of replacements in at least one of them!

by the way: How will this play out with Amber?
I guess it will be obsolete and there will be some breakout on Faith itself?
Or could we replace Amber with some better version as well? (thinking of Graffiti, HAM-E, DCTV functionality ...)

Faith has no break-out.

The idea is to make chip replacements and leverage all the strengths and weaknesses of the original design. Faith will output a 30kHz signal via the DB23 pin and that can be disabled for genlock compatibility. Amber probably will bypass this just like any productivity mode.

I'm unsure about how to implement a chunky mode. It really do think that adding it would be valuable, but doing it like Graffiti could be an infringement on Jens' IP. I have some ideas, but we'll need to test.

[Gorf]

Originally Posted by nonarkitten

Faith has no break-out.

The idea is to make chip replacements and leverage all the strengths and weaknesses of the original design. Faith will output a 30kHz signal via the DB23 pin and that can be disabled for genlock compatibility.

Composite?

So we are stuck with the 12 Bit on the RGB pins for AGA?

(Just thinking: couldn't the RGB pins be multiplexed to offer 24Bit? One would need to decode that afterwards of course...)

I'm unsure about how to implement a chunky mode. It really do think that adding it would be valuable, but doing it like Graffiti could be an infringement on Jens' IP. I have some ideas, but we'll need to test.

Faith could here of course go a more direct route, by altering the fetch modes...

[nonarkitten]

Originally Posted by Gorf

Composite? So we are stuck with the 12 Bit on the RGB pins for AGA? (Just thinking: couldn't the RGB pins be multiplexed to offer 24Bit? One would need to decode that afterwards of course...)

Okay, so you drive the three high bits from each RGB channel as-is. The low bit of each channel you PWM using the missing 5-bits of information at around 4x the pixel clock (e.g., around 115MHz). The resistors used for the R2R ladder combined with all the parasitic capacitance is more than enough to filter that out.

Originally Posted by Gorf

Faith could here of course go a more direkt route, by altering the fetch modes...

Here's where I'm at so far.

To enable chunky mode, you must enable UHRES mode. When UHRES is enabled, the BPLHPT pointer comes out on every free display DMA cycle during the display line. It increments by one word on every cycle. UHRES, despite its name, is displayed at the same pixel pitch as the general screen mode. It's bit depth depends on the number of bit planes allocated and the fetch mode (FMODE).

		   ----FMODE----
          0    1/2  3
Lores
  BPL=0   8b   16b  16b
  BPL1-8  n/a  8b   16b
Hires
  BPL=0   n/a  8b   16b
  BPL1-8  n/a  n/a  8b
SHires
  BPL=0   n/a  n/a  8b
  BPL1-8  n/a  n/a  n/a

Chunky mode starts when all other bit planes start and stops when they stop. It only has it's own unique vertical start and stop which specifies the scan lines UHRES is enabled on.

Chunky mode does not have fine scroll and regular scroll is simply accomplished by incrementing or decrementing its initial pointer. Chunky mode supports 8-bit aligned bitplanes in 8bpp modes.

In 8bpp mode, chunky mode will use the colour table. This allows chunky mode to be affected by the COPPER.

In 16bpp mode, chunky mode will use a 4444 RGBV mode where the high 4-bits of each channel are independently controlled and the low four bits are the same for all three channels. This produces 65536 colours with 256 gradients.

Chunky pixels are displayed anywhere the background bit is enabled. This can be done in a few ways: within the colour registers themselves by setting the transparent bit; by setting a global colour channel to be transparent or by having a whole bitplane define transparency. However this bit gets set, the UHRES pixels will show through.

Chunky mode is thus not simultaneously compatible with genlock hardware.

Since the background is only visible through the "genlock" signal this allows really weird tricks like say, having a sprite show the chunky plane, or having per-pixel interleaving for some checker-board "alpha blend." Since it doesn't affect existing display modes, you could easily have 8bpp background, 4bpp background playfield, 4bpp foreground playfield as well as eight, 64-pixel wide sprites.

The Blitter should be able to BitBlt within Chunky memory as easily as anywhere else, no special concession has to be made other than watching alignments -- a whole byte or word now represents a "pixel."

I debated about what to do with the other UHRES registers. It's risky adding ANYTHING NEW, it really is. But I know everyone loves 3D. You do. Admit it. So what about Mode 7? (This is me asking, not promising.)

$dff1e8 Affine Register Select (0 thru 7, or H, V, X0, Y0, A, B, C and D)
$dff1ea Affine Register Read/Write (8.8 signed fixed point format)

This would all the 8-bit background to be affine transformed in almost anyway. This can be easily combined with all sorts of scanline tricks to add perspective, wiggling motion, etc. Since it can do hires and even superhires, it would be much sharper than Mode 7 was on the SNES...

At the very least it would make emulating a SNES on an Amiga a lot easier.

[Gorf]

Originally Posted by nonarkitten

Okay, so you drive the three high bits from each RGB channel as-is. The low bit of each channel you PWM using the missing 5-bits of information at around 4x the pixel clock (e.g., around 115MHz). The resistors used for the R2R ladder combined with all the parasitic capacitance is more than enough to filter that out.

nice and elegant trick ...
Probably visually good enough, but PWM @ 4x the pixel clock is not enough for encoding 32 values, is it?
It will be interesting to see how resistance ladders and Vidiot will handle such a signal