Things the Amiga didn't get right from Day 1

[roondar]

Originally Posted by idrougge

The fact that multitasking is claimed proudly on the packaging while the main interface does not multitask internally is also a bit embarrassing for Amiga users.

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.

[TEG]

Originally Posted by idrougge

The ST also has an advantage in its cheap monochrome high resolution screen with a steady 72 Hz refresh rate. Perfect for a sequencer and without any annoying 15 kHz squeal of a (more expensive) 1084.

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.

[drHirudo]

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:

Just in time for the Gateway Computer Show Amiga 2001 Amiga, Inc. and H&P are able to release Boing Bag #1 for OS 3.9. The most important feature is AsyncWB, which adds asynchronous copying and delete functionality to Workbench.

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.

[drHirudo]

Originally Posted by TEG

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 win points.

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.

[Jope]

Originally Posted by drHirudo

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?

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

[idrougge]

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.

[NorthWay]

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

[TEG]

Originally Posted by drHirudo

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.

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.

[Shadowfire]

Originally Posted by NorthWay

For some reason copper blitting has been churning around in my head as of lately and I thought I had a solution. Until I went back to the docs and read them:
"When the BFD bit is a 0, the logic of the Copper WAIT instruction is
modified. The Copper will WAIT until the beam counter comparison is true
_and_ the blitter has finished." (My emphasis)

If they simply had made that into an OR condition then you could have had lots more use of the copper in driving the blitter! (If it could have been a busy->nonbusy change test it would have been even better.)
(Though not perfectly as you could risk doing a blit twice if the copper was reset by top of screen in-between blit start and copper list pointer self-update.)

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.

[Bruce Abbott]

Originally Posted by Thomas Richter

Sorry, i fail to understand this. Where does *it* count? Loading? Why? There was only one disk drive, thus you cannot make it "load faster" by two tasks busy on the drive. This creates just a lot of "disk grunting".

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.

I beileve it counts a lot that you can start another program while another one is still running. The Mac Finder could not do that. You need to quit the running program to return to the Finder. MultiFinder allowed that, but only later on (but in a kludgy way).

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).

[Bruce Abbott]

Originally Posted by drHirudo

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.

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.

Is this one of the reasons the Amiga 500 had Monochrome Composite output?

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?

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.

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.

[AmigaHope]

Originally Posted by Thomas Richter

CBM was, always, a cheap company. Including a joystick would have made the system more expensive. It was rather unclear to them, however, how to sell the machine. The original A1000 package was more that of a business machine. Mouse and keyboard included, joystick not included.

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.

The problem did not appear with OCS. It appeared with ECS where registers were added behind the color registers. But then again, those registers could have been considered private, and it wasn't the application to poke them, but rather the operating system, so anything could have been added later. Actually, AAA was designed to be only ECS compatible, and any extended registers would have been elsewhere.

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.

Different bus. You cannot easily ft a SID into an Amiga system. It would have required additional interface logic, or a redevelopment of SID, none of which CBM had resources for. Actually, the Amiga was not an in-house product for them in first place as CBM accquired the hardware design more or less in last minute, with the hardware already complete. Actually, it is an Atari-type design.

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=.

As said, this would have complicated the design as then Agnus has also to allocate DMA slots for the faster CPU, hence would have required a new Agnus design. However, CBM never "redesigned" much of the system. The development costs for such a system would be much higher than that of the "budget" A500 system which only collected some gates in advanced custom chips, without extending their capabilities.

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.

But the workbench is multithreaded. You mean the "loading part"? Or the "copy part"? Program-wise, this is trivial enough, but it would have meant more ROM space, and that was already tight.

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.

[Jope]

Originally Posted by Bruce Abbott

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.

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.

[NorthWay]

Originally Posted by Shadowfire

there's no decision making ability in the copper to see why the wait was completed and branch

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

You could replace your standard (pseudocode)

CWAIT position

with

CMOVE Return,cop1pt ; tell the blitter stuff where it should go to after it is done
Return:
CWAIT (position|blitfree) ; this now triggers on either being true, not both
CSKIP position ; if we are at the wanted position we don't do blitter stuff
CMOVE blah,COPJMP2 ; go do some blitter stuff

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.)

[chb]

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.

[TEG]

Originally Posted by Bruce Abbott

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?

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.

[sandruzzo]

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.

[NorthWay]

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.

[Spriteer]

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.

[gimbal]

Originally Posted by Spriteer

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.

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.