Amiga.org
Amiga computer related discussion => General chat about Amiga topics => Topic started by: ElPolloDiabl on June 19, 2009, 05:38:58 AM
-
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 >"Alice"< 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 >262,144< 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".
Paula - Originally, there would have been a DSP chip (to compliment Paula - see the AA3000 prototype), but costs were cut and Paula was kept from the ECS chipset.
Alice - The AGA successor to Agnus in OCS/ECS systems.
Lisa - The AGA successor to Denise in OCS/ECS Cnipsets
Gayle - And upgrade of Gary, handled IDE drives as well.
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.
-
The second thing that stands out (though failed to input above) is the OS sitting in chip RAM, later moved to the ROM.
Lets just reverse engineer the whole thing from top to bottom and submit the results to the UAE emulator team.
Lets start with the two most important engineers Jay and Dave (forgive me Dave, I'm going to go over this with a fine tooth comb). Jay was BS, Dave was a BS electrical engineering. Let's suppose Jay's favourite class was physics; pendulums, clockwork, you get the idea. Visualize the bus like you do the solar system. Planets making an intricate dance around the Sun, interacting with each other via gravity.
-
last time I counted them, I only got 262,000 colors in HAM8 not a mere 256,000
-
last time I counted them, I only got 262,000 colors in HAM8 not a mere 256,000
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.
-
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?
-
I thought Gary was the Gate ARraY.
-
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.
-
I'm getting a bit confused here.
I've read up on AGA vs OCS/ECS differences a number of times and every time so far I found that the Blitter (and Copper) was not actually changed for AGA (as in it wasn't any faster). Now I read this which basically says that the custom chips did get faster.
So, which one is it?
(I do know about the 64 bit fetch modes, but my understanding was this was only for the graphics chip (Lisa) and not for the Blitter).
-
Now I read this which basically says that the custom chips did get faster.
So, which one is it?
(I do know about the 64 bit fetch modes, but my understanding was this was only for the graphics chip (Lisa) and not for the Blitter).
The bus width was increased to 32 bit (from 16-bit). Still at (approx) 7Mhz
-
Now I read this which basically says that the custom chips did get faster.
So, which one is it?
(I do know about the 64 bit fetch modes, but my understanding was this was only for the graphics chip (Lisa) and not for the Blitter).
This is another thing related to the first 32-bit console: 3DO claimed it (over Amiga CD-32) because the CPU was a cut down 24-bit 68020. hmm
-
But with what sort of performance hit?
Well, for displaying static images, none really. HAM in general, however, is not ideally suited for realtime graphics applications.
-
Well, for displaying static images, none really. HAM in general, however, is not ideally suited for realtime graphics applications.
Hey,
Stop hijacking my thread. If you have corrections or suggestions. Message me.
-
AGA quadrupled bitplane DMA bandwidth by doubling the data path to 32 bit and doubling the clock speed, hence the new DMA address generator (Alice) and bitplane data serializer (Lisa). Unfortunately the opportunity was missed to utilize the added bandwidth for speed up of the blitter or floppy DMA (for high density). The blitter is still 16 bit and got no speedup at all, apart from the overall DMA slots saved due to bitplane speedup - that's why a 32 bit CPU can achieve a higher fillrate than the AGA blitter.
-
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.
-
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...
My dear Watson,
I should have emphasised this thread was about reverse engineering the custom chip bus. Not discussing individual functions.
Plus: Point taken it was a fair question/answer.
-
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.
Wish List:
Shrink chip mem bus into a single serial bus.
Integrated HD Video output.
Dedicated OS Bus.
-
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?
-
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?
Hard to say... It would certainly be handy, especially for 3D GUI. Did you have a specific function in mind?
-
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?
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.
-
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.
-
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.
-
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?
A good idea, but I haven't perused the UAE source code, or looked at the CUDA specific commands. It seems like the logical progression though.
-
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.
Ah right, now I get you. I've wondered about that too. You could probably use it to speed up planar to chunky (yes, that's right, not chunky 2 planar) and rendering of HAM framebuffers to the host display format, you could probably use it to speed up blitter emulation too.
However, the thing is that on current CPU's these aren't really too taxing. A more widely supported solution I think would be to leverage multiple core support on the CPU. Since AmigaOS 3.x exec just isn't cut out for SMP (something else I've pondered for UAE is a hacked exec that can use multiple concurrent JIT instances for handling as many AmigaOS "ready to run" processes as the host feasibly allows), you can have the JIT on one core and offload things like display emulation to another core. Worth noting too is that if you are using UAE for anything beyond a spot of retro gaming you are probably going to be using RTG anyway and not even worried about "native" amiga modes.
Also, anything you do with the GPU is probably best left until OpenCL becomes more widespread as it'll work on more systems than CUDA.
-
A good idea, but I haven't perused the UAE source code, or looked at the CUDA specific commands. It seems like the logical progression though.
CUDA doesn't have commands, per se. You write code for it using a modified subset of the C++ syntax.
-
http://www.natami.net/knowledge.php might be a forum for this. There's talk there of making a consumer-grade Amiga-compatible chip out of a FPGA chip and some other logic using 16-bit memory busses. Of course the developer version will be more expensive but also more powerful with 32-bit memory busses. The Natami aims to put all of the chipset functionality on one chip including an experimental new 68050 processor core.
Also, I'm planning on working on a GLSL shader implementation that will imitate the functionality of an Amiga graphics chipset without outright emulating all of the timing of each function. It's intended to be just enough gusto to make Amos Basic code work on non-Amiga graphics chipsets.
-
@SamuraiCrow
Thanks for that, it looks interesting.
Yeah, I'm thinking that smartphone/multimedia device parts are likely to be cheap in the next couple of years. While I've got time on my hands I can look at ways to replace the ageing Amiga hardware. I won't get very far without a Oscilloscope, but I'll look at picking up a cheap one in the near future.
Check this: (unlikely, but a good idea)
_AAA spec_>
64-bit pixel bus with 114 MHz pixel clock in dual systems which makes 1280x1024 @72Hz screens possible.
128-bit long memory bus bursts
_Hombre spec_> (nearly rubbish)
Indexed 8-bit (256 colors) chunky mode with 24-bit CLUT
non-indexed 16-bit chunky graphic modes
32-bit chunky with 8-bit alpha channel)
1280 x 1024 resolution in 16.8 million colors
the what if:
(http://farm4.static.flickr.com/3334/3642573896_504210dc25.jpg?v=0)
That's Dave's design. I poured over it for 5 minutes, but couldn't fault it.
-
Theoretical digital sound... Can you make a speaker up of many elements? And make a guesstimate how much that would cost...
-
Like this? (http://jasondiyaudio.blogspot.com/2008/01/diy-electrostatic-loudspeakers-esls_11.html)
-
Like this? (http://jasondiyaudio.blogspot.com/2008/01/diy-electrostatic-loudspeakers-esls_11.html)
That are basically earbud headphone on a large scale. I was thinking you could have a hundred plus (per channel) speakers outputting the various frequencies while minimizing the use of ADC/DAC.
Imagine connecting each instrument in a orchestra to a mic. Then having wall to wall speakers. It would be truly immersive sound.
-
That are basically earbud headphone on a large scale. I was thinking you could have a hundred plus (per channel) speakers outputting the various frequencies while minimizing the use of ADC/DAC.
Imagine connecting each instrument in a orchestra to a mic. Then having wall to wall speakers. It would be truly immersive sound.
And a bit of a bother to troubleshoot if one of the speakers blew up ;)
-
Okay here's an idea:
Build a pseudo operating system for the WinUAE shell. Something gives you the ability access Amiga functions from Windows. Also allow WinUAE to run in multiple sandboxes.
-
Also allow WinUAE to run in multiple sandboxes.
How's that different from running multiple instances of UAE?
-
How's that different from running multiple instances of UAE?
Put a hypervisor in so they can talk to each other. (sry I should have put that in)
-
Wow! Weird thread, I can't follow... can someone abstract for me?
-
Wow! Weird thread, I can't follow... can someone abstract for me?
Trying to reverse engineering the co-processor bus.
-
Trying to reverse engineering the co-processor bus.
Why?
The only really need to know what is on the bus is if you plan to build your own chips to sit on the bus... Jens did that and created the Indivision... and hopefully the CloneA soon :D
-
I'll close this investigation, with the following conclusion.
Amiga was right for its time. The world has moved on. The future lies in open source operating systems and open architecture hardware.