Shop OBEX P1 Docs P2 Docs Learn Events
Monitor in P2 ROM — Parallax Forums

Monitor in P2 ROM

msrobotsmsrobots Posts: 3,701
edited 2017-10-26 02:20 in Propeller 2
I still think the monitor of P2-HOT was a very good idea.

It does not need to be a full blown TACHYON kernel, just the monitor back.

I am attaching a pdf from @potatohead describing some of it, it is for the P2-HOT and from 2013.

Enjoy!

Mike
«13456

Comments

  • Since we have no fuses and no encryption, a build in monitor is no risk at all anymore.

    In the opposite it would allow instant access to the chip.

    could even be batch-able over serial, so easy to handle for any host and nice for testing the chip after production.

    @Publison - I an sadly not able to find the thread from 2013(?) about the monitor, could you help me there, please?

    Enjoy!

    Mike
  • jmgjmg Posts: 15,140
    msrobots wrote: »
    Since we have no fuses and no encryption, a build in monitor is no risk at all anymore.
    In the opposite it would allow instant access to the chip.
    could even be batch-able over serial, so easy to handle for any host and nice for testing the chip after production.

    This is a good idea, and now there is more room in ROM, Parallax should be thinking about how P2 can work in a Module / Education situation too.

    I've already suggested the Loader allow a command to configure the PLL, (one key reason, is to allow a loader MCU to confirm the P2 xtal is OK), and it's a tiny step from there to allow general Memory : Value R/W parameters, aka a monitor.

    Users could 'play live' with Smart pins, with a simple GUI, and use another smart pin to test :)

    Some suggest < favourite language > in ROM, but I'm not sure language kernels should be in ROM ? - there are better uses for ROM, and better ways to manage language features.


    If the ROM can read designated/protected Flash areas, (and OTP areas), then having "a FORTH kernel in the P2 ROM" becomes less important.
    You could tell the boot loader, to launch forth, via the Flash 'nano-FAT'. To the end user, that appears exactly like 'they booted-forth'.

    It could also launch any bytecode language, including Spin 2 - Parallax just needs to provide a "P2-Languages-flash-file image, compatible with the ROM, and users can update that.

    eg Winbond parts look to have 4k top/bottom protect and says Complement Protect bit (CMP) is a non-volatile read/write bit in the status register (S14).
    I think that allows a new 'FAT' to be written in the 'other' 4k, and then once verified, that can flip. CMP thus points to which 4K is active, ROM just needs to read that, then look at the info.

    These Flash parts also have Unique IDs and I think that can be used to load-many P2's, without Pin-Addr-Cost, with some simple ROM enhancements.

    Avnet shows W25Q16JVSNIQ-TR for $0.1840/10k
  • jmg wrote: »
    [
    These Flash parts also have Unique IDs and I think that can be used to load-many P2's, without Pin-Addr-Cost, with some simple ROM enhancements.

    I've seen you make this assertion a number of times now, but I don't understand how the Pin-Addr-Cost can be avoided if the ROM is the same in each P2.

    I could see a load order chain costing an additional 2 pins per P2: On boot, one pin is driven while the other is sensed. First in the chain has the sense pin tied externally to the appropriate state to start loading. As each P2 completes loading it drives the driven pin to the alternate state to start the next in the chain.

    Please elaborate on your scheme.
  • jmgjmg Posts: 15,140
    edited 2017-10-26 09:15
    AJL wrote: »
    I've seen you make this assertion a number of times now, but I don't understand how the Pin-Addr-Cost can be avoided if the ROM is the same in each P2.

    I could see a load order chain costing an additional 2 pins per P2: On boot, one pin is driven while the other is sensed. First in the chain has the sense pin tied externally to the appropriate state to start loading. As each P2 completes loading it drives the driven pin to the alternate state to start the next in the chain.
    Yes, that can work.

    Or, you can build a ring, that chains Tx-Rx in a circle, and define some number of bytes per node.
    Addressing is implicit by place in chain, and this works best with 9-bit UART modes, which are sadly not well supported in USB-UART land.
    We've done this with MCUs, but probably less ideal for OS hosts.

    or, you can wire OR the TXD's and use wired-or arbitration (like CAN-BUS does), using the key feature of Unique FLASH ID
    The host sends a CheckID, and all nodes start to reply each with their Unique FLASH ID, in close sync (they Autobauded, and all did a WAIT on Start bit)
    To keep pace, and allow higher baud speeds, a NextID/NOP repeat char could be sent, so TX Echo is always just one-byte sync'd.
    eg a Winbond part could send something like
    SPI_CMD+04bh+(NOP)*4 + (NextID) *16


    As each P2 replies, they check to confirm TX_Pin == Tx_Data and when <>, they release the send, and wait for next enquiry.
    The P2 that makes it to end, flags itself as done, and goes quiet.
    Repeated CheckIDs reveal all serial numbers present, like a roll call. This needs to be done once only for each cluster of P2's connected, as then the host has collected all the Unique IDs.

    With a 20MHz RC osc, I'd expect 100~200kBaud is practical, and if a PLL config is added to ROM, then maybe 1MBd.
  • Ok, I think I understand better now.

    So each P2 has it's own external Flash storage including Unique ID and the only shared connection is to the host?

    The Flash part only provides the Unique ID during development to control which code blob is loaded into each P2, but can be used for standalone (simultaneous) program load in a "finished" system.

    The shared connection in a programmed system is then only used for a HMI terminal, if desired?

    Perhaps the boot process could include a check of the Flash content for a "locked" load image and then if found require a successful challenge response before allowing access to the monitor or loading code from the host? The correct response would also need to be stored on the Flash chip if it is not a universal response code.

    I recognise that this is not providing security from code theft as there is nothing stopping an attacker snooping the bus between Flash and P2, but it will prevent accidental access to the code, and might prevent code tampering.
  • cgraceycgracey Posts: 14,133
    edited 2017-10-26 12:11
    About a ROM monitor...

    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.

    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.

    Here is what a 3KB download would look like (X represents the base64 characters):
    > Prop_Txt 0 0 0 0
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    

    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.
  • I still like the idea of a small interpreter. It can do anything a monitor can and more.
  • cgraceycgracey Posts: 14,133
    David Betz wrote: »
    I still like the idea of a small interpreter. It can do anything a monitor can and more.

    There's almost nothing to learn with a monitor, if you just want to use smart pins.
  • SeairthSeairth Posts: 2,474
    edited 2017-10-26 12:17
    As I understand it, manually loading a monitor would only work if you either didn't have flash, or the flash was not programmed. Otherwise, you have a 100ms window to start loading. OTOH, this would be perfect for a small, portable command-line program/script to handle:

    1. run "p2load monitor" (or "p2load forth", etc)
    2. p2load repeatedly send Prop_Chk until it gets a response.
    3. p2load then sends your monitor using Prop_Hex.
    4. p2load exits when done.

    To get things going, you would first start p2load, then force a reboot on your P2 (cylce power). Then just fire up your favorite serial terminal and go to town.

    Edit: and, of course, on more full-featured IDEs, this could all be built in and automated.
  • cgraceycgracey Posts: 14,133
    edited 2017-10-26 12:16
    Or, we can leave this up to paste-able code chunks that bring things to life.

    The thing about having something in ROM, though, is that it can become a mainstay just because it doesn't change. There is value in something NOT changing over a long period of time. More know-how gets accumulated out there.
  • cgracey wrote: »
    David Betz wrote: »
    I still like the idea of a small interpreter. It can do anything a monitor can and more.

    There's almost nothing to learn with a monitor, if you just want to use smart pins.
    I don't think I understand your point. If people are worried that an interpreter will be hard to use I think we can just give simple examples of commands that look like monitor commands but are actually interpretive code. If they don't want to learn how to write programs that's fine. It isn't required. Here are some examples of how that could work with a Forth-like language.
    // dump 256 bytes starting at location $1000
    $1000 256 dump
    
    // fill memory with $ff starting at $1000
    $1000 256 $ff fill
    
    Granted these look a bit odd since one might expect something like this:
    dump $1000 256
    fill $1000 256 $ff
    
    but is that really a significant difference?
  • A monitor does not allow you to extend it with "macros". Being able to define or have predefined words that allow you to configure the pin for serial and send data or read it as an ADC etc is very powerful, indeed, especially if you can then build new "macros" with them or just execute a Q&D line of code interactively.

    Guess what this bit of code would do from scratch.
    26 PIN 1,000,000 TXD
    26 SERIAL 10 FOR CR PRINT" Hello World!" NEXT CON
    
  • cgraceycgracey Posts: 14,133
    David Betz wrote: »
    cgracey wrote: »
    David Betz wrote: »
    I still like the idea of a small interpreter. It can do anything a monitor can and more.

    There's almost nothing to learn with a monitor, if you just want to use smart pins.
    I don't think I understand your point. If people are worried that an interpreter will be hard to use I think we can just give simple examples of commands that look like monitor commands but are actually interpretive code. If they don't want to learn how to write programs that's fine. It isn't required. Here are some examples of how that could work with a Forth-like language.
    // dump 256 bytes starting at location $1000
    $1000 256 dump
    
    // fill memory with $ff starting at $1000
    $1000 256 $ff fill
    
    Granted these look a bit odd since one might expect something like this:
    dump $1000 256
    fill $1000 256 $ff
    
    but is that really a significant difference?

    That looks good to me.
  • cgracey wrote: »
    The thing about having something in ROM, though, is that it can become a mainstay just because it doesn't change. There is value in something NOT changing over a long period of time. More know-how gets accumulated out there.

    Yes, but you have only one shot to get it right, both it terms of features and reliability.
  • David BetzDavid Betz Posts: 14,511
    edited 2017-10-26 12:25
    deleted

  • 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.
  • Heater.Heater. Posts: 21,230
    Peter,
    Guess what this bit of code would do from scratch.
    26 PIN 1,000,000 TXD
    26 SERIAL 10 FOR CR PRINT" Hello World!" NEXT CON
    
    Me to mystery a is it.

    :)

  • Heater. wrote: »
    Peter,
    Guess what this bit of code would do from scratch.
    26 PIN 1,000,000 TXD
    26 SERIAL 10 FOR CR PRINT" Hello World!" NEXT CON
    
    Me to mystery a is it.

    :)
    Examples like that are a bit difficult to parse. I think we'll win more converts with simpler examples even if they are a bit more verbose. However, Peter's examples do show how much can be done with only a small amount of code. Now if only he would clue us in as to what these incantations do...

  • Guess what this bit of code would do from scratch.
    26 PIN 1,000,000 TXD
    26 SERIAL 10 FOR CR PRINT" Hello World!" NEXT CON
    
    Okay, I think I understand the second line. It prints "Hello World!" 10 times over a serial connection on pin 26. How does the baud rate get setup or does it just default to something sensible?

  • David Betz wrote: »
    Guess what this bit of code would do from scratch.
    26 PIN 1,000,000 TXD
    26 SERIAL 10 FOR CR PRINT" Hello World!" NEXT CON
    
    Okay, I think I understand the second line. It prints "Hello World!" 10 times over a serial connection on pin 26. How does the baud rate get setup or does it just default to something sensible?
    Another guess: the first line sets up pin 26 to transmit serial data at 1M baud?

  • Selecting PIN 26 I make it a serial TXD pin at 1M baud.
    Then I redirect all output to SERIAL on pin 26 and FOR 10 times I do a CR (carriage return) and PRINT' a literal string looping as we do with NEXT until finally redirecting output back to the console CON since we are doing this interactively.

    But the words themselves could be more verbose for sure or I could make each word more specialized so that TXD for instance took a whole string of arguments but that just complicates it when we could just keep it simple, clean, and compact.

    I could setup 10 serial ports printing Hello World! with this too:
    26 FROM 10 FOR   I PIN   115200 TXD  I SERIAL CR PRINT' Hello World!" NEXT CON
    

    Or we could monitor and debug serial traffic continually printing serial data as hex bytes like this:
    27 PIN 115200 RXD BEGIN RX .BYTE SPACE KEY UNTIL
    
    Using PIN 27 as a serial RXD @ 115,200 BAUD we BEGIN to RX a character and print the BYTE with a trailing SPACE UNTIL we hit a console KEY.

    This is how it works with Tachyon on the P2 now.
  • Selecting PIN 26 I make it a serial TXD pin at 1M baud.
    Then I redirect all output to SERIAL on pin 26 and FOR 10 times I do a CR (carriage return) and PRINT' a literal string looping as we do with NEXT until finally redirecting output back to the console CON since we are doing this interactively.

    But the words themselves could be more verbose for sure or I could make each word more specialized so that TXD for instance took a whole string of arguments but that just complicates it when we could just keep it simple, clean, and compact.

    I could setup 10 serial ports printing Hello World! with this too:
    26 FROM 10 FOR   I PIN   115200 TXD  I SERIAL CR PRINT' Hello World!" NEXT CON
    

    Or we could monitor and debug serial traffic continually printing serial data as hex bytes like this:
    27 PIN 115200 RXD BEGIN RX .BYTE SPACE KEY UNTIL
    
    Using PIN 27 as a serial RXD @ 115,200 BAUD we BEGIN to RX a character and print the BYTE with a trailing SPACE UNTIL we hit a console KEY.

    This is how it works with Tachyon on the P2 now.

    Does RX block? Won't that mean that we can't escape from the loop unless at least one character comes in on pin 27?
  • RX as it is now is very simple and blocks but I can always send a break on the terminal line which resets the Prop. Of course we could have a variant of RX that doesn't block, in fact this is what I do with KEY in that it never blocks but simply returns with a null when there is nothing there but a real null would come across as $100 and only the lower 8-bits are used anyway.

    A monitor in ROM is good for debugging assembly code but Forth is excellent for debugging hardware and trying out what-ifs instantly.
  • RX as it is now is very simple and blocks but I can always send a break on the terminal line which resets the Prop. Of course we could have a variant of RX that doesn't block, in fact this is what I do with KEY in that it never blocks but simply returns with a null when there is nothing there but a real null would come across as $100 and only the lower 8-bits are used anyway.

    A monitor in ROM is good for debugging assembly code but Forth is excellent for debugging hardware and trying out what-ifs instantly.
    Yes, being able to poke at hardware would be very useful.

  • TorTor Posts: 2,010
    edited 2017-10-26 14:26
    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?
  • You have a startup word. For most, its just a monitor.

    Run the exit command, and it's Forth.
  • potatohead wrote: »
    You have a startup word. For most, its just a monitor.

    Run the exit command, and it's Forth.
    So I guess it could start up in a simple monitor that is written in Forth and the monitor has an "EXIT" command to return you to the main Forth read-eval-print loop. That makes sense.

  • @everyone:

    Yes, having the monitor there is a great learning tool. In terms of Parallax education, that feature could have some value in that the very low level means and methods can be taught.

    IMHO, they should be. The one in HOT was excellent. The only thing it was missing then was a hook so additional code could be uploaded to extend what it can do.

    Today, Chip has identified these things:
    1) Hub RAM: read/write and launch cogs from
    2) Cogs: start, stop, and poll
    3) Smart pins: configure and poll

    I would add one command, and a jump vector pointer. Once the monitor is in there, we get much more flexible uploads too.

    See the doc I made, page 21.

    An upload could include the jump vector needed, and it would literally be paste and go. User has new command available.

    Intrepeters, assemblers, editors all follow.

    For the on-chip kit, and we really do need one that is simple, "done" in the sense the P1 stuff is "done", would be the baseline for drivers and all sorts of other basics.

    That body of code would be universal as everything else can be a super-set of it, and or offer translators / filters for it.

    We get a P1 style OBEX, and we get code that will compile on something unchanged 20 years from now, just like most of the code for P1 works today.

    Extremely high value here. We need to do it. Please. :D

  • potatohead wrote: »
    @everyone:

    Yes, having the monitor there is a great learning tool. In terms of Parallax education, that feature could have some value in that the very low level means and methods can be taught.

    IMHO, they should be. The one in HOT was excellent. The only thing it was missing then was a hook so additional code could be uploaded to extend what it can do.

    Today, Chip has identified these things:
    1) Hub RAM: read/write and launch cogs from
    2) Cogs: start, stop, and poll
    3) Smart pins: configure and poll

    I would add one command, and a jump vector pointer. Once the monitor is in there, we get much more flexible uploads too.

    See the doc I made, page 21.

    An upload could include the jump vector needed, and it would literally be paste and go. User has new command available.

    Intrepeters, assemblers, editors all follow.

    For the on-chip kit, and we really do need one that is simple, "done" in the sense the P1 stuff is "done", would be the baseline for drivers and all sorts of other basics.

    That body of code would be universal as everything else can be a super-set of it, and or offer translators / filters for it.

    We get a P1 style OBEX, and we get code that will compile on something unchanged 20 years from now, just like most of the code for P1 works today.

    Extremely high value here. We need to do it. Please. :D
    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.
  • potatoheadpotatohead Posts: 10,253
    edited 2017-10-26 16:22
    What I put above is the baseline minimum to be ultra useful. It will get used.

    If we do choose to put Tachyon in there, and I'm totally good with that, the appeal there has three main attractions:

    1. Monitor, interactive assembler, disassembler. (this is what the Apple 2 had in it's ROM, BTW) I think Peter can pack it in there. The guy has done amazing stuff in tiny memory spaces.

    2. For people who grok this stuff, bootstrapping new chips is cake. Nothing out there could touch it.

    3. Robust boot support possible. A whole lot of people want this. Why not deliver it? We can you know.

    The downsides are few:

    1. There would be more of a memory map needed. Not too much, but it's not as lean as the monitor can be. I personally don't think much of this as it can all be ignored by simply booting earlier, ignoring this stuff, and or with an upload and jump that wipes it clean straight away.

    2. It's bigger, more clunky and that can mean mistakes kill it off easier. (minor)

    And dang it, I'm gonna ask one more time:

    Can we write inhibit the lower 16k? Do it with a little state machine. Use the COGID instruction, and just require steps, to toggle it, and require they all be sequential, maybe. Or within X clocks.

    P2 chip starts up, just as it does now. If the states are performed or triggered, then writes to the lower 16K are ignored. Run through the states, or a different state again to return to default.

    The chances of rouge instructions doing this are extremely slim, and it allows the thing to be useful past a bonehead mistake, which people will do.

    And I'm only asking this if it's not gonna break timing, or some other crazy thing. Would be a shame to have not done this, particularly with something useful in the chip.

    Of course, a quick reset returns the thing to default state too...

    All I know is when I was developing on the Apple, in RAM, having the ROM be stable was high value. Made a lot of bonehead errors. Later, on a Color Computer 3, it would move it's ROM to RAM on boot. I stomped it pretty regularly when learning how things are done. A write latch would have made it golden.

    Again, only if it's no brainer. If it's an issue at all, ignore my request. I don't make it lightly. In fact, have held to the "don't do it" for some time now. But this one goes way back to when we decided to make the ROM a serial thing, streamed in to RAM at the right time.

Sign In or Register to comment.