@pixie

Quote:

pixie wrote: @cdimauo [quote]Again? As I've already said, this comparison is completely non-sense: 1985 vs 1992...

Quote:

Are you talking regarding VGA release

Quote:

Yes

Quote:

But from what I saw VGA only appeared after in 1987, that's why I got confused about the meaning.

That was the point: he compared the VGA which was released on '87 with AGA which was released on '92...

There were some problems with c2p.

1. copy speed is only on 060 on slower cpu c2p is slower than simple copy.
2. c2p routines takes at least 32 pixels wide blocks even if only few pixels have to be converted.
it is big overhead.
3. It takes few years to made fast c2p routines it was not available before Escom bankruptcy
developers on pc/mac etc just made games do not have to waste time on c2p.

Aga was crap because it has not chunky pixels.
If AGA has chunky pixels everything will be different.
It is still valid.

@cdimauro

Quote:

I don't think so. The C65 was still very limited. AFAIR its Blitter has also less functionalities compared to Amiga one. Anyway, it was never sold, so: who cares!

I can buy a MEGA65 today...so I guess I care.
Also, when you add an REU or similar device to even on old C64, you get much faster DMA speeds and can play games like this [Sonic The Hedgehog]:
https://www.youtube.com/watch?v=_Cg8r-VmeMk

DMA speeds will always be the main limiting factor about what a console/computer is capable of achieving.

Last edited by Lou on 22-Aug-2022 at 05:10 PM.

@ppcamiga1

Quote:

ppcamiga1 wrote: Aga was crap because it has not chunky pixels. If AGA has chunky pixels everything will be different. It is still valid.

The same applies to OCS (and, by extension, to ECS).


@Lou

Quote:

Lou wrote: @cdimauro Quote: I don't think so. The C65 was still very limited. AFAIR its Blitter has also less functionalities compared to Amiga one. Anyway, it was never sold, so: who cares! I can buy a MEGA65 today...so I guess I care.

It isn't a C65.
Quote:

Also, when you add an REU or similar device to even on old C64, you get much faster DMA speeds and can play games like this [Sonic The Hedgehog]: https://www.youtube.com/watch?v=_Cg8r-VmeMk

Impressive. Many of the best videogames were released after that the C64 left the market...
Quote:

DMA speeds will always be the main limiting factor about what a console/computer is capable of achieving.

It's not a matter of DMA, rather of memory accesses AKA available bandwidth.

@cdimauro

OCS/ECS was made when everyone use bitplanes - pc/mac/atari etc.
It use bitplanes it is ok.

AGA was made when everyone use chunly pixels - pc/mac/atari etc.
AGA has not chunky pixels its mean AGA was outdated crap.

@ppcamiga1

Do be quiet. Grown-ups are talking.

_________________
Doing stupid things for fun...

@matthey

Quote:

The graphics card likely has a little bigger advantage but there is more function call overhead for WritePixelArray8() than Chunky2Planar(). It would be better to use the same function for both AGA and the graphic cards (possible with a switch?) and this should increase the performance of the graphics card if switching to Chunky2Planar() or decrease the performance of AGA if switching to WritePixelArray8(). Using the same graphics function, it should be possible to more accurately estimate the actual performance of the Zorro III bus and the bandwidth to the graphics card. My hypothesis is that the difference in fps is roughly due to the difference in write memory bandwidth to the different graphics memories. In addition to switching to the same graphics functions, the actual memory write bandwidth to the graphics cards should be measured with something like bustest.

A switch could be added. It uses WritePixelArray8() on older graphics.library version. But uses WriteChunkyPixels() on version 40 and above. Seems I've got an older version. I have OS3.1 since I run OS3.9 on it. Could be a CD32 thing since WriteChunkyPixels() likes to use chunky hardware or is slow without it. However, it somehow knows through the RastPort it's RTG, so the internal routines called from WritePixelArray8() would differ.

The bustest program uses addresses so would be hard to test I think. There is transferring to RTG and then directly writing to RTG. I'm not sure how finding the memory map could be done but it would be possible to find direct framebuffer address. Either way memory space would need to be found and locked which is somewhat dodgy doing it from one CLI program to feed into another CLI program to test it.

