Amiga.org
Amiga computer related discussion => General chat about Amiga topics => Topic started by: nikodr on February 21, 2010, 01:31:01 PM
-
Reading the thread 3 worst idea in amiga developemt it came the idea of how some chips like the akiko were used.
I dont know of any (except one game that was wing commander ?) that used it.
If someone made a doom port for cd32 (like the many doom or quake ports that are out there),how fast could the akiko do the chunky to planar?
Can someone write a benchmark program with a custom c2p routine and test akiko on a cd32?
How much bandwidth does it use?How much data can it really handle?Is it faster with or without fast memory?
I always had this question....
-
5V * 0.8A = 4 Watts.
Oh not that power... you mean processing power?
The Akiko is shite. Should never have been made. A CD32 with fast memory can do C2P much faster using the CPU (in addition to all other tasks) than using the Akiko
Doom written to use the Akiko would be slower than an A1200 with fast memory and much much slower than an 030. Quake would be impossible. Not enough RAM, not enough CPU power.
-
Doom written to use the Akiko would be slower than an A1200 with fast memory and much much slower than an 030. Quake would be impossible. Not enough RAM, not enough CPU power.
Back in the early 90ies would it be any good if we had the akiko?
Would it help a stock 1200 have 256 color games ported from pc with no slowdowns?
-
Ah, but the CD32 didn't have fast RAM out-of-the-box. Given that the Akiko's never really been used, I think some empirical testing is in order:
1. Akiko vs. no Akiko
2. Akiko + fast RAM vs. no Akiko + fast RAM
3. Akiko vs. no Akiko + fast RAM
-
The figures I remember being quoted suggested that the akiko could do c2p at "copy speed". In other words, it could perform the c2p operation in the same amount of time that it would take to just copy the data to chip ram without any operations being performed on it. Once you hit that limit, no amount of "doing it faster" on the CPU is going to help, it'll just end up waiting to write the transformed data.
-
Ah, but the CD32 didn't have fast RAM out-of-the-box. Given that the Akiko's never really been used, I think some empirical testing is in order:
1. Akiko vs. no Akiko
2. Akiko + fast RAM vs. no Akiko + fast RAM
3. Akiko vs. no Akiko + fast RAM
I think that would be an excellent test.We have to remember that back in that area the game production was moving toward chunky style with 256 colors.
I can't understand some of Commodore's desicion's.Use a chunky to planar convertor while not giving any fast ram at all.
I think there is wing commander cd32 that uses akiko.What is the speed of it?
I know there is a special patch for accelerated amigas with fast ram for that game.
But back in the cd32 area with only 2mbytes did wing commander cd32 play the same speed as a fast equiped pc?
-
Would it help a stock 1200 have 256 color games ported from pc with no slowdowns?
Unlikely, even doom required too much ram.
Not to mention the 020 starving due to no fastmem. Stock A1200 crawls, no akiko can change that.
-
Has anyone ever tried running benchmark tests to compare the performance? I HAVE!
I have here an A1200 with an 8MB/FPU card, an A1200 with 32MB/030/FPU, and a CD32 with SX32 and 8MB/FPU. I ran the Doom benchmark test using DoomAttack, which seems to be the best DOOM port for lower-end machines. It needs more than 2MB RAM so I can't test it on an unexpanded CD32.
To run the test yourself, use this command line: DoomAttack -forcedemo -timedemo demo3
Here are the results I got:
A1200 030/50Mhz 32Mb (Optimised 020 C2P) - 8481 realtics (8.8 fps)
Amiga CD32 68020/14Mhz 8Mb (Optimised 020 C2P) - 18971 realtics (3.9 fps)
Amiga CD32 68020/14Mhz 8Mb (Optimised Akiko C2P) - 12872 realtics (5.8 fps)
So there you go, Akiko DOES work.
-
Here's more information about the Doom benchmark if anyone wants to give it a go: http://www.complang.tuwien.ac.at/misc/doombench.html
-
Cammy this is very interesting.I am going to the link you posted and read it.So it seems akiko can do something after all.!
-
So there you go, Akiko DOES work.
Girl Power! :hammer:
-
Did'nt microcosm and gloom deluxe make use of it as well?
Full Hardware details of Akiko are here
http://www.amiga-hardware.com/showhardware.cgi?HARDID=1449
and so technically you could say, every game made on the CD32 use it.
-
Here are the results I got:
A1200 030/50Mhz 32Mb (Optimised 020 C2P) - 8481 realtics (8.8 fps)
Amiga CD32 68020/14Mhz 8Mb (Optimised 020 C2P) - 18971 realtics (3.9 fps)
Amiga CD32 68020/14Mhz 8Mb (Optimised Akiko C2P) - 12872 realtics (5.8 fps)
So there you go, Akiko DOES work.
It makes a small difference, but nothing spectacular.
Also, when the actual game gets more complicated the amount of time spent on c2p conversion lets smaller and smaller, and so does the performance boost given by Akiko.
In short: Having akiko on existing A1200 systems would give no benefit whatsoever, except maybe in case of an 030 accelerator. If your system doesn't have an accelerator it is really too slow to run the game anyway. If your system does have an 040/060 accelerator it's as fast to use optimized c2p (they reach copyspeed (http://membres.multimania.fr/amycoders/sources/writepipe.html)) anyway.
-
Given the very simple way Akiko works (write chunky words to its registers and then read back/copy the planar converted data) it's no surprise the speed up is rather moderate. AFAIR there was some space left on the gate array that was to become Akiko and the developers tried to think up something useful. Well, they did, given the budget.
Something that would really have made a change:
- adding a c2p converter in front of Lisa's bus interface with on-the-fly conversion - no waste of bandwidth here
or better:
- adding a chunky mode to Lisa - was missing from AGA from the start
-
Given the very simple way Akiko works (write chunky words to its registers and then read back/copy the planar converted data) it's no surprise the speed up is rather moderate. AFAIR there was some space left on the gate array that was to become Akiko and the developers tried to think up something useful. Well, they did, given the budget.
Something that would really have made a change:
- adding a c2p converter in front of Lisa's bus interface with on-the-fly conversion - no waste of bandwidth here
or better:
- adding a chunky mode to Lisa - was missing from AGA from the start
If I understand this correctly, Akiko was the C2P equivalent of the FPU? Given that, I have a bitter taste over the Akiko. I would have thought you could have it actually operate on a segment of memory if it was going to be a grafted-on component. My thought was double- or triple-buffer (if the 2MB memory permitted), sick Akiko on the off-screen buffer, then switch.
Better to be integrated, as you say, in the existing custom chipset. Very sad, indeed.
-
If I understand this correctly, Akiko was the C2P equivalent of the FPU?
Do you mean the memory mapped mode w/ a 68000? That really is very similar. Sadly Akiko needs to be fed by the CPU and therefore somewhat thwarts the usual Amiga chip design of smart and efficient chips. But as mentioned earlier, the gate budget was very limited.
-
I remember playing the CD32 version of AB3D and it ran quite better than the AGA counterpart on a 020 with fast. However Akiko never was a big deal, i think it was designed more like a CD controller that could do some specific tasks aside than meant to be used for heavy processing tasks. However i always have been curious about how could
this chip had work on an A1200 with a 030 and doing C2P for Shapeshifter or PCTask.
-
@Piru
I lack knowledge about how Akiko works but wouldn't it allow the coder to write directly to chipmem groups of 8-32 pixels without relying in a chunkybuffer? wouldn't akiko work as a small buffer that converts chunkypixels to bitplanes? something like that perhaps would allow optimizing chipmem access more. I guess that writting to a chunkybuffer and later copying to chipmem may not be as fast as writting directly to chipmem.
-
- adding a chunky mode to Lisa - was missing from AGA from the start
Yep and then we could have got a chunky AGA WB :)
-
Eww! I don't want chunks in it!
-
@Piru
I lack knowledge about how Akiko works but wouldn't it allow the coder to write directly to chipmem groups of 8-32 pixels without relying in a chunkybuffer? wouldn't akiko work as a small buffer that converts chunkypixels to bitplanes? something like that perhaps would allow optimizing chipmem access more. I guess that writting to a chunkybuffer and later copying to chipmem may not be as fast as writting directly to chipmem.
One problem with the akiko c2p is that it forced you to convert 32 consecutive 8-bit pixels (8 32-bit words) into 8 32-bit planar words. That's actually fine if your application renders spans of pixels sequentially. However, a lot of the 3D engines of the day used column rendering to texture vertical surfaces. If your application needs this sort of thing, in the end, you end up having to render everything into a fast ram buffer and then doing a c2p pass over the entire buffer. Since the CPU then has to read the data back from the fast ram buffer and feed it into the akiko,, read it back and then shovel it into the bitplanes. All that shuffling can end up using almost as much CPU as a good software C2P routine. On faster processors, pure software c2p ends up being the most effective method.
-
It makes a small difference, but nothing spectacular.
Amiga CD32 68020/14Mhz 8Mb (Optimised 020 C2P) - 18971 realtics (3.9 fps)
Amiga CD32 68020/14Mhz 8Mb (Optimised Akiko C2P) - 12872 realtics (5.8 fps)
5.8/3.9=149% sped boost in frame rate. People spend big dollars on a 25% frame rate improvement on modern graphics cards. You get 50% increase in frame rate for free with Akiko. whereas a 50 mhz '030 with 32 meg ram at the time could have cost about $1800, with the ram costing about half of that. Sure prices came down, but that was years after the CD32 was released.
-
Amiga CD32 68020/14Mhz 8Mb (Optimised 020 C2P) - 18971 realtics (3.9 fps)
Amiga CD32 68020/14Mhz 8Mb (Optimised Akiko C2P) - 12872 realtics (5.8 fps)
5.8/3.9=149% sped boost in frame rate. People spend big dollars on a 25% frame rate improvement on modern graphics cards. You get 50% increase in frame rate for free with Akiko. whereas a 50 mhz '030 with 32 meg ram at the time could have cost about $1800, with the ram costing about half of that. Sure prices came down, but that was years after the CD32 was released.
Most people that have graphics cards aren't using them on a 68020 so your comparison isn't valid. The speed up for my 040 on an RTG card over AGA was immediately obvious.
-edit-
Oh wait, you are referring to modern cards on other systems, not RTG versus AGA. Yeah, you have a point. I currently have a GTX260, hopefully I won't get any newer card that isn't at least 50% faster.
-
Most people that have graphics cards aren't using them on a 68020 so your comparison isn't valid. The speed up for my 040 on an RTG card over AGA was immediately obvious.
-edit-
Oh wait, you are referring to modern cards on other systems, not RTG versus AGA. Yeah, you have a point. I currently have a GTX260, hopefully I won't get any newer card that isn't at least 50% faster.
Yep I meant that akiko gave you a 50% increase in frame rate for essentially nothing. And I have seen people spend hundreds of dollars on a PC graphics card to get less than 50% frame rate improvement. And when you consider the price of fast ram, or worse still an '030 card AND fast ram at the time, you realise that akiko gave quite a bit of bang for your buck. If Akiko was built into A1200's, it would have been used a lot more.
-
hello everybody
fortuneatly i have a SX32Pro in my CD32 and i can test adoom speed with 030 CPU and akiko
but i cant find for download ready for launch doomattack port,
i found patch files for a normal adoom, but i cant run it
message appers after load WAD file "cant create screen ",
i set stack for 20000, and i choose correct c2p file in prefs file
Cammy, can you send me ready and working version of doom attack ?
my priv : goer21@wp.pl
PS. sorry for my english
PS2. everybody know how to install 128 Meg module in SX32Pro, in instruction from DCE is written that 64 mb is maximum
-
@Blizzard-pl
First, welcome aboard :)
I was actually just thinking it'd be interesting to see how much akiko helps with an sx32 pro, so I look forward to seeing your results.
@thread
I seem to recall one of the gloom games having support for akiko c2p? Could be another interesting test, although is there any way to benchmark it?
-
Hello everyone!
I have bundled DoomAttack with the better MIDI instruments file, the shareware DOOM wad, and configured it for the best settings on an A1200. Anyone is welcome to download it and give it a try, it's ready to go! If it's a little slow, run DoomAttackPrefs and disable the music by removing the text from the music plugin string, hitting Enter, and saving the prefs. I have run extensive tests on all of my Amigas and found the best results for video are the Blitter C2P (or Akiko on the CD32) and the best music plugin is the MIDI one, not the doomsound.library one. Just in case anyone was curious, here are the results I got from running the Doom Benchmark on all my Amigas:
DoomAttack
Amiga A1200 020/14Mhz 8Mb (Optimised 020 C2P) - 22976 realtics (3.3 fps)
Amiga A1200 020/14Mhz 8Mb (Blitter 020 C2P) - 20660 realtics (3.6 fps)
Amiga CD32 68020/14Mhz 8Mb (Optimised 020 C2P) - 18971 realtics (3.9 fps)
Amiga CD32 68020/14Mhz 8Mb (Akiko Optimised C2P) - 12872 realtics (5.8 fps)
Amiga A1200 030/28Mhz 64Mb (Optimised 020 C2P) - 17732 realtics (4.2 fps)
Amiga A1200 030/28Mhz 64Mb (Blitter 020 C2P) - 12727 realtics (5.8 fps)
Amiga A1200 030/50Mhz 128Mb (Optimised 020 C2P) - 8696 realtics (8.6 fps)
Amiga A1200 030/50Mhz 128Mb (Blitter 020 C2P) - 8296 realtics (9.0 fps)
ADoom
Amiga A1200 020/14Mhz 8Mb (AGA 68020 C2P) - 22984 realtics (3.2 fps)
Amiga A600 030/30Mhz 64Mb (EHB 68030 C2P) - 17886 realtics (4.2 fps)
Amiga CD32 68020/14Mhz 8Mb (AGA 68020 C2P) - 16294 realtics (4.6 fps)
Amiga A1200 030/28Mhz 64Mb (AGA 68030 C2P) - 14430 realtics (5.2 fps)
Amiga A1200 030/50Mhz 128Mb (AGA 68030 C2P) - 9133 realtics (8.2 fps)
Remember, these results are running the game in High Detail mode, in almost full-screen. The game will run faster in Low Detail mode in a smaller sized screen of course. Leaving the music on also makes a considerable performance hit so I turn it off during benchmark tests, since a PC wouldn't be using extra CPU to emulate Midi either so it's not fair on the Amiga to leave it on when testing the speed of the game engine. Anyway, here it is: Amiga Doom (DoomAttack) (http://home.exetel.com.au/~amiga/Doom.lha)
-
@Cammy
Your downloaded archive contained corrupt files. Lha reported...
*** Error on file 'Midi_Instruments' : I/O Error
I re-downloaded the archive but had the same error. It might be worth checking your archive.
DoomAttack with the timedemo (no sound) works but gave an error and no fps...
Error: timed 2134 gametics in 2420 realtics
ADoom with the timedemo (and sound) works and gives me an error but shows the fps...
Error: timed 2134 gametics in 1869 realtics ( 40.0 fps)
The closest "competitor" on the Doom benchmark list happens to be an Amiga with PPC604E-150 at 2x the clock speed and 4x the CPU cache as my lowly 68060 ;). The Natami 060 and fpga processors could be up to 2x as fast as me too.
-
I think that would be an excellent test.We have to remember that back in that area the game production was moving toward chunky style with 256 colors.
I can't understand some of Commodore's desicion's.Use a chunky to planar convertor while not giving any fast ram at all.
I think there is wing commander cd32 that uses akiko.What is the speed of it?
I know there is a special patch for accelerated amigas with fast ram for that game.
But back in the cd32 area with only 2mbytes did wing commander cd32 play the same speed as a fast equiped pc?
Forget it even exists, one of the worst bits of coding ever seen. Barely improved over crappy A500 version. Luckily the game is c0ck anyway :roflmao:
-
Wing Commander is a class game, and totally playable on the CD32!
-
It makes a small difference, but nothing spectacular.
Also, when the actual game gets more complicated the amount of time spent on c2p conversion lets smaller and smaller, and so does the performance boost given by Akiko.
In short: Having akiko on existing A1200 systems would give no benefit whatsoever, except maybe in case of an 030 accelerator. If your system doesn't have an accelerator it is really too slow to run the game anyway. If your system does have an 040/060 accelerator it's as fast to use optimized c2p (they reach copyspeed (http://membres.multimania.fr/amycoders/sources/writepipe.html)) anyway.
You miss the point, big deal a 486 33mhz requiring game requires an 040 25mhz Amiga shocker.
The benchmarks show a 50% speed improvement. So if you wrote any game engine and it managed 13-15fps on A1200 sans Akiko you can make it run 22fps for free on Akiko. The issue is 95% of Amiga games had sloppy n00b coding.
Both A1200 and CD32 should have had a single SIMM slot to add fast ram AND Akiko.
040 50mhz card = £799 in 1992 so stop going off topic.
-
Given the very simple way Akiko works (write chunky words to its registers and then read back/copy the planar converted data) it's no surprise the speed up is rather moderate. AFAIR there was some space left on the gate array that was to become Akiko and the developers tried to think up something useful. Well, they did, given the budget.
Something that would really have made a change:
- adding a c2p converter in front of Lisa's bus interface with on-the-fly conversion - no waste of bandwidth here
or better:
- adding a chunky mode to Lisa - was missing from AGA from the start
OR just scrap Amiga compatibility and make it all 8/16/24bit chunky pixel modes only (as compatibility is the whole reason AGA was a luke warm minor upgrade...2 years too late). Chunky AND planer doesn't mix and is hugely epensive....ie AAA chipset trainwreck.
-
Most people that have graphics cards aren't using them on a 68020 so your comparison isn't valid. The speed up for my 040 on an RTG card over AGA was immediately obvious.
-edit-
Oh wait, you are referring to modern cards on other systems, not RTG versus AGA. Yeah, you have a point. I currently have a GTX260, hopefully I won't get any newer card that isn't at least 50% faster.
Think the point is you get something for nothing, in 1992 a SIMM slot for A1200 fast ram and Akiko would have helped sales against £999 386DX 25/33mhz PCs.
Commodore didn't go bankrupt because nobody wrote Doom style games for Retina or Picasso graphics card equipped 33mhz 040s you know ;)
A1200 was not thought out properly, a SIMM slot costing 50 pence would have allowed users to easily double the speed of the new fashionable Doom style crap popping up everywhere and if Akiko was on the motherboard too thats 50% for Akiko and 100% for CPU speed increase for the price of a 512kb SIMM purchase compared to what we were stuck with. And luckily for us because Amiga games were so badly programmed most of that increase in speed is automatic.
A1200 had no Akiko option and bare FAST RAM cards alone were £125 with no memory included for A1200s and CD32 was an 'unexpandable toy' unless you spent another £300 on an SX32 type device. £650 for a 14mhz computer vs £999 for a 40mhz one with monitor and 16bit sound card from Win/Tel world.
Commercial suicide. Can you imagine Sega or Nintendo or Sony getting themselves in that situation? Exactly.
Sad thing is the A1400 (A1200 with CD drive and 28mhz 020 and 2mb Fast Ram in A3000 style 3 piece case design was nearly ready for 3rd quarter 94).
-
@Cammy
Your downloaded archive contained corrupt files. Lha reported...
*** Error on file 'Midi_Instruments' : I/O Error
I re-downloaded the archive but had the same error. It might be worth checking your archive.
DoomAttack with the timedemo (no sound) works but gave an error and no fps...
Error: timed 2134 gametics in 2420 realtics
ADoom with the timedemo (and sound) works and gives me an error but shows the fps...
Error: timed 2134 gametics in 1869 realtics ( 40.0 fps)
The closest "competitor" on the Doom benchmark list happens to be an Amiga with PPC604E-150 at 2x the clock speed and 4x the CPU cache as my lowly 68060 ;). The Natami 060 and fpga processors could be up to 2x as fast as me too.
I got the same error. I disabled the sound.
It seems to run really slow on my 1200 and I'd expect better from an 060.
anyway, how do you start the timedemo...
-
The issue is 95% of Amiga games had sloppy n00b coding.
I wouldn't say 95%. There were some very good Amiga programmers too.
Both A1200 and CD32 should have had a single SIMM slot to add fast ram AND Akiko.
The CD32 should have had 1 SIMM slot, IDE and PCMCIA. I would have traded those for Akiko any day. Better yet would have been Akiko plus SIMM, IDE and PCMCIA. Surely that would have only cost a couple of dollars.
It seems to run really slow on my 1200 and I'd expect better from an 060.
The 060 speed is reasonable for a port written in C. Yea, the 060 was better than the Pentium at integer but the game was optimized for the x86. I'm sure a little 060 assembler could speed things up. ADoom is very playable upscaled to 640x400 (~11 fps by timedemo) on my Amiga which looks MUCH nicer so what is the point? The actual game plays much faster than the timedemo for some reason. I would say I'm getting >20 fps at 640x400 judging by how Quake feels at 20 fps on my Amiga.
anyway, how do you start the timedemo...
To run the test yourself, use this command line: DoomAttack -forcedemo -timedemo demo3
-
A1200 was not thought out properly, a SIMM slot costing 50 pence would have allowed users to easily double the speed of the new fashionable Doom style crap popping up everywhere and if Akiko was on the motherboard too thats 50% for Akiko and 100% for CPU speed increase for the price of a 512kb SIMM purchase compared to what we were stuck with. And luckily for us because Amiga games were so badly programmed most of that increase in speed is automatic.
A SIMM slot doesn't do you any good without a RAM controller to go with it.
And there was no "fashionable Doom style crap popping up everywhere" because Doom came out a year after the A1200.
-
it gets an error but says
2134 gametics in 15115 realtics
anyway, this is not the killer app I upgraded past my 030/40 for...
-
2134 gametics in 15115 realtics
That should be 5.4 to 5.5 fps based on Cammy's numbers assuming a linear result. I bet the game is playable though where 5.5 fps would not be. The actual game seems like it has twice the frame rate of the timedemo.
-
The formula for FPS is:
gametics / realtics * 35
So 2134 / 15115 * 35 = 4.94 FPS
(well, for the DOS version anyway. I assume the amiga version treats timedemos the same way)
A timedemo renders every frame in the demo and tells you how long it took (in realtics). Number of gametics will always stay the same for each demo file. During normal gameplay doom will skip frames to keep the speed up, this is why the timedemo is much slower than the actual game.
-
That should be 5.4 to 5.5 fps based on Cammy's numbers assuming a linear result. I bet the game is playable though where 5.5 fps would not be. The actual game seems like it has twice the frame rate of the timedemo.
well, i think it runs better under shapeshifter.
seriously, should it not be faster on an 060?
-
Well, if matthey is right and this is just a straight recompile from source, it's understandable that it wouldn't run all that great (though it depends on what compiler is used.) What I'm a little surprised at is that nobody's done a 68k-optimized version yet...
-
@DonutKing
Thanks. That sounds reasonable.
seriously, should it not be faster on an 060?
Are you saying you have a 68060 and you're only getting 5 fps? I'm getting 40fps with ADoom using 68060@75MHz. ADoom was fastest on my system using...
adoom -forcedemo -timedemo demo3 -cpu 68060
@commodorejohn
There are CPU optimized versions of part of the code but that probably just means that it was compiled for the 68060 which doesn't mean much. Assembler for the 060 by someone who knows what they are doing will usually result in a 50% speed increase from 060 compiled code I've seen. The c2p routines are probably assembler but I'm using a gfx board which skips this.
-
Are you saying you have a 68060 and you're only getting 5 fps? I'm getting 40fps with ADoom using 68060@75MHz. ADoom was fastest on my system using...
yes. it runs that slow. I have a Bliz1260 50mhz with 64MB ram.
-
yes. it runs that slow. I have a Bliz1260 50mhz with 64MB ram.
I had the same problem. It turned out I wasn't running the 060 executable.
-
yes. it runs that slow. I have a Bliz1260 50mhz with 64MB ram.
There's something wrong with your setup. In the Doom benchmark page, there is an Amiga 1200 with 060@50MHz using AGA getting 24.6 fps and even a 1200 with 040@40MHz using AGA getting 13.4 fps. You should be at least 20fps. Here is my setup...
All 060 caches turned on and MAPROM off (for BlizKick) in accelerator menu (ESC)
AmigaOS 3.9 BB4
"BlizKick myROM QUIET" line in S:Startup-Sequence using my custom made 3.9 ROM
ThoR's MuLibs installed (http://aminet.net/util/libs/MMULib.lha)
"MuFastZero MOVESSP ON" line added to S:Startup-Sequence for above
CopyMem installed (http://aminet.net/util/boot/CopyMem.lha)
The most likely problems would be incorrectly installed 68040 and 68060 libraries and not turning on the caches. The 68040.library in Libs: should be tiny. Mine is 748 bytes. If yours is over 1k then that is your problem. Open a shell and type "CPU" . You should see "System: 68060 68882 (INST: Cache Burst) (DATA: Cache CopyBack)". If these are fine, then try removing programs from your WBStartup, S:User-Startup and S:Startup-Sequence that might be causing a slow down.
Edit: I installed the 060 executable for Doom Attack and it made a large difference. I now get 1945 realtics (38.4 fps) instead of 2420 realtics (30.9 fps). ADoom is still faster though. The Doom Attack manual does mention removing divsu.l and divsl.l instructions because he thought they didn't exist on the 68060 but they do (the 68060 manual is not clear in some places) and his compiler did not support the 060 at all. The executables probably do contain some assembler which does provide a speed increase. There is probably room for improvement and the source is on Aminet. Here is Doom Attack with CPU specific executables...
http://aminet.net/game/shoot/DoomAttack.lha
-
There's something wrong with your setup. In the Doom benchmark page, there is an Amiga 1200 with 060@50MHz using AGA getting 24.6 fps and even a 1200 with 040@40MHz using AGA getting 13.4 fps. You should be at least 20fps. Here is my setup...
All 060 caches turned on and MAPROM off (for BlizKick) in accelerator menu (ESC)
AmigaOS 3.9 BB4
"BlizKick myROM QUIET" line in S:Startup-Sequence using my custom made 3.9 ROM
ThoR's MuLibs installed (http://aminet.net/util/libs/MMULib.lha)
"MuFastZero MOVESSP ON" line added to S:Startup-Sequence for above
CopyMem installed (http://aminet.net/util/boot/CopyMem.lha)
The most likely problems would be incorrectly installed 68040 and 68060 libraries and not turning on the caches. The 68040.library in Libs: should be tiny. Mine is 748 bytes. If yours is over 1k then that is your problem. Open a shell and type "CPU" . You should see "System: 68060 68882 (INST: Cache Burst) (DATA: Cache CopyBack)". If these are fine, then try removing programs from your WBStartup, S:User-Startup and S:Startup-Sequence that might be causing a slow down.
FaLLeNOnE was correct. The problem was with the DoomAttack executable. I downloaded the DoomAttack package from aminet and the 060 one is much better...
2134 gametics 3385 realtics
I have never been able to use MuFastZero on my 1260, says the zero page is already remapped.
I use WB 3.1 with ClassicWB ADV
I am using blizkick and I'll look into CopyMem.
Anyway I have created an icon/script to run the timedemo. I was getting tired of retyping...
thanks
_nate
-
Chunky AND planer doesn't mix and is hugely epensive....ie AAA chipset trainwreck.
VGA did it, which is what AGA was supposed to compete with.
AAA was a trainwreck because engineering and management had a disfunctional relationship. There was no way that AAA was ever going to be financially successful, but they burned money on it for years.
Adding chunky to AGA during it's design phase would have been free in comparison to the money spent on AAA.
And adding a texture mapper would have saved them.
-
You miss the point, big deal a 486 33mhz requiring game requires an 040 25mhz Amiga shocker.
The benchmarks show a 50% speed improvement. So if you wrote any game engine and it managed 13-15fps on A1200 sans Akiko you can make it run 22fps for free on Akiko. The issue is 95% of Amiga games had sloppy n00b coding.
I think it's you that has rather missed the point. The 50% it gave for an 020 won't scale upwards linearly with faster systems. Akiko gave a 50% speed increase on slow systems where the time it takes to do C2P per frame is comparable to the time it takes to do everything else, that is to say, systems which are too slow to run the game at all. Going from 3FPS to 5FPS doesn't at all imply a 15FPS game will go to 22FPS.
For an engine of a given complexity, as the CPU gets faster, the portion time it takes to do C2P on the CPU becomes less and less of the overall time of execution time until you hit the magical copyspeed bottleneck. At that point, performing C2P takes no more processor time than simply copying data from Fast RAM to Chip RAM.
Some fast 030 C2P routines are already approaching copyspeed, once you start using 040, they get there. On these systems, using an Akiko would likely result in an even slower FPS count than a copyspeed software C2P routine. The reason for that is the way Akiko works. You have to write your chunky data to it, then read back the planar result then write that to Chip RAM all using the CPU. All that copying back and forth takes longer than simply reading the source data from Fast RAM, transforming it then writing it to Chip RAM.
At copyspeed for AGA, even an infinitely fast CPU/Fast RAM combination (where the Chip RAM write speed of ~7MB/s becomes the only rate limiting factor) would be limited to around 90fps at 320x256 for 256 colours.
Doom uses a fairly simple (and efficient) 2D BSP and optimised column and span texturing routines for walls and floors and a sprite routine for objects, each of which has been pretty well-tuned. For more complex game engines, the time taken to render the frame becomes dominant and so C2P time becomes even less important. Take Quake for example. Here you have a full 3D BSP and a much more general-case textured/shaded/depth-buffered polygon rendering system. All much more CPU work than Doom. On 68K, eliminating the C2P all together (i.e. using an RTG card) only gives a comparatively small increase in fps over AGA. For 603/604 PPC systems, you see a bigger improvement because they are able to render the frame significantly faster than the 040/060 can and the whole argument about time spent rendering versus time spent C2P/copying becomes relevant again.
-
Doom uses a fairly simple (and efficient) 2D BSP and optimised column and span texturing routines for walls and floors and a sprite routine for objects, each of which has been pretty well-tuned.
Just curious, you make it sound like Doom has separate rendering code for sprites? I guess I'd kinda figured it'd just reuse the column routine, since that's capable of transparency anyway.
-
For 603/604 PPC systems, you see a bigger improvement because they are able to render the frame significantly faster than the 040/060 can and the whole argument about time spent rendering versus time spent C2P/copying becomes relevant again.
I agree with your point about c2p becoming a smaller percentage of CPU usage as the CPU becomes faster. I'm not so sure that the 603/604 PPC on the Phase5 boards were significantly faster than the 68060. I obtained the same results of 40 fps in the timedemo test with 68060 at 1/2 the clock speed as an Amiga with 604e. The 68060 can compete with and sometimes win in a competition with a RISC processor at 2x the speed. The 2x faster clock speed, 4x greater CPU cache and faster memory access of the PPC looks better on paper and advertisements than real life results show. It was a while before the low end PPC macs even outperformed the 68040@40MHz. The code and compilers continued to improve for the PPC as that was the focus of marketing and development while the 68060 was abandoned before it's limits were explored on any desktop platform. On the Amiga, the bottlenecks in WarpUp and the poor PPC optimization in AmigaOS 4.x certainly remove any significant speed advantage of the PPC beyond clocking it up. Do you want to buy this CPU with a 2GHz CPU or this one with a 3GHz CPU? The vast majority of people will think the 3GHz sounds faster so it should play games faster and it doesn't even cost 50% more.
-
Just curious, you make it sound like Doom has separate rendering code for sprites? I guess I'd kinda figured it'd just reuse the column routine, since that's capable of transparency anyway.
It might do, but sprites are a special case as they are always "face on" and thus don't require anything beyond scaling - certainly not the recalculation of scale per column that walls do. It would seem an obvious case where an optimisation could be made.
I'm not so sure that the 603/604 PPC on the Phase5 boards were significantly faster than the 68060
I only mentioned PPC from the perspective of Quake, not Doom, as Quake is an example of an engine where even the fastest 68K spends most of it's time doing something other than C2P or copying data to the video device.
On 68060, using C2P+AGA versus an RTG board shows only a modest performance increase, since doing C2P takes only a small fraction of the overall time per frame. When you move up to PPC, going from C2P+AGA to RTG (at least when the bus is suitably faster than AGA, such as BVisionPPC/CVision/GRexx), you observe a more noticeable increase.
Still, now that you mention it, the 040 version of DoomAttack runs significantly faster on my 603e under emulation. Fast enough for 640x400 (RTG) to be playable (only the transition effects are slow):
[youtube]AQ1t5q3xmYk[/youtube]
Out of curiosity, how is it at 640x400 RTG with 68060 (I can't test as I only have 040, but it's cripplingly slow for me at that resolution)?
-
It might do, but sprites are a special case as they are always "face on" and thus don't require anything beyond scaling - certainly not the recalculation of scale per column that walls do. It would seem an obvious case where an optimisation could be made.
Oh. Thought you were talking about the column renderer specifically.
Though I suppose it might help to have a separate column renderer for sprites and walls with transparency in their textures, only I don't know if Doom marks those specially or not.
-
Out of curiosity, how is it at 640x400 RTG with 68060 (I can't test as I only have 040, but it's cripplingly slow for me at that resolution)?
ADoom at 640x400 RTG (Mediator with Voodoo 4 and no gfx bus overclocking) is ~11 fps using the timedemo test on my 68060@75MHz. The actual game play feels a little faster than Quake at 20 fps (HW 3D) on the same setup. It takes VERY heavy combat situations to perceive any slow down at all. There is no slow down just walking around, turning and shooting a barrel like in your video, or was that my slow 1.86 GHz Windows machine pausing just playing the low resolution video :/. That would be a good show for a 68040 though. I'm surprised Doom Attack worked at 640x400 as the docs say it doesn't support increasing the horizontal resolution.
-
ADoom at 640x400 RTG (Mediator with Voodoo 4 and no gfx bus overclocking) is ~11 fps using the timedemo test on my 68060@75MHz.
Mediator1200 or Mediator4000?
The actual game play feels a little faster than Quake at 20 fps (HW 3D) on the same setup. It takes VERY heavy combat situations to perceive any slow down at all. There is no slow down just walking around, turning and shooting a barrel like in your video, or was that my slow 1.86 GHz Windows machine pausing just playing the low resolution video :/. That would be a good show for a 68040 though.
It wasn't an 040, it was the 040 executable running under OS4's emulation on a 603e. The device recording the footage was a bit slow too. My old mouse was acting up, has a tendency to move in jumps (you can see that when opening the preferences application and it overshoots). The performance of the game itself was pretty consistent.
I'm surprised Doom Attack worked at 640x400 as the docs say it doesn't support increasing the horizontal resolution.
Give it a bash, seems to work regardless :)
-
Mediator1200 or Mediator4000?
Mediator 3000T/4000T (works through Zorro II/III slots but only 6-8 MB/s as I recall)
It wasn't an 040, it was the 040 executable running under OS4's emulation on a 603e. The device recording the footage was a bit slow too. My old mouse was acting up, has a tendency to move in jumps (you can see that when opening the preferences application and it overshoots). The performance of the game itself was pretty consistent.
The PPC emulation in AmigaOS 4.x is fast at least. Maybe AmigaOS 4.x should just use emulated 68k code as applets like Android OS uses java ;). The faster 604 CyberStorm PPCs should be close to emulating the 68k at 68060 speed with 3x the clock speed, 4x the cache, over 2x the memory bandwidth and much more memory needed. That's progress though :/.
-
Mediator 3000T/4000T (works through Zorro II/III slots but only 6-8 MB/s as I recall)
Hmm, I thought it was at least faster than the 1200 version.
The PPC emulation in AmigaOS 4.x is fast at least. Maybe AmigaOS 4.x should just use emulated 68k code as applets like Android OS uses java ;). The faster 604 CyberStorm PPCs should be close to emulating the 68k at 68060 speed with 3x the clock speed, 4x the cache, over 2x the memory bandwidth and much more memory needed. That's progress though :/.
Emulation is a funny thing. Sometimes it's faster, sometimes it isn't, it all depends.
-
I can't test as I only have 040, but it's cripplingly slow for me at that resolution
Data cache size? Or is it rendering to framebuffer directly (in which case the writes would be going to cache inhibited memory anyway...)? If I remember correctly there was some specific resolutions that were optimal for the specific cache configurations, while other resolutions were way worse.
Speaking of emulation: MorphOS JIT was significantly faster than the parent 68k from very early on. Even the slowest 603 can easily beat 060@50 in pretty much everything.
-
Data cache size? Or is it rendering to framebuffer directly (in which case the writes would be going to cache inhibited memory anyway...)?
Not sure with DoomAttack, to be honest. I doubt it's rendering to the framebuffer directly, given the way Doom renders the scene columns at at a time. You'd at least want to use a buffer that could hold say four 8-bit pixel columns so that you could then transfer them as 32-bit words over the bus. That would be 800 bytes for a 200 pixel display. Or 1600, if you wanted to have a nice 16 column, cache-aligned wide buffer :)
-
Speaking of emulation: MorphOS JIT was significantly faster than the parent 68k from very early on. Even the slowest 603 can easily beat 060@50 in pretty much everything
I don't doubt it, at least for anything processor intensive. There's little that can be done for the rest of the system though. Slow buses, in particular.
My remark about emulation performance was intended to be a general observation, not specific to emulation of 68K under OS4. There is the expectation that whenever you emulate something - particularly via any sort of JIT mechanism - that the result is going to be faster as long as the host processor is faster. It isn't always the case, however. How is 6888x extended precision floating point performance, for example? IIRC, the PPC only supports 64-bit IEEE 754, so any accurate emulation is probably going to end up hampered trying to find interesting ways of handling the extra precision. Or, is it (as I suspect) the case that only extended precision read/write are really emulated and any extended precision operations are all carried out at 64-bit instead?
-
Not sure with DoomAttack, to be honest. I doubt it's rendering to the framebuffer directly, given the way Doom renders the scene columns at at a time. You'd at least want to use a buffer that could hold say four 8-bit pixel columns so that you could then transfer them as 32-bit words over the bus. That would be 800 bytes for a 200 pixel display. Or 1600, if you wanted to have a nice 16 column, cache-aligned wide buffer :)
Ah the cache size vs resolutions were discussed in the PPC ADoom port readme:
http://www.aminet.net/game/shoot/ADoomPPC.readme
Dunno where that overflow comes from though and how you'd go on calculating fast/slow resolutions for various 68k.
-
How is 6888x extended precision floating point performance, for example? IIRC, the PPC only supports 64-bit IEEE 754, so any accurate emulation is probably going to end up hampered trying to find interesting ways of handling the extra precision. Or, is it (as I suspect) the case that only extended precision read/write are really emulated and any extended precision operations are all carried out at 64-bit instead?
You're right, for performance reasons all FPU calculations are performed by using the native FPU datatypes. This means that the FPU does give slightly different results under emulation. It's fast though.
-
You're right, for performance reasons all FPU calculations are performed by using the native FPU datatypes. This means that the FPU does give slightly different results under emulation. It's fast though.
Which is fair enough. Other than a few esoteric fractal generators, did anything use extended precision?
I know there are methods of doubling up (if you'll pardon the pun) and using two floats to represent a number with greater precision, though I can't recall the specifics at the moment.
-edit-
Yep, I remember now, it was for GPGPU stuff where real double precision may not be supported (or, it might be too slow):
http://forums.nvidia.com/index.php?showtopic=73067
-
So, getting back on topic: Akiko is great if you need to do C2P on a CPU as weak as the one the CD32 ships with. Unfortunately, that also tends to imply that you are restricted to very simple engines since the moment you've got a 50MHz 030 expansion in there, it might be faster just to use CPU C2P...
-
Which is fair enough. Other than a few esoteric fractal generators, did anything use extended precision?
Yes. All fp values are extended to extended precision in registers and all calculations use extended precision on the 68k FPU unless specified to use less precision. More precision means less chance of rounding and cumulative errors and there is no speed difference so it's generally best to keep the extra precision and round the value to the needed precision before storing or outputting. Even the 68060 which traps extended precision immediate floats still does full extended precision fpu calculations and register updates. Very few programs rely on the extra precision of the floating point.
I have heard that the CD32 patched graphics.library/WriteChunkyPixels() to use the Akiko so it might have transparently sped up more programs than Wing Commander while not making them incompatible to non CD32 Amigas. The docs for this function mention installing and using HW chunky to planar although it's a bit cryptic.
-
I'm really sorry, everyone! I checked the archive on the FTP and it was incomplete, I guess it never finished uploading the first time. I have re-uploaded it and checked that it's the right size now, so if anyone would like to try and re-download it, it should work fine now.
I'm very sorry for linking to a bad archive.
-
I'm really sorry, everyone! I checked the archive on the FTP and it was incomplete, I guess it never finished uploading the first time. I have re-uploaded it and checked that it's the right size now, so if anyone would like to try and re-download it, it should work fine now.
I'm very sorry for linking to a bad archive.
Cammy,
I tried to download it again and this time I got "unexpected end of archive". Maybe it just still uploading? I'll try again later...
thanks
_nate
-
Please try again, I've re-uploaded it from my Amiga just to be sure, and then re-downloaded and extracted it.
-
Yes. All fp values are extended to extended precision in registers and all calculations use extended precision on the 68k FPU unless specified to use less precision.
I realise that, what I meant was, are there many applications which depend on being able to use the additional precision? I know some fractal generators used "long double" types for increased precision at high magnification, but were there any others?
-
I have heard that the CD32 patched graphics.library/WriteChunkyPixels() to use the Akiko so it might have transparently sped up more programs than Wing Commander while not making them incompatible to non CD32 Amigas.
I was under the impression that commodore only documented using Akiko by calling WriteChunkyPixels.
-
I was under the impression that commodore only documented using Akiko by calling WriteChunkyPixels.
Didn't the CD32 version of WingCommander need patching to run on regular Amiga's though? It could have easily been other incompatibilities than using the Akiko directly. I wouldn't be too surprised to see a game use undocumented programming to give a speed increase. A more impressive game was a competitive advantage as long as it worked on the majority of hardware, in many game developers minds.
-
I think it's you that has rather missed the point. The 50% it gave for an 020 won't scale upwards linearly with faster systems. Akiko gave a 50% speed increase on slow systems where the time it takes to do C2P per frame is comparable to the time it takes to do everything else, that is to say, systems which are too slow to run the game at all. Going from 3FPS to 5FPS doesn't at all imply a 15FPS game will go to 22FPS.
For an engine of a given complexity, as the CPU gets faster, the portion time it takes to do C2P on the CPU becomes less and less of the overall time of execution time until you hit the magical copyspeed bottleneck. At that point, performing C2P takes no more processor time than simply copying data from Fast RAM to Chip RAM.
Some fast 030 C2P routines are already approaching copyspeed, once you start using 040, they get there. On these systems, using an Akiko would likely result in an even slower FPS count than a copyspeed software C2P routine. The reason for that is the way Akiko works. You have to write your chunky data to it, then read back the planar result then write that to Chip RAM all using the CPU. All that copying back and forth takes longer than simply reading the source data from Fast RAM, transforming it then writing it to Chip RAM.
At copyspeed for AGA, even an infinitely fast CPU/Fast RAM combination (where the Chip RAM write speed of ~7MB/s becomes the only rate limiting factor) would be limited to around 90fps at 320x256 for 256 colours.
Doom uses a fairly simple (and efficient) 2D BSP and optimised column and span texturing routines for walls and floors and a sprite routine for objects, each of which has been pretty well-tuned. For more complex game engines, the time taken to render the frame becomes dominant and so C2P time becomes even less important. Take Quake for example. Here you have a full 3D BSP and a much more general-case textured/shaded/depth-buffered polygon rendering system. All much more CPU work than Doom. On 68K, eliminating the C2P all together (i.e. using an RTG card) only gives a comparatively small increase in fps over AGA. For 603/604 PPC systems, you see a bigger improvement because they are able to render the frame significantly faster than the 040/060 can and the whole argument about time spent rendering versus time spent C2P/copying becomes relevant again.
Simple point is nobody bought 040s to play games 68030 was a minimal improvement mhz per mhz over 020 ergo A4000/030 25mhz was slow and dead end for games.
My point is spot on thanks. So getting back on topic in relevance to A1200 and CD32 (ie 1992 and 1993) chunky screen gaming, and accepting the known fact that A1200 had to compete out of the box for less than half the price of a 386DX for £899 with monitor blah blah...... if you wanted Wolfenstein style games having Akiko in A1200 rather than not would have made a difference of 50%, and even if Commodore had the brains to use a cheaper 28mhz 020 in A4000 (which is same speed as 25mhz 030 really) OR eventually launched the A1200 28mhz 020 pizza box successor it still makes a difference at the bottom end.
We are talking games and Amigas for games use are stock A1200 + 2mb Fast Ram at best, so yes Akiko would have been usefull (as would have IDE connector and Fast Ram SIMM slot on CD32 motherboard).
If anyone had programmed 030 games worth a sh1t then I might be swayed but fact is 90% of AGA games are badly programmed mildly breathed over crap.
Or Akiko on A1200 AND proper programming would have made games on Amiga 1200 for 99% of people expecting to play better games than a 1985 A1000 a bit less 'old' looking in 93/94.
I fail to see how £3000 A4000 with 040 50mhz and 16mb Ram performs playing Doom engines compared to £1500 PC running them the same speed is remotely relevant and yet more thread dilution and off topic dreaming. WHO CARES? It's like saying a Mercedes 6L V12 pissed all over a Ford Fiesta 1.6L straight 4 engine....true but bollox that is not helpful :)
-
Simple point is nobody bought 040s to play games
I did.
-
SWe are talking games and Amigas for games use are stock A1200 + 2mb Fast Ram at best, so yes Akiko would have been usefull (as would have IDE connector and Fast Ram SIMM slot on CD32 motherboard).
akiko was too little too late. AGA had trouble competing with the SNES and it's mode 7 graphics.
The advantage of the Amiga was always the power of custom chips instead of using brute processing power.
The blitter in AGA was basically the same as the one they wire wrapped in the early 80's, that was their mistake. They could even have lived with bitplanes, because it's only cpu rendering which makes that beneficial.
-
Akiko wasn't really used by any commercial games so it doesn't really matter how powerful it was ;)
A fast 030 can almost do C2P as fast as the bus can accept the data coming from the accelerator so the performance hit of having to do chunky-to-planar each frame is not really a big deal.
All of my recent Amiga coding has been with chunky graphics and C2P so I basically write code without having to worry about how the graphics are actually being rendered.
An interesting note, with my recent port of ScummVM over to AGA (which uses the chipset for double buffering, all of the graphics are generated as chunky screen in FASTRAM) I've found that most speed limitations are not with the AGA chipset, C2P or even the slow bus....it's normally my 030 which is too slow to generate the chunky screen in time. This is true up to 320x200 8bit, for SuperVGA (640x480 8bit) the AGA chipset/bus speed/C2P lets the side down and you really need to use RTG ;)
-
Simple point is nobody bought 040s to play games 68030 was a minimal improvement mhz per mhz over 020 ergo A4000/030 25mhz was slow and dead end for games.
Speak for yourself. I got my first 040 not long after the AB3D2 demo first appeared ;)
My point is spot on thanks. So getting back on topic in relevance to A1200 and CD32 (ie 1992 and 1993) chunky screen gaming, and accepting the known fact that A1200 had to compete out of the box for less than half the price of a 386DX for £899 with monitor blah blah......
Sorry, but no. Perhaps if the Akiko were implemented in a somewhat better fashion it would be useful, but it wasn't.
Let's imagine we have a 020+FastRAM+Akiko.
Having to first calculate 32 pixels of worth of data in fast ram (no data cache on 020), then copy it as 8 longwords to the Akiko. Then read it back again as 8 long words, then write each of those 8 longword to different addresses (offset into each bitplane) in your chip RAM. Rinse and repeat until the entire buffer has been converted.
Had the Akiko been implemented in such a fashion that you fed it your 8 bitplane addresses and then simply wrote 8 longwords of chunky pixels to it at a time and it in turn wrote them to ChipRAM incrementing the address pointers as it went, then it wouldn't have sucked.
-
Had the Akiko been implemented in such a fashion that you fed it your 8 bitplane addresses and then simply wrote 8 longwords of chunky pixels to it at a time and it in turn wrote them to ChipRAM incrementing the address pointers as it went, then it wouldn't have sucked.
+1
-
Had the Akiko been implemented in such a fashion that you fed it your 8 bitplane addresses and then simply wrote 8 longwords of chunky pixels to it at a time and it in turn wrote them to ChipRAM incrementing the address pointers as it went, then it wouldn't have sucked.
Should have been a blitter mode :-/
-
akiko was too little too late. AGA had trouble competing with the SNES and it's mode 7 graphics.
The advantage of the Amiga was always the power of custom chips instead of using brute processing power.
The blitter in AGA was basically the same as the one they wire wrapped in the early 80's, that was their mistake. They could even have lived with bitplanes, because it's only cpu rendering which makes that beneficial.
Brian The Lion has "Mode 7" type effects.
-
Brian The Lion has "Mode 7" type effects.
Please elaborate.
-
An interesting note, with my recent port of ScummVM over to AGA (which uses the chipset for double buffering, all of the graphics are generated as chunky screen in FASTRAM) I've found that most speed limitations are not with the AGA chipset, C2P or even the slow bus....it's normally my 030 which is too slow to generate the chunky screen in time. This is true up to 320x200 8bit, for SuperVGA (640x480 8bit) the AGA chipset/bus speed/C2P lets the side down and you really need to use RTG ;)
Depending on the game it may be more effective to use graphics.library calls and avoid chunky2planar completely.
Using AmigaOS functions instead of using the miggy like a dumb framebuffer would bring advantages, e.g. screenshake can be done without problems with AmigaOS functions like ScrollVPort(), there's no need to copy memory as that slows down the system without any need.
-
Should have been a blitter mode :-/
It should have been a Lisa mode - so no data at all would have to get moved twice (or even more).
-
Or Akiko on A1200 AND proper programming would have made games on Amiga 1200 for 99% of people expecting to play better games than a 1985 A1000 a bit less 'old' looking in 93/94.
To be honest the software library for Amiga in 1985/1986 wasnt very good either...
-
It should have been a Lisa mode - so no data at all would have to get moved twice (or even more).
True, but you would still probably want to render to fast ram and then copy the entire frame to chip ram in one go...
-
True, but you would still probably want to render to fast ram and then copy the entire frame to chip ram in one go...
No, you don't want to render to fast ram. The blitter should have been able to rotate and scale bitmaps. The way saturn drew polygons (they called them distorted sprites) wouldn't have been much of a stretch to add to the amiga blitter. It would be less efficient but it could have used bitplanes for the screen and textures, so lisa wouldn't necessarily have needed any changes.
If would have to have been introduced in 1990 instead of the a500+ to stop the snes, by 1995 it would have been time to do something much better. In the meantime games like Wolfenstein & doom would have come out on the Amiga first.
Add a cheap cd drive (like the cdtv cr or cd32) and they would have been unbeatable. Piracy wouldn't have been so widespread so the developers wouldn't have jumped ship.
The Amiga was cutting edge for 1985, but they milked it for far too long. On the A1000 launch day they should have been working on the chips that would come out in 5 years time (ECS was aiming too low and AAA was aiming too high).
The A1000 went from nothing to launch in three years, it then took a futher seven years to add 2 bitplanes & some higher resolution modes. Everyone then tried to fix the aging architecture with fast ram and accelerators, that wasn't ever the Amiga way.
-
The A1000 went from nothing to launch in three years, it then took a futher seven years to add 2 bitplanes & some higher resolution modes. Everyone then tried to fix the aging architecture with fast ram and accelerators, that wasn't ever the Amiga way.
I 200% agree with that! It took them 7 years to update some parts of the chipset, not even all parts (sound remained unchanged...). Too little, far too late.
-
100% ack - the 3000 should've had AGA and possibly some intermediate AAA by 1994 before adopting the other world's chips (on a PCI platform). But that didn't happen. :( Apple did it that way (mostly).
-
On the subject of Akiko Chunky-to-Planar, Toni Wilen released a new beta of WinUAE today which incorporated an optimised Akiko C2P algorithm I submitted in C code for WinUAE/PUAE.
Although it tested twice as fast as the old WinUAE algorithm in isolation, it's unclear whether due to CPU caching this will actually be any faster in practical use than the old algorithm (it makes for a very tiny difference anyway in overall CD32 emulation), but Toni's source code did say the original algorithm was, quote, a "piece of crap", and he decided to switch to my version instead, so I guess this is a small improvement.
At least it works when I tried it with CD32 Wing Commander and Microcosm. :)
-
No, you don't want to render to fast ram. The blitter should have been able to rotate and scale bitmaps. The way saturn drew polygons (they called them distorted sprites) wouldn't have been much of a stretch to add to the amiga blitter. It would be less efficient but it could have used bitplanes for the screen and textures, so lisa wouldn't necessarily have needed any changes.
If would have to have been introduced in 1990 instead of the a500+ to stop the snes, by 1995 it would have been time to do something much better. In the meantime games like Wolfenstein & doom would have come out on the Amiga first.
Add a cheap cd drive (like the cdtv cr or cd32) and they would have been unbeatable. Piracy wouldn't have been so widespread so the developers wouldn't have jumped ship.
The Amiga was cutting edge for 1985, but they milked it for far too long. On the A1000 launch day they should have been working on the chips that would come out in 5 years time (ECS was aiming too low and AAA was aiming too high).
The A1000 went from nothing to launch in three years, it then took a futher seven years to add 2 bitplanes & some higher resolution modes. Everyone then tried to fix the aging architecture with fast ram and accelerators, that wasn't ever the Amiga way.
That was the most wonderful post of how it should have happened I've ever read. If I ever get a Tardis I'll test it out.
-
...The Amiga was cutting edge for 1985, but they milked it for far too long. On the A1000 launch day they should have been working on the chips that would come out in 5 years time (ECS was aiming too low and AAA was aiming too high).
The A1000 went from nothing to launch in three years, it then took a futher seven years to add 2 bitplanes & some higher resolution modes. Everyone then tried to fix the aging architecture with fast ram and accelerators, that wasn't ever the Amiga way.
Having just caught up with this thread I would agree with the above quote.
I hate to dabble in "What if" but I have always wondered "what if" Commodore would have kept Jay Miner, et al, on the payroll and let them continue to upgrade the chipset. From my understanding, Jay and others were working on the Ranger chipset when Commodore shot them down.
I think that the Ranger chipset was a year or so away from release after the Amiga 1000 which would have kept the technology in an upgrade cycle. I also believe that Jay would have pushed to keep the technology moving where Commodore left it to stagnate.
I have always loved the Amiga 3000 and felt it was the last product Commodore truly put to market with polish and effort. That was also a pivotal moment in the market when Apple and IBM hadn't quite caught up with the Amiga chipset. Sadly, the 3000 lacked any significant upgrade to the chipset which was an opportunity missed by Commodore. A path that led to the 1994 closing.
I think if the Amiga 3000 would have had something along the lines of AGA and the 4000 a much more powerful chipset things would have gone different.
Atlas, it is only conjecture and speculation but I think it would have been interesting to see what Jay Miner et al would have done for the line if they would have remained full-time.
-P
-
c2p Gloom 1x1 256 colors
68020/14 - 61.6 ms
68020/14+fast - 54.6 ms
68020/14+akiko - 24.2 ms
68030/50+fast - 21.7 ms
68040/25+fast - 18.6 ms
68020/14+fast+akiko - 17.6 ms
68060/50+fast - 9.1 ms
(http://i67.tinypic.com/2hrmkoj.jpg)
My result:
A1200 BlizzardPPC + 68060/60+fast - 8.5 ms
A1200 BlizzardPPC + 68060/66+fast - 8 ms
Question, what will be the result on SX32Pro 68030/50+fast+akiko?
-
Question, what will be the result on SX32Pro 68030/50+fast+akiko?
LOL. I think we've found @fondpondforever (http://www.amiga.org/forums/member.php?u=10949)'s new BFF. :lol:
-
c2p Gloom 1x1 256 colors
...
Question, what will be the result on SX32Pro 68030/50+fast+akiko?
I could try that, but I am just too lazy.
-
c2p Gloom 1x1 256 colors
68020/14 - 61.6 ms
68020/14+fast - 54.6 ms
68020/14+akiko - 24.2 ms
68030/50+fast - 21.7 ms
68040/25+fast - 18.6 ms
68020/14+fast+akiko - 17.6 ms
68060/50+fast - 9.1 ms
(http://i67.tinypic.com/2hrmkoj.jpg)
My result:
A1200 BlizzardPPC + 68060/60+fast - 8.5 ms
A1200 BlizzardPPC + 68060/66+fast - 8 ms
Question, what will be the result on SX32Pro 68030/50+fast+akiko?
Impressive results there for Akiko. Is there a list of games which use this chip? Maybe a short list? Anyone?
-
Ultimate Gloom is the only one of note that actually makes a good game better:
http://www.amigacd32.com/games/gamepage.php?ID=1168&submitButtonName=Submit
Description: Another update to Gloom. In fact, this is also known as Gloom 3, as there was a Gloom Deluxe that is sort of the second game. This version features more levels and various other improvements. One of the few games that takes advantage of the CD32's Akiko chip to do chunky to planar graphics conversion. This should be compatible with any ECS or AGA Amiga, but requires at least a 68020 (it also claims to need 4MB of RAM, but the CD32 doesn't have that much and it works anyways, so...)
As already stated Wing Commander has the C2P Aikiko routine but an error was made in the programming so it is buggy and not up to speed. Since it was bundled in the Dangerous Streets pack that one was very important to get right and Nick Pelling screwed it up. It's awesome using WHDLoad on an accelerated AGA Amiga though.
Also:
Microcosm
Nick Faldo CD32
-
Ultimate Gloom is the only one of note that actually makes a good game better:
http://www.amigacd32.com/games/gamepage.php?ID=1168&submitButtonName=Submit
Description: Another update to Gloom. In fact, this is also known as Gloom 3, as there was a Gloom Deluxe that is sort of the second game. This version features more levels and various other improvements. One of the few games that takes advantage of the CD32's Akiko chip to do chunky to planar graphics conversion. This should be compatible with any ECS or AGA Amiga, but requires at least a 68020 (it also claims to need 4MB of RAM, but the CD32 doesn't have that much and it works anyways, so...)
As already stated Wing Commander has the C2P Aikiko routine but an error was made in the programming so it is buggy and not up to speed. Since it was bundled in the Dangerous Streets pack that one was very important to get right and Nick Pelling screwed it up. It's awesome using WHDLoad on an accelerated AGA Amiga though.
Also:
Microcosm
Nick Faldo CD32
Microcosm quote from http://www.verycomputer.com/2_20dd6dd9ef039920_1.htm:
The intro for Microcosm used the chunky to planar conversion if I remember
rightly. You got 2 versions of the intro - the CDXL style one (quarter
screen with speech) or the chunky looking one (using Akiko) which was full
screen but with no speech. As far as I can remember there was never a
game that used the Akiko chip.
(Now somebody's going to prove me wrong...)
-
Hi,
Yet the CD32 can play the intro video to "Microcosm" using the Akiko.
Regards, Michael
aka rockape
-
Those time tests tend to be better than what i'd expect from the previous discussion. With fast ram as quick as an '040. If that translates to real world use, akiko was a missed opportunity when the 3d graphics craze took off on the PC.
-
Everyone then tried to fix the aging architecture with fast ram and accelerators, that wasn't ever the Amiga way.
Yes.
-
The Mighty power of the Akiko????
Is this for real?
A stock cd32 (2mb chip+akiko) is nearly on par performance with an 030 50mhz with fast ram??
Am reading this wrong! It seems extremely impressive?
68020/14+akiko - 24.2 ms
68030/50+fast - 21.7 ms
If this is the case, and knowing the Doom runs ok on a 030/50...
If Commodore was doing well with CD32 and be financially sound back in 1994 makes me wonder... Could of Doom be ported to CD32 when the Jaguar/32X and 3DO games were being made...
By the looks of that, even the 2mb chip CD32 stock system could of had Doom.
Could we even of had a decent CD32 version of Streetfighter 2?
68040/25+fast - 18.6 ms
68020/14+fast+akiko - 17.6 ms
Although after reading this i am concerned i have read this wrong as 68020/14+fast+akiko could no way compete with 68040/25? Forgive me if i have got this wrong.
Played Gloom Deluxe tonight on stock CD32. Pixel width 1 / Pixel height 2;
ran well in nearly full screen. Impressive.
-
Well what this shows is that on a stock 68020 at 14MHz, too much time is spent in a software C2P routine, so much that the Akiko actually helps massively, despite being a pretty dumb chip AFAIK.
So in essence on the CD32, Akiko was meant to save money on including fast RAM in the system. A small cheap bit of silicon versus more expensive memory.
I don't even think Akiko can do DMA C2P on a range of memory. I think you have to write the chunky data into 32 32-bit registers on the system, and then read the resulting planar data back from it. I.e., it's probably a dual-ported SRAM with different bit access modes for write and read.
It's just that in code, that particular C2P operation takes too much time on a 68020. A 68060 can effectively do it transparently at memcpy speed (but hey, 68060!).
So a chunky game on CD32:
1. Render game in chunky in RAM.
2. Cycle over rendered chunky scene (might be a tile/column/row rather than full screen) in memory
2a. Write chunky memory into Akiko
2b. Read planar memory from Akiko (saves a lot of bit fiddling/shifting/rotating)
2c. Write to planar display memory (backbuffer)
3. Until scene finished. Switch backbuffer to front. Start again.
Note that DMA would have automated all of 2a,2b,2c. Maybe Akiko did have that?
Interested to see that it would mean a difference from around 12fps Gloom to around 40fps. A major difference.
-
Well what this shows is that on a stock 68020 at 14MHz, too much time is spent in a software C2P routine, so much that the Akiko actually helps massively, despite being a pretty dumb chip AFAIK.
So in essence on the CD32, Akiko was meant to save money on including fast RAM in the system. A small cheap bit of silicon versus more expensive memory.
I don't even think Akiko can do DMA C2P on a range of memory. I think you have to write the chunky data into 32 32-bit registers on the system, and then read the resulting planar data back from it. I.e., it's probably a dual-ported SRAM with different bit access modes for write and read.
It's just that in code, that particular C2P operation takes too much time on a 68020. A 68060 can effectively do it transparently at memcpy speed (but hey, 68060!).
So a chunky game on CD32:
1. Render game in chunky in RAM.
2. Cycle over rendered chunky scene (might be a tile/column/row rather than full screen) in memory
2a. Write chunky memory into Akiko
2b. Read planar memory from Akiko (saves a lot of bit fiddling/shifting/rotating)
2c. Write to planar display memory (backbuffer)
3. Until scene finished. Switch backbuffer to front. Start again.
Note that DMA would have automated all of 2a,2b,2c. Maybe Akiko did have that?
Interested to see that it would mean a difference from around 12fps Gloom to around 40fps. A major difference.
-
@ hattig. You can say that again.
-
There's a project here for someone... Doom on a stock CD32!
-
I would like to see some mode-7 style retro games for CD32, that is what akiko was for i suppose...
-
There's a project here for someone... Doom on a stock CD32!
working on it :laugh1:
-
working on it :laugh1:
Fantastic!!!
-
I could try that, but I am just too lazy.
Tests can be done TimeC2P with GloomC2P10 (http://aminet.net/package/game/demo/GloomC2P10),
newer c2p are the latest versions of Gloom.
Example CLI: TimeC2P akiko_1 1
-
TimeC2P Gloom 1x1 256 colors
68020/14 - 61.6 ms
68020/14+fast - 54.6 ms
68020/14+akiko - 24.2 ms
68030/50+fast - 21.7 ms
68040/25+fast - 18.6 ms
68020/14+fast+akiko - 17.6 ms
Heart Of The Alien Redux Amiga v1.0 - Another World sequel as an Amiga port gets an Amiga CD32 beta release (http://www.indieretronews.com/2016/11/heart-of-alien-redux-amiga-v10-another.html)
"The game uses C2P for rendering so we've been testing builds using the Akiko for that, and we've seen a big FPS increase. Currently with the test build, cutscenes can still drop down to 50% framerate but ingame framerate is either at or close to 100%."
-
There's a project here for someone... Doom on a stock CD32!
Would be too slow on a 14mhz '020, even with RTG.
Even disregarding c2p overheads that spec system, with 2meg RAM can barely play Gloom well let alone Doom. :)
-
Would be too slow on a 14mhz '020, even with RTG.
Even disregarding c2p overheads that spec system, with 2meg RAM can barely play Gloom well let alone Doom. :)
Yep I agree but I think Wolfy is possible
-
Yeah, definitely. Runs ok-ish on an 8mhz 68000 Atari ST, so an optimally tuned version for CD32 should run quite well.
Just looking at specs needed for original dos versions of these games gives a pretty good indication.
CD32 is, in raw grunt terms, well short of a 33mhz 386, and Doom, even with 4meg RAM runs terrible on that sort of system. And that's a machine that is optimal for that style game.
Wolf3d on the other hand runs OK on a 16mhz 286, which a 14mhz '020 can comfortably match.
-
TimeC2P Gloom 1x1 256 colors
(...)
68020/14+akiko - 24.2 ms
(...)
68020/14+fast+akiko - 17.6 ms
(...)
Question, what will be the result on sx32pro 68030/50+fast+akiko?
I could try that, but I am just too lazy.
You can see that you never use the Amiga. You're just a collector.
Tests can be done TimeC2P with GloomC2P10 (http://aminet.net/package/game/demo/GloomC2P10),
newer c2p are the latest versions of Gloom.
LOL no one else has CD32 with 68030?
-
Heart Of The Alien Redux Amiga v1.0 - Another World sequel as an Amiga port gets an Amiga CD32 beta release (http://www.indieretronews.com/2016/11/heart-of-alien-redux-amiga-v10-another.html)
"The game uses C2P for rendering so we've been testing builds using the Akiko for that, and we've seen a big FPS increase. Currently with the test build, cutscenes can still drop down to 50% framerate but ingame framerate is either at or close to 100%."
Neat. Always nice to have another CD32 title.
-
You can see that you never use the Amiga. You're just a collector.
Yeah, I "collected" the SX32 Pro back when it was new, from DCE. I use it a whole lot, but not for games (SX32 Pro was not made for gaming), and I don't have Gloom.
-
Yeah, I "collected" the SX32 Pro back when it was new, from DCE. I use it a whole lot, but not for games (SX32 Pro was not made for gaming), and I don't have Gloom.
Yeah, I've got an SX1, but I'd kill for an SX32.
And I'm wouldn't be using that for games either.
-
Yeah, I "collected" the SX32 Pro back when it was new, from DCE. I use it a whole lot, but not for games (SX32 Pro was not made for gaming), and I don't have Gloom.
The SX32 Pro is an equivalent of an A1200 with 030 accelerator,extra memory, hard drive and CD-ROM. I don't remember A1200 owners being so precious about only using their 030 machines for productivity! Get off your high horse. Just because it is rare doesn't mean someone shouldn't play a few games on it every so often:
Genetic Species
Alien Breed 3D
ADoom
TFX
Heck even Theme Park benefits from a 030 and extra memory!
All worthwhile uses for a CD32 SX32 Pro if you can find one ;-)
-
ADoom
Not to change the subject too much, but I have both ADoom and DoomAttack on my A2000. Of the two I found DoomAttack to be faster and have more features. Obviously just IMHO, but if you haven't tried it I'd recommend it:
http://aminet.net/package/game/shoot/DoomAttack
-
Yeah, I "collected" the SX32 Pro back when it was new, from DCE. I use it a whole lot, but not for games (SX32 Pro was not made for gaming), and I don't have Gloom.
You have a yellow papers? TimeC2P is not a game.
-
The SX32 Pro is an equivalent of an A1200 with 030 accelerator,extra memory, hard drive and CD-ROM. I don't remember A1200 owners being so precious about only using their 030 machines for productivity! Get off your high horse. Just because it is rare doesn't mean someone shouldn't play a few games on it every so often:
Genetic Species
Alien Breed 3D
ADoom
TFX
Heck even Theme Park benefits from a 030 and extra memory!
All worthwhile uses for a CD32 SX32 Pro if you can find one ;-)
Get off your high horse?
How about grow up and realize some people actually use their computers for something productive?
-
Yep I agree but I think Wolfy is possible
Hi Nova
I have been following this thread and wondered why Doom was extremely playable on Jaguar as that was only 2MB. I know Jag had 26mhz processor and CD32 14mhz - however i have played Doom Attack on CD32+4mb and it plays ok.
I am of course not a programmer or developer so my knowledge is limited - is it because it was developed by John Romero himself especially for Jaguar? Could a hacked down version by do-able on CD32 even if it has less colours or stripped down Graphics?
Would you be willing of having a crack at this if i paid you for it?
Thanks
Steve
ps> Wolf being made i believe at the moment on Jag by the same guy that did catacomb 3d.
-
Get off your high horse?
How about grow up and realize some people actually use their computers for something productive?
While I tend agree, let's be completely frank about it: What productive use is an Amiga good for these days anyhow? (-; Or to put this in other terms: While I love to play with software and programs, would you call the net result "productive", or is it just that: "Playing with obsolete software?".
I do not know the answer, but I'm a bit afraid of what it might be. (-:
-
Because of the Amiga's versatility, it's damn cool that users can pick and choose how they use their machines, spend their money and "waste" their time with them! Personally, I never feel guilty spending hours playing with them! I can never get my fill of "technical" info from the forums! Just wish I had more time to spend with them! @TR... hope you (& OM + other Miggy devouts here) never leave the scene or get tired of your devotion to the platform! I still have sooooo much to learn about my Blizz 060 card! BTW, Merry Christmas all! :)
-
The SX32 was bought for running Linux, believe it or not. It was in 1996 or 1997, and for a period it was used for OpenBSD too.
-
The SX32 was bought for running Linux, believe it or not. It was in 1996 or 1997, and for a period it was used for OpenBSD too.
Make sense to me, although I would prefer NetBSD.
-
While I tend agree, let's be completely frank about it: What productive use is an Amiga good for these days anyhow? (-; Or to put this in other terms: While I love to play with software and programs, would you call the net result "productive", or is it just that: "Playing with obsolete software?".
You can be productive using obsolete software, how efficient you are would be the real test.
Some people will ignore that they could be more efficient using a pc or a tablet, and it would be cheaper. I'm sure there are some things you can use an Amiga for that doesn't impact your efficiency, but I gave in when Windows XP came out. I have plenty of retro computers and consoles that I mess around with still.
-
You can be productive using obsolete software, how efficient you are would be the real test.
Some people will ignore that they could be more efficient using a pc or a tablet, and it would be cheaper. I'm sure there are some things you can use an Amiga for that doesn't impact your efficiency, but I gave in when Windows XP came out. I have plenty of retro computers and consoles that I mess around with still.
You soldiered on a lot longer than I did.
But there are still a few things an Amiga can do adequately.
For instance, I've never seen the need for heavy hitting power to do basic text editing or word processing, just good software.
Not everything requires high performance systems.
-
You soldiered on a lot longer than I did.
But there are still a few things an Amiga can do adequately.
For instance, I've never seen the need for heavy hitting power to do basic text editing or word processing, just good software.
Not everything requires high performance systems.
I agree with text editing, a writer who just needs to send off some ascii text once a year is unlikely to notice any major impact to their efficiency. Although getting that text off your Amiga is going to need CrossDOS/USB/Ethernet & CrossDOS onto a floppy is likely to be a problem for the receiver.
I think you'd be better off with a PC for "word processing" if you include what used to be referred to as DTP (Desktop Publishing).
In the very unlikely event that you've got software that improves your efficiency over any other platform then WinUAE gives you the best of both worlds.
-
I agree with text editing, a writer who just needs to send off some ascii text once a year is unlikely to notice any major impact to their efficiency. Although getting that text off your Amiga is going to need CrossDOS/USB/Ethernet & CrossDOS onto a floppy is likely to be a problem for the receiver.
I think you'd be better off with a PC for "word processing" if you include what used to be referred to as DTP (Desktop Publishing).
In the very unlikely event that you've got software that improves your efficiency over any other platform then WinUAE gives you the best of both worlds.
"software that improves your efficiency over any other platform"
I try not to be too critical on that point, or I'd keep falling back to Windows, leaving my Android and Linux hardware unused as well as my Amiga related systems.
Besides, the line between basic text editing and word processing can get pretty fuzzy, its a matter of how much formatting power you need.
-
I try not to be too critical on that point, or I'd keep falling back to Windows, leaving my Android and Linux hardware unused as well as my Amiga related systems.
Besides, the line between basic text editing and word processing can get pretty fuzzy, its a matter of how much formatting power you need.
I would rather be brutally honest and aim for efficiency when I'm trying to be productive and then use the spare time to do things I enjoy with other hardware.
-
Make sense to me, although I would prefer NetBSD.
At the time, OpenBSD was to be considered a NetBSD distro, the kernel was identical on m68k :)
-
So, last night, since I was playing around with MuTools anyways, I also downloaded GloomC2P, here goes...
Minne: > timec2p c2p/akiko_1 0
c2p/akiko_1
A chunky to planar routine by Peter McGavin. REQUIRES AKIKO CHIP, e.g, as in CD32. Supports 6/8 bitplane, single/double width pixels.
Screen = 320x200, Window = 256x180
Depth = 8, Chunky at $178ab530
Times in microseconds:
13478 13534 13117 13365 13361 13764 13403 13320
13223 13441 13423 13176 13389 13274 13525 13630
13446 13368 13317 13663 13362 13257 13376 13309
13503 13093 13360 13362 13630 13527 13454 13255
Mean time = 13390 microseconds (excluding first 2 frames)
Minne: > timec2p c2p/akiko_1 1
c2p/akiko_1
A chunky to planar routine by Peter McGavin. REQUIRES AKIKO CHIP, e.g, as in CD32. Supports 6/8 bitplane, single/double width pixels.
Screen = 320x200, Window = 256x180
Depth = 6, Chunky at $178ab530
Times in microseconds:
10836 11237 11096 11129 10986 11137 11010 11093
11032 11308 10984 11270 11114 11058 10987 11105
11027 11423 11118 10808 11122 11335 11000 10840
11124 11382 10981 10832 11244 11268 10991 10880
Mean time = 11089 microseconds (excluding first 2 frames)
Minne: > timec2p c2p/akiko_1 2
c2p/akiko_1
A chunky to planar routine by Peter McGavin. REQUIRES AKIKO CHIP, e.g, as in CD32. Supports 6/8 bitplane, single/double width pixels.
Screen = 320x200, Window = 256x180
Depth = 8, Chunky at $178ab530
Times in microseconds:
12742 12604 12524 12763 12887 12921 13128 13212
13224 13190 12951 13142 12808 12553 12619 12487
12473 12480 12729 12526 12759 12818 13045 13069
13134 13275 13164 13178 13099 12896 13023 12896
Mean time = 12899 microseconds (excluding first 2 frames)
Minne: > timec2p c2p/akiko_1 3
c2p/akiko_1
A chunky to planar routine by Peter McGavin. REQUIRES AKIKO CHIP, e.g, as in CD32. Supports 6/8 bitplane, single/double width pixels.
Screen = 320x200, Window = 256x180
Depth = 6, Chunky at $178ab530
Times in microseconds:
9713 9821 9637 9456 9852 9663 9724 9706
9610 9717 9896 10041 9646 9700 9675 9610
9700 9710 9699 9708 9573 9451 9765 9711
9601 9704 9686 9773 9459 9878 9700 9606
Mean time = 9689 microseconds (excluding first 2 frames)
-
You can be productive using obsolete software, how efficient you are would be the real test.
Damn right. For example, I always keep FS-UAE around on my systems because of Deluxe Paint - it is a program I know how to use and how to get the results I want, trying to get used to so called modern paint programs just leaves me frustrated.
What I use the CD32/SX32 mostly for these days falls under tinkering, which I find quite satisfying in a therapeutic kind of way. I am just done replacing all spinning IDE drives in all systems with either SD-adapters or mSATA adapters, and well on my way to build RaspberryPi systems inside all the Amiga computers, to provide various services (wifi, 464XLAT, resolver, ntp, smb), so for the SX32 I plan to build in a PlipBox, that will be plugged directly into a RPi mounted on the 2.5" disk area of the SX32, which is empty after I replaced IDE drive with an SD adapter and card :)
-
It's true power lies in its ability to generate forum discussions 23 years after it was released. :)
-
It's true power lies in its ability to generate forum discussions 23 years after it was released. :)
Hah, yes. People still think it hides magic powers :laughing:
-
So, now the numbers are there for a 030@50MHz + akiko and everyone is totally unimpressed. Yeah, that's what I thought, lol :)
-
I would rather be brutally honest and aim for efficiency when I'm trying to be productive and then use the spare time to do things I enjoy with other hardware.
In my case, its the net equivalent anyway as what I WANT to do IS use an alternative, AND I only use the mainstream hardware when I really need to.
Also, I must again reiterate that I am highly offended by Microsoft's decision to integrate software that shares my personal information without requiring my permission, AND preventing its removal.
To be brutally honest myself, I don't like paying for the privileged of being spied upon.
-
So, now the numbers are there for a 030@50MHz + akiko and everyone is totally unimpressed. Yeah, that's what I thought, lol :)
I think they only make sense if you can compare them to basic a1200 or basic a1200 + 030.
-
I think they only make sense if you can compare them to basic a1200 or basic a1200 + 030.
Or the very same system, only using the 68030 instead of the akiko:
Minne: > TimeC2P c2p/020_1 0
c2p/020_1
A chunky to planar routine by Peter McGavin. Optimised for 68020. Supports 6/8 bitplane, single/double width pixels.
Screen = 320x200, Window = 256x180
Depth = 8, Chunky at $17c7bb10
Times in microseconds:
22115 22112 22057 22060 22042 22078 21718 22036
22135 22166 22109 21984 21770 22108 22039 22107
22228 21939 22053 22028 22156 22035 22047 21760
21936 22262 22109 21766 21812 21881 22159 22184
Mean time = 22025 microseconds (excluding first 2 frames)
Minne: > TimeC2P c2p/020_1 1
c2p/020_1
A chunky to planar routine by Peter McGavin. Optimised for 68020. Supports 6/8 bitplane, single/double width pixels.
Screen = 320x200, Window = 256x180
Depth = 6, Chunky at $17c7bb10
Times in microseconds:
17363 17318 17109 17011 17129 16966 16943 16985
17043 17118 16981 17099 17022 16973 17211 17018
16912 16956 17097 17188 17036 16943 16988 16957
17212 17040 16946 16964 17047 17178 17057 16926
Mean time = 17035 microseconds (excluding first 2 frames)
Minne: > TimeC2P c2p/020_1 2
c2p/020_1
A chunky to planar routine by Peter McGavin. Optimised for 68020. Supports 6/8 bitplane, single/double width pixels.
Screen = 320x200, Window = 256x180
Depth = 8, Chunky at $17c7bb10
Times in microseconds:
12161 12791 12762 12283 12208 12101 12765 13259
12440 12039 12037 12359 13116 12760 12402 12096
12092 12803 13162 12371 12226 12033 12456 13028
12576 12323 12039 12029 12959 13151 12240 12101
Mean time = 12474 microseconds (excluding first 2 frames)
Minne: > TimeC2P c2p/020_1 3
c2p/020_1
A chunky to planar routine by Peter McGavin. Optimised for 68020. Supports 6/8 bitplane, single/double width pixels.
Screen = 320x200, Window = 256x180
Depth = 6, Chunky at $17c7bb10
Times in microseconds:
9218 9427 9222 9231 9173 9408 9545 9209
9173 9432 9226 9279 9431 9310 9125 9439
9348 9249 9425 9517 9191 9326 9291 9342
9078 9427 9425 9319 9424 9604 9214 9280
Mean time = 9322 microseconds (excluding first 2 frames)
-
well, then its much more clear to me. compared to a basic a1200, the akiko seems to make quite a big difference: performance is almost doubled. this was already written on page 2 of this thread, but its nice to see someone confirm this :)
-
does any talented amiga dev fancy making a CD32 (with fast) version of doom (either 4mb fast/8mb fast dont mind) ... that has CD Audio (eg. Doom 3DO music) optimised best possible for CD32/akkiko?
Happy to fund this project.
-
does any talented amiga dev fancy making a CD32 (with fast) version of doom (either 4mb fast/8mb fast dont mind) ... that has CD Audio (eg. Doom 3DO music) optimised best possible for CD32/akkiko?
Happy to fund this project.
Woah - hang on a minute. I think Kolla's ratings were based on accelerators and Akiko, not just Akiko on its own.
You are looking at an accelerated CD32 for that, I reckon. Not common to find for sale.
-
Hi Pat
I did mean CD32 14mhz + Fast Ram.
eg. so it would be bootable if you had the SX1 upgrade attached, for example.
If you follow the thread back to the start; the results show the CD32 is approx same speed for Doom as 030/28mhz with Akiko Optimised.
Doom Attack:
Amiga CD32 68020/14Mhz 8Mb (Akiko Optimised C2P) - 12872 realtics (5.8 fps)
Amiga A1200 030/28Mhz 64Mb (Blitter 020 C2P) - 12727 realtics (5.8 fps)
and/or
Gloom:
68030/50+fast - 21.7 ms
68040/25+fast - 18.6 ms
68020/14+fast+akiko - 17.6 ms
This will mean Doom would be playable (on low res/windowed) and IMO would be well worth doing.
-
I guess sooner or later somebody will come up with a suitable accelerator, or maybe complete console that is CD32/accelerator friendly... dev costs just keep coming down, and it's not likely the internet archives are going to start shrinking.
OK. I see...... actually to be totally truthful, I don't, never really been a fan of Doom.
(slowly backs out of thread in shame).:flak:
-
Hi Pat
I did mean CD32 14mhz + Fast Ram.
My results are from CD32 50MHz 68030 + Fast RAM.
-
I guess sooner or later somebody will come up with a suitable accelerator
A1200 acc boards are shrinking, there are AFAIK no technical obstacles preventing something similar as ACA500 for CD32, "ACA32" if you like, that would let you use A1200 acc boards on CD32.
-
A1200 acc boards are shrinking, there are AFAIK no technical obstacles preventing something similar as ACA500 for CD32, "ACA32" if you like, that would let you use A1200 acc boards on CD32.
It's even easier for the CD32 as it's practically an A1200 slot on the back.
-
It's even easier for the CD32 as it's practically an A1200 slot on the back.
Disagree with your there. CD32 accelerators have a big problem - volume available, and airflow.
SX-64 was a hot little bugger - literally. Needed to put a fan on it in the summertime. Don't get me wrong, it packed a lot of Amiga goodness into a very small area. Lovely little machine. But, it was using tech from 20 years ago.
Anyway, that's hopefully where the TerribleFire is headed one day. Developer is feeling his way, setting size limits on board size, thinking about designing them properly. He wants to do a video breakout board first for the CD32, after getting some reliable A500/A2000 accelerator designs under his belt.
If you think about it, that's where the real lack is for Amiga accelerators - more A500/A2000s were sold than the others. CBM did make quite a few CD32s, didn't sell many, and there are still some quantities around.
Looking ahead even way further, maybe even chip replication will become available - not just for developers, but at the local library/college level. Want some custom silicon? Just upload it and wait for the chips to be delivered to your door. Now THAT would be cool. Custom design your own Amiga. With Akiko and a cherry on top.
-
A1200 acc boards are shrinking, there are AFAIK no technical obstacles preventing something similar as ACA500 for CD32, "ACA32" if you like, that would let you use A1200 acc boards on CD32.
Well, apart from the volume issue, that's true. A1200 is probably the most "developed" for aMIGA these days. There is a software base to work from, people want the hardware to run the software.
Arguable, really, as some people just want the 68K based Amigas to all expire from natural causes, and just develop around PPC.
I guess the most "tolerant" approach is to look at slaving any old processors to an Amiga bus, and let them choose which processor architecture they're going to use... which is kind of how WinAAE and the other emulators do it.
It boils down to how attached you are to the original hardware, I guess. Seduction. Love at first sight. That kind of issue. Very personal, of course. Very human.
EDIT: I know no shame. Never did. :D
Having a NEED to run Amiga software is different. Some of it kicks ass, even today. :)
-
I made a video driver for FUSION that uses the Aikiko for the CD-32/SX1 combo. DEFINITELY worth the time to make the driver as the C2P is a lot faster than any 020/030 setup.
-
FWIW kippet2k has said a few times that he wants a Vampire for the CD32. Don't know if anything will ever come of it but he is a member of the team.
-
I made a video driver for FUSION that uses the Aikiko for the CD-32/SX1 combo. DEFINITELY worth the time to make the driver as the C2P is a lot faster than any 020/030 setup.
Did you ever make that publicly available? Would it also work with CD32/SX32 or was there something particular on the SX1 that tied it only to it?
-
Disagree with your there. CD32 accelerators have a big problem - volume available, and airflow.
SX-64 was a hot little bugger - literally.
Of course if you put something hot inside the CD32 then you have a problem, but you're assuming that a CD32 vampire would be as hot as a SX-64 and also that a CD32 vampire would be inside the CD32 case. It could easily stick out the back if heat was a problem.
-
There is plenty of space in a CD32, really, more than enough for both a card, cooling ribs and a fan.
It's like a garage in there!
http://www.amiga.org/forums/picture.php?albumid=204&pictureid=1386
ACA1221 just resting in side the "garage":
http://www.amiga.org/forums/picture.php?albumid=204&pictureid=1387
Open CD32 with ACA1221 and RPi 2B, just for size comparison...
http://www.amiga.org/forums/picture.php?albumid=204&pictureid=1388
-
The biggest obstacle I can see to an internal accelerator card for the CD32 is that the cpu is surface mounted.
Frankly I'd rather have an external card, that way it could be used with the SX1.
-
The biggest obstacle I can see to an internal accelerator card for the CD32 is that the cpu is surface mounted.
Er... guess how the SX32 Pro is connected :p
-
The biggest obstacle I can see to an internal accelerator card for the CD32 is that the cpu is surface mounted.
Frankly I'd rather have an external card, that way it could be used with the SX1.
@Iggy
Kolla is correct in that the CD32 had a trapdoor like expansion slot that allowed the connection of the FMV MPEG-1 Video Card and a range of accelerators culminating in the SX32-Pro with 030 50Mhz CPU and EDO Ram slot.
-
Did you ever make that publicly available? Would it also work with CD32/SX32 or was there something particular on the SX1 that tied it only to it?
Yes, this driver was included with FUSION. It worked with the CD32 setup. I used the SX1 with mine, but there is nothing required other than the CD32.
-
Yes, this driver was included with FUSION. It worked with the CD32 setup. I used the SX1 with mine, but there is nothing required other than the CD32.
Is it still possible to buy / get Fusion anywhere? I have iFusion but not the latest version of the regular Fusion. I have 3.1 from a cover disk but I know that there was at least version 3.2. If it's not possible to buy it anywhere now, do you have any idea if the cover disk version included the Akiko driver?
PS I'm really looking forward to the Vampire version you've mentioned on eab. It's great to see you developing the software again. My Emplant was great until lightning zapped it :(
-
Er... guess how the SX32 Pro is connected :p
Since I own an SX1, I hardly have to guess.
My point being an internal accelerator is not practical for the CD32.
-
Since I own an SX1, I hardly have to guess.
My point being an internal accelerator is not practical for the CD32.
My SX32 Pro seems to be fairly practical. Temperatures don't get much higher with a CF card although a spindle drive adds about 10°F. Still not bad though.
The main impractical part is finding one :)
A Vampire type accelerator mounted internally shouldn't be any worse than an SX32 Pro. Better because it's smaller, lower voltage and feels a good bit cooler. As others have said, the expansion connector is essentially a 1200 trapdoor connector. A Vampire 1200 mated with the connector kipper2k has already developed gives you a fantastic internal accelerator for a CD32.
If I'm reading things correctly (not a given) it sounds like the Vampire 1200 is progressing well. Once it's done, add the expansion connector and you've got a sweet CD32.
At least so says the genius whose hardware skills go no further than recapping :)
-
Is it still possible to buy / get Fusion anywhere? I have iFusion but not the latest version of the regular Fusion. I have 3.1 from a cover disk but I know that there was at least version 3.2. If it's not possible to buy it anywhere now, do you have any idea if the cover disk version included the Akiko driver?
PS I'm really looking forward to the Vampire version you've mentioned on eab. It's great to see you developing the software again. My Emplant was great until lightning zapped it :(
The driver for the CD32 was originally released with Mac1200, which was the Mac emulation I did for the A1200. So, FUSION definitely has the Akiko driver for it and that should be included with the cover disk.