Method to the madness

[the_leander]

Actually, it's 2^18, which is 262144.

Unlike HAM6, however, the base colours are still 8 bits wide. Altering a pixel by changing any of the RGB guns of the previous one does not affect the lowest 2 bits of the gun you are altering. If you use the copper to alter the base palette for each scan line, you can actually achieve considerably more than 262144.

But with what sort of performance hit?

[the_leander]

Here is a description of the Amiga custom chips:

Most components within the machine were known by nicknames. The coprocessor commonly called the "Copper" is in fact the "Video Timing Coprocessor" and is split between two chips: the instruction fetch and execute units are in the "Agnus" chip, and the pixel timing circuits are in the "Denise" chip (A for address, D for data).

"Agnus" and "Denise" were responsible for effects timed to the real-time position of the video scan, such as midscreen palette changes, sprite multiplying, and resolution changes. Different versions (in order) were: "Agnus" (could only address 512K of video RAM), "Fat Agnus" (in a PLCC package, could access 1MB of video RAM), "Super Agnus" (slightly upgraded "Fat Agnus"). "Agnus" and "Fat Agnus" came in PAL and NTSC versions, "Super Agnus" came in one version, jumper selectable for PAL or NTSC. "Agnus" was replaced by "Alice" in the A4000 and A1200, which allowed for more DMA channels and higher bus bandwidth.

"Denise" outputs binary video data (3*4 bits) to the "Vidiot". The "Vidiot" is a hybrid that combines and amplifies the 12-bit video data from "Denise" into RGB to the monitor.

Other chips were "Amber" (a "flicker fixer", used in the A3000 and Commodore display enhancer for the A2000), "Gary" (I/O, addressing, G for glue logic), "Buster" (the bus controller, which replaced "Gary" in the A2000), "Buster II" (for handling the Zorro II/III cards in the A3000, which meant that "Gary" was back again), "Ramsey" (The RAM controller), "DMAC" (The DMA controller chip for the WD33C93 SCSI adaptor used in the A3000 and on the A2091/A2092 SCSI adaptor card for the A2000; and to control the CD-ROM in the CDTV), and "Paula" (Peripheral, Audio, UART, interrupt Lines, and bus Arbiter).

There were several Amiga chipsets: the "Old Chipset" (OCS), the "Enhanced Chipset" (ECS), and AGA. OCS included "Paula", "Gary", "Denise", and "Agnus".

ECS had the same "Paula", "Gary", "Agnus" (could address 2MB of Chip RAM), "Super Denise" (upgraded to support "Agnus" so that a few new screen modes were available). With the introduction of the Amiga A600 "Gary" was replaced with "Gayle" (though the chipset was still called ECS). "Gayle" provided a number of improvments but the main one was support for the A600's PCMCIA port.

The AGA chipset had "Agnus" with twice the speed and a 24-bit palette, maximum displayable: 8 bits (256 colours), although the famous "HAM" (Hold And Modify) trick allows pictures of 256,000 colours to be displayed. AGA's "Paula" and "Gayle" were unchanged but AGA "Denise" supported AGA "Agnus"'s new screen modes. Unfortunately, even AGA "Paula" did not support High Density floppy disk drives. (The Amiga 4000, though, did support high density drives.) In order to use a high density disk drive Amiga HD floppy drives spin at half the rotational speed thus halving the data rate to "Paula".

The thing that immediately stands out to me is that Paula seems to be bunged together to do several unrelated things. This comes back later by not allowing the A1200 to do HD floppy native.
I'm trying to both visualize the flow and figure out how they added 8 bit graphics. hmm.

Err, dude, you might want to go back and check some of this stuff.

From memory Agnus was replaced by Alice and Denise by Lisa in AGA, with Paula being left more or less untouched.

[the_leander]

Hey,
Stop hijacking my thread. If you have corrections or suggestions. Message me.

How was answering a perfectly legitimate question regarding performance within the HAM modes hijacking? Especially when Zac67 answered the question as to why blitter performance didn't improve...

What's good for the goose and all that.

Btw, interesting fact. The logic that allows for HAM was almost removed in an attempt to cut costs, it was only when one of the engineers pointed out that removing it would leave a ruddy great hole in the chip and cost more for the redesign that the beancouters backed off.

[the_leander]

I don't want to try and upstage AROS, UAE or even the Minimig. So I will aim at... A theoretical hand held Amiga device. If you can come up with any ideas for someone who 'may' carry such an idea to completion, feel free to share.
1st thing to do:
Shrink chip mem bus into a single serial bus.

One thing I am curious though and possibly this would be more into UAE territory is would it be possible or even desirable to run a similar type of software inside CUDA?

[the_leander]

Hard to say... It would certainly be handy, especially for 3D GUI. Did you have a specific function in mind?

These CUDA processors are (as I understand it) essentially programable units. So would it not be possible to offload the translation of Amiga graphics calls more directly then is currently done and allow the cpu more room to breath.

[the_leander]

How do you mean exactly? CUDA excels at parallel processing. For example, I'm currently using it to solve the optimal spacing of points on the surface of a sphere. Running on the Q9450, the system starts to struggle at 2000 points. With CUDA, it's still fast at over 10 times that number thanks to the inherent parallelism in the problem at hand.

I'm not sure where you see it fitting into Amiga hardware emulation, though I expect it could emulate things like high resolution HAM displays etc without any problem, but then you have RTG for that job anyway.

One of the biggest issues with Amiga emulation as I understood it was the graphics. Would it not be possible to have the CUDA processor deal more directly with it rather then needing the cpu to handle that particular facet?

This isn't my area of expertise so I could be viewing this in completely the wrong way.