Does anybody remember The Juggler? The Amiga 500: now in your browser.
December 12, 2013 9:03 PM Subscribe
Christian Stefansen has made Amiga Workbench 1.3 available in Chrome via the Portable Native Client. For those of you rode on the third wheel of the 16-bit operating system wars, this is quite a treat, in addition to being a nifty proof-of-concept. More info on the technology here.
Cool! Now how do I get it to play Shadow Of The Beast?
posted by sourwookie at 9:26 PM on December 12, 2013 [4 favorites]
posted by sourwookie at 9:26 PM on December 12, 2013 [4 favorites]
A couple of days ago I stumbled across a Cray X-MP emulator on this Cray hobbyist site. If there's a Valhalla of programming, I'm sure the people who code this stuff will be there one day.
posted by crapmatic at 9:30 PM on December 12, 2013 [1 favorite]
posted by crapmatic at 9:30 PM on December 12, 2013 [1 favorite]
a Cray X-MP emulator
Having just re-read Jurassic Park, I can't overstate how excited I am to discover that the box I'm typing on is powerful enough to emulate a computer that could purportedly genetically engineer dinosaurs.
posted by justsomebodythatyouusedtoknow at 9:47 PM on December 12, 2013 [5 favorites]
Having just re-read Jurassic Park, I can't overstate how excited I am to discover that the box I'm typing on is powerful enough to emulate a computer that could purportedly genetically engineer dinosaurs.
posted by justsomebodythatyouusedtoknow at 9:47 PM on December 12, 2013 [5 favorites]
Wait, this is Unix! I know this!
posted by flabdablet at 9:51 PM on December 12, 2013 [6 favorites]
posted by flabdablet at 9:51 PM on December 12, 2013 [6 favorites]
AmigaOS really was a nice design in lots of ways. The only part of it I considered regrettably ugly was the fact that, since Exec was all assembly code (really very nice assembly code, too - 68000 is not a bad architecture at all) while so much of AmigaDOS had been implemented using a fairly simple-minded BCPL compiler, there was this frequent requirement for format conversion between BCPL word addresses and 68000 native addresses.
Then again, sweet efficient kernels are really not that hard to design if you just completely give up on any kind of sandboxing for user processes.
posted by flabdablet at 10:24 PM on December 12, 2013 [2 favorites]
Then again, sweet efficient kernels are really not that hard to design if you just completely give up on any kind of sandboxing for user processes.
posted by flabdablet at 10:24 PM on December 12, 2013 [2 favorites]
of course, the javascript version of has been around for a while. Even runs on phones, terrifyingly.
posted by jaymzjulian at 10:46 PM on December 12, 2013 [1 favorite]
posted by jaymzjulian at 10:46 PM on December 12, 2013 [1 favorite]
Amiga Unix
Oh man. My first use of Unix was on a Macintosh Centris 650. I remember feeling quite superior to the shlubs stuck using the A3000 hardware.
posted by peeedro at 11:34 PM on December 12, 2013
Oh man. My first use of Unix was on a Macintosh Centris 650. I remember feeling quite superior to the shlubs stuck using the A3000 hardware.
posted by peeedro at 11:34 PM on December 12, 2013
I'm not sure this is really emulating an Amiga. I've been clicking around for several minutes and haven't been able to trigger guru meditation once....
posted by samworm at 12:25 AM on December 13, 2013 [2 favorites]
posted by samworm at 12:25 AM on December 13, 2013 [2 favorites]
Can anyone get the Cloanto add-ins to work or even install?
posted by GallonOfAlan at 2:09 AM on December 13, 2013
posted by GallonOfAlan at 2:09 AM on December 13, 2013
> so much of AmigaDOS had been implemented using a fairly simple-minded BCPL compiler …
I don't think that was the problem. TRIPOS (→ AmigaDOS) had been around a long time, and the CAOS operating system wasn't ready. The Amiga team had to wedge the two together, and didn't have time to do it right. TRIPOS/BCPL always got an unnecessarily bad rap amongst Amiga people.
posted by scruss at 1:30 PM on December 13, 2013
I don't think that was the problem. TRIPOS (→ AmigaDOS) had been around a long time, and the CAOS operating system wasn't ready. The Amiga team had to wedge the two together, and didn't have time to do it right. TRIPOS/BCPL always got an unnecessarily bad rap amongst Amiga people.
posted by scruss at 1:30 PM on December 13, 2013
> Can anyone get the Cloanto add-ins to work or even install?
Yep, no trouble. It may be possible to get this to run arbitrary roms/disks without forking over the $1 to Cloanto if you dig in "Advanced Options". I should've dug deeper.
posted by scruss at 1:52 PM on December 13, 2013
Yep, no trouble. It may be possible to get this to run arbitrary roms/disks without forking over the $1 to Cloanto if you dig in "Advanced Options". I should've dug deeper.
posted by scruss at 1:52 PM on December 13, 2013
Would have much preferred AmigaDOS 2.x. I loved the grey and blue. Found it easy on my eyes.
posted by juiceCake at 12:19 PM on December 14, 2013
posted by juiceCake at 12:19 PM on December 14, 2013
Man! It's been a long time since I thought of BCPL. I studied at University a loooonnng time ago... Funny, I never knew the Amiga used it!
posted by BillW at 7:08 PM on December 14, 2013
posted by BillW at 7:08 PM on December 14, 2013
TRIPOS/BCPL always got an unnecessarily bad rap amongst Amiga people.
I have no axe to grind against either, but I do remember being frequently irritated by the need to convert back and forth between BPTRs and raw memory addresses while using the AmigaDOS API (on the Amiga, a BPTR was a 32-bit-aligned raw memory address shifted right by two bits).
The reason for the distinction between the BPTRs used inside AmigaDOS and the raw memory addresses used by Exec and application programs is that BCPL abstracts RAM, treating memory as a global vector of word-addressable machine words (32-bit words, in the case of the compiler used for AmigaDOS).
BCPL defines vectors in such a way that adjacent items have indexes that differ by exactly 1. It also doesn't have types, so it can't make arithmetic work different ways for different things; if you add 1 to a BCPL variable, the value you end up storing into the memory allocated to that variable always gets incremented by 1. And it doesn't have a genuine pointer-dereference operation, only the ability to index the global vector.
B is essentially BCPL with curly braces, and C is essentially B with types. In C you can still add the integer value 1 to a pointer into an array of 32-bit ints to get a pointer to the next item; but on a byte-addressed machine like the 68000, the compiler will actually emit code to add 4 to the contents of a pointer variable that it implements as a raw machine address. It can do this because it knows the types and sizes not only of the pointers themselves but of the things the pointers point to.
In general it's hard to say whether a C compiler will emit more or less code than a BCPL compiler doing logically equivalent pointer manipulations, but the fact that a C compiler is free to implement pointers as raw machine addresses does mean that C-derived APIs tend to be a little tidier than BCPL-derived equivalents.
posted by flabdablet at 2:37 AM on December 15, 2013
I have no axe to grind against either, but I do remember being frequently irritated by the need to convert back and forth between BPTRs and raw memory addresses while using the AmigaDOS API (on the Amiga, a BPTR was a 32-bit-aligned raw memory address shifted right by two bits).
The reason for the distinction between the BPTRs used inside AmigaDOS and the raw memory addresses used by Exec and application programs is that BCPL abstracts RAM, treating memory as a global vector of word-addressable machine words (32-bit words, in the case of the compiler used for AmigaDOS).
BCPL defines vectors in such a way that adjacent items have indexes that differ by exactly 1. It also doesn't have types, so it can't make arithmetic work different ways for different things; if you add 1 to a BCPL variable, the value you end up storing into the memory allocated to that variable always gets incremented by 1. And it doesn't have a genuine pointer-dereference operation, only the ability to index the global vector.
B is essentially BCPL with curly braces, and C is essentially B with types. In C you can still add the integer value 1 to a pointer into an array of 32-bit ints to get a pointer to the next item; but on a byte-addressed machine like the 68000, the compiler will actually emit code to add 4 to the contents of a pointer variable that it implements as a raw machine address. It can do this because it knows the types and sizes not only of the pointers themselves but of the things the pointers point to.
In general it's hard to say whether a C compiler will emit more or less code than a BCPL compiler doing logically equivalent pointer manipulations, but the fact that a C compiler is free to implement pointers as raw machine addresses does mean that C-derived APIs tend to be a little tidier than BCPL-derived equivalents.
posted by flabdablet at 2:37 AM on December 15, 2013
I consider all of those to be BCPL features and C flaws, flabdablet. But then, the first compiled language I ever learned was BCPL.
posted by scruss at 10:22 AM on December 18, 2013
posted by scruss at 10:22 AM on December 18, 2013
BCPL features and C flaws
BCPL's data model is indeed elegantly sparse. On the other hand it's a relatively poor fit to modern machine architectures, all of which treat RAM as a logical array of bytes, not machine words.
I guess it's perfectly legitimate to view that as an aesthetic flaw in machine architecture as well and retreat to the purity of the BCPL model, but I personally prefer the C compromise: put just enough type knowledge into your language to make it map neatly over whatever underlying architecture you're working with. That seems a sensible decision, to me, for something designed as a systems programming language.
Early C source code was also quite spare and elegant. Only once ANSI got its hands on C and started trying to turn it into a proper high-level language rather than a really useful portable assembler did the clumsy ugliness set in.
posted by flabdablet at 6:50 PM on December 18, 2013
BCPL's data model is indeed elegantly sparse. On the other hand it's a relatively poor fit to modern machine architectures, all of which treat RAM as a logical array of bytes, not machine words.
I guess it's perfectly legitimate to view that as an aesthetic flaw in machine architecture as well and retreat to the purity of the BCPL model, but I personally prefer the C compromise: put just enough type knowledge into your language to make it map neatly over whatever underlying architecture you're working with. That seems a sensible decision, to me, for something designed as a systems programming language.
Early C source code was also quite spare and elegant. Only once ANSI got its hands on C and started trying to turn it into a proper high-level language rather than a really useful portable assembler did the clumsy ugliness set in.
posted by flabdablet at 6:50 PM on December 18, 2013
« Older Lynch on the Air | Fixing Windows 8 Newer »
This thread has been archived and is closed to new comments
You, me, this entire universe just a simulation in some mega-firefox-browser in the bedroom of an inter-dimensional teen age boy.
posted by sammyo at 9:10 PM on December 12, 2013