Yes, it should operate as a pure text terminal for any text characters 00..$7F so that there is no unnecessary overhead. VT100 sequences are horrible and we can do something simpler and better. In Forth I can pass any number of space separated parameters on a stack and then execute a word which takes the parameters it needs and passes results back to the stack. There is no need however to have a word that needs to be entered and terminated since it can be a single unique character code that once encountered in a stream will execute the code associated with it using the stack. So there is no need to use Forth, it could be anything.
The text sequence (where the alphas are actually offset from $80) "100x50y300w200hr" could set the x y w h and then draw a rectangle. Maybe the alphas could be plain ASCII text but precede the string with a single control character (say $10) to force all single alphas on that line to execute as commands.
@ErNa - I forgot about that propterm and that's also somewhat similar to something that I wanted to write too for the same purpose.
@MJB - Yes, a browser would be great too. I will check it out.
Peter,
Just be aware that some of the wireless keyboards effectively sleep after a short time of no activity. It then takes a few seconds for it to get back up to speed to send the character(s) you typed. IIRC they were ~$30 from Officeworks with a wireless mouse too.
Browser will be great, but that also means some kind of Webserver in p2. This server needs to run some kind of GUI to the Browser. As there is input to the p2 from outside of the browser (mouse and keyboard via BT) there needs to be some kind of more complicated communication to make mouse movements and keyboard inputs visible in the browser. This is all possible but means to have more than just a dumb Webserver
Also the mouse needs to be implemented in the p2, not on the terminal layer. That also let me wish to have some kind of clipboad, that also needs to be on p2 layer because mouse is in the p2 layer.
Not using ansi like Terminal also means to implement a custom terminal emulation software
It will be very interesting for me to write such a program
I made some money years ago implementing terminal emulation for IBM machines in pc and amiga
...
@MJB - Yes, a browser would be great too. I will check it out.
Peter .. remember the extensions I did to your webserver for Spinneret with Tachyon 2.7 ...
It was actually based on a bidirectional character stream. Aka TCP but would run the same via serial.
Then the GUI can be created with dynamic HTML and Javascript using all the nice available widget sets etc. Like I demonstrated at that time.
May be time to port the old code ... or make s.th. better
...
@MJB - Yes, a browser would be great too. I will check it out.
Peter .. remember the extensions I did to your webserver for Spinneret with Tachyon 2.7 ...
It was actually based on a bidirectional character stream. Aka TCP but would run the same via serial.
Then the GUI can be created with dynamic HTML and Javascript using all the nice available widget sets etc. Like I demonstrated at that time.
May be time to port the old code ... or make s.th. better
I thought the idea behind a self-hosted development environment was to get away from complex operation systems that are out of our control. If you use a tablet you are relying on a complex, closed-source OS. Doesn't that sort of defeat the purpose? In addition, if you are using a web browser as an interface, those are notorious for being changed in incompatible ways that break existing applications.
A tablet is an LCD display with GPU and CPU and yes, an O/S. Is it complex? Yes it is. Is it easy to use and cheap? Yes. Yet I don't have the "source" to the P2 CPU and it is also complex. Should I not use it also then? I am not using an abc tablet for ideological reasons, my reasons are purely practical and what makes good sense. But unlike the P2 chip, these are non-critical peripherals that can be replaced with alternatives, just as they can replace conventional peripherals.
Browsers were mentioned and could be considered but despite the passing years they still render most standard stuff just fine.
Browser are pretty stable if you use basic things like html, JavaScript and Ajax. They get angry if you try to incorporate your own ways of data transfer or try to work around them.
Being able to have a IDE on the p2 and use it by just connect a browser via serial/tcp or BT will be a dream
I am not sure if a BT keyboard or Mouse connected to the P2 is necessary, but it will not be bad either
@"Peter Jakacki" is there a penalty for putting the HyperRam on another board on the other side of those DIP spaced connectors you have on the P2D2?
Unfortunately I won't be using any bluetooth thing like coding for endless hours. After about half an hour, I can feel bluetooth, & wifi as a dull ache from over exposure over the years. There are negative health effects to these things, unfortunately. It's gotta be all wired for me, otherwise it's no fun.
@Cluso99 Would 3 pins for the PS/2 keyboard and mouse work without having to hit the space bar or some such? Couldn't the difference in clocks be detected by a smart pin as 2 bits of resolution on an analog input with 2 different values of resistors?
Come to think of it, could you just put both the keyboard and mouse on 1 input pin with 4 bits of resolution?
Is data ever required to go the other way for things like the caps lock light or setting mouse resolution?
@"Peter Jakacki" is there a penalty for putting the HyperRam on another board on the other side of those DIP spaced connectors you have on the P2D2?
Unfortunately I won't be using any bluetooth thing like coding for endless hours. After about half an hour, I can feel bluetooth, & wifi as a dull ache from over exposure over the years. There are negative health effects to these things, unfortunately. It's gotta be all wired for me, otherwise it's no fun.
You can try putting HyperRAM anywhere you want but it has to be clocked at a very high speed so signal paths are kept short and tight. Is there a reason not to have the HyperRAM on the flip side of the P2D2?
As for BT, I know that these BT keyboards and mice are running on cheap AAA batteries that last a year or so and the range is only few metres, so it is really low power, maybe 1mW. How much power do you think it would have to be so that the "radiation" at arms length would be harmful? Do the maths.
Sunlight is extremely powerful radiation and if we bake in it for too long and repeatedly, we get skin cancer. But without this radiation we would die. Too little water and we die. Too much water and we drown. It's a jungle out there alright
The TV show "Monk" has the theme song which says in part:
People think I'm crazy, 'cause I worry all the time
If you paid attention, you'd be worried too
You better pay attention
Or this world we love so much might just kill you
I could be wrong now, but I don't think so!
'Cause there's a jungle out there.
It's a jungle out there.
source: https://www.lyricsondemand.com/tvthemes/monklyrics.html
@Cluso99 Would 3 pins for the PS/2 keyboard and mouse work without having to hit the space bar or some such? Couldn't the difference in clocks be detected by a smart pin as 2 bits of resolution on an analog input with 2 different values of resistors?
Come to think of it, could you just put both the keyboard and mouse on 1 input pin with 4 bits of resolution?
Is data ever required to go the other way for things like the caps lock light or setting mouse resolution?
You only require 1 data pin for the keyboard in PS2 mode. Both pins require a 10K pullup to 5V. Of course you will not get the Caps Lock etc LEDs to light as this is sent from the pc and you cannot do this without the clock pin connected. The space bar was required (at least once if the speed is saved in EEPROM/SDcard) because I found the speed was way off on some keyboards (back 8 years ago tho) so it was necessary to determine this for each keyboard.
I've not done anything with the mouse, but presume the same applies.
As for using a 3rd pin being a common clock for both the mouse and keyboard, what happens when they both send data (and clocks) at the same time? You're going to need to do some special decoding for it to work - possible but I don't see the point.
I had a specific need with P1 as I used 30 pins for SRAM/SD/EEPROM so I needed to get a keyboard and screen in those last 2 pins.
@Cluso99 Would 3 pins for the PS/2 keyboard and mouse work without having to hit the space bar or some such? Couldn't the difference in clocks be detected by a smart pin as 2 bits of resolution on an analog input with 2 different values of resistors?
Come to think of it, could you just put both the keyboard and mouse on 1 input pin with 4 bits of resolution?
Is data ever required to go the other way for things like the caps lock light or setting mouse resolution?
You only require 1 data pin for the keyboard in PS2 mode. Both pins require a 10K pullup to 5V. Of course you will not get the Caps Lock etc LEDs to light as this is sent from the pc and you cannot do this without the clock pin connected. The space bar was required (at least once if the speed is saved in EEPROM/SDcard) because I found the speed was way off on some keyboards (back 8 years ago tho) so it was necessary to determine this for each keyboard.
I've not done anything with the mouse, but presume the same applies.
As for using a 3rd pin being a common clock for both the mouse and keyboard, what happens when they both send data (and clocks) at the same time? You're going to need to do some special decoding for it to work - possible but I don't see the point.
I had a specific need with P1 as I used 30 pins for SRAM/SD/EEPROM so I needed to get a keyboard and screen in those last 2 pins.
The point was to make a VGA * PS/2 Keyboard And Mouse port that just plugged into the HDMI port without anything more than passives and connectors. That way we could standardize on the HDMI and for us that would rather have VGA a simple adapter would work.
With 2 clocks on the same pin, the keyboard could have a 470 Ohm resister and the mouse a 1K Ohm and just read it with A2D as 2 bits. That way I think we can have full PS/2 compatibility and full VGA in the same 8 pins that others use for just HDMI video out.
You can try putting HyperRAM anywhere you want but it has to be clocked at a very high speed so signal paths are kept short and tight. Is there a reason not to have the HyperRAM on the flip side of the P2D2?
I was afraid of that. I just was hoping to use your P2D2 to design a P2 Demo board and keep the expensive parts, in this case a pair of 32MB HyperRam's for double buffering 1080P video, on the lower board with all of the connectors and use your board for the P2 itself, the clock circuit and the boot micro. Either way, I think we need a P2 Demo board with standardized ports like the Propeller Demo board of old, but more capable, in fact capable enough to host it's own dev system.
As for BT, I know that these BT keyboards and mice are running on cheap AAA batteries that last a year or so and the range is only few metres, so it is really low power, maybe 1mW. How much power do you think it would have to be so that the "radiation" at arms length would be harmful? Do the maths.
Sunlight is extremely powerful radiation and if we bake in it for too long and repeatedly, we get skin cancer. But without this radiation we would die. Too little water and we die. Too much water and we drown. It's a jungle out there alright
Yeah, you would think so, wouldn't you, but different frequencies have different effects on the nervous system, and after a couple of weeks with a used phone I found and a Bluetooth speaker I inherited, I could feel it within half an hour. Some people can feel the update that happens in the middle of the night from their smart meters. Some people are so sensitive that they can tell if you have a cell phone on within 20 feet. The fact of the matter is that we do not know the long term effects of these higher frequencies we are using. I just know that I can feel bluetooth, and it doesn't feel good.
The p2 eval has the HyperRAM accessory board and that seems to work.
Isn't BT simply 2.4GHz??? What's different about that and wifi or microwave ovens and cordless phones and non-bt wireless keyboards and mice etc etc? That spectrum is well used.
@Cluso99 Would 3 pins for the PS/2 keyboard and mouse work without having to hit the space bar or some such? Couldn't the difference in clocks be detected by a smart pin as 2 bits of resolution on an analog input with 2 different values of resistors?
Come to think of it, could you just put both the keyboard and mouse on 1 input pin with 4 bits of resolution?
Is data ever required to go the other way for things like the caps lock light or setting mouse resolution?
You only require 1 data pin for the keyboard in PS2 mode. Both pins require a 10K pullup to 5V. Of course you will not get the Caps Lock etc LEDs to light as this is sent from the pc and you cannot do this without the clock pin connected. The space bar was required (at least once if the speed is saved in EEPROM/SDcard) because I found the speed was way off on some keyboards (back 8 years ago tho) so it was necessary to determine this for each keyboard.
I've not done anything with the mouse, but presume the same applies.
As for using a 3rd pin being a common clock for both the mouse and keyboard, what happens when they both send data (and clocks) at the same time? You're going to need to do some special decoding for it to work - possible but I don't see the point.
I had a specific need with P1 as I used 30 pins for SRAM/SD/EEPROM so I needed to get a keyboard and screen in those last 2 pins.
The point was to make a VGA * PS/2 Keyboard And Mouse port that just plugged into the HDMI port without anything more than passives and connectors. That way we could standardize on the HDMI and for us that would rather have VGA a simple adapter would work.
With 2 clocks on the same pin, the keyboard could have a 470 Ohm resister and the mouse a 1K Ohm and just read it with A2D as 2 bits. That way I think we can have full PS/2 compatibility and full VGA in the same 8 pins that others use for just HDMI video out.
OK, that makes more sense now.
Because the keyboard and mouse are both masters, but the lines can be turned around, I am not at all sure there is any way to make this work reliably. It would be easier to just use the keyboard with 1 pin and the space character. It's easy when starting a program to output to the screen a message to hit <space>. I do that when using the 1pin keyboard on my RamBlade.
Because the keyboard and mouse are both masters, but the lines can be turned around, I am not at all sure there is any way to make this work reliably. It would be easier to just use the keyboard with 1 pin and the space character. It's easy when starting a program to output to the screen a message to hit <space>. I do that when using the 1pin keyboard on my RamBlade.
What do you think of the idea of a passive adapter? Am I missing something critical, or can I just connect 5 wires for RGBHV to VGA and 1pin for keyboard and 2 for mouse and no resistors or anything? I'm asking because I have never used HDMI on the P2. In fact I haven't got a P2 because the P2Eval is so bloody expensive and to get the connectors too, it's $250 + shipping and you STILL don't get VGA & PS/2. I've been wanting a P2D2 for quite a while now, but it seems production still hasn't happened.
As for the RamBlad, I think I have one of those around here in a match box. Do you have a link for images for it that I can put on a microSD and play with it.
@hinv Some VGA monitors will accept less than 5 pins for VGA. Some will allow Sync on green (3 pins), more will allow a component sync on HSync, where H+V are xor'd together on a single pin. Depending on your monitor you could still potentially get 2 full PS/2 ports + VGA on 8 pins. Or in the longer run if you can use USB, once we get hubs supported you might be able to have both a USB KBD and USB mouse on just 2 USB pins plus the 3,4, or 5 VGA pins easily fitting inside the 8 pins for HDMI. Another option to save pins is 3 pin component video if you HDTV monitor accepts that (I know it's out of fashion now, not many monitors would have it).
You might still get HyperRAM working on another main board. The signal path lengths will be longer, but remember we are already getting HyperRAM working overclocked at 297MHz on the P2-EVAL through those 0.1 inch header connector pins a good inch from the P2 chip without signal matching, so there is hope for what you would like to do. P2D2 trace lengths are probably quite a bit shorter to the pins.
The p2 eval has the HyperRAM accessory board and that seems to work.
OK, now we're up to $350 for a system that still doesn't provide VGA & PS2 in order to do double buffered full res 1080p video. Has anybody tried running 2 HyperRam chips and doing double buffer like @cgracey talked about in his last video? What kind of bandwidth are they getting out of a single HyperRam chip? These are quite a ways away from the P2 and on the other side of a DIP connector as well. Are you getting a better performance on your HyperRam on the flip side of the propeller? Dare I ask if you are planning on doing a 2chip variant? I really don't want to delay production any further.
Isn't BT simply 2.4GHz??? What's different about that and wifi or microwave ovens and cordless phones and non-bt wireless keyboards and mice etc etc? That spectrum is well used.
WiFi and microwave ovens and the newer cordless phones do run in the 2.4GHz spectrum as well. I don't use any of these though.
The non-bt wireless keyboards I've seen commonly run in the 433MHz range and I don't use any of these either, but I think 433MHz is a lot safer.
Because the keyboard and mouse are both masters, but the lines can be turned around, I am not at all sure there is any way to make this work reliably. It would be easier to just use the keyboard with 1 pin and the space character. It's easy when starting a program to output to the screen a message to hit <space>. I do that when using the 1pin keyboard on my RamBlade.
What do you think of the idea of a passive adapter? Am I missing something critical, or can I just connect 5 wires for RGBHV to VGA and 1pin for keyboard and 2 for mouse and no resistors or anything? I'm asking because I have never used HDMI on the P2. In fact I haven't got a P2 because the P2Eval is so bloody expensive and to get the connectors too, it's $250 + shipping and you STILL don't get VGA & PS/2. I've been wanting a P2D2 for quite a while now, but it seems production still hasn't happened.
Just ignore HDMI. A passive adapter will just use those pins to connect directly to a VGA connector and PS2/USB or whatever.
Sure you can connect 1 pin for keyboard and 2 for the mouse. You will need 4 10K pullups to 5V although using internal P2 pullups to 3V3 may work. If only 3 pins are used, then the 4th pin (clock to keyboard) will require an external 10K pullup tho.
The caveat is that the keyboard speed either has to be pre-determined, or a <space> key pressed first to establish the speed or another method. Speed varies widely between keyboards of older PS2 style altho maybe the current USB/PS2 compatible keyboards might be better.
BTW I think Peter is intending to bring out 10 P2 pins, being the 4 channels plus the USB D+/- pair.
As for the RamBlad, I think I have one of those around here in a match box. Do you have a link for images for it that I can put on a microSD and play with it.
The p2 eval has the HyperRAM accessory board and that seems to work.
OK, now we're up to $350 for a system that still doesn't provide VGA & PS2 in order to do double buffered full res 1080p video. Has anybody tried running 2 HyperRam chips and doing double buffer like @cgracey talked about in his last video? What kind of bandwidth are they getting out of a single HyperRam chip? These are quite a ways away from the P2 and on the other side of a DIP connector as well. Are you getting a better performance on your HyperRam on the flip side of the propeller? Dare I ask if you are planning on doing a 2chip variant? I really don't want to delay production any further.
Isn't BT simply 2.4GHz??? What's different about that and wifi or microwave ovens and cordless phones and non-bt wireless keyboards and mice etc etc? That spectrum is well used.
WiFi and microwave ovens and the newer cordless phones do run in the 2.4GHz spectrum as well. I don't use any of these though.
The non-bt wireless keyboards I've seen commonly run in the 433MHz range and I don't use any of these either, but I think 433MHz is a lot safer.
I respect that each of us can choose whether we do this or do that. But merely "thinking" or "feeling" something is safe or unsafe is always a matter of personal opinion.
The P2D2+ has HyperRAM and 4-bit 8MB PSRAM if that helps but it also has a 24-pin USB-C connector with 10 smartpins routed to it and intended to provide HDMI or VGA as well as USB etc. I have little breakout dongles that plug directly into the monitors so that I only need a single USB-C cable.
Has anybody tried running 2 HyperRam chips and doing double buffer like @cgracey talked about in his last video? What kind of bandwidth are they getting out of a single HyperRam chip?
Well if you overclock I know you can probably get 297MB/s of total read bus bandwidth excluding overheads. My driver is able to operate at that rate with a single HyperRAM device with the P2-EVAL breakout board. Of course overheads are going to be introduced by both software and hardware which reduces the bandwidth. Hardware needs address setup and extra latency clocks, plus some minimum chip select high time. Software needs time to poll for incoming requests, process them and take action using the IO pins and streamer & fifo config etc. The maximum bandwidth occurs when you keep the CS pin low as long as refresh allows (~4uS). In general a rough rule of thumb I found with my own driver clocked at P2 rates of around 250MHz or so, is there is about 1us of overhead for 4us of transfers if you do single transfers. So you can get around 80% bus utilization (it will be a bit higher if the requests all come from the same COG and you don't need to re-poll). However with a single HyperRAM you do need to share this bandwidth between video reading and other COGs reading/writing data. Writes are far easier to achieve at sysclk/2 compared to sysclk/1. So if you are running the video resolution at 1080p with sysclk/1 reads and you need to read in 1920 bytes per scanline, you would need to sustain 130MB/s to service the video reads. This could be achieved in 2 burst reads of 960 bytes each, probably taking around 8.2us or so. The remaining 6.6us is then available for other writes or other reads, which is something in the vicinity of 20MB/s EDIT: 46MB/s worth of writes but it will depend on actual burst size used. It's not full frame update rate at this resolution if you wanted that, but it could be so for lower resolutions/depths. Once you go down to more reasonable resolutions like VGA/SVGA etc, the video read requirements drop and more bandwidth is available for other COGs.
The dual HyperRAM approach is not something I've experimented with to date as I only have one HyperRAM breakout module but it could certainly offer increased performance if you decide to alternate frames between chips. It will cost at least an extra 11 P2 pins for this, or 16 if you use P2-EVAL HyperRAM board breakouts.
I don't see any problems with actually using all those pins on P2 to do what it can do - drive two low-speed single-device USB hosts, driving a HDMI display. So what that the entire one port is used up? What else would you do with it? It's a "PC". A closed box. Peripherals are extra, right? And you've already got a humongous set of peripherals compared to what came "standard" on a PC. You're already talking two high complexity serial ports, a digital display port, a dedicated storage port (SD, not another USB host), ... - that's a lot you can do with!
As for memory: given the speed of peripherals, I wouldn't bother with HyperRAM for a basic system. If you can live with lower display resolution and color depth, then P2's RAM should be plenty, given that SD mass storage is so fast. Think of it like this: original PC software ran just fine using color text mode, or say Hercules graphics. That will fit into the hub RAM no problem, just as it did on the 8086. Lots of larger software ran overlays back in those days, e.g. WordStar as well as Turbo Pascal and the applications developed in it - both on CP/M and early MS-DOS. The difference is that in the time it takes to load a few sectors from one track on a floppy on an original PC, we can load or store the entire HUB ram from/to SD card, several times over most of the time.
So I wouldn't fret at at all: if you want 32-bit 720p HDMI output, you'll need additional graphics RAM, and thus HyperRAM comes into play, and the pin resources it consumes. No different than what was needed with a better graphics card: it came with its frame RAM.
There's still enough pins left on the other port for RMII connection to a 100MBit Ethernet PHY, and smartpin DAC/ADC audio, and you've got yourself a rather nifty little computer. Not too shabby, I'd say. But one really doesn't need to start with the assumption that P2 would be emulating what amounts to a modern PC, at least resolution-wise. Such resolutions were mostly a pipe dream in the 80s well into the 90s in the consumer space, and everyone did relatively fine without 1k on their display.
Let's not forget that display density is coupled with other resources - it doesn't help to have high-res display if there simply aren't enough resources on P2 to do much useful with it in terms of driving it with dynamic, interactive content. On that note: it'd be fun if P2 could do 3-component distance field text rendering in realtime with a minimal resolution HDMI output (perhaps with several cogs doing it in parallel). Font representations are quite compact such representation, and are almost infinitely scalable with the cost being fixed *per output pixel* - so ideal for Propeller-like systems. A basic 64-glyph font would fit into 16kb of RAM without trying too hard, while rendering about as well as an unhinted Type 1 font would, at any size, without any curve processing. Distance fields are trivial to decode compared to any other scalable font representation - even compared to vector outline fonts rendered in "wireframe" mode i.e. without polygon filling.
I was thinking of what is not a closed box, but a strong common platform for which to develop a nice programming environment and have IO's for expansion/experimentation/controlling/monitoring.
Perhaps take a look at the Color Maximite 2 Platform. They offer a 8bit micro like box with nice features and IO based on an Arm Cortex. Offers Basic interpreter, an IDE and complete operation over Terminal emulation. I wish it was using the P2
Perhaps take a look at the Color Maximite 2 Platform. They offer a 8bit micro like box with nice features and IO based on an Arm Cortex. Offers Basic interpreter, an IDE and complete operation over Terminal emulation. I wish it was using the P2
That is pretty neat!
Getting away from the big-OS/platform beast is sure attractive.
Perhaps take a look at the Color Maximite 2 Platform. They offer a 8bit micro like box with nice features and IO based on an Arm Cortex. Offers Basic interpreter, an IDE and complete operation over Terminal emulation. I wish it was using the P2
That is pretty neat!
Getting away from the big-OS/platform beast is sure attractive.
Yes.
I do support @"Peter Jakacki" in using the ES32 but I disagree with any usage of a browser as Desktop. The point is to get away from all of this. Longtime.
So PS/2 Keyboards will not do it, it has to be USB, Monitor Output from the P2 should not be a problem for the foreseeable future,, as long as we have Hyperram for the Display memory.
I am not sure why more then one Hyperram would be needed, but if @rogloh want to test something I can test with 2 Hyperrams on 2 different rev B boards.
But to get away from big-OS/platform issues, in a world where more and more of your 'Personal Computer' is not so "Personal' at all and all them hurdles even Parallax has now to get thru to get Pnut not deleted, I am very sure it will get worse.
So that is the basic reason for a P2PC.
That would require to get native compilers on the P2 or we all have to learn FORTH. I asked @ersmith about the possibility of compiling fastspin for P2 and he said that he might be able to do so, but it would be quite slow. Too less memory.
@RossH still supports XMM in C for the P1 but currently sees no need to support XMM with Hyperram on the P2, but said that it basically is a maybe if needed.
I forgot to ask if his compiler would be able to compile itself for the P2.
Getting GCC running on the P2 itself seems to be impossible.
That leaves @cgracey to think about reading bytecodes from hyperram and not from hub. As far as I understand Spin Bytecode is complete relocatable by design. thus some form of paging/caching of methods should be possible.
And - hmm - rewrite the compiler it in C or SPIN2.
Or the last two options, either @Cluso99 extends his Z80 emulator to x386 or @"Peter Jakacki" just writes one in TAQOZ.
MMBasic on Micromite/plus/extreme, picromite and CMM2 is very nice .... and also powerful to a certain degree.
Now on extreme/picromite and CMM2 perhaps is not an issue but on smaller series like micromite/plus the onboard compiler limits the program size. Infact the MMBasic have a buffer for the plain text code that get then compiled to tokens and this limit the size. I would prefer to have an external compiler and then download the compiled tokens to the platform like eg basicstamp or picaxe. Infact most of the people use external editors (MMEdit, Notepad++) anyway.
The greatest thing of MMBasic is the CFunctions that allows to "create" new commands (functions or subs) written in assembler (or compiled C) which allows to add fast commands based on the project you are actually working on.
Perhaps MMBasic could be ported to the P2 too (the source is freely available from the author upon request). This will open sales to en other community that is focused on the product (MMBasic) rather than on underlying platform/architecture.
Comments
The text sequence (where the alphas are actually offset from $80) "100x50y300w200hr" could set the x y w h and then draw a rectangle. Maybe the alphas could be plain ASCII text but precede the string with a single control character (say $10) to force all single alphas on that line to execute as commands.
@ErNa - I forgot about that propterm and that's also somewhat similar to something that I wanted to write too for the same purpose.
@MJB - Yes, a browser would be great too. I will check it out.
Just be aware that some of the wireless keyboards effectively sleep after a short time of no activity. It then takes a few seconds for it to get back up to speed to send the character(s) you typed. IIRC they were ~$30 from Officeworks with a wireless mouse too.
That's an old thread.
Also the mouse needs to be implemented in the p2, not on the terminal layer. That also let me wish to have some kind of clipboad, that also needs to be on p2 layer because mouse is in the p2 layer.
Not using ansi like Terminal also means to implement a custom terminal emulation software
It will be very interesting for me to write such a program
I made some money years ago implementing terminal emulation for IBM machines in pc and amiga
Peter .. remember the extensions I did to your webserver for Spinneret with Tachyon 2.7 ...
It was actually based on a bidirectional character stream. Aka TCP but would run the same via serial.
Then the GUI can be created with dynamic HTML and Javascript using all the nice available widget sets etc. Like I demonstrated at that time.
May be time to port the old code ... or make s.th. better
Something like that will be cool 😎
Browsers were mentioned and could be considered but despite the passing years they still render most standard stuff just fine.
Being able to have a IDE on the p2 and use it by just connect a browser via serial/tcp or BT will be a dream
I am not sure if a BT keyboard or Mouse connected to the P2 is necessary, but it will not be bad either
Unfortunately I won't be using any bluetooth thing like coding for endless hours. After about half an hour, I can feel bluetooth, & wifi as a dull ache from over exposure over the years. There are negative health effects to these things, unfortunately. It's gotta be all wired for me, otherwise it's no fun.
Come to think of it, could you just put both the keyboard and mouse on 1 input pin with 4 bits of resolution?
Is data ever required to go the other way for things like the caps lock light or setting mouse resolution?
You can try putting HyperRAM anywhere you want but it has to be clocked at a very high speed so signal paths are kept short and tight. Is there a reason not to have the HyperRAM on the flip side of the P2D2?
As for BT, I know that these BT keyboards and mice are running on cheap AAA batteries that last a year or so and the range is only few metres, so it is really low power, maybe 1mW. How much power do you think it would have to be so that the "radiation" at arms length would be harmful? Do the maths.
Sunlight is extremely powerful radiation and if we bake in it for too long and repeatedly, we get skin cancer. But without this radiation we would die. Too little water and we die. Too much water and we drown. It's a jungle out there alright
The TV show "Monk" has the theme song which says in part:
You only require 1 data pin for the keyboard in PS2 mode. Both pins require a 10K pullup to 5V. Of course you will not get the Caps Lock etc LEDs to light as this is sent from the pc and you cannot do this without the clock pin connected. The space bar was required (at least once if the speed is saved in EEPROM/SDcard) because I found the speed was way off on some keyboards (back 8 years ago tho) so it was necessary to determine this for each keyboard.
I've not done anything with the mouse, but presume the same applies.
As for using a 3rd pin being a common clock for both the mouse and keyboard, what happens when they both send data (and clocks) at the same time? You're going to need to do some special decoding for it to work - possible but I don't see the point.
I had a specific need with P1 as I used 30 pins for SRAM/SD/EEPROM so I needed to get a keyboard and screen in those last 2 pins.
The point was to make a VGA * PS/2 Keyboard And Mouse port that just plugged into the HDMI port without anything more than passives and connectors. That way we could standardize on the HDMI and for us that would rather have VGA a simple adapter would work.
With 2 clocks on the same pin, the keyboard could have a 470 Ohm resister and the mouse a 1K Ohm and just read it with A2D as 2 bits. That way I think we can have full PS/2 compatibility and full VGA in the same 8 pins that others use for just HDMI video out.
I was afraid of that. I just was hoping to use your P2D2 to design a P2 Demo board and keep the expensive parts, in this case a pair of 32MB HyperRam's for double buffering 1080P video, on the lower board with all of the connectors and use your board for the P2 itself, the clock circuit and the boot micro. Either way, I think we need a P2 Demo board with standardized ports like the Propeller Demo board of old, but more capable, in fact capable enough to host it's own dev system.
Yeah, you would think so, wouldn't you, but different frequencies have different effects on the nervous system, and after a couple of weeks with a used phone I found and a Bluetooth speaker I inherited, I could feel it within half an hour. Some people can feel the update that happens in the middle of the night from their smart meters. Some people are so sensitive that they can tell if you have a cell phone on within 20 feet. The fact of the matter is that we do not know the long term effects of these higher frequencies we are using. I just know that I can feel bluetooth, and it doesn't feel good.
Isn't BT simply 2.4GHz??? What's different about that and wifi or microwave ovens and cordless phones and non-bt wireless keyboards and mice etc etc? That spectrum is well used.
Because the keyboard and mouse are both masters, but the lines can be turned around, I am not at all sure there is any way to make this work reliably. It would be easier to just use the keyboard with 1 pin and the space character. It's easy when starting a program to output to the screen a message to hit <space>. I do that when using the 1pin keyboard on my RamBlade.
What do you think of the idea of a passive adapter? Am I missing something critical, or can I just connect 5 wires for RGBHV to VGA and 1pin for keyboard and 2 for mouse and no resistors or anything? I'm asking because I have never used HDMI on the P2. In fact I haven't got a P2 because the P2Eval is so bloody expensive and to get the connectors too, it's $250 + shipping and you STILL don't get VGA & PS/2. I've been wanting a P2D2 for quite a while now, but it seems production still hasn't happened.
As for the RamBlad, I think I have one of those around here in a match box. Do you have a link for images for it that I can put on a microSD and play with it.
Thanks,
hinv
You might still get HyperRAM working on another main board. The signal path lengths will be longer, but remember we are already getting HyperRAM working overclocked at 297MHz on the P2-EVAL through those 0.1 inch header connector pins a good inch from the P2 chip without signal matching, so there is hope for what you would like to do. P2D2 trace lengths are probably quite a bit shorter to the pins.
WiFi and microwave ovens and the newer cordless phones do run in the 2.4GHz spectrum as well. I don't use any of these though.
The non-bt wireless keyboards I've seen commonly run in the 433MHz range and I don't use any of these either, but I think 433MHz is a lot safer.
Sure you can connect 1 pin for keyboard and 2 for the mouse. You will need 4 10K pullups to 5V although using internal P2 pullups to 3V3 may work. If only 3 pins are used, then the 4th pin (clock to keyboard) will require an external 10K pullup tho.
The caveat is that the keyboard speed either has to be pre-determined, or a <space> key pressed first to establish the speed or another method. Speed varies widely between keyboards of older PS2 style altho maybe the current USB/PS2 compatible keyboards might be better.
BTW I think Peter is intending to bring out 10 P2 pins, being the 4 channels plus the USB D+/- pair.
https://forums.parallax.com/discussion/comment/1469836/#Comment_1469836
https://forums.parallax.com/discussion/116893/ramblade-prop-sram-microsd-addon-to-run-zicog-cpm-propdos-catalina-etc/p1
I respect that each of us can choose whether we do this or do that. But merely "thinking" or "feeling" something is safe or unsafe is always a matter of personal opinion.
The P2D2+ has HyperRAM and 4-bit 8MB PSRAM if that helps but it also has a 24-pin USB-C connector with 10 smartpins routed to it and intended to provide HDMI or VGA as well as USB etc. I have little breakout dongles that plug directly into the monitors so that I only need a single USB-C cable.
Well if you overclock I know you can probably get 297MB/s of total read bus bandwidth excluding overheads. My driver is able to operate at that rate with a single HyperRAM device with the P2-EVAL breakout board. Of course overheads are going to be introduced by both software and hardware which reduces the bandwidth. Hardware needs address setup and extra latency clocks, plus some minimum chip select high time. Software needs time to poll for incoming requests, process them and take action using the IO pins and streamer & fifo config etc. The maximum bandwidth occurs when you keep the CS pin low as long as refresh allows (~4uS). In general a rough rule of thumb I found with my own driver clocked at P2 rates of around 250MHz or so, is there is about 1us of overhead for 4us of transfers if you do single transfers. So you can get around 80% bus utilization (it will be a bit higher if the requests all come from the same COG and you don't need to re-poll). However with a single HyperRAM you do need to share this bandwidth between video reading and other COGs reading/writing data. Writes are far easier to achieve at sysclk/2 compared to sysclk/1. So if you are running the video resolution at 1080p with sysclk/1 reads and you need to read in 1920 bytes per scanline, you would need to sustain 130MB/s to service the video reads. This could be achieved in 2 burst reads of 960 bytes each, probably taking around 8.2us or so. The remaining 6.6us is then available for other writes or other reads, which is something in the vicinity of 20MB/s EDIT: 46MB/s worth of writes but it will depend on actual burst size used. It's not full frame update rate at this resolution if you wanted that, but it could be so for lower resolutions/depths. Once you go down to more reasonable resolutions like VGA/SVGA etc, the video read requirements drop and more bandwidth is available for other COGs.
The dual HyperRAM approach is not something I've experimented with to date as I only have one HyperRAM breakout module but it could certainly offer increased performance if you decide to alternate frames between chips. It will cost at least an extra 11 P2 pins for this, or 16 if you use P2-EVAL HyperRAM board breakouts.
As for memory: given the speed of peripherals, I wouldn't bother with HyperRAM for a basic system. If you can live with lower display resolution and color depth, then P2's RAM should be plenty, given that SD mass storage is so fast. Think of it like this: original PC software ran just fine using color text mode, or say Hercules graphics. That will fit into the hub RAM no problem, just as it did on the 8086. Lots of larger software ran overlays back in those days, e.g. WordStar as well as Turbo Pascal and the applications developed in it - both on CP/M and early MS-DOS. The difference is that in the time it takes to load a few sectors from one track on a floppy on an original PC, we can load or store the entire HUB ram from/to SD card, several times over most of the time.
So I wouldn't fret at at all: if you want 32-bit 720p HDMI output, you'll need additional graphics RAM, and thus HyperRAM comes into play, and the pin resources it consumes. No different than what was needed with a better graphics card: it came with its frame RAM.
There's still enough pins left on the other port for RMII connection to a 100MBit Ethernet PHY, and smartpin DAC/ADC audio, and you've got yourself a rather nifty little computer. Not too shabby, I'd say. But one really doesn't need to start with the assumption that P2 would be emulating what amounts to a modern PC, at least resolution-wise. Such resolutions were mostly a pipe dream in the 80s well into the 90s in the consumer space, and everyone did relatively fine without 1k on their display.
Let's not forget that display density is coupled with other resources - it doesn't help to have high-res display if there simply aren't enough resources on P2 to do much useful with it in terms of driving it with dynamic, interactive content. On that note: it'd be fun if P2 could do 3-component distance field text rendering in realtime with a minimal resolution HDMI output (perhaps with several cogs doing it in parallel). Font representations are quite compact such representation, and are almost infinitely scalable with the cost being fixed *per output pixel* - so ideal for Propeller-like systems. A basic 64-glyph font would fit into 16kb of RAM without trying too hard, while rendering about as well as an unhinted Type 1 font would, at any size, without any curve processing. Distance fields are trivial to decode compared to any other scalable font representation - even compared to vector outline fonts rendered in "wireframe" mode i.e. without polygon filling.
That is pretty neat!
Getting away from the big-OS/platform beast is sure attractive.
Yes.
I do support @"Peter Jakacki" in using the ES32 but I disagree with any usage of a browser as Desktop. The point is to get away from all of this. Longtime.
So PS/2 Keyboards will not do it, it has to be USB, Monitor Output from the P2 should not be a problem for the foreseeable future,, as long as we have Hyperram for the Display memory.
I am not sure why more then one Hyperram would be needed, but if @rogloh want to test something I can test with 2 Hyperrams on 2 different rev B boards.
But to get away from big-OS/platform issues, in a world where more and more of your 'Personal Computer' is not so "Personal' at all and all them hurdles even Parallax has now to get thru to get Pnut not deleted, I am very sure it will get worse.
So that is the basic reason for a P2PC.
That would require to get native compilers on the P2 or we all have to learn FORTH. I asked @ersmith about the possibility of compiling fastspin for P2 and he said that he might be able to do so, but it would be quite slow. Too less memory.
@RossH still supports XMM in C for the P1 but currently sees no need to support XMM with Hyperram on the P2, but said that it basically is a maybe if needed.
I forgot to ask if his compiler would be able to compile itself for the P2.
Getting GCC running on the P2 itself seems to be impossible.
That leaves @cgracey to think about reading bytecodes from hyperram and not from hub. As far as I understand Spin Bytecode is complete relocatable by design. thus some form of paging/caching of methods should be possible.
And - hmm - rewrite the compiler it in C or SPIN2.
Or the last two options, either @Cluso99 extends his Z80 emulator to x386 or @"Peter Jakacki" just writes one in TAQOZ.
Then we can use Chips code directly.
I want one,
Mike
Now on extreme/picromite and CMM2 perhaps is not an issue but on smaller series like micromite/plus the onboard compiler limits the program size. Infact the MMBasic have a buffer for the plain text code that get then compiled to tokens and this limit the size. I would prefer to have an external compiler and then download the compiled tokens to the platform like eg basicstamp or picaxe. Infact most of the people use external editors (MMEdit, Notepad++) anyway.
The greatest thing of MMBasic is the CFunctions that allows to "create" new commands (functions or subs) written in assembler (or compiled C) which allows to add fast commands based on the project you are actually working on.
Perhaps MMBasic could be ported to the P2 too (the source is freely available from the author upon request). This will open sales to en other community that is focused on the product (MMBasic) rather than on underlying platform/architecture.