22 Apr
2016
22 Apr
'16
11:03 a.m.
Remember all the accelerator boards for the Mac, Amiga, and even PCs in the
90's ? I've often wished that I could get something similar on my older SGI
systems. For example, fitting an R16k into an O2 or doing dynamic
translation on a 4.0Ghz i7.
I'm most familiar with the Amiga accelerators. I suspect those who
produced them were helped out greatly by a couple of factors. One is that
the hardware specs were very well known and full schematics were available
for most (all?) Amigas. I doubt the same is true of SGI machines. The
other is that many Amigas had processor "slots" (with edge connectors)
rather than some tiny fiddly ball-grid array etc... but I'm not a EE; so
maybe that's bunk.
When I look at these boards they seem like they'd be a LOT of work to
develop and produce. I wonder how they were even economical to make back in
the day. Plus, now the user base will probably only shrink. It's not a
great business model for a hard-to-produce item. It doesn't keep my
techno-lust from wanting it, though.
So, here's the question. Is my dream likely to ever be possible enough that
a boutique shop could pull it off and not lose their shirt on the production
costs and R&D to do it ? I'm encouraged by things floppy emulators that are
produced for these old machines. However, that's probably significantly
easier to make than a CPU accel board.
What do you guys think?
-Swift
22 Apr
22 Apr
11:25 a.m.
On Apr 22, 2016, at 11:03 AM, Swift Griggs
<swiftgriggs at gmail.com> wrote:
Remember all the accelerator boards for the Mac, Amiga, and even PCs in the
90's ? I've often wished that I could get something similar on my older SGI
systems. For example, fitting an R16k into an O2 or doing dynamic
translation on a 4.0Ghz i7.
The main reason for a lot of the ?accelerator? boards was to be able to run
non-native code on the same platform. With the advent of performance
micros (latest x86 and Power) there is little need to do that because emulation
(or dynamic translation) is fast enough and with the various virtualization
capabilities, it?s not unusual to have multiple different OS?s running on the
same HW.
Apple did this with some success in it?s various CPU transitions. When they
switched from 68K to PPC, the PPC emulated the 68K code. The same
happened when they switched from PPC to x86, again the PPC code was
emulated (actually in that case it was dynamically translated).
So, here's the question. Is my dream likely to ever be possible enough that
a boutique shop could pull it off and not lose their shirt on the production
costs and R&D to do it ? I'm encouraged by things floppy emulators that are
produced for these old machines. However, that's probably significantly
easier to make than a CPU accel board.
It?s also keeping in character with the old machines. It?s not adding new
capabilities but more replacing old peripherals with something a bit more
convenient. Adding in a new accelerator means not only developing the
HW but also writing a boatload of *new* SW in order to be able to take
advantage of it.
Most of what you see (and what I?m mainly doing these days in terms of
?hobby?) is producing parts to a system in order to keep it running rather
than adding completely new capabilities. Most companies would rather
spend their time and budget doing things for a high ROI and for large and
growing markets.
TTFN - Guy
11:51 a.m.
On Fri, Apr 22, 2016 at 1:25 PM, Guy Sotomayor <ggs at shiresoft.com> wrote:
I've heard about PPC Amigas from time to time. What was the state of
68K->PPC emulation or dynamic translation on those?
I like the new types of peripherals but it makes me a little uncomfortable
knowing that e.g. in the case of the uIEC-SD for Commodores, the clock
speed of the peripheral is 16 to 20 times that of the original host CPU. I
keep hatching little schemes of perhaps putting a tiny OS kernel in the
thing, but at that point *it* would become the computer and the 128 would
be just sort of sitting there. The same is true of the CosmosEx device I've
been thinking of getting for my Atari STs; it has a Raspberry Pi inside.
--
Eric Christopherson
On Apr 22, 2016, at 11:03 AM, Swift Griggs
<swiftgriggs at gmail.com>
wrote:
Remember all the accelerator boards for the Mac, Amiga, and even PCs in
the
90's ? I've often wished that I could
get something similar on my older
SGI
systems. For example, fitting an R16k into an O2
or doing dynamic
translation on a 4.0Ghz i7.
The main reason for a lot of the ?accelerator? boards was to be able to run
non-native code on the same platform. With the advent of performance
micros (latest x86 and Power) there is little need to do that because
emulation
(or dynamic translation) is fast enough and with the various virtualization
capabilities, it?s not unusual to have multiple different OS?s running on
the
same HW.
Apple did this with some success in it?s various CPU transitions. When
they
switched from 68K to PPC, the PPC emulated the 68K code. The same
happened when they switched from PPC to x86, again the PPC code was
emulated (actually in that case it was dynamically translated).
So, here's the question. Is my dream likely to ever be possible enough
that
a boutique shop could pull it off and not lose
their shirt on the
production
costs and R&D to do it ? I'm encouraged
by things floppy emulators that
are
produced for these old machines. However,
that's probably significantly
easier to make than a CPU accel board.
It?s also keeping in character with the old machines. It?s not adding new
capabilities but more replacing old peripherals with something a bit more
convenient. Adding in a new accelerator means not only developing the
HW but also writing a boatload of *new* SW in order to be able to take
advantage of it.
Most of what you see (and what I?m mainly doing these days in terms of
?hobby?) is producing parts to a system in order to keep it running rather
than adding completely new capabilities. Most companies would rather
spend their time and budget doing things for a high ROI and for large and
growing markets.
1:28 p.m.
On Fri, 22 Apr 2016, Eric Christopherson wrote:
I like the new types of peripherals but it makes me a
little uncomfortable
knowing that e.g. in the case of the uIEC-SD for Commodores, the clock
speed of the peripheral is 16 to 20 times that of the original host CPU. I
keep hatching little schemes of perhaps putting a tiny OS kernel in the
thing, but at that point *it* would become the computer and the 128 would
be just sort of sitting there. The same is true of the CosmosEx device I've
been thinking of getting for my Atari STs; it has a Raspberry Pi inside.
I heard at the time, that the Apple Laserwriter was the "most powerful"
machine that they made, and that certain people were connecting terminals
to it and programming in Postscript. I did some trivial programming in
Postscript, but didn't have a Laserwriter. It was a stack based language,
with similarities to Forth. I suspect that the "terminals" were actually
terminal emulation in whichever machines were currently connected anyway.
I made a company logo that was outline letters with a fill of lines
radiating from a point (think about Moire pattern artifacts when pushing
the resolution limits). Then I found that the "Freedom Of Press"
Postscript emulation of the commercial large format printer was too slow,
and did not have a large enough stack space. (whilst other deadlines were
looming).
1:47 p.m.
New subject: Apple LaserWriter - was Re: Accelerator boards - no future? Bad business?
On 2016-04-22 4:28 PM, Fred Cisin wrote:
On Fri, 22 Apr 2016, Eric Christopherson wrote:
Yes, it had RS232 serial (and AppleTalk), like all the early PostScript
devices.
It wasn't _that_ fast, though: 12 MHz 68K running an interpreted
language (with no doubt native code for the graphics implementation;
perhaps that's where its reputation for speed came from, but only useful
for its actual purpose, printing :).
I suppose one could say that it was a little faster hardware-wise than
the Macs of 1985, but they were usually running native code, so the
comparison isn't very useful imho.
--Toby
I like the new types of peripherals but it makes
me a little
uncomfortable
knowing that e.g. in the case of the uIEC-SD for Commodores, the clock
speed of the peripheral is 16 to 20 times that of the original host
CPU. I
keep hatching little schemes of perhaps putting a tiny OS kernel in the
thing, but at that point *it* would become the computer and the 128 would
be just sort of sitting there. The same is true of the CosmosEx device
I've
been thinking of getting for my Atari STs; it has a Raspberry Pi inside.
I heard at the time, that the Apple Laserwriter was the "most powerful"
machine that they made, and that certain people were connecting
terminals to it and programming in Postscript. I did some trivial
programming in Postscript, but didn't have a Laserwriter. It was a
stack based language, with similarities to Forth. I suspect that the
"terminals" were actually terminal emulation in whichever machines were
currently connected anyway.
I made a company logo that was outline letters with a fill of lines
radiating from a point (think about Moire pattern artifacts when pushing
the resolution limits). Then I found that the "Freedom Of Press"
Postscript emulation of the commercial large format printer was too
slow, and did not have a large enough stack space. (whilst other
deadlines were looming).
2:24 p.m.
New subject: Apple LaserWriter - was Re: Accelerator boards - no future? Bad business?
On Fri, 22 Apr 2016, Toby Thain wrote:
Yes, it had RS232 serial (and AppleTalk), like all the
early PostScript
devices.
It wasn't _that_ fast, though: 12 MHz 68K running an interpreted language
it would certainly not be fast by any recent standards, and I had always
assumed that the speed differential was pretty minor.
1:31 p.m.
On Fri, 22 Apr 2016, Eric Christopherson wrote:
I've heard about PPC Amigas from time to time.
What was the state of
68K->PPC emulation or dynamic translation on those?
From my perspective it's complicated and
sub-optimal but a darn-sight better
than nothing. They usually had a hosted 68k
proc + PPC. Then they'd hand
you a somewhat incomplete bevvy of replacement libraries and binaries to put
the PPC60x proc into action. However, despite the jiggery pokery, they were
effective in speeding up nearly any kind of Workbench application, but for
games it was hit or miss. Sometimes it'd hork up games that depended too
much on the CPU clock.
That reminds me of the time my best friend in 7th grade got miffed at me
because I hit the "TURBO" button while he was playing "Budokan" and
some
ninja with a pair of chucks got froggy and put him on the mat because of the
extra speed. So, he made me try it and I didn't even get past the first
fight (while he laughed at me).
I keep hatching little schemes of perhaps putting a
tiny OS kernel in the
thing, but at that point *it* would become the computer and the 128 would
be just sort of sitting there.
... you are right, but it'd still feel "original" to me because of the same
hardware my hands were on & original video graphics running the show. Hmfp.
Maybe I'm just rationalizing, though.
The same is true of the CosmosEx device I've been
thinking of getting for
my Atari STs; it has a Raspberry Pi inside.
That thing is rad. I didn't know about it. I never owned an ST, but lately
I've considered getting one. I like the all-in-one designs, but I'd probably
go for the full size rig in the end. Wait, nevermind, I seem to remember my
SO threatening bodily harm if anymore old gear showed up....
-Swift
1:58 p.m.
The same is
true of the CosmosEx device I've been thinking of getting for
my Atari STs; it has a Raspberry Pi inside.
That thing is rad. I didn't know
about it. I never owned an ST, but lately
I've considered getting one. I like the all-in-one designs, but I'd probably
go for the full size rig in the end. Wait, nevermind, I seem to remember my
SO threatening bodily harm if anymore old gear showed up.... 
23 Apr
23 Apr
7:57 a.m.
On 04/22/2016 01:51 PM, Eric Christopherson wrote:
I like the new types of peripherals but it makes me a
little uncomfortable
knowing that e.g. in the case of the uIEC-SD for Commodores, the clock
speed of the peripheral is 16 to 20 times that of the original host CPU.
Honestly, I can't see the point in modern upgrades except perhaps for
temporary use in order to get data to/from original equipment. At the point
where people start adding emulated storage, USB interfaces, VGA display
hardware etc. it stops being a vintage system and starts being a modern
version which just happens to still have a few vintage parts. May as well
say screw it and just use an emulator for the whole thing...
Now upgrades within the realm of what would have been possible during a
system's lifetime I can get on board with - using period components to
implement things such as Ethernet interfaces, accelerators, extra memory etc...
J.
8:25 a.m.
Honestly, I can't see the point in modern upgrades
except perhaps for
temporary use in order to get data to/from original equipment. At the point
where people start adding emulated storage, USB interfaces, VGA display
hardware etc. it stops being a vintage system and starts being a modern
version which just happens to still have a few vintage parts. May as well
say screw it and just use an emulator for the whole thing...
Now upgrades within the realm of what would have been possible during a
system's lifetime I can get on board with - using period components to
implement things such as Ethernet interfaces, accelerators, extra memory etc...
I'm with you on this, generally...
A concrete example. As many of you know I have a VAX 11/730 that I am restoring
(It's currently on hold as I may have a lead on a scrap RA80 that I can get the
brackets, etc, I need to repair the R80 from (as well as a spare HDA) so until
I know one way or the other I am not going to do metalbashing...). I do NOT want
to use any of the common TU58 emulators. It seems ridiculous to use something
like an Rpi to boot an 11/730 CPU. If I can't get the real tape-based TU58 running
then any emulator I make for it will use a CPU contemporary with the rest of
the machine (probably an 8085 as used in the real TU58).
Similarly I want to keep FPGAs and the like (hacker-unfriendly, closed, devices)
away from my classics. I want proper documentation -- that's one reason
I run the classics in the first place. Not a closed-source compiler that does
$diety-knows-what to my design. I will not stick an FPGA-based board in my
Unibus, there were no such things with the Unibus was 'current' .
However, how far do you go (I am asking, I am not sure of the answer). Is it
'OK' to use a modern machine running a terminal emulator in place of a
real contemporary-to-the-machine terminal (FWIW, I do try to have at
least the console as a 'real' terminal in the end but might well use a
terminal emulator when getting it all working). What about mass storage
units that just connect to a peripheral interface (I am thinking of things
like the HPIB-interfaced drives on HP9000/200 machnes). Should you
not use modern machines and compilers to cross-develop software for
classic computers? Should you only use test gear that was contemporary
with the machine (so no DSO's when working on classics, I should not
use my (ancient) logic analysers, even less the LogicDart on my
PDP11s)?
-tony
10:29 a.m.
On 04/23/2016 10:25 AM, tony duell wrote:
I'd be comfortable with that *if* I couldn't acquire a terminal for the
system - and I'd prefer to use a period terminal over an emulator even if
it wasn't necessarily the correct one for the machine. It's all about
recreating the original 'experience' as closely as possible, I suppose.
Now upgrades
within the realm of what would have been possible during a
system's lifetime I can get on board with - using period components to
implement things such as Ethernet interfaces, accelerators, extra memory etc...
I'm with you on this, generally...
...
However, how far do you go (I am asking, I am not sure of the answer). Is it
'OK' to use a modern machine running a terminal emulator in place of a
real contemporary-to-the-machine terminal What about mass storage
units that just connect to a peripheral interface (I am thinking of things
like the HPIB-interfaced drives on HP9000/200 machnes).
Personally I'm planning on keeping period storage around and using it for
as long as I can. There will come a day when it's not realistic/possible to
do that, but I'm really not interested in emulating a vintage drive with
something that uses a CF card (say) if I don't have to.
Should you
not use modern machines and compilers to cross-develop software for
classic computers?
Hmm. I don't have any problem with using modern hardware for the
development side of it - but I'm not entirely sure *why* I feel that way;
logically I fell like I should object to it :-)
Should you only use test gear that was contemporary
with the machine (so no DSO's when working on classics, I should not
use my (ancient) logic analysers, even less the LogicDart on my
PDP11s)?
I've got no problem at all with modern test equipment; I consider fixing
the hardware to be a separate thing to using it, I suppose (even though I'd
be inclined to say that I get far more enjoyment out of restoring vintage
systems than I do once they're 100% operational).
cheers
Jules
6:10 p.m.
Overall I'm personally much more about using the system *as a whole* than using it *as
it was*.
For example, I have a Mac IIci with maxed-out RAM, some large SCSI disks, Ethernet, and an
accelerated NuBus video card, all possible at the time. (Though 128MB RAM and the 1GB
disks would have bankrupt a small nation in 1989.) I'm not going to plug it into a
period monitor though, I just acquired a multi sync LCD with which to replace its current
late-1990s CRT. Similarly, I have a BigMessOWires MacFloppyEmu for most of my real storage
needs, which has virtually no latency and virtually infinite capacity, so I can spend my
time with the system using it rather than spend it all booting it and launching
applications.
Similarly, I pulled the 4GB drive from my SPARCstation 20[1] and put in a pair of 167GB
15.5K Cheetahs, so I could run Solaris 8 and NetBSD fast and never worry about space. I
have an external 411 to put the 4GB drive in, so I can still run SunOS, I've put in a
SunSwift 100Base-T card to make getting things to the system faster, and if I add more
storage it'll be with a SCSI2SD or equivalent, again so I can use the system rather
than wait to use it.
I've even looked a little at ProFile emulation for my Lisa 2/10. I don't even know
if its current ProFile still works, since all ProFiles are old enough at this point that
their formatting is decaying, and I've also moved a few times in the dozen years since
I last booted it. (At least the MacFloppyEmu will also work with the Lisa, so I don't
need its 3.5in drive to work, or to run Dart on my IIci to write 400KB floppies?) And
again, to avoid spending all my time with it waiting, I've looked a tiny bit at how to
replace the two 512KB RAM boards with a single board with 2MB, 8MB, or whatever it will
take, using some more modern hardware.
I want to use the systems as a whole enough not to just live in emulation, but I only have
a limited amount of time to spend with them, so replacing just a few subsystems in ways
that make the use of the overall systems smoother seems like a reasonable compromise.
-- Chris
[1] When I first got my SS20 home and booted it, it came up as ids-three.smcc.sun.com and
said it was starting Cadence license servers. I assume it was an identity server for Sun
Microcomputer, if anyone knows more I'd love to hear about it.
25 Apr
25 Apr
8:42 a.m.
On Sat, 23 Apr 2016, Chris Hanson wrote:
I want to use the systems as a whole enough not to
just live in emulation,
but I only have a limited amount of time to spend with them, so replacing
just a few subsystems in ways that make the use of the overall systems
smoother seems like a reasonable compromise.
I completely agree with you and the rest of your post. It sounds like you
and I have a very similar attitude and use-case for our retro-hardware.
I don't mind putting 3rd party extras on my older systems. As an example,
I use several Acard 50-pin SCSI2 narrow adapter that can hold 2.5" SATA
drives on older systems. The bandwidth of the SSDs I put in these
adapters far outstrips the capabilities of my old SGI & Amiga systems.
The thing is the latency is _so_ much lower, and that *does* translate to
improved performance on the old hardware. It makes using the machines
much more enjoyable.
Plus, I remember a tradition of modifying and extending hardware in the
80's and 90's that's mostly been lost in the era of cheap disposable PCs.
I'm okay with hot-rodding machines, even 20-30 years later when it doesn't
make much difference. Why not use an emulator? Well where is the fun in
that if I can't touch the metal ?
I guess it's a bit like old cars. Lots of people hate the idea of someone
putting non-original parts onto classic cars. Others will go nuts and
butcher them into franken-rods with a mix. To each his own. I might be
laughed at for wanting a Fiero-Ferrari, but hey it's all in good fun.
-Swift
22 Apr
22 Apr
12:12 p.m.
On Fri, 22 Apr 2016, Guy Sotomayor wrote:
[...] emulation (or dynamic translation) is fast
enough and with the
various virtualization capabilities, it?s not unusual to have multiple
different OS?s running on the same HW.
Indeed. My other wish is that someone far brighter than I will someday
develop a MIPS emulator capable of emulating IRIX. The odds of that aren't
great since untangling the ROM would be a real PITA.
Apple did this with some success in it?s various CPU
transitions. When
they switched from 68K to PPC, the PPC emulated the 68K code. The same
happened when they switched from PPC to x86, again the PPC code was
emulated (actually in that case it was dynamically translated).
Yes, and don't forget the NeXT platform which had "quad-fat binaries"
capable of running on 4 (!) platforms at once. It might have been a little
top heavy and impractical at times, but it was soooo cool to me. I'm sure
you remember "Rosetta" too. IRIX on x86 would be heresy to some, but I'd
welcome it *especially* if it could dynamically translate MIPS ECOFF
binaries, and run legacy IRIX software. I know the lawyers would never let
any of that happen, but a man needs to have some dreams. :-)
It?s also keeping in character with the old machines.
It?s not adding new
capabilities but more replacing old peripherals with something a bit more
convenient.
I see your point and I agree.
Adding in a new accelerator means not only developing
the HW but also
writing a boatload of *new* SW in order to be able to take advantage of
it.
An oil-tanker sized boat. Yep. Unless of course you could keep everything
pin compatible etc... which is even harder. "We're gonna need a bigger
boat."
Most of what you see (and what I?m mainly doing these
days in terms of
?hobby?) is producing parts to a system in order to keep it running rather
than adding completely new capabilities.
Well, I appreciate that fact that anyone is doing anything! If I ever
meet "Lotharek" I'm definitely buying him a round. I get excited just
looking at some old gear that someone's cleaned up nicely or polished the
face panels on. I'd probably die in an apoplectic fit if I ever saw an ad
for an SGI accel board. If I ever make someone mad, they could totally get
back at me by handing me a fake flyer for "Press release: Acme Inc
releases SGI MIPS accelerator board based off high speed GPU". When I
found out it was bogus I'd go jump off the roof. Joking aside, I do see
your point about restoring vs enhancing, and it's well taken.
Most companies would rather spend their time and
budget doing things for
a high ROI and for large and growing markets.
Amen brother, I was just wishing out loud. I needed someone to bring me back
to Earth.
-Swift
1:38 p.m.
The way one would implement such accelerator boards over an IO subsystem
bus is to use memory-mapped registers and depending upon the accelerator
either a single register that executes an instruction on write or a
small memory for microcode with some way of triggering execution.
Older SGI's have a VME bus and the GIO/GIO64 bus used for I think the
Indigo's is also documented. This is aside from E(ISA) and PCI cards.
So it is possible but as mentioned before the software is an issue,
especially if you don't want to explicitly write code for it but have
the compiler automatically use the accelerator.
On the topic of IRIX emulation:
There used to be an emulator from Stanford which could run IRIX 5.4
https://en.wikipedia.org/wiki/SimOS
Also whilst searching for the latter's name I've found
https://www.vanheusden.com/miep/
(also Gxemul can emulate the PROM firmware of an O2)
- Jan
On 04/22/2016 09:12 PM, Swift Griggs wrote:
On Fri, 22 Apr 2016, Guy Sotomayor wrote:
[...] emulation (or dynamic translation) is fast
enough and with the
various virtualization capabilities, it?s not unusual to have multiple
different OS?s running on the same HW.
Indeed. My other wish is that someone far brighter than I will someday
develop a MIPS emulator capable of emulating IRIX. The odds of that aren't
great since untangling the ROM would be a real PITA.
Apple did this with some success in it?s various
CPU transitions. When
they switched from 68K to PPC, the PPC emulated the 68K code. The same
happened when they switched from PPC to x86, again the PPC code was
emulated (actually in that case it was dynamically translated).
Yes, and don't forget the NeXT platform which had "quad-fat binaries"
capable of running on 4 (!) platforms at once. It might have been a little
top heavy and impractical at times, but it was soooo cool to me. I'm sure
you remember "Rosetta" too. IRIX on x86 would be heresy to some, but I'd
welcome it *especially* if it could dynamically translate MIPS ECOFF
binaries, and run legacy IRIX software. I know the lawyers would never let
any of that happen, but a man needs to have some dreams. :-)
It?s also keeping in character with the old
machines. It?s not adding new
capabilities but more replacing old peripherals with something a bit more
convenient.
I see your point and I agree.
Adding in a new accelerator means not only
developing the HW but also
writing a boatload of *new* SW in order to be able to take advantage of
it.
An oil-tanker sized boat. Yep. Unless of course you could keep everything
pin compatible etc... which is even harder. "We're gonna need a bigger
boat."
Most of what you see (and what I?m mainly doing
these days in terms of
?hobby?) is producing parts to a system in order to keep it running rather
than adding completely new capabilities.
Well, I appreciate that fact that anyone is doing anything! If I ever
meet "Lotharek" I'm definitely buying him a round. I get excited just
looking at some old gear that someone's cleaned up nicely or polished the
face panels on. I'd probably die in an apoplectic fit if I ever saw an ad
for an SGI accel board. If I ever make someone mad, they could totally get
back at me by handing me a fake flyer for "Press release: Acme Inc
releases SGI MIPS accelerator board based off high speed GPU". When I
found out it was bogus I'd go jump off the roof. Joking aside, I do see
your point about restoring vs enhancing, and it's well taken.
Most companies would rather spend their time
and budget doing things for
a high ROI and for large and growing markets.
Amen brother, I was just wishing out loud. I needed someone to bring me back
to Earth.
-Swift
4:37 p.m.
On 22/04/2016 21:38, Jan Adelsbach wrote:
Older SGI's have a VME bus and the GIO/GIO64 bus
used for I think the
Indigo's
and Indys and the small Challenges
is also documented.
yes, it could be obtained through the Developer Program (I have a copy),
though I seem to recall some strings attached.
There used to be an emulator from Stanford which could
run IRIX 5.4
https://en.wikipedia.org/wiki/SimOS
Perhaps you mean IRIX 5.3, the last 5.x, which ran on Indy, Indigo,
Challenge, etc, or 6.4 which was an early special for the Octane and
O2000/Onyx2. There's no IRIX 5.4, at least, not released. It went from
5.3 to the very short-lived 6.0.1, then 6.2 (Indy, Indigo2, etc) 6.3
(first release for O2) and 6.4 (ditto for Octane, Onyx/O2K) and quickly
to 6.5 across the product line.
--
Pete
2:09 p.m.
----- Original Message -----
From: "Guy Sotomayor" <ggs at shiresoft.com>
Sent: Friday, April 22, 2016 2:25 PM
...
Most companies would rather
spend their time and
budget doing things for a high ROI and for large and
growing markets.
TTFN - Guy
------------
True in general of course and a board like this is probably not exactly up his alley, but
let's not forget that there are folks out there like our own Jim Brain who design and
build/sell items with a limited market and ROI mainly for the satisfaction of contributing
to the hobby.
http://store.go4retro.com/
m
2:12 p.m.
On Apr 22, 2016, at 2:09 PM, Mike Stein <mhs.stein
at gmail.com> wrote:
----- Original Message -----
From: "Guy Sotomayor" <ggs at shiresoft.com>
Sent: Friday, April 22, 2016 2:25 PM
...
As am I?just in a more limited way due to time constraints. ;-)
TTFN - Guy
Most companies would rather
spend their
time and budget doing things for a high ROI and for large and
growing markets.
TTFN - Guy
------------
True in general of course and a board like this is probably not exactly up his alley, but
let's not forget that there are folks out there like our own Jim Brain who design and
build/sell items with a limited market and ROI mainly for the satisfaction of contributing
to the hobby.
http://store.go4retro.com/
12:17 p.m.
I'm most familiar with the Amiga accelerators. I
suspect those who
produced them were helped out greatly by a couple of factors. One is that
the hardware specs were very well known and full schematics were available
for most (all?) Amigas. I doubt the same is true of SGI machines.
SGI stuff is still much under wraps as far as I know. Thats why NetBSD and
similar for SGI are still pretty rudimentary. All propriatary, those
groups don't want to use stolen info, and who knows if the documentation
still even exists after the rackable purchase.
The
other is that many Amigas had processor "slots" (with edge connectors)
rather than some tiny fiddly ball-grid array etc... but I'm not a EE; so
maybe that's bunk.
High clock rates for data busses of modern systems wouldn't work with old
style card edge interconnects AFAIK. Also, I don't think the old PPC
accelerators for the Amiga or the ones for the Macs (that sometimes had
CPU upgrade slots) would really accelerate everything - you might get
faster processor instructions and maybe L1/L2 cache -- but memory and
I/O are still slow?
When I look at these boards they seem like they'd
be a LOT of work to
develop and produce. I wonder how they were even economical to make back in
the day. Plus, now the user base will probably only shrink. It's not a
great business model for a hard-to-produce item. It doesn't keep my
techno-lust from wanting it, though.
They were really expensive at the time :-) US dollars have lost a lot of
value (especially given overpriced housing.) The old $3000 Tandy system
with a 20 meg hard card and TGA/CGA graphics is like $7000 in todays cash.
Amiga stuff was always pretty expensive, and you had to pay VGA monitor
prices for it's crappy TV display (1084S). And yea, at least Atari stuff
was made in Taiwan so they were using cheaper labor then too.
So, here's the question. Is my dream likely to
ever be possible enough that
a boutique shop could pull it off and not lose their shirt on the production
costs and R&D to do it ? I'm encouraged by things floppy emulators that are
produced for these old machines. However, that's probably significantly
easier to make than a CPU accel board.
What do you guys think?
-Swift
You gotta build it!
There are better tools for doing it now (board layout apps and such) and
you can get boards made in China cheap. So that's on your side.
--
Ethan O'Toole
2:17 p.m.
On Fri, 22 Apr 2016, ethan at 757.org wrote:
SGI stuff is still much under wraps as far as I know.
Thats why NetBSD
and similar for SGI are still pretty rudimentary. All propriatary, those
groups don't want to use stolen info, and who knows if the documentation
still even exists after the rackable purchase.
Rackable totally needs to release that stuff, but the lawyer-weasels are
probably never going to let that happen due to all the cross-licensed code
in IRIX. However, I still wish they'd release hardware specs. I wonder
what that could hurt? Maybe it's the same type of thing if they OEM'd too
many parts. I think IRIX support of any kinds ends this year (for 6.5.30 on
a Tezro only). Maybe they will reconsider after they don't get any $$$ from
it in order to build some good will and gain some street cred. Yes, I
know.. feel free to wake me up anytime...
High clock rates for data busses of modern systems
wouldn't work with old
style card edge interconnects AFAIK.
Ahh, yeah I forgot that's why they did that (move to BGA and such). I'll
bet you are right. It'd have to go in the processor slot.
Also, I don't think the old PPC accelerators for
the Amiga or the ones for
the Macs (that sometimes had CPU upgrade slots) would really accelerate
everything - you might get faster processor instructions and maybe L1/L2
cache -- but memory and I/O are still slow?
That's totally true from my recollection. However, some of the boards for
the Amiga would co-locate additional RAM on the accel board. That was a bit
of an in-between state. Nonetheless the faster CPU(s) would generally have
some positive impact. Plus, some of the boards were just plain neat looking
and made your Amiga look even-more-awesome (to my geek eyes, at least).
They were really expensive at the time :-) US dollars
have lost a lot of
value (especially given overpriced housing.) The old $3000 Tandy system
with a 20 meg hard card and TGA/CGA graphics is like $7000 in todays cash.
Which is why I never owned one :-) My parents were so poor when I was a kid
I slept in a dresser drawer (until I outgrew it). hehe. I only got
cast-off gear at that time, usually 10 years behind the state of the art
(mostly stuff my mom found at garage sales).
Amiga stuff was always pretty expensive, and you had
to pay VGA monitor
prices for it's crappy TV display (1084S).
Awww. That truth stings. :-) It sure was a purty video display and playing
SNES and Genesis games on it rocked.
And yea, at least Atari stuff was made in Taiwan so
they were using
cheaper labor then too.
Heh, Atari always was a forerunner. Guess they pioneered offshoring, too.
:-)
You gotta build it!
Oh man, I can barely repair my guitar amps when they fail. You guys would
laugh hard watching me try to run a scope, too. I can fix monitors,
sometimes (used to do it back in the day for a job). Mostly, I'm a 'test
post' electronics tech. I can measure voltages, run a solder-sucker, tell
the diff between most components, and possibly not burn and bird-crap all my
joints, but I pretty well suck at electronics. I'm not even close to
skilled enough with digital component layout tools, logic analyzers,
verilog, FPGAS, etc.. as what I'd need to be and I doubt I could learn it
fast enough to be useful, but who knows. Like you say, the tools today are
amazing. I'm more of a software and integration guy, but I'm interested in
just about everything technical, even biology (esp female biology, har har) !
:-)
-Swift
25 Apr
25 Apr
1:13 p.m.
On Fri, Apr 22, 2016 at 2:17 PM, <ethan at 757.org> wrote:
Well, the native memory, and peripherals, yeah sure, that was still "slow."
(but still adequate). Most every accelerator board available for Amiga had
it's own dedicated on-board memory and SCSI adapter for faster IO where it
really mattered most. The other major thing being graphics adapters ran
better on the 3000 and 4000 since those had 32-bit busses (and with higher
speed and burst modes available), so they kinda sorta planned on people
putting faster processors on those than what they were shipped with (and in
some cases didn't have a CPU on the motherboard even).
Not sure about the Apple front.
The
other is that many Amigas had processor "slots" (with edge connectors)
rather than some tiny fiddly ball-grid array etc... but I'm not a EE; so
maybe that's bunk.
High clock rates for data busses of modern systems wouldn't work with old
style card edge interconnects AFAIK. Also, I don't think the old PPC
accelerators for the Amiga or the ones for the Macs (that sometimes had CPU
upgrade slots) would really accelerate everything - you might get faster
processor instructions and maybe L1/L2 cache -- but memory and I/O are
still slow? 
2:20 p.m.
On 4/25/2016 2:13 PM, Geoffrey Oltmans wrote:
Well, the native memory, and peripherals, yeah sure, that was still "slow."
(but still adequate). Most every accelerator board available for Amiga had
it's own dedicated on-board memory and SCSI adapter for faster IO where it
really mattered most. The other major thing being graphics adapters ran
better on the 3000 and 4000 since those had 32-bit busses (and with higher
speed and burst modes available), so they kinda sorta planned on people
putting faster processors on those than what they were shipped with (and in
some cases didn't have a CPU on the motherboard even).
Not sure about the Apple front.
Well I know, you get the wrong chipset and nothing got suported
for the PC. Ben.
PS: I hate OS's for upgrading the screen resolution to get more crappy
dancing toasters. BRING BACK 640x480. I can READ the SCREEN.
2:46 p.m.
New subject: Screen sizes. Was Re: Accelerator boards - no future? Bad business?
On Mon, 25 Apr 2016, ben wrote:
PS: I hate OS's for upgrading the screen
resolution to get more crappy
dancing toasters. BRING BACK 640x480. I can READ the SCREEN.
Amen to that. I have macular degeneration in my retinae. It's not really
having any effect, yet. However, I'm starting to note that my fonts sizes
are creeping up. I *dream* of an LCD that's greater than 21" but uses a
much lower native resolution. I'd take 640x480, 800x600, 1024x786, or
1280x1024 (at most).
Incidentally, have you seen any new 4k screens? I got one early on and boy
what a mistake that was. I didn't even keep it for a week. You can jack up
your terminal fonts to 14 or 18 and it's still tiny and nearly unreadable.
In applications that you can't adjust easily, it's a nightmare. You can't
read *anything*. Playing some games in 4k was cool, it looked marginally
better than 1920x1080, but not much. The only thing that was better or more
detailed (in my case, folks, in my case) was photo-editing.
-Swift
3:15 p.m.
New subject: Screen sizes. Was Re: Accelerator boards - no future? Bad business?
On 04/25/2016 02:46 PM, Swift Griggs wrote:
On Mon, 25 Apr 2016, ben wrote:
I'm still using a NEC 5:4 1200x1600 Multisync 23.1" LCD. Not
wide-screen, but then I'm not a goat (hint: look up "goat pupil
shape"), so I'm fine with it.
The 32" 1080p widescreen monitors that I have are terrible when it comes
to displaying detail.
--Chuck
PS: I hate OS's for upgrading the screen
resolution to get more
crappy dancing toasters. BRING BACK 640x480. I can READ the
SCREEN.
Amen to that. I have macular degeneration in my retinae. It's not
really having any effect, yet. However, I'm starting to note that my
fonts sizes are creeping up. I *dream* of an LCD that's greater than
21" but uses a much lower native resolution. I'd take 640x480,
800x600, 1024x786, or 1280x1024 (at most). 
3:16 p.m.
New subject: Screen sizes. Was Re: Accelerator boards - no future? Bad business?
-----Original Message-----
From: Swift Griggs
Sent: Monday, April 25, 2016 5:46 PM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Screen sizes. Was Re: Accelerator boards - no future? Bad business?
I *dream* of an LCD that's greater than 21" but uses a
much lower native resolution. I'd take 640x480, 800x600, 1024x786, or
1280x1024 (at most).
Those resolutions don't exist in widescreens which is all anybody makes
anymore. I picked up a nice 19" 1280x1024 native resolution LCD monitor
years ago but ended up with a 24" 1080P IPS monitor. You can still find old
DELL 1280x1024 monitors used for cheap. Not sure if anybody made that
resolution in larger then 19" size.
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
8:39 p.m.
New subject: Screen sizes. Was Re: Accelerator boards - no future? Bad business?
On 25 April 2016 at 23:46, Swift Griggs <swiftgriggs at gmail.com> wrote:
On Mon, 25 Apr 2016, ben wrote:
I ran into that with a 2560x1440 screen. But it turns out that the
solution is *not* to increase font size. OS'es which can handle those
screens (and 4K as well), including various Linux distros and Windows,
do this by changing the GUI to 'high dpi' (or various versions of that
term). Everything adjusts to the high resolution, including terminal
windows (although not the humble 'xterm'. GTK-based ones, and other of
that kind, do though). So my screen became perfectly readable again.
Crisp, clear, and large.
PS: I hate OS's for upgrading the screen
resolution to get more crappy
dancing toasters. BRING BACK 640x480. I can READ the SCREEN.
Amen to that. I have macular degeneration in my retinae. It's not really
having any effect, yet. However, I'm starting to note that my fonts sizes
are creeping up. I *dream* of an LCD that's greater than 21" but uses a
much lower native resolution. I'd take 640x480, 800x600, 1024x786, or
1280x1024 (at most).
Incidentally, have you seen any new 4k screens? I got one early on and boy
what a mistake that was. I didn't even keep it for a week. You can jack up
your terminal fonts to 14 or 18 and it's still tiny and nearly unreadable.
In applications that you can't adjust easily, it's a nightmare. You can't
read *anything*. Playing some games in 4k was cool, it looked marginally
better than 1920x1080, but not much. The only thing that was better or more
detailed (in my case, folks, in my case) was photo-editing.
2:55 p.m.
New subject: High resolution screens are great for typography - Re: Accelerator boards - no future? Bad business?
On 2016-04-25 5:20 PM, ben wrote:
On 4/25/2016 2:13 PM, Geoffrey Oltmans wrote:
Or just make the text bigger... We've had proper font scaling technology
in common operating systems for about 30 years now.
There is no upper limit to size & more pixels means better fidelity to
letterforms and therefore better legibility, not worse. Ask a
typographer anything.
--Toby
Well, the native memory, and peripherals, yeah sure, that was still
"slow."
(but still adequate). Most every accelerator board available for
Amiga had
it's own dedicated on-board memory and SCSI adapter for faster IO
where it
really mattered most. The other major thing being graphics adapters ran
better on the 3000 and 4000 since those had 32-bit busses (and with
higher
speed and burst modes available), so they kinda sorta planned on people
putting faster processors on those than what they were shipped with
(and in
some cases didn't have a CPU on the motherboard even).
Not sure about the Apple front.
Well I know, you get the wrong chipset and nothing got suported
for the PC. Ben.
PS: I hate OS's for upgrading the screen resolution to get more crappy
dancing toasters. BRING BACK 640x480. I can READ the SCREEN.
3:34 p.m.
New subject: High resolution screens are great for typography - Re: Accelerator boards - no future? Bad business?
On 4/25/2016 3:55 PM, Toby Thain wrote:
There is no upper limit to size & more pixels
means better fidelity to
letterforms and therefore better legibility, not worse. Ask a
typographer anything.
--Toby
I suspect other that TEX fonts, You cannot get fonts to scale properly
for the bigger screens. Ben.
4:21 p.m.
New subject: High resolution screens are great for typography - Re: Accelerator boards - no future? Bad business?
On 2016-04-25 6:34 PM, ben wrote:
On 4/25/2016 3:55 PM, Toby Thain wrote:
Incorrect. Scalable system (& third party) fonts have been with us for
more than 30 years, as I said.
Both Mac System 7 and ancient Windows shipped with TrueType, but even
before that you had anti-aliased type with Adobe Type Manager.
OS X 10.3 shipped with subpixel rendering on LCD as has Windows
Cleartype for many years.
Now, not ALL UI elements may be properly resolution independent, but
TEXT definitely is (e.g. the Terminal window example, or any editor, etc).
Blow it up as big as you like; you might like to use one of these
scalable fonts: http://programmingfonts.org/ (Adobe Source Code Pro is a
great start)
--Toby
There is no upper limit to size & more pixels
means better fidelity to
letterforms and therefore better legibility, not worse. Ask a
typographer anything.
--Toby
I suspect other that TEX fonts, You cannot get fonts to scale properly
for the bigger screens. Ben.
5:15 p.m.
New subject: High resolution screens are great for typography - Re: Accelerator boards - no future? Bad business?
On Mon, 25 Apr 2016, Toby Thain wrote:
Incorrect. Scalable system (& third party) fonts
have been with us for
more than 30 years, as I said.
Though you are quite correct, it doesn't mean that scalable fonts are
everywhere. They might be present more or less everywhere in MacOS and
maybe even Windows, too. However, there are two problems. One is that it's
(currently) a big hassle in Windows to get absolutely every font to get
bigger at once. Trust me, I tried. For example, you might make the title
bar bigger, but the text underneath button icons might be immutable (and
thus microscopic). I expect this will change in the future as folks adopt
Apple's solution where they can sort of interpolate (maybe that's the wrong
term in this case) the view of what you are seeing. I'm guessing you know
what I mean. If that happens, I might decide I *love* high res screens.
What you are saying is fundamentally sound, ie.. more pixels mean more
detail and readability. It's just the current state of the art that's no
fun.
My other (personal) issue is that I use a lot of oddball operating systems
that don't have and will never have good support for scalable fonts which
can easily be adapted for ultra-high-res. So, I just stick with old
monitors and specialty stuff (like the Samsung 210T).
OS X 10.3 shipped with subpixel rendering on LCD as
has Windows Cleartype
for many years.
Which is, I agree, great for readability. Now if there was just a universal
one-stop place to double my font sizes in every OS (or even the same OS)...
:-)
-Swift
5:29 p.m.
New subject: High resolution screens are great for typography - Re: Accelerator boards - no future? Bad business?
On Apr 25, 2016, at 8:15 PM, Swift Griggs
<swiftgriggs at gmail.com> wrote:
On Mon, 25 Apr 2016, Toby Thain wrote:
Indeed. At least Windows offers the option, though it does a mediocre job. Mac OS
doesn't do it at all, in any way. It seems that Apple thinks everyone is a young
whipppersnapper.
paul
Incorrect. Scalable system (& third party)
fonts have been with us for
more than 30 years, as I said.
Though you are quite correct, it doesn't mean that scalable fonts are
everywhere. They might be present more or less everywhere in MacOS and
maybe even Windows, too. However, there are two problems. One is that it's
(currently) a big hassle in Windows to get absolutely every font to get
bigger at once. Trust me, I tried.
6:05 p.m.
New subject: High resolution screens are great for typography - Re: Accelerator boards - no future? Bad business?
On 2016-04-25 8:15 PM, Swift Griggs wrote:
On Mon, 25 Apr 2016, Toby Thain wrote:
"Maybe" even Windows? Microsoft was a partner in developing TrueType...
You couldn't use Windows in graphic arts without this feature.
& Linux has had Freetype for a long time (also with subpixel rendering).
Incorrect. Scalable system (& third party)
fonts have been with us for
more than 30 years, as I said.
Though you are quite correct, it doesn't mean that scalable fonts are
everywhere. They might be present more or less everywhere in MacOS and
maybe even Windows, too. However, there are two problems. One is that it's (currently) a big hassle in Windows to get absolutely
every font to get
bigger at once. Trust me, I tried. For example, you might make the title
bar bigger, but the text underneath button icons might be immutable (and
thus microscopic). I expect this will change in the future as folks adopt
Apple's solution where they can sort of interpolate (maybe that's the wrong
term in this case) the view of what you are seeing. I'm guessing you know
what I mean. If that happens, I might decide I *love* high res screens.
What you are saying is fundamentally sound, ie.. more pixels mean more
detail and readability. It's just the current state of the art that's no
fun.
My other (personal) issue is that I use a lot of oddball operating systems
that don't have and will never have good support for scalable fonts which
Then again, some "oddball" operating systems have excellent support for
scalable fonts and anti-aliasing. Embedded user interfaces often need it
just as much as desktops.
can easily be adapted for ultra-high-res. So, I just
stick with old
monitors and specialty stuff (like the Samsung 210T).
Control + or Command + :-)
[also Chrome has a default window zoom. I find this setting for me has
crept up a little in recent years :]
--Toby
OS X 10.3 shipped with subpixel rendering on LCD
as has Windows Cleartype
for many years.
Which is, I agree, great for readability. Now if there was just a universal
one-stop place to double my font sizes in every OS (or even the same OS)...
:-)
-Swift
6:43 p.m.
New subject: High resolution screens are great for typography - Re: Accelerator boards - no future? Bad business?
On 4/25/2016 6:15 PM, Swift Griggs wrote:
On Mon, 25 Apr 2016, Toby Thain wrote:
Since I am in sour mood today, rain is hampering my cleaning plans ...
The screen looks great, But how does that web page print?
The sour side ... printing.
Ben.
Incorrect. Scalable system (& third party)
fonts have been with us for
more than 30 years, as I said.
Though you are quite correct, it doesn't mean that scalable fonts are
everywhere. They might be present more or less everywhere in MacOS and
maybe even Windows, too. However, there are two problems. One is that it's
(currently) a big hassle in Windows to get absolutely every font to get
bigger at once. Trust me, I tried. For example, you might make the title
bar bigger, but the text underneath button icons might be immutable (and
thus microscopic). I expect this will change in the future as folks adopt
Apple's solution where they can sort of interpolate (maybe that's the wrong
term in this case) the view of what you are seeing. I'm guessing you know
what I mean. If that happens, I might decide I *love* high res screens.
What you are saying is fundamentally sound, ie.. more pixels mean more
detail and readability. It's just the current state of the art that's no
fun.
My other (personal) issue is that I use a lot of oddball operating systems
that don't have and will never have good support for scalable fonts which
can easily be adapted for ultra-high-res. So, I just stick with old
monitors and specialty stuff (like the Samsung 210T).
OS X 10.3 shipped with subpixel rendering on LCD
as has Windows Cleartype
for many years.
Which is, I agree, great for readability. Now if there was just a universal
one-stop place to double my font sizes in every OS (or even the same OS)...
:-)
-Swift
22 Apr
22 Apr
8:29 p.m.
It was thus said that the Great Swift Griggs once stated:
Remember all the accelerator boards for the Mac, Amiga, and even PCs in the
90's ? I've often wished that I could get something similar on my older SGI
systems. For example, fitting an R16k into an O2 or doing dynamic
translation on a 4.0Ghz i7.
One major problem with adding a faster CPU to an SGI is the MIPS chip
itself---code compiled for one MIPS CPU (say, the R3000) won't run on
another MIPS CPU (say, the R4400) due to the differences in the pipeline.
MIPS compilers were specific for a chip because such details were not hidden
in the CPU itself, but left to the compiler to deal with.
-spc (Who had near exclusive use of an SGI in college in the early 90s)
10:16 p.m.
On Fri, Apr 22, 2016 at 9:29 PM, Sean Conner <spc at conman.org> wrote:
One major problem with adding a faster CPU to an SGI
is the MIPS chip
itself---code compiled for one MIPS CPU (say, the R3000) won't run on
another MIPS CPU (say, the R4400) due to the differences in the pipeline.
MIPS compilers were specific for a chip because such details were not hidden
in the CPU itself, but left to the compiler to deal with.
Having written a bunch of R3000 and R4000/4200/4300/4400/4600 assembly
code in the 1990s, my (possibly faulty) recollection disagrees with
you. There are differences in supervisor-mode programming, but I don't
recall any issues with running 32-bit user-mode R3000 code on any
R4xxx. The programmer-visible pipelline behavior (e.g., branch delay
slots) were the same.
That's only considering the CPU itself, which I used as an embedded
processor; I never used IRIX so I don't know whether IRIX on R4xxx
might have somehow prevented use of IRIX R3xxx binaries (e.g., by
different system call conventions or the like).
11:42 p.m.
It was thus said that the Great Eric Smith once stated:
On Fri, Apr 22, 2016 at 9:29 PM, Sean Conner <spc
at conman.org> wrote:
Hmm ... I might have been misremembering. I just checked the book I have
on the MIPS, and yes, the supervisor stuff is different between the R2000,
R3000, R4000 and R6000. Also, the R2000, R3000 and R6000 have a five stage
pipeline, and the R4000 has an eight stage pipeline.
One major problem with adding a faster CPU to
an SGI is the MIPS chip
itself---code compiled for one MIPS CPU (say, the R3000) won't run on
another MIPS CPU (say, the R4400) due to the differences in the pipeline.
MIPS compilers were specific for a chip because such details were not hidden
in the CPU itself, but left to the compiler to deal with.
Having written a bunch of R3000 and R4000/4200/4300/4400/4600 assembly
code in the 1990s, my (possibly faulty) recollection disagrees with
you. There are differences in supervisor-mode programming, but I don't
recall any issues with running 32-bit user-mode R3000 code on any
R4xxx. The programmer-visible pipelline behavior (e.g., branch delay
slots) were the same. That's only considering the CPU itself, which I
used as an embedded
processor; I never used IRIX so I don't know whether IRIX on R4xxx
might have somehow prevented use of IRIX R3xxx binaries (e.g., by
different system call conventions or the like).
That I do not know. There were very few SGIs on campus at the time.
-spc
23 Apr
23 Apr
7:49 a.m.
On Sat, 23 Apr 2016, Sean Conner wrote:
Hmm ... I might have been misremembering. I just checked the book I have
on the MIPS, and yes, the supervisor stuff is different between the R2000,
R3000, R4000 and R6000. Also, the R2000, R3000 and R6000 have a five stage
pipeline, and the R4000 has an eight stage pipeline.
Pipeline restrictions were gradually relaxed by adding more and more
interlocks as the architecture evolved. So while user mode code compiled
for a higher ISA might not necessarily work with an older one even if it
only used instructions defined in the older ISA, there was no issue the
other way round, old code was forward compatible with newer hardware (or,
depending on how you look at it new hardware was backward compatible with
older code).
The timeline was roughly:
- MIPS II -- removed load delay slots -- for memory read instructions
targetting both general purpose and coprocessor registers,
- MIPS IV -- removed coprocessor transfer and condition code delay slots
-- for instructions used to move data between general purpose
and coprocessor registers as well as ones setting or reading
coprocessor condition codes.
The original MIPS I ISA only had an interlock on multiply-divide unit
(MDU) accumulator accesses, so all the other pipeline hazards had to be
handled in software, by inserting the right number of instructions between
the producer and the consumer of data; NOPs were used where no useful
instructions could be scheduled.
Some operations continued to require a manual resolution of pipeline
hazards even in the MIPS IV ISA, like moves to the MDU accumulator, as
well as many privileged operations (TLB writes, mode switches, etc.).
For these the SSNOP (superscalar NOP) instruction was introduced, which
was guaranteed not to be nullified with superscalar pipelines. The
encoding was chosen such that it was backwards compatible, using one of
the already existing ways to express an operation with no visible effects
other than incrementing the PC, which given the design of the MIPS
instruction set there has been always a plethora of. Consequently SSNOP
was executed as an ordinary NOP by older ISA implementations.
NB despite the hardware interlocks it has always been preferable to avoid
pipeline stalls triggered by them by scheduling the right minimum number
of instructions between data producers and the respective consumers anyway
and compilers have had options to adapt here to specific processor
implementations. The addition of hardware interlocks made the life of
compiler (and handcoded assembly) writers a little bit easier as a missed
optimisation didn't result in broken code. Also more compact code could
be produced where there was no way to schedule useful code to satisfy
pipeline hazards and NOP would have to be inserted otherwise.
I won't dive into the details of the further evolution with modern MIPS
ISAs here, for obvious reasons.
Maciej
One major problem with adding a faster CPU to an SGI
is the MIPS chip
itself---code compiled for one MIPS CPU (say, the R3000) won't run on
another MIPS CPU (say, the R4400) due to the differences in the pipeline.
MIPS compilers were specific for a chip because such details were not hidden
in the CPU itself, but left to the compiler to deal with.
Having written a bunch of R3000 and R4000/4200/4300/4400/4600 assembly
code in the 1990s, my (possibly faulty) recollection disagrees with
you. There are differences in supervisor-mode programming, but I don't
recall any issues with running 32-bit user-mode R3000 code on any
R4xxx. The programmer-visible pipelline behavior (e.g., branch delay
slots) were the same.
3:54 a.m.
On 23/04/2016 06:16, Eric Smith wrote:
On Fri, Apr 22, 2016 at 9:29 PM, Sean Conner <spc
at conman.org> wrote:
Nope, you're right. I've got R3000 and R4000 Indigos, R4000, R4400 ,
R4600 and R5000 Indys, R5K O2s and an R10K Origin 2000 running Irix 5.3
and 6.5, and the code written for the R3000 Indigos works fine on all
the others - with one exception (COFF vs ELF).
The same isn't necessarily true the other way around, of course, as the
later processors and later IRIX versions had things that didn't
translate back. For example, cc under IRIX 5.3, even with an R5000SC
CPU, compiles 32-bit "-mips1" by default and the resulting code will run
on any of the above and also on R2000 machines. However, in later
versions of IRIX the default became "-mips2" or higher, and of course on
some machines/IRIX versions the default became "-n32" or "-64" and in
some cases "-mips3" or "-mips4". Nevertheless there was still a
"-o32"
option and I've often compiled software on my O2K running 6.5.22 using
"-o32 -mips1" and run the resulting binary on an R3K Indigo as well as
the Origin (only somewhat slower :-)). About half of my /usr/local/bin
is compiled that way.
Another change was that IRIX 5.3 was the last version to support COFF
binaries, and the compiler itself would only produce ELF; later versions
of IRIX couldn't load COFF and would only run ELF binaries (with the
possible exception 6.0.1, but I don't remember). Under 5.3, you had to
use as(1) directly to generate COFF output.
--
Pete
One major problem with adding a faster CPU to
an SGI is the MIPS chip
itself---code compiled for one MIPS CPU (say, the R3000) won't run on
another MIPS CPU (say, the R4400) due to the differences in the pipeline.
MIPS compilers were specific for a chip because such details were not hidden
in the CPU itself, but left to the compiler to deal with.
Having written a bunch of R3000 and R4000/4200/4300/4400/4600 assembly
code in the 1990s, my (possibly faulty) recollection disagrees with
you. There are differences in supervisor-mode programming, but I don't
recall any issues with running 32-bit user-mode R3000 code on any
R4xxx. The programmer-visible pipelline behavior (e.g., branch delay
slots) were the same.
That's only considering the CPU itself, which I used as an embedded
processor; I never used IRIX so I don't know whether IRIX on R4xxx
might have somehow prevented use of IRIX R3xxx binaries (e.g., by
different system call conventions or the like).
25 Apr
25 Apr
8:05 a.m.
On Fri, 22 Apr 2016, Sean Conner wrote:
One major problem with adding a faster CPU to an SGI
is the MIPS chip
itself---code compiled for one MIPS CPU (say, the R3000) won't run on
another MIPS CPU (say, the R4400) due to the differences in the pipeline.
Oh and you are so totally correct. I forgot about that, but yes, it's all
coming back now. I remember reading about that in some MIPSPro C
documentation. Well darn. There goes my dream :-0
I guess I could still posit that some advanced form of dynamic translation
would be able to do it, but that sounds extremely daunting.
MIPS compilers were specific for a chip because such
details were not
hidden in the CPU itself, but left to the compiler to deal with.
Ugh. That doesn't sound like such a great idea, but what do I know. That's a
very weird intersection of hardware and software that I couldn't begin to
unravel.
-Swift
8:11 a.m.
On Apr 25, 2016, at 11:05 AM, Swift Griggs
<swiftgriggs at gmail.com> wrote:
On Fri, 22 Apr 2016, Sean Conner wrote:
Huh?
I know some very ancient MIPS processors had oddball required delays ("load
delay"?) that went away after. And there's the misbegotten "branch delay
slot" -- but that is part of the architecture and applies to all MIPS even long after
the reason for it was ancient history.
Of course you can generate code for new MIPS that will break on old MIPS, just like for
any other processor family that has evolved over time. But old code that would break on
new MIPS? That's news to me. Sub-optimal, yes of course, that too is true for every
processor family. I've worked for years on MIPS family systems, and always wrote or
compiled for the oldest CPU used in the product line. Upward compatibility would take
care of the rest.
Swapping chips in a system is a different issue: what you need there is not just
instruction set compatibility but also pin compatibility, and that is far less common
(again, not just in MIPS but across many CPU families. Try plugging in a Pentium in place
of a 486 and see how far you get, or an Alpha EV4 in place of an EV2, or a J-11 in place
of an F-11.
paul
One major problem with adding a faster CPU to an
SGI is the MIPS chip
itself---code compiled for one MIPS CPU (say, the R3000) won't run on
another MIPS CPU (say, the R4400) due to the differences in the pipeline.
Oh and you are so totally correct.
8:37 a.m.
On Mon, 25 Apr 2016, Paul Koning wrote:
I know some very ancient MIPS processors had oddball
required delays
("load delay"?) that went away after. And there's the misbegotten
"branch delay slot" -- but that is part of the architecture and applies
to all MIPS even long after the reason for it was ancient history.
See my other posting in this thread for details.
NB branch delay slots have been gradually disappearing too as the
architecture evolved. Branches with no delay slot (compact branches)
first appeared with the MIPS16 ISA back in ~1996, then compact jumps were
added with the MIPS16e ISA extension. Later on compact branches and jumps
reappeared in the microMIPS ISA (assembly source level compatible with the
regular MIPS ISA).
With the recent R6 architecture revision compact branches and jumps were
added to the regular ISA and delay slots removed altogether from the
microMIPS ISA (R6 breaks full backwards compatibility for pipeline
performance reasons; some old inventions were deemed too costly in terms
of die space and power consumption for a contemporary architecture in
embedded use).
This is drifting away from the scope of our mailing list though.
FWIW,
Maciej
23 Apr
23 Apr
7:45 a.m.
On 04/22/2016 01:03 PM, Swift Griggs wrote:
Remember all the accelerator boards for the Mac, Amiga, and even PCs in the
90's ? I've often wished that I could get something similar on my older SGI
systems.
Well, I seem to remember that some of the desktop SGI machines could take a
variety of CPUs. Often though they were designed for a certain performance
point and if you wanted more you bought the next model up - and when I
worked with them commercially, a lot of hardware was technically under
lease; they'd bring out a new model and throw it our way, then take the old
one away (where I was told it got sent to the crusher).
On the server side of things, they were generally pretty expandable - if
you wanted higher performance, you just added more CPUs / disks /
backplanes, rather than fitting faster versions of individual components.
So, here's the question. Is my dream likely to
ever be possible enough that
a boutique shop could pull it off and not lose their shirt on the production
costs and R&D to do it ?
I think you'd be wasting your time, even if it could be done... for a lot
of tasks the CPU isn't the limiting factor anyway - disk speed, bus
bandwidth etc. all play a part, too.
Then there's the "what's the point?" angle... I mean, why take a vintage
machine that's dog-slow in comparison to modern hardware and try to make it
slightly less dog-slow?
cheers
Jules
3162
days inactive
3166
days old
41 comments
21 participants
participants (21)
-
ard＠p850ug1.demon.co.uk -
bfranchuk＠jetnet.ab.ca -
cclist＠sydex.com -
cisin＠xenosoft.com -
cmhanson＠eschatologist.net -
echristopherson＠gmail.com -
ethan＠757.org -
ggs＠shiresoft.com -
jan＠janadelsbach.com -
jules.richardson99＠gmail.com -
kspt.tor＠gmail.com -
macro＠linux-mips.org -
mhs.stein＠gmail.com -
oltmansg＠gmail.com -
paulkoning＠comcast.net -
pete＠dunnington.plus.com -
spacewar＠gmail.com -
spc＠conman.org -
swiftgriggs＠gmail.com -
teoz＠neo.rr.com -
toby＠telegraphics.com.au