Welcome to the Parallax Discussion Forums, sign-up to participate.

# TAQOZ - Tachyon Forth for the P2 BOOT ROM

• Posts: 14,494
These secondary bootloaders annoy me in that they are an extra layer that needs to be added when all we need to know at boot is what it has for a clock. So I propose that both the Flash and the SD have configuration parameters that are set by the user so that when they save a file they can also describe their system that the boot loader can use. The loader wants to know if there is an oscillator or a crystal, the frequency of that crystal, the desired runtime frequency after booting, and perhaps the baud rate of any terminal that may be connected.
It may also need to know the stabilize delay. Maybe the header can simply store the 32b Osc Config copy, which includes the XI settings, and PLL values, plus the delay ?
Keeps the ROM simpler.

• Posts: 16,660
edited 2018-11-04 - 03:49:44
Chip,
Is this how the xtal circuit works...

clockfreq = crystal / dddddd * mmmmmmmmmm / pppp

where pppp is 1=15, 2=0, 4=2...30=14 (eg divide by 1 means pppp=%1111, divide by 4 means pppp=%0001)

Put differently, the pppp divider divides the result of the xtal divided by dddddd and multiplied by mmmmmmmmmm
• Posts: 13,077
Cluso99 wrote: »
Chip,
Is this how the xtal circuit works...

clockfreq = crystal / dddddd * mmmmmmmmmm / pppp

where pppp is 1=15, 2=0, 4=2...30=14 (eg divide by 1 means pppp=%1111, divide by 4 means pppp=%0001)

Put differently, the pppp divider divides the result of the xtal divided by dddddd and multiplied by mmmmmmmmmm

That's right. And try to keep the VCO over 50MHz.
• Posts: 16,660
edited 2018-11-04 - 10:14:43
Crystal Parameters for HUBSET

This should work. Just fill in the values and the values will be calculated for you...
```CON
_XTALFREQ       = 12_000_000                                    ' crystal frequency
_XDIV           = 12                                            ' crystal divider to give 1MHz
_XMUL           = 180                                           ' crystal / div * mul
_XDIVP          = 1                                             ' crystal / div * mul /divp to give _CLKFREQ (1,2,4..30)
_XOSC           = %01                                   'OSC    ' %00=OFF, %01=OSC, %10=15pF, %11=30pF
_XSEL           = %11                                   'XI+PLL ' %00=rcfast(20+MHz), %01=rcslow(~20KHz), %10=XI(5ms), %11=XI+PLL(10ms)
_XPPPP          = ((_XDIVP>>1) + 15) & \$F                       ' 1->15, 2->0, 4->1, 6->2...30->14
_CLOCKFREQ      = _XTALFREQ / _XDIV * _XMUL / _XDIVP
_SETFREQ        = 1<<24 + (_XDIV-1)<<18 + (_XMUL-1)<<8 + _XPPPP<<4 + _XOSC<<2  ' %0000_000e_dddddd_mmmmmmmmmm_pppp_cc_00  ' setup  oscillator
_ENAFREQ        = _SETFREQ + _XSEL                                             ' %0000_000e_dddddd_mmmmmmmmmm_pppp_cc_ss  ' enable oscillator

DAT
'+-------[ Set Xtal ]----------------------------------------------------------+
hubset  #0                              ' set 20MHz+ mode
hubset  ##_SETFREQ                      ' setup oscillator
waitx   ##20_000_000/100                ' ~10ms
hubset  ##_ENAFREQ                      ' enable oscillator
'+-----------------------------------------------------------------------------+
```
Oops. Fixed this _SETFREQ = 1<<24 +.. was 1<<25
• Posts: 13,077
It seems to me that the goal of the initial booter in ROM should be ONLY to load in enough program data from either a Flash or SD card to execute a program that sets the clock mode and loads in the rest of the data to launch the application. We can't cover every SPI memory (flash?) possibility in ROM and exploit their special features. It's futile to try to have the ROM cover unknowns. Same goes for SD card support. Just have common-base approaches to loading in some code and let the code handle the specifics for the bigger job. As they say, reliability is inversely proportional to complexity. Simple is best.
• Posts: 9,711
And a configuration file is a better known then a safe guess
• Posts: 13,077
Cluso99 wrote: »
Crystal Parameters for HUBSET