@ppcamiga1

And yet ALL the main productivity packages came out or hit their stride during he AGA era e.g. PageStream, Deluxe Paint IV and V, Scala, Lightwave etc. Also, ADoom, Napalm, Guardian, Sim City 2000, Colonisation, Slam Tilt, TFX and Speedball 2 CD32 (colourful version with crowd noise and atmosphere) all needed AGA. The only games that don't need AGA that stand the test of time are The Settlers, Lemmings, Dune 2, Battle Squadron, Apidya and Ruff N' Tumble IMHO. It would've been a duller world without it. The Monkey Island games had inferior graphics to VGA versions because AGA wasn't out in 1990/91 like it should have been but AGA was still valuable.

_________________
"Art challenges technology. Technology inspires the art."
John Lasseter, Co-Founder of Pixar Animation Studios

@Hammer

Quote:

PC GPU hardware evolution is largely driven by the gaming PC market competition i.e. high performance graphics are the heart of it. From the PC gaming market, PC GPU companies such as NVIDIA crushed SGI's hardware OpenGL business.

It took a while. GPU units already existed in the 80's and blitters. But it was only around the mid 90s's the PC took up this trend when hardware 3d cards became common.Quote:

Super Buster chip needs to be upgraded to close the gap between real and theoretical numbers. 32-bit x 25 Mhz bus would yield a theoretical 100 MB/s while real work performance is about 15 MB/s

Even close to 100 MB/s would have been way better.

Quote:

I selected PC, but I would have kept the A1200.

I thought so.

Quote:

My purchase for A1200 in Y2020 was luck since it was advertised as a "sold for parts" wreak and I took the chance and paid $200 for it. A1200 was found to be working. A1200 was recapped and I fixed the timing issue. A fully working A1200's price is crazy.

That would have been a good find.

Quote:

Some ET4000AX reached 33 fps. ET4000AX comes in either high-speed 16-bit VRAM or 32-bit DRAM SKUs. Your mileage may vary.

That's closer to the mark.

Quote:

A4000's motherboard wasn't designed for 68040, let alone 68060. A4000's motherboard was an AA3000+ motherboard.

They shouldn't have called it the A4000 then since it's implied 040. Like how A3000 implies 030. But given the A2000 was still stuck on the 68000 and not using the 020 this is not surprising.

Quote:

Amiga Ranger chipset with 128 colors (7-bit planes) and 4096 color palette should have been in 1987. 32-bit DRAM would be more than enough for 128 colors (7-bit planes) 320x200/256 resolution. The original Amiga team worked on the Amiga Ranger chipset after the OCS.

I bet Commododore didn't like it because it would take them too long to catch up with it. Too much pressure. They'd have to do better!

Quote:

A3000 is effectively redundant when A2500/030 has a similar capability. My Dad fell for the large model number on A3000 with a 68030 CPU. My Dad was one of those gamers who plays sports games.

I noticed sports games like golf used a bit of CPU time and were slow.

Quote:

ECS's 4 colors 640x480p mode is largely obsolete when VGA has 16 colors 640x480p mode. ET4000AX that was cost reduced IBM 8514/a clone was released in 1989.

It would be. It must have lost it at that point. Amiga was ahead of the game then in 1990 it caught up with 4 colour CGA and went backwards!

Quote:

100 Mhz 68060 helps with compacting render time for the CPU stage while the AGA stage remained as is. AGA as a dumb frame buffer device is superior when compared to IBM's original VGA.

Except VGA can write multiple pixels from one write operation and AGA isn't exactly a normal framebuffer with the bitplanes.

Quote:

I don't have Warp1260 and my AMiga 1200/TF1260 only has 68060 rev 1 @ 62.5 and haven't applied the new firmware...

Looks like a good system to test.

Quote:

Amiga Graffiti add-on running Doom with 68030 @ 50Mhz.

