Something went wrong in the last 50 years,
msrobots
Posts: 3,709
we all know it.
And I am NOT talking about the general state of the world, just about computer and software.
I am not sure when it happend, personally I think at the time when the IBM PC came out. Some people I worked with date it back 10 years earlier. And some say we never should have climbed down from the trees.
One Forum Member (Ale?) mentioned OBERON, and since N.Wirth was one of my Professors way back when, I looked a bit more into it.
Like I disagreed a lot with him while beeing his studend, I still disagree with his solution that just a strongly typed language is worth to exist, but anyways this is a very good read,
http://cr.yp.to/bib/1995/wirth.pdf
It is from 1995 but the situation got way worse since then.
We talked about this in other threads, @Chip mentioned it a couple of times, and a lot of people chimed in, but it was always OT.
So that is what this thread is for, to discuss the problem of software bloat and weekly updates and spying software and having 70 processes running on your computer for - who knows what.
But I am more interested in ways OUT of that situation, not more examples of who does what or linux and windows and free versus ... you get the gist.
What I would like to discuss here is what the minimum requirements for a stable system would be and how many P2s one would need to build one.
@Heater might get CPM running, I might be able to get COBOL running via PropGCC, but that is to far back. To make a usable system we need Internet access.
A full blown web-browser is probably not doable. Maybe a very simple text based one like lyncs?
If TAQOZ does it make into the boot rom there would be a way to provide system services to user programs. Since @Peter supports WORDS defined in PASM one can call back anyone from FORTH and for the other way around I guess @Peter can use his redirection for input and output he already has, to support a text-scriptable system call from any language running as user program.
I also hope that @peter includes his serial multi P1 protocol in the boot TAQOZ.
Thoughts?
Mike
And I am NOT talking about the general state of the world, just about computer and software.
I am not sure when it happend, personally I think at the time when the IBM PC came out. Some people I worked with date it back 10 years earlier. And some say we never should have climbed down from the trees.
One Forum Member (Ale?) mentioned OBERON, and since N.Wirth was one of my Professors way back when, I looked a bit more into it.
Like I disagreed a lot with him while beeing his studend, I still disagree with his solution that just a strongly typed language is worth to exist, but anyways this is a very good read,
http://cr.yp.to/bib/1995/wirth.pdf
It is from 1995 but the situation got way worse since then.
We talked about this in other threads, @Chip mentioned it a couple of times, and a lot of people chimed in, but it was always OT.
So that is what this thread is for, to discuss the problem of software bloat and weekly updates and spying software and having 70 processes running on your computer for - who knows what.
But I am more interested in ways OUT of that situation, not more examples of who does what or linux and windows and free versus ... you get the gist.
What I would like to discuss here is what the minimum requirements for a stable system would be and how many P2s one would need to build one.
@Heater might get CPM running, I might be able to get COBOL running via PropGCC, but that is to far back. To make a usable system we need Internet access.
A full blown web-browser is probably not doable. Maybe a very simple text based one like lyncs?
If TAQOZ does it make into the boot rom there would be a way to provide system services to user programs. Since @Peter supports WORDS defined in PASM one can call back anyone from FORTH and for the other way around I guess @Peter can use his redirection for input and output he already has, to support a text-scriptable system call from any language running as user program.
I also hope that @peter includes his serial multi P1 protocol in the boot TAQOZ.
Thoughts?
Mike
Comments
In this context, Project Oberon looks interesting.
Given the size of FPGA system hosting this now, this likely could fit into 1 P2 - certainly 1 P2, with XIP support via OctalSPI - the ultimate question then is one of 'what performance ?'.
Like many users here, I cut my programming teeth on Fortran and BASIC. I still think BASIC is a good introductory programming language. But it doesn't meet modern functional requirements.
I'll have to read Wirth's paper. I like the title, "A Plea for Lean Software." Based on the title alone, I think he would like Spin!
-Phil
yes @jmg that is exactly the question. What should a stable system contain.
And with stable system I try to describe a computer system you could have at home, but it will not need to get updated every few weeks and does not run tons of programs/services you never needed or asked for.
Some sort of stable island in the constantly changing software world, a save haven to put your personal stuff and be sure it will stay there.
To me the jump from the P1 to the P2 is comparable to my jump from a 8-bit Atari to 16-bit 512ST. I miss the 68000 assembler.
And there is where I agree with N.Wirth, from then on things got bloated.
My personal hope now is that one can fork from there and take a different approach. OBERON shows very thought thru design rules, breaking with the 'classic' desktop behavior.
It basically even supports SPINs object concept, just WITH the ability to call procedures out of other objects even if they are not sub-objects, but parent ones.
But my main question is still what a minimal useful stable system would need to be useful enough.
Mike
Looking at this computer today I know one thing wrong, java.
The biggest process running just now is the InteliJ IDE. It's using 1.4GB while editing 4 small Scala files.
The next biggest offender in the bloat department is Google Chrome. Currently hogging 1.1GB. But I'm inclined to mostly forgive that. I have 25 tabs open quite a few of which are applications in their own right. For example, email, 3d rendering, various dashboards.
Third up is the Visual Studio Code IDE. At a paltry 250MBytes
After that the memory usage of everything else running is hardly worth worrying about. I get the gist. But that is a little self-contradictory. It's like asking for more efficient ways to drive in screws than your electric screwdriver, but also saying "don't talk to me about screwdrivers". Linux, for example is one means of cutting your system down to size, knowing about and having control of everything that runs on it. First define your "system". What do you need/want it to do?
No, CP/M does not quite cut it anymore
Have enough systems level software to support standard I/O, keyboard, mouse, file, display. That way, apps can leverage those things in very basic ways to improve on overall utility, and make them somewhat easy to write.
Author software. It's not important it be the most efficient or capable self-hosted tool. SPIN, BASIC, whatever + PASM is more than good enough.
Take a look at this thing: https://github.com/dschmenk/PLASMA
Honestly, I've got it running on an Apple //e, and it's useful. That machine, being 1mhz, isn't relevant today for most things, but the idea is solid otherwise. One can write reasonably high level code, it's SPIN like, and a mix of assembly language and high level code isn't hard.
Something like it for P2 would be killer, IMHO. Version 2 includes a JIT compiler, and it's all self-hosted, or cross dev, should someone want to do that.
Regarding "File" above, a simple FAT type system would be just fine. Go standard 8.3, or mooch from something like the Apple 2, incorporating file attributes, more descriptive names. Block / sector access one layer below, obviously.
Run small applications. Signal generate, logic analyzer, scope, AD capture, output, calculator, text editor, terminal ANSI, VT, Tektronix. (that one is kind of awesome, even today)
IMHO, it should contain:
Most of the things, if not all of them, mentioned, can be done on one P2. The idea here being to run system inside of an interrupt, where it owns some COGS, leaving the rest free for user activities.
Large external RAM. Frankly, another P2 managing this in various ways wouldn't be a bad idea. It could do things like computation, or maybe some more distant, less real time I/O. With the system operating inside an interrupt, things like DMA, make sense. Larger programs, datasets, other things would benefit from a smart MMU, in the form of a P2 able to service requests from the primary, supervisor P2.
Two SD cards, one system, one user. At the very least, this allows for copies, images, other things to be self-hosted.
A nice set of AD ports, with good connectors, exposed, ready to be used. Use RCA, and or headers. A set of pins, perhaps 32, exposed raw, like with an old IDE style connector.
I would do a card slot / bus, but not needed. Could be really spiffy though. People might make cool things.
HDMI display adapter chip. Feed this various analog signals. Analog displays can run on one of the exposed AD pins as well. Software switch this. One, both, neither.
Legacy serial, with DB9, and or header.
USB ports. One system, one user. Could run keyboard / mouse on the system port. Otherwise, this is the PC interface, useful for a lot of things, User port is whatever user wants to do. This could be an optional load too. USB will be big, relative to other things, IMHO.
Ps2 style mouse / keyboard. These are simple, known, adapters exist, are cheap. Small code footprint.
Default set of drivers for these things. Again, they don't have to do everything. Think the graphics for P1 that Chip did. Honestly, that bit of code does a whole lot. A similar set of code, with some nice fonts, would be high impact and used a lot, particularly for mixed mode, say text + graphics area type displays.
Respectable power. Wall wart, or battery, with appropriate charging circuit. Maybe battery back the external RAM, or use newer memory tech so that isn't a requirement.
Optional, built in, modest, useful display. This does not need to be much. Full NTSC resolution or better would be practical, and not consume too much of the available resources.
Optional, a couple useful UX elements. Spinner, on some simple encoder, analog input stick, maybe package those up into a plug in thing, like SGI did with the buttons and dials device they made a long time ago. That operated over serial, and it presented a very useful set of "standard" input options. The applications making use of them worked very well and offered an efficient and intuitive interface. If it were me, I would put a P1 into something like this and make it serial, plug right into the port on the system, all optional.
Use case:
One, bench computer. You've got a DOS, maybe two displays, maybe serial + display, maybe no display at all. Run apps, compute, capture data, transform, visualize, output. Measure. If it's got a built in display, results can go to it, or an external one, depending. This is much like a laptop + external display is today. I often use one of those USB, self powered panels for exactly that purpose. A monitor, TV, VGA, whatever can be an optional connection, and we've got color management in the chip, making things easy, standard calls / library code useful across all of it.
Author small apps to get things done, test ideas, explore sensors, that kind of thing. Maybe author whole sub-systems, or an application a piece at a time too.
Create, view, edit basic documentation. Bitmaps and Text. It's all anyone needs. More could be done, but just those two would be pretty sweet.
That's the non-networked idea.
IMHO, a networked thing would basically require another P2, and may be useful as a more general purpose system. It's hard for me to see that use case happening without a lot of effort, and multiple P2 chips, but hey! People have got useful things running on much lesser machines. Perhaps the P2 handling external memory can do networking of some sort. If so, big win. Do it.
With some creative presentation, filtering, ignoring of various things, one could participate on this forum on a system that is networked. Either build a P2 subsystem for networking, maybe on a card, or use a dedicated device, maybe on a card, and a lot becomes possible, though I am not sure practical.
I've got access to large format, industrial grade 3d printers right now. Making a case wouldn't be a huge deal. If successful, make a few, then arrange for cheap tooling. IMHO, that kind of polish might make for a compelling product.
Back to the primary use case:
Right now, I use a P1, with a PC and Prop Tool in this way. Have a small library of stuff I like to run, and that is useful to me. I've not had to touch it, and can do a variety of things quickly, same skills different day. A P1 isn't quite enough to stand alone. A P2 will be.
For some perspective, I used my Apple back in the day in exactly these ways. It was lacking in the self-hosted department. Technically, you did have an assembler and BASIC. But, not all of that was as easy as, say the BBC Micro, which offered a lot more. But the point was, one could use the machine on the bench, and with a card or two, get all the stuff I just put here, done.
Another example would be the Tandy Model 100 series. I picked one of those up a while back, just as some inspiration. It runs on 4 AA batteries, and will deliver a good 30 hours on modern cells. It contained terminal software, modest word processor (text editor really), calculator, spreadsheet, and BASIC, that can call Assembly Language, but no built in assembler. Authoring a small, dumb one, does work, but takes a lot of the small RAM. I think mine is 24K. It has serial, cassette, battery backed RAM, keyboard, display, a couple other small things. It's almost a bench computer, but for very low speed. It's an 80C85, running on a modest clock of 2Mhz. Has an expansion port, and ROMS one can add to, or change out to change onboard functionality. Heh, someone probably did a better editor / assembler for it. Maybe I'll check one day.
Now, why?
For me, a few reasons:
One reason is time and flow. I tend to come at this stuff in bursts with long periods of time, sometimes, between bursts. It's very nice to come back to an environment and just continue, or start something new, and do those things in a very lean way. This is why I've stuck with P1 and the Prop Tool. Known quantity. I can fire it all up, get things connected, run a test program or two, and I'm off to the races as if no time had actually passed. And, all that I know is valid. No bull stuff. This is extremely high value. And I've been very successful each time. I can focus on the problem, and there is always some learning related to that. I have time for it, because I'm not having to dedicate time and mental capacity on tools. Those are transparent to me.
For years, I've taught and used CAD, often pretty high end stuff, with a simple premise: One should not have to know anything to build a model and get the utility of it to advance a project. What I mean by that is let the computer do the work, avoid hand computation, focus on those things that are meaningful to the problem, and leverage the system capability to the maximum possible. Used to take the hand calculators away for class and teach people how to think about the problem, understand their givens and why they are givens. That's huge. Then, input to the system that which is known, deriving or constructing to actualize what isn't known, or that would normally be computed. The outcome is being able to jump onto a modeler today and build things. Most any modeler, a lot like being able to jump on most any word processor is. I've simplified some of this, but the idea is solid, relevant.
With electronics, embedded, a similar problem scope and overhead exists. Keeping it lean, as in once someone has bootstrapped themselves onto a set of tools, using them becomes transparent in much the same way a familiar set of hand tools does. We may not have everything possible in our tool boxes, but we generally know how to apply what is in our toolboxes, and maximize the utility of what is in there.
That's the idea here.
A system like this would be a known quantity. People could learn to use it, and once they have some mastery, it's more transparent to them, which leaves them free to attack a problem, create something new, learn, whatever they want, and do so in a lean way.
The beauty of it, assuming we end up with a minimum, but complete and useful subset of what SPIN + PASM can be, and likely will be over time, is all that people learn will be relevant to the greater environments possible when not employing P2 as a system, but in the standard way. A small C complier, or something like PLASMA, would be similar.
"Standard" library code, drivers, other useful things would fall out of all this too. It's not like people would have to do it this way, and in fact, a fair number of them won't. That's OK. This isn't about what is better, or not. It's about making sure a lean, consistent, enduring environment is available. Here we are more than a decade later, and the P1 OBEX code is as useful as it ever was. Mostly no bull stuff. It's about making sure we still have that.
I personally believe there is a lot more use for something like this than many people think. A well designed system, with appropriate ports and circuits to maximize the potential we've packed into the P2 Smart Pins, could serve as the starter basis for doing a whole lot of things reasonably. Not pro-grade, but not trash either. Just useful, potent.
Thanks,
-Phil
that was what I was looking for.
The Plasma idea is quite nice, retro computing the other way around.
I spend some time to read thru a lot of the OBERON documentation, a lot of good stuff there but besides that it might be quite easy to write a emulator for the used instruction set of that OBERON RISC FPGA, I think the user interface is not really intuitive.
Yes. I am pleading for a while now to avoid the mistake made with the P1 and provide a standard convention for character and block devices, so it will be more easy to switch between say, serial or PS2 and TV for example. Maybe TAQOZ could play a role there to provide standardized words as system-call? Since FORTH is extensible one could for example override the serial output with some 'driver' in FORTH and still use the same standardized system-calls for basic interaction. Some sort of extensible BIOS?
Yes. A workbench helper would be one of the uses, No updates and almost instant on.
No need for a interrupt here. We have COGS
Yes. And you familiar set of hand tools are familiar because they do not change every week into something else...
Enjoy!
Mike
Indeed we do. And, that's just an idea. Completely up to anyone working toward these goals.
@Phil
Bench computer. Runs a DOS essentially, has on chip dev tools, storage, RAM, sufficient to be used stand alone. Done right, it's got support for things people need as part of specific, purpose based applications, many of which would be useful in the context of learning, building.
That's very brief.
Granted the Pet wasn't the best in its class but it was good for teaching people BASIC, and I was one of them, but I did better on the Apple family of machines. I was also darned good at R6502 assembler.
Granted switching to the PC wasn't easy, but it worked.
And please don't get me started on which Linux distribution is best. I already made that decision a while ago.
And I'm not going to bring up the mainframe versus distributed argument either.
And lets run down this thread before it becomes a candidate for a submarine defense.
Nor do I. It's very pure, and in that sense, quite elegant. But, it's a paradigm that never really took root, though I will say well configured and thought out X window systems were kind of similar. I did a lot of highlighting text, middle button paste to execute type tasks that hint at Oberon type workflow.
I do think someone investing in all of that would reach a point of utility and mastery. It's not like it all won't work. But, given where most people are, and the dominant paradigms today, that UX paradigm a side show of little value.
Touch isn't though. If "the system" included a touch screen display of some type, that's high value, IMHO.
It takes a while to disentangle the grammar and usually I don't understand half of it. But there is generally the seeds of a good idea or two in there: )
@Potatohead,
What I did not understand there was this: What does that mean? Interrupts don't "own" COGs, they are something that goes on inside COGs.
In general what I'm reading here sounds like people want all the features of a full up operating system, keyboard, mouse, screen, touch screen, file system, etc, etc, without all the code that actually does that, as seen in Android, Linux etc.
I guess the P2 is on a par with early PC's memory wise so something like early Windows is doable. If anyone is up for creating such a thing.
The issue of standards for serial, storage, and the like has come up on this forum many times over the last decade. Never getting any traction. My guess is that to get traction it would require someone to create some kind of OS kernel that implements all that thus making the interfaces a defacto standard. But that kernel itself would need to get traction...
On the other hand, the P2 leans towards FPGA application territory. In that world people create soft IP of their own and mix up up with IP cores made by others, a CPU, a serial port, memory, etc, there they have standards for hooking up such soft IP blocks, like the AXI and wishbone buses. So it is possible to define such interfaces and get people to use them used.
You have encountered what is known as "The Universal Struggle"
A house always needs something more, and always needs upkeep.
Because the upkeep is so tedious we invent new ways to lessen the upkeep, which complicates things, and results in bloat (or an excess of stuff), and now you need a bigger house. (sound familiar?)
When big business and big government get their say, to decide what is in your house, well that's when it all turns into what we have today, back door galore, obfuscated by "tools" and "background code" Or even just viruses and malware made by the same that want to keep the backdoors open, built into the os.
Get a darknet. Partition computers for specific uses, no other way, today.
As for "without all the code" It's not that at all. Think about the Demo Board. It had a lot of things on it. Whether they got used was application specific. The minimum would be to just launch things. Use them, be done.
That is very specifically why I set networked off as a "maybe" case. I personally wouldn't use that much.
As drivers get made. I would use the other things mentioned. Just build them up over time.
Starting from the opening post this has been about "bloat". The excesses of modern operating systems and application software. We all feel it. So I would say that means "without all the code".
But then as the thread goes on, and people define their wants and needs of a "system" that system starts to bloat.
Certainly whatever happens on the P2 it will be "without the code", there just isn't the space available for modern day bloat. Yes.
Unless someone takes the reigns, gains mind share for some kind of organised way of composing parts, defining interfaces and such, I imagine the P2 world will be as chaotic as the P1.
Perhaps that is where Blockly comes in. Perhaps Blockly has definitions for sub-blocks that can be dropped in and connect up in standard ways. Interchangeable parts. I have no idea.
There is no hardware provision for that. Just agreement. Think MSDOS program that takes the machine over, vs one that plays nice.
Just a way of thinking for planning purposes.
I did a similar thing with my PPDB. Had some hand circuits on the breadboard, and over time put together a nice collection of tools that all worked together.
The way I see it. The very minimum here would be to center on the on chip tools to come. Their display, input, output, and a few other things could be standard things for this purpose.
Write a shell with that, and it all starts. Or, if enough people are interested, do more and others can build on it, with it.
I suspect, just making the hardware would trigger that.
I actually need to quote myself here.
Robots of war are coming, and someone may soon also say, Something went wrong.
I say no. YOU didn't develop robots of defense, is what went wrong.
It's not so much wrong as there are gaps appearing. Opportunities as there always are.
Re: unorganized
Yeah. Part of that is an artifact of the P1 scale. It is a build it, run type device. We've seen a couple nice efforts to make a little system. I like and do use one of those at times. But, available resources make it an either or type scenario. One is in the system, doing DOS type things, or running something.
On P2, a whole lot more can be done, with the system context active.
IMHO, that change in scale makes an idea like this more compelling and viable. May well bring some focus, or at the least, will make mods and ports of useful tools more worth doing.
I put together a PE-Kit, one chip development, serial exchangeable with TV or VGA + PS2 Keyboard.
For a while I was in heaven. Programming for a living almost my whole life I had reached a point where programming was not fun anymore but - boring tedious work.
Then I found the Propeller and programming was fun again, because one could understand the whole system, the languages are lovely and the forum is addictive.
But Spinx took most of the available system resources so one could just write small programs, neverless fun.
I am waiting a long time now for the P2 to appear, it will allow to make something like this usable.
The Parallax Pocket Knife, a multi-functional programmable bench tool?
Enjoy!
Mike
Its gonna happen.
.... What is going to happen?
Exactly, @Heater, that is what this thread is about!
And we have still the unknown if TAQOZ makes it into the boot rom and if it will be callable from other applications, to be used as scriptable, expandable BIOS...
And I have not out-ruled CP/M yet, in opposite to you I never got it running on a P1, I got lost in that long thread at the point of external memory.
P2 has enough memory even for MP/M and with a LUT and that XBYTE thing another Z80 emulator could be quite fast. I do have some COBOL for CP/M on Z80...
Isn't ZOG also warming up?
Enjoy!
Mike
I had been dreaming of getting ZiCog and hence CP/M running on a P2 for what seems a lifetime now. It's never going to happen, my interests have moved elsewhere. Perhaps someone else will pick up the Z80 on P2 challenge.
ZOG is not warming up either.
ZOG was an experiment in making it possible to use a C compiler for the Propeller. I believe it was the first way to do that [*]. As such Zog was soon obsoleted by the arrival of native C compilers for the Propeller, Catalina, ImageCraft, prop-gcc.
Today I would not make Zog, a ZPU emulator, I would make a RISC V emulator which is now a supported target of GCC and LLVM. But hey, ersmith has already done that!
* The first way to use C for the Propeller was the BDSC compiler in CP/M running under ZiCog. Still the only way to actually run a C compiler on the Propeller itself.
Ahh, mobile. Well, I'll just leave it. Why not? LMAO
Yes. Single task system, and in this context, playing nice means MSDOS is left intact after running something. Not a completely descriptive expression on my part though.
In the P2 context, playing nice, would mean leaving the "system" intact, and often running, while another program is running.
Re: What is gonna happen?
People are going to build that bench computer, tool being discussed here.
This thread is a glance at what some are thinking it looks like. That is why I wrote what I did. And why @msrobots initiated this discussion thread.
A lot of this thought was probably inspired by the monitor we had in the P2 HOT edition. On that one, connecting two prop plugs made the chip pretty interesting from an interactive system point of view.
One could leave one COG running that monitor, and upload, and launch other programs, type in machine code snippets, and interact with hardware in some basic ways. It, being in ROM, was always there, easy to call, use.
When those other programs were written "to play nice", it was possible to run one or more of them, and interact by changing their parameters, stopping, starting them, and so forth.
Doing things like firing up a VGA display driver to replace a running TV driver, could happen while another program was running. Several of us did things like that.
On this chip, we have the protected RAM region, and the debug facility, and some code that can load into that region. Some possibilities there to get a fairly robust environment running that is capable of more and easier than the P2 HOT monitor only one did.