|
|---|
Vann Vicious
USA
| |
Posts 5
16 Mar 2010 00:21
| Thanks for the update Thomas, I check here everyday hoping for a bump to this thread.
| |
Ayodele Stephenson
USA
| |
Posts 83
16 Mar 2010 00:50
| Cool! Nice to see progress!!
| |
Erik Bauer
Italy
| |
Posts 301
16 Mar 2010 08:17
| Every little step is great!
| |
Marcel Verdaasdonk
Netherlands
| |
Posts 3979
16 Mar 2010 08:34
| Well one tackled, and still a few problems to go. It's terrific we are this far.
| |
Thomas Hirsch
Germany
| | (MX-Board Owner)
Posts 647
16 Mar 2010 18:41
|
SpritesSprites are implemented now. The line-buffer in only 16bit for now. For better AGA compatibility they only need to be extended, fetching is already done. I explicitly say "better AGA compatibility" because full AGA compatibility will deliberately not be reached: all eight sprites will be available at all times, and this without any performance penalty. In the picture you can see a single sprite which displays the 1.2 pointer. 
Leaving this table:
Frame generation ...... ECS, fixed 28MHz pixel clock
SyncZorro Interface ... preliminary version
Copper ................ fully implemented
Video DMA ............. fully implemented
256 color registers ... fully implemented
Sprites ............... 16bit linebuffer
Video priority ........ half implemented
Scandoubler ........... fully implemented
Interrupts ............ o
Paula DMA control ..... fully implemented
Audio DMA ............. o
VGA out ............... working
DVI out ............... o
PCI ................... o
IDE ................... o
CIAs .................. processor interface
Disk DMA .............. o
Slow peripheral I/O ... o
(Joy/Mouse/Keyb/PRT/DSK/SER)
| |
Bartek "Banter" K.
Poland
| | (Natami Team)
Posts 2277
16 Mar 2010 18:48
| Thomas Hirsch wrote:
|
I explicitly say "better AGA compatibility" because full AGA compatibility will deliberately not be reached: all eight sprites will be available at all times, and this without any performance penalty.
|
That is interesting news! Could you elaborate how this "enhanced incompatibility" influence old software? I mean, can the new improvement of 8 sprites being available all the time stop old games from working or it is unlikely and not the case? Could you explain? mfG
| |
Thomas Hirsch
Germany
| | (MX-Board Owner)
Posts 647
16 Mar 2010 18:59
| No, it can't harm old software. On the original chipset you had to set unused sprites (or sprites which were not usable for any reason) to SAVE NULL. On the original chipset unused sprites (including unusable) were flickering around randomly on the screen when they were not properly terminated. So old software has to disable the unusable sprites, meaning even as they are available now old software still disables them.
| |
Marcel Verdaasdonk
Netherlands
| |
Posts 3979
16 Mar 2010 20:03
| That is a good thing, i think.
that would prevent something that wouldn't be in the programmers control.
| |
Richard Maudsley
United Kingdom
| |
Posts 821
16 Mar 2010 20:31
| What effect would this have on demos?
| |
Thomas Hirsch
Germany
| | (MX-Board Owner)
Posts 647
16 Mar 2010 21:19
| What do you mean "what effect"??? You could take the old source code and recompile the old demos and now enable all eight sprites end use them all. If you want. Or you can write new demos using eight sprites in one single raster line, no matter how much planes you use how big your overscan is.
| |
Marcel Verdaasdonk
Netherlands
| |
Posts 3979
16 Mar 2010 21:27
| what effect, it means in this context what will it do or what will happen. and I figured as much.
| |
Thomas Hirsch
Germany
| | (MX-Board Owner)
Posts 647
16 Mar 2010 23:39
| Hmmmm... I still do not understand the question.
new is:
you can use all sprites all the time.
original Amiga is:
on some circumstances you can not use sprite 7. If you do it anyhow you will get some random data running over the screen. See "DMA Time Slot Allocation" HRM 6.9 EXTERNAL LINK
So when the question is "what will happen when eg. Sprite 7 is initialized on a wide display screen?" - Then the answer is: Sprite 7 will be displayed correctly on the NatAmi whereas on the original chipset it would cause "spurious sprite video to appear".
| |
Channel Z
| |
Posts 227
16 Mar 2010 23:42
| I guess he just wanted to know if it would break old, existing demos.
| |
Thomas Hirsch
Germany
| | (MX-Board Owner)
Posts 647
16 Mar 2010 23:46
| OK, then the answer is: it can not break old demos because the "old demo" in question had to disable sprite 7 to work correctly.
| |
Steve Thomas
United Kingdom
| |
Posts 178
16 Mar 2010 23:50
| Do you think developers will write software that uses Natami's unique hardware, or will they write software that will run on an A1200 to get the extra sales?
| |
Team Chaos Leader
USA
| | (Moderator)
Posts 2094
17 Mar 2010 06:21
| I am a software developer and I write software that requires Natami's unique hardware.
| |
Matt Hey
USA
| |
Posts 735
17 Mar 2010 06:58
| steve thomas wrote:
|
Do you think developers will write software that uses Natami's unique hardware, or will they write software that will run on an A1200 to get the extra sales?
|
Both and both are good. New machines and a larger, growing market will do wonders for the 68k.
| |
Erik Bauer
Italy
| |
Posts 301
17 Mar 2010 09:50
| Sprites! YAY!!! I'd run a banana dance if only we had banana smiles here!!
| |
Hagbard Celine
Norway
| |
Posts 24
17 Mar 2010 11:13
| Thomas Hirsch wrote:
| | Sprites
Sprites are implemented now. The line-buffer in only 16bit for now. For better AGA compatibility they only need to be extended, fetching is already done. I explicitly say "better AGA compatibility" because full AGA compatibility will deliberately not be reached: all eight sprites will be available at all times, and this without any performance penalty.
In the picture you can see a single sprite which displays the 1.2 pointer.
Leaving this table:
Frame generation ...... ECS, fixed 28MHz pixel clock
SyncZorro Interface ... preliminary version
Copper ................ fully implemented
Video DMA ............. fully implemented
256 color registers ... fully implemented
Sprites ............... 16bit linebuffer
Video priority ........ half implemented
Scandoubler ........... fully implemented
Interrupts ............ o
Paula DMA control ..... fully implemented
Audio DMA ............. o
VGA out ............... working
DVI out ............... o
PCI ................... o
IDE ................... o
CIAs .................. processor interface
Disk DMA .............. o
Slow peripheral I/O ... o
(Joy/Mouse/Keyb/PRT/DSK/SER)
|
Fantastic!! Thanks for the update. I really can not wait to get my hands on this beast :) Keep up the good work.
| |
Gunnar von Boehn
Germany
| | (Moderator)
Posts 5775
18 Mar 2010 09:14
| Thomas Hirsch wrote:
|
I explicitly say "better AGA compatibility" because full AGA compatibility will deliberately not be reached: all eight sprites will be available at all times, and this without any performance penalty.
|
No offence Thomas but this post is VERY misleading. I think you wanted to say something completely different.
I think what you wanted to say was:
- AGA compatibility is the goal.
- Some limitations in AGA or OCS you want to remove.
One example of this is that SAGA can always display 8 Sprites.
(old AGA sometimes could not) But in my opinion this has NOTHING to do with compatibility. Old AGA program should run fine independent whether the new SAGA can always display 8 or 16 or 512 sprites, right?
| |
|
The team will post updates and news here