Runs at a respectable speed. The obviously raw video output resembles my ordered packed mode. So I've read it uses 16 colour hires and each 4 pixels goes into planes 0 to 3 so every 16x1 pixel block represents 8x1 packed. They must have a faster conversion routine. I didn't get close using a similar arrangement with my optimised ASM!

Quote:

Graffiti changes the Amiga bitplaned graphics into a chunky pixel mode. I'll get around to benchmarking it with Doom.

Although the packed data is in planes it may lack direct access like RTG. Like chunky copper needing pixels in a certain arrangement. So it has a custom routine for uploading a chunky screen to the bitplanes.

Quote:

I also broke my Witcher 508's pin, and I manage to solder a new pin.

Close one.

Quote:

For soldering work, I practiced on old non-Amiga PCBs e.g. PC gaming mouse that needs click button replacements.

I decided to start and stop at mice. Although I bought a new iron now. However don't want to go about forging on the sacred ground of my A1200.

Quote:

I fixed timing issues on my Amiga 1200 rev 1d1 motherboard.

That used to cost $40 in the 90's including a resistor.

Last edited by Hypex on 23-Aug-2022 at 04:19 PM.

@cdimauro

Quote:

It's not a matter of DMA, rather of memory accesses AKA available bandwidth.

you do realize the MA in DMA stands for 'memory access' and adding the word "speed" in association with that = your bandwidth - right?


...and the MEGA65 is as much a C65 as a Vampire is an Amiga!

Last edited by Lou on 23-Aug-2022 at 06:04 PM.
Last edited by Lou on 23-Aug-2022 at 06:03 PM.
Last edited by Lou on 23-Aug-2022 at 06:00 PM.

Hypex Quote:

A switch could be added. It uses WritePixelArray8() on older graphics.library version. But uses WriteChunkyPixels() on version 40 and above. Seems I've got an older version. I have OS3.1 since I run OS3.9 on it. Could be a CD32 thing since WriteChunkyPixels() likes to use chunky hardware or is slow without it. However, it somehow knows through the RastPort it's RTG, so the internal routines called from WritePixelArray8() would differ.

I'm surprised there is no switch for comparison purposes. I don't expect much difference in performance except when using C2P hardware like the CD32.

Hypex Quote:

The bustest program uses addresses so would be hard to test I think. There is transferring to RTG and then directly writing to RTG. I'm not sure how finding the memory map could be done but it would be possible to find direct framebuffer address. Either way memory space would need to be found and locked which is somewhat dodgy doing it from one CLI program to feed into another CLI program to test it.

Can you use the system monitor Scout to find a RTG bitmap address (window)?

http://aminet.net/package/util/moni/Scout_os3

Then close all RTG screens and use the bitmap address with bustest.

> bustest addr=BitmapPtr

http://aminet.net/package/util/moni/bustest

It's not system friendly to use allocated RTG memory but it should be safe enough while there are not RTG screens active. Just reboot before using a RTG screen again.

@ppcamiga1

Quote:

ppcamiga1 wrote: @cdimauro OCS/ECS was made when everyone use bitplanes - pc/mac/atari etc.

As usual, you're plainly wrong.

Macs were... monochromatic at the time ('84). How could you even think about that they used bitplaneS (note: it's PLURAL)?!?

Atari ST, yes: they used bitplanes. In the most awkward way.

Finally, PCs. Here's the first color graphic card for it (1981):
https://en.wikipedia.org/wiki/Color_Graphics_Adapter#320%C3%97200

each pixel is two bits, which select colors from a four-color palette

IGNORANT!
Quote:

It use bitplanes it is ok.

See above: NO!
Quote:

AGA was made when everyone use chunly pixels - pc/mac/atari etc. AGA has not chunky pixels its mean AGA was outdated crap.

See above: it was the same crap as OCS (and ECS).

@Lou

Quote:

Lou wrote: @cdimauro Quote: It's not a matter of DMA, rather of memory accesses AKA available bandwidth. you do realize the MA in DMA stands for 'memory access' and adding the word "speed" in association with that = your bandwidth - right?

