Back in the day, 1980 something, there was an IBM compatible computer that became a hit. It was from a company called "Compaq".
At the time I did not understand the thing about the "q" there. Especially as we English kids were taught in school that after a "q" there is always a "u". There is no "u" in "Compaq"
Of course it was a marketing gimmick. A way to be a bit weird and get attention. Pretty smart.
A gimmick picked up by many other companies since then.
So, when I say "taQos" it is just the same boring "TACOS". But with a "q".
I have no problem with a naked Q in an advertising term; I'm Aussie, and we had that way before Compaq was even thought of (Qantas in 1920).
But, the naked Q in Qantas has a reason behind it: Queensland And Northern Territory Aerial Services.
So let me reiterate: It you are replacing the C for Coding with a Q, what does it stand for?
If we were all to help build a monitor/debugger/tachyon/etc to be placed in ROM, would you load all this into Hub RAM on bootup, or could it be copied from the ROM to Hub RAM later?
Is any of the lower 4KB of Hub RAM remapped into the top of the 1MB space when Hub RAM <1MB ?
I welcome the idea of adding some form of monitor, together with a callable "Tachyon/Tacos/Interpreter" into the ROM.
I would like to add some callable hubexec routines to display cog/lut/hub in varying format, as well as displaying long/hex/decimal/char formats. I would do this in a similar form to my pre P2Hot monitor/debugger. The display routines all call a single "serial send" routine that could be intercepted to divert to a "terminal/display cog via a hub mailbox".
Also I would like there to be a basic SPI (maybe native 1bit too) SD Card read/write routine to load a piece of code.
What I know: Heater is always right, but jmg is also right about 99.99% of the time.
Why in the world wouldn't a monitor be built using Spin2?
I don't get it.
I don't get it.
I love Peter's dedication, intelligence, persistence, and country of origin, but I love Spin even more... and unique id's for every P2 module:)
I don't get it.
The idea was to put an interactive language in the ROM. Spin2 is not interactive. Well, since it doesn't actually exist yet I guess I can't say that for certain but Spin1 is certainly not an interactive language. Its compiler would not fit in 14K of ROM.
Let's make one thing clear, Spin2 is a language that is compiled on a PC but the Prop runs an interpreter and machine code. So Spin2 as a language only exists on the PC. Tachyon however IS the language and interpreter that runs on the Prop. What good is Spin2 in ROM??? How do you use it? A monitor I get, you can talk to it via a terminal from a PC or tablet or phone, either hardwired or wireless, all without having supporting software such as a compiler etc. Same too with Tachyon, hence the reason why it would be considered as a boot ROM candidate. However, while you can type commands into a monitor you can't program in it, and that's where TACOS comes in as it provides for hardware debugging and higher level functions such as FAT32 etc.
If you said you want Spin2 then please explain how it will fit and interact and be useful in 14kB or so of ROM? If now we had 64kB or more of ROM then you could implement a compiler in there and an assembler etc. Chip said the monitor only uses around 2kB of the 16kB ROM, so do we waste it, or do we use it, and how?
I suppose you could use it if you could fit the Spin2 compiler in the ROM along with an editor and had sufficient memory to buffer both the Spin2 source code you're working on and the generated byte codes. This still wouldn't be an interactive language like Tachyon. In any case, as you mention, the available ROM space is far too small for that even if you were to want it. And I wouldn't want it because it only really makes sense to have a real interactive language available in the boot ROM. Any larger development system should be loaded from flash or SD card or some larger storage medium.
I don't remember the thread, but you were demonstrating how to control a chip to drive a stepper motor at amazing speed and with amazing accuracy. I remember looking at Forth and then giving up:) So, I have been impressed and I have looked.
I am not sure why Spin can't be an interactive language. It seems kind of trivial, but I really don't know.
As long as the spill over is on Flash, I really have no problems.
If we were all to help build a monitor/debugger/tachyon/etc to be placed in ROM, would you load all this into Hub RAM on bootup, or could it be copied from the ROM to Hub RAM later?
Is any of the lower 4KB of Hub RAM remapped into the top of the 1MB space when Hub RAM <1MB ?
I welcome the idea of adding some form of monitor, together with a callable "Tachyon/Tacos/Interpreter" into the ROM.
I would like to add some callable hubexec routines to display cog/lut/hub in varying format, as well as displaying long/hex/decimal/char formats. I would do this in a similar form to my pre P2Hot monitor/debugger. The display routines all call a single "serial send" routine that could be intercepted to divert to a "terminal/display cog via a hub mailbox".
Also I would like there to be a basic SPI (maybe native 1bit too) SD Card read/write routine to load a piece of code.
Right now, the booter loads the initial 2KB from ROM into RAM. The rest could be loaded later, as needed.
Currently, there is no remapping of RAM when the configuration is less than 1MB.
It might be really neat to have a Tachyon implementation that behaves as a monitor and is extensible. SD card support would be a bonus. We could make a command from the booter to load the Tachyon from ROM into RAM and execute it. That makes it clean, for me, and safe for the chip.
Right now, the booter loads the initial 2KB from ROM into RAM. The rest could be loaded later, as needed.
...
It might be really neat to have a Tachyon implementation that behaves as a monitor and is extensible. SD card support would be a bonus. We could make a command from the booter to load the Tachyon from ROM into RAM and execute it. That makes it clean, for me, and safe for the chip.
Yes, it sounds best to optionally load the extras, so the total embedded (SPI/MCU) boot time is kept to an absolute minimum.
Terminal-connected systems are more development in nature, and more time-tolerant.
There would be situations where I have an embedded microSD instead of a Flash chip so it would be good if the monitor could detect the microSD-only boot option so that it could then jump to TAQOZ. I find that when I use the small microSD connector as I do on some other designs, that I can have the microSD card sit over the top of the CPU which both saves space and also provides a bit of physical protection for the card.
Even the smallest capacities are 8GB for just a few dollars which works out around one cent per 2MB so in these cases Flash can't even compete plus you don't have to worry about large and awkward sector sizes as you do with Flash, and those Flash sector sizes are all over the place from chip to chip. TAQOZ can deal with SD memory or files as virtual memory alongside FAT32.
But I think just calling it Boot-Rom and maybe extensible Monitor should be good enough.
Its not an OS. The P2 does not need a OS It is a MCU not a CPU.
Just put it in and don't brag about it. Like with the old PC, sure you need to boot your OS, but if you DON'T you end up in a build in BASIC. Or Apple and Sun and whoever did with booting forth out of the rom.
I would just mention it in the small print that there is a monitor and in even smaller print that one can exit to a FORTH prompt.
NO claims of Integrated Development System, just put it in as a goodie for the developer working with the chip, Don't bother marketing with it.
P2 can be programmed in various languages like any other MC out there, using a host PC and some IDE/compiler/whatever. BIG DOT.
That needs to stand up first in every readers/EEs/customers mind.
small print:
Additional to that there is a interactive, extensible build in monitor and simple debugger(?) available.
The developer using it will pretty soon find out that it is FORTH.
Yes, low profile is best. Nobody really knew that the Sun console monitor was a Forth program. That wasn't the point of having the monitor anyway.
I'm a little bit worried about 'exit to Forth' though.. I'm sure I'm not the only one with muscle memory typing 'exit' automatically now and then (that came from my years of minicomputer work). So suddenly the user would be in Forth.. the question is: How to get back to the monitor? I guess I would have it the other way around.. enter 'forth', be in Forth, enter 'exit', back to the safe zone (monitor).
I have SPI Flash hooked up and I can backup an image to there no problems but is there something special I need to do to the image to make it boot from there? I do have a 10k pullup on the W25W80B CS.
I have SPI Flash hooked up and I can backup an image to there no problems but is there something special I need to do to the image to make it boot from there? I do have a 10k pullup on the W25W80B CS.
The DOCs mention a BOOT PROCESS, & says
If an external pull-up resistor is sensed on P61 (SPI_CS), then attempt to boot from SPI:
* Load the first 992 bytes ($F8 longs) from SPI into the hub starting at $00000.
* Load the next 32 bytes from SPI into a signature buffer.
* Compute a SHA-256/HMAC signature on the first 992 bytes, using the first 128 fuses as the key.
* Compare the buffered signature against the computed signature.
but some of that might be out of date, with fuses now gone... I think the signature of 00 means skip SHA ?
@jmg - yes, the stuff is out of date but the boot still seems to want to check it and skip boot from spi if something is not right. I'm wondering if Chip can't just remove this check altogether as it is a pain to reload after any hiccup while testing TAQOZ and it is problematic with high level boot testing too.
To boot from a SPI chip, you'll have 256 longs worth of data that will get loaded into cog0 from $000..$0FF. There needs to be a long somewhere in those 256 which is a checksum. It is computed as: "Prop" minus SumOfAllTheOther255Longs. "Prop" is $706F7250. The data will be loaded from the start of the SPI memory.
@jmg - yes, the stuff is out of date but the boot still seems to want to check it and skip boot from spi if something is not right. I'm wondering if Chip can't just remove this check altogether as it is a pain to reload after any hiccup while testing TAQOZ and it is problematic with high level boot testing too.
Peter, can you elaborate a little? I'm not sure what you'd like removed.
@jmg - yes, the stuff is out of date but the boot still seems to want to check it and skip boot from spi if something is not right. I'm wondering if Chip can't just remove this check altogether as it is a pain to reload after any hiccup while testing TAQOZ and it is problematic with high level boot testing too.
Peter, can you elaborate a little? I'm not sure what you'd like removed.
When I first looked at the booter I thought fuses were somehow involved but now I'm having another look at it again with the checksum of the first 256 longs = "Prop" in mind.
So it looks like I either have to have a booter sitting in the first 1kB of the Flash that then loads the image I want or have the booter as the first 1kB of the image. This means the ROM loads a 1kB page and then the booter in that loads the rest of the image. Would be nice if the ROM also read an image size and just loaded it up all in one go.
When I first looked at the booter I thought fuses were somehow involved but now I'm having another look at it again with the checksum of the first 256 longs = "Prop" in mind.
So it looks like I either have to have a booter sitting in the first 1kB of the Flash that then loads the image I want or have the booter as the first 1kB of the image. This means the ROM loads a 1kB page and then the booter in that loads the rest of the image. Would be nice if the ROM also read an image size and just loaded it up all in one go.
In order to run more code from ROM, I can read more ROM bytes into RAM and then do a 'COGINIT #0,#0' on them. All I really need is the circumstance in which to do that.
In order to run more code from ROM, I can read more ROM bytes into RAM and then do a 'COGINIT #0,#0' on them. All I really need is the circumstance in which to do that.
How much time does ROM read take ? - it is important to keep SPI boot times as short as possible, eg by only loading extra-features, on user request.
Can any COG read from rom, and can you re-load from ROM some time after reset, or is it only one-COG and one-time copy ?
I'm thinking more of the current situation where I want to load the image from SPI on boot and it looks like the ROM already reads in 256 longs (with checksum) so all I want it to do is also check for an SPI image size in that so it can continue to read from SPI into RAM. However the booter seems to be reading and checking the 32-byte signature, is that really necessary?
Comments
I have no problem with a naked Q in an advertising term; I'm Aussie, and we had that way before Compaq was even thought of (Qantas in 1920).
But, the naked Q in Qantas has a reason behind it: Queensland And Northern Territory Aerial Services.
So let me reiterate: It you are replacing the C for Coding with a Q, what does it stand for?
If we were all to help build a monitor/debugger/tachyon/etc to be placed in ROM, would you load all this into Hub RAM on bootup, or could it be copied from the ROM to Hub RAM later?
Is any of the lower 4KB of Hub RAM remapped into the top of the 1MB space when Hub RAM <1MB ?
I welcome the idea of adding some form of monitor, together with a callable "Tachyon/Tacos/Interpreter" into the ROM.
I would like to add some callable hubexec routines to display cog/lut/hub in varying format, as well as displaying long/hex/decimal/char formats. I would do this in a similar form to my pre P2Hot monitor/debugger. The display routines all call a single "serial send" routine that could be intercepted to divert to a "terminal/display cog via a hub mailbox".
Also I would like there to be a basic SPI (maybe native 1bit too) SD Card read/write routine to load a piece of code.
Why in the world wouldn't a monitor be built using Spin2?
I don't get it.
I don't get it.
I love Peter's dedication, intelligence, persistence, and country of origin, but I love Spin even more... and unique id's for every P2 module:)
I don't get it.
If you said you want Spin2 then please explain how it will fit and interact and be useful in 14kB or so of ROM? If now we had 64kB or more of ROM then you could implement a compiler in there and an assembler etc. Chip said the monitor only uses around 2kB of the 16kB ROM, so do we waste it, or do we use it, and how?
Well, like me, maybe we'll just keep it simple:
TacOS - Tachyon O/S
It would be a shame if we "missed it by that much!"
Thanqs.
I don't remember the thread, but you were demonstrating how to control a chip to drive a stepper motor at amazing speed and with amazing accuracy. I remember looking at Forth and then giving up:) So, I have been impressed and I have looked.
I am not sure why Spin can't be an interactive language. It seems kind of trivial, but I really don't know.
As long as the spill over is on Flash, I really have no problems.
Regards,
Rich
I prefer NACHOS to TACOS.
Not
Another
Contrived
Homophonic
Operating
System
No hopeful though
Right now, the booter loads the initial 2KB from ROM into RAM. The rest could be loaded later, as needed.
Currently, there is no remapping of RAM when the configuration is less than 1MB.
It might be really neat to have a Tachyon implementation that behaves as a monitor and is extensible. SD card support would be a bonus. We could make a command from the booter to load the Tachyon from ROM into RAM and execute it. That makes it clean, for me, and safe for the chip.
I like TAQOZ!
-Phil
That name is the best, I think.
Yes, it sounds best to optionally load the extras, so the total embedded (SPI/MCU) boot time is kept to an absolute minimum.
Terminal-connected systems are more development in nature, and more time-tolerant.
Even the smallest capacities are 8GB for just a few dollars which works out around one cent per 2MB so in these cases Flash can't even compete plus you don't have to worry about large and awkward sector sizes as you do with Flash, and those Flash sector sizes are all over the place from chip to chip. TAQOZ can deal with SD memory or files as virtual memory alongside FAT32.
because I have to bend my mind at least 2 times - but sure will get used to it
BUT:
TacOS - 136.000.000 Google hits ...
TAQOZ - 0 Google hits still .... will change very soon ;-)
so better reserve TAQOZ.com s.o. ... ;-) !!
EDIT: typo - TAQOS.com already exists
EDIT2: too late ... :-(( TAQOZ.com is gone by now
EDIT3: TaQOS - Tachyon Quantum Operating System ;-)
there we go.
Even if I found the Taco-Chip a nice touch.
But I think just calling it Boot-Rom and maybe extensible Monitor should be good enough.
Its not an OS. The P2 does not need a OS It is a MCU not a CPU.
Just put it in and don't brag about it. Like with the old PC, sure you need to boot your OS, but if you DON'T you end up in a build in BASIC. Or Apple and Sun and whoever did with booting forth out of the rom.
I would just mention it in the small print that there is a monitor and in even smaller print that one can exit to a FORTH prompt.
NO claims of Integrated Development System, just put it in as a goodie for the developer working with the chip, Don't bother marketing with it.
P2 can be programmed in various languages like any other MC out there, using a host PC and some IDE/compiler/whatever. BIG DOT.
That needs to stand up first in every readers/EEs/customers mind.
small print:
Additional to that there is a interactive, extensible build in monitor and simple debugger(?) available.
The developer using it will pretty soon find out that it is FORTH.
The marketing does not need to know that.
Enjoy!
Mike
I'm a little bit worried about 'exit to Forth' though.. I'm sure I'm not the only one with muscle memory typing 'exit' automatically now and then (that came from my years of minicomputer work). So suddenly the user would be in Forth.. the question is: How to get back to the monitor? I guess I would have it the other way around.. enter 'forth', be in Forth, enter 'exit', back to the safe zone (monitor).
The monitor program is just a startup word.
Mike
The DOCs mention a BOOT PROCESS, & says
If an external pull-up resistor is sensed on P61 (SPI_CS), then attempt to boot from SPI:
* Load the first 992 bytes ($F8 longs) from SPI into the hub starting at $00000.
* Load the next 32 bytes from SPI into a signature buffer.
* Compute a SHA-256/HMAC signature on the first 992 bytes, using the first 128 fuses as the key.
* Compare the buffered signature against the computed signature.
but some of that might be out of date, with fuses now gone... I think the signature of 00 means skip SHA ?
Peter, can you elaborate a little? I'm not sure what you'd like removed.
When I first looked at the booter I thought fuses were somehow involved but now I'm having another look at it again with the checksum of the first 256 longs = "Prop" in mind.
So it looks like I either have to have a booter sitting in the first 1kB of the Flash that then loads the image I want or have the booter as the first 1kB of the image. This means the ROM loads a 1kB page and then the booter in that loads the rest of the image. Would be nice if the ROM also read an image size and just loaded it up all in one go.
In order to run more code from ROM, I can read more ROM bytes into RAM and then do a 'COGINIT #0,#0' on them. All I really need is the circumstance in which to do that.
How much time does ROM read take ? - it is important to keep SPI boot times as short as possible, eg by only loading extra-features, on user request.
Can any COG read from rom, and can you re-load from ROM some time after reset, or is it only one-COG and one-time copy ?