#ESCOM – UUGH!!!
27 messages in this thread
I thought we were comparing an 1989/90 pc and macintosh. You can't fit a
pentium to a 1989 pc, I must admit my hardware knowledge of macs is pretty
limited so I can't comment on that.
Amiga hardware often costs more than the equivalent pc or mac. The only real
cost advantage the amiga ever had was that you could actually USE a machine
with 512k and run more than one piece of software at once. Something the pc and
mac will never be able to do.
Phill
To refocus the thread, let me remind you that Ian's original post said simply
that a 1990 Mac or PC isn't usable today.
You can purchase a Pentium motherboard for about half the cost of Warp Engine
or similar accelerator for the Amiga.
On the Mac side, you can purchase a PPC601 upgrade for most Macintoshes for
about $1,550 – roughly the same price as a Warp Engine or similar accelerator
for the Amiga.
In regard to the merits of the Operating Systems, no argument: the Amiga has
always had superior multitasking when compared to the Macintosh's primitive
co-operative multitasking or Window's slightly less primitive schema.
However, the rest of the world has seen the light and Win95 offers usable
multitasking, WinNT offers excellent multitasking and the next version of
Apple's OS is supposed to include pre-emptive multitasking.
The key point, though, is that Ian's claim that a PC or Mac produced in 1990
is unusable is simply not true.
Jerry
I think the real point was that the 1990 pc or mac wouldn't run todays
software, this for a pc is true, I know people with 8086 and 80286 and they
can't run win95. I can multitask on a 68000 (which although it is a crime to do
so can be compared to a 286).
Bying a pentium motherboard is the same as buying a new computer, all you have
is the power supply and the case. You would probably have to buy new simms as
your 1990 pc probably used 1mb simms or soldered/dips etc. Your new motherboard
would also need a new monitor as your 1990 pc could well have had ega, or maybe
vga. But who would use a pentium with a decent video chip but only a vga
monitor? Then of course as you are now going to install windows 95 or windows
nt you will need much larger and faster hard disk storage.
Build 490 of windows 95 is just about useable on a 486-66 with 16mb of memory.
On a pentium its pretty nippy. On a 386 it is a dog ( I was using it earlier
today on a 386 ).
The pc's architecture is bodged, if intel had thought about the future instead
of money it would have been a much nicer processor. As it is, each time they
produced a major advance you needed to learn another processor. 8086, 80286 and
80386 are all programmed differently, if they had implemented a flat memory
model in the first place ( like motorola did ) then windows 95 would run on an
8086, it would be slow, but it WOULD run.
I know how pc's work as I have to do a bit of low level assembly programming,
personally I would never buy a pc, I don't need what it offers. The amiga does
what I need to do. If commodore had a clue about marketing then maybe everyone
would be using amiga clones now.
Phill
Phillip,
PMFJI, but I have to disagree in some points.
>> … the 1990 pc or mac wouldn't run todays software, this for a pc is
>> true …
This is true for the Amiga, too. I can't run today's AGA software on my stock
A2000, and it isn't upgradable, either.
>> As it is, each time they (Intel) produced a major advance you needed to
>> learn another processor. 8086, 80286 and 80386 are all programmed
>> differently
It's the same thing or even worse with the motorola processors 68000,
68020+68851+68881, 68030+68882, and 68040. So what's the point ?
>> if they had implemented a flat memory model in the first place ( like
>> motorola did ) then windows 95 would run on an 8086
Well, the 8086 ist a very old processor, and it _had_ a flat memory model, that
was 64 K in size. In that time, most other processors were 8 bit only, and you
had to swap 64 K banks around using the hardware and interrupts.
Remember the C= 64/128, C= PET/4032/4064, C= 610/710 ? So the 6086 was an
improvement, because you could switch segments by software.
Sure, Intel could have made a new processor not downwards compatible to the
8086. But the marketplace didn't want that, because all the software that
already existed, like accounting packages, payroll, etc. would have to be
rewritten. Much less users would have upgraded if they had to install and let
all their employees learn to handle new software.
So the hardware and software upgrades were decoupled and divided into different
subjects. The effect was, that each subject has dynamically stimulated the
other.
– wkc – … via AP from Hamburg, Germany
It's not even worse with the 68k series, if you believe that then you really
don't understand programming the 80×86 and the 68k.
You can write serious applications that quickly access up to 4gig of memory and
the code will work on 68000 through to 68060. The only real compatibility
problems come with fpu's and mmu's. You either have to compile for each fpu to
get maximum speed or you resort to the libraries. Most software doesn't have to
program the mmu anyway.
On the 80×86, you would have to support ems for 8086, xms for 286 (which both
still only give you 16mb maximum). Then the code for the 386, 486 and pentium.
Software for the amiga that requires 020's for no reason is lame, but it does
happen.
And you can run some AGA software on your a2000, just buy a graphics board for
it. And while you are at it why not add a 68060 board to it as well? But you
don't have to as long as you don't mind a slow machine. A 286 pc just won't run
windows 95, fast or slow.
You try and get an 8086 running windows connected to the internet ( something
that I am going to attempt ), then compare to how easy it is to get an a500
attached ( something I have already done ).
Phill
>>Software for the amiga that requires 020's for no reason is lame, but it does
happen. The 68020 has a considerably more advanced instruction set. Programs
that operate with bitfields really need a 68020. Personally I think that there
should be a version of Workbench/ROM compiled for the 68020. Some of my
assembly programs require the 020, for long division, and bitfields. It is so
much easier to use these instructions than doing it the long way.
People with the 68000 should really try to upgrade, so more people can make
their code optimized for the 68020.
What is lame is when people make a "68030 version" of their program. What
people running C compilers don't know is that there is no instruction set
difference between a 68020 and 030, and usually no reason for compiling a 030
verison at all.
If you put the time in you could have a version of your code that can work on
68000 or 020. All you need to do is check and modify your code at runtime.
Some people can't upgrade to 020, I do have an a1200, but it needs more memory,
more disk space and a new monitor (my current monitor doesn't work on it).
I have a 28mhz 68000 in my a500, this should be able to keep up with a 14mhz
020. Bitfield operations can be done with tables, long division can be a pain
though. Exactly what programs do you write?
Phill
>>Exactly what programs do you write? AddPower, AutoStart, Colors, AmigaStart,
IconPlus. All available on Compuserve and GEnie, and most of my stuff is on
Fred Fish. I have a few other miscellaneous things floating around too.
>>If you put the time in you could have a version of your code that can work on
68000 or 020. All you need to do is check and modify your code at runtime. I
know, but my point is "time". I've had a 68030 for 5 years, and I only have
68030's and 020's to test software with. So very few of my registered users
have a 68000 that it is nearly pointless not to use the 020's instruction set.
I'm not saying anyone with a 68000 should junk it, nor that I'm incapable of
programming a 68000, but just as people who relentlessly hang on to WB1.3 will
be left in the cold, so will people without hard drives, people with stock
68000's, people with 2400 baud modems…
That I'm aware, most of my programs work fine on a 68000 except Colors (avail
on FF939) which requires a 68020. However, when I released this program, which
is a color requester requiring 3.0 that is primarily intended for AGA users
(and now gfx cards), all people with 3.0 had a 68020. This is why I think 3.0
should have been compiled for '020, all 1200's and 4000's had it, so why not
use it?
>>I have a 28mhz 68000 in my a500, this should be able to keep up with a 14mhz
020. I would have died and went to heaven if I had a 28 MHz 000 in my 500…
Whether it "keeps up" only a benchmark would show, but your 68000 is probably a
little slower. This is because the 68000 is a 16 bit processor at heart (even
though it had a 24 bit addressing space and 32 bit registers). The 68020 is
true 32 bit, and conducts all operations with 32 bit reads and writes, and
internal operations as well. So a 14 MHz 020 is equal in speed to a 28 MHz
68000. The advantages of the 020 are an instruction cache, additional
addressing modes, and fast bitfield instructions, quick long integer divion and
multiplication. If you turn off your cache and run a program not optimized for
the 020, there will be no speed difference between that 500 and the 1200.
The primary thing used in colors that is 020 specific are scaled index
registers. I REALLY want to use these addressing modes all the time, but can't
if I want to be 68000 compatible. I have so little time to program, I need to
do things as quickly as I can. If it slows me down to make 000 programs,
sometime I eventually need to say, no. There will most likely never be another
68000 Amiga manufactured again, ever. No new 68000 users will ever come into
existence. The number of 68000 users will only decline.
It's hard enough for some people to justify supporting the Amiga at all. There
certainly ain't too much money to be seen doing so. Why should I support the
68000? If you can make a good case, maybe I will continue to support it, but I
haven't even seen or touched a computer, Amiga or Mac, with a 68000 since 1990!
the 68ec020 is not 32bit…not a true 32bit cpu
does not supprt all 32bit feautres required for zorro 3 bus
Yes, but the 68ec020 is a cheap-o stripped down 68020. It does not count, in
terms of describing the CPU family. I can safely say a 68030 has an MMU, even
though the 68ec030 doesn't, simply because a 68ec030 is an 030 with the MMU
disabled. It is sort of lame that people even use these "economy" versions,
because then software written for the 68030, say, might not even work on an
EC030, and the user is confused. The savings associated with ripping out part
of the CPU just aren't too cool compared to the performance and ability loss on
a CPU that is already not exactly "top of the line".
That was one of the things that really annoyes me, when os3 came out and there
were all these nice datatypes, and they all needed 020+.
The thing is that KS3.0 would run on an any amiga, there were rumours that it
wouldn't and that it was bugged. Most of the bugs with KS3.0 are to do with
pcmcia etc (which of course the a500 didn't have). When I was running KS3.0 in
about 1993 I think it was, these datatypes got on my nerves. In fact I still
haven't got one installed that works properly ( the only one that I have found
to work only does so when the file extension is jfif and not jpg, don't really
know how to kludge it yet ).
I never learnt anything other than 68000, so I don't know of the advantages.
Phill
what?
then one of your files is messed up
all of my datatypes work
ALL Of them
i have ping,targa,pcx,bmp,macpaint,jfif,gif,binary,c,font,postscript,wav,voc,
aiff,ico,info, in addition to the origin la os 3.0 ones
You didn't mention jpg, the jfif I have that works on 68k doesn't recognise
jpg's. It is the tower jfif that I downloaded from CIS. I guess I may have
installed it incorrectly ( I used the included script) and it might have been
updated since.
Phill
Sorry Lepido,
most of the datatypes you mention do not work right. While writing datatypes
support for my program, I checked serveral datatypes. Most of the turned out to
be seriously buggy. Others are working fine. But because of limitations in the
datatypes standard, running datatypes on some files are rather frustating. The
quality is VERY low. For instance, you can't read 24 bit with datatypes. Using
the routines Commodore shows in it examples, you can't read HAM8 on ECS
machines as the datatype library automaticly converts to image to something
your machine can understand. On an ECS Amiga this means HAM mode. Some programs
directly access the datatype buffer in order to avoid this problem. But I have
no idea how legal this is. There are several reasons why this can't be legal.
However, it's currently the only way to get good results (ever used MultiView
to show a 24 Bit image on an ECS machine? Yuk!).
Regarding your list:
PNG: Very well done. So far, I couldn't find any bug and the datatype performs
well with interlaced files.
PCX: the versions I did test very seriously buggy and a crash is very likely as
the software overwrites memory.
MacPaint: I only heard bad things about this datatype…
GIF: I never tried ZGif yet, but the other more widely spreaded GIF datatype
doesn't work right on interlaced GIFs. Colors are wrong.
PostScipt? Sorry, this datatype is far from PostScript. You can call it an EPS
datatype (with one eye closed).
JFIF? See comments above regarding 24 bit…
BMP: I haven't tested this one yet. But reading the documentation, this rather
sounds limited.
Don't get me wrong, the general idea of datatypes is great. However, the
current system lacks quality.
>what? then one of your files is messed up all of my datatypes work ALL Of them
i have ping,targa,pcx,bmp,macpaint,jfif,gif,binary,c,font,postscript,wav,voc,
aiff,ico,info, in addition to the origin la os 3.0 ones<
No messed up files at all. You have a 1200 and that means 68020. Phillip has a
500, and that means 68000.
Rafa <Motorola Inside> from Berlin, thanks to AP1.80
>…olive oil is the way to go.<
Phillip,
>> You can write serious applications that quickly access up to 4gig of
>> memory and the code will work on 68000 through to 68060
>> On the 80×86, you would have to support ems for 8086, xms for 286
>> (which both still only give you 16mb maximum). Then the code for the
>> 386, 486 and pentium.
I totally agree with your explanations concerning the diffent memory adressing
schemes between the 80×86 an 68k. It's a pita writing code that will run
automatically optimated for all 80×86 based machines.
For my current projects, I decided to drop the support for 8086 and 80286.
But my statement had in no way to do with the abilities of the CPUs, or which
one would be better, or which Assembly commands would be used by specific
programs, or how difficult it is to update existing software.
I only stated, that, after looking into the manuals, the amount of changes of
and additions to the commands is roughly the same for upgrades of the 80×86 and
the 680×0 families, resulting in an equal learning curve.
– wkc – … via AP from Hamburg, Germany
80×86 is more complicated as an 80386 can run as a 386/286 and 8086. Addressing
changes in each so an program written for an 8086 has to be run in 8086 mode
etc.
68060 runs in one mode, 68000/020/030 & 040. The only problem is with mmu's as
they aren't compatible. There is no reason why you have to write software that
will only run on an 020, there are some instructions on the 020 and up that can
sometimes give you speed benefits. But you can just write 68000 code if you
want to.
Phill
I think you can use AGA software on a non AGA machine. You do this by buying an
OS 3.1 upgrade. AGA is then simulated. I remember when I received my developers
kit several years ago that they provided software to simulate AGA.
Richard,
<I think you can use AGA software on a non AGA machine. You do this by buying
an OS 3.1 upgrade. AGA is then simulated. I remember when I received my
developers kit several years ago that they provided software to simulate AGA.>
They may have intended that to go into 3.1 but if it's there, I haven't seen
any indication of it. I'm running 3.1 on my A2000/040 with both an Opal and a
Picasso board. So if there were a way to simulate AGA, I should have been able
to do it, and I can't. Nothing that was written, specifically for AGA (games,
DPaint AGA, Brilliance) runs in AGA modes on my machine.
Asha
@}–`–,-
Richard,
>> I think you can use AGA software on a non AGA machine. You do this by
>> buying an OS 3.1 upgrade
thanks for the info. I just can't try it, because my A2000 is OS 2.1 only. My
A4000 got OS 3.1, but as it has AGA as well, I can't verify it either.
>> I remember when I received my developers kit several years ago that they
>> provided software to simulate AGA.
I just browsed through the files of my Update_3.1 Native Developer's Kit, but
can't locate such a peace of software. Can't locate it on the disks that came
with the DevCon 93 Notes either. Could you be a little bit more specific where
I can find it ?
– wkc – … via AP from Hamburg, Germany
>>It's the same thing or even worse with the motorola processors 68000,
68020+68851+68881, 68030+68882, and 68040. So what's the point ?
No way, are you going just by names? There a a few differences between the
chips. And they were design to be downward compatible. The 68010->68040 were
extremely similar for programming. The biggest difference was the jump from
68000 to 68010 were virtual memory was added (allowing 4 gig, 68000 can only go
to 16Meg).
The 68020 can run a 68882 & the 68030 can be coupled with a 68881. And I do
not know any program that would run in a 68881 and not in a 68882. The 68882
is just a better math coprocessor. The 68851 was (sorta) incorporated in the
68030. The chips are downward compatible. The only time you get in trouble is
when you have BAD programming practices.
In contrast I have programmed assembly in 8088 🙁
And is the worst nightmare you can imaging and it was very different with the
80286 on. You trullu have to learn different stuff. Nothing like any other
processor I had to programmed.
The main reason the PC was stuck in 8086 mode was entirely Intels screw-up. Is
more MicroS**t screwup with DOS than Intel's. DOS is the problem and Intel
made patches around the 80286 and 80386 to attempt to enhance it. In the 80386
and beyond they did great stuff to go around MS-Junk's (and all programs that
ran on it), and 80386 is very different than 8088 (or 8086, 80186 or 82086).
Apple had similar problems way back around 1986 with the OS supporting only 4
Megs (although the M68000 could address 16 Meg) but they bit the bullet and
fixed the problem for good in the next release of the OS.
Eduard Joseph
Eduard,
>> 80386 is very different than 8088 (or 8086,80186 or 82086).
well, I see no significantly bigger differences between the 80386 and 8088 (or
8086, 80186, or 80286) than between the 68030 and 68000 (or 68000, 68010, or
68020).
Of course, the 80386 was a progress over the 80286, not only as it introduced
32-bit registers, but as you could switch back from protected mode to real
mode. And you may redefine the segment size.
>> DOS is the problem […]
I absolutely agree.
But, there are OSes like OS2 and Windows NT available for quite awhile now,
that dont't have the problems of DOS (beeing non-reentrant, requests real
mode).
So why do you think the user base and developers did not simply switch to that
OSes but continue to write DOS applications ?
– wkc – … via AP from Hamburg, Germany
>>It's the same thing or even worse with the motorola processors 68000,
68020+68851+68881, 68030+68882, and 68040. So what's the point ?
As an assembly programmer with many years experience with the 80×86 and 680×0
series of processors, I have to disagree here. The differences in programing
between the 286 and 386, and the 386 and 486 etc. are fairly large. If you
want to really take advantage of the processor you must program special code
optimized for the processor. It is necessary to really learn the ins and outs
of each new processor that comes out.
The 68020 added a few new instructions, none of which you really need in order
to run a program faster. They just make the programmer's life easier. The
68040 added changed a few FPU instructions, but the FPU is something you rarely
need to worry about programming (and easy to program anyway). The MMU did
indeed change every time from the 851 to the 030 to the 040, but very rarely is
it necessary to program the MMU. Only one out of a hundred programs you have
touches it. Only virtual memory and the system at boot time use it.
It is way easier to learn the 680×0 series of assembly language, and I have
never found anyone who prefers programming assembly on an Intel to a Motorola.
Regular 68000 code works quite efficiently on a 68040, but if you write your
program for the 8086, it will be very inefficient compared to the same program
coded directly for the 486 (assuming its a somewhat complex program).
Ian,
>> I have never found anyone who prefers programming assembly on an Intel
>> to a Motorola.
I totally agree. Not only you have to deal with a crappy adressing scheme, but
you have to fiddle around with registers that lack the universality of the ones
in a Motorola chip.
>> but if you write your program for the 8086, it will be very inefficient
>> compared to the same program coded directly for the 486
Hmm.. could you be a little more concrete ?
I'm right now on a project of porting one of my special Amiga applications to
the PC (on request from and payed by the customer).
Because the source application is 80 % asm, and uses a special GUI the user is
accustomed to, it's a very extensive task.
– wkc – … via AP from Hamburg, Germany
>> but if you write your program for the 8086, it will be very inefficient
>> compared to the same program coded directly for the 486
Hmm.. could you be a little more concrete ?
.. Well, the 486 has registers that make copying to/from memory blocks and
stuff a lot easier, rather than just increasing the speed of their processor,
which was originally 8 bit, in order to get up to 32 bit modes Intel had to
make new instructions to fully take advantage of 32 bits. The 68000 can add
and subtract 32 bit words. and the 68020 can multiply and divide 32 and even
64 bit quantities. The 8086 operates on 8 bits. So if you want to do 32 bit
operations, you are using 286, 386, or 486 specific instructions – your code
will not work on a 8088/8086. If you were to program right out of the 8086
hardware ref manual, your program would be inefficient compared to using 386
instructions.
Phillip W may be overstating his case, but he has a point.
Three 16-bit chips came out in roughly the same time frame: The Intel 8086,
the Zilog Z80, and the Motorola 68000. Of the three, the Motorola chip had by
far the best framework for future expansion: 68000 programs had the capability
of using 24-bit addresses directly. The 8086, with its 64K instruction reach,
was clearly the most crippled for the future: its instruction set was already
overloaded. All three chips had architectures based on earlier 8-bit products.
Intel had the clumsiest 8-bit product; heck, it had its origins in a 4-bit
chip, and the history had gone 4004, 8008, to 8080.
The 68000 was expanded to the '20, '30, '40 and '60 in a number of ways, but
the improvements were largely in the area of new instructions and more
addressing modes. The 8086, in contrast, was in a "64K blocked" mode, and
major surgery had to be performed to unblock it. "Protected mode" is a clever
idea, but it was also a radical change, and the MS-DOS operating system
couldn't handle it. Even today, MS-DOS requires protected mode to be disabled
when it takes over an operation. I've run across no such anomaly in the 680×0.
From the 80386, newer intel chips have smooth upward compatibility; but the
road from the 8086 to the 386 was a bumpy one indeed. The 68000 to 68060 path,
in contrast, shows no comparable signs of retrofit.
Intel had the most popular chip for small computer systems: a large part of
that world ran on CP/M. When PC-DOS/MS-DOS came into place, it was a recut of
CP/M, and couldn't shake loose from the intel chip line. It wasn't because the
chip set was superior.
Many people on this board would agree that technical superiority does not
always assure leadership in the marketplace.
–Jim
Jim,
thanks for you statements.
>> Many people on this board would agree that technical superiority does
>> not always assure leadership in the marketplace.
<SIGH!> How true.
I'm just working on a port of a program from Amiga to MS-DOS, because the
customer wants to get rid of his amigas and will buy clones (from me, of course
🙂 ). He has become irritated when he heard that C='s ship sunk.
So poeple even will spend lots of money to loose technical superiority !
– wkc – … via AP from Hamburg, Germany