This should work. Just fill in the values and the values will be calculated for you...
```CON
_XTALFREQ       = 12_000_000                                    ' crystal frequency
_XDIV           = 12                                            ' crystal divider to give 1MHz
_XMUL           = 180                                           ' crystal / div * mul
_XDIVP          = 1                                             ' crystal / div * mul /divp to give _CLKFREQ (1,2,4..30)
_XOSC           = %01                                   'OSC    ' %00=OFF, %01=OSC, %10=15pF, %11=30pF
_XSEL           = %11                                   'XI+PLL ' %00=rcfast(20+MHz), %01=rcslow(~20KHz), %10=XI(5ms), %11=XI+PLL(10ms)
_XPPPP          = ((_XDIVP>>1) + 15) & \$F                       ' 1->15, 2->0, 4->1, 6->2...30->14
_CLOCKFREQ      = _XTALFREQ / _XDIV * _XMUL / _XDIVP
_SETFREQ        = 1<<25 + (_XDIV-1)<<18 + (_XMUL-1)<<8 + _XPPPP<<4 + _XOSC<<2  ' %0000_000e_dddddd_mmmmmmmmmm_pppp_cc_00  ' setup  oscillator
_ENAFREQ        = _SETFREQ + _XSEL                                             ' %0000_000e_dddddd_mmmmmmmmmm_pppp_cc_ss  ' enable oscillator

DAT
'+-------[ Set Xtal ]----------------------------------------------------------+
hubset  #0                              ' set 20MHz+ mode
hubset  ##_SETFREQ                      ' setup oscillator
waitx   ##20_000_000/100                ' ~10ms
hubset  ##_ENAFREQ                      ' enable oscillator
'+-----------------------------------------------------------------------------+
```

Looks good. Nice way to cover the _XPPPP cases.
• Posts: 13,077
Tools will install appropriate loaders. The ROM doesn't need to second-guess the future. Just cover the most basic.
• Posts: 14,494
cgracey wrote: »
That's right. And try to keep the VCO over 50MHz.
.. and below ? MHz ?

There should also be a rule for PFD frequency Min/Max mentioned ? (PFD = Xtal / DDDDDD = VCO / MMMMMMMMMM)

• Posts: 14,494
cgracey wrote: »
Tools will install appropriate loaders. The ROM doesn't need to second-guess the future. Just cover the most basic.

Yes.
The ROM already uses smart pin modes for UART, so it should be able to be acceptably fast, using the Smart Pin SPI modes + RCFAST ?
• Posts: 16,660
So this should give 50MHz minimum and 400MHz maximum?

_XMUL = 180 ' crystal / div * mul
• Posts: 13,077
jmg wrote: »
cgracey wrote: »
That's right. And try to keep the VCO over 50MHz.
.. and below ? MHz ?

There should also be a rule for PFD frequency Min/Max mentioned ? (PFD = Xtal / DDDDDD = VCO / MMMMMMMMMM)

Ah, sorry. 180MHz max, unless you are overclocking, in which case the sky is the limit and you'd use %1111 for the post-divider which means divide-by-1. The first thing to fail is the 10-bit VCO divider (acts as a multiplier) at ~408MHz (don't know how high the VCO actually goes). Fortunately, the core logic isn't being held up by the PLL, because it seems to fail at 360MHz.
• Posts: 16,660
Here is the ROM MBR/VOL signature test code
```'+-----------------------------------------------------------------------------+
'+ Validate MBR/VOL CSUM \$080-\$17F="Prop". If valid, copy to Cog & Run         +
'+-----------------------------------------------------------------------------+
_validateCSUM   mov     bufad,            #\$17C         ' check long at \$17C
cmp     reply,            ##_csum   wz  ' ="Prop"?
if_e    jmp     #@_success80                    ' y: go load it
cmp     reply,            ##_csum2  wz  ' ="ProP"? sector/size?
'               ----------------------------------------
mov     bufad,            #\$174         ' get sector start
mov     bufad,            #\$178         ' get length(bytes)
rdlong  _sectors,         bufad         ' simulate file found
'                                                       ' fall thru to _readFILE
```

