@OneTimer1

Not sure what you are going at.

If you bough a Kick1.2/1.3 Amiga you got AmigaBasic including on ok manual.

Sure it was far from perfect, but both in games and applications you were set to write stuff that went well beyond any 8bit could do in Basic and to some extend even with HW hitting assembly.

The only issue I see is that breaking out from Basic into "real" languages or Assembler had a steeper learning curve due to both the HW and the OS being far more complicated.

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

Quote:

Kronos wrote: Not sure what you are going at. If you bough a Kick1.2/1.3 Amiga you got AmigaBasic including on ok manual. Sure it was far from perfect, but both in games and applications you were set to write stuff that went well beyond any 8bit could do in Basic ...

It was discontinued soon, I don't think it worked under Kick2.x or with Accelerator.

@OneTimer1

"Soon" is relative.

A500 with 1.3 was still the default entry level config in 91 (and sold well into 92) by which point Amiga had already started going downhill.

Not only that but also the way (home) computers were seen and used had shifted away from coding making it less of an issue.

So when it mattered AmigaBasic was there.

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@Kronos: but it didn't work with 68020+ processors using 32 address lines, because it used the top 8 bits of pointers to store metadata (something which Apple did a few years with its ARM processors, but in a much more controlled manner).

Another great example of very bad coding practice, unfortunately, and that cannot be fixed (better to rewrite it).

@cdimauro

And did that matter to those of us who learned coding with AmigaBasic?

Nope.


It wasn't perfect but it was good enough for the tasks it was designed for.


The whole idea that SW could (or should) be used for decades and every increasing specs hadn't really been established at that time, hence Y2K, 640k is enough for everyone and many many other things.

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@Kronos: well, I've used and enjoyed it a lot as well.

But it remains a piece of crap from a design/implementation perspective: a notable example of things that must NOT be done.

@cdimauro

In our actual situation i would prefer a hundred more bad amiga programmers together with few good ones - AND i would prefer people not to go nuclear as soon as they see something that is not the new turrican or cinemaware - bad programmers can improve most of the time

_________________
Scarabocchi Binari - Italian AROS Blog
Binary Doodles - English language AROS Blog

@cdimauro

Quote:

You can't pretend the quality of AAA productions from indies which are using Unity: they very little (human) resources, and you get what they could.

Isn't what the average base amigan expect from ANY developer in proportion?

_________________
Scarabocchi Binari - Italian AROS Blog
Binary Doodles - English language AROS Blog

@bhabbott

Quote:

The real 'plague' was millions of Amiga fans who didn't appreciate (or care about) the impact of their immoral activities. Ironically this helped sell Amiga hardware - until it didn't. It encouraged the development of games that were sold on hype rather than optimized design. Outrun is the classic example - selling hugely on the name alone. Every game like this damaged the Amiga's reputation a bit, until by the early 90's fans were getting tired of mediocre games and developers were wondering how they could justify continuing to support the Amiga. The parasites were killing the host.

Was not only New Zealand; think at countryside: it was very uncommon around here to see original software - one way in italy was to sell it in newsstands at reduced price, else programs like Outrun were sold for like LIT 39.000, around 20 UKP of the time that was very expensive for teens like me.

And WHY i would contribute to pay for THAT version of Outrun, that is my personal open sore, by the way? If it was good i would have considered to buy it original, but no: i could feel they want to ship it fast to sell with no regards for quality! And Yo ho we went...

_________________
Scarabocchi Binari - Italian AROS Blog
Binary Doodles - English language AROS Blog

Software quality was a problem for the Amiga, especially early software. AmigaOS was far from mature when it was released, many early AmigaOS changes often broke software and documentation trailed development. Software was often rushed to market, early to fill the gap of missing Amiga software and later for a faster return on the time value of money invested and to beat pirates to market. Software can be updated and patched although distribution was more difficult before the internet (we have the internet and WHDLoad today but still a lack of networking capable 68k Amiga hardware). Productivity and AmigaOS software seemed to be better updated than games where it was not unusual to be left in a buggy condition and unusable for certain CPU/hardware/AmigaOS configurations. Amiga software did get better about compatibility and labeling compatibility on the box (CBM likely deserves some credit here). Professional Amiga programmers improved creating impressive software and should be contrasted with the fast to market game "porters". Of course every programmer and software has bugs.