Wrong, because the DMA USES memory accesses for its work but it's NOT equal to memory accesses and, even worse, it's NOT equal to speed/bandwidth.
Quote:

...and the MEGA65 is as much a C65 as a Vampire is an Amiga!

Vampire had the full Amiga hardware specs, so it was relatively easy to start implementing it.

Where are the specs for the C65?

Lou Quote:

you do realize the MA in DMA stands for 'memory access' and adding the word "speed" in association with that = your bandwidth - right?

DMA hardware uses memory bandwidth but implies little about how much memory bandwidth is available, other than that it is not zero.

https://en.wikipedia.org/wiki/Direct_memory_access

Lou Quote:

...and the MEGA65 is as much a C65 as a Vampire is an Amiga!

Actually, Vampire hardware is not anymore an Amiga than THEA500 Mini is an Amiga. Neither is any so called Amiga NG hardware Amiga hardware including AmigaOne hardware. There hasn't been an officially branded Amiga computer that I'm aware of since the fall of Escom.

@Lou

I am sure you realised it already but DMA is a consumer of memory bandwidth, a mechanism for accessing data without having to go via some sort of programmed IO which is less efficient usually. Which is all great, provided there's enough available bandwidth to do that without starving everything else.

_________________
Doing stupid things for fun...

EGA and VGA 16 color modes has bitplanes.
Classic Mac Os also has support for bitplanes.
That some morons never heard of it it not means it not exist.
So everyone at OCS/ECS times use bitplanes pc/mac/atari ets.
AGA was crap because Commodore dont switch to chunky pixels.
Like everyone else pc/mac/atari etc.
good c2p come too late after Escom bankruptcy.
If AGA han chunky pixels everything will be different.

@Hypex

This is a test I made on my uae setup:

It's on 640x480, although in emulation cpu achieves speeds one can only dream on a real amiga, the chipset should be set at about the same speed as in a real amiga.

Quote:

Screen Mode $00039024 is NATIVE-PLANAR 8-BIT Error: timed 1710 gametics in 1125 realtics ( 53.2 fps) Total number of frames = 1787 Total blit wait time = 0 us (0 us/frame) Total safe wait time = 0 us (0 us/frame) Total Chunky2Planar time = 544549 us (304 us/frame) Total CopyChunkyScreen time = 0 us (0 us/frame) Total WritePixelArray8 time = 0 us (0 us/frame) Total LockBitMap time = 0 us (0 us/frame)

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

@ppcamiga1

Regarding C2P with 32 pixels wide blocks. It needs to process 32 pixels at a time so it can write long words out to chip ram. Any less and it would be slower if it only converted bytes at a time. It also makes it more complicated as it needs to cache 8 long words with only 8 data registers for 8 planes. But it needs to work with the largest amount of data to be fastest.

Compare with my ordered and tabled modes which are even slower. My ordered mode simply copies each byte into each bitplane sequentially. It just copies all the bytes, with no conversion, into a different order and it's slower.

The tabled mode reads in chunky data at word size, shifts it into an index, then uses it to copy bytes from a look up table. It also does a byte copy into chip. And is also slower by the byte.

@matthey

Quote:

I'm surprised there is no switch for comparison purposes. I don't expect much difference in performance except when using C2P hardware like the CD32.

That's likely because ADoom contains optimised C2P routines. It checks the system and picks the routine based on hardware. Slower machines use CPU_blitter. Faster use CPU only. It has CD32 routine.

So, since WritePixelArray8() would end up slower than any optimised routine, would be why it's not offered as a direct option.

Quote:

Can you use the system monitor Scout to find a RTG bitmap address (window)?

I'd have to test that.

Quote:

Then close all RTG screens and use the bitmap address with bustest.

Could it be an issue if the framebuffer isn't locked out first?

Quote:

It's not system friendly to use allocated RTG memory but it should be safe enough while there are not RTG screens active. Just reboot before using a RTG screen again.

I suppose so.

@pixie

Thanks for your testing. Yes I too found UAE ran too fast. Which is why I did all my actual testing on the real thing.

I don't know why but it always returns any tic results as an error.