Provided we can find a few more longs in the Boot ROM, what if the signature was "Prop" then
+\$170 = the hubset crystal setting ' %0000_000e_dddddd_mmmmmmmmmm_pppp_cc_ss
+\$174 = the sector start
+\$178 = the length(bytes)
+\$17C = "ProP" signature
• Posts: 13,077
Cluso99 wrote: »
Here is the ROM MBR/VOL signature test code
```'+-----------------------------------------------------------------------------+
'+ Validate MBR/VOL CSUM \$080-\$17F="Prop". If valid, copy to Cog & Run         +
'+-----------------------------------------------------------------------------+
_validateCSUM   mov     bufad,            #\$17C         ' check long at \$17C
cmp     reply,            ##_csum   wz  ' ="Prop"?
if_e    jmp     #@_success80                    ' y: go load it
cmp     reply,            ##_csum2  wz  ' ="ProP"? sector/size?
'               ----------------------------------------
mov     bufad,            #\$174         ' get sector start
mov     bufad,            #\$178         ' get length(bytes)
rdlong  _sectors,         bufad         ' simulate file found
'                                                       ' fall thru to _readFILE
```

Provided we can find a few more longs in the Boot ROM, what if the signature was "Prop" then
+\$170 = the hubset crystal setting ' %0000_000e_dddddd_mmmmmmmmmm_pppp_cc_ss
+\$174 = the sector start
+\$178 = the length(bytes)
+\$17C = "ProP" signature

So, you would set the clock as requested by the data, then turn control over to the small booter that was just loaded?
• Posts: 14,494
cgracey wrote: »
Cluso99 wrote: »
Here is the ROM MBR/VOL signature test code
... Provided we can find a few more longs in the Boot ROM, what if the signature was "Prop" then +\$170 = the hubset crystal setting ' %0000_000e_dddddd_mmmmmmmmmm_pppp_cc_ss +\$174 = the sector start +\$178 = the length(bytes) +\$17C = "ProP" signature [/quote] So, you would set the clock as requested by the data, then turn control over to the small booter that was just loaded?[/quote] + Some delay may, or may not, be needed - depends on the external clock source ? If you just loaded a small booter, why not have that code set the clock it wants, then it can also manage the delays ? [code]
...
Provided we can find a few more longs in the Boot ROM, what if the signature was "Prop" then
+\$170 = the hubset crystal setting ' %0000_000e_dddddd_mmmmmmmmmm_pppp_cc_ss
+\$174 = the sector start
+\$178 = the length(bytes)
+\$17C = "ProP" signature

So, you would set the clock as requested by the data, then turn control over to the small booter that was just loaded?

+ Some delay may, or may not, be needed - depends on the external clock source ?

If you just loaded a small booter, why not have that code set the clock it wants, then it can also manage the delays ?
• Posts: 16,660
cgracey wrote: »
Cluso99 wrote: »
Here is the ROM MBR/VOL signature test code
```'+-----------------------------------------------------------------------------+
'+ Validate MBR/VOL CSUM \$080-\$17F="Prop". If valid, copy to Cog & Run         +
'+-----------------------------------------------------------------------------+
_validateCSUM   mov     bufad,            #\$17C         ' check long at \$17C
cmp     reply,            ##_csum   wz  ' ="Prop"?
if_e    jmp     #@_success80                    ' y: go load it
cmp     reply,            ##_csum2  wz  ' ="ProP"? sector/size?
'               ----------------------------------------
mov     bufad,            #\$174         ' get sector start
mov     bufad,            #\$178         ' get length(bytes)
rdlong  _sectors,         bufad         ' simulate file found
'                                                       ' fall thru to _readFILE
```

Provided we can find a few more longs in the Boot ROM, what if the signature was "Prop" then
+\$170 = the hubset crystal setting ' %0000_000e_dddddd_mmmmmmmmmm_pppp_cc_ss
+\$174 = the sector start
+\$178 = the length(bytes)
+\$17C = "ProP" signature

So, you would set the clock as requested by the data, then turn control over to the small booter that was just loaded?

I would set the clock according to the long setting at MBR/VOL offset \$170 (AND off the bottom 2 ss bits), delay 10ms at 30MHz (being max rcfast), then redo with ss set accordingly, then load the data/file at the new clock frequency from sector specified by \$174 for length at \$178.

