P2 Self Hosting OS
Cluso99
Posts: 18,069
Thought I'd share some reasons I think the P2 is a great candidate for a self-hosting micro.
History:
Many of you were not even around before the PC, so let me share what it was like in the 70's. Mini-computers were becoming mainstream. I'll refer to the Friden/Singer/ICL System Ten mini because that is what I worked on from 1974 onwards.
In the early 70's a mini came with...
10K-110K of 6-bit core memory 2.2us or 3.3us cycle time, cost $20K for 10K
1-10 10MB removable Disk Drives, although a modified 2x4MB version came out where two heads were removed and the disk pack came in two halves. Cost in 1976 $16K for 1x10MB disk drive - the size of a washing machine. Disk packs were ~$500 ea - 19" 6 platter 10 surfaces.
Video terminal 20x80 characters black/grey-white $4K
Printer 200LPM (lines per minute) ~$16K and a crane to lift it!
A typical small system would typically start at 20K core, 2 x 10MB disk drives, 2 partitions (two separate programs run concurrently - similar to a COG but software time-shared), 2 video terminals and a printer. Cost ~$150K and maintenance typically 20+% of original cost pa.
Now add a specialised air-conditioned, temperature controlled 20C max, humidity controlled, specialised voltage controller, computer room. The disk drives took 40A @ 240Vac on power up to spin the disks at 100mph.
So a typical program had 10KB allocated to DMF (Disk Management Facility = OS), and each program would run in its' own memory of 5K-10K of core memory. Code editing was disk based using a video terminal and an editting program. The DMF was supplied by the mini vendor and that included the editor, assembler (yes, all code was written in assembler, including the DMF), and maintenance programs.
Software packages could be purchased at expensive rates, but many users wrote their own, either in-house, of by contract programmers.
Just for reference, the assembler instruction for the System Ten were
A/S/M/D/FN (add, subtract, multiply, divide, form numeric)
MC/MN/X/C/E (move character, move numeric, exchange, compare, edit)
BC (branch including link=call variations)
R/W (read and write to disc/tape/video/printer and POS point-of-sale terminals)
SM (restricted specialised control instruction)
MA/AA (move address and add address were added later)
Worthy of note is that each instruction was dual operand, so everything was memory to memory. Each operand could address it's own 10K (think cog) or common (think hub), and one of three index registers could optionally modify this address. Later, an optional indirect addressing bit was added for each operand.
MC/MN/X/C/E could move from 1 to 100 characters in one instruction.
A/S could add/subtract 1-10 digits to/from 1-10 digits (all in decimal - the memory was also addressed in decimal only)
M/D were special as overflow was not possible. The multiply took 1-10 digits multiplied by 1-10 digits and the result would be stored in the second operand for a length that was the sum of both operands length. You needed to reserve the extra space required. Divide worked in reverse, giving a result and a remainder.
General...
So, where am I going with this?
Well, the P2 plus an SD card or two has way more power than this and what was done on these minis was absolutely amazing. Of course it was character based, and no color. So, the P2 can absolutely self-host an OS and editor/compiler. It has way more power than even the CPM systems of the 80's.
BTW I already have a P1 with 512KB SRAM and uSD that runs CPM (RamBlade) and I've built an OS for the P1. On P2 - it's a no-brainer
And do I plan on doing a SystemTen emulation on the P2? You betcha! But it will be the later System 25 which I've done on a PC using 486 assembler in 1990 (fully validated).
History:
Many of you were not even around before the PC, so let me share what it was like in the 70's. Mini-computers were becoming mainstream. I'll refer to the Friden/Singer/ICL System Ten mini because that is what I worked on from 1974 onwards.
In the early 70's a mini came with...
10K-110K of 6-bit core memory 2.2us or 3.3us cycle time, cost $20K for 10K
1-10 10MB removable Disk Drives, although a modified 2x4MB version came out where two heads were removed and the disk pack came in two halves. Cost in 1976 $16K for 1x10MB disk drive - the size of a washing machine. Disk packs were ~$500 ea - 19" 6 platter 10 surfaces.
Video terminal 20x80 characters black/grey-white $4K
Printer 200LPM (lines per minute) ~$16K and a crane to lift it!
A typical small system would typically start at 20K core, 2 x 10MB disk drives, 2 partitions (two separate programs run concurrently - similar to a COG but software time-shared), 2 video terminals and a printer. Cost ~$150K and maintenance typically 20+% of original cost pa.
Now add a specialised air-conditioned, temperature controlled 20C max, humidity controlled, specialised voltage controller, computer room. The disk drives took 40A @ 240Vac on power up to spin the disks at 100mph.
So a typical program had 10KB allocated to DMF (Disk Management Facility = OS), and each program would run in its' own memory of 5K-10K of core memory. Code editing was disk based using a video terminal and an editting program. The DMF was supplied by the mini vendor and that included the editor, assembler (yes, all code was written in assembler, including the DMF), and maintenance programs.
Software packages could be purchased at expensive rates, but many users wrote their own, either in-house, of by contract programmers.
Just for reference, the assembler instruction for the System Ten were
A/S/M/D/FN (add, subtract, multiply, divide, form numeric)
MC/MN/X/C/E (move character, move numeric, exchange, compare, edit)
BC (branch including link=call variations)
R/W (read and write to disc/tape/video/printer and POS point-of-sale terminals)
SM (restricted specialised control instruction)
MA/AA (move address and add address were added later)
Worthy of note is that each instruction was dual operand, so everything was memory to memory. Each operand could address it's own 10K (think cog) or common (think hub), and one of three index registers could optionally modify this address. Later, an optional indirect addressing bit was added for each operand.
MC/MN/X/C/E could move from 1 to 100 characters in one instruction.
A/S could add/subtract 1-10 digits to/from 1-10 digits (all in decimal - the memory was also addressed in decimal only)
M/D were special as overflow was not possible. The multiply took 1-10 digits multiplied by 1-10 digits and the result would be stored in the second operand for a length that was the sum of both operands length. You needed to reserve the extra space required. Divide worked in reverse, giving a result and a remainder.
General...
So, where am I going with this?
Well, the P2 plus an SD card or two has way more power than this and what was done on these minis was absolutely amazing. Of course it was character based, and no color. So, the P2 can absolutely self-host an OS and editor/compiler. It has way more power than even the CPM systems of the 80's.
BTW I already have a P1 with 512KB SRAM and uSD that runs CPM (RamBlade) and I've built an OS for the P1. On P2 - it's a no-brainer
And do I plan on doing a SystemTen emulation on the P2? You betcha! But it will be the later System 25 which I've done on a PC using 486 assembler in 1990 (fully validated).
Comments
I don't like these types of computers as I thing the OS gets in the way of what I'm trying to program. I just want to move the data from device a to device b. Turn this light on or display this data on a screen.
Most of the time they need an operating system to setup multi-tasking which the micro controllers they are using doesn't support. By using an operating system they can build application that can do more things at one time. The P2 has that already built in and doesn't need an operating system.
Mike
PS: I think it would be fun to build an operating system for the P2 just not very useful in the end.
With the P2 having so much capability, I am thinking maybe some kind of software that allows you to run a built script that turns lights on/off, moves data between devices, …
Since there is a ton of objects , in the OBEX, make them work in a script file of some sort. Attach something to a Pxx, and then fire it up within your script. I think an OS of that sort would be very beneficial. I think Chip mentioned that he wanted to have Spin2 run on the P2, that would fit in with the P2 OS strategy also.
Never even considered running spreadsheets, word processors, or anything like that, on the P2. Just my 2 cents.
Ray
But I think P2 may be better suited as it has so many more features, and of course that RAM!
I'm not talking about *nix or windows as far as an OS goes. Just a simple DOS/CPM like base to enable launching of programs that include being able to edit and compile programs right on the P2. So a whole development system.
Now, one may say they can have that on a Pi. But, those ARM chips don't let you get at the microcontroller features. Things like ADC, DAC, those smart pins, etc. And their OSes have interrupts. P2 doesn't need these, and you can run "your" program in a seperate cog(s) while the OS may still stay-resident.
You can test out your program while still having the OS present, and debug it too.
Anyway, those are my thoughts.
There are Arduinos used to do simple things that micros do best, interfacing to sensors and motors. But to develop the code one uses a PC (or a RPi perhaps) and every iteration requires a download, reset, and run. Now, what if you could write your program also on the Arduino. Now you don’t need to download as it’s already there.
Now let’s look at doing this on a P2...
Connect a keyboard, mouse maybe, and a monitor. With a simple OS, and edit and compile programs, now you can edit/compile/run all on the same P2.
Taking this a little further, cogs for the keyboard, monitor and running the OS, editor, compiler, do your compile and then leaving that running, load another cog(s) with your code and start it. You don’t have to switch keyboards and monitors. This whole process is so much cleaner, simpler, and cheaper too.
And no risk of viruses here either, and security too.
Seems just what schools should be looking for!
And to take it further, you’ve developed a widget to interface/control some factory device. Something goes wrong and you need to go onsite to locate the problem. With this scenario you can interact with the device more easily, and you could edit and recompile and test your code all on the P2. And remember, most of those those other micros need to reprogram their internal flash every time to try a new test while we just load RAM. They have a high, but limited program cycles.
BTW It’s not a PC replacement, and it’s never going to run those bloatware OSes or programs. It’s not a RPi and it’s not going to run Linux although no doubt someone will try.
IMHO the P2 has a future in this that ARM micros just can’t match, while it’s never going to be an ARM either.
Who says one can't access the internet on a P2?
FAT32 support on uSD plus commands such as copy, del, diff,dir, dircpm,dnload, dumpfil, dumphub, flash, free, getcpm, getfat, help, lf, ls, mapcpm, putcpm, putfat, reboot, ren, run, type, used, ver.
You’ll note some CPM references - because you’ll be able to jump back and forth between CPM and the FAT32 OS. We will need a P2 hosted compiler tho.
-Phil
Sure I later on used PropTool, but hell yeah, @mpark got me hooked somewhen in the last century.
I also see a decline of Desktop Computers. Lots of people I know got rid of them, because their smartphones fit all their needs.
Me myself and I on the other hand are desperate about the situation. I can handle mainframes, but am to stupid to use smart phones. Or - hmm - never liked them in the first place, starting with the brief case size A-Net my company made me to carry around.
Since a decade now I am bound to use Windows, and am slowly beginning to hate computers.
There are tons of services/background stuff running and sometimes my computers react as fast as molasses, update on me while waiting for a urgent conference call, it is just wrong.
And Linux is not much better there, overall it is a man made disaster. So alike chip I see some networked P2 system (aka multiple P2's working together) as a viable way to have a responsive system, booting fast and doing what I need to do.
Sadly I am right now hammered with work and have no Prop time at all, but the ringnet was working with my rev A's and will work nicely with rev B/C as soon as I can put some time into it.
With Hyper-Ram used for the Video Buffer(s) there is enough HUB-RAM left for some nice Editor/Compiler/Loader. Mail might be easy, file upload/download easy, something like RDP more complicated, a non Text based browser basically out of scope.
So yes you need your cellphone/tablet for browsing and the P2's for easy, fast development. I am all into that and my fingers are itching to combine @rogloh's Video driver, @garryj's USB Mouse/KBD, @cheezus, SD driver and some ANSI decoding to provide some TUI based Windows for multiple serial Terminals connected to a P2...
Enjoy!
Mike
Source Code still needs to be backed up externally, and data sheets read, and test reports written...Users are also used to hover & Find Declaration type support frameworks.
Plus, everyone will have varying ideas about what minimal system is needed: eg What screen resolution do you choose ? (This steals from user RAM)
Then, do you use one, or two, P2's ? - Packing everything into one P2, will leave only a fraction of a usable P2 for the user.
That said, google finds this :
"About Turbo Pascal 1.0: Turbo Pascal version 1.0 shipped on one floppy disk. The total number of files on the disk was 10. Total floppy disk space used was 131,297 bytes.
Total size of TURBO.COM (including the integrated development environment with compiler, Wordstar-style editor, and run-in-memory system) was 33,280 bytes."
&
"The entire Turbo Pascal 3.02 executable--the compiler and IDE--was 39,731 bytes"
Older BASIC systems were even smaller, but did not compile code.
A more modern equivalent would be Project Oberon, uses modest hardware specifications: memory (1Mb), screen resolution (1024 x 768) and colour depth (black and white).
Yes. I remember TurboPascal well. I still have the boxed set of TurboPascal 5.0 with ASMx86 and IIRC C too.
What was done on those minis was amazing! The System Ten at Blackwoods in the late 70's had 200KB total core memory, 2 @ 10MB + 2 @ 40MB disk drives and supported 35 video terminals doing online order entry, inventory management of well over 100,000 items, invoicing, etc. There were numerous Centronics printers located in the warehouse printing picking slips for the local warehouse section. All this was real-time updating.
And all this was written in assembler by a handful of programmers
That sounds a lot like the hardware, software, and application I worked on back in the late 70's when I was a programmer at Varian Canada. They produced a nice minicomputer for their communication systems and wanted to use it as a general purpose system for order entry, book keeping, etc.
While I do not think having a self hosting system for the P2 is a necessity I do think it would be a useful addition, particularly in the education and hobbyist area. We might be surprised to find it turns out to be useful in other areas or for other things.
I think David was meaning a 'x86', rather than a genuine '8086' chip.
Would users in 2020+ tolerate a 8086 MHz, DOS/BIOS/VGA Text level performance, when they can get a RaspPi Zero W for ~ $10 ?
ersmith did some great work in JIT emulation of RISC-V using P2, but that only has to emulate RISC V opcodes, and does not need to emulate interrupts and memory mapped IO.
Then there is size, eg FreeDOS reports this
✓ 10MB to install minimal FreeDOS
✓ 81MB to install everything
That's getting large by P2 standards ?
https://arstechnica.com/information-technology/2014/07/dos-boot-ars-spends-a-day-working-in-freedos/
I write/edit code on a mobile device that is wirelessly linked to the MCU. Make it IoT.
> I love the self hosting idea but why bother having to connect a keyboard and monitor?
>
> I write/edit code on a mobile device that is wirelessly linked to the MCU. Make it IoT.
Are you up for writing the code to run the screen/keyboard from/to wifi on an android phone/tablet and iphone/ipad? I have no idea about doing this part or if there are apps that can do this.
I really like the open-source 920
Now, if we are talking about a setup like an Activity Board WX with a WX module, maybe a concept like that for the P2 that has an OS, would be an interesting start.
So, lets say the P2 has a WX module, maybe you can connect up via WiFi, and with a program like mincom or Tera Term, you gain access to the P2, and you can do some things with it. Also the same concept could work if the P2 had a comm port for an external connection, again using minicom or Tera Term to communicate with the P2.
Ray
They had a "Web-IDE" via the ESP8266.
Not too familiar with what's out there but surely this exists for other platforms (?)