Was anyone else disappointed with the A1200?

[sandruzzo]

Originally Posted by Gorf

Can you elaborate?

Yes. Take Aga bus, you have a peak rate at 28 mb. So if you Have

- One chip-ram bus
- One bus for trap door ram (without bitplane penalties)
- one for HW Registers (64 bit transfer rate possible!)
- One for Fast-mem

Even without adding expensive ram, you'll have a peak rate at 28mb*4 = 112mb! This, with a few more pennies..

These are just fixes

[Gorf]

Originally Posted by sandruzzo

Yes. Take Aga bus,

There is no such thing.
That is by no means a bus.

you have a peak rate at 28 mb.

??
Like a speed of 4 km?
Or a electric power of 3 amp?

So if you Have

- One chip-ram bus

still not a bus.

- One bus for trap door ram (without bitplane penalties)

also not a bus, but an expansion port.

- one for HW Registers (64 bit transfer rate possible!)

???
A hardware register bus?
What is that supposed to be?

Please get your terminology right - it is really hard to figure out, what you are actually talking about - in this case I have seriously no clue.

- One for Fast-mem

That is called ZorroII or ZorroIII

Even without adding expensive ram, you'll have a peak rate at 28mb*4 = 112mb! This, with a few more pennies..

no ... sorry, but I don't think you know what you are talking about.
You seem to miss the basic understanding of buses, memory access and frankly all the rest.

[sandruzzo]

@Gorf

I miss some things, maybe my terms aren't ok. I was just wondering what would have been possible if they allowed the possibility to acce to HW register with double-cas(64it) ( maybe whitout bitplanes penalties) instead of 16 bit as the old OCS/ECS.



fai una foto

[Promilus]

Pseudofast ram is "slow ram" and that was a cheap solution to essentially add (hypothetically a lot more) memory by hooking additional RAM to CHIP RAM addressing and refresh signals... Downside was... it was damn slow (hence the name).
You cannot just add new buses - you need to route new signals and create new controller inside ASIC. And Commodore was hardly able to do things like Agnus and Alice. So ... no go. Also - that'd fragment memory even more and you'd have to handle that as a developer...

[sandruzzo]

@Promilus

No question about it, but it could have opened a lot of opportunities. They could have the exact same cycles as main bus and synchronization(226/7 slots), but just with more spare cicles for both chipset(but not bitplanes) and cpu

[Gorf]

Originally Posted by sandruzzo

@Gorf
I was just wondering what would have been possible if they allowed the possibility to acce to HW register with double-cas(64it) ( maybe whitout bitplanes penalties) instead of 16 bit as the old OCS/ECS.

Have look at the ChipSet registers (I assume you are referring to them?)
http://amigadev.elowar.com/read/ADCD.../node0011.html

Most of them will only take a 16bit value and only NEED 16bit or even less!
You don't want to read 64 bit of joystick data at once, when all the information comfortably fits into 16bit.

There are only very few registers that would profit from a 32bit wide access, like eg. the colour registers, which now need 2 accesses instead of one ...

Almost no registers would profit from 64bit (DoubleCAS)

That said:
Paula's AUDx and Floppy DMA could theoretically profit from wider access, but this would need an internal redesign of Paula ... we talked about that many times already in this thread.

A much simpler solution would have been second Paula in parallel for an other 4 sound channels and the DMA map shows there would have been enough room for that as there is an CPU cycle between each audio DMA fetch:
So by changing into "nasty" mode and blocking the CPU these slots could have been used to drive a second Paula - with only rather small changes in Agnus/Alice and no changes to Paula.

[pandy71]

Originally Posted by Promilus

I wouldn't call audio subsystem dependence of screen resolution particular advantage...

LoL - anyone tried to present such functionality as advantage?
Problem is related to fixed DMA slot allocation - trade of between simplification of state machine and some design goals.
AGA could be different introducing twice faster chipset bus and offering new DMA dynamic slots while still offering old, static DMA slot allocation to keep legacy compatibility... AGA could offer this but CBM ignored opportunity.
But nevertheless Paula at 56kHz works well so it shows that some room for improvements was possible (same like adding ADPCM decoder to Paula efficiently doubling sample rate and bit depth so 16 bit at 56kHz without any change in DMA slots).

