What would be the Minimum Requirements, to make a Useful standalone P2 System?
Christof Eb.
Posts: 1,214
Hi!
From time to time in this forum the wish for a standalone P2 computer keeps popping up.
I have now stumbled upon a small C-compiler https://github.com/rswier/c4, that could be brought to P2. And there is an enlarged version together with an operating system too: https://github.com/rswier/swieros
In comparison to a PC or a Linux based system, P2 is smaller and slower, so this P2 computer must be much more simple. Something like the computers around 1985. But I think, it would be much preferable to have 32bits used instead of emulating an 8 or 16bit machine.
What would be the minimum features to make such system useful?
"Minimum", because due to RAM amount and development time, this has to be limited. ("Needs a Web browser" is a killer.)
For me, I think a useful starting point would be:
- Have a shell via serial pc terminal, that can start programs from SD-card
- Have a way to transfer files to/from pc.
- Have a compiler
- Have an Assembler for P2
- Have a way to start (and stop) programs in a cog (and other cogs), that will run in background in parallel to the shell. This background programs must continue to run, if the pc is disconnected. This would be the programs that controls some device or takes measurements. From time to time you can contact the P2 computer to change parameters or get some evaluation of data done.
What are your thoughts?
Christof
Comments
I think the shell needs to go into the 16K rom area and provide some basic I-O to access sd, flash and eventual RAM on the P2-Edge. It also should be able to share Serial in some form. Sort of a mini-bios called via debug interrupt.
Write protected it would be save from user-programs but has access to the whole HUB. The basics are already in the ROM, serial/sd, Monitor, load file, run hub address. All written by @Cluso99 and reusable.
You might not like the idea, because you will need to overwrite TAQOZ in ROM with your OS/Shell/Bios.
But it might be usable. The whole memory map can be used, basically all COGs are available and call into BIOS or Shell via a BRK #x instruction having parameter in defined COG locations.
Mike
Is that possible without the new chip revision ? I would think if it's in ROM then it can't be overwritten, can it ?
@"Christof Eb." agreed but I would like to know what use cases for such a computer would be intended (apart from the obvious - P2 standalone dvelopment) or controlled/scriptable sensor hub or sensor data processor ?
I have been working on a file system which will use the 16MB flash chip that attaches to the P2 chip. I figure this is a key ingredient to a standalone system.
I think @msrobots just means turning on the write-protect for the top 16KB of hubram.
I'm not really following the words 'standalone system', as any self-developing P2, is not truly standalone at all :
Any serious SW and HW Development includes needing the access PDF files and github and Zoom and email, and other resources, without those, a system is not standing at all, in any real sense, it is at best crawling.
With a crawling system, what is the use-case ?
To me, it is smarter to focus on what PC/Tablets and MCU's each do well, and put efforts into helping them co-operate better.
The key words are minimum, useful and standalone.
"Serious"does not necessarily fall withn the "miniumum" category and a regular PC is not really "stand alone" either because it too does need a keyboard and a display ... but I get the point and in that sense, to be effective one might very well need something more than a minimal, useful, semi-standalone system.
Keyboards and displays are peripherals, and don't affect the determination of a system as 'standalone' any more than having an SD card interface or a Flash chip.
An interface to a PC may indeed be necessary for an application, but I challenge the assertion that it would be needed in most cases if a standalone system existed.
A standalone P2 system would support direct connection of keyboard and display, with some local storage.
Requiring github, email, video conferencing, etc for a system to be considered to 'stand' renders 'standalone' an impossible definition.
Ok, you have your focus and should feel free to make suggestions to that effect, in another thread.
As far as a minimum useful standalone P2 system:
In other words, something like an early Unix system.
They somehow managed to develop for, and on, those systems without all of the mod-cons.
I presume your text based interface also includes a useful Text Editor ? (Multi window, undo, copy/paste, column edit mode...)
You need to also decide what is a minimum RAM & COG resource, left over for the user, after you have duplicated all that resource, already sitting on the same desk as your P2.
and Debugger ?
It's useful, but removable storage is required, too.
Oh, that's soooo cute! Thanks for posting it!
With just a few tweaks to make the C code ANSI compliant, I can now compile this C compiler on the PC using Catalina, and then on the Propeller this C compiler can then compile itself. The whole process took just a few minutes.
So we now have fully self-hosted C development on the Propeller (well, as long as you are happy to use the term "C" very loosely indeed)
Catalina already had these.
And now Catalina has this! I may include it as a demo in the next Catalina release.
You don't need it. All the above compiler needs is a way to save and load the binaries it generates, which it can't currently do. But this would be trivial to add.
Easy enough. But I'm not sure why you would want the shell to stay running if you plan to disconnect the PC. It just wastes resources.
Ross.
What size is the compiler once compiled, and what source file sizes and binary outputs can it handle within the P2 ?
The program when compiled for the Propeller is about 40k code size, so I gave it 40k of code space, 40k of data space and 40k of stack space to execute in, which turns out to be enough space for it to compile itself and execute itself - i.e. to compile a C source file of about 500 lines and then execute the resulting program.
This version cannot save its binary output (it executes it in memory and then discards it) so I cannot easily tell you how big the resulting binaries would be - but the total output code size must be less than 40k.
Ross.
It's certainly a cute little minimalist C compiler at around 500 lines. It's obviously incomplete with no floats or structs or pre-processor or linking etc and is currently executed in a tokenized form. It does look like something fun to mess about with for running little program control snippets etc. Be rather handy if this tool compiles under flexspin too (need to try).
I wonder how fast it can run? I imagine it's probably faster than Micropython, and it could be quite useful for certain small things. It might be possible to map its output into a byte code VM in the P2 and extend it further to support P2 IO and other HW capabilities to let it control the P2 resources more. Also it could be tweaked to support external memory giving it access to much larger programs.
EDIT: Nope! Nice error message from flexspin LOL.
Hi Ross,
yes, isn't it a gem?
Have you had a look at that even more complete brother c.c https://github.com/rswier/swieros/blob/master/root/bin/c.c ?
Unfortunately I was not yet able to compile c.c with cygwin. (If this is as easy for you, I would be glad for some hints, how to compile it for Windows .....)
For me the internals of compilers ( other than Forth ) is a new field so I spent some hours with c4, trying to understand, what it does. There is a commented version https://github.com/AoiKuiyuyou/AoikC4x86Study Unfortunately this has bugs and cannot be compiled.
(((I even read pascal.hansotten.com/uploads/books/Compiler%20Bau%20Nwirth%201986.pdf )))
At the moment I believe, that c4 needs to have the source code in Ram during execution, because it uses string constants from there. (?)
I think, that it would be good to have relocatable code and vars. As far as I understand, it compiles to absolute addresses.
I wrote, that an assembler is necessary, because all of this special features of P2 are only accessible via special assembler instructions contrary to almost any other processor.
Christof
I think the Amiga came out in late 1986. It had 256kB of RAM, a true multitasking OS, a GUI with overlay windows, shell, filesystem and even speech synthesis. A single cog of the P2 is much more powerful than the 7MHz 68k, so I think the hardware and it's performance is not the problem.
Yes, 10 years ago with the P1 I still had printed paper manuals on my desk. But theese days big LCD monitors are cheap and the documentation is never really finished so we had to chop a lot of trees to print out all the updates. So a PDF viewer is mandatory. I had Email on my Amiga in 1987. GIT also should be no real problem. There was something called RCS (revision control system) which I used around that time. Zoom isn't really necessary. I could use the phone for that.
A P2 can be a standalone system.
(1) A keyboard and mouse: PS2 is easy to implement and I think it has been already implemented somewhere
(2) A monitor: we have a lot of VGA and HDMI drivers, including graphic primitives and sprites
(3) Audio: we have a lot of audio drivers
(4) File systems: SD cards/FAT32 are already supported in Flexprop
(5) Ability to load and run external programs: in PSRAM system it is easy to implement, so I already did it (a "MicroDOS" topic on this forum)
What has to be be done to make it the retro style modern computer is....
.... a proper BASIC interpreter
I always wanted to write one...
While P2 may be good as is, the PSRAM enabled systems (EC32MB) may be even better. The frame buffer can be placed there giving up to fullHD resolution in 8 bpp. Or 1024x576 at full color. Then, while executing binary code from PSRAM may be not convenient, executing a bytecode from there may be fast and convenient enough.
Now fully open source. MMBasic has been ported to many devices and is really impressive.
https://github.com/UKTailwind/PicoMite
https://geoffg.net/picomite.html
I tried this thing on a Pico.
This Basic is written in C - maybe it is possible to port it and recompile it in FlexC.
We've had standalone P2 development systems (TAQOZ, MicroPython come to mind). In practice nobody used them, at least as standalone systems -- it just isn't that compelling a use case Possibly a standalone Spin2 compiler might get some traction, since at least it would be able to use the existing libraries of objects.
Well, at least for me, the word "useful" for a controller means, that I want to control some equipment with it. For me this is not about retro computing. I have seen so many emulators now and apparently no one is really using them with one single exception: The only usage is to play old games. If this is the goal, then Ada's MegaYume EMULATOR makes a lot of sense because it can be used to revive these. It has to have much more than just Basic, because it has to emulate the hardware.
I had invested a lot of time in the coco-3 emulator. I still think, that this was a very interesting machine together with OS9. If someone wants to build a very nice retro computer, then this seems to be a good way to go. Interestingly only very few examples exist, that coco-3 was used to control something.
Of course the very central point for something useful with P2 is, that it enables the user to do multitasking and employ 8 cores. I have to add this more explicitly at the first post.
Perhaps the word "standalone" is a problem. I do use Taqoz and Forths on other MC too. As PDFs and internet are so very helpful, you will have to have a pc in parallel. You want to copy and paste. I like to use notepad++ on the pc and it is much more convenient than an oldtime editor. But an editor on the target system can be quite useful to edit a short parameter file. And the compile cycle is shorter as I normally only need to compile a small part of my target software even if the target mc is much slower than my pc.
Thinking of it, the self hosted system makes then most sense, if you can access it from different devices. Some bridge to wlan + telnet is needed here for P2.
This doesn't need a standalone system. A program can be written and compiled on a PC, then transferred to a P2 controlled device. As it is now. There is no need to have a compiler/editor on a P2 itself and connect to it with a notebook or something like this using telnet. If I have a notebook connected, I can always compile and debug on it via the same connection
However, the MMBasic/Picomite is an example of self-hositing system with a keyboard, editor and interpreter, which is suitable not only for retro-type stuff, but also for controlling systems. This thing on a Pico supports several types of (small, SPI) touchscreens and allows to define a GUI for a device which then is controlled internally by Picomite. You can have buttons, gauges, etc, and you can define what has to be done when these controls are touched. As in (a much simpler version of) Nextion HMI.
I am much less active here now because of work I have to do with a P2 based thing - a robot. The robot has a 7" screen. I had to write a lot of code to define and control the GUI. Having something like Picomite... much less to code... And it is still something to control the equipment ...
... as well as write/port/convert a fancy game on it...
I need to look deeper at this MMBASIC and try to port this.
... Edit... this software has no open source compatible license. At least I cannot see any. Instead, MMBASIC is available free for personal use, but with hard restrictions:
Picomite has sources opened, but that thing is heavily modified for a Pico and still no real OS license.
The four square sockets are RP2040s running MMBASIC.
They serve as I/O expanders for the P2 Edge and because they are self-hosting, they can be used for PLC functions.
Three have Click sockets (mounted on the other side) and the fourth has a VGA port.
Craig
Yes, I saw it, but haven't had time to investigate. Getting this baby one working took minutes - getting its big brother working one would probably take hours.
Perhaps later this week.
Ross.
As a fan of the arduino environment I totally agree, that the ability to reuse code, that others have written, is extremely convenient. Libraries!
Perhaps this question about a useful self hosted system is the same. In some cases, I have found, that it provides means to do something easily. For example, if I have a system, that does measurements over months in another room. I can connect to it to get data, do some simple graphics, change parameters, compile new graphics analysis, all in parallel to the running tasks. In this case an operating system with the possibilities of a shell in parallel to other tasks is just useful.
I have been wondering, if there is special benefit for you, that the RP-2040 are self hosted? You use a nice language and some powerful libraries, which certainly are useful. But it is this more useful than if it was pc-hosted? You could use arduino environment with it's libraries instead or use the original c-compiler setup to have PLC functions.
Is this more useful, because you can connect indirectly via P2 with simple protocol over serial lines?
Self hostng is maybe less important than simplicity. Picomite is very simple to use and is very efficient, a lot can be done with a small piece of code. This is BASIC language power. It is much simpler than using C and the official cmake based toolchain.
For a P2 I use FlexBasic when and where possible. The same effect: much shorter and simpler code source. I rewrote my robot control program family from Spin to Basic and It is now 3x shorter and much simpler to maintain.
@"Christof Eb."
The goal is to provide a solution for my customers where they don't have to depend on me for programming changes or hardware repairs (hence the socketed buffers).
The P2 is merely a "black box" that handles the real-time motion control but the devices with onboard interpreters are responsible for machine sequencing and communication with the Android-based HMI (tablet, phone or industrial panel).
All that is required to edit the code is a terminal which can be a laptop or even the Android HMI.
Most of my customers are in other countries and many of them have technicians who are familiar with PLC programming. MMBasic is absolute child's-play and is well documented. If they need help, I can remotely access their Android device.
Any of the RP2040s can be switched over to use another language (they have USB ports) if the customer wants to but then they will also need to use the appropriate tool-chain.
Craig
May I ask how the P2 and the picomites communicate?
And is there a post on thebackshed for this project?
@aaaaaaaargh
After extensive testing, I went with this:
https://forums.parallax.com/discussion/172266/multi-drop-serial#latest
thebackshed: I tend to irritate people with my Prop-talk over there. There are so many problems that could be easily overcome if
they would simply involve a P1.
Craig