Just JMP to it in hub (hubexec). Would like to swap CSn with CLK and test for pull-up on CSn (now P60). Flash remains same as previously. Just check for its CSn pull-up.
Don't forget we want to look for Flash reply on both P58 and P59 and then use that pin. This allows support for both 3pin and 4pin flash connections.
Peter suggested we also check for pull-up on P59 and if present Do not support serial download. Allows a designer to better lockdown the hardware.
We also really think that the serial should initially proceed in parallel with flash/SD on a separate cog.
I always reformat my SDXC cards to FAT32 as there is no good reason to use M$ exFAT other than perhaps >4GB files. My Linux systems use ext4 that can handle all the good stuff and journaling but FAT32 works on all systems.
Yes, I just wanted to verify that the SDXC works, and that it also did at least work in exfat with MBR. The VOL sector is used so we cannot put code there.
I have been reading about exFAT. If I get time I will search the dir table for a file name.
This patent is bogus. They are claiming a first using hashing to get a pointer to the directory entry. While I guess they might get a patent on the physical hash, providing it's never been used before. But using a hash to lookup entries were done on minis and mainframes in the late 70's. I used them in 1981. Somewhere I have microfiche with my code listings.
Please do. Turns out Atari, with the ST series of 16 bit machines, implemented Win 95 style long file name hashing before Microsoft did. That helped free FAT for general use. Info from both USENET and a recovered Atari mainframe in use today for historical and nostalgic reasons provided the prior art.
exFAT limits the load ability to the MBR sector 0.
So the following is now possible...
1. MBR sector 0: Offset $17C = "Prop" then load and JMP $080
2. "ProP" then $174 = sector to load, $178 = bytes to load, JMP $000
If FAT32 continue (exFAT = stop)
3. VOL sector x: Offset $17C = "Prop" then load and JMP $080
4. "ProP" then $174 = sector to load, $178 = bytes to load, JMP $000
5. Search DIR = "_BOOT_P2.BIX" and if found, load file data sector(s) for file size bytes, JMP $000
5. "_BOOT_P2.BIY" and if found, load file data sector(s) for file size bytes, JMP $000
else stop.
The deadline has blown out a little for other reasons but I have managed to make TAQOZ compile to upper memory and copy to the first 64kB and run without any fudging. I overwrote the boot ROM for this test but now I want to integrate Chip's boot loader with TAQOZ and try it out using an escape key to go to TAQOZ. Then Cluso and I can merge and check everything running together. Finally, we will submit the combined source code to Chip as one file as he may make some other changes.
The deadline has blown out a little for other reasons but I have managed to make TAQOZ compile to upper memory and copy to the first 64kB and run without any fudging. I overwrote the boot ROM for this test but now I want to integrate Chip's boot loader with TAQOZ and try it out using an escape key to go to TAQOZ. Then Cluso and I can merge and check everything running together. Finally, we will submit the combined source code to Chip as one file as he may make some other changes.
Good news! Thanks for the update. I'm glad you ended up getting a bit more time.
I have posted the SD code and Monitor code so it can be downloaded and tested. If there are any issues they can be fixed without requiring new FPGA code.
Have the SD boot code and TAQOZ been finalized yet? Will a new FPGA image containing the new ROM code be available so that we can test it?
I'm jumping back into the boot seat now as I have been testing the combination SD and Flash on the same pins, and also moving that around to other pins, just in case. When I'm done hopefully today then I'm hoping Chip will be able to compile an FPGA with this ROM as it also allows me to override the mask ROM by having a pullup on P58 so that the very first thing the mask ROM does is read in 16kB of Flash from $FC000 to $FC000 and run that as if it were the mask ROM. So that will allow me to do power-up and hard reset boot testing and if necessary make changes to the "ROM" for final inclusion into silicon. Cluso and I are now cloud sharing the ROM source using a Telegraph plug-in for the the Atom editor. What he and I type are instant and visible.
Right now I'm just going to add a couple of extras into TAQOZ to allow backup to Flash as well as loading binary or source from areas in Flash, just as a little extra productivity aid since we are only talking about three hundred bytes for this part.
I know the original deadline of April 27 was pushed out a bit, but it's almost 2 weeks later. Is there a hard deadline for finalizing the ROM? I fear that this could go on for weeks or months, and then after the chip is submitted it will have to be pulled because of some crucial change required in the ROM. I would hate to think that the P2 gets delayed just so it can include Forth in the ROM.
I know the original deadline of April 27 was pushed out a bit, but it's almost 2 weeks later. Is there a hard deadline for finalizing the ROM? I fear that this could go on for weeks or months, and then after the chip is submitted it will have to be pulled because of some crucial change required in the ROM. I would hate to think that the P2 gets delayed just so it can include Forth in the ROM.
That's overreacting and then being rather simplistic about where the delay is since the emphasis in the boot ROM has been on the booting and sequencing part, whereas TAQOZ/Tachyon has always been working, any tweaks aside. Remember what I was saying about testing the power-up and hard reset?
To be perfectly honest, there has been way too little testing!!!
The problems are not likely to be in the boot. The only changes to the existing boot rom is to test the pullups to jump to extra code, and a similar change to detect characters to jump to that code too.
There has been little instruction testing done after the last major changes, with the exception mainly being Chip and Brian (ozpropdev). This is my concern.
Having said that, I don't think anyone up until now, other than Chip, has actually tested the FLASH boot. Peter is doing that right now.
Our test ROM of a little over a week ago failed miserably. Fortunately we can still download code.
I have been testing SD. But no-one has tested my recent versions of SD code!
Now, here's the thing...
Serial and Flash Booting is self-contained, and copies some parts to cog and some to lut, and runs from there after performing some housekeeping.
SD is self-contained in Hub ROM and runs in hubexec mode. Some parts may be callable from user programs.
The Monitor/Debugger is self-contained, callable by user programs, and runs in hubexec mode.
TAQOZ is self-contained, and copies itself to lower hub from Hub ROM, and runs from there.
If any of these end up with bugs, then they can be ignored without upsetting the other blocks. And it's highly likely that we can apply a simple patch, albeit requiring downloading after each reset.
The problems are not likely to be in the boot. The only changes to the existing boot rom is to test the pullups to jump to extra code, and a similar change to detect characters to jump to that code too.
Did the Tx turn around delay get reduced from the rather glacial 1ms now, to a suggested 1 char time ?
That allows faster serial boot times, especially following a Watchdog reset.
It's important that a WDOG/SW reset especially, is able to get to a defined-pins state, as fast as possible.
Comments
Just JMP to it in hub (hubexec). Would like to swap CSn with CLK and test for pull-up on CSn (now P60). Flash remains same as previously. Just check for its CSn pull-up.
Don't forget we want to look for Flash reply on both P58 and P59 and then use that pin. This allows support for both 3pin and 4pin flash connections.
Peter suggested we also check for pull-up on P59 and if present Do not support serial download. Allows a designer to better lockdown the hardware.
We also really think that the serial should initially proceed in parallel with flash/SD on a separate cog.
The only boot possible is MBR (sector 0), which works fine, as the VOL sector contains required information that must not be overwritten.
That is very good news, cool. Good decision to allow booting from the MBR...
Mike
I have been reading about exFAT. If I get time I will search the dir table for a file name.
This patent is bogus. They are claiming a first using hashing to get a pointer to the directory entry. While I guess they might get a patent on the physical hash, providing it's never been used before. But using a hash to lookup entries were done on minis and mainframes in the late 70's. I used them in 1981. Somewhere I have microfiche with my code listings.
Ask Patents. https://patents.stackexchange.com
..and some info about it here:
https://www.forbes.com/sites/timworstall/2013/07/23/crowdsourcing-the-fight-against-bad-software-patents/#685eca626975
...and more detailed info here:
http://www.fedbar.org/Resources_1/Federal-Lawyer-Magazine/2014/December/Features/Crowdsourced-Prior-Art.aspx?FT=.pdf
Jason
exFAT limits the load ability to the MBR sector 0.
So the following is now possible...
I have posted the SD code and Monitor code so it can be downloaded and tested. If there are any issues they can be fixed without requiring new FPGA code.
Peters still working on TAQOZ.
I'm jumping back into the boot seat now as I have been testing the combination SD and Flash on the same pins, and also moving that around to other pins, just in case. When I'm done hopefully today then I'm hoping Chip will be able to compile an FPGA with this ROM as it also allows me to override the mask ROM by having a pullup on P58 so that the very first thing the mask ROM does is read in 16kB of Flash from $FC000 to $FC000 and run that as if it were the mask ROM. So that will allow me to do power-up and hard reset boot testing and if necessary make changes to the "ROM" for final inclusion into silicon. Cluso and I are now cloud sharing the ROM source using a Telegraph plug-in for the the Atom editor. What he and I type are instant and visible.
Right now I'm just going to add a couple of extras into TAQOZ to allow backup to Flash as well as loading binary or source from areas in Flash, just as a little extra productivity aid since we are only talking about three hundred bytes for this part.
That's overreacting and then being rather simplistic about where the delay is since the emphasis in the boot ROM has been on the booting and sequencing part, whereas TAQOZ/Tachyon has always been working, any tweaks aside. Remember what I was saying about testing the power-up and hard reset?
The problems are not likely to be in the boot. The only changes to the existing boot rom is to test the pullups to jump to extra code, and a similar change to detect characters to jump to that code too.
There has been little instruction testing done after the last major changes, with the exception mainly being Chip and Brian (ozpropdev). This is my concern.
Having said that, I don't think anyone up until now, other than Chip, has actually tested the FLASH boot. Peter is doing that right now.
Our test ROM of a little over a week ago failed miserably. Fortunately we can still download code.
I have been testing SD. But no-one has tested my recent versions of SD code!
Now, here's the thing...
Serial and Flash Booting is self-contained, and copies some parts to cog and some to lut, and runs from there after performing some housekeeping.
SD is self-contained in Hub ROM and runs in hubexec mode. Some parts may be callable from user programs.
The Monitor/Debugger is self-contained, callable by user programs, and runs in hubexec mode.
TAQOZ is self-contained, and copies itself to lower hub from Hub ROM, and runs from there.
If any of these end up with bugs, then they can be ignored without upsetting the other blocks. And it's highly likely that we can apply a simple patch, albeit requiring downloading after each reset.
Did the Tx turn around delay get reduced from the rather glacial 1ms now, to a suggested 1 char time ?
That allows faster serial boot times, especially following a Watchdog reset.
It's important that a WDOG/SW reset especially, is able to get to a defined-pins state, as fast as possible.
Maybe exFAT is one of them?!?
https://www.zdnet.com/article/microsoft-open-sources-its-entire-patent-portfolio/