ROM changes for next silicon...

BOOTER

This is the boot code that checks the pull-ups and pull-downs and decides whether to run the serial, load/run FLASH, or pass control to the SD BOOTER, or via serial to TAQOZ or the MONITOR.

This is Chip’s code and currently I am unsure if he has any changes planned. I know Peter would like control passed to TAQOZ if all other possibilities fail.

TAQOZ

Peter has been working tirelessly adding all sorts of features. I’ll leave him to comment.

SD BOOTER

I am tweeting the code to improve speed. The result is likely that it may no longer be “callable” from user programs. That also means the Monitor might not be able to call the SD BOOTER. Does this matter?

I am also considering removal of support for the older SD Cards where the address is byte rather than sector. It’s a 9bit shift but saves a few instructions. If FAT16 was supported (need to check) it will be removed. Only FAT32 will be supported, otherwise the MBR will be used for booting as is currently supported.

MONITOR/DEBUGGER

Other than possible removal of calling the SD BOOTER (as mentioned above), I don’t have anything planned. There really isn’t any space available.

Have I missed anything?
My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
Website: www.clusos.com
Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
«1

Comments

  • I had a card that was formatted FAT16, but reported in Windows as FAT32. It would not boot the P2-ES until formatted as FAT32. I don't think FAT16 support is needed.
    Terry's Workbench

    Feel the need for speed between your PC's com port and Prop?
    Try the FTDI 245 and the FullDuplexParallel Object.
    Check out my spin driver for the Parallax "96 x 64 Color OLED Display Module" Product ID: 28087
    22FPS video from the P2 on the Parallax "96 x 64 Color OLED Display Module" https://www.youtube.com/watch?v=ja84rf38QHM
  • Thanks. Yes FAT16 is way too old now.
    Shame MS patented (invalid IMHO) exFAT. Otherwise I’d support the reading of files but too risky to fall foul of MS :)
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • msrobotsmsrobots Posts: 2,909
    edited 2019-01-30 - 22:08:49
    I am not sure what you mean by Monitor not able to call SD-booter.

    I do really like your callable HUBexec methods, especially the ability to load a file from SD into any HUB location. will that still be possible?

    The next thing I do not really like I that your boot file can NOT overwrite the ROM, why you restrict it to 512K - ROM length?

    Since the ROM is RAM it would be nice to load a full 512K image, overwriting the ROM in HUB. One could load a full image and then write protect the ROM area (if this is still there, havn't found it yet)

    Byte addressing can go, you can not buy SD cards that small anymore.

    It would be nice if all the ROM code uses one fixed ROM location for the values of RX and TX,
    RXpin long 63
    TXpin long 62
    
    and
    
    wrpin xxx, RXpin
    instead of
    wrpin xxx,#RXpin
    
    

    same goes for the mode selector used, if they would be a fixed long in the ROM one could overwrite the 4 longs and jump into the ROM using different pins then 63/62,

    The mode selector is especially important, because to use the ROM as a serial device, and being able to access MONITOR/DEBUGGER/TAQOZ via a serial driver from any program requires to set the RX pin mode running on smart pin 63 to some different pin to free 63 and make it listen to some neighboring pin so that one can be used for output in smart mode.

    I have a thread here (https://forums.parallax.com/discussion/169620/hijacking-the-p2-eval-rom#latest) where I patch the ROM to do that, and it works nicely (except lsio in TAQOZ) but requires a lot of patches, it would be nice just to patch 4 longs.

    So if it would be possible to spare 4 longs for this purpose that would be great. Actually its just 3 since TAQOZ has already a long for RXpin. Since TAQOZ now gets compressed in the ROM patching will be more complicated, thus asking for 4 fixed location is more important.


    Enjoy!

    Mike
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • msrobots wrote: »
    I am not sure what you mean by Monitor not able to call SD-booter.

    I do really like your callable HUBexec methods, especially the ability to load a file from SD into any HUB location. will that still be possible?
    No. The SD code will be in cog, so it cannot co-exist with your user code.
    The next thing I do not really like I that your boot file can NOT overwrite the ROM, why you restrict it to 512K - ROM length?

    Since the ROM is RAM it would be nice to load a full 512K image, overwriting the ROM in HUB. One could load a full image and then write protect the ROM area (if this is still there, havn't found it yet)
    Specifically so you cannot overwrite the ROM code with faulty code.
    This is easily overcome by using a simple 2-stage loader.
    Yes, the write protect feature is still there.

    Byte addressing can go, you can not buy SD cards that small anymore.
    Agreed.

    It would be nice if all the ROM code uses one fixed ROM location for the values of RX and TX,
    RXpin long 63
    TXpin long 62
    
    and
    
    wrpin xxx, RXpin
    instead of
    wrpin xxx,#RXpin
    
    

    same goes for the mode selector used, if they would be a fixed long in the ROM one could overwrite the 4 longs and jump into the ROM using different pins then 63/62,

    The mode selector is especially important, because to use the ROM as a serial device, and being able to access MONITOR/DEBUGGER/TAQOZ via a serial driver from any program requires to set the RX pin mode running on smart pin 63 to some different pin to free 63 and make it listen to some neighboring pin so that one can be used for output in smart mode.

    I have a thread here (https://forums.parallax.com/discussion/169620/hijacking-the-p2-eval-rom#latest) where I patch the ROM to do that, and it works nicely (except lsio in TAQOZ) but requires a lot of patches, it would be nice just to patch 4 longs.

    So if it would be possible to spare 4 longs for this purpose that would be great. Actually its just 3 since TAQOZ has already a long for RXpin. Since TAQOZ now gets compressed in the ROM patching will be more complicated, thus asking for 4 fixed location is more important.
    This sounds simple, but...

    Firstly, we didn't have ROM space.

    But most importantly, the fixed locations need to be in cog, not hub. I am already taking 16 longs in cog to support the monitor. SD required another 32 longs in cog.

    rxmode & tx mode can be patched in the ROM - 2 places.

    baud and the receive buffer location can be externally set.


    Enjoy!

    Mike

    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Cluso99 wrote: »
    I am tweeting the code to improve speed.

    My experience has been that Twitter is useless for improvement of most things. :o
  • Cluso99 wrote: »
    I am tweeting the code to improve speed.

    My experience has been that Twitter is useless for improvement of most things. :o

    LOL

    Crap autocorrection. Need to turn it off as it makes more mistakes than it fixes :(
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Or as autocorrection might phrase it, "autocorruption"
  • well, in the current ES rom there are 22 locations to get patched, not 2. And that it will be later a location in the cog would not matter, since my goal is to use the rom to start my own program, leaving enough space for TAQOZ at the bottom, start my main prog in cog1 then patch the rom and 'restart' the rom with new pins by jumping COG0 to TAQOZ start in the ROM.

    That does currently work like a charm, except lsio resetting the PINs for TAQOZ, if you avoid lsio you can use TAQOZ as serial device.

    But maybe I am wrong and the official way is for my program to include a complete TAQOZ, write TAQOZ code to switch the PINS, write TAQOZ code to start my own Program in COG1, include the whole shebang into every program I want to debug or use TAQOZ on liners and ignore completely that we have a TAQOZ in ROM.

    Oh there is another way, I can just use a second P2, connect it serial to the first one and use that from my program as smart IO processor. It just would work on a different chip with different pins and to watch my program while running I just need a lot of wires to connect all pins I want to observe with TAQOZ.

    I give up

    Mike
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • ersmithersmith Posts: 3,390
    edited 2019-02-01 - 02:37:17
    Could we reserve a block of memory in HUB RAM for program configuration? I'm thinking of things like clock frequency, clock mode, baud rate, and so forth that different COGs might wish to share. Ideally it'd be nice to have at least 32 bytes reserved for this kind of configuration, although more is better.

    Lower HUB RAM is convenient because it's easily accessible via immediate addressing. But if that's a problem let's reserve some space at the top of HUB RAM instead.

    I don't think we need to define the contents of this space yet, just make sure that everyone agrees not to stomp on it. At some point in the future we can define how programs will populate it. Having the ROM routines leave it alone would be convenient for preserving data across soft resets, and for knowing that it's safe to call into the ROM without that memory being written to.

    (In case it's not obvious I'm posting in this thread because I want the area to be defined across the system, and to know that ROM subroutines will leave this area alone. If we can put some "bread crumbs" in there, like any autobaud rate that the ROM has discovered, and/or an indication of the boot device, so much the better.)
  • ersmith wrote: »
    Could we reserve a block of memory in HUB RAM for program configuration? I'm thinking of things like clock frequency, clock mode, baud rate, and so forth that different COGs might wish to share. Ideally it'd be nice to have at least 32 bytes reserved for this kind of configuration, although more is better.

    Lower HUB RAM is convenient because it's easily accessible via immediate addressing. But if that's a problem let's reserve some space at the top of HUB RAM instead.

    I don't think we need to define the contents of this space yet, just make sure that everyone agrees not to stomp on it. At some point in the future we can define how programs will populate it. Having the ROM routines leave it alone would be convenient for preserving data across soft resets, and for knowing that it's safe to call into the ROM without that memory being written to.

    How about:

    0..3 = long Frequency
    4..7 = long PLL/clock value for HUBSET
  • jmgjmg Posts: 13,920
    cgracey wrote: »
    How about:

    0..3 = long Frequency
    4..7 = long PLL/clock value for HUBSET

    That's good, what about reserving fields for RCFAST and RCSLOW values, that could be calibrated & read from FLASH ?
  • cgraceycgracey Posts: 11,711
    edited 2019-02-01 - 03:56:55
    jmg wrote: »
    cgracey wrote: »
    How about:

    0..3 = long Frequency
    4..7 = long PLL/clock value for HUBSET

    That's good, what about reserving fields for RCFAST and RCSLOW values, that could be calibrated & read from FLASH ?

    The RCFAST would hold frequency pretty well over temperature, assuming the 1.8V core voltage was consistent. The RCSLOW is all over the place with temperature, though.

    Holding calibration values seems like giving false hope.
  • jmgjmg Posts: 13,920
    cgracey wrote: »
    The RCFAST would hold frequency pretty well over temperature, assuming the 1.8V core voltage was consistent. The RCSLOW is all over the place with temperature, though.

    Holding calibration values seems like giving false hope.

    Maybe for RCSLOW, but storing RCFAST calibrates is widespread industry practice - was you say, "RCFAST would hold frequency pretty well over temperature"
    Users do not have to calibrate, but it seems if 'Useful values' space is being reserved, allocating a known-location where RCFAST could be found, would be useful.
    A blank flash value could indicate no-valid.
  • FYI My P2-ES RCFAST runs @ ~23.94 Mhz over temps from 20C to 35C.
    Melbourne, Australia
  • Mine is 23.05 MHz today.
  • While Hub $0 and up sounds great for these, Hub $00-$FF could be good for fast hub tables, vectors, etc. I’d hate to lose this possibility for code.

    Top of Hub just below the interrupt vectors might be better, and it can be write protected.

    Some of the ROM boot code can be overwritten. For example, I overwrite Chips Flash and Serial for the Monitor’s default input buffer.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • TAQOZ

    I think it would be great to be able to call TAQOZ from a user program. However I see a couple of flaws with this.

    Firstly, Peter is still adding features. But some of these need to go to fit in ROM.

    TAQOZ is still being extended and it won’t stop when the ROM freezes in a few days time.

    It will need more ROM to support this.

    The whole point here is that TAQOZ (for user program calling) would be better loaded from Flash or SD. So it could be made callable in the future, rather than diverting Peters attention now. And IMHO, it would then be a superior product than having a cut down version loaded from ROM. After all, TAQOZ is there to get the P2 talking and tested without requiring Flash or SD. Once you have Flash or SD, then anything can be loaded.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Since Taqoz receives its commands via serial, is it possible to send Taqoz commands via the receive Smartpin it is listening to? Override the smartpin mode with something mailbox-like, but in a way that Taqoz is none the wiser?

    (or perhaps modify taqoz to recognize when the smartpin receive mode has been changed over to a message box)
  • Since your in control of the instructions couldn't you build some instructions that would hold these reserved values and then be able to access them with these instructions. Wouldn't be as nice as just accesses them from memory but would make storing and sharing simple.

    Mike
  • cgracey wrote: »
    ersmith wrote: »
    Could we reserve a block of memory in HUB RAM for program configuration? I'm thinking of things like clock frequency, clock mode, baud rate, and so forth that different COGs might wish to share. Ideally it'd be nice to have at least 32 bytes reserved for this kind of configuration, although more is better.

    How about:

    0..3 = long Frequency
    4..7 = long PLL/clock value for HUBSET

    If we put the config block at address 0 I think the first long should be a JMP over the config area (or to wherever the final code is).

    Which actually is a good argument for moving the config area to the top of HUB RAM, because typically at boot time stuff gets loaded at the bottom. Perhaps right under the ROM area we could reserve 16 longs for config. WIth two of those longs being set to Frequency and PLL/clock value?

  • ersmith wrote: »
    cgracey wrote: »
    ersmith wrote: »
    Could we reserve a block of memory in HUB RAM for program configuration? I'm thinking of things like clock frequency, clock mode, baud rate, and so forth that different COGs might wish to share. Ideally it'd be nice to have at least 32 bytes reserved for this kind of configuration, although more is better.

    How about:

    0..3 = long Frequency
    4..7 = long PLL/clock value for HUBSET

    If we put the config block at address 0 I think the first long should be a JMP over the config area (or to wherever the final code is).

    Which actually is a good argument for moving the config area to the top of HUB RAM, because typically at boot time stuff gets loaded at the bottom. Perhaps right under the ROM area we could reserve 16 longs for config. WIth two of those longs being set to Frequency and PLL/clock value?

    It's hard for me to get a feel for what would be optimal, yet.
  • ersmith wrote: »
    cgracey wrote: »
    ersmith wrote: »
    Could we reserve a block of memory in HUB RAM for program configuration? I'm thinking of things like clock frequency, clock mode, baud rate, and so forth that different COGs might wish to share. Ideally it'd be nice to have at least 32 bytes reserved for this kind of configuration, although more is better.

    How about:

    0..3 = long Frequency
    4..7 = long PLL/clock value for HUBSET

    If we put the config block at address 0 I think the first long should be a JMP over the config area (or to wherever the final code is).

    Which actually is a good argument for moving the config area to the top of HUB RAM, because typically at boot time stuff gets loaded at the bottom. Perhaps right under the ROM area we could reserve 16 longs for config. WIth two of those longs being set to Frequency and PLL/clock value?
    Eric, I like that suggestion. I actually implemented that in p2gcc, but then I decided to move the config block to $400. This works fine for C code running hubexec, but I think putting the config block at $0 with a JMP at the beginning would appeal to more people.
  • Peter posted his TAQOZ configuration info on another thread. It starts at 0 with a JMP. I think it's got the kinds of things many programs would be interested in, so why don't we just adopt that as a standard?

    What I was thinking is that the initial boot ROM could clear the config area (or fill it with sensible defaults) and subsequent programs could probe it and use the values there if they are valid. If the user changes things (e.g. the clock frequency) they should update the corresponding fields.

    Here is the current TAQOZ config area:
    00000              		orgh	0
    00000 000          		org
    00000 000 fd900058 		jmp	#initsys
                       
                       '**************** configuration block **************** '
                       ''
    00004 001 452d3250 		byte	"P2-ES   "		' 8 character ID'
    0000c 003 03       _OPTIONS	byte	%0000_0011		' options    SD,FLASH
    0000d 003 000000   		byte	0,0,0
                       
                       '	*** CLOCK ***	'
    00010 004 01312d00 _XIN		long	XIN			' input freqency'
    00014 005 11e1a300 _CPUHZ		long	CPUHZ			' final clock '
    00018 006 01000ef8 _CLKCFG		long	CLKCFG	''$014CB3FC 'CLKCFG
                       
                       '	*** SERIAL/VGA/KEYBOARD *** '
    0001c 007 0001c200 _BAUD		long	baud_rate
    00020 008 03020100 _VGACFG		long	$03020100		' VRGBH pins '
    00024 009 00000004 		long	4
    00028 00a 00000b8c _VGAINIT	long	@vgainit		' VGA code '
    0002c 00b 0aaaaab0 _VGASET		long	round(fset)
    00030 00c 00000607 _KBCFG		long	$0607
                       '	*** RESET VECTORS *** '
    00034 00d 00000420 _RESET		long	@RESET
    00038 00e 00001f8c _IDLE		long	@IDLE
    0003c 00f 00002044 _TERMINAL	long	@TERMINAL		' COG0 TASK'
    00040 010 00000000 _COG1		long	0			' COG1 TASK ( 0=none )
    00044 011 00000000 _COG2		long	0
    00048 012 00000000 _COG3		long	0
    0004c 013 00000000 _COG4		long	0
    00050 014 00000000 _COG5		long	0
    00054 015 00000000 _COG6		long	0
    00058 016 00000000 _COG7		long	0
    
    The only ones fastspin is likely to touch are the CPU frequency ($14), mode setting ($18), and baud rate ($1c).

    I'll move the fastspin config area to match TAQOZ in the next fastspin release, if that sounds good to everyone else.
  • jmgjmg Posts: 13,920
    ersmith wrote: »
    Peter posted his TAQOZ configuration info on another thread. It starts at 0 with a JMP. I think it's got the kinds of things many programs would be interested in, so why don't we just adopt that as a standard?

    What I was thinking is that the initial boot ROM could clear the config area (or fill it with sensible defaults) and subsequent programs could probe it and use the values there if they are valid. If the user changes things (e.g. the clock frequency) they should update the corresponding fields.

    Here is the current TAQOZ config area:
    00000              		orgh	0
    00000 000          		org
    00000 000 fd900058 		jmp	#initsys
                       
                       '**************** configuration block **************** '
                       ''
    00004 001 452d3250 		byte	"P2-ES   "		' 8 character ID'
    0000c 003 03       _OPTIONS	byte	%0000_0011		' options    SD,FLASH
    0000d 003 000000   		byte	0,0,0
                       
                       '	*** CLOCK ***	'
    00010 004 01312d00 _XIN		long	XIN			' input freqency'
    00014 005 11e1a300 _CPUHZ		long	CPUHZ			' final clock '
    00018 006 01000ef8 _CLKCFG		long	CLKCFG	''$014CB3FC 'CLKCFG
                       
                       '	*** SERIAL/VGA/KEYBOARD *** '
    0001c 007 0001c200 _BAUD		long	baud_rate
    00020 008 03020100 _VGACFG		long	$03020100		' VRGBH pins '
    00024 009 00000004 		long	4
    00028 00a 00000b8c _VGAINIT	long	@vgainit		' VGA code '
    0002c 00b 0aaaaab0 _VGASET		long	round(fset)
    00030 00c 00000607 _KBCFG		long	$0607
                       '	*** RESET VECTORS *** '
    00034 00d 00000420 _RESET		long	@RESET
    00038 00e 00001f8c _IDLE		long	@IDLE
    0003c 00f 00002044 _TERMINAL	long	@TERMINAL		' COG0 TASK'
    00040 010 00000000 _COG1		long	0			' COG1 TASK ( 0=none )
    00044 011 00000000 _COG2		long	0
    00048 012 00000000 _COG3		long	0
    0004c 013 00000000 _COG4		long	0
    00050 014 00000000 _COG5		long	0
    00054 015 00000000 _COG6		long	0
    00058 016 00000000 _COG7		long	0
    
    The only ones fastspin is likely to touch are the CPU frequency ($14), mode setting ($18), and baud rate ($1c).

    I'll move the fastspin config area to match TAQOZ in the next fastspin release, if that sounds good to everyone else.

    Sound good, but maybe TAQOZ can be packed better, to make the most useful info lowest ?
    eg final clock (CPUHZ) is the most useful, then XIN and CLKCFG, and then BAUD etc


    there was also this point made :
    Cluso99 wrote: »
    While Hub $0 and up sounds great for these, Hub $00-$FF could be good for fast hub tables, vectors, etc. I’d hate to lose this possibility for code.
    Top of Hub just below the interrupt vectors might be better, and it can be write protected.

    ie Config info should not compromise speed of possible other code. Config info is read-rarely, so can go pretty much anywhere, it just needs to be a defined location and order.
  • jmg wrote: »
    ersmith wrote: »
    Peter posted his TAQOZ configuration info on another thread. It starts at 0 with a JMP. I think it's got the kinds of things many programs would be interested in, so why don't we just adopt that as a standard?
    Sound good, but maybe TAQOZ can be packed better, to make the most useful info lowest ?
    eg final clock (CPUHZ) is the most useful, then XIN and CLKCFG, and then BAUD etc

    There's no packing involved, they're all long words. So it really doesn't make any difference, and I suspect people will disagree vehemently about what words are "most useful" :).
    there was also this point made :
    Cluso99 wrote: »
    While Hub $0 and up sounds great for these, Hub $00-$FF could be good for fast hub tables, vectors, etc. I’d hate to lose this possibility for code.
    Top of Hub just below the interrupt vectors might be better, and it can be write protected.

    ie Config info should not compromise speed of possible other code. Config info is read-rarely, so can go pretty much anywhere, it just needs to be a defined location and order.

    Once you're using a table or vector you're calculating the address, so the speed of access will be the same wherever you are. I think the only benefit of low HUB memory is that it can be accessed via an instruction like "rdlong freq, #$14". Table accesses are going to look more like:
    add tableaddr, tableptr
    rdlong tableaddr
    
    I guess sometimes you could save a register if you could write "#tablebase" instead of "tableptr", which would be an argument for moving the config area later.

    OTOH there's already a config table in TAQOZ (i.e. in the current ROM) so there's a pretty compelling argument for us to standardize on that and to keep it in future ROMs.
  • Cluso99Cluso99 Posts: 15,405
    edited 2019-02-01 - 21:05:05
    If you insist with it being in low Hub, then consider changing the ROM BOOTER (serial, flash and SD) to load the cog from hub $10 instead of hub $0. Then there’s no need for a jump at $0 in future silicon.

    FWIW I still think it should be in top of hub. We can make the ROM load this correctly but time is slipping by quickly.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Cluso99 wrote: »
    If you insist with it being in low Hub, then consider changing the ROM BOOTER (serial, flash and SD) to load the cog from hub $10 instead of hub $0. Then there’s no need for a jump at $0 in future silicon.

    FWIW I still think it should be in top of hub. We can make the ROM load this correctly but time is slipping by quickly.

    BTW, I'm not insisting. I've been pushing for a standard config block since I initially saw it as a way to make the bootloader itself load faster without being forced to go through a second stage loader. Having the option to simply read the config and change the clock to a higher rate and preferably one that has already been specified, can only be a good thing.

    I can see the merits of having it in ROM but at the same time this complicates addressing since the first 256 locations of low mem (let's call it the page 0) can use 9-bit immediate, or at least 8-bit immediate if that has changed for this mode?

    So I will have a look at what may be required.

    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    --->CLICK THE LOGO for more links<---
    P2 +++++ TAQOZ INTRO & LINKS +++++ P2 SHORTFORM DATASHEET
    P1 +++++ Latest Tachyon includes EASYFILE +++++ Tachyon Forth News Blog
    Brisbane, Australia
  • Cluso99 wrote: »
    If you insist with it being in low Hub, then consider changing the ROM BOOTER (serial, flash and SD) to load the cog from hub $10 instead of hub $0. Then there’s no need for a jump at $0 in future silicon.

    FWIW I still think it should be in top of hub. We can make the ROM load this correctly but time is slipping by quickly.

    BTW, I'm not insisting. I've been pushing for a standard config block since I initially saw it as a way to make the bootloader itself load faster without being forced to go through a second stage loader. Having the option to simply read the config and change the clock to a higher rate and preferably one that has already been specified, can only be a good thing.

    I can see the merits of having it in ROM but at the same time this complicates addressing since the first 256 locations of low mem (let's call it the page 0) can use 9-bit immediate, or at least 8-bit immediate if that has changed for this mode?

    So I will have a look at what may be required.
    I see the lower 256 hub (yes 8bits IIRC) as better kept for programs that require easy access to this, which is why IMHO top of hub is a better place. I also think there are more things to go there for an OS of sorts.

    And yes, we've been trying for years to get some consensus for where to place the mailbox things, but no-one wanted to discuss such things :(

    BTW here is what I reserve in my P1 OS
    ' OS Hub Definitions...         
    ' ------------------       bytes
      _HubFree      = $7FFC  '    4     ' \ stores total hub available (typ $7800)
                                        ' |  (hub is allocated to the OS above this value)
                                        ' /  (eg $7000 means $0000-$6FFF is available)
    
      _OS_DateTime  = $7FF8  '    4     'Year20xx  Month    Date    Hours   Minutes   Seconds
                                        ' (00-63)  (1-12)  (1-31)  (00-23)  (00-59)   (00-59)                                     
                                        '  000000___0000____00000___00000____000000____000000
                                        'To convert to FAT16/32 format, shift >>1 then add 16<<25
                                        '   --> Y(7)M(4)D(5)H(5)M(6)S*2(5bits) Base=1980
                                        '  (FYI seconds in 4yrs = 126,230,400)
                                                                                                       
      _OS_Rows      = $7FF7  '    1     ' \ combined <lf> and rows
        _LF_MASK      = $80             ' | b7  : 1= <lf> ON; 0= strip <lf>
        _ROW_MASK     = $7F             ' / b0-6: no of rows on screen (0-127)
      _OS_Columns   = $7FF6  '    1     '         no of cols on screen (0-255)
      _OS_Cogs      = $7FF5  '    1     ' stay resident cogs: 1= don't stop on reboot
      _OS_Clkmode   = $7FF4  '    1     ' clkmode: saved fm hub byte $0004
    
      _OS_Clkfreq   = $7FF0  '    4     ' clkfreq(Hz): saved fm hub long $0000
    
      
      _SDpins       = $7FEC  '    4     ' \ sd pins packed 4 bytes
                             '          ' / Byte 3=/CS, 2=DI, 1=CLK, 0=DO
      _SIOpins      = $7FE8  '    4     ' \ serial pins and mode settings (and cog#)
                             '          ' / Byte 3=cog, 2=mode, 1=SI, 0=SO
      _SIObaud      = $7FE4  '    4     ' serial baud (speed typ 115,200)
    
      _Hardware     = $7FE0  '    4     ' \ hardware: hi-word=company, lo-word=config
                                        ' |            $0001 = Cluso99  $0001 = RamBlade 1           
                                        ' |            $0001 = Cluso99  $0002 = TriBlade#2           
                                        ' |            $0001 = Cluso99  $0003 = RamBlade3
                                        ' |            $0001 = Cluso99  $0004 = P8XBlade2
                                        ' /            $0001 = Cluso99  $0007 = CpuBlade7
                                        ' ^^^ may be more valuable for something else??
    
      _AuxIn        = $7FDC  '    4     ' auxilary input  rendezvous
      _AuxOut       = $7FD8  '    4     ' auxilary output rendezvous
      _StdIn        = $7FD4  '    4     ' standard input  rendezvous
      _StdOut       = $7FD0  '    4     ' standard output rendezvous
    
      _CIDRegister  = $7FC0  '   16     ' \ CID (card identification register)
      _CSDRegister  = $7FB0 '    16     ' | CSD (card specification data register)
      _CIDcopyAddr  = $7FAC  '    4     ' | address of CIDcopy
      _SDblockAddr  = $7FA8  '    4     ' | address of Block
      _SDsectorAddr = $7FA4  '    4     ' | address of Sector
      _SDflags      = $7FA3 '     1     ' | (WPflag)<<4 | (NoCard) 0==OK  (for later!!!
      _SDlockcogid  = $7FA2  '    1     ' | (LockID+1)<<4 | (CogID+1)
      _SDerror      = $7FA1  '    1     ' | error   (returned from pasm driver)
      _SDcommand    = $7FA0  '    1     ' / command (set by app, cleared by pasm driver)
    
      _OSreserved   = $7F90  '   16     ' undefined
    
      _pBuffer_C    = $7F80  '   16  '| ' \ user buffers... 
      _pBuffer_B    = $7F40  '   64  '| ' |   (maybe serial in and serial out buffers?)
      _pBuffer_A    = $7F00  '   64  '| ' /   (used to pass parameters between modules)
      _pBuffer      = $7F00  '  144  '^ ' / ...joins all 3 buffers A+B+C
    
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Can't you just have a few longs at the beginning of the boot file say what to set the clock to when loading?
    Prop Info and Apps: http://www.rayslogic.com/
  • Rayman wrote: »
    Can't you just have a few longs at the beginning of the boot file say what to set the clock to when loading?

    That's fine for loading, but at run time you might be starting up code on another COG that needs to get the system configuration. If everything is built together at the same time that's known, but if the modules come from different places (some from disk, some from ROM, some from serial) then it would be nice if they could agree on a few basic things.

    One of the use cases we're considering here is being able to run TAQOZ from a PASM program to invoke some basic functions (e.g. reading from disk). This'll save having to re-invent the wheel: some system functions could be written in Forth and then re-used in PASM, C, Spin, etc.

Sign In or Register to comment.