Individual Computers - New accelerator cards for A600 & A1200

[MarkONE]

Maybe it is time to ask? Should I write a email? Or is he active in the board as well? I mean it should not cost anything to ask, and we can see if he would be interested to build some when we get enough preorder's in place?

[Predseda]

Maybe we should do a count? I have two, one plane and one with SX32 Pro

Summarising of CD32 units: I set a new topic. Go here: http://eab.abime.net/showthread.php?t=55974

[phipscube]

Originally Posted by MarkONE

I wished there would be something available for the CD32 ... But saying that, I assume there are hardly any users left ;(

Well I don't currently own a CD32 but its on my list to get when i'm back home in January.

Originally Posted by Cammy

I'd spend money on a CD32 accelerator before I spend it on one for the A600 or A1200. I have all these Amigas but the one I'd love to boost the speed of the most is definitely the CD32!

I agree exactly! My A1200 is maxxed out already, and my sons A600 is fine at stock level for his use, but I had ideas on buying a second A1200 and putting an 030 in it just for WHDLoad games... but then I thought, hang on, a CD32 with a 030 would be perfect for that job actually being a games machine that can natively play all the CD32 games too. installed with something like the upcoming X-Bench WHDload OS it would be awesome!

[Oliver_A]

Work in progress

ADoom Shareware in 1024x768 256 colours on Indivision ECS and the upcoming ACA630.



I'm currently adding Indivision GFX support to ADoom and I thought you might be interested in comparing some performance figures. First, ADoom using etra halfbrite chunky 2 planar routine in 320x200, 64 colours:



One frame takes 71731 us to render. Now compare this to the Indivision GFX direct chunky graphics mode in 320x200, 256 colours:



Wow, rendering time is only 24000 us per frame, almost three times faster than using the ECS chipset! Reason for this is the maximum chip ram write speed of the ACA630 (3.5MB/s) to the SDRAM chunky framebuffer of the Indivision ECS flickerfixer. It's as close as one can get having an Amiga 3000 with a Zorro II graphics card in the tiny Amiga 600 case.

Result: Adoom is very playable in 1x1 graphics mode in 320x200 in 256 colours on Indivision ECS and ACA630.

More details will follow soon.

[FOL]

Originally Posted by Oliver_A

Work in progress

Adoom Shareware in 1024x768 256 colours on Indivision ECS and the upcoming ACA630.



I'm currently adding Indivision GFX support to ADoom and I though you might be interested in comparing some performance figures. First, ADoom using etra halfbrite chunky 2 planar routine in 320x200, 64 colours:



One frame takes 71731 us to render. Now compare this to the Indivision GFX mode in 320x200, 256 colours:



Wow, rendering time is only 24000 us per frame, almost three times faster than using the ECS chipset! Reason for this is the maximum chip ram write speed of the ACA630 (3.5MB/s) to the SDRAM chunky framebuffer of the Indivision ECS flickerfixer. It's as close as one can get having an Amiga 3000 with a Zorro II graphics card in the tiny Amiga 600 case.

Result: Adoom is very playable in 1x1 graphics mode in 320x200 in 256 colours on Indivision ECS and ACA630.

More details will follow soon.

Thats awesome, .

[gulliver]

@Oliver_A
Wow!
Could you please upload a youtube video of those setups running Adoom?

[cv643d]

Oliver: is it possible to add 256 color mode to WB also?

Great work, nice pictures. Refreshing to see products and product maker keeping community up to date. Danke schön...

Just pinging in that I would be in for 2 CD32 accellerator boards if there were any. I do however plan to buy one of the A1200 and A600 boards.. I do plan to buy those systems in the not too distant future..

[Paul_s]

Jens has done great work here. It's comparable to Jesus turning water to wine!

[Ratte]

@Oliver_A:
Using display and blitter-dma at the same time?
Is this newstyle (framebuffer-mode) or graffiti-style generated (with higher resolutions)?

[FOL]

Originally Posted by Paul_s

Jens has done great work here. It's comparable to Jesus turning water to wine!

LMFAO, your comments always make me laugh,

[NovaCoder]

Originally Posted by Oliver_A

Work in progress

ADoom Shareware in 1024x768 256 colours on Indivision ECS and the upcoming ACA630.



I'm currently adding Indivision GFX support to ADoom and I thought you might be interested in comparing some performance figures. First, ADoom using etra halfbrite chunky 2 planar routine in 320x200, 64 colours:



One frame takes 71731 us to render. Now compare this to the Indivision GFX direct chunky graphics mode in 320x200, 256 colours:

Hiya Oliver,

This is very interesting. Can you tell us more about this. Is this going to be a new native chunky screen mode? If so are you going to patch the OS API's to use it (eg writeChunkyPixels)? In otherwords how to you use it in a game?

Thanks,
Nova

[Oliver_A]

Hi guys!

Thanks for your enthusiastic response! Some valid questions have been brought up here, which I am going to respond to.

How does this mode work? And where is the difference between this and the Grafitti mode?

As some people correctly pointed out, 320x200 in 256 colours is also possible in Grafitti mode. However, there is one very important difference. In order to display a 256 colour picture under Grafitti, one has to open a hires screen in 16 colours. Those, who know a bit how the Amiga chipset works, immediately realize that under OCS/ECS, any 16 colour hires screen causes Agnus to reserve all available memory slots for display DMA. That means, the CPU can only access the Chip Ram during the horizontal and vertical blanking interval, which effectively reduces memory bandwidth from 3.5 MB/s to under >1MB/s. If you have ever wondered why Deluxe Paint was always unbearable slow in hires 16 colours on an A500 without fast ram, this is the answer. The result is that Grafitti mode is not really useful for games on OCS/ECS machines, especially on 68030+ CPUs, where a chunky/planar routine is faster.

The new Indivision GFX mode (which btw. was introduced with V1.0 firmware) works completely different. Here, the Amiga video is completely disabled (as you can see in the first picture). Instead, the CPU writes directly to the 8MB SDRAM chunky framebuffer of the Indivision ECS flickerfixer. Since the Amiga display DMA is completely turned off, we get a 256 colour chunky screen with full 3.5MB/s access to it, exactly like a Zorro II graphics card.

Of course, this method has certain restrictions since the 8MB SDRAM is not memory mapped. Instead, you can only access it by setting up a write address and writing the data directly to a register, while the FPGA autoincrements the video address.

That means, in any case, where a game or application renders its display in fast ram, and then copies the result into the graphics memory of the graphics card, Indivision ECS is an equivalent replacement to a Zorro II graphics card. Whether I do a move.l (ax)+,(ay)+ or a move.l (ax)+,(ay) is completely irrelevant since it's the same speed. So, 3D games with software rendering can have the same speed on Indivision ECS than on a graphics card. Which is especially important on small Amigas without slots, like the A600. The upcoming ACA630 has a very fast interface to fast ram and chip ram.

Is there any API available? Is it possible to add native RTG support?

Currently, there is no API available. Since the framebuffer is not directly mapped into the Amiga memory map, a context-independent implementation is quite challenging. Any RTG driver would first have to render all pixel operations to fast ram, and then copy it into the SDRAM framebuffer. The only way I can imagine how this could be fast enough would be to copy only the display areas, where something has changed. One could imagine a graphics driver using the MMU to split the memory into segments. This is how some Shapeshifter video drivers work. Realistically, this would be a quite ambitious project, far exceeding the amount of work implementing support for Indivision ECS in various games. We'll see about that. At least, I already implemented a hardware sprite for a mouse pointer in the Indivision GFX core.

[chiark]

Wow. Excellent work! That is quite astonishing

The RTG driver would have to effectively blit the changes across to the framebuffer... However, your buffer isn't memory mapped so you'd have to render the whole frame unless you add appropriate calls to get to the right framebuffer location?

[fitzsteve]

@chiark

There's a buy back option on your Apollo 620 when these are released

[Amiga1992]

IN-fucking-credible.
I am totally down for the A600 accel!

[Cosmos]

>The new Indivision GFX mode (which btw. was introduced with V1.0 firmware) works completely different. Here, the Amiga video is completely disabled (as you can see in the first picture). Instead, the CPU writes directly
>to the 8MB SDRAM chunky framebuffer of the Indivision ECS flickerfixer. Since the Amiga display DMA is completely turned off, we get a 256 colour chunky screen with full 3.5MB/s access to it, exactly like a Zorro II graphics card

Will works with the Indivision AGA ??

[Cosmos]

And for the new Indivision AGA, please add an Akiko replica !

Thanks a lot !

[Schoenfeld]

Cosmos,

this thread is about the accelerators, not Indivision.

Unfortunately, Indivision ECS is substantially different from any other flickerfixer, even Indivision AGA. While Indivision AGA takes it's input from the Lisa output, Indivision ECS takes it's input directly from the chip bus, bypassing the Denise. This gives us the unique opportunity to also talk to the flickerfixer's infrastructure directly with the CPU. This data path does not exist on the AGA models, so neither C2P, nor direct Framebuffer access can be done. All gfx data has to take the re-route through chipmem. However, the new FPGA of Indivision AGA MK2 is most probably large enough for Graffiti emulation, so a chunky screen with 256 colours maintaining 7MB/s access speed to chipmem is more than possible.

Jens

[solaris104]

Schoenfeld: Do you plan highend turbo boards with MC68060FE133?