-
After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.
More OS to play with in browser
- Thread starter zuben el genub
- Start date
Rukbat
Extreme Android User
I never "wondered" what it was like to use those systems. Aside from the Amiga 500, I supported them all. (And Commodore 64, Amiga 400 and 800, Apple ][ [I still have one running], TRS 80, TRS 2, and older systems like CPM 1.4 and 2.2, and Isis.)
I still have a working laptop (AC only - the batteries are probably lumps of rust by now) with 5 MB of RAM, running DOS 5.0 and Windows 3.11. I may still have (it might have gotten lost in the move) a still-shrink-wrapped version of Windows 386.
The real fun days, though, were when, if you wanted an assembler, to write your programs in assembly, you had 2 choices - a legal pad, pencil and eraser or write your own assembler (and I wrote a few of them). We programmed right on the bare metal. And the cheapest, oldest Android phone is thousands of times more powerful than a 4040 running 8k of RAM+ROM, with the video RAM switched in and out 30 times/second. Networking? We worked one Friday - until an early breakfast on Saturday morning when we finally got it working - to get 2 computers to talk to each other, regardless of which one went first. About 8 years after DARPA had figured it out but not yet released the details.
Fun days. "Programming" these days seems to be watching kids running "program making programs" or "designing" websites that use 1998 standards and don't work (healthcare.gov, anyone?)
I still have a working laptop (AC only - the batteries are probably lumps of rust by now) with 5 MB of RAM, running DOS 5.0 and Windows 3.11. I may still have (it might have gotten lost in the move) a still-shrink-wrapped version of Windows 386.
The real fun days, though, were when, if you wanted an assembler, to write your programs in assembly, you had 2 choices - a legal pad, pencil and eraser or write your own assembler (and I wrote a few of them). We programmed right on the bare metal. And the cheapest, oldest Android phone is thousands of times more powerful than a 4040 running 8k of RAM+ROM, with the video RAM switched in and out 30 times/second. Networking? We worked one Friday - until an early breakfast on Saturday morning when we finally got it working - to get 2 computers to talk to each other, regardless of which one went first. About 8 years after DARPA had figured it out but not yet released the details.
Fun days. "Programming" these days seems to be watching kids running "program making programs" or "designing" websites that use 1998 standards and don't work (healthcare.gov, anyone?)
Joelgp83
Android Enthusiast
Hey, since you've actually done bare-metal programming, did you like that style better or worse than today's API/abstracted hardware methods?
I know typically bare metal means you have 100% control to make your hardware operate in whatever insane way you felt like, but required a LOT of knowledge about individual hardware registers and stuff, whereas modern stuff lets you program easier but doesn't let you use what you've got in unusual ways.
I know typically bare metal means you have 100% control to make your hardware operate in whatever insane way you felt like, but required a LOT of knowledge about individual hardware registers and stuff, whereas modern stuff lets you program easier but doesn't let you use what you've got in unusual ways.
Think with programming on bare metal, i.e. pure assembler, you end up with your software been very specific to whatever CPU and system architecture, however you have complete control and can do whatever you like. Think Android is a good example of not programming on bare metal, you code in Java, and it most of the time it shouldn't matter what CPU or base architecture the system has. Same with doing portable C code, etc. C and Unix or Linux were developed with portability in mind AFAIK.
...and then there's Microsoft Visual Basic, programming by numbers, where it's most definitely not on bare metal, but you still end up with something that's very specific to a system architecture and OS.
Rukbat
Extreme Android User
I prefer coding on the bare metal. I understood exactly what every part of the program was doing every moment, and could fix a bug almost immediately, becauyse I knew exactly what should have happened and the only reason it could have screwed up the way it did.
It also taught us a lot (you learned or you went into a different line of work, since we were inventing the science as we went). But Mike, it wasn't that specific. It only took me about a week to port CP/M (8080) to 6502 - which was a totally different kind of animal.
But we were also able to shoehorn a lot of code into a little space. We did an entire planetarium automation system in about 32k of ROM, split among 3 computers. Today, "Hello, World" takes a 5GB library just so you can put text on the screen. I used to get WordStar files (text, but with the high bit of some letters set for various reasons, like soft hyphen) and had to strip off the 8th bit for certain uses. I never saved the source, because it was about 10 lines of code. You ran debug, punched in the machine code and ran. The whole thing was faster than loading a compiler from storage today.
It was fun too. "That can't be done" meant "I can't figure it out, let's see if there's someone better than I am". We always figured it out. And in very small spaces too. A shoehorn was a standard programming tool, so you could cram more code into whatever RAM you had. (BASIC saves line numbers as characters, so we'd write renumbering tools, so we could change the line numbers to start at 0 with an increment of 1. Fewer digits that way. And every line had as many characters as you could cram in. Instruction:instruction:instruction: etc. CR and the next line number took at least 2 bytes that we could use for code.
We'd write code so one routine would call (or jump to) the opcode, but another routine could jump to the operand and the code would run entirely differently. (Anyone who understands assembler knows that's like pulling a rabbit out of a hat you don't have.)
We didn't know all the rules - because no one had made any yet - so we did things that can't be done. Tom Pittman started it, I think, with a 2k BASIC interpreter. Dr. Dobbs (Journal of Calisthenics and Orthodontia - Running Light without Overbyte) ran a contest for the smallest interpreter anyone could write and someone got it down to a lot less than 2k. (Guy with a Chinese name - I can't remember it.) Reading that code taught me how to write interpreters.
Programming was fun then - if you found a way to do something that everyone said couldn't be done, you didn't write an app and charge for it, you published the source for everyone to play with - like an early Sourceforge or git. Andrew wouldn't invent the term "shareware" for another 10 years or more.
But it was easier. I learned 8080 in a couple of days. (I already knew programming.) And I mean all 200 (about) opcodes. And remembered most of them in first octal, then when we started using hex, in hex.
Had to do a monitor (kind of a primitive command line interpreter) on an 8048 - no compare instruction, so how do you compare the input character with your list of operations characters? Figured that one out too.
Assemblers? At the stationery store. Other people called them legal pads. We knew the difference between one pass and two pass assemblers, because we WERE the assemblers. If you wanted the computer to assemble your code, you'd have to write the assemble first.
Then people came out with things like compiled languages, Mark Williams came out with a great C compiler and, not far behind, Microsoft came out with theirs - with a bug that made you rewrite the assembler file before assembling it. (I guess they were trying to be IBM. One of the error codes in one of IBM's Fortran compiler error listing said something to the effect of "this is not a bug in your code, it's a bug in our compiler".)
Oh, and I had hair, teeth, could hear and see, even bend over far enough to touch my knees ... anyone have a spare 30 year old body lying around? Just back up the memories before rebuilding me, they were - and still are - good ones.
Mike - do you ever get down to Kowloon? If you do, go to the Space Museum - it's a couple of blocks east of the ferry to the island. If they're running a recorded show, you'll see one of my early projects. We automated that thing back in 1978. Done entirely in 8080 (but we cheated, we used an assembler). Strange things for the time (that "couldn't be done"). Like a 400 foot long data bus done in ribbon cable (with no shielding - and run in the same trough as the main, noisy, power cables). Like controlling the kilowatt arc lamp in the projector with SCRs the size of your thumbnail. (They were on heatsinks because we didn't want to give anyone who saw them running in air a heart attack.) Fun times.
It also taught us a lot (you learned or you went into a different line of work, since we were inventing the science as we went). But Mike, it wasn't that specific. It only took me about a week to port CP/M (8080) to 6502 - which was a totally different kind of animal.
But we were also able to shoehorn a lot of code into a little space. We did an entire planetarium automation system in about 32k of ROM, split among 3 computers. Today, "Hello, World" takes a 5GB library just so you can put text on the screen. I used to get WordStar files (text, but with the high bit of some letters set for various reasons, like soft hyphen) and had to strip off the 8th bit for certain uses. I never saved the source, because it was about 10 lines of code. You ran debug, punched in the machine code and ran. The whole thing was faster than loading a compiler from storage today.
It was fun too. "That can't be done" meant "I can't figure it out, let's see if there's someone better than I am". We always figured it out. And in very small spaces too. A shoehorn was a standard programming tool, so you could cram more code into whatever RAM you had. (BASIC saves line numbers as characters, so we'd write renumbering tools, so we could change the line numbers to start at 0 with an increment of 1. Fewer digits that way. And every line had as many characters as you could cram in. Instruction:instruction:instruction: etc. CR and the next line number took at least 2 bytes that we could use for code.
We'd write code so one routine would call (or jump to) the opcode, but another routine could jump to the operand and the code would run entirely differently. (Anyone who understands assembler knows that's like pulling a rabbit out of a hat you don't have.)
We didn't know all the rules - because no one had made any yet - so we did things that can't be done. Tom Pittman started it, I think, with a 2k BASIC interpreter. Dr. Dobbs (Journal of Calisthenics and Orthodontia - Running Light without Overbyte) ran a contest for the smallest interpreter anyone could write and someone got it down to a lot less than 2k. (Guy with a Chinese name - I can't remember it.) Reading that code taught me how to write interpreters.
Programming was fun then - if you found a way to do something that everyone said couldn't be done, you didn't write an app and charge for it, you published the source for everyone to play with - like an early Sourceforge or git. Andrew wouldn't invent the term "shareware" for another 10 years or more.
But it was easier. I learned 8080 in a couple of days. (I already knew programming.) And I mean all 200 (about) opcodes. And remembered most of them in first octal, then when we started using hex, in hex.
Had to do a monitor (kind of a primitive command line interpreter) on an 8048 - no compare instruction, so how do you compare the input character with your list of operations characters? Figured that one out too.
Assemblers? At the stationery store. Other people called them legal pads. We knew the difference between one pass and two pass assemblers, because we WERE the assemblers. If you wanted the computer to assemble your code, you'd have to write the assemble first.
Then people came out with things like compiled languages, Mark Williams came out with a great C compiler and, not far behind, Microsoft came out with theirs - with a bug that made you rewrite the assembler file before assembling it. (I guess they were trying to be IBM. One of the error codes in one of IBM's Fortran compiler error listing said something to the effect of "this is not a bug in your code, it's a bug in our compiler".)
Oh, and I had hair, teeth, could hear and see, even bend over far enough to touch my knees ... anyone have a spare 30 year old body lying around? Just back up the memories before rebuilding me, they were - and still are - good ones.
Mike - do you ever get down to Kowloon? If you do, go to the Space Museum - it's a couple of blocks east of the ferry to the island. If they're running a recorded show, you'll see one of my early projects. We automated that thing back in 1978. Done entirely in 8080 (but we cheated, we used an assembler). Strange things for the time (that "couldn't be done"). Like a 400 foot long data bus done in ribbon cable (with no shielding - and run in the same trough as the main, noisy, power cables). Like controlling the kilowatt arc lamp in the projector with SCRs the size of your thumbnail. (They were on heatsinks because we didn't want to give anyone who saw them running in air a heart attack.) Fun times.
Here's quite an unusual 8-bit micro from the UK that you can run in your browser, the Jupiter Ace from 1982.
Jupiter Ace Resource Site - zzace09 Java Jupiter Ace Emulator
...unusual because it used Forth as its language and not Basic. The company that made it was only around for a few months.
Jupiter Ace Resource Site - zzace09 Java Jupiter Ace Emulator
...unusual because it used Forth as its language and not Basic. The company that made it was only around for a few months.
Yeh I've been to the Space Museum in Tsim Sha Tsui. I'm going to HK again in about 3 months. I'll have to keep a look out for that. :thumb: ..in the early '80s i was working for a coin-op video game company, which was basically converting cabinets to the newer games by changing out the boards, with bootlegged ROMs of course.
Rukbat
Extreme Android User
If you look at the console, you'll see it's all LED displays, not the calibrated knobs that Zeiss used. Intel 8279 display/keypad controllers. (We were among the first to get samples.) The keypads were little 10 key pads, and you entered numbers like a calculator. I don't remember how many little display/keypad sets we put on that console, but at the time it seemed like millions. We had stacks of them all over the lab. They did everything from the light levels in the dome (there were 4 color channels, so you could simulate anything from sunrise to noon to dusk) to angles at which the sky appeared, to how fast the moon was moving.
Funny day during the project. We were at Zeiss in Germany, integrating the console with their projector. There was a power line glitch. There wasn't one single IC left on any board - not even epoxy. Just pins sticking out of sockets. We had spares, but not for every single IC in the system - and this was during the 7400 crunch, when you couldn't buy ICs. We had someone fly us a set in checked baggage from the factory in Texas (can't remember the name now, not TI - it started with a D). Most expensive ICs ever used in any project, probably, except for the spares flown to the moon.
As far as Forth, no - I'm too old to stand on my head to write code. But I've used Forth, Stoic, MacForth, etc. You can write some pretty small powerful programs when each function is just an address.
Funny day during the project. We were at Zeiss in Germany, integrating the console with their projector. There was a power line glitch. There wasn't one single IC left on any board - not even epoxy. Just pins sticking out of sockets. We had spares, but not for every single IC in the system - and this was during the 7400 crunch, when you couldn't buy ICs. We had someone fly us a set in checked baggage from the factory in Texas (can't remember the name now, not TI - it started with a D). Most expensive ICs ever used in any project, probably, except for the spares flown to the moon.
As far as Forth, no - I'm too old to stand on my head to write code. But I've used Forth, Stoic, MacForth, etc. You can write some pretty small powerful programs when each function is just an address.
nickdalzell
Extreme Android User
although it is 'fictional' the OS used in Jurassic Park is online and is quite convincing, although it would look better on a devoted fan's mockup of an old SGI computer with a CRT monitor. it just looks 'wrong' on a modern laptop or tablet.
JPOS Project Nedryland - Jurassic Park - Online System
JPOS Project Nedryland - Jurassic Park - Online System