Sometimes programmers went too far to try to save memory which was common in the early Amiga days. Limited memory didn't help and neither did CBM trying to release a 256kiB Amiga. Jay Miner warned them that 256kiB was not enough and adding the memory rather than putting it on the motherboard increased the cost. Chipset enhancements and an earlier 68020 standard could have saved memory. Amiga Corporation wasted time scrunching the AmigaOS with undesirable results that still affect the AmigaOS like non-naturally aligned data in structures. The 68020 was already available when the Amiga was in development so this should not have happened but how does the AmigaOS fit in 256kiB when better options become more and more difficult to find in time. Game programmers sometimes faced similar memory constraints and had limited time to address them. AmigaBasic dirty pointers may have been an attempt to save memory on the 68000. There were certainly mistakes that should have been foreseen while CBM did a poor job of updating some of the software they released including never in some cases despite critical bugs. Some patches eventually became available but the software quality standard CBM set early was not good.

https://aminet.net/package/dev/basic/ABasiC_patch
https://aminet.net/package/dev/misc/PtchAmigaBASIC

CBM not only failed to properly program and update their own software but there are other things they could have done to improve software quality. They could have adopted standard MMU use earlier at least for their high end hardware. They could have adopted a software quality seal with software testing for compliance as well as a content rating system. CBM was very inconsistent and sent mixed messages. The Amiga Corporation team, including AmigaOS developers, was originally fostered, then practically eliminated, followed by chaos and minimal development and eventually CATS became more professional than original Amiga Corporation AmigaOS development and included tech/developer support, AmigaOS development and other Amiga software development. Overall, CBM was far from consistently nurturing and building software development and support on the Amiga. They failed to attract or contract many big software developers and bring important software titles to the Amiga. Smaller developers started to fill the software void left by larger developers, including some high quality software, but the slow Amiga launch and mixed messages from CBM set the Amiga back. Then there was the hardware they failed to properly upgrade too despite having all the tools to bring the Amiga to market and make it a success.

@saimon69

Quote:

saimon69 wrote: @cdimauro In our actual situation i would prefer a hundred more bad amiga programmers together with few good ones - AND i would prefer people not to go nuclear as soon as they see something that is not the new turrican or cinemaware - bad programmers can improve most of the time

Our actual situation is a niche market for a retro-platform, so even "blessing" bad programmers the situation will not change, because of the obsolescence.

One thing where the Amiga OS might fit is the embedded market, but without the burden of the Amiga chipset. Since a while I've joined the Italian embedded community on LinkedIn/Telegram, and I see that sometimes people reinvent the wheel to get some nano-kernel or having a "bootstrap system" better than what Arduino offers. The AmigaOS would a perfect fit for this, IMHO.

Besides that, it's difficult to find other markets for an Amiga / Amiga-inspired platform.

Anyway, and going back to the topic, the article was about the Commodore times and not now.
Quote:

saimon69 wrote: @cdimauro Quote: You can't pretend the quality of AAA productions from indies which are using Unity: they very little (human) resources, and you get what they could. Isn't what the average base amigan expect from ANY developer in proportion?

If I got it right, no: "quality" in this context was related to the assets (3D models, textures, maps and complexity of the world, sound tracks, sfx) of the indie games. So, how complex and visual/audio appealing is a game.


@matthey: a 68020 based Amiga at the time was out of question. The Amiga 1000 was already quite expensive. However, at least properly considering the data structures for this "full" 32-bit processor should have been made.

Regarding the AmigaBASIC, the two patches solve some problems, but unfortunately not the most important one: the 24-bit pointers + 8-bit metadata. This is the major CRAP which Microsoft did with this very nice IDE (because it was a revolution from this point of view: a modern environment for programming).

@matthey

Quote:

matthey wrote: Software can be updated and patched although distribution was more difficult before the internet[/quote Yeah, things were very different back then. The cost of screwing was much higher so you had to get it right - not like today when software is routinely released while still full of bugs. [quote]Productivity and AmigaOS software seemed to be better updated than games where it was not unusual to be left in a buggy condition and unusable for certain CPU/hardware/AmigaOS configurations.

It wasn't a big problem in practice, because 95% of gamers had a stock A500.

Fans complain about how Commodore didn't upgrade the chipset for years, but this was a good thing because it maintained excellent hardware compatibility. Until 1991 I had an A1000 with 2MB FastRAM and a 20MB hard drive, and I don't remember having any compatibility issues. Some of my friends had A2000s with hard drives and accelerator cards - again not a problem because the cards could be turned off.

Things only became sticky for me when I got an A3000, and a few days later thieves stole my A1000 along with all my original software and backup disks. Then I was stuck with the not very compatible 68030 etc. However since I had to buy new software I could avoid titles that didn't work, and I didn't have time to play games anyway because I had to catch up on 6 months of software development (that taught me to keep off-site backups!).

Quote:

Limited memory didn't help and neither did CBM trying to release a 256kiB Amiga. Jay Miner warned them that 256kiB was not enough and adding the memory rather than putting it on the motherboard increased the cost.

The A1000 had 512k of RAM. Problem is 256k of it was in the WCS, which was needed because the OS wasn't finished. If they hadn't needed that then they could have put 512k in the base machine without raising the price. Jay Miner may have 'warned' them, but it was his team's lack of progress in developing a bug-free OS which forced Commodore to do it that way.

Later on the A1000 was routinely bundled with the 256k RAM expansion. The WCS then became a great asset because you could boot different ROMs, including patched ROMs. That's one reason I bought an A1000 rather than an A500. Unfortunately the dealer had run out RAM expansions on the day I bought it, so I experienced the joys of a 256k A1000 for a month. However the dealer did bundle some 256k compatible titles with it. Even with that 'tiny' RAM it was pretty impassive compared to what I had before (Amstrad CPC664 with 64k, introduced in the same year as the A1000).

It was actually possible to use that WCS RAM if you didn't need the OS, but that was a hard thing to do in the early days before developers had built up libraries of bare metal code. For obvious reasons Commodore didn't encourage this practice.

Quote:

Chipset enhancements and an earlier 68020 standard could have saved memory. Amiga Corporation wasted time scrunching the AmigaOS with undesirable results that still affect the AmigaOS like non-naturally aligned data in structures.

The 68020 was very expensive, and not ready when the Amiga was launched. They really had no choice, but the 68000 was fine. 'Non-naturally' aligned data in structures was less of a problem than 'non-naturally' aligned word data on the 8086, which resulted in it performing poorly for a 16-bit CPU.

Quote:

The 68020 was already available when the Amiga was in development

No, it wasn't.

DTACK GROUNDED #34 - August 1984
Quote:

FICTION: Motorola is going to ship 100,000 68020s in 1985. Sure it is. Well, at least Motorola is not claiming that they will be in production in 1984. Thank goodness for small favors, we guess. (EVERY semi house lies in its teeth about future schedules because a company which told the truth would be at a severe competitive disadvantage.) Page 3, Column 1 But we think that Motorola probably WILL ship production 68020s in the second half of 1985. Motorola has announced that the initial price will be $487 each, about $12 less than we had expected. (Initial production is always in small quantities and so the price is selected politically. You DO understand that it does not matter a rat's hindquarters whether Nat Semi got $60 or $600 or $6000 per chip set for the 500 sets it shipped the last nine months, don't you?) $487 is a very moderate initial price for the 68020. We paid almost that much for the first 12.5MHz 68000 we bought. And never regretted it. Now, if we only had a time machine so we could duck into the future about 15 months or so...

Quote:

how does the AmigaOS fit in 256kiB when better options become more and more difficult to find in time.

Amiga OS easily fitted into 256k, there was even some space to spare! This despite large inefficiencies like Tripos having its own multitasking and Intuition duplicating graphics functions. Most of the code was written in C, unlike eg. the IBM PC whose BIOS and DOS was written in assembly language. In later versions of Amiga OS they 'downcoded' some of it into asm to improve speed and save space. Had they done this from the start there would have been tons of spare space in the ROM.


Quote:

Game programmers sometimes faced similar memory constraints and had limited time to address them.

Game programmers are always hitting the limits because they want the most they can get. Still got 20k of memory left? Must jam in some more graphics and sound! A similar problem affected the CPC. The CPC464 had 43k of free memory. The 664 added a disk drive which stole 2k for buffers. Result - many games didn't work. They could have designed those games to work in 41k and nobody would have noticed the difference, but they didn't because...

Quote:

AmigaBasic dirty pointers may have been an attempt to save memory on the 68000.

Amiga BASIC was ported from the Mac version, where the same dirty trick was used because the OS itself did it. Amiga fans who excoriate Commodore for making what they think are bad design decisions should think about that for a bit. The Mac came with a pathetic 128k of RAM with no official way to upgrade it. To minimize fragmentation they developed a screwy memory management system that moved data around behind the application's back, requiring it to access all data through a pointer that could change at any time. As part of this scheme they stored flags in the upper 8 bits of addresses, having absolutely no vision of the future. It also didn't have multitasking, or hardware graphics acceleration, or even color. And it was expensive to produce. Yet despite these bad design points Mac sales kept growing.

Quote:

CBM not only failed to properly program and update their own software but there are other things they could have done to improve software quality. They could have adopted standard MMU use earlier at least for their high end hardware.

Pointless. The PC and Mac didn't have standard MMU use, yet between them they had 90% of the desktop market. Commodore's foray into high-end Amigas was a total disaster, wasting resources that could have been put into growing the low end. By the time they realized that it was too late.

How did this happen? Commodore's engineers suffered from the same myopia as today's Amiga fans - they were focusing on the improvements they wanted, not what the market wanted. Commodore should have known what that was, but they kept trying to go in another direction. The Plus 4 was bundled with several ROM-based applications designed to appeal to the business sector. They were a joke - a complete waste of money - but you had to pay for that crap if you wanted 64k RAM.

Exactly what would 'standard MMU use' do for the end user? Nothing.

Commodore wasn't a software company, and that's fine. But they could have made the OS more complete to make application programming easier. That was what Apple got right with the Mac. Commodore also could have provided more guidance for game developers and not been so afraid to promote 'bare metal' coding. They knew (or should have known) that people would do it anyway, and that amateurs had a lot of talent which could be tapped into. But instead they stayed on their high horse and tried to turn the Amiga into something it would never succeed at - being a high-end workstation and a PC and Mac killer. Even if they had made it do everything fans dream of, it still wouldn't succeed in those markets because they were already sewn up.

Quote:

Overall, CBM was far from consistently nurturing and building software development and support on the Amiga. They failed to attract or contract many big software developers and bring important software titles to the Amiga.

That was never going to happen. In fact some big software developers did bring important titles to the Amiga, but that was pointless because the Amiga wasn't important. Where the Amiga shone was in titles that weren't brought over from other platforms, but developed on the Amiga first - making use of its strengths and the market it attracted.

Quote:

Smaller developers started to fill the software void left by larger developers, including some high quality software, but the slow Amiga launch and mixed messages from CBM set the Amiga back.

You can blame Jay Miner for that - he didn't want Commodore producing a 'games machine' (despite that being the original plan for it). The A1000 was very expensive to produce so the price was too high, but if they had made it much cheaper it would compete against their other products - as well being seriously compromised to get the price down. To make matters worse Jack Tramiel had previously screwed their dealer network so bad that nobody wanted to stock it, while he competed against them with the cheaper Atari ST. Mind you he initially made the same mistake they did, thinking he could get enough sales in the US. The ST didn't make it big until entering Europe - where the Amiga should have been from the start too.

I'm not complaining though. I loved my A1000 and still hope it comes back to me one day. Commodore got the A500, A2000 and A1200 right too. In fact no Amiga model was such a lemon that I wouldn't grab it in a heartbeat if I could (and had enough time to appreciate it). The little flaws and omissions just give us more to enjoy doing to our retro machines.

Right now I am finishing up the development of a 're-assembler' similar to Resource but with a better GUI and more automated operation. I'm coding up to 6 hours a day and loving every minute of it. If the Amiga had been made perfect and every game and app I ever wanted already produced, there would be nothing to do and I would have to move on to something else.

Last edited by bhabbott on 05-Oct-2024 at 08:39 AM.

@bhabbott

Quote:

bhabbott wrote: It wasn't a big problem in practice, because 95% of gamers had a stock A500.

This doesn't justify the lamers that haven't followed the guidelines and shipped crap software which didn't work or had problems with configurations other than that one.
Quote:

Fans complain about how Commodore didn't upgrade the chipset for years, but this was a good thing because it maintained excellent hardware compatibility.

That's simply ridiculous, for three reasons.

First of all, you need upgraded hardware to be more competitive with the other players of the time.

Second, for the same reason you need it to provide BETTER products to your customers. Products = software.

Third, you can maintaining excellent compatibility by... rolling drum... FOLLOWING THE GUIDELES!
Quote:

Until 1991 I had an A1000 with 2MB FastRAM and a 20MB hard drive, and I don't remember having any compatibility issues. Some of my friends had A2000s with hard drives and accelerator cards - again not a problem because the cards could be turned off.

Sure: you need to turn them off because of what? Compatibility reasons, of course!

GENIOUS!
Quote:

Things only became sticky for me when I got an A3000, and a few days later thieves stole my A1000 along with all my original software and backup disks. Then I was stuck with the not very compatible 68030 etc.

I reveal you a secret: it wasn't the 68030 which wasn't "very compatible", but CRAPPY software which was developed...
Quote:

It was actually possible to use that WCS RAM if you didn't need the OS, but that was a hard thing to do in the early days before developers had built up libraries of bare metal code.

That's a non-sense: you need to build your libraries anyway when you go for bare metal coding.

The problem here is NOT the quantity of RAM, rather that you've reinvent the wheel for everything that the OS had already built-in.
Quote:

For obvious reasons Commodore didn't encourage this practice.

Where? Care to point me to the Commodore's documentation which is stating this?
Quote:

Chipset enhancements and an earlier 68020 standard could have saved memory. Amiga Corporation wasted time scrunching the AmigaOS with undesirable results that still affect the AmigaOS like non-naturally aligned data in structures.

The 68020 was very expensive, and not ready when the Amiga was launched. They really had no choice, but the 68000 was fine. 'Non-naturally' aligned data in structures was less of a problem than 'non-naturally' aligned word data on the 8086, which resulted in it performing poorly for a 16-bit CPU. [/quote]
It was a problem on the 8086 TOO...
Quote:

Amiga OS easily fitted into 256k, there was even some space to spare!

Where? Randell Jesup and Mike Seinz talked about this just a few days commenting one of my posts on FB, and they stated that they were working like crazy by trying to save a few bytes to fit the stuff in the ROM.

Mike said that it was needed to move some stuff from ROM to disk because of this.

And we know this very well!

How can you say that there was space in the ROM?!?
Quote:

This despite large inefficiencies like Tripos having its own multitasking and Intuition duplicating graphics functions. Most of the code was written in C

Most was in assembly.
Quote:

, unlike eg. the IBM PC whose BIOS and DOS was written in assembly language. In later versions of Amiga OS they 'downcoded' some of it into asm to improve speed and save space.

And viceversa: they moved more code to C to make it easier to maintain and enhance.
Quote:

Had they done this from the start there would have been tons of spare space in the ROM.

LOL. You don't know of what you talk about!!!

Why don't you go to the post in FB and tell it to Randell and Mike? I prepare the popcorns...
Quote:

Amiga BASIC was ported from the Mac version, where the same dirty trick was used because the OS itself did it. Amiga fans who excoriate Commodore for making what they think are bad design decisions should think about that for a bit.

Why someone has to change opinion depending on the company? If a company makes CRAPPY software, it's CRAPPY anyway, either it was Commodore or Apple.

That's called COHERENCE. Something which fanatics don't know.
Quote:

The Mac came with a pathetic 128k of RAM with no official way to upgrade it. To minimize fragmentation they developed a screwy memory management system that moved data around behind the application's back, requiring it to access all data through a pointer that could change at any time. As part of this scheme they stored flags in the upper 8 bits of addresses, having absolutely no vision of the future.

Exactly. It was super crappy from this PoV. However, there was no 68020 when it was developed.
Quote:

It also didn't have multitasking, or hardware graphics acceleration, or even color. And it was expensive to produce. Yet despite these bad design points Mac sales kept growing.

Probably because of good APIs / SDK which allowed to easily create software. AND the flicker-free, high resolution monitor.
Quote:

Commodore wasn't a software company, and that's fine. But they could have made the OS more complete to make application programming easier. That was what Apple got right with the Mac. Commodore also could have provided more guidance for game developers and not been so afraid to promote 'bare metal' coding.

They provided the necessary documentation for bare metal coding: what else was needed?
Quote:

Right now I am finishing up the development of a 're-assembler' similar to Resource but with a better GUI and more automated operation. I'm coding up to 6 hours a day and loving every minute of it.

Do it in Python and it'll take 1/100 of the time to achieve the same.
Quote:

If the Amiga had been made perfect and every game and app I ever wanted already produced, there would be nothing to do and I would have to move on to something else.

Not the Amiga: if developers would have worked following the guidelines.

@cdimauro

Quote:

cdimauro wrote: high resolution monitor.

512x342 is just slightly more pixels than 640x256 (HighRes PAL) and once you used Overscan you could get more pixels than that or about as much if you start from NTSC.

So no the Mac's 9" screen surely didn't impress

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

How did game developers create/modify graphics for Amiga games? What about audio/music? What would game development have looked like without certain productivity software titles?

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@cdimauro

Quote:

Do it in Python and it'll take 1/100 of the time to achieve the same.

PROVE IT!!!111

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

The big difference between old Amiga and old Mac (aside from price) was that Amiga’s hardware was fairly well openly while Apple kept most hardware documentation internal and only released styleguides and OS APIs. It wasn’t until Apple released mkLinux (1995/96) that some of the chips were finally “revealed�, via source code from Apple (which gave a boost to Linux and *BSD on old 68k macs)

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

cdimauro Quote:

@matthey: a 68020 based Amiga at the time was out of question. The Amiga 1000 was already quite expensive. However, at least properly considering the data structures for this "full" 32-bit processor should have been made.

I wasn't suggesting the Amiga should have been introduced with 68020 but rather that a minimum 68020@14MHz standard could have come much earlier for the high end and earlier for the low end. It wouldn't have been a huge memory savings but I expect a 68020 with chipset changes to reduce memory could have saved 5%-10% of memory. Much of the ROM and AmigaOS are code. Further code density improvements are possible. The memory saving chipset improvements would have been nearly free by ECS release and practically free by AGA release.

cdimauro Quote:

Regarding the AmigaBASIC, the two patches solve some problems, but unfortunately not the most important one: the 24-bit pointers + 8-bit metadata. This is the major CRAP which Microsoft did with this very nice IDE (because it was a revolution from this point of view: a modern environment for programming).

The first patch was for the earlier Metacompco ABasic and is more complete while the latter is for the Microsoft AmigaBasic and minimal. I recall seeing a patched version of AmigaBasic with dirty pointers supposedly fixed but the problem is prevalent throughout and difficult to reliably fix without source code and a recompile. AmigaBasic also had very poor performance so it was best to toss it without a bug fixed version from CBM/M$. There were later options with some level of compatibility like GFA Basic as I recall. There is AQB today includes integrated IDE as "An experiment in alternate history: what AmigaBASIC could have looked like, had it been developed further tailored to the Amiga OS."

https://aminet.net/package/dev/basic/aqb-0.8.2

The source code is available if any later incompatibilities arise.

bhabbott Quote:

The 68020 was very expensive, and not ready when the Amiga was launched. They really had no choice, but the 68000 was fine. 'Non-naturally' aligned data in structures was less of a problem than 'non-naturally' aligned word data on the 8086, which resulted in it performing poorly for a 16-bit CPU.

The 68020 was reasonably priced when introduced considering it was a high performance CPU and significantly higher performance than the 68000 (your own quote verifies this). The 68000 was also high performance and not low priced when introduced.

https://www.lunarmobiscuit.com/the-needle-in-my-1970s-computer-history-haystack/ Quote:

That is half of the needle in this haystack. The other half is also mentioned in the interview, and it was none other than Steve Jobs. Looking at the specs, it is just as clear today as it was then that the 68000 was a big step up from the other chips of the day. But the 6502 had won round one on its $25 price more than performance. The 8086, Z80, and 6800 cost at least $150. The 68000 in 1979 cost more, between $175 and $200. What the interview explains is that Steve Jobs walked into Motorola, and told them Apple would guarantee an order of 1 million chips, if the price per chip were $15. That was less than it cost Motorola to make a chip, but they nonetheless said yes. That price forced Motorola to improve their manufacturing processes in order not to lose money on the order, and the managed to do that.

There was a large demand for the 68020, much of it expected to go into high end workstations. Demand has a tendency to push prices up but it eventually came down even for embedded use like the 68000 which was predictable.

matthey Quote:

The 68020 was already available when the Amiga was in development

bhabbott Quote:

No, it wasn't.

I can verify that the 68020 was not produced until mid-1985 due to severe production problems.

https://archive.computerhistory.org/resources/text/Oral_History/Motorola_68000/102658164.05.01.acc.pdf Quote:

Goldman: I remember the 68020 was introduced. It was a huge success. However, we called it CMOS. It performed well, it did everything we kind of hoped it would do, and you're getting customers coming from everywhere. Then we ran into this little problem of making it. Isn't that the part we had the silicide problem with? Gunther: Absolutely, yes Goldman: Where suddenly we had all this demand and all these customers and so on. We were (inaudible) House: A real problem. Gunther: It was a problem for them. Goldman: But none of them gave up on it. Bill, maybe you can just tell us what happened on that? Walker: Well, I think that started in 1984, with MOS-8 (5 inch factory) trying to get 68K product to yield good die. . I was running MOS-2, an older 4 inch factory, when I received a call in early 1985 from Gary Johnson saying, ‘we would like you to take over MOS-8 and run the factory.’ At the time he called the factory was yielding zero die per wafer. Goldman: Yes, zero is not a good number. Walker: They were really struggling. I told Gary sure I would be happy to run MOS-8. You all remember how good Gary was about communicating with people. He told me to go over and change jobs with Tom Felesi on July 5th. So on July 5th, I walked over and said I am here to replace you. Gary Johnson told me we are switching factories. As I stood at his door and said “I am here to switch with you�, he looked at me and said “screw you, I am not going anywhere!� I called Gary Johnson and he said, “Oh yeah, I forgot to tell Tom�. Tom and I finally worked out the factory switch. I can remember taking my first tour of MOS-8. It had originally been equipped and started up by Al Tash (came out of TI R&D). As I toured I noticed the factory looked more like a lab than a factory. Every tool in the factory was different. The Steppers were an off brand that no one else had ever purchased. Al had built a good R&D facility, but a really poor manufacturing factory. The Engineers were really struggling with lack of back-up equipment, bad equipment and a new process that was yet to be proven and qualified. The new process used silicide based on a Genius silicide machine. The process didn’t work, and most of the time neither did the equipment. We were really struggling in many ways. I remember one of my first biggest challenges was to figure out how to get any yield at all. Up until now one or two die per wafer was the max we could yield. Tom and team were really on us because they needed parts to sample customers. I scheduled a meeting with the CEO of Genius in California. At the meeting he was giving me excuse after excuse, as to why his machine wouldn’t run. I finally slammed my hand on the conference table, at which time my watchband broke and flew across the table and hit him in the chest, and I said ‘no more excuses!’ I looked him straight in the eye and told him “I want this thing fixed now, today!� From that meeting we had the entire Genius team focused on fixing our problems. Bottom line, they fixed their machine, we improved the process and started seeing better yields. Later the Genius CEO sent me a watch in commemoration of that meeting. It was a very interesting time and both Motorola and Genius were better for that meeting. That was the beginning of MOS-8 becoming a factory we essentially re-equipped and in some areas re-built. MOS-8 was probably the factory that produced most of the 68K family of products and did so for a very long time. But, as I look back it got off on a pretty rocky start…that July 5th 1985 morning.

The 68020 was big news with lots of demand. Developers knew it was coming since at least 1984 and likely earlier. It was also predictable that natural memory alignment would provide better performance as should have been known by that time.

bhabbott Quote:

Amiga OS easily fitted into 256k, there was even some space to spare! This despite large inefficiencies like Tripos having its own multitasking and Intuition duplicating graphics functions. Most of the code was written in C, unlike eg. the IBM PC whose BIOS and DOS was written in assembly language. In later versions of Amiga OS they 'downcoded' some of it into asm to improve speed and save space. Had they done this from the start there would have been tons of spare space in the ROM.

C and B compilers were a problem as anyone who has disassembled early AmigaOS versions knows. Some of the artifacts remained for a long time like the intuition.library function stubs until Olaf Barthel fixed them fairly recently, at least in Amiga Neverland time. Actually, 68k Amiga compilers are still less than what they should be and won't improve in Amiga Neverland with emulation where code density doesn't matter anymore as the 68000 compiled version of AmigaOS verifies. There is no need to optimize for emulation as the hardware will go nowhere important.

bhabbott Quote:

Exactly what would 'standard MMU use' do for the end user? Nothing.

I expect more than a few poor developers did not have access to a MMU for software testing and debugging considering CBM didn't even consistently provide a MMU for their supposedly high end hardware. Also, more end users with a MMU would have provided more software testers. Zero page and out of bounds illegal access monitoring are already a big improvement even without more traditional memory protection. CBM could have easily optionally supported protection and monitoring of hunks in a backward compatible way too.

bhabbott Quote:

You can blame Jay Miner for that - he didn't want Commodore producing a 'games machine' (despite that being the original plan for it). The A1000 was very expensive to produce so the price was too high, but if they had made it much cheaper it would compete against their other products - as well being seriously compromised to get the price down. To make matters worse Jack Tramiel had previously screwed their dealer network so bad that nobody wanted to stock it, while he competed against them with the cheaper Atari ST. Mind you he initially made the same mistake they did, thinking he could get enough sales in the US. The ST didn't make it big until entering Europe - where the Amiga should have been from the start too.

From listening to Jay Miner's speeches, I believe he was supportive of a console as long as compatibility was maintained across all models which he was proud of for all existing Amiga models. My understanding is that it was the 1983 video game crash that scared CBM and many other computer game businesses off. Nintendo was practically the only console business left and they had to be creative and innovative to bring the market back.

The Amiga 1000 was expensive to bring to market but not expensive to produce. It was introduced at $1,285 USD in 1985 with a profit. The hardware was high performance for a mid-performance price even though more cost reduction was possible at that time and even for the Amiga 500 and Amiga 1200 due to integration. It was the failure of CBM to integrate and enhance the Amiga technology fast enough that led to their demise. If CBM had a 68k SoC making the Amiga 1200 $100 USD cheaper, there would have been no A300/A600 and the A1200 and CD32 likely would have sold at least twice as many units.

cdimauro Quote:

They provided the necessary documentation for bare metal coding: what else was needed?

It may have been possible to create standard code and an environment to safely shut down the AmigaOS for games. Something kind of like what WHDLoad provides today. Tell programmers to not kick out the AmigaOS unless they absolutely need to but provide a consistent and safer way of doing so.

cdimauro Quote:

Do it in Python and it'll take 1/100 of the time to achieve the same.

And it may use 100 times the memory and have 1/10 the performance which may be important on less than bloated desktop computers.

Last edited by matthey on 05-Oct-2024 at 10:12 PM.

@Kronos

Quote:

Kronos wrote: @cdimauro Quote: cdimauro wrote: high resolution monitor. 512x342 is just slightly more pixels than 640x256 (HighRes PAL) and once you used Overscan you could get more pixels than that or about as much if you start from NTSC. So no the Mac's 9" screen surely didn't impress

The Amiga 1000 was substantially US -> NTSC, so you've to take 640x200 as a reference.

Yes, you can use overscan, but the results depend on your TV.

And AFAIR the Mac's monitor had a higher refresh rate, but I'm not sure about that now (it's too long and I might not recall right).

@kolla

Quote:

kolla wrote: How did game developers create/modify graphics for Amiga games?

Deluxe Paint. Later, even with Personal Paint (it was easy to exchange formats with the "external world" AKA other graphics formats).
Quote:

What about audio/music?

AudioMaster for the samples, ProTracker for the soundtracks.
Quote:

What would game development have looked like without certain productivity software titles?

It's difficult to answer, because it depends on the specific tool and area.

There were some other tools besides the above ones to roughly do the same things, but the productivity wasn't at the same level -> longer development times for games.

On top of that, usually games required private/internal tools, which too time to develop as well.

For example, for Fightin' Spirit the main coder (Dario Merola) had to create a special editor for the characters, that allowed to load all graphics frames from the artist (Giacinto Platania) and divide it in small pieces to create the single mega map containing all pieces for a single character, saving all their related information (metadata like width, height, where it's positioned in the graphics map). The tool also allowed to take some pieces and combine them to generate each single character frames, and taking note as well of this information.
All this was needed to save space, in order to reuse as much common pieces of graphic possible in some frames.
Beside that, there were also tools for assembling all assets and generate the disk image formats, so that it was possible to test the game inserting the floppies.

For USA Racing I did the same: I've created a tool (which I've called A.I.D.S.: Amiga Integrated Development System) to handle all assets. For example, you can select the file containing all tiles used for the graphics then you can select the file with map and then you've an editor for picking up to two tiles (one per each mouse button) and putting them in the map to build it. You can also define the boundaries of the track/road, that were used to detect the collisions with such borders. The tool also allowed to select a sprite to be showing on a specific position of the map (for example, one which indicates that a left turn is coming).
I've also created many other tools to convert the IFF files to raw file for saving the palettes, sprites, bobs, and from the MOD file created by the musician to my special compact format (which I've called it DSP). And another tool to packetize everything and generate the disk image formats, of course.
Since USA Racing had super huge maps (8192x65536 pixels initially. Halved to 4096x65536 after a couple of years of development, to try to reduce the immense work load for the graphic artist for assembly the maps), I've also created a map viewer, which allowed the graphics artist to quickly view & inspect the map, to see how is it going with the work.
Quote:

kolla wrote: @cdimauro Quote: Do it in Python and it'll take 1/100 of the time to achieve the same. PROVE IT!!!111

Easy-peasy: C requires 1/10 of the time of assembly, and Python requires 1/10 of the time of C.

Here is an "Hello World" in Python using the builtin tk library:

from tkinter import *
from tkinter import ttk
root = Tk()
frm = ttk.Frame(root, padding=10)
frm.grid()
ttk.Label(frm, text="Hello World!").grid(column=0, row=0)
ttk.Button(frm, text="Quit", command=root.destroy).grid(column=1, row=0)
root.mainloop()

Last edited by cdimauro on 08-Oct-2024 at 04:17 AM.