Given this is literally the first time I've ever heard it being called embarrassing by anyone, never had any non-Amiga user even bring this up when talking to me and never personally felt it at all important for the overall experience, I respectfully disagree.

Oh yes, I agree! From day one the quality of the display that can be connected, was not enough for a professional usage, especially graphical, which was where the A1000 could have won points.

Isn't multithreading something like AsyncWB, which according to this page - http://www.haage-partner.de/amiga/aos39/index-e.html only came with AmigaOS 3.9 BB1 in 2001? Although, I believe there were Aminet hacks that added similar to AsyncWB functionality long before this.

Also quote from this page:
I remember when I installed BB1 on my Amiga 1200 back then. AsynchWB really added noticeable difference to a hard disk installed operating system. I didn't had DOpus 5 at the time, which also added something similar.

Back in 1980-ies and even early 1990 (heck in my country up until late 1990-ies) monochrome displays were considered standard, especially in the business circles and offices. Color displays were considered not good enough for daily business usage, especially for people who were doing Spreadsheets and Word processing all day long. In bookkeeping and press offices, CGA, Monochrome Macs and Ataris were good enough for their job.

Is this one of the reasons the Amiga 500 had Monochrome Composite output? Unlike the Amiga 1000 which had Color Composite display output? Or this is for cost reduction reasons?

There are some Amiga demos and programs, which were done on monochrome displays. I remember in an old scene magazine a guy did some Amiga demo in a submarine on monochrome display and he coded the graphics assuming how they will look on color display, only to see his product later.

For sure it was because of cost reduction. No need to add a chip for PAL or NTSC encoding.

At least on PAL, the composite output of the A1000 was abysmal.

The A1000 also had a built-in RF modulator, which was also removed on the A500. Without a modulator, you don't need the typical composite encoder chip either.

Wasn't there a WB replacement called JazzBench or something like that?

Yeah, the Mac 128K, on the market one year before the A1000, with its B&W display, was very enjoyable to use. But Jobs had paid attention to fonts and to have pixels as round as possible to obtain this result. He set a standard.

Realistically it wouldn't matter, there's no decision making ability in the copper to see why the wait was completed and branch, so you either use the copper to do your screen transitions/sprite multiplexing (by sorting and building up your list in with the processor in the previous frame), OR run the blitter fulltime. Blitter setup with the copper isn't even all that useful unless you're racing the beam with your blits, but there just isn't any need for that as the amiga has more than enough memory to double buffer the display.

Yep, the dreaded disk thrashing. It didn't help that Commodore decided to demonstrate multitasking in the startup-sequence, making it take 3 times longer to boot.

But despite all that, compared to the single tasking systems we were used to the Amiga was pure magic. Even today I wish could I could drag my PC desktop screen down to see another program with different resolution etc. behind it.

Those of us who wanted more added some FastRAM (I had 2MB plugged into the side of my A1000) and increased buffers to make things a bit smoother. I connected a 20MB MFM hard drive and controller to my A1000 via a home made 'bridgeboard' interface, and patched the kickstart to hide a RAD: disk in the upper 512k of FastRAM. This had the boot files copied into it so the hard drive would be mounted automatically on reset. The A1000 would run all day like that so long as I didn't turn the power off.

This is where it counts, and the Amiga did it much better than the competition. If we wanted to multitask while Workbench was busy we would just keep a CLI window open. And of course we used utility programs like Diskmaster for more involved file operations (running in its own screen, not taking up space on the desktop!). Sometimes I will have two copies of Diskmaster running to copy between different directories etc., safe in the knowledge that they can't lock up the desktop like my 'modern' PC does sometimes!

But I still don't do silly things like running two copying sessions at once, because the disk thrashing makes it slower than doing them sequentially (even on a 3GHz PC).

I worked with several businesses in the 80's and early 90s that used CGA or EGA color screens, but most didn't need it and monochrome was much cheaper. And most business applications were text only, so fancy graphics wasn't needed either.

In those days there was a big divide between business and 'home' users, and in New Zealand the markets were completely different. Unfortunately (or perhaps fortunately) Commodore was an American company, so they figured they had to cover both markets - even though the Amiga's chipset was not business oriented.

Not exactly. It had monochrome because building a modulator in would have raised the price and required different models for different regions. Also by this time most people realized that composite didn't do the machine justice. It was usually bundled with an RGB monitor that was much sharper than a TV.

Monochrome output was cheap to add, and had somewhat higher resolution. But I don't think many people used it. PC monochrome screens used a funny resolution that was incompatible, and why would anybody buy an Amiga, with all those fantastic colors, just to run it in monochrome?

