Right now, we are using Ray's SD booter, right? Could it be integrated into TAQOS, so that its subroutines become available in Forth? Or, have you got the equivalent code in TAQOS, already? I mean, is there any functional redundancy, at this point? Or, can making this TAQOS-compatible expand the Forth, while still providing SD boot?
Yes, Ray's SD booter can load an expanded version of TAQOZ from SD. But Ray also has an LMM debugger. There are a lot of more powerful high level TAQOZ functions for debugging but TAQOZ does overwrite the first 64kB. Of course there is a bit of common SD code that could be made compatible but at what cost? Ray's SD boot code is only 1.3k with another 1.4k for his debugger. When we are jammed into a tiny 16kB ROM we will have limitations.
could the rom be expanded to say 32k in the respin?
curious,
Remember also, the die size is package-fixed and finite, so more ROM may mean lower MHz (due to constrained routing room) and/or less RAM.
How much less RAM can you tolerate, to fit in 16k more ROM ?
could the rom be expanded to say 32k in the respin?
curious,
Mike
Yes, but ON Semi might charge us more.
Peter, what could you do with another 16KB?
Pretty much everything We could have full FAT32 utilities, Ethernet, VGA/HDMI, fonts, USB HID, and a GUI. Power on P2 and P2 will power on!
even with all those "goodies" in ROM, for all applications I can think of, you will want to have some application code using them. So external memory will be used anyhow.
And from there a full Tachyon can be loaded including the application.
Given the dynamics of advancements in Tachyon code who would not choose to run the full system instead of a fixed ROM-code.
The only benefit I see is that it would be STABLE.
Like the SPIN-Interpreter in P1.
Something you can rely on even years later.
But would it be worth the opportunity cost @JMG points out above?
Would other (compiled) languages besides FORTH even be able to utilize the ROM code like they would use a BIOS?
even with all those "goodies" in ROM, for all applications I can think of, you will want to have some application code using them. So external memory will be used anyhow.
And from there a full Tachyon can be loaded including the application.
Given the dynamics of advancements in Tachyon code who would not choose to run the full system instead of a fixed ROM-code.
The only benefit I see is that it would be STABLE.
Like the SPIN-Interpreter in P1.
Something you can rely on even years later.
But would it be worth the opportunity cost @JMG points out above?
Would other (compiled) languages besides FORTH even be able to utilize the ROM code like they would use a BIOS?
Solder a chip onto a board, connect power, a monitor, a keyboard, and start programming, all without a PC. That's what I see is useful about it. If we have Ethernet connected then it would also be possible for instance for the P2 to check p2.parallax.com for "extras" that a user/student can select from or install additional firmware onto Flash or SD if selected.
TAQOZ exists on the P2 whereas other languages only exist on the PC and once compiled can use their own routines otherwise we may be squeezing out functionality when it is easy for a PC compiler to include libraries.
All of that stuff sounds great, but do we have time to implement and test it all well enough before the respin is sent off?
Much of it has been done and given that more chips will be available soon means we now have a larger test base in the next couple of months. I don't think Chip needs the new ROM before then.
could the rom be expanded to say 32k in the respin?
curious,
Remember also, the die size is package-fixed and finite, so more ROM may mean lower MHz (due to constrained routing room) and/or less RAM.
How much less RAM can you tolerate, to fit in 16k more ROM ?
Chip, please do not sacrifice speed for larger ROM. Also, please keep the SD booter that does not use hub RAM. This would be important in applications that reboot from SD, and do not want hub RAM disturbed.
I might be the odd one out here.
But I think for an internal boot ROM, less is more.
Don't get me wrong, TAQOZ is awesome and I will use it.
But I rather have a complex VGA command line tool loaded into RAM from an external EEPROM or SD card.
On chip ROMs are set in stone, Complex Dev tools like a VGA command line editor with file system will be changing over time with user updates and improvements.
I mean there is something awesome about the idea of a P2 booting up to something on it's own with almost no external parts, but external eeproms are pretty cheap these days.
Unless I'm missing or not understanding something?
Either way, CAn't wait to try out TAQOZ when the early test ICs are up for grabs.
could the rom be expanded to say 32k in the respin?
curious,
Remember also, the die size is package-fixed and finite, so more ROM may mean lower MHz (due to constrained routing room) and/or less RAM.
How much less RAM can you tolerate, to fit in 16k more ROM ?
Chip, please do not sacrifice speed for larger ROM. Also, please keep the SD booter that does not use hub RAM. This would be important in applications that reboot from SD, and do not want hub RAM disturbed.
Don't worry, I agree too but Chip is simply asking. A respin is a respin and now we have HDMI so things are a bit different already. If I had the extra ROM though I'd sure put it to good use anyway.
Will TAQOZ include a Windowing System in the next re-spin?
Sure, if we have a larger ROM
But no, TAQOZ is useful as it is in 12k of the 16k ROM. But you can can have a larger version sitting in Flash or SD to load as you want, just as I am doing now. I am looking at implementing GUI windowing.
when you were doing your VGA demo above, were all of those words part of TAQOZ, or were you loading additional words off an SD? (my apologies if my terminology is incorrect.)
I might be the odd one out here.
But I think for an internal boot ROM, less is more.
Don't get me wrong, TAQOZ is awesome and I will use it.
But I rather have a complex VGA command line tool loaded into RAM from an external EEPROM or SD card.
That is my concern as well. Does the ROM need "gamma", for instance?
What I am testing at present is the ROM part compiled for RAM and then I use TAQOZ to load extensions and methods I am testing so that I can see what I can include in ROM and what I need to leave out all in preparation for the respin. I'd like to have VGA working in the ROM but that isn't essential. Words such as gamma etc are just to exercise the VGA modes and also see what might be possible later on. I'm not counting on having any more ROM so a lot of these things will be able to be added to TAQOZ by pasting in or loading from SD card etc. Perhaps Chip sees some other possibility for this and either way he has every right to consider and ask the question.
All of the things that Peter "could" do with an extra 16K are things that would very likely be Upgraded/Enhanced/Patched over time.
In other words, if they were baked into a ROM, it would be COMMON for people to be loading Extensions/Patches to them from an SD card anyway, so why bake them in?!?
Just stick to 16K for ROM which has the foundational stuff that will likely NOT need patches over time and load all of the extra stuff from the SD card.
Users will still get all the advantages of having a WHOLE SYSTEM. It will just need to be loaded from a card.
I think this will keep things much more flexible and clean in the long term.
If we apply the same logic that says "why bake it in" then why have TAQOZ at all? If you remember Chip only needed a k or two for his booter and when the question was asked "what can we put in the other 14k" the answer came back that Tachyon would be useful. The primary purpose for TAQOZ therefore is to provide hardware debugging when nothing else seems to work and also of course it is possible to program when no compilers and tools are available. Since it also has FAT32 utilities it can examine and edit files and names etc. It was going to handle SD booting as well however Cluso wanted to do the SD boot loader and then he added his LMM debugger in the process.
If there was nothing but Chip's booter baked into ROM then you would have to have your PC available and various tools to download into P2. You can ignore all that blank ROM all you like, but you don't have a choice. With TAQOZ you can still do that but you now have a choice to escape into TAQOZ to debug the hardware or just to get something up and running quickly. So what's the problem? What skin is it off your nose? I'm not understanding the resistance to having something instead of nothing.
I'm speaking from where we are now; Boot Loader, Monitor & TAQOZ in 16K ROM.
Personally, I would be fine with it either way; 32K ROM with "everything" or 16K ROM with essentials.
My point was that the items slated for the added 16K (32K total) would MORE LIKELY end up being patched in some way soon after the release of the chip and thus users would be loading new versions of those extensions from SD anyway, rendering the ROM extensions (the added 16K not the original 16K) less useful.
could the rom be expanded to say 32k in the respin?
curious,
Remember also, the die size is package-fixed and finite, so more ROM may mean lower MHz (due to constrained routing room) and/or less RAM.
How much less RAM can you tolerate, to fit in 16k more ROM ?
Chip, please do not sacrifice speed for larger ROM. Also, please keep the SD booter that does not use hub RAM. This would be important in applications that reboot from SD, and do not want hub RAM disturbed.
The hubram-less SD booter is useful for not touching hub RAM, but why keep it in ROM? ROM isn't memory-mapped like it is on the P1, so to load it into a cog you would need to first have it in RAM. You could load it out of ROM into RAM, but unless you're really tight on memory and load it from ROM into a shared buffer that has other uses at other times, you might as well just have it in the RAM image you load at boot and load it from there.
Any non-trivial boot (i.e. not serial, spi, or flash) should be done by TAQOZ. It will give a higher flexibility to ROM consumption ratio than anything else.
All I need is something to boot my program from SD. That can be done with 2K of ROM. I prefer that we don't increase the ROM at the expense of overwriting more RAM, reducing the size of RAM or reducing the speed of the processor. I'm OK with keeping the ROM at 16K, but I don't want to see it increased if it's going to reduce performance in other areas.
All I need is something to boot my program from SD. That can be done with 2K of ROM. I prefer that we don't increase the ROM at the expense of overwriting more RAM, reducing the size of RAM or reducing the speed of the processor. I'm OK with keeping the ROM at 16K, but I don't want to see it increased if it's going to reduce performance in other areas.
Doesn’t ROM already clobber some memory, as it serially loads first?
For what you describe, it would need a 2(+) stage rom fetch, loading what was needed ?
COG & LUT could fit boot & sd, but I think the hw does not load-to-cog?
Yes, ROM does clobber 16K of RAM. Just asking that we don't increase it to clobber more RAM or to impact the size of RAM or the speed of the processor.
But you can reuse that ROM for your own purposes after boot. This is why the P2 doesn't have the font tables that the P1 has: you can just load them in yourself. If something were taken out of the ROM (e.g. the non-TAQOZ SD bootloader when used for reboot purposes), you could still load it in yourself if desired. The ROM should only contain what is needed for booting the system without any external program (e.g. a basic bootloader and one, and only one, SD bootloader, preferably the more flexible one); anything needed after a program is loaded can be supplied by that program, instead of cluttering up the memory layout in programs that don't need it.
well, the ROM get 'loaded' into RAM at startup, nothing prevents a user program to overwrite it. Unlike to the P1 the ROM is soft, so changeable. I am not sure if the software write protect is still in there, I hope it is.
And I do not see any problem or difference if the top 16k or the top 32 k are loaded with something before any user program is loaded.
And in case of some program wants to have the RAM untouched after a reset, well, 4xx k are untouched, the top 16/32 are reloaded.
I do not see the restriction there.
Most P1 programs I looked at use the memory from the bottom and use the top of the RAM as stack or for buffers, so could easily either preserve the ROAM/RAM or overwrite it.
The only problem I have with the current TAQOZ implementation is that it uses the lower RAM area, so if one (like me) would like to have TAQOZ running beside my own software, the loader would need to load in between the TAQOZ used low memory and the TAQOZ used top memory.
At least TAQOZ should provide two fixed memory locations stating the top used memory address and the low memory address used, even after loading some dictionary to add functionality.
Then co-existence would be possible with a TAQOZ aware loader.
TAQOZ never loads into RAM until the user escapes into it from Chip's bootloader, then it copies itself into RAM, sets up shop, and then it's ready to use.
Instead of having two sets of SD routines in ROM, what if the current SD bootloader were replaced with TAQOZ in an new SD bootloader mode? It would look for a special signature in the MBR. If no signature was found, it would mimic the current bootloader. If it found the signature, it would load it and then execute it using the TAQOZ kernel as if it were a compiled TAQOZ word. This function in the MBR would have full access to TAQOZ words: it could mount a FAT filesystem, and then search for a file in it, and boot it, all using built-in TAQOZ facilities, or it could just use TAQOZ's block-layer facilities and read and boot from some non-FAT filesystem that it would have to understand itself. You would be able to compile and write it from TAQOZ. If TAQOZ in bootloader mode fails, it would jump back to Chip's bootloader, which could potentially start TAQOZ again in interactive mode.
TAQOZ never loads into RAM until the user escapes into it from Chip's bootloader, then it copies itself into RAM, sets up shop, and then it's ready to use.
Do you mean additional RAM, like VARs and stack ?
The ROM itself loads once only at RST exit, and all 16K, into RAM from what I understand.
That means TQAOZ binary footprint is sitting in RAM from reset exit, but not yet called.
Instead of having two sets of SD routines in ROM, what if the current SD bootloader were replaced with TAQOZ in an new SD bootloader mode? It would look for a special signature in the MBR. If no signature was found, it would mimic the current bootloader. If it found the signature, it would load it and then execute it using the TAQOZ kernel as if it were a compiled TAQOZ word. This function in the MBR would have full access to TAQOZ words: it could mount a FAT filesystem, and then search for a file in it, and boot it, all using built-in TAQOZ facilities, or it could just use TAQOZ's block-layer facilities and read and boot from some non-FAT filesystem that it would have to understand itself. You would be able to compile and write it from TAQOZ. If TAQOZ in bootloader mode fails, it would jump back to Chip's bootloader, which could potentially start TAQOZ again in interactive mode.
Sounds interesting. A bit like the code on the SD card can become an extension of TAQOZ itself at boot time if the special MBR condition matches. This might then allow all sorts of other device specific features and VGA/USB stuff built for a board type to be developed later and plugged into the initial ROM based TAQOZ itself and not need an entire new OS/application reloaded again. I guess Peter would know if that is doable from his memory model standpoint and also if its in any way desirable to have this sort of extension feature added to the TAQOZ kernel or if it is better to just load up a new full blown version of TAQOZ (which should still be possible anyway).
TAQOZ copies itself from the upper 16KB RAM which has been loaded from the serial ROM. TAQOZ is ~12KB of that. The remaining 4KB shared between Chip's booter, my SD booter, and my Monitor/Debugger.
Chip's booter starts with a test for pull-ups and pull-downs, and then jumps to the respective code. It includes the ability to load and run from SPI FLASH, jump to the SD booter to download and run from code stored in the SD MBR or VOL, or download and run a FAT32 file "_BOOT_P2.BIX" or "_BOOT_P2.BIY", jump to its Serial for auto-baud and downloading capabilities, and the ability to receive serial commands to jump to TAQOZ or the Monitor/Debugger.
TAQOZ needs to be run from the bottom 64KB of HUB RAM due to a limitation of using 16-bit addressing. You cannot call the TAQOZ routines from your own programs. You can add words to TAQOZ either via serial or from FLASH or SD.
In fact, the built P2D2 board Peter sent me has extended words for TAQOZ already programmed into the SPI FLASH. Ctl-R loads these extra words which includes setting the oscillator and running at various clock speeds. This is a great feature!!!
You can replace TAQOZ with a complete new version from either FLASH or SD. This can be loaded automatically from FLASH or SD via pull-ups at boot time, or can be loaded and run using either TAQOZ or the Monitor.
My SD booter has user program callable hub-exec routines to initialise the SD card, search the FAT (FAT32) directory table, and load and optionally run any file, as long as my SD code remains in the top 16KB of HUB RAM. Your program just needs to reserve COG $1C0-$1DF for SD variables.
My Monitor/Debugger has user program callable hub-exec routines to load or display COG/LUT/HUB memory, initialise the serial port, print characters/words/longs in various hex formats, etc. There are also callable send and receive routines for characters and strings. The Monitor can also be "called" from your program. And it can be jumped to from TAQOZ and Chip's booter, and it can jump to TAQOZ too.
So, why have two SD booters (TAQOZ and my SD booter)...
My SD Booter is a basic, slow, proven and simple SD boot program that runs in hub-exec from where it is initially loaded from Serial ROM. For this reason, the SPI control is slower than it could be if it ran from COG RAM. But then it would not be callable, and we would need to be careful not to overwrite it while loading new code. It is "callable" from your programs and uses a minimal footprint in your COG RAM for variables. The actual boot code is quite small of ~1.2KB IIRC.
TAQOZ embeds the routines to access the SD. You cannot call TAQOZ from your own programs, and it resides at the bottom of HUB RAM and IIRC COG and LUT RAM too. So there is no room for your usual code to call it.
TAQOZ...
As I understand it, TAQOZ is a lot of nano routines of a few words (2 bytes). More complex TAQOZ words (commands) builds a table calling a number of these nano routines.
We are extremely fortunate to have TAQOZ in the ROM. From a pristine P2, all we need is the power supply and caps, and a TTL 3V3 serial interface to a terminal/PC, and we can get interactive life from a P2. This is amazing
We no longer need to be tethered to a PC. A P2 only development solution will be absolutely in the P2's future
My SD booter has user program callable hub-exec routines to initialise the SD card, search the FAT (FAT32) directory table, and load and optionally run any file, as long as my SD code remains in the top 16KB of HUB RAM. Your program just needs to reserve COG $1C0-$1DF for SD variables.
Then could you change your SD booter so that, if it fails to find a FAT partition or if it finds a FAT partition but fails to find the file it wants, it loads the MBR and boots from that instead? If your bootloader found a certain signature, it would jump to the MBR, which would have access to your SD routines. If your bootloader found some other signature, it would jump to TAQOZ but tell the TAQOZ kernel to execute the MBR instead of whatever it normally executes on start.
EDIT: Actually, you don't have to support TAQOZ; just supporting running the MBR as machine code is sufficient. The first few instructions of the MBR could start the TAQOZ kernel and instruct it to run the rest of the MBR as TAQOZ bytecode. TAQOZ should be extended to make setting this up easy.
EDIT: Sorry, I can't read. You said your booter already supports running the MBR.
Peter, is there an easy way to have TAQOZ write PASM instructions to the beginning of the MBR to have it run TAQOZ on the rest of the MBR?
Comments
Yes, Ray's SD booter can load an expanded version of TAQOZ from SD. But Ray also has an LMM debugger. There are a lot of more powerful high level TAQOZ functions for debugging but TAQOZ does overwrite the first 64kB. Of course there is a bit of common SD code that could be made compatible but at what cost? Ray's SD boot code is only 1.3k with another 1.4k for his debugger. When we are jammed into a tiny 16kB ROM we will have limitations.
Here's a map of the ROM as it is now:
curious,
Mike
Yes, but ON Semi might charge us more.
Peter, what could you do with another 16KB?
Remember also, the die size is package-fixed and finite, so more ROM may mean lower MHz (due to constrained routing room) and/or less RAM.
How much less RAM can you tolerate, to fit in 16k more ROM ?
Pretty much everything
And from there a full Tachyon can be loaded including the application.
Given the dynamics of advancements in Tachyon code who would not choose to run the full system instead of a fixed ROM-code.
The only benefit I see is that it would be STABLE.
Like the SPIN-Interpreter in P1.
Something you can rely on even years later.
But would it be worth the opportunity cost @JMG points out above?
Would other (compiled) languages besides FORTH even be able to utilize the ROM code like they would use a BIOS?
Solder a chip onto a board, connect power, a monitor, a keyboard, and start programming, all without a PC. That's what I see is useful about it. If we have Ethernet connected then it would also be possible for instance for the P2 to check p2.parallax.com for "extras" that a user/student can select from or install additional firmware onto Flash or SD if selected.
TAQOZ exists on the P2 whereas other languages only exist on the PC and once compiled can use their own routines otherwise we may be squeezing out functionality when it is easy for a PC compiler to include libraries.
Much of it has been done and given that more chips will be available soon means we now have a larger test base in the next couple of months. I don't think Chip needs the new ROM before then.
Chip, please do not sacrifice speed for larger ROM. Also, please keep the SD booter that does not use hub RAM. This would be important in applications that reboot from SD, and do not want hub RAM disturbed.
But I think for an internal boot ROM, less is more.
Don't get me wrong, TAQOZ is awesome and I will use it.
But I rather have a complex VGA command line tool loaded into RAM from an external EEPROM or SD card.
On chip ROMs are set in stone, Complex Dev tools like a VGA command line editor with file system will be changing over time with user updates and improvements.
I mean there is something awesome about the idea of a P2 booting up to something on it's own with almost no external parts, but external eeproms are pretty cheap these days.
Unless I'm missing or not understanding something?
Either way, CAn't wait to try out TAQOZ when the early test ICs are up for grabs.
Thanks Peter. : ]
Don't worry, I agree too but Chip is simply asking. A respin is a respin and now we have HDMI so things are a bit different already. If I had the extra ROM though I'd sure put it to good use anyway.
when you were doing your VGA demo above, were all of those words part of TAQOZ, or were you loading additional words off an SD? (my apologies if my terminology is incorrect.)
(edit...)
That is my concern as well. Does the ROM need "gamma", for instance?
In other words, if they were baked into a ROM, it would be COMMON for people to be loading Extensions/Patches to them from an SD card anyway, so why bake them in?!?
Just stick to 16K for ROM which has the foundational stuff that will likely NOT need patches over time and load all of the extra stuff from the SD card.
Users will still get all the advantages of having a WHOLE SYSTEM. It will just need to be loaded from a card.
I think this will keep things much more flexible and clean in the long term.
j
If there was nothing but Chip's booter baked into ROM then you would have to have your PC available and various tools to download into P2. You can ignore all that blank ROM all you like, but you don't have a choice. With TAQOZ you can still do that but you now have a choice to escape into TAQOZ to debug the hardware or just to get something up and running quickly. So what's the problem? What skin is it off your nose? I'm not understanding the resistance to having something instead of nothing.
Personally, I would be fine with it either way; 32K ROM with "everything" or 16K ROM with essentials.
My point was that the items slated for the added 16K (32K total) would MORE LIKELY end up being patched in some way soon after the release of the chip and thus users would be loading new versions of those extensions from SD anyway, rendering the ROM extensions (the added 16K not the original 16K) less useful.
j
The hubram-less SD booter is useful for not touching hub RAM, but why keep it in ROM? ROM isn't memory-mapped like it is on the P1, so to load it into a cog you would need to first have it in RAM. You could load it out of ROM into RAM, but unless you're really tight on memory and load it from ROM into a shared buffer that has other uses at other times, you might as well just have it in the RAM image you load at boot and load it from there.
Any non-trivial boot (i.e. not serial, spi, or flash) should be done by TAQOZ. It will give a higher flexibility to ROM consumption ratio than anything else.
Doesn’t ROM already clobber some memory, as it serially loads first?
For what you describe, it would need a 2(+) stage rom fetch, loading what was needed ?
COG & LUT could fit boot & sd, but I think the hw does not load-to-cog?
And I do not see any problem or difference if the top 16k or the top 32 k are loaded with something before any user program is loaded.
And in case of some program wants to have the RAM untouched after a reset, well, 4xx k are untouched, the top 16/32 are reloaded.
I do not see the restriction there.
Most P1 programs I looked at use the memory from the bottom and use the top of the RAM as stack or for buffers, so could easily either preserve the ROAM/RAM or overwrite it.
The only problem I have with the current TAQOZ implementation is that it uses the lower RAM area, so if one (like me) would like to have TAQOZ running beside my own software, the loader would need to load in between the TAQOZ used low memory and the TAQOZ used top memory.
At least TAQOZ should provide two fixed memory locations stating the top used memory address and the low memory address used, even after loading some dictionary to add functionality.
Then co-existence would be possible with a TAQOZ aware loader.
Mike
Do you mean additional RAM, like VARs and stack ?
The ROM itself loads once only at RST exit, and all 16K, into RAM from what I understand.
That means TQAOZ binary footprint is sitting in RAM from reset exit, but not yet called.
Sounds interesting. A bit like the code on the SD card can become an extension of TAQOZ itself at boot time if the special MBR condition matches. This might then allow all sorts of other device specific features and VGA/USB stuff built for a board type to be developed later and plugged into the initial ROM based TAQOZ itself and not need an entire new OS/application reloaded again. I guess Peter would know if that is doable from his memory model standpoint and also if its in any way desirable to have this sort of extension feature added to the TAQOZ kernel or if it is better to just load up a new full blown version of TAQOZ (which should still be possible anyway).
TAQOZ copies itself from the upper 16KB RAM which has been loaded from the serial ROM. TAQOZ is ~12KB of that. The remaining 4KB shared between Chip's booter, my SD booter, and my Monitor/Debugger.
Chip's booter starts with a test for pull-ups and pull-downs, and then jumps to the respective code. It includes the ability to load and run from SPI FLASH, jump to the SD booter to download and run from code stored in the SD MBR or VOL, or download and run a FAT32 file "_BOOT_P2.BIX" or "_BOOT_P2.BIY", jump to its Serial for auto-baud and downloading capabilities, and the ability to receive serial commands to jump to TAQOZ or the Monitor/Debugger.
TAQOZ needs to be run from the bottom 64KB of HUB RAM due to a limitation of using 16-bit addressing. You cannot call the TAQOZ routines from your own programs. You can add words to TAQOZ either via serial or from FLASH or SD.
In fact, the built P2D2 board Peter sent me has extended words for TAQOZ already programmed into the SPI FLASH. Ctl-R loads these extra words which includes setting the oscillator and running at various clock speeds. This is a great feature!!!
You can replace TAQOZ with a complete new version from either FLASH or SD. This can be loaded automatically from FLASH or SD via pull-ups at boot time, or can be loaded and run using either TAQOZ or the Monitor.
My SD booter has user program callable hub-exec routines to initialise the SD card, search the FAT (FAT32) directory table, and load and optionally run any file, as long as my SD code remains in the top 16KB of HUB RAM. Your program just needs to reserve COG $1C0-$1DF for SD variables.
My Monitor/Debugger has user program callable hub-exec routines to load or display COG/LUT/HUB memory, initialise the serial port, print characters/words/longs in various hex formats, etc. There are also callable send and receive routines for characters and strings. The Monitor can also be "called" from your program. And it can be jumped to from TAQOZ and Chip's booter, and it can jump to TAQOZ too.
So, why have two SD booters (TAQOZ and my SD booter)...
My SD Booter is a basic, slow, proven and simple SD boot program that runs in hub-exec from where it is initially loaded from Serial ROM. For this reason, the SPI control is slower than it could be if it ran from COG RAM. But then it would not be callable, and we would need to be careful not to overwrite it while loading new code. It is "callable" from your programs and uses a minimal footprint in your COG RAM for variables. The actual boot code is quite small of ~1.2KB IIRC.
TAQOZ embeds the routines to access the SD. You cannot call TAQOZ from your own programs, and it resides at the bottom of HUB RAM and IIRC COG and LUT RAM too. So there is no room for your usual code to call it.
TAQOZ...
As I understand it, TAQOZ is a lot of nano routines of a few words (2 bytes). More complex TAQOZ words (commands) builds a table calling a number of these nano routines.
We are extremely fortunate to have TAQOZ in the ROM. From a pristine P2, all we need is the power supply and caps, and a TTL 3V3 serial interface to a terminal/PC, and we can get interactive life from a P2. This is amazing
We no longer need to be tethered to a PC. A P2 only development solution will be absolutely in the P2's future
Then could you change your SD booter so that, if it fails to find a FAT partition or if it finds a FAT partition but fails to find the file it wants, it loads the MBR and boots from that instead? If your bootloader found a certain signature, it would jump to the MBR, which would have access to your SD routines. If your bootloader found some other signature, it would jump to TAQOZ but tell the TAQOZ kernel to execute the MBR instead of whatever it normally executes on start.
EDIT: Actually, you don't have to support TAQOZ; just supporting running the MBR as machine code is sufficient. The first few instructions of the MBR could start the TAQOZ kernel and instruct it to run the rest of the MBR as TAQOZ bytecode. TAQOZ should be extended to make setting this up easy.
EDIT: Sorry, I can't read. You said your booter already supports running the MBR.
Peter, is there an easy way to have TAQOZ write PASM instructions to the beginning of the MBR to have it run TAQOZ on the rest of the MBR?