[sandruzzo]

@Gorf

Think about an Aga Copper than could load 4 16bit registers at once...

[Gorf]

Originally Posted by sandruzzo

@Gorf

Think about an Aga Copper than could load 4 16bit registers at once...

Since registers are per definition on different memory locations, Copper can not store values to 4 of them at once!
This is not how things work.

[sandruzzo]

Originally Posted by Gorf

Since registers are per definition on different memory locations, Copper can not store values to 4 of them at once!
This is not how things work.

I know it Mate. They could have made it possible with a little bit of effort

[Gorf]

Originally Posted by sandruzzo

I know it Mate. They could have made it possible with a little bit of effort

No - this is not possible even on modern computers today.
You don't seem to understand the concept ...

[sandruzzo]

Let me see:

lea.l $dff000,a5
move.l #$09f00000,bltcon0(a5) ; load bltcon0/1 . 2 16 bit registers

What prent it to be 2 registers at once? bus... If cpu can so could have been done by Copper

[Gorf]

Originally Posted by sandruzzo

Let me see:

lea.l $dff000,a5
move.l #$09f00000,bltcon0(a5) ; load bltcon0/1 . 2 16 bit registers

What prent it to be 2 registers at once? bus... If cpu can so could have been done by Copper

That only works if both registers are at addresses exactly next to each other, so there are only very few cases, where this is actually useful - and even less so with 4 addresses in a row.
There is not really not much performance gain to expect on this front.

Nice to have for some use cases but not a huge deal.

And it would make Copper much more complicated, so it is not really easy to archive and it would potentially break compatibility with old copper lists ... you would need to set a different mode for "new Copperlist" and you need to be very careful not to be in the wrong Copper mode, if you only want to write a 16bit value ...

At this point a totally different approach would be much more useful:
A small memory (1-2 KB) inside of a Neo-Copper (like a programmable shader in todays gfx-cards)....

[sandruzzo]

@Gorf