Before the Amiga I had an Amstrad CPC664. I bought the monochrome version because their color screens sucked (they had a small TV tube with huge dot pitch). Being used to shades of green, it was quite a shock to see what my stuff looked like in color when I later got a Microvetic RGB monitor.

They could have done this on the A500 and it would have not been too late. The 3-button joysticks could have been purchasable for A1000 users, and the A500 could have set the standard as it was a much more mass-market product. The A500 set the standard insofar as games required at least 512k of RAM, and even set the stage for 1M games given the ubiquity of the A501. Pretty much every A500 sold came with a joystick.
Another example of the tragedy of C= not supporting AAA development when it was needed, and having to pull AGA out of their ass when they were forced to.
Good point, but I still think you could make it work on the bus with some minor tweaks to Gary and a small latch IC. It would have obviously required a couple more discrete ICs on the A1000.
But as I said they could have easily spared the resources to spin a new SID if they hadn't wasted time on stuff that would obviously fail like TED. TED was such a huge step backward for C=.
What I was suggesting required no changes to the DMA slots, just a single chip to induce wait states on the 68000. There were inexpensive accelerator boards that did just this that would have been even cheaper if integrated into the motherboard. Remember that the 68000 benefited greatly from a higher clockspeed given how many cycles many instructions used, even if hobbled by slow RAM access.

C= should have put workbench.library and icon.library on disk from the very beginning and never had them in ROM. =P Make them free for distribution for companies that needed them on a bootable floppy.

Do you mean how 1.3 does run execute s:StartupII?

That's so that StartupII runs in a shell instead of a CLI and can use resident.

The main Startup-Sequence has a wait command that stops it until StartupII is done, then in the end of StartupII a break is signaled back to CLI 1 (where wait is still running) and Startup-Sequence continues.

So it isn't actually actively executing two scripts at the same time.

That was my point - there would be if it was OR instead of AND.

You could replace your standard (pseudocode)

with

There would be a few restrictions like only run the beam synchronization from cop1pt and only blitter from cop2pt, and then you would need to reset cop1pt from the VBI too.
The blitter part would need to advance and update cop2pt after every blit is started so it is possible it would be derailed by the automatic strobe of cop1jmp and hence all blits should be repeatable without side effects (at least cookie-cuts are).
(Oh, and when the the blitter part of cop2pt has run to the end you would preferably switch to a different version of the cop1pt list that doesn't run every available cycle.)

IMHO a nice option would have been an independent COP3LC register for blitter queuing that would not have been reset at VBlank. So like having a list of CMOVEs that are executed when the copper isn't busy with the display copper list, with a CWAIT that just waits for the blitter to be finished, with some kind of end of the list mechanism. Plus making COP3LC readable, so the CPU could read the position in the blitter queue. Coupled with some fastram that would have been quite usefull, esp. for a lot of smaller blits: Just create a list of blitter commands, start it, do some work in fastmem and get an interrupt when finished.

I think in practice that would be more useful than the possibility to sync the blitter to the electron beam, which is a bit alike to Atari VCS game programming and was probably very seldomly used even in games.

Because of money. Color monitors were expensive and I was very happy to have be able to use my monochrome monitor when I switched to the Amiga. I clearly did not had the budget to buy a color monitor. So sometime I used the family TV to play games. But I agree, I was the only one to be stuck in the monochrome world, all of my friends had color monitors. :rolleyes

Even Copper move could be made faster, at least the ones that have to set consecutive registers. Some sort of move next, so you could allmost double coppers' speed, and use less dma cycles.

There should have been some kind of setup/configuration that made interlace and non-interlace be programmed the exact same way. Perhaps you'd need twice as many registers or something - the ideas have not fully formed in my head yet.
The idea would then be to have both a 15KHz and a 31KHz connector and a little logic that could sense if 15KHz was not used. This to convert interlace modes to the equivalent non-interlace 31KHz with a single bit register/sensor.

There might not always have been enough bandwidth to upscale everything, but that should eventually have come.

Good thread. Why I didnt even think about the limited joysticks? Its true that joysticks with more buttons and joypads/controllers would have made a difference.

A500 was ok without HD controller. You could get one anyway if you wanted. Besides if you actually needed it you could buy an A2000.

Never had big problems with floppy disks. I still use some decades old floppies.

Theoretically yes, but you have to keep in mind that people shopping for an A500 did so probably because they were looking for something that fit within a budget.