programming the prop2 on the prop2
mrchillin
Posts: 17
in Propeller 2
how easy/hard would it be to build a simple dev tool that can be self hosted
obviously....an sd card....tv.....keyboard driver would need to exist first.....then a simple assembler....and then a cog loader....
i think i would stick to assembly....is basic possible tho
obviously....an sd card....tv.....keyboard driver would need to exist first.....then a simple assembler....and then a cog loader....
i think i would stick to assembly....is basic possible tho
Comments
In my case, I want to get spin2 working, then rewrite the spin2 to compiler in spin2. That would enable everything to run on the chip.
I suspect @"Peter Jakacki" could argue that this type of environment already exists if you use the TAQOZ environment and Forth etc, but you mention assembler.
Like Micropython, a Basic environment should certainly be possible to put together to run standalone.
edit...transfer...compile...load
TurboPascal was 38k, but do users really want to go that retro ?
When I code, I have many PDF files open, and I've not seen mention of PDF readers for P2.
I also run multi-window editors, with column editing modes and file compare and syntax highlighting, and Find Declaration type features.
And google... and PCB design software .... and Spice simulators...
A lot happens on any modern, commercial design desktop.
All of that makes 'self hosting' more of a retro-mirage, than a real commercial thing.
TACHYON already self-hosts, and P2 already emulates RISV-V, so almost anything that runs on that, could run on P2. Python is in alpha form.
It's smarter I think to focus on speeding up the link between P2 and PCs, and getting a real PC hosted Debugger working.
That's one reason I pushed up the baud rate on EFM8UB3 as high as the chip & drivers could manage, and maxed the RX buffer size.
Michael Park wrote a spin compiler (homespun for PC/*nix/mac) and then converted it to spin to run on a P1. It had a rudimentary editor and OS. I took it and reorganised it to run under my Prop OS tho noone was interested enough to see if my reorganisation actually worked.
As soon as we have spin2 I'll try and get my OS running on P2. I've been extremely busy at work so I haven't had time to experiment with getting it to compile with Eric's spin to pasm converter/compiler
I appreciate what you are saying about the PC handily doing a lot of things and how obvious it would be to have it host the development environment, as well. The problem with the PC is that there are layers of complex software between a simple intention to put something on the screen and the screen, itself. You'd think there'd be some kind of efficient and refined universal protocol, by now, for using a window, mouse, keyboard, and storage on any machine, to make it into a graphical user interface, but it hardly exists. You have to pick one complex scheme, or another, and then work your way around all the simple things it won't let you do. And nowadays it's even morphing into pay-to-play with app signing. The whole thing is a joyless slog. And then you''re at the mercy of forces beyond your control. It's like buying real estate in a corrupt jurisdiction. Better to build a base on the moon if it means freedom from regulation and tribute payments. That said, we will have Spin2 running in Windows soon.
TAQOZ and microPython
I could see myself using an environment with a nice text UI like Borland Pascal etc or maybe an even nice GUI that allows SPIN2/PASM code editing and running directly and debug on the P2 itself. With the HyperRAM, video and USB COGs going, things like this are certainly going to become possible. Hopefully we can eventually get to a point where in some cases attaching a PC for development becomes optional. With debugging and logic analzyer and scope capture options, we could have a nice self contained system on the P2. I know it's still a lot of software integration work to be sorted out and not everyone will want it and not every system is going to be able to support a display/keyboard etc, but some people might be able to do things that way.
rogloh's DVI code is highly optimised ASM, as is garyj's USB code. Users would struggle to debug or fix code in those libraries, so you have shifted the problem slightly, more than fixed it..
The P2 COG approach means (hopefully) such libraries have a more robust operation than other MCU's libraries.
That's sounding quite close to the EVE / EVE2 type chips, and that is an area P2 could do very well in, but those chips do not try to be development systems too, they focus on the pixels and touch interfaces.
The volumes in that market, are also more commercially appealing than the volumes in self-development
A problem P2 will have with new users, re development, is they are used to Phones and Tablets, and so expect that level of processing power, if presented with anything graphical.
Project Oberon is the nearest existing self-hosting compiler + graphics, and that might just fit into a P2 (with some effort) but that has chosen monochrome graphics.
I'm not sure that's enough, to attract new users over the next decade ?
Yes, a work of art. I was thinking of having 2 cogs working together to handle graphics + text if that was possible. I also don't really like the idea of wasting cogs trying to implement very slow USB though just for keyboard and mouse. I did some sniffing with the nRF24L01 in promiscuous mode and I think I can implement Logitech wireless keyboard and mouse using that interface with just a tiny amount of code memory and not even have to dedicate a cog.
Once I get over making up this batch of P2D2 boards next week to ship out, and after I knock out a dev board as well, I may just take a few days to put a system together with the dev board in an enclosure as a P2PC.
I loaded TAQOZ with lots of different modules and didn't even bother to reclaim any private dictionary space, and even with the palette and file buffers etc it still has over 8k free in the 64k corner. An editor would probably take about 2k.
Parallax P2 *TAQOZ* Extensible Firmware V2.2 'CHIP' 240MHz 191021-0900 KERNEL Parallax P2 *TAQOZ* Extensible Firmware V2.2 'CHIP' 240MHz 191021-0900 MODULES: *EASYNET* WIZnet NETWORK SERVERS 160707.1500 *W5500* WIZNET W5500 driver for TAQOZ V1.0 191007 *BREAKOUT* BREAKOUT FOR THE P2 - 190606 *C2PROG* Silabs C8051F Microcontroller Flash Loader - 190529.0000 *MANDELBROT* MANDELBROT VGA DEMO 190800-0000 *TEXT* VGA BMP TEXT 190800-0000 *BMV* BMV VIDEO PLAYER 190800-0000 *WAVE* WAVE AUDIO FILE PLAYER 190800-0000 *BMP* BMP FILE VIEWER 190800-0000 *AV* AUDIO & VIDEO DRIVERS 190614-0000 *CLKGEN* Si5351 Clock generator 190800-0000 *ASMEX* PASM2 instruction exerciser 191014-0000 *SPIRAM* LY68L6400 8MB SPI RAM ACCESS 191020-0000 *DECOMPILER* A decompiler for TAQOZ 190825-0000 *RTC* RV-3028 RTC DATE and TIME 190800-0000 *I2C* I2C BUS DRIVER 191000-0000 *DISK* SD DISK REPORTING & FORMATTING TOOLS 190800-0000 *EASYFILE* SD CARD and FAT32 with VIRTUAL MEMORY 190800-0000 *SMARTPINS* SMARTPIN FUNCTIONS and drive modes 190800-0000 *P2CLOCK* P2 CLOCK CONTROL 190800-0000 *EXTEND* Primary kernel extensions 191114-0000 *SPIFLASH* MEMORY MAP CODE: $0000_-- ok TAQOZ# $0007_E17A 378 bytes 64K FREE: 8,132 bytes DEVICES SD CARD SANDISK SD SL08G REV$80 #588053344 DATE:2016/2 I2C DEVICES $A4 RV-3028 RTC $C0 Si5351A CLOCK GEN 2019/11/15 FRI 18:57:33 ------------------------------------------------------------------------------- TAQOZ#(1) I think Peter's TAQOZ can run stand-alone, using a USB keyboard and VGA monitor.
(2) I have written micropython programs entirely on the P2, again using a USB keyboard, VGA monitor, and SD card. I used the pye.py editor(written in Python) to edit a file on the SD card and then ran it from the micropython prompt.
It's still early days, so I don't think any of these systems are really user friendly yet, but it's certainly going to be possible. I think Chip's spin2 on P2 will be a very nice environment.
Have you looked at the Plan 9 operating system & protocol? It was designed to allow use of window, mouse, keyboard, and file storage remotely on any machine. The windowing system is quite elegant: the user program opens /dev/mouse and /dev/cons to read mouse and keyboard input (which can be coming from anywhere, even another machine) and opens /dev/draw for writing pixels to the display. All of this is transparent to the application, so you can run the whole windowing system inside a window recursively.
The Plan 9 OS never really caught on, but the 9P protocol it defines (for remote file access, including by the windowing system) has found a lot of applications, e.g. Windows 10 services for Linux uses it internally.
the prop was doing the work!
no pc!
Of course if you have a phone then it could run the development system too -- phones these days are much more capable than most PCs of a few years ago.
True, but it is a pain to use a tiny touchscreen for anything more than simple edits.
The phone then takes touch, pen, keyboard, mouse / trackpad input. It works better than one would expect.
The phone has 5gb RAM, 8 core Arm clocking at roughly 2ghz. It is crazy.
Honestly, it is lean and mean. Actually does compete with my laptop. This was surprising to me. What tipped me off was watching someone else use a phone. I got curious and decided to just load apps and try all the options. Who knew?
I can setup, do a video conference on the thing, and in another window, bring up email, author docs, manipulate images, etc....
To me, this is largely a design problem. Should a P2 system get made for dev, then doing that will make more sense like PC does.
Multi display, maybe 2 SD cards, a big RAM. Slots or ports.
I like Peter's idea of just doing logitech protocol. Means those little bluetooth radios can be used. Or fall back to ps2 and people can use adapters.
What I am getting at is a board, enclosure, ports, etc... set up for that purpose.
When one looks at old computers, for example, all of the design work can be seen. Compare an Apple 2 to say, a single board 6502. Both can run software and control things. The "PC" like design of the Apple is what makes it a workstation. And back in the day, that is one of the use cases. Apples were used to develop for many other targets. This worked because software, slots, storage all lined up with the task. And as a system, it got targeted for software that would not happen without the design work being there.
For now, we all are likely to just build stuff. Later, that stuff can be combined in various ways. The dev use case will make more sense to more people.
Another way to look at it is those people who package Raspi computers into laptops, brief cases, etc... the design fits the task.
everybody has preferences....mine is to keep the middle man out apple microsoft linux...what no android...must not be used enough
so: how? will the prop 2 start with assembly only...or will it require spin? at that point u can make the rules....its the initial code that the prop2 runs on.....the original prop required a spin program at start up
Or, add at $10 Raspberry Pi zero and do the same wirelessly ...
P2 can take an assembly only program. Chip is working on a self hosted Spin 2. That will do assembly only, or any mix of assembly and spin someday.
Other people are doing their own thing. Right now, micro python and Tachyon Forth are self hosted.
It will all evolve over time. It is very early right now.