Maybe this is just too much?

Currently we can load/run an MBR/VOL minimum first stage booter, or load/run from a pointer+length in MBR/VOL, or load/run a FAT32 file "_BOOT_P2.BIX" or "_BOOT_P2.BIY". This FAT32 file can be a small first stage booter, or the real thing. These are all done at RCFAST. The first stage loader can switch xtal.
• Posts: 14,494
edited 2018-11-04 - 05:50:31
Cluso99 wrote: »
Maybe this is just too much?
How much time is saved here ?

Is the same header applicable to FLASH boot ?

I guess to make this flexible/transparent, that 'gear change' could be optional ?
+\$170 = the hubset crystal setting ' %0000_000e_dddddd_mmmmmmmmmm_pppp_cc_ss
ie using those spare 7 bits to signal ignore or apply

• Posts: 13,077
edited 2018-11-04 - 06:45:16
Cluso99 wrote: »
cgracey wrote: »
Cluso99 wrote: »
Here is the ROM MBR/VOL signature test code
```'+-----------------------------------------------------------------------------+
'+ Validate MBR/VOL CSUM \$080-\$17F="Prop". If valid, copy to Cog & Run         +
'+-----------------------------------------------------------------------------+
_validateCSUM   mov     bufad,            #\$17C         ' check long at \$17C
cmp     reply,            ##_csum   wz  ' ="Prop"?
if_e    jmp     #@_success80                    ' y: go load it
cmp     reply,            ##_csum2  wz  ' ="ProP"? sector/size?
'               ----------------------------------------
mov     bufad,            #\$174         ' get sector start
mov     bufad,            #\$178         ' get length(bytes)
rdlong  _sectors,         bufad         ' simulate file found
'                                                       ' fall thru to _readFILE
```

Provided we can find a few more longs in the Boot ROM, what if the signature was "Prop" then
+\$170 = the hubset crystal setting ' %0000_000e_dddddd_mmmmmmmmmm_pppp_cc_ss
+\$174 = the sector start
+\$178 = the length(bytes)
+\$17C = "ProP" signature

So, you would set the clock as requested by the data, then turn control over to the small booter that was just loaded?

I would set the clock according to the long setting at MBR/VOL offset \$170 (AND off the bottom 2 ss bits), delay 10ms at 30MHz (being max rcfast), then redo with ss set accordingly, then load the data/file at the new clock frequency from sector specified by \$174 for length at \$178.

Maybe this is just too much?

Currently we can load/run an MBR/VOL minimum first stage booter, or load/run from a pointer+length in MBR/VOL, or load/run a FAT32 file "_BOOT_P2.BIX" or "_BOOT_P2.BIY". This FAT32 file can be a small first stage booter, or the real thing. These are all done at RCFAST. The first stage loader can switch xtal.

I don't know if it's too much. Perhaps SD card know-how is stable enough that this could get around needing a 2nd-stage loader. If the process is deterministic and not likely needing to change, then I guess reading some clock constants and setting the clock accordingly, then loading the file is doing what the 2nd-stage loader would have done, anyway, without requiring it to be there. That's the thinking behind this, right? It wouldn't preclude anyone from making a 2nd-stage loader, would it? Maybe it's just fine to do that. I know that SPI flash chips vary too widely to be able to take such a singular approach.
• Posts: 14,494
edited 2018-11-04 - 07:27:00
cgracey wrote: »
I don't know if it's too much. Perhaps SD card know-how is stable enough that this could get around needing a 2nd-stage loader. If the process is deterministic and not likely needing to change, then I guess reading some clock constants and setting the clock accordingly, then loading the file is doing what the 2nd-stage loader would have done, anyway, without requiring it to be there. That's the thinking behind this, right? It wouldn't preclude anyone from making a 2nd-stage loader, would it? Maybe it's just fine to do that. I know that SPI flash chips vary too widely to be able to take such a singular approach.

If the Clock setting param is made optional (using the spare bits to say skip, or as a simple checksum of the lower bits, whose error says skip ?) then it becomes invisible, and any second stage loads as before.
It could be useful to have the same param rule on FLASH, to allow faster boot-loading from flash ?
• Posts: 1,713
With test boards hopefully coming out soon, is there a basic getting started document for TAQOS?