I think only 64 bit inside could suffice. With an "advance move", you could make Copper point to an address (a.k.a registers') and then store the values. With a 2 stage "copper" you could load and store values very fast, like the blitter does!. Not a big deal, for good engineers! Registers are nothing more than fast internal, ram!

[Gorf]

Originally Posted by sandruzzo

@Gorf

I think only 64 bit inside could suffice. With an "advance move", you could make Copper point to an address (a.k.a registers') and then store the values. With a 2 stage "copper" you could load and store values very fast, like the blitter does!.
Not a big deal, for good engineers!

But you don't want the value inside the Copper!
You want the value on the data-lines so Denise/Lisa or Paula can take that value and store it.
That is the magic of copper-lists: the first word tells Agnus/Alice what value to put on the RGA bus, the following word is the data that is put directly from RAM into the registers chosen on the RGA...

To change this you need to implement a lot of changes on every corner - that is equivalent to a complete redesign (they tried with AAA)

Not a big deal, for good engineers!

It is not a big deal, because it is a HUGE deal.

And at this point it would make more sense to leave the old Copper be as it is for compatibility and add something completely new in for advanced features.

[hammer]

Originally Posted by sandruzzo

Yes. Take Aga bus, you have a peak rate at 28 mb. So if you Have

- One chip-ram bus
- One bus for trap door ram (without bitplane penalties)
- one for HW Registers (64 bit transfer rate possible!)
- One for Fast-mem

Even without adding expensive ram, you'll have a peak rate at 28mb*4 = 112mb! This, with a few more pennies..

These are just fixes

Only Lisa can access up to 28 MB/s Chip RAM bandwidth i.e. 3.5 Mhz x 64 bit (via double pump 32 bit) = 28 MB/s which matches 14 Mhz x 32 bit / 2 cycle access Fast Page DRAM spec = 28 MB/s. Lisa has 32-bit data pins.

Lisa has 4X the Chip RAM bandwidth access when compared to ECS Denise.
Lisa is capable of displaying 256 colors (8 bitplanes) in Double PAL/Double NTSC modes.

ECS Denise in double scan resolution modes has reduced to 2 bitplanes i.e. 4 colors.

Alice has 16-bit data pins. Alice's Blitter (2D object manipulator) remained in OCS/ECS's 16-bit x 3.5 Mhz. The Blitter can do very basic arithmetic math, but it's very primitive. Refer to 3DO's MADAM example.

The original intent for AGA was to be bundled with $20 DSP3210 @ 50Mhz as the object manipulator upgrade. DSP3210 is equipped with a hardware barrel shifter beside the 12.7 MIPS (integer pipeline) and 25 MFLOPS FP32 (floating point pipeline) @ 50Mhz. AT&T marketed DSP3210 as "3D and multimedia DSP". Object manipulator switched from 2D to 3D.

DSP3210's role in Amiga Hombre is taken over by the integrated custom PA-RISC @ 100 to 120 Mhz with 3D extensions.

In 3DO, MADAM has custom 3D math hardware and a quadrilateral 3D texture mapper @ 25 Mhz.

Motorola's CPU wasn't price-competitive with a 3D math power use case.

68030 wasn't modified with a fast integer math instruction subset (just a few ADD and MUL instructions moved from ROM'ed microcode to hardware implementation) like its hardware barrel shifter.

There's less need for most 68K instruction set hardware implementations like 68040 when the platform specifically targets 3D-related math. The main difference between 68040 and 68030 is moving instructions from ROM'ed microcode to full hardware implementation at the cost of large-scale transistor usage i.e. 1.2 million transistors.

68882 wasn't designed for game 3D performance i.e. just above 1 MFLOPS @ 50Mhz

Motorola didn't provide Intel-style drop-in RapidCAD (486DX without L1 cache) for 1st generation full 32-bit CPU socket. It's a 68040 infrastructure switch or bust.

RapidCAD is Intel's fastest drop-in CPU for the 386DX socket infrastructure.

There are 486DLC clones for 386DX socket infrastructure that exceeds AMD's 386DX-40.

My Dataquest links show 68040's prices aren't following Intel 486 counterparts. 680EC040 is useless for the Amiga or any desktop 68K platforms.

[hammer]

Originally Posted by sandruzzo

@Gorf

Think about an Aga Copper than could load 4 16bit registers at once...

The Copper's main purpose is to conserve the color register transistor (change the color palette on the fly) and memory bandwidth budgets (e.g. displaying more colors with 3 or 4 or 5 bitplanes) without burdening the CPU.

The Copper is less relevant for packed pixel color display with high memory bandwidth i.e. 1 byte (8-bit, 256 colors), 2 bytes (16-bit, 65,536 colors), and 3 bytes (24-bit, 16,777,216 colors).

Modern GPUs have delta color compression/decompression, texture compression, and a large cache to conserve external memory bandwidth.

Original Amiga team-led 3DO beats the Commodore Semiconductor Group's graphics/audio chipset efforts.

Blame the soft drink CEO for dismantling the original Los Gatos Amiga team.

The Copper induces complexity for mainstream game programmers i.e. it's easier on PC VGA.

[sandruzzo]

Copper is very important to prevent CPU overload. Let's do a real example: chunky-copper. On Aga you can get to 2x2, with copper like i stated, you can archive 1x1 like nothing! Like I told before, they already did it with Blitter: 2 stage chip that is very fast even though it is "primitive". Why is blitter on Aga faster than the same exact chip on ECS? Because you can feed it due to the fast bus, a.k.a you can load it almost at full rate, and blitter can store data into chip-mem faster!

You can even have a copper without any "registers" inside and do load and store at faster speeds like this:

Load datas ---> Store Datas
-------------------Load Datas ---> Store Datas
---------------------------------------Load Datas ----> Store Datas

Not A Big Deal to do!

[hammer]

Originally Posted by xavlahaye

By the mid-90s in Southern France where I come from, I only had one friend with a PC on which we played Doom, the 3d was making me feel sick to be honest, and MS-DOS was just scary. Microsoft was considered evil and PCs were still quite expensive while being completely unsexy. Macs were super expensive AND boring. Console gaming was expensive too
I had several friends with Amigas and I wanted one so bad. I managed to convince my parents to buy me an Escom 1200HD with Blizzard 1230. This is quite late I realize but the cost/performance ratio was not that important, this is what I wanted.
I must have had it for 2 years from 1995 to 1997 before selling it to finance a piano keyboard.
During the first lockdown, I had time and money to get a 1200 again and I don't regret it. It's the perfect hobby computer to reconnect with what made you like computers in the first place!
Nowdays, the 1200 is upgraded with 060/RTG/WIFI/sampler/midi-MT32/shitloads of ram/Graphic tablet on a second serial port,PCMCIA SCSI: all this with the 1200 still in the original case. The machine is rock stable and fast, it's a pleasure to use it.
I don't think the design was bad at all considering everything I do with it 30 years after and how much you can expand it!
It's for me one of the best computers ever made, not so disappointing!

CD32 has additional audio paths from two 16-bit DAC CD-ROM and FMV module
https://bigbookofamigahardware.com/b...2b5d29ffec.jpg.

AA3000+ has additional 16-bit DACs via DSP3210 path.


https://amitopia.com/updated-dsp-321...a-3000-is-out/

In late 1990, Jeff Porter and I took a trip out to AT&T in Bethlehem, PA. They had this new DSP chip, the AT&T DSP3210, that they were selling as a replacement for a whole board of electronics. We didn’t want it for that — we wanted it for a general-purpose signal computing engine. They had an OS, called VCOS/VCAS, which was kind of a perfect match to interface to AmigaOS, which would have allowed multitasking of DSP work, something you didn’t get with the typical DSP of the day. The DSP3210 could do some floating-point operations (single precision only) ten times faster than the 68040. So anyway, the A3000+ had this chip — which lived in the system as a bus master, sharing all of memory with the CPU slot processor — and as well, two audio CODECs. One was for modem projects, a lower bitrate mono CODEC with phase correction, and the other was a 16-bit, CD-quality audio CODEC, for high-quality audio I/O… the DSP would have been able to give us at least eight channels of playback at full CD quality.”

“You can see quite a bit of support circuitry for the DSP in the upper lefthand corner of this board. There was an audio CODEC here, designed to allow 16-bit, 2-channel recording, and playback. This was very cutting edge at the time, such chips, common today, were just becoming available. In addition, there was a separate mono CODEC with hardware phase correction, which supported modem protocols up to V32. The actual DSP was located above and to the right of the CPU

It's too bad the CD32 FMV module wasn't a general-purpose "3D and multimedia".

A1200 was "PCJr'ed".

[hammer]

Originally Posted by sandruzzo

Copper is very important to prevent CPU overload. Let's do a real example: chunky-copper. On Aga you can get to 2x2, with copper like i stated, you can archive 1x1 like nothing! Like I told before, they already did it with Blitter: 2 stage chip that is very fast even though it is "primitive". Why is blitter on Aga faster than the same exact chip on ECS? Because you can feed it due to the fast bus, a.k.a you can load it almost at full rate, and blitter can store data into chip-mem faster!

You can even have a copper without any "registers" inside and do load and store at faster speeds like this:

Load datas ---> Store Datas
-------------------Load Datas ---> Store Datas
---------------------------------------Load Datas ----> Store Datas

Not A Big Deal to do!

Why the additional complexity with chunky-copper? CD32 has Akiko C2P.

AGA ChipRAM has less bandwidth contention, hence the same Biltter has up to 60% boost. Lisa has up to 4X (400 percent) performance boost which is mismatched with a 60 percent boosted Biltter.

Chip RAM only 68EC020 (effectively 7 Mhz) is about 56% of AGA Biltter. There are reasons for CPUFastBilt patches with faster 68K CPUs i.e. the accelerator turned into de-accelerator.

Commodore's Amiga chipset = the original de-accelerator, before S3.

AGA Lisa and CPU's access to 32-bit Chip RAM is fine for displaying +50 fps 256 colors 320x200 Star Wars Dark Forces when the primary object manipulator is very fast.