Say we have a demo program running on VGA, and it's developed with the monitor in mind. Origin = +16 or 32K, something like that.
It's running, user enters monitor, uploads TV code for the display, kills off the VGA COG, fires up the TV COG and the demo program is none the wiser. Or, just add the TV, and have both going.
This kind of thing done as a "how to", just for perspective, what can be done, how it works, why it could be done, is high value for some people who may be engineering fairly crazy things. Or, maybe one day they are fixing broken things, hacking. This kind of education needs to be out there. It's not necessary for people to do it, but it is definitely important those who can or want to get an opportunity, or even know about these ways and means.
And, BTW, Peter does this kind of thing all day long. It's one of the super powers in Forth. Still, few will be working in Forth, so we might as well show them the lower level lay of the land in the more mainstream sense.
Finally, whether we intend it or not, this chip is a little computer. People are gonna use it that way. I plan to, and have been building up some stuff for that purpose. As a bench computer, doing these kinds of things are fairly low cost and risk, but very high value.
I'll shut up about that now.
Just so everyone knows, I changed careers again. Fourth one! Well, sort of. It's a return to what I have done for many years, but in a new context.
One nice thing is some product design is going on and it's using Propeller 1 chips. Super cool.
Left my higher level executive role, mostly business, product design, with some cool R&D I got to help with / supervise, and am in a startup related to additive manufacturing. Message me, if you want to chat some. I don't see a need to drop names here.
Short story there is I am returning to a place where Prop chips, this idea of a bench computer, etc... are all becoming increasingly relevant again. Super happy about it. But, it's a startup too. Lots of all hours work. Pay off should be good though, and I need it.
All of this is true but there is much higher value in having a programmable monitor.
David, I do agree. Maybe you didn't see all my contribution yet, but I'm actually a strong advocate for getting something programmable "in the can" built in, available no matter what, and that whatever it is, offers a simple jump vector / command parser "hook" to allow it to be extended with an upload too.
I'm all for Tachyon, if Peter is game. That could be a very compelling package. And it's ON CHIP, literally.
However, if we don't go there, then yes! Make sure the ROM code can be extended simply.
Ideally, we get to a point where we have a subset of SPIN+PASM, very similar to Pnut today available to be uploaded and hooked into the ROM code, whatever that is. I think this should be done no matter what we put in the ROM.
Basically, port Pnut to the P2, have it work over serial. (a self-hosted display could be done too, and done later with code written on the Pnut for P2)
If it's kept super lean, and it's considered the "on chip", self-hosted tool chain, drivers, and other important code, much of which will be library code eventually, can be written.
This package can get "done" in the sense of it not needing changes, and compatability with code sits right at the top of the feature list.
If we do that, and we stick to it, the body of code that gets written on this small, simple, lean platform will be very useful over very long periods of time, similar to how the P1 OBEX has proven out.
Honestly, it's one of the highest value things we can do.
Other language needs / features / etc... can and will get done, and they will be done in the mainstream way, using a PC + IDE, build, upload, run. All familiar.
The little self-hosted environment won't be as feature rich, but it won't need to be either.
Think of it a lot like "prop tool" for P2, running over serial. Everything else can and likely will support that feature set and syntax. It's stable, "done" in the sense of being feature complete enough to be practical.
Anyone learning that set of software tools is set! Won't change. Writing software on that should be useful for applications, but also useful as library code on all the stuff that will follow and that will change frequently.
Given we are off the path here, doing a non-standard type of chip, having a baseline software / dev stack is super important. It needs to be stable, "done" in the sense I am trying to articulate here (badly it seems this morning).
If it's seen like 'ROM' code is, stable, and all that, people will write drivers and stuff with it, and that's the value right there. Once people learn it, targeting the basics will happen and make sense.
Maybe think of it as the root of a very big tree to come. A tree we won't know the shape of, or it's branches or any of that.
This root, or trunk, will end up being common, and code written with it, used all over the place, P1 OBEX style.
My fear, should we not do a simple "self-hosted" set of tools, Pnut with minimum SPIN in it basically, is the basics, library code like we saw happen with P1, won't happen again. And we lose out, because the barrier to entry is too high to use the P2.
P1 had this happen because there was no choice, and SPIN+PASM were super simple, easy. P2, can have it happen, can have a super lean, easy SPIN+PASM, like P1 did too.
So, I think it should happen. That way, we've got a real shot at doing the OBEX again. If it happens that way, P2 is gonna be a win, like P1 is. By that, I mean anyone who takes a look at a P1, wants to do something, has a great body of code available to them and it requires very little to get going. We need that to be true again.
...So, I think it should happen. That way, we've got a real shot at doing the OBEX again. If it happens that way, P2 is gonna be a win, like P1 is. By that, I mean anyone who takes a look at a P1, wants to do something, has a great body of code available to them and it requires very little to get going. We need that to be true again.
Amen. This can't be overstated. At this point, the R&D and design years Parallax has sunk into the P2 demand a return. This latest development direction is great stuff. If the available 14K space is enough, leverage it into something appealing that directly results in more sales.
even if it is FORTH, we do not need to tell anybody , like the Arduino calls C++ sketches, we could call it something else like openboot or TACHYON-boot?.
One thing speaking for FORTH is the build in extensibility, that Jump vector out of the monitor @potatohead mentioned is there already.
So what we would need for experiments is a minimalistic TACHYON kernel to squirt via serial into P2-FPGAs or simulated with spinsim for us poor FPGA less folks.
And a base directory containing the debugger commands used by P2-Hot. That was thought out pretty well. Sure if @Peter could fit in his SD card stuff even better. But on the end it is not more complicated to connect a flash to the P2 as to connect a SD socket.
As to the question if @Peter is able and willing to do that? My guess is that he is definitive able to do that, if he is willing too, I can't say. But I have the strong feeling he would be interested in doing that.
I see the Prop2 resources and their needed monitor interactions as follows:
1) Hub RAM: read/write and launch cogs from
2) Cogs: start, stop, and poll
3) Smart pins: configure and poll
If a monitor just gave you access to the above, the chip could be used right away in applications where just a bunch of smart pins were needed. Add some cog code and you've got real-time processing. Build apps and you've got stand-alone products.
I do not see Configure PLL in that list, but maybe it is inferred in the broader prose.. ?
A monitor would be about 3KB of code. It could be built-in, for greatest ease of use, but remember that a 4KB squirt of data could load that same monitor using Prop_Txt via the serial boot protocol.
That squirt is a copy/paste-able chunk of text that could easily be administered by a larger system. And, it could be upgraded, as needed, then.
Then, there's total flexibility. On the other hand, a nice little monitor in ROM could become a mainstay, and once people want more, they can squirt a better one in.
I think there would be value in having a monitor built into ROM. For early sales, this might be more important than code protection.
Yes, something simple and reliable makes sense, and then you can update it.
Fast Chip and POST testing should be a focus. eg Bare board testing can be 'built in' here...
If you can have the Loader check Flash Tables, then all of this can be preloaded into the Flash, and it appears just like it was in ROM.
Nothing to copy or paste, (tho that still works...) just connect to a Parallax Host and it checks and updates the firmware lists, and the user chooses a default.
Becomes very plug and play like.
With everything serialized, (via that Unique Flash ID) you can even have spreadsheets showing the corporate defaults...
Large Flash is very cheap, 16MBit is now the price-knee, and that will only move up. That represents a lot of spare space, above a Max 512k P2 image.
Software is one of Parallax's strengths, so the ROM really should be designed to support that, as a P2+Flash eco system.
...
All of this is true but there is much higher value in having a programmable monitor. I suppose you'll argue that that can just be downloaded but then so can the simple monitor.
True - to me, the finite time to reset and restart is why simple, basic things like resource access should be in initial ROM.
Things like PLL, Smart Pins, and all Memory (including SPI Flash Read) should be booter-accessible, as this allows Rapid Testing, and that saves everyone money.
Rapid Testing is why I have PLL access high on the list.
Anything above that is icing, and can be loaded later.
I'd like the ROM to be smart enough to read the flash, and load a user-chosen default, so a Serial-Send is NOT mandated.
Systems WILL have spare flash, and this 'looks' like many ROMs to the final user.
I wrote an extended Monitor/Debugger for the pre-P2HOT that used LMM before we had hubexec. I'll dig out the specs later today and post them.
I'd also like to see an optional SD FAT32 driver available. My P1 has been running fine for years!
Hm.. the console 'monitor' for Sun machines was Forth. But I didn't notice at the time, it worked like a traditional monitor program for me. So was it really just a non-programmable monitor that happened to be written in Forth, or was it (programmable) Forth that looked like a monitor?
It was programmable. A version of Pong was made for MacHack '98.
"Taking second place was OFPong by Marcus Jager and Quinn "The Eskimo!". OFPong is an implementation of the classic "Pong" game, written entirely in Open Firmware, the Macintosh boot-strap environment. As your machine is booting you can take a break for a quick game and then continue booting up." http://www.hax.com/MacHack/BestOf98.html
Here were the commands for my pre-P2Hot LMM debugger/monitor.
The debugger was designed also to be able to be called as routines from user programs, with the debugger remaining in hub and used minimal cog longs as an interface and LMM runtime. Of course, the LMM Runtime is no longer required as hubexec is built-in to the new P2.
A disassembler was also inbuilt too.
=== Cluso's P2v10a Debugger v.110x ===",$0D,0
------------ Help -----------------------------------------------------------
[[#]xxxxxxxx][.yyyyy][,[$]ccccc]z[m]<cr> <-- command format
-----1----- ---2-- -----3--- 4 5 --6- <-- parameter no.
...where...
1: # xx xx xx xx = an immediate byte/word/long value (spaces optional)
# xxxxxxxx = stored as a long (spaces mean little endian order)
xxxxx = from address (hex) where <$200 is in cog, else hub
2: . yyyyy = to address (hex) where <$200 is in cog, else hub
3: , $ ccccc = (hex) count/length
, ccccc = (decimal) count/length
4: z = (single char) command ( ? - G L M P Q V )
5: m = (single char) command modifier (command specific)
6: <cr> = <enter> key
? HELP: Show this text
- STORE: to {addr1} the following {byte(s)}|{word(s)}|{long(s)}
G GOTO: Goto cog {addr1} (if {addr1} omitted, return to user program)
COGINIT {addr1}:{par2} for COGID {m5}
{m5} omitted = this cog; 0..7 = cog 0..7; * = next avail cog
L LIST: from cog/hub {addr1} to {addr2}
from cog/hub {addr1} for {count3}|{length3}
L = L0 = bytes + ascii; L1 = bytes; L2 = code; L3 = long
M MOVE: from cog/hub {addr1} to cog/hub {addr2} for {Count3}|{length3}
FILL #{immediate1} to cog/hub {addr2} for {count3}|{length3}
P PORT: Show port status
Q QUIT: Quit user program and run the Rom Monitor
V VIEW: View the variables (special for Sapieha)
------------------------------------------------------------------------------
I also have an Interactive P2 debugger that uses the hardware single step and supports hub/cog/lut examination, IO pin control, flag modify ,watchlists and full V24 disassembly .
Hardware stack examination is supported too.
It's already running on V24 on all FPGA images and has been my "go to" utility to test P2.
I also have an Interactive P2 debugger that uses the hardware single step and supports hub/cog/lut examination, IO pin control, flag modify ,watchlists and full V24 disassembly .
Hardware stack examination is supported too.
It's already running on V24 on all FPGA images and has been my "go to" utility to test P2.
What size is that ?
Can it morph with the bootloader ?
Yes, we'd need a 'Prop_PLL 0 0 0 0 x' where x is the 32-bit value to write to the CLKSET.
Thinking about the use of this, can it echo a char, just before it loads the PLL ?
Use example A - suit PCs
IN: '>Prop_PLL 0 0 0 0 x'
OUT: '.' at 20MHz RCFAST Auto-baud
User Changes baud, and waits short delay
IN: '>Prop_PLL 0 0 0 0 x'
OUT: '.' now at PLL Auto-baud
Use example B - suit local MCU
IN: '>Prop_PLL 0 0 0 0 x'
OUT: '.' at 20MHz RCFAST Auto-baud
User Changes baud, then sends many autobaud chars to cover PLL settling time.
IN: '>>>>>>>>>>>>>>>>>>>>>>>>>>Prop_txt'
^^^^^ PLL Done sometime here
Is it safe to load the PLL in one command, (self timed ? )
I made an SBus graphics card and had to put Forth bytecodes into an onboard memory. Not being a Forth programmer I just did the bare minimum plus drew a company logo.
I will be firing up my FPGAs with the latest image and updating Tachyon anyway so we will see where this takes us. Since it would be good if Tachyon could be utilized in the spare memory of the boot ROM on top of the loader and monitor, I will be aiming to see what useful functionality I can achieve with less than 14k. This would nonetheless include SD FAT32 capabilities so at the very least we can find a file and load it as a binary, or even as Forth source. I may be able to build a tiny Basic on top of Tachyon in the boot ROM too.
Would a Forth kernel reside entirely in ROM/cog RAM or would it require some hub RAM as well? Also, would the Forth kernel need to use space in flash memory or and SD card for the dictionary? Maybe a simple monitor would be sufficient, or maybe a monitor isn't needed at all. As Chip said, you can just download a monitor or Forth kernel if needed.
Would a Forth kernel reside entirely in ROM/cog RAM or would it require some hub RAM as well? Also, would the Forth kernel need to use space in flash memory or and SD card for the dictionary? Maybe a simple monitor would be sufficient, or maybe a monitor isn't needed at all. As Chip said, you can just download a monitor or Forth kernel if needed.
The aim would be to make it all fit in ROM and use little if any of the hub memory at all, so that means it should work from a single cog. The Tachyon dictionary space is separate from code so it becomes a simple matter to not only have just have the names that are important and necessary but also it is possible to compress them up a bit more too. This ROM version might end up using bytecodes since we want to pack as much as we can into that tiny space and we don't need to expand it either which is where it would be advantageous to use wordcode. Also if the SD card is connected to pins different from the default then that is easily handled as it is now by passing all four pins in a single long in the form of &ce.miso.mosi.sck long to SDPINS. All the essentials required for debugging the chip and hardware would be included but other non-essentials such as various peripherals will not be as that would be part of the full version. I mentioned implementing a tiny Basic on top of Tachyon and I want to be able to do this too as I know that this is something anyone, even Heater, can handle
Peter,
Don't forget you have the LUT 2KB usable too, so Cog RAM is now 4KB.
Note the ROM is serial and not usable (or as accessible AFAIK once P2 boots).
Peter,
Don't forget you have the LUT 2KB usable too, so Cog RAM is now 4KB.
Note the ROM is serial and not usable (or as accessible AFAIK once P2 boots).
Oh, that's right, so I will have to copy it to hub RAM for it to be useful then. But maybe it might be better being copied up to the top of RAM then. In the current version of Tachyon on the P2 I use the LUT for stacks etc but I will see how I can utilize the LUT a bit better. I can't see any reason why the boot ROM can't make use of more than one cog either if necessary and that might be another way of avoiding using hub RAM if that was a concern.
Next week I should be able to get stuck into a new version based upon the current version back, just to get it functional so it can be evaluated. From there I could look at a bytecode version if necessary.
I mentioned implementing a tiny Basic on top of Tachyon and I want to be able to do this too as I know that this is something anyone, even Heater, can handle.
Ha! As much as I like to rag on the absurdity that is Forth I have always said it is an amazing thing. Possibly the smallest most efficient way to implement a sort of high level language. And clearly those who are patient enough to master it can do amazing things with it.
I was even a fan of RPN back in the day of HP calculators. Clearly they had to do it that way to get all the functionality they wanted in there.
I can cope with simple expressions in Forth being backwards. I just wish there was a better way to deal with control structures and all the other stuff you need in a high level language.
You should know me better by now Peter, I am no fan of BASIC either. But I guess there is a reason Bill Gates came to rule the world with his BASIC rather than Charles Moore and Forth.
Back in the day when I was bringing up 8 bit micro-processor boards and wrote a couple of monitors it kind of made sense. There were few opcodes. All 8 bit. Quite likely one could memorize them. A monitor made it easy to enter code in HEX, fiddle with memory, set break points, run code etc.
Does this make any sense on a 32 bit processor with a thousand instructions?
Back in the day when I was bringing up 8 bit micro-processor boards and wrote a couple of monitors it kind of made sense. There were few opcodes. All 8 bit. Quite likely one could memorize them. A monitor made it easy to enter code in HEX, fiddle with memory, set break points, run code etc.
Does this make any sense on a 32 bit processor with a thousand instructions?
'Monitor' means many things..
I'd agree a vanilla terminal interface, ASCII command line is not going to be used much on a 32 bit MCU, just connected to a terminal.
I'd expect something smarter at the PC end, like a Smart Pin Configurator, that allows users to specify a mode, and then it uses the monitor/loader link to access the Pin registers.
Likewise, code debug, would be smarter PC-Side SW that uses monitor/loader link, so is rather more than a scrolling terminal....
Things like Dis-assembler do not need to be in ROM.
To me all that must be in ROM is the simplest access items
* A means to Read/Write all memory. (including PLL, with AutoBAUD)
* Some means to break/step - but this will need some stub co-operation with user code.
also nice would be the ability to access the Unique ID in FLASH, and user protected flash areas, to act as virtual 'Boot-DIP-switches' to reduce pin costs on P2 & many-P2 designs.
The idea behind my debugger/monitor was that almost all of it resided in hub. All the functions could be called from any program (PASM, SPIN2, C, or whatever) so you could convert to hex/binary/ascii, dump hub/cog memory (display in the old pc style dump where you get hex and ascii on the line), etc.
There is a simple UART (I did in sw) that can output and input.
I think what jmg says makes most sense. A KISS monitor, when you can load from SD card o SPI flash or serial, then you can load whatever you may also need.
Comments
Say we have a demo program running on VGA, and it's developed with the monitor in mind. Origin = +16 or 32K, something like that.
It's running, user enters monitor, uploads TV code for the display, kills off the VGA COG, fires up the TV COG and the demo program is none the wiser. Or, just add the TV, and have both going.
This kind of thing done as a "how to", just for perspective, what can be done, how it works, why it could be done, is high value for some people who may be engineering fairly crazy things. Or, maybe one day they are fixing broken things, hacking. This kind of education needs to be out there. It's not necessary for people to do it, but it is definitely important those who can or want to get an opportunity, or even know about these ways and means.
And, BTW, Peter does this kind of thing all day long. It's one of the super powers in Forth. Still, few will be working in Forth, so we might as well show them the lower level lay of the land in the more mainstream sense.
Finally, whether we intend it or not, this chip is a little computer. People are gonna use it that way. I plan to, and have been building up some stuff for that purpose. As a bench computer, doing these kinds of things are fairly low cost and risk, but very high value.
I'll shut up about that now.
Just so everyone knows, I changed careers again. Fourth one! Well, sort of. It's a return to what I have done for many years, but in a new context.
One nice thing is some product design is going on and it's using Propeller 1 chips. Super cool.
Left my higher level executive role, mostly business, product design, with some cool R&D I got to help with / supervise, and am in a startup related to additive manufacturing. Message me, if you want to chat some. I don't see a need to drop names here.
Short story there is I am returning to a place where Prop chips, this idea of a bench computer, etc... are all becoming increasingly relevant again. Super happy about it. But, it's a startup too. Lots of all hours work. Pay off should be good though, and I need it.
David, I do agree. Maybe you didn't see all my contribution yet, but I'm actually a strong advocate for getting something programmable "in the can" built in, available no matter what, and that whatever it is, offers a simple jump vector / command parser "hook" to allow it to be extended with an upload too.
I'm all for Tachyon, if Peter is game. That could be a very compelling package. And it's ON CHIP, literally.
However, if we don't go there, then yes! Make sure the ROM code can be extended simply.
Ideally, we get to a point where we have a subset of SPIN+PASM, very similar to Pnut today available to be uploaded and hooked into the ROM code, whatever that is. I think this should be done no matter what we put in the ROM.
Basically, port Pnut to the P2, have it work over serial. (a self-hosted display could be done too, and done later with code written on the Pnut for P2)
If it's kept super lean, and it's considered the "on chip", self-hosted tool chain, drivers, and other important code, much of which will be library code eventually, can be written.
This package can get "done" in the sense of it not needing changes, and compatability with code sits right at the top of the feature list.
If we do that, and we stick to it, the body of code that gets written on this small, simple, lean platform will be very useful over very long periods of time, similar to how the P1 OBEX has proven out.
Honestly, it's one of the highest value things we can do.
Other language needs / features / etc... can and will get done, and they will be done in the mainstream way, using a PC + IDE, build, upload, run. All familiar.
The little self-hosted environment won't be as feature rich, but it won't need to be either.
Think of it a lot like "prop tool" for P2, running over serial. Everything else can and likely will support that feature set and syntax. It's stable, "done" in the sense of being feature complete enough to be practical.
Anyone learning that set of software tools is set! Won't change. Writing software on that should be useful for applications, but also useful as library code on all the stuff that will follow and that will change frequently.
Given we are off the path here, doing a non-standard type of chip, having a baseline software / dev stack is super important. It needs to be stable, "done" in the sense I am trying to articulate here (badly it seems this morning).
If it's seen like 'ROM' code is, stable, and all that, people will write drivers and stuff with it, and that's the value right there. Once people learn it, targeting the basics will happen and make sense.
Maybe think of it as the root of a very big tree to come. A tree we won't know the shape of, or it's branches or any of that.
This root, or trunk, will end up being common, and code written with it, used all over the place, P1 OBEX style.
My fear, should we not do a simple "self-hosted" set of tools, Pnut with minimum SPIN in it basically, is the basics, library code like we saw happen with P1, won't happen again. And we lose out, because the barrier to entry is too high to use the P2.
P1 had this happen because there was no choice, and SPIN+PASM were super simple, easy. P2, can have it happen, can have a super lean, easy SPIN+PASM, like P1 did too.
So, I think it should happen. That way, we've got a real shot at doing the OBEX again. If it happens that way, P2 is gonna be a win, like P1 is. By that, I mean anyone who takes a look at a P1, wants to do something, has a great body of code available to them and it requires very little to get going. We need that to be true again.
Amen. This can't be overstated. At this point, the R&D and design years Parallax has sunk into the P2 demand a return. This latest development direction is great stuff. If the available 14K space is enough, leverage it into something appealing that directly results in more sales.
One thing speaking for FORTH is the build in extensibility, that Jump vector out of the monitor @potatohead mentioned is there already.
So what we would need for experiments is a minimalistic TACHYON kernel to squirt via serial into P2-FPGAs or simulated with spinsim for us poor FPGA less folks.
And a base directory containing the debugger commands used by P2-Hot. That was thought out pretty well. Sure if @Peter could fit in his SD card stuff even better. But on the end it is not more complicated to connect a flash to the P2 as to connect a SD socket.
As to the question if @Peter is able and willing to do that? My guess is that he is definitive able to do that, if he is willing too, I can't say. But I have the strong feeling he would be interested in doing that.
Enjoy!
Mike
I do not see Configure PLL in that list, but maybe it is inferred in the broader prose.. ?
Yes, something simple and reliable makes sense, and then you can update it.
Fast Chip and POST testing should be a focus. eg Bare board testing can be 'built in' here...
If you can have the Loader check Flash Tables, then all of this can be preloaded into the Flash, and it appears just like it was in ROM.
Nothing to copy or paste, (tho that still works...) just connect to a Parallax Host and it checks and updates the firmware lists, and the user chooses a default.
Becomes very plug and play like.
With everything serialized, (via that Unique Flash ID) you can even have spreadsheets showing the corporate defaults...
Large Flash is very cheap, 16MBit is now the price-knee, and that will only move up. That represents a lot of spare space, above a Max 512k P2 image.
Software is one of Parallax's strengths, so the ROM really should be designed to support that, as a P2+Flash eco system.
True - to me, the finite time to reset and restart is why simple, basic things like resource access should be in initial ROM.
Things like PLL, Smart Pins, and all Memory (including SPI Flash Read) should be booter-accessible, as this allows Rapid Testing, and that saves everyone money.
Rapid Testing is why I have PLL access high on the list.
Anything above that is icing, and can be loaded later.
I'd like the ROM to be smart enough to read the flash, and load a user-chosen default, so a Serial-Send is NOT mandated.
Systems WILL have spare flash, and this 'looks' like many ROMs to the final user.
I'd also like to see an optional SD FAT32 driver available. My P1 has been running fine for years!
It was programmable. A version of Pong was made for MacHack '98.
"Taking second place was OFPong by Marcus Jager and Quinn "The Eskimo!". OFPong is an implementation of the classic "Pong" game, written entirely in Open Firmware, the Macintosh boot-strap environment. As your machine is booting you can take a break for a quick game and then continue booting up."
http://www.hax.com/MacHack/BestOf98.html
j
The debugger was designed also to be able to be called as routines from user programs, with the debugger remaining in hub and used minimal cog longs as an interface and LMM runtime. Of course, the LMM Runtime is no longer required as hubexec is built-in to the new P2.
A disassembler was also inbuilt too.
=== Cluso's P2v10a Debugger v.110x ===",$0D,0 ------------ Help ----------------------------------------------------------- [[#]xxxxxxxx][.yyyyy][,[$]ccccc]z[m]<cr> <-- command format -----1----- ---2-- -----3--- 4 5 --6- <-- parameter no. ...where... 1: # xx xx xx xx = an immediate byte/word/long value (spaces optional) # xxxxxxxx = stored as a long (spaces mean little endian order) xxxxx = from address (hex) where <$200 is in cog, else hub 2: . yyyyy = to address (hex) where <$200 is in cog, else hub 3: , $ ccccc = (hex) count/length , ccccc = (decimal) count/length 4: z = (single char) command ( ? - G L M P Q V ) 5: m = (single char) command modifier (command specific) 6: <cr> = <enter> key ? HELP: Show this text - STORE: to {addr1} the following {byte(s)}|{word(s)}|{long(s)} G GOTO: Goto cog {addr1} (if {addr1} omitted, return to user program) COGINIT {addr1}:{par2} for COGID {m5} {m5} omitted = this cog; 0..7 = cog 0..7; * = next avail cog L LIST: from cog/hub {addr1} to {addr2} from cog/hub {addr1} for {count3}|{length3} L = L0 = bytes + ascii; L1 = bytes; L2 = code; L3 = long M MOVE: from cog/hub {addr1} to cog/hub {addr2} for {Count3}|{length3} FILL #{immediate1} to cog/hub {addr2} for {count3}|{length3} P PORT: Show port status Q QUIT: Quit user program and run the Rom Monitor V VIEW: View the variables (special for Sapieha) ------------------------------------------------------------------------------Hardware stack examination is supported too.
It's already running on V24 on all FPGA images and has been my "go to" utility to test P2.
How much space does your monitor code take?
What size is that ?
Can it morph with the bootloader ?
I am not intending to rewrite unless there is a proper demand for it.
Thinking about the use of this, can it echo a char, just before it loads the PLL ?
Use example A - suit PCs IN: '>Prop_PLL 0 0 0 0 x' OUT: '.' at 20MHz RCFAST Auto-baud User Changes baud, and waits short delay IN: '>Prop_PLL 0 0 0 0 x' OUT: '.' now at PLL Auto-baud Use example B - suit local MCU IN: '>Prop_PLL 0 0 0 0 x' OUT: '.' at 20MHz RCFAST Auto-baud User Changes baud, then sends many autobaud chars to cover PLL settling time. IN: '>>>>>>>>>>>>>>>>>>>>>>>>>>Prop_txt' ^^^^^ PLL Done sometime hereIs it safe to load the PLL in one command, (self timed ? )
Don't forget you have the LUT 2KB usable too, so Cog RAM is now 4KB.
Note the ROM is serial and not usable (or as accessible AFAIK once P2 boots).
Oh, that's right, so I will have to copy it to hub RAM for it to be useful then. But maybe it might be better being copied up to the top of RAM then. In the current version of Tachyon on the P2 I use the LUT for stacks etc but I will see how I can utilize the LUT a bit better. I can't see any reason why the boot ROM can't make use of more than one cog either if necessary and that might be another way of avoiding using hub RAM if that was a concern.
Next week I should be able to get stuck into a new version based upon the current version back, just to get it functional so it can be evaluated. From there I could look at a bytecode version if necessary.
Is or would it possible to have the monitor be able to call routines written in PASM, Spin, or C/C++ and vice-versa?
Or is the thought that the P2 monitor is a one-way path from boot/explore to other code?
-joe
I was even a fan of RPN back in the day of HP calculators. Clearly they had to do it that way to get all the functionality they wanted in there.
I can cope with simple expressions in Forth being backwards. I just wish there was a better way to deal with control structures and all the other stuff you need in a high level language.
You should know me better by now Peter, I am no fan of BASIC either. But I guess there is a reason Bill Gates came to rule the world with his BASIC rather than Charles Moore and Forth.
Some people haven't given up on them, yet. (self-advertisement).
Maybe it can be compressed, but a full disassembler needs some room, specially because the P2 has so many opcodes.
Back in the day when I was bringing up 8 bit micro-processor boards and wrote a couple of monitors it kind of made sense. There were few opcodes. All 8 bit. Quite likely one could memorize them. A monitor made it easy to enter code in HEX, fiddle with memory, set break points, run code etc.
Does this make any sense on a 32 bit processor with a thousand instructions?
'Monitor' means many things..
I'd agree a vanilla terminal interface, ASCII command line is not going to be used much on a 32 bit MCU, just connected to a terminal.
I'd expect something smarter at the PC end, like a Smart Pin Configurator, that allows users to specify a mode, and then it uses the monitor/loader link to access the Pin registers.
Likewise, code debug, would be smarter PC-Side SW that uses monitor/loader link, so is rather more than a scrolling terminal....
Things like Dis-assembler do not need to be in ROM.
To me all that must be in ROM is the simplest access items
* A means to Read/Write all memory. (including PLL, with AutoBAUD)
* Some means to break/step - but this will need some stub co-operation with user code.
also nice would be the ability to access the Unique ID in FLASH, and user protected flash areas, to act as virtual 'Boot-DIP-switches' to reduce pin costs on P2 & many-P2 designs.
There is a simple UART (I did in sw) that can output and input.