Thanks,

C.W.
• Posts: 6,159
Just go to page 1 of this thread. BTW, it's spelled TAQOZ.
• Posts: 9,711
edited 2018-12-04 - 15:13:00
This is a photo of my VGA monitor and PS/2 keyboard setup which is running stand-alone although the serial port is still plugged into the PC but otherwise the Forth console is using VGA and PS/2. When it first starts up it displays the "PARALLAX P2 TAQOZ PC" message and then attempts to mount the SD card and report the name etc. Then it switches to a black on white text format and displays a short listing of the FAT32 directory. In this case I decide to load and compile C2PROG.FTH which has all the programmer and debugging words for the Busy Bee 8051 micro I'm testing. Then I run a simple Fibonacci benchmark, change the pen color to red, set the graphics to use from 400,400 to draw a filled in panel for 100 wide and 60 high before returning the pen back to black.

After this .SF lists the idents of the SPI Flash chip and then I dump some hub RAM. All from the PS/2 keyboard. If I view a BMP file I find it easier to get the console to use 8 or 10 lines at the bottom of the screen for text with 10 TERM so that it only scrolls text in that region.

Here I add a bit more in a crude Q&d way as I define FLAG which simply draws a vertical red/green/blue flag as specified.
• Posts: 14,179
nice
• Posts: 16,660
Looking good Peter, as usual
• Posts: 630
Wow Peter! It looks beautiful, simple and clean!
• Posts: 2,768
Something seems slightly weird Peter with your video driver. I noticed that the pixels at the end of the line wrap back to the start of the line, see the letter E and N on the right edge from the word "PANEL", and also the pixels on the left edge in your picture above. I think you just need to clear the last pixel at the end of the scanline as it is being replicated on the next scanline, or something like that. Maybe it is off by a whole pixel somewhere.
• Posts: 8,613
rogloh wrote: »
Something seems slightly weird Peter with your video driver. I noticed that the pixels at the end of the line wrap back to the start of the line, see the letter E and N on the right edge from the word "PANEL", and also the pixels on the left edge in your picture above. I think you just need to clear the last pixel at the end of the scanline as it is being replicated on the next scanline, or something like that. Maybe it is off by a whole pixel somewhere.

Looks OK to me, like it is just the result of the line of text being longer than the terminal screen can display so it wraps it around to the next line. Could you be mistaking the reflection on the bezel for part of the video image?
• Posts: 1,432
kwinn wrote: »
rogloh wrote: »
Something seems slightly weird Peter with your video driver. I noticed that the pixels at the end of the line wrap back to the start of the line, see the letter E and N on the right edge from the word "PANEL", and also the pixels on the left edge in your picture above. I think you just need to clear the last pixel at the end of the scanline as it is being replicated on the next scanline, or something like that. Maybe it is off by a whole pixel somewhere.

Looks OK to me, like it is just the result of the line of text being longer than the terminal screen can display so it wraps it around to the next line. Could you be mistaking the reflection on the bezel for part of the video image?

I see it too. The very first column of pixels, not of text. It's only on the two lines with an E and an N at the very end.
• Posts: 8,613
kwinn wrote: »
rogloh wrote: »
Something seems slightly weird Peter with your video driver. I noticed that the pixels at the end of the line wrap back to the start of the line, see the letter E and N on the right edge from the word "PANEL", and also the pixels on the left edge in your picture above. I think you just need to clear the last pixel at the end of the scanline as it is being replicated on the next scanline, or something like that. Maybe it is off by a whole pixel somewhere.

Looks OK to me, like it is just the result of the line of text being longer than the terminal screen can display so it wraps it around to the next line. Could you be mistaking the reflection on the bezel for part of the video image?

I see it too. The very first column of pixels, not of text. It's only on the two lines with an E and an N at the very end.

My what sharp eyes you have. With reading glasses on and the laptop screen a couple of inches from my eyes I can finally see it.
• Posts: 9,711
I see what has happened with the pixels on the screen, it looks like my line wrap is off by one pixel but since my left margin is set to 6 pixels it was also easy just to change that to 5 pixels so that the last character fits.