@msrobots A serial browser interface was mentioned and would be very useful for environments where they cannot install other software perhaps.
However that was never my primary method I advocated anyway since I proposed a serial graphics terminal. In the past I have implemented serial graphics to dedicated Prop terminals over RS485 and also to enhanced serial text terminals via Bluetooth on Android tablets.
Back in the 70's there were various graphics terminals and protocols available but now terminals are mostly dumb text terminals, and not many even support ANSI modes. What I am proposing is a small display with inbuilt CPU and USB/Bluetooth/WiFi capability, but cheap. There is such a beast, it's called an Android tablet that I can pick up for $50 or I might have a few of them just sitting around.
So it's not about using Android or any other O/S but to treat them as a display (plus input device) that will also display serial text no matter way, but can also accept graphics commands as simple as "plot pixel" to complete "draw button" macros etc. If I program this terminal in Forth then I can add these macros via the serial terminal itself from the Prop. How good is that!?
Now that it is on a tablet, it could use the tablet's Bluetooth to communicate to a cheap keyboard and mouse as well, or the Prop can do this via the ESP32. Wow! Now you don't have to worry about sourcing PS/2 keyboards or gobbling software resources and having dedicated connectors for USB keyboards either. Now the P2 is free to do what it does best which isn't USB or hires displays.
However, this does not preclude directly interfacing to monitors and keyboards as that also has advantages and may be necessary in some cases. It's just that we can have the P2+ESP32 as a stand-alone development system that could use a cheap battery powered smart monitor (aka "a tablet"). Imagine if the tools that are PC based now were primarily written to run on the P2 itself, but I'm sure the tool developers would need most of the memory and resources to run these tools. I'd like to see them run in command line mode so that we could hook up a monitor and keyboard and run a simple color text terminal on the P2 to support it. But any tablet could be tasked as a monitor using just the normal serial comms P63,62 that would also support Chip's debugger graphics.
I am sure that I will have some products that will use up enough resources on the P2 that I would not be able to develop and debug the system without the support of a PC or this simple tablet display, both of which would support Chip's debugger graphics but the tablet would have the power of the Forth "macros' or scripts, however you look at it, to be fully customizable.
@msrobots - My current multimode VGA driver can handle that. Default is 640x480x8 but I can punch in any parameters on the fly to go from 128x96 to 1920x1080. So I'm sure that I could take those debug strings and display those graphics, which I might just do as an exercise. I haven't bothered with just a pure text mode yet, but that is very simple thing to add to my current driver. I need to have a look at rogloh's universal driver though to see if I can integrate that into TAQOZ.
But bear in mind that graphics requires resolution which takes up a lot of memory, the standard 256 color VGA mode takes 300kB already, although TAQOZ itself takes less than 64kB which helps. So don't get me wrong, when it is purely TAQOZ running, I don't have the same need for external graphics support, although I'd still like to be able to do it anyway. At the very least the ESP32 should allow me to connect Bluetooth keyboards and possibly even 2.4GHz wireless devices.
If TAQOZ and my video+memory drivers plus HyperRAM get combined I think it will open up a lot of possibilities. The extra driver code's PASM2 footprint burden should be relatively small (each are around 4kB) and it will free up lots of HUB RAM too if your frame buffers get moved into HyperRAM. The P2D2+P2PAL combo will allow for this. My drivers are all accessed through defined memory structures (display list + region structs for video, and mailboxes for memory), so any non-SPIN2 languages that can still read/write HUB memory and can spawn COGs should be able to easily interface to it. You lose the SPIN2 API I wrote to help access some of the driver's special features, but you can simply select the subset of useful APIs you require and implement those parts in your own language.
@"Peter Jakacki" have you looked into Tcl/Tk. The GUI interface builder is so good that it has been ported to other platforms like Python called tkinter. There are Tcl/Tk interpreters implemented on Android, iOS, Mac, Windows, Linux, Solaris, IRIX, HP-UX, etc. It's been around since the 90's and easy to develop for.
Here's a nice little program to demonstrate
Basically, one can get setup and then just use it for a decade with no real worries. Keeps people off the update treadmill.
2. Simple, lean, mean. By its nature, a self hosted environment can be well understood and that appeals to some people.
3. Support for different development styles.
A current example is building code to addresses, same goes for data. One may, for example, build a routine, intended to be loaded dynamically, relocated, whatever. Build a few of these, write to file system, load together as one image in the future, or to form an application.
There are other ideas in this bucket, and I just put one here to illustrate.
4. Known dev target. Think, "works on P1 Demo Board" and that is roughly what was expressed.
5. PC / big OS avoidance.
Of all of us here so far, Peter has basically done it with Forth. Others are thinking along similar lines with other languages and or perhaps a lean OS.
Personally, I would live to see a P2 implemented microcomputer style, which leads to...
6. Fun!
And that counts, given it was one if the original design goals. It's in spec
In any case, that's the line of thinking to catch Ross up.
Don't get me wrong - I am all in favor of fun. If people want to do it just for the fun of doing it, I'd say "Go for it!"!
I can see the point of emulating old CPUs, and even resurrecting old operating systems, such as Cluso has done with CP/M. I see someone wants to use the P2 to revive the Amiga, and that would be great as well (I always wanted one of those!).
But self-hosted development? When a complete Raspberry Pi Linux-based development system (which would seem to satisfy all the requirements you listed, plus fit in your pocket, plus give you a far better development experience) costs about half the price of a single P2 board?
I just can't see the need. However, I can see the fun!
Ross,
I think the use/advantage is a single pcb that can do the edit/compile/test/run on the one P2 board, just like we had with the Commodore, Apple and Z80/CPM computers in the early 80’s.
There’s really no need to have a seperate PC or RPi to do this. I think this has appeal for the education market. It’s not a commercial product requirement tho.
@RossH "Don't get me wrong" Trust me, I didn't and agree with need vs. want in all this. Really just intended to catch you up on that discussion mostly because I think you were busy in the thick of it.
In my own adventures, a system like that will likely happen as part of a product design brewing. Wants can turn into needs when three letter agencies, contracts and such all come together. In the meantime, I am quite happy to follow along and get bits of time here and there to explore my P2.
Ross,
I think the use/advantage is a single pcb that can do the edit/compile/test/run on the one P2 board, just like we had with the Commodore, Apple and Z80/CPM computers in the early 80’s.
There’s really no need to have a seperate PC or RPi to do this. I think this has appeal for the education market. It’s not a commercial product requirement tho.
I wish this times back, but on the other hand having Webbrowser open and all the documentation at hand, and use copy/paste is also a strong argument for a real OS based IDE.
Comments
However that was never my primary method I advocated anyway since I proposed a serial graphics terminal. In the past I have implemented serial graphics to dedicated Prop terminals over RS485 and also to enhanced serial text terminals via Bluetooth on Android tablets.
Back in the 70's there were various graphics terminals and protocols available but now terminals are mostly dumb text terminals, and not many even support ANSI modes. What I am proposing is a small display with inbuilt CPU and USB/Bluetooth/WiFi capability, but cheap. There is such a beast, it's called an Android tablet that I can pick up for $50 or I might have a few of them just sitting around.
So it's not about using Android or any other O/S but to treat them as a display (plus input device) that will also display serial text no matter way, but can also accept graphics commands as simple as "plot pixel" to complete "draw button" macros etc. If I program this terminal in Forth then I can add these macros via the serial terminal itself from the Prop. How good is that!?
Now that it is on a tablet, it could use the tablet's Bluetooth to communicate to a cheap keyboard and mouse as well, or the Prop can do this via the ESP32. Wow! Now you don't have to worry about sourcing PS/2 keyboards or gobbling software resources and having dedicated connectors for USB keyboards either. Now the P2 is free to do what it does best which isn't USB or hires displays.
However, this does not preclude directly interfacing to monitors and keyboards as that also has advantages and may be necessary in some cases. It's just that we can have the P2+ESP32 as a stand-alone development system that could use a cheap battery powered smart monitor (aka "a tablet"). Imagine if the tools that are PC based now were primarily written to run on the P2 itself, but I'm sure the tool developers would need most of the memory and resources to run these tools. I'd like to see them run in command line mode so that we could hook up a monitor and keyboard and run a simple color text terminal on the P2 to support it. But any tablet could be tasked as a monitor using just the normal serial comms P63,62 that would also support Chip's debugger graphics.
I am sure that I will have some products that will use up enough resources on the P2 that I would not be able to develop and debug the system without the support of a PC or this simple tablet display, both of which would support Chip's debugger graphics but the tablet would have the power of the Forth "macros' or scripts, however you look at it, to be fully customizable.
But not essential. It should be usable W/O pc/mac/linux/android/younamemeit.
And I bet with @rogloh's driver you can easy build some TAQOZ module decoding the send debug string and displaying the result. Me? sadly not so.
Mike
But bear in mind that graphics requires resolution which takes up a lot of memory, the standard 256 color VGA mode takes 300kB already, although TAQOZ itself takes less than 64kB which helps. So don't get me wrong, when it is purely TAQOZ running, I don't have the same need for external graphics support, although I'd still like to be able to do it anyway. At the very least the ESP32 should allow me to connect Bluetooth keyboards and possibly even 2.4GHz wireless devices.
yes please.
Mike
Here's a nice little program to demonstrate
% button .b -text hello -command {puts "Hello, World!"}
% pack .b
Python is more popular, I'm sure that it is just as simple in tkinter
Why native dev?
The top reasons expressed over the years are:
1. No dependencies
Basically, one can get setup and then just use it for a decade with no real worries. Keeps people off the update treadmill.
2. Simple, lean, mean. By its nature, a self hosted environment can be well understood and that appeals to some people.
3. Support for different development styles.
A current example is building code to addresses, same goes for data. One may, for example, build a routine, intended to be loaded dynamically, relocated, whatever. Build a few of these, write to file system, load together as one image in the future, or to form an application.
There are other ideas in this bucket, and I just put one here to illustrate.
4. Known dev target. Think, "works on P1 Demo Board" and that is roughly what was expressed.
5. PC / big OS avoidance.
Of all of us here so far, Peter has basically done it with Forth. Others are thinking along similar lines with other languages and or perhaps a lean OS.
Personally, I would live to see a P2 implemented microcomputer style, which leads to...
6. Fun!
And that counts, given it was one if the original design goals. It's in spec
In any case, that's the line of thinking to catch Ross up.
Don't get me wrong - I am all in favor of fun. If people want to do it just for the fun of doing it, I'd say "Go for it!"!
I can see the point of emulating old CPUs, and even resurrecting old operating systems, such as Cluso has done with CP/M. I see someone wants to use the P2 to revive the Amiga, and that would be great as well (I always wanted one of those!).
But self-hosted development? When a complete Raspberry Pi Linux-based development system (which would seem to satisfy all the requirements you listed, plus fit in your pocket, plus give you a far better development experience) costs about half the price of a single P2 board?
I just can't see the need. However, I can see the fun!
Ross.
I think the use/advantage is a single pcb that can do the edit/compile/test/run on the one P2 board, just like we had with the Commodore, Apple and Z80/CPM computers in the early 80’s.
There’s really no need to have a seperate PC or RPi to do this. I think this has appeal for the education market. It’s not a commercial product requirement tho.
In my own adventures, a system like that will likely happen as part of a product design brewing. Wants can turn into needs when three letter agencies, contracts and such all come together. In the meantime, I am quite happy to follow along and get bits of time here and there to explore my P2.
I wish this times back, but on the other hand having Webbrowser open and all the documentation at hand, and use copy/paste is also a strong argument for a real OS based IDE.
(OT but fun) A friend of mine makes really powerful Amiga retro-fits based on an FPGA. Look for "apollo-accelerators.com".