32 and 64 bit sprite control words question
 

Hello,

this is still related the the AGA/AAA minimig implementation.
I would like to know the format of the first line of a 32-pixel or 64-pixel sprite : I guess they are 2 x 2 words long and 2 x 4 words long respectively. But, where are the control words located ?
Is it :
<SPRxPOS>, <1 empty word>, <SPRxCTL>, <1 empty word> for 32-pixel sprite :confused
<SPRxPOS>, <3 empty words>, <SPRxCTL>, <3 empty words> for 64-pixel sprite :confused

BTW, for the AAA implementation, I have a problem with sprite positioning on high resolution screen (i.e. 1280x1024), there is not enough bit for VSTART and VSTOP.:crazy

Regards,

Frederic

Correct.

Why? I am quite sure nobody is going to use it and in worst case there will be multiple different (and incompatible) so called 'AAA' implementations..

Why not just simple dummy RTG compatible framebuffer?

btw, attach bit works differently in ECS/OCS and AGA:

OCS/ECS: even or odd sprite's attach bit set = sprite is attached.
AGA: even sprite's attach bit is ignored.

Even attach bit could be used as an extra vertical position bit for both even and odd sprites.. :nuts

I confirm the positions of control words for sprites.
I have a related question: is it possible to use 32 and 64 pixel in non-DMA mode, i.e. writing directly to the SPRxPOS, SPRxCTL, SPRxDAT registers as one do with 16 pixel OCS sprites? I tried once but was unable to do that. :-(

AFAIK only DMA can use 32/64-bit transfer modes. All CPU custom chip accesses are still only 16 bit :(

too bad ! :sad:(
...but it makes sense. Would you consider possible for the copper to do a wide transfer? After all it works as a DMA channel...but it has to fetch copper instructions. Blitter too is DMA but unfortunately, AFAIK, it is 16 bit. :confused

That's what I had in mind. There are several open source, VESA compatible, VHDL/VERILOG VGA controllers out there. Would it be easy to write an RTG driver for a "new RTG card"?

Unfortunately it's pointless implementing these features in the short term.

A new FPGA platform is required first.

The MiniMig v1.1 PCB doesn't have enough RAM (1.5Mbytes), it only has 12-bit a DAC and it doesn't have an 020+ compatible CPU that would be required for RTG software like Picasso96.

Best to stick to ECS for the time being. All those users out there with LCD's that dont sync to 50Hz are dying for it ;-)

Well, maybe we have to write a AAA specification based on Dave Haynie's docs.

Here are the planned characteristics:

For the video:
- 114.5 MHz Chip RAM 32-bit bus (454 MB/s)
- Variable dot clock, up to 114.5 MHz
- 32-bit chip register access from the CPU
- 1024 chip registers (DFF000 - DFF7FE)
- DMAs not blocking CPU access to the chip registers
- 8 "variable bit" planes (depth: 1,2,4 or 8 bits per plane)
- 16 sprites with 2,4, 16 or 256 colors with up to 1024 bits per line.
- 9 256-entry color LUT : 1 per plane + 1 for sprites
- The planes can be combined to create up to 8 independant layers.
- The layers can be color LUT based, HAM6/8/10, YUV or RGB.
- Copper with "move multiple"

For the audio:
- 16 16-bit channels with panning.

If we write an RTG driver for the AAA. We have an RTG framebuffer.
I do not think we can create a FPGA clone of a Picasso II or IV board.:nuts

Regards,

Frederic

I disagree. While you wouldnt clone the chips 100%, it would be very easy to make something simple that was a VGA register set compatible. There is lots of information out there including reference code.

http://www.opencores.org/projects.cg...a_lcd/overview

Surely it's more important to have a standard VGA programmers interface with chunky pixels than an "as yet" unused AAA implementation?

The AAA implementation I plan will have chunky pixels.
For every plane, you can choose the depth : 1 (normal Amiga mode), 2,4 or 8 bits per pixels. It is really easy to do in an FPGA : every plane will have a 2048 bytes FIFO (this way, scan doubling does not consume DMAs). The write port will be 32-bit wide and the read port will be 1,2,4 or 8-bit wide. The bits from a plane can be combined with the bits from another plane to index one or more color palettes (up to 8) or feed some HAM block (up to 4). The YUV mode is done by setting 3 palettes with Y -> RGB, U -> RGB and V -> RGB LUTs and activating some adders in the RGB pipeline. In RGB mode, the palettes are just bypassed.

Imagine : you want a WB with a HAM10 backdrop picture. You setup:
- Plane 1 in 8-bit mode (HAM10 data)
- Plane 2 in 2-bit mode (HAM10 command)
- Plane 3 in 4-bit mode (16 color WB) or 8-bit mode (256 color WB)
You want a video in a window ? You setup Planes 4,5,6 as 8-bit plane with their palettes with YUV coefs. And voila.:spin

With the current bus speed I can display up to 5 8-bit planes in 1280x1024, 60 Hz.

Of course each plane will have its own modulo, shift value, pixel resolution (very useful for YUV 422 or 411) and maybe display window.

Regards,

Frederic