07 January 2008, 02:47 | #1 |
FPGAmiga rulez!
Join Date: Dec 2007
Location: South of France
Age: 50
Posts: 155
|
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 <SPRxPOS>, <3 empty words>, <SPRxCTL>, <3 empty words> for 64-pixel sprite 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. Regards, Frederic |
07 January 2008, 22:41 | #2 | ||
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,502
|
Quote:
Quote:
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.. |
||
08 January 2008, 10:36 | #3 |
Registered User
Join Date: Dec 2007
Location: Dark Kingdom
Posts: 213
|
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. :-( |
08 January 2008, 10:52 | #4 | |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,502
|
Quote:
|
|
08 January 2008, 14:27 | #5 | |
Registered User
Join Date: Dec 2007
Location: Dark Kingdom
Posts: 213
|
Quote:
...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. |
|
08 January 2008, 16:09 | #6 | |
Thalion Webshrine
Join Date: Jan 2004
Location: Oxford
Posts: 14,332
|
Quote:
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 ;-) |
|
09 January 2008, 00:46 | #7 | ||
FPGAmiga rulez!
Join Date: Dec 2007
Location: South of France
Age: 50
Posts: 155
|
Quote:
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. Quote:
I do not think we can create a FPGA clone of a Picasso II or IV board. Regards, Frederic |
||
09 January 2008, 10:19 | #8 | |
Thalion Webshrine
Join Date: Jan 2004
Location: Oxford
Posts: 14,332
|
Quote:
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? |
|
10 January 2008, 02:32 | #9 | |
FPGAmiga rulez!
Join Date: Dec 2007
Location: South of France
Age: 50
Posts: 155
|
Quote:
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. 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 |
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
AMOS Sprite Programming Question | ricky500 | support.Apps | 1 | 26 June 2012 16:10 |
24-bit + Picasso96 (stupid question) | studiox | support.WinUAE | 10 | 22 July 2011 14:58 |
Question about 32-bit ram | sink | support.WinUAE | 7 | 12 January 2011 12:02 |
Simple 14 bit audio question... | Thorham | Coders. General | 7 | 06 June 2010 10:55 |
Swear words | Kodoichi | project.EAB | 19 | 14 December 2001 00:53 |
|
|