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.
The "KISS monitor" being Peter's stripped down version of Tachyon I hope.
I do too actually. While doing that may seem useless and or strange to some, I see it as a total freebie. Major bonus!
Not that Peters time and contributions have no value. They do. It's that he's close anyway, having years of experience maxing out what a P1 can really do in 32k.
Seems a shame to miss out on an opportunity like this for P2.
Lots of people won't care. And it's just not about them. We could say that for a number of features. And they are in there for the people who do care.
Since that has guided the design, no reason not to finish that way.
I certainly don’t see a downside. We would have a frozen release of Tachyon in ROM (extensible) and more people (Chip included I assume) who would understand it at a deep level, and Parallax quality documentation for it.
I am not a forth person at all, but I support the idea of a small forth interpreter/engine in the ROM. Especially if Peter can get SD card support packed in there.
I, also, really like the idea of it starting up running a simple monitor program that you can exit out of to get back to command line forth.
I am not a forth person at all, but I support the idea of a small forth interpreter/engine in the ROM. Especially if Peter can get SD card support packed in there.
I, also, really like the idea of it starting up running a simple monitor program that you can exit out of to get back to command line forth.
I agree. Also, I see no need for a simple BASIC interpreter written in Forth. It should be enough to have a monitor written in Forth with an "exit" command to get to the Forth REPL.
Especially if Peter can get SD card support packed in there.
Seriously!
Was just kind of thinking about this. If we do go this way, and Peter is up for it, an SD card could have a few startup files:
chipdev.bin = port of Pnut to p2.
forth.bin = extension of Tachyon, intended for full operation as we know Peter will whittle the ROM'ed one down to pack stuff in.
pasm.bin = full on PASM image, same as a loader would fetch.
**Guys, this would be ultra sweet. We need to do it.**
Hey, I forgot to ask earlier. Can we get the ROM streamed in again after startup, or is it a one time thing?
Good question, Chip has mentioned a special opcode variant that reads one ROM byte, so I guess it depends on what the ROM pointer does.
If the ROM routines always read 16k, the read would wrap/realign ?
Another question would be can any COG read the boot ROM, or only the boot-COG ?
Note that if the Booter can read a defined 'FLASH-DIP-Switch area', then multiple Power Up 'ROM Boot choices' are easily available, from a firmware image in flash.
The chipdev.bin image could, and I would argue should, be a minimal SPIN+PASM. It's the logical end to Pnut.exe, ported to P2.
That can be baseline dev tools, related to my comment above. It's one of the highest value things we can do. Language is lean, but mean. No BS, but capable. We do our library code in that, and everything else will either support the syntax, or filters / translators / processors will be written to make the code useful elsewhere.
Language features should be qualified out, not in. Like, is it really needed, kind of qualified out. Lean and mean. Ultra lean. Like framework for PASM kind of ultra lean. That way, it's easy to translate, filter, process into basically anything else. Most code will be PASM anyway.
Education, hobby, other uses can target that baseline language with no worries about changes. It's a target that can get "done." Super important.
The forth.bin would be a continuation of Peter and other Tachyon enthusiasts work. Why not? Peter will have extending the ROM Tachyon down cold. Has done it multiple times in various forms anyway. The forthers take this and run with it. Maybe pick up a few newbies.
And of course, the one everyone wants, pasm.bin is a straight up binary image load, same as the loader would do. We have written hundreds of pages toward this end.
**Real filesystem support is possible!** No arguments! I'm very sorry for my own contributions to that horror. But dang! I feel very strongly about real file systems vs hacks, partitions, or just block device. Purist, I guess. It was very surprising to read all of us having strong opinions on that topic.
SD Card boot is a very compelling feature. Marketing off of it is worth doing the work. Tachyon is a clear, compelling answer here.
...Especially if Peter can get SD card support packed in there.
One caution there, I read a note recently in a forum that the newest Cards are dropping SPI modes & MCUs that hope to support SD cards, need smarter Sync Serial ports.
Addit: Managed to find that comment around MCUs and SD/SDIO support trends ...
Q: Regarding "SD/SDIO" peripheral, (in EFM32GG series 1) does this mean eMMC devices (which drop support for the SD SPI mode) are now supported in hardware?
A: Yes!
Might not be the best ROM target, but sounds ideal for a SPI-Flash boot Firmware set ?
Easy SD cards are going nowhere soon. Way too many devices remain useful for that to happen. If we are left with just an eeprom like device, then it is all moot.
Just build a loader P1 style, get it setup once, then do all the cool stuff there.
Your link is to an article about eMMC, embedded MMC (MultiMediaCard) and not SD cards. eMMC is used in devices (phones, set top boxes, etc.) as a non-removable flash media, aka the internal flash memory. The SPI mode was only dropped for eMMC, not for MMC or SD.
Don't be trying to scare everyone about SD cards not working with SPI mode based on info about eMMC.
I have to admit, I have no strong opinions about the monitor. Anything is fine with me.
What scares me about SD cards: price and footprint.
I would much rather have the goodies packed into the ROM with the spillage on Flash.
The idea of having a unique ID for each P2 module is really compelling. 2MB for pennies seems like a great value.
I think you can have both.
The Serial Boot or Skip, then SPI Flash Chip boot will always try first, then when all other boot sources are exhausted, SD Card can try.
I don't think anyone is suggesting SD cards displace SPI Flash boot entirely, it merely tacks on the end (where it can do no harm).
When HP introduced the hp35 they made a big mistake by making a scientific calculator only affordable to engineers, not to kids. The BOM wouldn't explain the price. There has been a chance to teach UPN to pupils. But TI jumped into that market with an extended conventional calculator and so this chance was missed. If not, introducing Forth would be simple. Beside UPN the compactness of Tachyon code keeps people from using Forth. But it the P2 has a Tachyon core to just manipulate I/O, internal registers etc, the users will find an easy way into Forth without the need to understand the full set of words, Peter has implemented. I believe, this is a huge chance to push forward the P2. A chip, a Propplug, a Terminal and you are in another universe. Or, like other geniuses, with a much higher IQ would say it: Happy #FirstP2Day to all of our HEROES out there. We are forever grateful to you for your service, sacrifice and courage 24/7/365! That's meant firstly for Chip, Peter, and all the other unnamed contributers.
Even if P2 Files are not released, long ahead of schedule!
To be fair the HP35 was the first such machine so we could not expect it to be cheap. Engineers were the only people who needed calculators at the time. I still maintain that kids in school do not!
Anyway, not so bad, us kids had RPN on the Sinclair Scientific calculator two years later. For only 50 quid. Sometimes it was nearly as accurate the log tables we had been using
1) No batteries required.
2) Not only do they calculate but you can use them as rulers to draw straight lines.
3) Kids with calculators would often quote the results of calculations from their physics experiments to a ridiculous numbers of decimal places. Which would get them marked down. A slide rule prevents that.
4) For those who had not actually done the experiment a slide rule introduced enough error into their write up to make it seem plausible they had. Not that I ever skipped any practicals you understand.
5) Slide rules develop an intuition as to how logarithms work.
6) One of my old slide rules was made of wood with ivory scales. It was a work of art.
Hmm...somewhere stashed away I have TI-59, with the card reader. Still worked last time I saw it ten years ago.
"To be fair the HP35 was the first such machine" As far as I know, HP transfered moon race technology to the engineers. The chips were from MOSTEK, I bought a chip set for little money. The calculator was designed and marketed not to a mass marked, so TI had the better understanding of market, but the worse product.
I am doing this for reasons of full disclosure, transparency and.....in order to put any and all conspiracy theories to rest.
This might not sound presidential, but I very much like to share (dump) my knowledge, and the most simple thing I can do is to recycle some tweets and make the best of it.
1) No batteries required.
2) Not only do they calculate but you can use them as rulers to draw straight lines.
3) Kids with calculators would often quote the results of calculations from their physics experiments to a ridiculous numbers of decimal places. Which would get them marked down. A slide rule prevents that.
4) For those who had not actually done the experiment a slide rule introduced enough error into their write up to make it seem plausible they had. Not that I ever skipped any practicals you understand.
5) Slide rules develop an intuition as to how logarithms work.
6) One of my old slide rules was made of wood with ivory scales. It was a work of art.
Hmm...somewhere stashed away I have TI-59, with the card reader. Still worked last time I saw it ten years ago.
1) That is why one of my slide rules is on my boat.
2) Mine has spacers so that it is above the page.
3) One of our smarties in our class always added an extra few digits just for fun.
4) 4 of us had to do a makeup physics class because we didn't pass the required level (long story where if you missed the level, they marked you down 2 more levels even if you passed those papers ). After each theory, we had prac. We knew how to fudge the results and why, so the lecturer figured if we Kew what to fudge and by how much, we must understand the problem.
5) Never thought of it that way, but yes exactly.
6) Mine were both Faber Castelle. Expensive but nice - some form of plastic.
Calculators came in the year after my course. Never bough a Scientific one.
IMHO, would be nice for after reset, the P2 copies some/all serial ROM to hub ram, then executes enough to...
1) Check if Serial avail (how about RXD=1)
A "1" can either be a pull-up or a serial connection. Need to wait long enough to ensure a "space" is not being sent at a low speed (say minimum 9600?)
Wait for a "space" to set baud and respond.
Now wait for instruction to indicate what to do...
a) download code (no more resets as this requires DTR/RTS which may not be available from wireless Comms, or from simple serial devices/dongles. ie Ditch the transistor reset circuit required for P1 as it's an impediment no longer required.
b) go to rom monitor ( load from serial rom if necessary)
c) go to Tachyon (or anything else in rom)
d) go load/run SPI FLASH
e) go load/run SPI SD Card
f) program downloaded code into FLASH. (no need to program SD as we can launch a program to do file transfers from SD)
It might be worthwhile to perform 2) onwards in parallel to waiting for 1). Need to allow sufficient time for a serial download to start before executing from either FLASH/SD in case its corrupted or we just want to reload it.
It might be worthwhile to check a pull-up on the SPI FLASH/SD pin to skip step 1)
2) Check if SPI FLASH is present
If yes, load small section and run..
3) Check if SPI SD Card is present
If yes, load the "boot sector" and Check for "signature" and if yes, use pointer to load up to 32KB and run. No need to support any special FAT format, although the 32KB would likely be a FAT32 file.
BTW I have been reading how to use the native command mode (both 1bit and 4bit) for SD Cards. The 1bit seems to be basically the same commands as SPI, just using different pins.
I use RPN calculators almost exclusively, and have done that almost from the beginning - I had a TI-30 back in '76, but as soon as I tried a HP I was sold. RPN makes everything easy.
However, it does nothing for my ability to program in Forth. So I don't think exposure to TI vs HP vs Casio etc. makes much difference. The RPN part isn't what's difficult with Forth. It's everything else.
Still, I support the idea of a Forth-based monitor. I think that's where even I could find a way to use Forth (my problem with Forth is that I can't find any way to use it for my "normal" programming projects.)
(The OT part.. I have several slide rules on my Android tablet.. and they work. And I have a Japanese wooden abacus that I'm learning to use. It's an incredible tool.)
I don't see Forth rom being used much and is not a selling point for next generations of engineers.
Sure it's better than nothing, but a few DOS routines than can be called from cmd prompt
that also can be used as function calls in spin/c/asm programs would be useful.
And not to forget: imagine a system as compact as tachyon not tachyon. And Tony, don't make me pessimitic. I believe next generation of engineers will realize that there was a dark age, just gone ;-)
A USB boot strap loader in Rom is way more important than anything.
A MCU that can do usb in hardware but first needs a ftdi chip to get the program in to work, people will scratch their head.
A USB boot strap loader in Rom is way more important than anything.
A MCU that can do usb in hardware but first needs a ftdi chip to get the program in to work, people will scratch their head.
That's certainly a candidate for the Flash Firmware list, but many things make it less likely for ROM
* USB code is simply too large
* It is not yet stable enough for ROM, nor likely to be...
* Users often still need that Low impact, KISS, UART connection for debug
(the better MCU development boards include both the All-Bauds UART and the Debug-USB-Bridge)
Comments
Not that Peters time and contributions have no value. They do. It's that he's close anyway, having years of experience maxing out what a P1 can really do in 32k.
Seems a shame to miss out on an opportunity like this for P2.
Lots of people won't care. And it's just not about them. We could say that for a number of features. And they are in there for the people who do care.
Since that has guided the design, no reason not to finish that way.
Tachyon Forth is kind of amazing. Rare gem, IMHO.
I, also, really like the idea of it starting up running a simple monitor program that you can exit out of to get back to command line forth.
Seriously!
Was just kind of thinking about this. If we do go this way, and Peter is up for it, an SD card could have a few startup files:
chipdev.bin = port of Pnut to p2.
forth.bin = extension of Tachyon, intended for full operation as we know Peter will whittle the ROM'ed one down to pack stuff in.
pasm.bin = full on PASM image, same as a loader would fetch.
**Guys, this would be ultra sweet. We need to do it.**
If the ROM routines always read 16k, the read would wrap/realign ?
Another question would be can any COG read the boot ROM, or only the boot-COG ?
Note that if the Booter can read a defined 'FLASH-DIP-Switch area', then multiple Power Up 'ROM Boot choices' are easily available, from a firmware image in flash.
That can be baseline dev tools, related to my comment above. It's one of the highest value things we can do. Language is lean, but mean. No BS, but capable. We do our library code in that, and everything else will either support the syntax, or filters / translators / processors will be written to make the code useful elsewhere.
Language features should be qualified out, not in. Like, is it really needed, kind of qualified out. Lean and mean. Ultra lean. Like framework for PASM kind of ultra lean. That way, it's easy to translate, filter, process into basically anything else. Most code will be PASM anyway.
Education, hobby, other uses can target that baseline language with no worries about changes. It's a target that can get "done." Super important.
The forth.bin would be a continuation of Peter and other Tachyon enthusiasts work. Why not? Peter will have extending the ROM Tachyon down cold. Has done it multiple times in various forms anyway. The forthers take this and run with it. Maybe pick up a few newbies.
And of course, the one everyone wants, pasm.bin is a straight up binary image load, same as the loader would do. We have written hundreds of pages toward this end.
**Real filesystem support is possible!** No arguments!
SD Card boot is a very compelling feature. Marketing off of it is worth doing the work. Tachyon is a clear, compelling answer here.
One caution there, I read a note recently in a forum that the newest Cards are dropping SPI modes & MCUs that hope to support SD cards, need smarter Sync Serial ports.
Addit: Managed to find that comment around MCUs and SD/SDIO support trends ...
background.. http://community.silabs.com/t5/32-bit-MCU-Knowledge-Base/eMMC-and-why-it-is-not-a-suitable-microcontroller-storage-option/ta-p/205133
and the Q&A in another thread...
http://community.silabs.com/t5/32-bit-MCU/The-New-Giant-Gecko-Series-1-is-Here/m-p/205405#M15534
Q: Regarding "SD/SDIO" peripheral, (in EFM32GG series 1) does this mean eMMC devices (which drop support for the SD SPI mode) are now supported in hardware?
A: Yes!
Might not be the best ROM target, but sounds ideal for a SPI-Flash boot Firmware set ?
Just build a loader P1 style, get it setup once, then do all the cool stuff there.
Your link is to an article about eMMC, embedded MMC (MultiMediaCard) and not SD cards. eMMC is used in devices (phones, set top boxes, etc.) as a non-removable flash media, aka the internal flash memory. The SPI mode was only dropped for eMMC, not for MMC or SD.
Don't be trying to scare everyone about SD cards not working with SPI mode based on info about eMMC.
What scares me about SD cards: price and footprint.
I would much rather have the goodies packed into the ROM with the spillage on Flash.
The idea of having a unique ID for each P2 module is really compelling. 2MB for pennies seems like a great value.
I think you can have both.
The Serial Boot or Skip, then SPI Flash Chip boot will always try first, then when all other boot sources are exhausted, SD Card can try.
I don't think anyone is suggesting SD cards displace SPI Flash boot entirely, it merely tacks on the end (where it can do no harm).
Even if P2 Files are not released, long ahead of schedule!
Anyway, not so bad, us kids had RPN on the Sinclair Scientific calculator two years later. For only 50 quid. Sometimes it was nearly as accurate the log tables we had been using
1) No batteries required.
2) Not only do they calculate but you can use them as rulers to draw straight lines.
3) Kids with calculators would often quote the results of calculations from their physics experiments to a ridiculous numbers of decimal places. Which would get them marked down. A slide rule prevents that.
4) For those who had not actually done the experiment a slide rule introduced enough error into their write up to make it seem plausible they had. Not that I ever skipped any practicals you understand.
5) Slide rules develop an intuition as to how logarithms work.
6) One of my old slide rules was made of wood with ivory scales. It was a work of art.
Hmm...somewhere stashed away I have TI-59, with the card reader. Still worked last time I saw it ten years ago.
I am doing this for reasons of full disclosure, transparency and.....in order to put any and all conspiracy theories to rest.
This might not sound presidential, but I very much like to share (dump) my knowledge, and the most simple thing I can do is to recycle some tweets and make the best of it.
2) Mine has spacers so that it is above the page.
3) One of our smarties in our class always added an extra few digits just for fun.
4) 4 of us had to do a makeup physics class because we didn't pass the required level (long story where if you missed the level, they marked you down 2 more levels even if you passed those papers
5) Never thought of it that way, but yes exactly.
6) Mine were both Faber Castelle. Expensive but nice - some form of plastic.
Calculators came in the year after my course. Never bough a Scientific one.
Sure killed the slide rules and log tables!
IMHO, would be nice for after reset, the P2 copies some/all serial ROM to hub ram, then executes enough to...
1) Check if Serial avail (how about RXD=1)
A "1" can either be a pull-up or a serial connection. Need to wait long enough to ensure a "space" is not being sent at a low speed (say minimum 9600?)
Wait for a "space" to set baud and respond.
Now wait for instruction to indicate what to do...
a) download code (no more resets as this requires DTR/RTS which may not be available from wireless Comms, or from simple serial devices/dongles. ie Ditch the transistor reset circuit required for P1 as it's an impediment no longer required.
b) go to rom monitor ( load from serial rom if necessary)
c) go to Tachyon (or anything else in rom)
d) go load/run SPI FLASH
e) go load/run SPI SD Card
f) program downloaded code into FLASH. (no need to program SD as we can launch a program to do file transfers from SD)
It might be worthwhile to perform 2) onwards in parallel to waiting for 1). Need to allow sufficient time for a serial download to start before executing from either FLASH/SD in case its corrupted or we just want to reload it.
It might be worthwhile to check a pull-up on the SPI FLASH/SD pin to skip step 1)
2) Check if SPI FLASH is present
If yes, load small section and run..
3) Check if SPI SD Card is present
If yes, load the "boot sector" and Check for "signature" and if yes, use pointer to load up to 32KB and run. No need to support any special FAT format, although the 32KB would likely be a FAT32 file.
BTW I have been reading how to use the native command mode (both 1bit and 4bit) for SD Cards. The 1bit seems to be basically the same commands as SPI, just using different pins.
However, it does nothing for my ability to program in Forth. So I don't think exposure to TI vs HP vs Casio etc. makes much difference. The RPN part isn't what's difficult with Forth. It's everything else.
Still, I support the idea of a Forth-based monitor. I think that's where even I could find a way to use Forth (my problem with Forth is that I can't find any way to use it for my "normal" programming projects.)
(The OT part.. I have several slide rules on my Android tablet.. and they work. And I have a Japanese wooden abacus that I'm learning to use. It's an incredible tool.)
Sure it's better than nothing, but a few DOS routines than can be called from cmd prompt
that also can be used as function calls in spin/c/asm programs would be useful.
FAT32
MEM
GPIO
CLOCK
The curious can drop to a Forth prompt and go for it.
Others would use the features. This is the way of Forth more often than most of us probably realize.
Everyone wants that filesystem aware boot, for example. (Most everyone)
A MCU that can do usb in hardware but first needs a ftdi chip to get the program in to work, people will scratch their head.
* USB code is simply too large
* It is not yet stable enough for ROM, nor likely to be...
* Users often still need that Low impact, KISS, UART connection for debug
(the better MCU development boards include both the All-Bauds UART and the Debug-USB-Bridge)