Bootloader question
Dr_Acula
Posts: 5,484
Hopefully this question has a quick answer. I am looking for a bootloader to put all the Z80 emulations on one sd card. Lots of parts of the problem are already solved - vga display, keyboard, small LCD 20x4 display mirroring the VGA, sd card (fat 16 and fat32). But here is my specific problem. I want to be able to load up a new binary from sd card into ram without first putting it into eeprom.
The steps as I see it:
Program in eeprom starts up the vga, keyboard and sd card drivers with the appropriate objects and loads them into cogs
Program presents a menu to the user, with simple arrow key control
User selects a 32k binary to load.
Next, a program, running either in spin or in a cog (I'm not sure where is best) takes 32k of binary data off a binary file on an sd card and places it into hub ram. I think that is not particularly difficult, though obviously it can't overwrite its own program, so the program doing this probably has to be in its own cog. And maybe it needs to explicitly shut down all other cogs, possibly including the spin interpreter cog as well.
Here is the bit that I don't quite understand. Once that 32k of data has been loaded into hub ram, is it possible for a cog to start running that program, as if the data had been loaded off an eeprom?
I don't really understand the exact instruction to do this, but I think it might be COGINIT rather than COGNEW. But is that running in Spin or PASM?
I feel this probably ought to be possible as it is not dissimilar to whatever program moves the data from the eeprom into ram when you push the reset button and then jumps to location 00 in the hub ram.
Is this possible, and if so, has anyone written such a bootloader?
I'd really appreciate a reply as I've thought this through a lot over the last few weeks and I think it all comes down to a single instruction to do a clean jump to location 00 of hub ram after filling that ram with an eeprom binary.
Many thanks in advance.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
The steps as I see it:
Program in eeprom starts up the vga, keyboard and sd card drivers with the appropriate objects and loads them into cogs
Program presents a menu to the user, with simple arrow key control
User selects a 32k binary to load.
Next, a program, running either in spin or in a cog (I'm not sure where is best) takes 32k of binary data off a binary file on an sd card and places it into hub ram. I think that is not particularly difficult, though obviously it can't overwrite its own program, so the program doing this probably has to be in its own cog. And maybe it needs to explicitly shut down all other cogs, possibly including the spin interpreter cog as well.
Here is the bit that I don't quite understand. Once that 32k of data has been loaded into hub ram, is it possible for a cog to start running that program, as if the data had been loaded off an eeprom?
I don't really understand the exact instruction to do this, but I think it might be COGINIT rather than COGNEW. But is that running in Spin or PASM?
I feel this probably ought to be possible as it is not dissimilar to whatever program moves the data from the eeprom into ram when you push the reset button and then jumps to location 00 in the hub ram.
Is this possible, and if so, has anyone written such a bootloader?
I'd really appreciate a reply as I've thought this through a lot over the last few weeks and I think it all comes down to a single instruction to do a clean jump to location 00 of hub ram after filling that ram with an eeprom binary.
Many thanks in advance.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Comments
For that matter, you could just use the VGA version of FemtoBasic with an AUTOEXEC.BAS file on the SD card that would present a menu and start the selected emulator (using the SPIN "<file>" statement). Parallax used this scheme for a kiosk a few years ago.
Post Edited (Mike Green) : 6/2/2010 3:12:45 PM GMT
I ended up coming at this in a roundabout way. While searching for femtobasic in the obex I found this obex.parallax.com/objects/557/
which takes code from femtobasic.
The relevant code is
pri bootSDCard(addr,count) | t '' Boot from an SD card if count < 16 ' Must load at least 16 bytes return true repeat t from 0 to 7 ' Stop all COGs except this one and if (t <> cogid) and (t <> (cog-1)) ' the one with the I2C/SPI driver cogstop(t) t := ioSpiBoot | ioStopLdr | cogid ' Tell the SD card driver to load long[noparse][[/noparse]control] := count << 16 ' into HUB RAM after stopping long[noparse][[/noparse]control][noparse][[/noparse]0] := (t << 24) | (addr & $FFFFFF) ' this calling cog repeat while long[noparse][[/noparse]control][noparse][[/noparse]0] & ioTestRdy ' Wait for this to finish return (long[noparse][[/noparse]control][noparse][[/noparse]0] & ioTestErr) <> 0 ' Return any error codewhich I subsequently found in femtobasic as well.
So I converted femtobasic into a binary file, put it on an sd card, renamed it "autoexec.bin" and then programmed the eeprom with William Steele's bootloader.
Some minor changes to the pins
{ spiDO = (Hydra & 16) | (Demo & 0) | (Proto & 8) spiClk = (Hydra & 17) | (Demo & 1) | (Proto & 9) spiDI = (Hydra & 18) | (Demo & 2) | (Proto & 10) spiCS = (Hydra & 19) | (Demo & 3) | (Proto & 11) } spiDO = 12 spiClk = 13 spiDI = 14 spiCS = 15(as an aside, BST simplifies that sort of complex and or logic equation into a simple #ifdef)
With no sd card, nothing happens on a reset. But - pop in the sd card... and up comes femtobasic. This is a delight to see. It is the missing piece of a jigsaw that I needed.
It is fast too. Equally as fast as loading off the eeprom.
There are a few other pieces to pull together. A way of finding all files on the sd card with a particular extension and putting them in a list on the screen. I think that exists because pullmoll is doing this with the Color Genie emulation. I'm sure I've seen menu systems in other programs as well. And I also would like to do this with fat32 rather than fat16, so I might see what is out there with fat32 drivers.
The big advantage of doing it this way is the eeprom won't wear out, and also, reading from sd card to ram is much faster (1 second?) than reading from sd card to eeprom to ram (?17 seconds).
Now I can start to think about putting the Nascom, Color Genie, MPM and Spectrum into binary files, and have a menu where you select which emulation you want to run, without having to reprogram the eeprom for each emulation. Dump all the associated .rom files onto the sd card, and it ought to be possible to have one little sd card with many computers on it.
Thanks ++ to Mike!
addit: writing the menu in femtobasic sounds a nifty idea.
addit addit: I just read your addit. Yes, there is a command in femtobasic
SPIN "<file>"
This causes a Spin program to be loaded into the Propeller's main memory
from a specified file on an attached SD card.
D'oh. Even better.
Hmm - just need to get the femtobasic "FILES" command to only print out files with a certain extension. Actually, it probably doesn't even need to do that. Just have a menu item "1 NASCOM" and if NASCOM.BIN does not exist on the sd card, then tell the user how to create it and copy it to the sd card.
Ok, well that is going to be an incredibly simple Femtobasic program. Print 4 lines, get an input, print an error if necessary, or run the binary.
Just need to look at fat32 now...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 6/3/2010 12:59:25 AM GMT
The eeprom has code that ONLY knows about the SD card, nothing else. It is based on the femto code so is FAT16 only although you could change the driver.
From memory this is how it works (all code is posted on the RamBlade thread). It reads the SD card and locates and runs a file called BOOTPROP.BIN which then does the smarts to see if there is an AUTOEXEC.BAT file and if so will run that program if found, otherwise it continues. BOOTPROP.BIN is actually PropCmd with some mods. It has a "?" command to show its commands and accepts "RUN" as well as "SPIN" as I think RUN is more meaningful. The latest version is at the end of the RamBlade thread (with ? and RUN). It would be easy to list the executables by forcing a "DIR *.BIN" in the arguments. Then the user can do a RUN xxx.
BTW: This would keep all our emualtions similar and when I get SphinxOS running how I want, we can all switch easily with only an SD card file change (no eeprom change). On my RamBlade, the eeprom is disabled from writing by default (it has a link to enable it). SphinxOS needs to be able to do FAT32 also, so that will resolve that problem for you. IIRC I think PropCmd may in fact handle FAT32 ???
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Indeed, I think we might be working towards the same thing. Switch everything with sd card changes. The eeprom just contains the minimum code and as a result, should not need to change very often, if at all. (of course, you will still use eeprom F11 or ram F10 for debugging a particular emulation).
So if you want the user to be able to select different things with keypresses 1,2,3 etc, have a program on sd card that does that (I was thinking femtobasic, but any language ought to work, even some sort of replication of dos batch files). And if you wanted it to bypass user input after no input for a while and run one particular program, put a different program on the sd card.
Perhaps then we can start to think about merging all these projects into one? eg one common set of files and you just dump the lot onto an sd card. Even files that might not run on that particular hardware, eg ramblade on a dracblade, but put them all there anyway. Give the user a link to a single zip file with all the emulations, rather than trying to find discussion threads on the forum that are disappearing into the mists of time...
Hmm, fat32. pullmoll has fat32 code on the qz80. I think kye wrote a driver as well. I haven't had a chance to test kye's code. I do know that pullmolls fat32 code managed to read some 512mb cards that simply would not read with fat16 code, even when reformatted with fat16.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
However, the eeprom should never require changing and that is the whole point. It only knows about the SD pins, nothing else. SO the SD card binaries control this.
Yes, the idea is to load all the binaries. I do that for RamBlade and TriBlade now and they have different binaries.
Yes, we may need to change the eeprom once if it cannot handle FAT32 - I just need to check and of course it is on the other laptop and I am working with one power supply :-(
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Yep, my fatfs.spin handles FAT32 as well as FAT16 (and in theory even FAT12). It is all read-only and requires the spi_warp.spin that hairymnstr wrote and which I extended to also support the RamBlade and TriBlade XMM. fatfs.spin does not have a boot loading function, though. The most recent version should run on a non-XMM Propeller - if none of DracBladeProp, TriBladeProp or RamBladeProp is #defined - and does have fopen/fclose/fread/fgetc functions, so adding some code to boot a file shouldn't be too hard.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
Post Edited (pullmoll) : 6/3/2010 2:32:09 AM GMT
Now I can see many ways of doing this, ranging from a tiny femtobasic program to sphinx to things in between. I think it might be a matter of merging femtobasic with pullmoll/hairymnstr's spi_warp. This might only be 20-30 lines of femtobasic code.
The boot program (eg femtobasic) does not need external memory and would run on any propeller board. It could then run some of the complex recent emulations that need external memory, but perhaps we could add to the menu heater's original zicog that ran without external memory. So already there might be 6 or 7 items in the menu to select. I'm sure other things will end up being added to the menu, femto basic itself for instance. And sphinx so you can do more fancy things with the files on the sd card.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
If you forgo the menu use for typing 1..7 and instead use the "RUN ZICOGXYZ" to run zicogxyz.bin then we can just force PropCmd or SphinxOS to display either
a) A list of *.BIN files by forcing a DIR *.BIN and returning to the prompt
-or-
b) Display a file by forcing TYPE MENU.TXT and returning to the prompt
... Remember, everyone will have to run some kind of commands from the emulation, be it CPM or Apple or Commodore DOS or whatever, so "RUN xyz" should not be a problem. KISS !
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
I did not want the eeprom program to change so only the sd card is used and it runs BOOTPROP.BIN or the program called·by AUTOEXEC.BAT.
On reflection, it would be better to RUN the binary called by BOOTPROP.BAT parameter from the eeprom.·I have·to rename PropCmd.bin to BootProp.bin and then you lose what program is really PROPBOOT.BIN.
I think we may now want to use AUTOEXEC.BAT for something else later. So, why not change to...
EEPROM reads the SD card and locates the file "BOOTPROP.BAT". If not found, stop. Otherwise, read the first parameter and "RUN" it with [noparse][[/noparse].BIN] added, if required. My intention is BOOTPROP.BAT should run "SPHINXOS.BIN" but I can run "PROPCMD.BIN" for the time being. You could run FemtoBasic or whatever.
Here is my code. You will only require to change the SD pins at the top, change "AUTOEXEC.BAT" --> "BOOTPROP.BAT". You can leave "BOOTPROP.BIN" there if you like (it gives us another option)·and recompile.
Note: FAT32 is not supported so the femto code will need to be modified to support it if you require FAT32.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Post Edited (Cluso99) : 6/3/2010 7:48:45 AM GMT
Take a look at Mike Green's link and then download the package and read the .pdf instructions. You only need to skim read to see the useful commands for printing out a list of files on an sd card, loading files off the sd card etc. I think it has all the building blocks.
I'm starting to think femtobasic is a bit unique. It does not require a PC to do any pre compilation. Makes you think about "femtoSpin"...
Anyway, all I think that needs adding is fat32, and I'm hoping most/all the commands end up the same. The eeprom program need never change (unless fat32 is replaced by fat64 or something). The eeprom program also ends up very small - just the bare basics for vga, keyboard and sd card.
The thing about femtobasic is that I might write a simple program that prints out '1 - nascom', '2 CP/M' and then you or anyone else could come along and put a more complex program on the sd card that reads off '*.bin' from the sd card and prints that a list. It can grow incrementally, but the very simple version hopefully can be working quickly.
Just a thought for Juergen - you could have two files for the Color Genie - one compiled for TV and one compiled for VGA. Load either.
Hmm - you also might need a femtobasic compilation that can do both TV and VGA so you can actually select something. I guess that might need to be some sort of keyword in femtobasic, or a data file that is read or something. I'll need to think about that.
Now I just need to get out of these 15 hour workdays...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 6/3/2010 8:22:33 AM GMT
The PropCmd I posted above has "?" commands (lists commands available like DIR, TYPE, etc) and "RUN" which is the same as "SPIN". So, just loadup the parameters for "DIR *.BIN" and run the DIR command from within PropCmd and you will get a list of programs that can be run. Or, loadup the parameters for "TYPE MENU.TXT" and run the TYPE command from within PropCmd and you will get a print of the file "MENU.TXT".
The only issue is that we have to add support for FAT32. Later, we have to get to a single SD pasm driver also. Currently I am using spisdfemto.spin, fsrw26, and a version in Sphinx by mpark. Pullmoll has one also as does Kye.
If we can get to SphinxOS then we can loadup TV or VGA into the cog(s) and then the emulations only need to know where the screen buffer is located. Likewise, SphinxOS will also loadup the Keyboard driver.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Where I am totally stuck is the simple concept of putting fat32 into femtobasic. I thought this would be easy, but the relevant spin programs are nested at least three deep and so the simple task of using control F to trace through program execution becomes all but impossible.
I know it is a matter of merging pullmolls code and femto basic. I think sdspiFemto matches with DracBlade_spi_warp and I think fsrwFemto matches with fatfs and I think io.spin matches with femtobasic.spin and I think cpm.spin doesn't match with anything. Just matching each of these routines took half an hour to work out. Anyway, I think it is beyond me at nearly midnight with caffeine levels fading.
Attached is a version of femto basic that boots off a fat16 file on the dracblade. This has the correct pins. There are large amounts of code not needed in pullmolls code, eg the memory drivers. I think it is a matter of start, mount, read files but matching up all the femtobasic commands is going to take some time. Help here would be most appreciated!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
I'll be releasing my file system driver tommorrow again, however, this time pretty much everything is working perfectly and at fast speeds (my code runs as fast as the old spiqasm in FSRW).
I have the booting functionality working perfectly and I've included a demo that can act as a stand alone file system acess command line. It can boot the propeller chip from any eeprom or bin file in any directory on the SD card.
I also have FAT32 and FAT16 support working.
The demo program itself will blow all the current bootloaders on line out of the water in functionality. You will really like it.
...So, wait until tommorrow.
(The demo can also play WAV files and record them
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
Sounds amazing.. I guess we'll have to wait until tomorrow..
Patience is a virtue.. And I have to say I am not that virtuous!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I always have someone watching my back.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
The attraction of Sphinx is the prop compiling and the commands DIR, TYPE, etc are actually seperate Sphinx aware binaries so they use whatever input and output driver is loaded in the cogs so no recompilation is required.
Drac:
My eeprom loader is the first binary. It then reads AUTOEXEC.BAT (here I am suggesting we can change to BOOTPROP.BAT) and runs that binary if found (so that is 2 levels). If either is not found, it runs BOOTPROP.BIN (also 2 levels). With the changes I suggested (AUTOEXEC.BAT or BOOTPROP.BAT point to PROPCMD.BIN) it is still 2 levels. PROPCMD is modified to display a menu, so it is still 2 levels.
AND, we NEVER have to change the EEPROM which means that a PropPlug is NOT required. This method also allows us to reprogram the EEPROM via the SD card by running a binary.
Obviously this EEPROM Boot binary needs to be FAT32 aware, but it should be minimal code. I am really pushing this objective so we can all use the same binary with only the SD pins changed. Note for me, the DO must be forced to be released by the SD card, and I think this is wise anyway.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
I guess we now have two programs that need to be made fat32 aware. The initial bootloader in eeprom and femtobasic. Mind you, the initial bootloader could be a minimalist version of femtobasic code.
The fat32 code looks complicated. Input from our resident sd card experts is very much appreciated.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
This would mean that anyone with an SD card could use this EEPROM boot code with only the SD pin changes. Then we have a standard boot code
So, can we have some consensus...
What do we call the SD File that will contain the name of the binary to be run after the EEPROM Boot code ?
AUTOEXEC.BAT - I now think this is a bad idea as there may be some emulations that may want to use this
BOOTPROP.BAT - may be a better idea - any other suggestions???
If this is not found (either the xxx.BAT file or the xxx.BIN file it points to), what do we execute ?
BOOTPROP.BIN - goes with BOOTPROP.BAT
or STOP ?
If this is not found (BOOTPROP.BIN), then STOP (as there is nothing we can do). This allows for a corrupted BOOTPROP.BAT.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
BOOTPROP.BAT
which runs whatever program is in that small text file (only one line I imagine eg MYPROG.BIN)
and if not found
run
BOOTPROP.BIN
and then halt if that isn't found.
Ultra simple to explain, and the code will be very simple to write as no display or keyboard drivers. Just a list of 4 pins for the sd card and that nifty bit of code from femtobasic that moves bytes into hub ram, shuts down cogs and starts afresh.
Hopefully Kye will be online soon. Or pullmoll. Or anyone else who has some fat32 drivers [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
I did upload the new version to the Object Exchange.
Kye has a fantastic new fat32 driver - see his active thread. It is almost a mini operating system. Next step for me is to merge the femto binary loader with kye's code and see if it can run a binary. Then look at merging femtobasic more formally with kye's code. Then strip it back to basics for Cluso's loader.
Hopefully this becomes a 'copy and paste' exercise - I think all the building blocks are there now.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
This bootloader question/thread is now solved thanks to some Fat32 code written by Kye. Discussed in more detail on this thread http://forums.parallax.com/showthread.php?p=912403 on page 2.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller