@Hammer

Quote:

Hammer wrote: @cdimauro Quote: @cdimauro Even on 1990, after FIVE year that the Amiga 1000 was introduced? New fabs and R&D need resources.

Engineers = R&D and they were paid... for doing what?
Quote:

Quote: From Commodore - The Final Years, However, those who looked closer at the annual report noted that Commodore’s expenditure in R&D was exceedingly low for a billion dollar company, spending only 3% of its revenues, or $31.4 million, on engineering. All this while the company spent $174.3 million, or 16.6%, on Sales and Marketing. This put Commodore at the bottom of computer companies, including Apple and Atari, in R&D expenditures. R&D is shared between Commodore PC's cost reduction R&D and Amiga R&D.

OK, but see above: there were PAID = R &D engineers working on Amiga.
Quote:

Quote: @cdimauro Then the question raises: was there any COMPETENT engineer left for upgrading the chipset? Or... none? Commodore management removed the original Amiga engineers. Commodore in-house engineers and managers have #metoo mindset instead of trailblazing A1000. Commodore in-house engineers and managers have a talent for cost reduction e.g. A500. The two halves made the A500's successful. In Commodore - The Final Years book, Commodore in-house engineers and sidelined Jeff Porter have claimed they can beat Bill Sydnes and Jeff Frank on A300's cost reduction. Commodore in-house engineers have identified mistakes in A600's cost structures. Ex-IBM PC personnel doing cost reductions is a joke. A300's purpose is to replace C64 in markets with weak currencies and low-income socio-economic demographics. The A300 wasn't supposed to replace the A500. Commodore has two main revenue pillars i.e. C64 and A500.

Indeed. And the engineers left hadn't the talent to evolve the Amiga platform how it was needed...
Quote:

Quote: @cdimauro Having to create new masks for new chips could have been a nice chance to introduce new features as well. You can clearly see it from what you've reported about how the new features were progressively added to the ECS Denise, 'til it reached the final status. "Read my lips, no new chips" refers to Amiga's graphics core architecture change.

Do you've a source for that?

Anyway and beside that, ECS's:
- genlock functionalities;
- programmable video modes;
- ultra-hires bitmap + sprite;

ARE graphics core architecture changes...
Quote:

Genlock is not a new feature since OCS Denise has Genlock, early ECS Denise broke the existing Genlock feature.

Nevertheless, the ECS's genlock features are way more advanced compared to the OCS ones. OCS was very very primitive from this PoV.
Quote:

AGA has met VGA's 256 colors criteria and reached entry-level SVGA i.e. 640x480p 256 colors.

Amiga could have had 256 colours already with the Amiga 500/2000, if the EHB (which was a very quick & dirty patch to Denise & Agnus) was extended by using 3 bitplanes instead of only one.

So, basically adding the 8 shades that Commodore already introduced with the Commodore 16 & Plus/4.
Quote:

The sidelined Jeff Portter was moved to the CDTV division where several managers have resigned themselves due to low R&D resources. From the CDTV division's low R&D resources, CD32 was born with Akiko C2P i.e. a hardware patch on AGA's chunky pixels issue.

You already know my opinion about Akiko and its crappy hardware C2P...
Quote:

Jeff Frank and Bill Sydnes fuked-up the main Amiga R&D division. The main Amiga R&D division has Amiga custom chipset R&D and Jeff Porter has lost control over this division. Purchase Commodore -The Final Years book for Jeff Porter's wish list before being sidelined by pro-PC Jeff Frank and Bill Sydnes.

Right but... what happened between 1985 and 1990? What have done the Commodore engineers for evolving the Amiga platform?

Because that was before the "IBM guys" joined, right?
Quote:

Jeff Porter's wish list follows the operational AGA state which includes chunky pixels mode.

I'm curious to see how it would have been implemented...
Quote:

Pro-PC campers Jeff Frank and Bill Sydnes have "lost more than six months" and are the major contributors to the $366 million loss that mortally wounded Commodore. Commodore -The Final Years book reveals the timeline and the fckups by pro-PC Jeff Frank and Bill Sydnes.

If a company goes bankrupt only for a 6 months delay, then it was already in very bad shape.
Quote:

Jeff Frank's road map is an important factor for the situation in the critical 1991 to 1992 years.

See above: it was already too much critical. Commodore was doomed to die.
Quote:

For 3D, DSP3210 is the low cost method to increase compute power to beat 80386DX-33, Am386DX-40, 80486 and 68040 class CPUs. You would need costly 68060-50 or Pentium 60 to beat cheap DSP3210-50 on 3D. DSP3210's i.e. DAU(FP) and CAU (INT) has access to 32-bit bus. DSP3210 is designed to interface with 680X0 and 80X86 bus i.e. not foreign for 68K based machines.

Again? I've proved that adding this DSP would have been a non-sense.
Quote:

I view DSP3210 like IEEE-754 stream processor unit in one of AMD's Graphics Core Next (GCN).

Irrelevant.

@Karlos

Quote:

Karlos wrote: @cdimauro Yeah, even basic SID style filters would've been a good value add for musicians. Whether it's just filtering out unwanted noise from a lofi sample or doing subtractive synthesis on a waveform shape, that's all you need. The lowpass mode would definitely benefit from a resonance control too. The key purpose of MidiIn is to make the Amiga an affordable hardware sampler capable of better-than-8-bit output without needing a soundcard. The screenshot there is from my Amiga back when I was using it for this. It works exactly like a hardware sampler, allowing you to do all kinds of multitimbral, multisampling with key splits etc, controlled over MIDI. The replay on Paula is 14-bit at up to 56kHz if you are using DblPal or CGX modes. In that screenshot I was using a 48kHz output rare with 16-bit multisampled (one sample per 4 semitones) famous Mellotron choir sound. It was set to 8 voices there but I've definitely used up to 20 channels at 48kHz without any issues on a 25MHz 040. It has some of the expected artefacts of 14 but replay but IIRC it supports several soundcards too.

I see. But it required a powerful (and expensive, at the time) hardware... basically only for that (if you need several channels).

@cdimauro

MIDIIn scales pretty well, to be honest, but as with a real sampler, the more RAM the better and being software mixed, more CPU => more polyphony.

I used vanilla Paula 4 channel mode, using left and right outputs as "independent" signal chains more often than I used MidiIn. Occasionally I'd use all 4 through a single input. It all depends on what I was doing. When I was using the Amiga as an instrument it was typically in a multitrack situation where it would be mixed later, even if that was as mods. Picture, if you will, writing 4 different mods that are arrangements of a single song. Then you independently record each mod and then mix the recordings after. The Amiga made this possible because the hardware timing was absolutely rock solid, even between machines. I sometimes used two Amigas at once, set to the same tempo, started them simultaneously and they'd retain sync.

Such an underrated musical device.

Last edited by Karlos on 03-Aug-2024 at 04:30 PM.
Last edited by Karlos on 03-Aug-2024 at 04:25 PM.

_________________
Doing stupid things for fun...

If you want to know how Paula can sound as an instrument, the soundtrack for one of my MC64K demos is a multitrack recording using high quality multi samples, processed via external effects (noise reduction, reverb)

https://youtu.be/qxL7BXOhyE4?si=RsePEtSAkwHikoK_

By contrast, this one uses a multichannel OctaMED SS module, played back in basic 14-bit with no external processing:

https://youtu.be/OgThodWAVOk?si=mr-b6KAK5RMp7uHS

You might recognise some of the samples, there's a couple from Exit Planet Dust.

Last edited by Karlos on 03-Aug-2024 at 09:14 PM.

_________________
Doing stupid things for fun...

@Karlos

Quote:

Karlos wrote: @cdimauro MIDIIn scales pretty well, to be honest, but as with a real sampler, the more RAM the better and being software mixed, more CPU => more polyphony. I used vanilla Paula 4 channel mode, using left and right outputs as "independent" signal chains more often than I used MidiIn. Occasionally I'd use all 4 through a single input. It all depends on what I was doing. When I was using the Amiga as an instrument it was typically in a multitrack situation where it would be mixed later, even if that was as mods. Picture, if you will, writing 4 different mods that are arrangements of a single song. Then you independently record each mod and then mix the recordings after. The Amiga made this possible because the hardware timing was absolutely rock solid, even between machines. I sometimes used two Amigas at once, set to the same tempo, started them simultaneously and they'd retain sync. Such an underrated musical device.

Well, that's how musicians were working with tools like ProTracker: recording one track at the time, while playing the entire soundtrack, and then again for the next track, 'til you completed all 4 tracks.

Your problem is that if you split it in 4 mods, then you can only play 1/4 of the soundtrack at the time, so you don't get the full melody at the same time 'til you mix all 4 mods.
Quote:

Karlos wrote: If you want to know how Paula can sound as an instrument, the soundtrack for one of my MC64K demos is a multitrack recording using high quality multi samples, processed via external effects (noise reduction, reverb) https://youtu.be/qxL7BXOhyE4?si=RsePEtSAkwHikoK_ By contrast, this one uses a multichannel OctaMED SS module, played back in basic 14-bit with no external processing: https://youtu.be/OgThodWAVOk?si=mr-b6KAK5RMp7uHS

Nice to hear. How many tracks? 8?
Quote:

You might recognise some of the samples, there's a couple from Exit Planet Dust.

Unfortunately no: I don't know it.

@cdimauro

Quote:

Your problem is that if you split it in 4 mods, then you can only play 1/4 of the soundtrack at the time, so you don't get the full melody at the same time 'til you mix all 4 mods.

Once you've recorded a a part, you can replay it or any section over and over. It's just a big sound file on a disk recorder (or more often another computer). So you don't have to figure out each mod in complete isolation to the rest. This is no different to multitrack recording any other instrument, e.g a piano. The only difference is that when you are done arranging, you aren't physically playing that instrument, you're just hitting the play button on your tracker. And you can save your sequence performance off to disk as well as the recording of it. You do as many different mods as you need but in the end, you also only need a few patterns per mos rather than a whole full duration mod because you can easily repeat and arrange patterns as needed once you've recorded them all and are mixing them, so you aren't really doing as much work as you might think.

_________________
Doing stupid things for fun...

@cdimauro

Quote:

@cdimauro Do you've a source for that? Anyway and beside that, ECS's: - genlock functionalities; - programmable video modes; - ultra-hires bitmap + sprite; ARE graphics core architecture changes...

From Commodore engineer Mike Sinz.

http://www.bambi-amiga.co.uk/amigahistory/mikesinz.html
Quote:

Mike Sinz: The A3000 had a number of radical departures from earlier designs *other than* the ECS chipset.

Quote:

@cdimauro Amiga could have had 256 colours already with the Amiga 500/2000, if the EHB (which was a very quick & dirty patch to Denise & Agnus) was extended by using 3 bitplanes instead of only one. So, basically adding the 8 shades that Commodore already introduced with the Commodore 16 & Plus/4.

A quick fix would be turning EHB into a proper arbitrary 64-color mode instead of a shadow 32-color set.

AGA's faster memory bandwidth is needed for Lisa's 64-bit wide sprites as a parallax background method for higher color single playfield mode.

AGA's faster memory bandwidth also improves the existing 16-bit Blitter by about 60 percent.

Quote:

@cdimauro You already know my opinion about Akiko and its crappy hardware C2P...

AGA only needs a better game-optimized SDK to improve consistency.

Based on VGA mode 13h, Michael Abrash's VGA mode X was published in July 1991 and 3rd party developers have equal access to it.

From 1990 to 1994, the Amiga doesn't have Michael Abrash's evangelism for sharing optimized code samples for the gaming PC platform.

Many Amiga developers with tech demos keep their knowledge to themselves.

From 1991 to 1994, optimized Blitter C2P knowledge is not equal across 3rd party developers.

Without equal access to game-optimized knowledge, the platform's games have less consistency and a weak baseline.

The Amiga can't match Michael Abrash's optimized code-sharing evangelism from 1991 and beyond.

Michael Abrash was hired by Microsoft for Windows NT 3.x's graphics-related optimization i.e. Microsoft paid Abrash.

Quote:

Again? I've proved that adding this DSP would have been a non-sense.

DSP3210 is no different from the Amiga custom chipset i.e. both have their setup cost.

Last edited by Hammer on 04-Aug-2024 at 10:41 AM.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

Yes, what the audio really needed more than anything else is better graphics...

(Yes, I know there is a relationship with the maximum playback frequency and the displaymode).

_________________
Doing stupid things for fun...

@Hammer

Quote:

Hammer wrote: @cdimauro Quote: @cdimauro Do you've a source for that? Anyway and beside that, ECS's: - genlock functionalities; - programmable video modes; - ultra-hires bitmap + sprite; ARE graphics core architecture changes... From Commodore engineer Mike Sinz. http://www.bambi-amiga.co.uk/amigahistory/mikesinz.html Quote: Mike Sinz: The A3000 had a number of radical departures from earlier designs *other than* the ECS chipset.

Well, ECS was an upgrade to OCS: nothing new here. Nevertheless, they were new chips and changes to its core.
Quote:

Quote: @cdimauro Amiga could have had 256 colours already with the Amiga 500/2000, if the EHB (which was a very quick & dirty patch to Denise & Agnus) was extended by using 3 bitplanes instead of only one. So, basically adding the 8 shades that Commodore already introduced with the Commodore 16 & Plus/4. A quick fix would be turning EHB into a proper arbitrary 64-color mode instead of a shadow 32-color set.

1) it would have been too much expensive (you need to add 32 x 16-bit registers);
2) it wouldn't have solved the problem, because then you can have only 128 colours (64 colors + their halved shades);
3) Have you took a look at how the Amiga chipset registers are defined? I don't think so. In fact, it wouldn't have possible because the last word in the OCS (and then ECS & AGA as well) registers is reserved and last of those new 32 colours colours clashes with it.
Quote:

AGA's faster memory bandwidth is needed for Lisa's 64-bit wide sprites as a parallax background method for higher color single playfield mode.

First of wall, why you talk about that in THIS context?

Second, and more important, do you know that if you enable the horizontal scrolling on AGA with 64-bit fetch mode, then you have only ONE 64 pixel sprite available?
Quote:

AGA's faster memory bandwidth also improves the existing 16-bit Blitter by about 60 percent.

Absolutely no! I've made the precise calculations here some time ago, and it's only 40%.

In fact, numbers at hand, AGA with 64-bit fetch mode would have allowed to move from 5 to 7 bitplanes (32 -> 128 colours) keeping exactly the same frame rate.
Quote:

Quote: @cdimauro You already know my opinion about Akiko and its crappy hardware C2P... AGA only needs a better game-optimized SDK to improve consistency. Based on VGA mode 13h, Michael Abrash's VGA mode X was published in July 1991 and 3rd party developers have equal access to it. From 1990 to 1994, the Amiga doesn't have Michael Abrash's evangelism for sharing optimized code samples for the gaming PC platform.

Again, we had already the Amiga Hardware Manual and we need no evangelist to know how to use our machine.
Quote:

Many Amiga developers with tech demos keep their knowledge to themselves.

Who cares? Game developers weren't less skilled.

And, more important, demo usually shown effects that couldn't be used / ported to games.
Quote:

From 1991 to 1994, optimized Blitter C2P knowledge is not equal across 3rd party developers.

Because that's the 2D age. Even for PCs.
Quote:

Without equal access to game-optimized knowledge, the platform's games have less consistency and a weak baseline.

Game developers had enough knowledge.
Quote:

The Amiga can't match Michael Abrash's optimized code-sharing evangelism from 1991 and beyond. Michael Abrash was hired by Microsoft for Windows NT 3.x's graphics-related optimization i.e. Microsoft paid Abrash.

And... who cares? We had good game developers as well, and our hardware hasn't needed evangelists to explain how to exploit it.
Quote:

Quote: Again? I've proved that adding this DSP would have been a non-sense. DSP3210 is no different from the Amiga custom chipset i.e. both have their setup cost.

That's totally different. Evidently you haven't programmed an Amiga in your life neither you have studied the DSP documentation.

@cdimauro

Quote:

Well, ECS was an upgrade to OCS: nothing new here. Nevertheless, they were new chips and changes to its core.

You're inserting yourself again.

ECS's "Productivity Mode" was operational with A2000 on September 20, 1988.

Quote:

1) it would have been too much expensive (you need to add 32 x 16-bit registers);

Nope, refer to CSG fabricated C65 chipset with 256 colors display from 4096 color palette.

CSG can fabricate C65's 256-color display capable VIC-III chipset, but not AA's Lisa.

Lisa can do entry-level SVGA's 640x480p with 256 colors from a 16.7 million colors palette.

The 16.7 million color palette is optional for my Tseng Labs ET4000 SVGA card i.e. lower cost model has VGA's 18-bit color palette.

C65's 256 color mode has VGA's 320x200 low resolution, A500-level Chip RAM bandwidth, and a 4096 color palette.

Quote:

3) Have you took a look at how the Amiga chipset registers are defined? I don't think so. In fact, it wouldn't have possible because the last word in the OCS (and then ECS & AGA as well) registers is reserved and last of those new 32 colours colours clashes with it.

AGA has a 64-color display mode. LOL

Quote:

Again, we had already the Amiga Hardware Manual and we need no evangelist to know how to use our machine.

Where's the "game ready" optimized blitter C2P code sample? Have you looked at PS1's PSY-Q dev kit?

Quote:

Second, and more important, do you know that if you enable the horizontal scrolling on AGA with 64-bit fetch mode, then you have only ONE 64 pixel sprite available?

https://eab.abime.net/showpost.php?p=1293564&postcount=2
"The demo I published for the Blitz tutorials in Amiga Future used a 4+4 bitplane display plus two 64-pixel-wide sprites and ran fine on an A1200/030"


Quote:

Game developers had enough knowledge.

Tell that to the developers of EA's Magic Carpet and IDsoftware's Doom.


https://bigbookofamigahardware.com/bboah/product.aspx?id=1604
Quote:

The “chunky to planar� logic was thought out in a lunchtime conversation between Beth Richard (system chip design), Chris Coley (board design), and Ken Dyke (software) over Subway sandwiches on a picnic table in a nearby park one day, because Ken was telling us how much of a pain it was to shuffle bits in software to port games from other platforms to the Amiga planar system. We took the idea to Hedley Davis, who was the system chip team manager and lead engineer on Akiko and he said we could go ahead with it. I showed him the “napkin sketch� of how I thought the logic would work and was planning on getting to it the next day as it was already late afternoon by that point. I came in the next morning and Hedley had completed it already, just from the sketch!

Tell that to Commodore's in-house CD32 software engineer Ken Dyke, hence Akiko's hardware C2P patch was created!

Have you looked at PS1's PSY-Q dev kit? There's a reason why modern-day game development has bucketloads of game-bias code samples from NVIDIA, AMD, Microsoft, and Intel.

https://www.codeproject.com/Articles/994774/Game-Companies-Speed-Up-Development-with-Intel-Sam
Quote:

Game Companies Speed Up Development with Intel Sample Code. All game developers from indie to lifetime professional will, at some point, benefit from code that someone else wrote. Whether it is to understand a new feature, fix a previously unsolvable problem, or saving time rather than writing it from the ground up, permissively licensed sample code is an invaluable tool. Intel provides a wealth of game sample code at the Game Developer section of the Intel® Developer Zone.

PS1's PSY-Q dev kit uses the above approach. The "spoon fed" by platform vendors.

You're intellectually dishonest.

Last edited by Hammer on 05-Aug-2024 at 02:03 PM.
Last edited by Hammer on 05-Aug-2024 at 01:56 PM.
Last edited by Hammer on 05-Aug-2024 at 09:38 AM.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@Hammer

Quote:

You're inserting yourself again.

Phrasing.

_________________
Doing stupid things for fun...

@Hammer

Quote:

Hammer wrote: @cdimauro Quote: Well, ECS was an upgrade to OCS: nothing new here. Nevertheless, they were new chips and changes to its core. You're inserting yourself again.

LOL You don't know how the things work the silicon industry and continue to talk.
Quote:

ECS's "Productivity Mode" was operational with A2000 on September 20, 1988.

Correction: it was DEMONSTRATED which does NOT mean that it was production-ready.

Words are important, right?
Quote:

Quote: 1) it would have been too much expensive (you need to add 32 x 16-bit registers); Nope, refer to CSG fabricated C65 chipset with 256 colors display from 4096 color palette.

You completely missed the context (!) and, specifically, YOUR words:

A quick fix would be turning EHB into a proper arbitrary 64-color mode instead of a shadow 32-color set.

EHB was a quick fix (as we know, it was a "last minute" change to Denise), but NOT the change that you're asking for, which requires a radical change in the chipset and TRIPLING the registers used for what you've suggested.

BTW, my proposal is, on the exact contrary, a quick fix, because it's just an extension of EHB ala Commodore 16.

And the context was (guess what): minimal changes to the chipset, like the ones which were done with ECS.
Quote:

CSG can fabricate C65's 256-color display capable VIC-III chipset, but not AA's Lisa.

VIC-III has 256 x 16-bit only for the palette entries which is MORE THAN the entire ECS' registers...
Quote:

Lisa can do entry-level SVGA's 640x480p with 256 colors from a 16.7 million colors palette. The 16.7 million color palette is optional for my Tseng Labs ET4000 SVGA card i.e. lower cost model has VGA's 18-bit color palette.

Irrelevant in this context (when it'll happen that you recall of what we're talking).
Quote:

C65's 256 color mode has VGA's 320x200 low resolution, A500-level Chip RAM bandwidth, and a 4096 color palette.

But required A LOT of transistors for this.

My proposal introduces 256 colours from a palette of 4096 (putting it above Acorn Archimedes, which has only 16 colours, each one with 16 shades) with very very minimal changes, and making it competitive (again).
Quote:

Quote: 3) Have you took a look at how the Amiga chipset registers are defined? I don't think so. In fact, it wouldn't have possible because the last word in the OCS (and then ECS & AGA as well) registers is reserved and last of those new 32 colours colours clashes with it. AGA has a 64-color display mode. LOL

Sure. And clearly you've no clue how it works. In fact, it uses the 32 colours entries of OCS/ECS as SELECTORS for the 256 24-bit colours palette.

Total: 32 x 16 bit (the selectors) + 256 x 16 bit (low 12 bits) + 256 x 16 (high 16 bits).

That's why before I've talked about TRIPLING the registers used: you need 32 x 16 bit (the selectors) + 64 x 16 bit (colours entries).

Again, you don't know of what you talk about...
Quote:

Quote: Again, we had already the Amiga Hardware Manual and we need no evangelist to know how to use our machine. Where's the "game ready" optimized blitter C2P code sample? Have you looked at PS1's PSY-Q dev kit?

You're really hopeless. PS1 = December '94. Even if you take two years before, it's December 1992: AGA was already out.

You don't know what a context in a discussion is...
Quote:

Quote: Second, and more important, do you know that if you enable the horizontal scrolling on AGA with 64-bit fetch mode, then you have only ONE 64 pixel sprite available? https://eab.abime.net/showpost.php?p=1293564&postcount=2 "The demo I published for the Blitz tutorials in Amiga Future used a 4+4 bitplane display plus two 64-pixel-wide sprites and ran fine on an A1200/030"

Thanks for showing again how much ignorant you're, since you have no clue at all of how the AGA chipset worked.

First of all, you haven't noticed the big bands at the left and right sides.

Now I explain you why, taking the Blitz documention.
http://docs.amiblitz.de/blitzprogrammers/0143.html
The number of sprites available will depend on the type of display and the fetchmode settings Most AGA modes will require the display to be shrunk horizontally for 8 sprites to be displayed.
[...]
Note that it is unrealistic to display more than 4 bitplanes and have more than 3 sprite channels available, the adjust required results in a very narrow display indeed.

http://docs.amiblitz.de/blitzprogrammers/0141.html
The width of the display will be less than the default 320/640/1280 when smooth scrolling is enabled.

http://docs.amiblitz.de/blitzprogrammers/0144.html
We think it is actually impossible for displays to run at fetchmode 3 with more than I sprite without having to adjust the display to around 256 pixels across.

Which is exactly the case and what I was talking about.

But from the same thread, on a following post:
https://eab.abime.net/showpost.php?p=1293714&postcount=7
Just to add a point here: if you want a scrolling screen plus 64 pixel wide sprites on AGA you basically can only do that full screen by either not taking advantage of the higher bitplane fetch modes or shifting the display to the right by 64 pixels. This much of a shift is usually not acceptable so you only end up with the first option.

Which would essentially mean that for a 4+4 dual playfield display you'd have no better performance than running a game in 16 colour hires on OCS. Or in short, you'd have a very hard time getting it to perform.

This is why the manual says you can't mix it.

Do note that 256 colours + 64 pixel sprites + no scrolling can be done just fine, though.

Which you clearly have not read or (much probably) not understand.

On the other hand, what I can expect from you? You never opened the Amiga hardware manual neither programmed the Amiga hardware. You're a complete ignorant which is ridiculously trying to teach the baker how to cook the bread...
Quote:

Quote: Game developers had enough knowledge. Tell that to the developers of EA's Magic Carpet and IDsoftware's Doom.

Ah, do they have an SDK available? Which one? Care to show it?

Besides that, you continue to completely missi the context:
- Magic Carpet -> 1994
- Doom -> 1993.

Hopeless...
Quote:

https://bigbookofamigahardware.com/bboah/product.aspx?id=1604 Quote: The “chunky to planar� logic was thought out in a lunchtime conversation between Beth Richard (system chip design), Chris Coley (board design), and Ken Dyke (software) over Subway sandwiches on a picnic table in a nearby park one day, because Ken was telling us how much of a pain it was to shuffle bits in software to port games from other platforms to the Amiga planar system. We took the idea to Hedley Davis, who was the system chip team manager and lead engineer on Akiko and he said we could go ahead with it. I showed him the “napkin sketch� of how I thought the logic would work and was planning on getting to it the next day as it was already late afternoon by that point. I came in the next morning and Hedley had completed it already, just from the sketch! Tell that to Commodore's in-house CD32 software engineer Ken Dyke,

Thanks for proving that the hardware guys had no clue on what the developers needed, and it was a software guy that had to tell it to them.
Quote:

hence Akiko's hardware C2P patch was created!

Thanks for confirming that the hardware guys had still no clue of what was really needed for the C2P, and they created this logic without a DMA (which was available on Akiko), so forcing the CPU to be fully busy on that and DOUBLING the conversion time.

Only Amiga engineers made it possible.

Ah, and BTW, this was already too late, since we're talking about the CD32. Another proof that the Amiga engineers never understood what was needed for developers and evolved the platform accordingly...
Quote:

Have you looked at PS1's PSY-Q dev kit? There's a reason why modern-day game development has bucketloads of game-bias code samples from NVIDIA, AMD, Microsoft, and Intel.

No, I don't and I don't care because it's completely out of context.

BTW, have you ever opened an Amiga manual? I don't think so. Guess what: they were the Amiga's SDK...
Quote:

https://www.codeproject.com/Articles/994774/Game-Companies-Speed-Up-Development-with-Intel-Sam Quote: Game Companies Speed Up Development with Intel Sample Code. All game developers from indie to lifetime professional will, at some point, benefit from code that someone else wrote. Whether it is to understand a new feature, fix a previously unsolvable problem, or saving time rather than writing it from the ground up, permissively licensed sample code is an invaluable tool. Intel provides a wealth of game sample code at the Game Developer section of the Intel® Developer Zone. PS1's PSY-Q dev kit uses the above approach. The "spoon fed" by platform vendors.

See above: totally irrelevant and out of context.
Quote:

You're intellectually dishonest.

You started again the Italian's "specchio riflesso". How childish you can be...

This is the audio thread, right? Just checking, you know, for a friend like.

_________________
Doing stupid things for fun...

@Hammer

Quote:

You're intellectually dishonest.

you are true ... but he was right about one thing: "a-eon hardware is a crappy expensive thing".

Last edited by tlosm on 06-Aug-2024 at 11:18 AM.

_________________
I love Amiga and new hope by AmigaNG
A 500 + ; CDTV; CD32;
PowerMac G5 Quad 8GB,SSD,SSHD,7800gtx,Radeon R5 230 2GB;
MacBook Pro Retina I7 2.3ghz;
#nomorea-eoninmyhome

@cdimauro

Quote:

@cdimauro You don't know how the things work the silicon industry and continue to talk

Irreverent.

Commodore's "no new chips" directive has its internal Commodore context.

"Read my lips, no new chips" is a "chant" or "slogan" from Commodore management.
https://dictionary.cambridge.org/dictionary/english/chant

For the most part, the A3000 has 32-bit upgrades for the CPU, Fast RAM, Zorro slots, and Chip RAM but the core Amiga graphics architecture remained in their 16-bit variant which is common with ECS-compliant A500 and A2000.

After removing the original Amiga team's governance over the Amiga R&D, similar ranking Commodore engineers are bickering among themselves on 32-bit Amiga graphics architecture upgrade, hence 16-bit ECS was the fallback option.

Henri Rubin didn't show strong leadership.

Examples of road map debates:
Jeff Porter has "8 bitplanes with 16 million colors".
Dale Luck preferred 16-bit color before moving to 24-bit color.
There are more arguments.

Quote:

You completely missed the context (!) and, specifically, YOUR words: A quick fix would be turning EHB into a proper arbitrary 64-color mode instead of a shadow 32-color set. EHB was a quick fix (as we know, it was a "last minute" change to Denise), but NOT the change that you're asking for, which requires a radical change in the chipset and TRIPLING the registers used for what you've suggested.

OCS's EHB was designed under 1985's CSG's chip fabrication capability e.g. 5-micron NMOS process node.

C65 used CGS's newer 2-micron CMOS process node.

AA Alice used CGS's newer 1.5-micron CMOS process node.

During 1990, Commodore was promoting C65 among the 3rd party game developer community when Wing Commander was released in 1990.

Quote:

From Commodore - The Final Years Commodore’s Large Scale Integration department, headed by Bob Olah, began preliminary investigations in July 1985 into a CMOS 6502 chip which Lenthe called the 55C02. (He eventually shortened the name to 5502.) The LSI group would design the chip using 3 micron CMOS. (skip) On his own, he decided to resurrect the 5502 project, this time using 2 micron CMOS. He dubbed the new chip the 4502. “All new CMOS custom chips were given the series number of 4000 and up, so 4502 was the obvious choice,� he says. “The 4502 core development started in late 1985. The original designers were myself and Charles Hauck.�

My argument is coupled with process node improvements with CSG.


For ECS Denise,
Quote:

From Commodore - The Final Years (skip) The arguments they made won over Gerard Bucas, and the team accepted that a 12-bit color table and 8 color registers would be too complex to work into the current chip. However, Bob Welland compromised and presented a case for a simpler scheme to allow a 6-bit color palette (64 colors) and only 4 additional color registers. (skip) A few days later, on September 7, Hedley Davis proposed an alternative plan. Instead of putting the color function in a chip, he proposed a 640 by 400 31 KHz scan converter card. The solution would not rely on VGA multisync monitors, but instead would output through the RGB (Red Green Blue color model) port to existing Amiga monitors. The device cost $31.50 in parts for the A2000 board and $40.50 for the A500 board.

That's September 1987.

ECS mode has an additional four color registers and a 64-color palette.

ECS mode's 8-color with the existing 12-bit palette was rejected due to complexity. LOL

A flicker fixer (AMBER) alternative was proposed for A2000 and A500.

Unlike ECS 640x400p mode, AGA has a common 16.7 million color palette across 15 kHz and hi-res 31 kHz modes.


Quote:

@cdimauro Thanks for showing again how much ignorant you're, since you have no clue at all of how the AGA chipset worked. First of all, you haven't noticed the big bands at the left and right sides.

I did notice them and I find them as acceptable compromises i.e. good enough for SNES, it's good enough for Amiga AGA.


Quote:

@cdimauro Now I explain you why, taking the Blitz documention. http://docs.amiblitz.de/blitzprogrammers/0143.html The number of sprites available will depend on the type of display and the fetchmode settings Most AGA modes will require the display to be shrunk horizontally for 8 sprites to be displayed. [...] Note that it is unrealistic to display more than 4 bitplanes and have more than 3 sprite channels available, the adjust required results in a very narrow display indeed. (cutting your defamation bullshit)

Don't assume. I'm aware of the gotchas with AGA.

https://youtu.be/33kH9DdNznA?t=588

For the background layer, use the Copper to multiplex the 128-pixel wide 16-color sprites. The 16 colors sprite needs to be ganged.

My 64-bit sprite statement assumes Copper multiplexing e.g. tree line background, multiple buildings background, some mountain range background, some clouds background, and 'etc'.

All hardware has design compromises.

Did you assume my "higher colors" statement to be strictly 256 colors?

In the past, I did state Fast RAM is recommended with 256-color action AGA gaming e.g. Turrcian 2 AGA. I'm aware of AGA's composition capability gotchas.


AGA's 2D composition capability issue wouldn't be a problem if the CPU side's frame buffer composition performance was fast enough.


https://www.youtube.com/watch?v=5scuw8lgEDc
With fast enough compute power, AGA can display 256 color Beats Of Rage. The PC style strong compute with near-dumb frame buffer method.

Note why I prefer cheap compute power from RISC processor approach. You haven't realized why I'm biased towards compute power, hint: I'm aware of AGA's composition capability limitations.

AGA's 2D composition capability is mostly for backward compatibility and some advancement. AGA's Chip RAM connection with the CPU is fast enough to display generated frames from the CPU side e.g. 61 fps 320x200 with 256 colors.


https://www.youtube.com/watch?v=A39vwT2w5po&t=0s
Final Fight AGA tech demo
Machine: physical A4000T, gimped 68040 @ 25 MHz, 12 MB Fast RAM
Resolution: 320×224 pixels
Depth: 7 bitplanes (128 colors)
Background layer: 15 colors with 384×144 pixels

68040's compute power needs to be cheap, hence it wouldn't be 68K.

Quote:

Thanks for proving that the hardware guys had no clue on what the developers needed, and it was a software guy that had to tell it to them.

Don't stereotype, one of Amiga engineer's road map debaters called for a 3D focus chipset in 1987, but his person didn't have the authority to tell others what to do.

Jeff Porter called for "8 bitplanes with 16 million colors" i.e. mooooore colors.

Ex-Amiga engineers led 3DO has chunky pixels.

My point with Ken Dyke's statement is to show how your "Amiga manual" argument is insufficient.

Quote:

No, I don't and I don't care because it's completely out of context.

It's reverent due to marketplace competition.

Quote:

@cdimauro Besides that, you continue to completely missi the context: - Magic Carpet -> 1994 - Doom -> 1993.

So, Doom appeared by magic? Doom was in development in 1992.

Raven Software's September 1993 released ShadowCaster has 3D engine improvements after Wolfenstein 3D (May 1992). John Carmack wrote the ShadowCaster 3D engine during his technology research after id Software completed Wolfenstein 3D.

ShadowCaster 3D (released in Sep 1993) engine improvements are between Wolfenstein 3D (released in May 1992) and Doom (released in Dec 1993).

Magic Carpet was in development in 1993, https://eab.abime.net/showpost.php?p=903812&postcount=17
Magic Carpet's developer focused on chunky pixel graphics effects.

PC has established a chunky pixel foundation before the mentioned games' releases.

Quote:

@cdimauro BTW, have you ever opened an Amiga manual? I don't think so. Guess what: they were the Amiga's SDK...

Irrelevant. Again, where's the "game ready" optimized blitter C2P sample code in Commodore's 1993 Amiga SDK?

The main reason for hardware chunky pixels is to make it easier for game programmers to reach the desired graphics effects at acceptable performance.

In 1993, some 3rd party game developers were able to release a Wolf3D-like engine on Amiga
https://youtu.be/8BnYHHVhJJs?t=988
Legends of Valour was released in 1992 for the MS-DOS. The Amiga/Atari ST version requires additional development time and it was released in 1993.

Legends of Valour first began development in May 1991. On the chunky pixels issue, there is less consistency on the Amiga.

Quote:

@cdimauro Thanks for confirming that the hardware guys had still no clue of what was really needed for the C2P, and they created this logic without a DMA (which was available on Akiko), so forcing the CPU to be fully busy on that and DOUBLING the conversion time. Only Amiga engineers made it possible. Ah, and BTW, this was already too late, since we're talking about the CD32. Another proof that the Amiga engineers never understood what was needed for developers and evolved the platform accordingly...

Again, where's the "game ready" optimized blitter C2P sample code in Commodore's 1993 Amiga SDK?

------------
Reminder, IBM VGA chunky pixels are very slow. There's a reason why IBM lost the VGA market.

Last edited by Hammer on 08-Aug-2024 at 06:39 AM.
Last edited by Hammer on 07-Aug-2024 at 09:46 AM.
Last edited by Hammer on 07-Aug-2024 at 09:43 AM.
Last edited by Hammer on 07-Aug-2024 at 08:56 AM.
Last edited by Hammer on 07-Aug-2024 at 08:39 AM.
Last edited by Hammer on 07-Aug-2024 at 08:34 AM.
Last edited by Hammer on 07-Aug-2024 at 08:22 AM.
Last edited by Hammer on 07-Aug-2024 at 07:57 AM.
Last edited by Hammer on 07-Aug-2024 at 07:50 AM.
Last edited by Hammer on 07-Aug-2024 at 07:27 AM.
Last edited by Hammer on 07-Aug-2024 at 07:11 AM.
Last edited by Hammer on 07-Aug-2024 at 07:00 AM.
Last edited by Hammer on 07-Aug-2024 at 06:57 AM.
Last edited by Hammer on 07-Aug-2024 at 06:54 AM.
Last edited by Hammer on 07-Aug-2024 at 06:39 AM.
Last edited by Hammer on 07-Aug-2024 at 06:32 AM.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@tlosm

Quote:

tlosm wrote: @Hammer Quote: You're intellectually dishonest. you are true ... but he was right about one thing: "a-eon hardware is a crappy expensive thing".

Reminder, Mini-ITX Seaberry with 11 PCIe slots for Raspberry Pi CM4 is not cheap.

Mini-ITX Seaberry is asking for $435.

https://www.jeffgeerling.com/blog/2021/mini-itx-seaberry-adds-11-pcie-slots-raspberry-pi

Alftel's Seaberry is a carrier board for the CM4 in the Mini ITX form factor that adds on eleven PCI Express slots:

1 x16 slot (with x1 lane) in the standard ITX location
1 x1 slot on board edge
4 mini PCIe slots
4 M.2 E-key slots (with dual PCIe lines so you can run specialty cards like dual-TPU accelerators)
1 M.2 M-key slot for NVMe SSD

Economies of scale is a bitch.

Last edited by Hammer on 07-Aug-2024 at 09:07 AM.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@Karlos

Quote:

Karlos wrote: This is the audio thread, right? Just checking, you know, for a friend like.

I apologize. I'll write my answer to the bot on the graphics thread, once I've time (now I'm busy writing my next article).


@tlosm

Quote:

tlosm wrote: @Hammer Quote: You're intellectually dishonest. you are true ...

Care to prove it?
Quote:

but he was right about one thing: "a-eon hardware is a crappy expensive thing".

I never stated this. That's YOUR holy war that you started when you were upset with AEON & co. and from the holy warrior "defensor fidei" you became the exact opposite.

Don't project yourself to me: I'm a professional, and I provided my technical analysis on such machines.

Any "What If" wouldn't matter when Commodore has a $116 million debt due to Commodore's large $366 million loss under Mehdi Ali/Bill Sydnes/Jeff Franks administration.

Any would-be armchair administrator must avoid Mehdi Ali/Bill Sydnes/Jeff Franks's large $366 million loss event.

Commodore spent a large inventory stock on Intel 386 (around 1989) and A300/A600 (around Late 1991 to 1992).

Unlike Compaq, Commodore was caught out on large Intel 386 inventory stock when Commodore didn't have Intel's internal road map access to the 486. The "Intel hate" is in "Commodore - The Final Years" book. The constrained room to maneuver was evident around 1989 and rescued by A500's game pack-driven boom sales in 1990-1991.

The Amiga division was carrying the Commodore's PC losses and the release of the higher build price A600/canceled A500 has pulled the rug under the Commodore's profitable revenue stream. Thanks to former Commodore PC's Jeff Frank and ex-IBM PCJr's Bill Sydnes.

Even if you overlay Amiga with 3DO's capabilities, Commodore will still go bust due to logistics and strategic mismanagement.

Commodore was selling A1200 with each unit sale's $50 paying off Mehdi Ali/Bill Sydnes/Jeff Franks' debt. Commodore UK and Commodore Germany were A1200's strongest markets.

Commodore couldn't produce enough A1200 due to incurred debt and the difficulty obtaining 3rd party components. A1200 has a "healthy profit margin" and CD32 has a lower profit margin due to a lower asking price.

There is very little room to maneuver. Better Amiga hardware specification alone is not enough for a company's survival. Commodore was in a debt spiral.

Last edited by Hammer on 08-Aug-2024 at 06:31 AM.
Last edited by Hammer on 08-Aug-2024 at 06:26 AM.
Last edited by Hammer on 08-Aug-2024 at 06:21 AM.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@cdimauro

Quote:

I'm a professional,

for be a professional you have really much free time for write huge posts inside a forum here and there...

PS: i never judge my self , i made other judge me and i smile.

In my town peole say...

"scendi da cavallo ... e spala la merda... quacquero".

_________________
I love Amiga and new hope by AmigaNG
A 500 + ; CDTV; CD32;
PowerMac G5 Quad 8GB,SSD,SSHD,7800gtx,Radeon R5 230 2GB;
MacBook Pro Retina I7 2.3ghz;
#nomorea-eoninmyhome

@tlosm

Quote:

tlosm wrote: @cdimauro Quote: I'm a professional, for be a professional you have really much free time for write huge posts inside a forum here and there...

First of all, I don't write much (in fact I'm busy writing my next article, as I've already written and you have clearly not read).

Second, I'm quite fast at typing. Maybe you're used to be slow. But I'm not.

Third, on which parallel universe a professional should have only a small amount of free time?
Are you (likely) confusing professionals and freelancers?
And have if you intended freelancers, do you expect that they should work 24h/24 compared to employees?
Quote:

PS: i never judge my self , i made other judge me and i smile.

Well, it depends on who are the other ones that judge you: if they a bunch on monkeys, then their remain... the judgement of monkeys...
Quote:

In my town peole say... "scendi da cavallo ... e spala la merda... quacquero".

In mine: "Si nuddu ammiscatu cu nenti".

In fact, there's nothing that you've made that could be considered relevant.

TLDR: don't (auto)glorify yourself.

/OT

BTW, I'm still waiting your PROOF of that:

- You're intellectually dishonest.

* you are true ...

Don't make me older that I'm, waiting you...

Last edited by cdimauro on 09-Aug-2024 at 05:53 AM.
Last edited by cdimauro on 09-Aug-2024 at 05:52 AM.