English Amiga Board


Go Back   English Amiga Board > Coders > Coders. General

 
 
Thread Tools
Old 07 January 2008, 03:47   #1
FrenchShark
FPGAmiga rulez!
FrenchShark's Avatar
 
Join Date: Dec 2007
Location: South of France
Age: 44
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
FrenchShark is offline  
AdSense AdSense  
Old 07 January 2008, 23:41   #2
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,934
Quote:
Originally Posted by FrenchShark View Post
<SPRxPOS>, <1 empty word>, <SPRxCTL>, <1 empty word> for 32-pixel sprite
<SPRxPOS>, <3 empty words>, <SPRxCTL>, <3 empty words> for 64-pixel sprite
Correct.

Quote:
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.
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..
Toni Wilen is online now  
Old 08 January 2008, 11:36   #3
TheDarkCoder
Registered User
 
Join Date: Dec 2007
Location: Dark Kingdom
Posts: 210
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. :-(
TheDarkCoder is offline  
Old 08 January 2008, 11:52   #4
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,934
Quote:
Originally Posted by TheDarkCoder View Post
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
Toni Wilen is online now  
Old 08 January 2008, 15:27   #5
TheDarkCoder
Registered User
 
Join Date: Dec 2007
Location: Dark Kingdom
Posts: 210
Quote:
Originally Posted by Toni Wilen View Post
AFAIK only DMA can use 32/64-bit transfer modes. All CPU custom chip accesses are still only 16 bit
too bad !
...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.
TheDarkCoder is offline  
Old 08 January 2008, 17:09   #6
alexh
Thalion Webshrine
alexh's Avatar
 
Join Date: Jan 2004
Location: Oxford
Posts: 11,939
Quote:
Originally Posted by Toni Wilen View Post
Quote:
Originally Posted by FrenchShark View Post
this is still related the the AGA/AAA minimig implementation
Why not just simple dummy RTG compatible framebuffer?
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 ;-)
alexh is online now  
Old 09 January 2008, 01:46   #7
FrenchShark
FPGAmiga rulez!
FrenchShark's Avatar
 
Join Date: Dec 2007
Location: South of France
Age: 44
Posts: 155
Quote:
Originally Posted by Toni Wilen View Post
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..
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.

Quote:
Why not just simple dummy RTG compatible framebuffer?
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.

Regards,

Frederic
FrenchShark is offline  
Old 09 January 2008, 11:19   #8
alexh
Thalion Webshrine
alexh's Avatar
 
Join Date: Jan 2004
Location: Oxford
Posts: 11,939
Quote:
Originally Posted by FrenchShark View Post
I do not think we can create a FPGA clone of a Picasso II or IV board.
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?
alexh is online now  
Old 10 January 2008, 03:32   #9
FrenchShark
FPGAmiga rulez!
FrenchShark's Avatar
 
Join Date: Dec 2007
Location: South of France
Age: 44
Posts: 155
Quote:
Originally Posted by alexh View Post
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.

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
FrenchShark is offline  
AdSense AdSense  
 


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 17:10
24-bit + Picasso96 (stupid question) studiox support.WinUAE 10 22 July 2011 15:58
Question about 32-bit ram sink support.WinUAE 7 12 January 2011 13:02
Simple 14 bit audio question... Thorham Coders. General 7 06 June 2010 11:55
Swear words Kodoichi project.EAB 19 14 December 2001 01:53

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 12:54.


Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Page generated in 0.21741 seconds with 14 queries