I tried the SDformat program (for mac) as someone suggested, then ran Clock Loop's modified code and I still get garbage. I don't know what's going on but it seems to not like this card.
I tried the SDformat program (for mac) as someone suggested, then ran Clock Loop's modified code and I still get garbage. I don't know what's going on but it seems to not like this card.
p
Something in the program is still messed up because I also get garbage at first for about 4 seconds, and then it works.
I tried this modified code with my troublesome Panasonic card with no change in result. I also tried it with the Lexar card above and found no difference.
Clock Loop,
I too had modified the spin code, first because of the pin assignments, but also
1) my SD card power is switched by p12 and
2) I was getting garbage data.
I too found that there was a weird interaction between the serial port and the SD card test, so I ended up moving the serial port initialization to after the test. Here is how I modified Cluso's spin code, only the first PUB. I'm using BST/Mac, so I left off the long startup delay.
[SIZE=1][FONT=courier new]pub Main : i | tm
'
' This Spin code is not part of the boot code, it
' just starts the PASM cog and shows the result
dira[12]~~ ' for Tracy only...
outa[12]~ ' This turns on power to my SD card
waitcnt(clkfreq/10+cnt)
bytefill(@done,0,4+512+512) 'clear the buffers
done[0] := $FF 'set busy
cognew(@entry, @done)
repeat until (done[0] == 0)
dbg.start(31,30,0,9600)
waitcnt(clkfreq/10+cnt)
dbg.str(string("testing...",13))
DisplayParam
DisplayMBR
repeat
[/FONT][/SIZE]
On a quick test with one SanDisk 4Gb card, your program (with the appropriate pin assignments) and mine give the same results. But how do you know they are correct?
I tried this modified code with my troublesome Panasonic card with no change in result. I also tried it with the Lexar card above and found no difference.
Does it still throw out the GARBAGE? before the mbr result?
The result you show could be correct, if your mbr really doesn't contain any data. (your result does show some data actually, at the bottom of the mbr)
You could try to write data to the mbr and see if it shows up. Its possible you don't have a problem with your sd cards?
On a quick test with one SanDisk 4Gb card, your program (with the appropriate pin assignments) and mine give the same results. But how do you know they are correct?
Because you modified the code to fix the sd PASM and fullduplexserial PASM stomping on eachother, before you tested, your results are probably correct. (as correct as can be?)
Technically the only perfect way to know we are getting good MBR data is to write custom data to our MBR, and then do this read.
(the program "winimage" allows the modification of MBR data) (CAREFULL, you can seriously screw up your computers mbr with this program)
Others here used the original code, and most their results show the MBR with all 0 data. (except the very end)
(it could be correct, but i figured its best to re-test because with my card, before the fix, it showed all 0's in the mbr (except the very end), and then after the PASM fix it showed tons of data in the mbr at the beginning.
I wrote to my sd cards MBR using winimage.
I did this by saving the mbr in winimage as mbr.bin file, I then opened it up in NOTEPAD and started typing, I then saved it as is. I then imported it into winimage, writing to the mbr of the sd card.
Heres the result with the fixed spin program.
Clusos program as it is now in the first post (he hasn't fixed it yet) will not even push this information to the terminal, it will just throw out garbage due to the pasm stomping.
It seems that due to variations in the sd card logic speeds, some see the problem, and others do not.
But rest assured, the sd PASM, and the fullduplexserial PASM are stomping on eachother in the original program.
BTW I have no idea what I'm looking for in this data. Is what I posted any good? I am using the latest code that Clock Loop posted on a Prop BOE board.
BTW I have no idea what I'm looking for in this data. Is what I posted any good? I am using the latest code that Clock Loop posted on a Prop BOE board.
It LOOKs good, there is data at the end of your MBR, but not at the beginning, most SD cards that have original format have nothing in the beginning of the MBR. (but most show some data near the end, like yours.)
The only way data gets into the MBR of a sd card is if you used a utility with it that wrote data to the mbr. (linux boot, etc...)
I expect most sd card results here to match yours IF they use my modified program.
If they use clusos, the beginning of the mbr could possibly show all 0's but really have data in it. (like my 16 gig sdhc pny card did, in my post above)
I used the SD formatter program from the SD org website on my Mac to format the cards before I used your program. It formats them to FAT16.
It looks like anyone who did that, or has original mbr format, ends up with this at the very end of the MBR, while most of the other mbr data is all 0's.
To that You can use mos of BOOT spaces area --- As long You don't will boot from that SC on windows machine. -- Reading else writing to That SD give You never problems.
On Image I post You can see what every value near end say to You.
Look on table on right side of picture
Oh right, I suppose this is the best way to verify the MBR data, open up winhex, and compare it to the values output by the spin program.
If I did that I would have immediately noticed the discrepancy and posted here about it.
But after fixing the original program, it made me aware that my previous MBR reads with the original broken program cluso posted were bad reads.
Some of my sd cards worked fine with the code cluso posted, like others here.
But 3 of my sd cards wouldn't show the result, and only throw garbage at the terminal continuously, which is what made me aware of the program being buggy.
At first I just added some wait counts, and that helped, it would still initially throw out garbage, but then would show the mbr data.
Then after figuring out the real problem (main spin code PASM stomping on sub object's PASM (or vice versa), it all cleared up and the garbage problem went away.
Im still curious, ... I didn't know it was possible for PASM in the main spin file, to interact with PASM in an object that is included in that main spin file.
But its happening in the original program. Its probably a simple fix, but I understand very little PASM.
Its also completely possible that I am not even close to what the cause of this problem really is. (i.e. memory stomping) (PASM labels being identical?)
Sorry guys, I am really busy.
What is most likely happening are 2 problems..
1. The card is slow and therefore the busy is being returned for a long time and this is filling up my hub buffer and overruning hubram. It could also occur on large cards. I have no checks, just a buffer of 8K longs. This is the 37 xx xx FF 29 xx 01 FF code repeating. I have not timeout checks, nor overrun checks.
2. The upper ASCII characters >= $80 should e checked and masked. Some of these may upset PST.
I did notwant the MBR changed so that I could see what else may be there that we might upset in my method. Seems most either have nothing (all $00) in the boot code, or a small bootloader with the message somthing like not found. We can utilise these without any risk. They all seem to be FAT16 or FAT 32. If the card is raw (no formatting) then it is all $00 with no MBR identifier $55 $AA at the very end. Often you can see partition table data - the last 4 * 16 bytes before the $55 $AA identifier.
To repeat again, my method does not care what formatting (read file system) is on the card. This way, we can best utilise whatever open file system is devised later to deal with the larger SD cards without falling foul of MS patents. I am sure this will happen, and we will be able to write (without any changes to the ROM) a new boot loader to take care of this. We also can utilise the full encryption of the P2 as well. This is the simplest and safest method possible.
I posted P1 code that can locate a Boot File within the FAT16/32 filesystem and write this pointer and an Identifier into the MBR boot area. This could be simply modified to copy the direct sector of a boot partition should you wish to utilise this method. It just works simply guys, so why al the fuss.
I am more concerned to make sure that we have the logic correct to read a few raw sectors from the SD card using the P2 ROM. Just enough to locate a small boot program (or whole P2 program). This can load up a file system, partition system, or nothing but raw access. My method can cater for almost anything, all with minimum ROM usage.
I did notwant the MBR changed so that I could see what else may be there that we might upset in my method. Seems most either have nothing (all $00) in the boot code, or a small bootloader with the message somthing like not found. We can utilise these without any risk. They all seem to be FAT16 or FAT 32. If the card is raw (no formatting) then it is all $00 with no MBR identifier $55 $AA at the very end. Often you can see partition table data - the last 4 * 16 bytes before the $55 $AA identifier.
To repeat again, my method does not care what formatting (read file system) is on the card. This way, we can best utilise whatever open file system is devised later to deal with the larger SD cards without falling foul of MS patents.
SO this test was just to see if most sd cards COULD read their MBRS? AND to see if any of the regular formatted sd cards had anything in the mbr?
It looks like everyones sd cards read fine with the test program, and most mbr's are empty. I like not relying on a specific format or file system to boot the p2. This will allow any p2 developer to even develop their OWN operating system and file system if they choose. And this also allows other file systems like linux ext3 to be utilized if the user so chooses, because the p2 is only looking for mbr data in specific location for boot code. What the developer does from that point on is wide open. Just the way everyone here likes it. FREEDOM!
I think that the only reason any one would suggest it be tied to a specific file system format, is because they don't understand the nature of the mbr and how it dosen't care what file system you use, the mbr chugs along oblivious to any file system format, making it perfectly suited for modification with pointer code. (exactly how computers work today)
The p2 is pretty much a computer in a single chip, so it makes sense to adopt mbr booting.
Perhaps I missing some gotchas? Consider how long computers have been utilizing mbr to boot a plethora of OS's, even today with our modern 64-bit cpus, OS's and super immersive gaming, but yet it all starts with a simple MBR method that was invented decades ago, and hasn't changed at all since, even with our 4ghz, 16gig ram, solid state hard drives, 64-bit cpus, etc... all the wonderful advanced hardware and software, but yet we still rely on the good ol' simple MBR to get it all going.
This method has worked so well for so long, I am kinda surprised to see opposition to it, and even more surprised to see people saying that the p2 ROM should contain FAT support!!!!!! HELL NO. o.O
A few of my sd cards had info in the mbr, but thats because i had used those sd cards for bootable utilities, firmware updaters, and mini-linux, and I had to use a special tool to format and write data to those cards.
It looks like, ALL sd cards so far can read the mbr just fine, and like you said, they all have no data in the mbr. (with original sd format)
The idea to use the sd mbr as pointer to locate boot code for p2, looks like it will work great! Now let hope it gets implemented.
(its pretty easy to plop a binary file onto the sd card, and then use a tool to find its start address, then inject that start address into the mbr at pre-defined location.)
Is this something a new user to the p2 will be able to easily do? No, not at first.
But then after the guru's here hack on it, they will develop a tool that allows one to automate most of the process, by just supplying the drive letter of the sd card, and the prop2 program to be booted.
A tool could be developed for different sd formats also.
But then after the guru's here hack on it, they will develop a tool that allows one to automate most of the process, by just supplying the drive letter of the sd card, and the prop2 program to be booted.
A tool could be developed for different sd formats also.
The same Prop (P1 or P2) can be the tool:
1) serially upload to prop ram the firmware for this purpose
2) send the information on what pins the SD is wired
3) send data to write to SD
Comments
I have only seen one MBR/VBR where data is in the area I want to store the pointer.
Does anyone have an SDXC that they can post results?
p
Something in the program is still messed up because I also get garbage at first for about 4 seconds, and then it works.
Size: 2gig
Type:MicroSD
Works with windows.
ALL PREVIOUS SD CARD RESULTS ARE INVALID DUE TO BROKEN PASM CODE!!!!
I found this out by only starting the FULLDUPLEXSERIAL object AFTER the sdroutines in PASM were done.
Now my SDHC 16gb PNY card reads like this:
[code]
Parameters used...
00 00 01 FF 08 AA 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
MBR sector 0...
FA 33 C0 8E D0 BC 00 7C 8B F4 50 07 50 1F FB FC
I tried this modified code with my troublesome Panasonic card with no change in result. I also tried it with the Lexar card above and found no difference.
[code]
Parameters used...
00 00 01 FF 08 AA 05 FF 37 AA 01 FF 29 AA 01 FF
37 AA 01 FF 29 AA 00 FF 11 00 00 FF FE FF 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
MBR sector 0...
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03 ................
39 00 06 1F FF DF F5 00 00 00 0B 83 1E 00 00 00 9..
I too had modified the spin code, first because of the pin assignments, but also
1) my SD card power is switched by p12 and
2) I was getting garbage data.
I too found that there was a weird interaction between the serial port and the SD card test, so I ended up moving the serial port initialization to after the test. Here is how I modified Cluso's spin code, only the first PUB. I'm using BST/Mac, so I left off the long startup delay.
On a quick test with one SanDisk 4Gb card, your program (with the appropriate pin assignments) and mine give the same results. But how do you know they are correct?
Does it still throw out the GARBAGE? before the mbr result?
The result you show could be correct, if your mbr really doesn't contain any data. (your result does show some data actually, at the bottom of the mbr)
You could try to write data to the mbr and see if it shows up. Its possible you don't have a problem with your sd cards?
Size: 2GB FAT16
Type:MicroSD
Works with windows and Prop.
Because you modified the code to fix the sd PASM and fullduplexserial PASM stomping on eachother, before you tested, your results are probably correct. (as correct as can be?)
Technically the only perfect way to know we are getting good MBR data is to write custom data to our MBR, and then do this read.
(the program "winimage" allows the modification of MBR data) (CAREFULL, you can seriously screw up your computers mbr with this program)
Others here used the original code, and most their results show the MBR with all 0 data. (except the very end)
(it could be correct, but i figured its best to re-test because with my card, before the fix, it showed all 0's in the mbr (except the very end), and then after the PASM fix it showed tons of data in the mbr at the beginning.
Size: 1GB FAT16
Type:MicroSD
Works with windows and Prop.
[code]
Parameters used...
00 00 01 FF 08 AA 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 00 FF 3A 00 00 FF 11 00 00 FF
FE FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
MBR sector 0...
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 ................
04 00 06 04 E4 C9 81 00 00 00 7F CF 1D 00 00 00 ....
Size: 2GB FAT16
Type:MicroSD
Works with windows and Prop.
[code]
Parameters used...
00 00 01 FF 08 AA 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 00 FF
3A 00 00 FF 11 00 00 FF FE FF 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
MBR sector 0...
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 ................
08 00 06 1F DF BF 85 00 00 00 7B 07 3B 00 00 00 ...߿
I did this by saving the mbr in winimage as mbr.bin file, I then opened it up in NOTEPAD and started typing, I then saved it as is. I then imported it into winimage, writing to the mbr of the sd card.
Heres the result with the fixed spin program.
Clusos program as it is now in the first post (he hasn't fixed it yet) will not even push this information to the terminal, it will just throw out garbage due to the pasm stomping.
It seems that due to variations in the sd card logic speeds, some see the problem, and others do not.
But rest assured, the sd PASM, and the fullduplexserial PASM are stomping on eachother in the original program.
Brand:SanDisk
Size: 1gb
Type: MicroSD
It LOOKs good, there is data at the end of your MBR, but not at the beginning, most SD cards that have original format have nothing in the beginning of the MBR. (but most show some data near the end, like yours.)
The only way data gets into the MBR of a sd card is if you used a utility with it that wrote data to the mbr. (linux boot, etc...)
I expect most sd card results here to match yours IF they use my modified program.
If they use clusos, the beginning of the mbr could possibly show all 0's but really have data in it. (like my 16 gig sdhc pny card did, in my post above)
It looks like anyone who did that, or has original mbr format, ends up with this at the very end of the MBR, while most of the other mbr data is all 0's.
[code]
Parameters used...
00 00 01 FF 08 AA 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
MBR sector 0...
33 C0 8E D0 BC 00 7C FB 50 07 50 1F FC BE 1B 7C 3
On Image I post You can see what every value near end say to You.
Look on table on right side of picture
To that You can use mos of BOOT spaces area --- As long You don't will boot from that SC on windows machine. -- Reading else writing to That SD give You never problems.
Only reserved place are Parameters area
Oh right, I suppose this is the best way to verify the MBR data, open up winhex, and compare it to the values output by the spin program.
If I did that I would have immediately noticed the discrepancy and posted here about it.
But after fixing the original program, it made me aware that my previous MBR reads with the original broken program cluso posted were bad reads.
Some of my sd cards worked fine with the code cluso posted, like others here.
But 3 of my sd cards wouldn't show the result, and only throw garbage at the terminal continuously, which is what made me aware of the program being buggy.
At first I just added some wait counts, and that helped, it would still initially throw out garbage, but then would show the mbr data.
Then after figuring out the real problem (main spin code PASM stomping on sub object's PASM (or vice versa), it all cleared up and the garbage problem went away.
Im still curious, ... I didn't know it was possible for PASM in the main spin file, to interact with PASM in an object that is included in that main spin file.
But its happening in the original program. Its probably a simple fix, but I understand very little PASM.
Its also completely possible that I am not even close to what the cause of this problem really is. (i.e. memory stomping) (PASM labels being identical?)
What version of Winhex do you have? I was thinking about buying.
What is most likely happening are 2 problems..
1. The card is slow and therefore the busy is being returned for a long time and this is filling up my hub buffer and overruning hubram. It could also occur on large cards. I have no checks, just a buffer of 8K longs. This is the 37 xx xx FF 29 xx 01 FF code repeating. I have not timeout checks, nor overrun checks.
2. The upper ASCII characters >= $80 should e checked and masked. Some of these may upset PST.
I did notwant the MBR changed so that I could see what else may be there that we might upset in my method. Seems most either have nothing (all $00) in the boot code, or a small bootloader with the message somthing like not found. We can utilise these without any risk. They all seem to be FAT16 or FAT 32. If the card is raw (no formatting) then it is all $00 with no MBR identifier $55 $AA at the very end. Often you can see partition table data - the last 4 * 16 bytes before the $55 $AA identifier.
To repeat again, my method does not care what formatting (read file system) is on the card. This way, we can best utilise whatever open file system is devised later to deal with the larger SD cards without falling foul of MS patents. I am sure this will happen, and we will be able to write (without any changes to the ROM) a new boot loader to take care of this. We also can utilise the full encryption of the P2 as well. This is the simplest and safest method possible.
I posted P1 code that can locate a Boot File within the FAT16/32 filesystem and write this pointer and an Identifier into the MBR boot area. This could be simply modified to copy the direct sector of a boot partition should you wish to utilise this method. It just works simply guys, so why al the fuss.
I am more concerned to make sure that we have the logic correct to read a few raw sectors from the SD card using the P2 ROM. Just enough to locate a small boot program (or whole P2 program). This can load up a file system, partition system, or nothing but raw access. My method can cater for almost anything, all with minimum ROM usage.
Dump of MBR:
Dump of MBR:
[code]
testing...
Parameters used...
00 00 01 FF 08 AA 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
37 00 01 FF 29 00 01 FF 37 00 01 FF 29 00 01 FF
MBR sector 0...
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 ................
0C 00 0B 38 F8 B8 89 00 00 00 77 9F 3A 00 00 00 ...8
http://www.winhex.com/winhex/
SO this test was just to see if most sd cards COULD read their MBRS? AND to see if any of the regular formatted sd cards had anything in the mbr?
It looks like everyones sd cards read fine with the test program, and most mbr's are empty. I like not relying on a specific format or file system to boot the p2. This will allow any p2 developer to even develop their OWN operating system and file system if they choose. And this also allows other file systems like linux ext3 to be utilized if the user so chooses, because the p2 is only looking for mbr data in specific location for boot code. What the developer does from that point on is wide open. Just the way everyone here likes it. FREEDOM!
I think that the only reason any one would suggest it be tied to a specific file system format, is because they don't understand the nature of the mbr and how it dosen't care what file system you use, the mbr chugs along oblivious to any file system format, making it perfectly suited for modification with pointer code. (exactly how computers work today)
The p2 is pretty much a computer in a single chip, so it makes sense to adopt mbr booting.
Perhaps I missing some gotchas? Consider how long computers have been utilizing mbr to boot a plethora of OS's, even today with our modern 64-bit cpus, OS's and super immersive gaming, but yet it all starts with a simple MBR method that was invented decades ago, and hasn't changed at all since, even with our 4ghz, 16gig ram, solid state hard drives, 64-bit cpus, etc... all the wonderful advanced hardware and software, but yet we still rely on the good ol' simple MBR to get it all going.
This method has worked so well for so long, I am kinda surprised to see opposition to it, and even more surprised to see people saying that the p2 ROM should contain FAT support!!!!!! HELL NO. o.O
A few of my sd cards had info in the mbr, but thats because i had used those sd cards for bootable utilities, firmware updaters, and mini-linux, and I had to use a special tool to format and write data to those cards.
It looks like, ALL sd cards so far can read the mbr just fine, and like you said, they all have no data in the mbr. (with original sd format)
The idea to use the sd mbr as pointer to locate boot code for p2, looks like it will work great! Now let hope it gets implemented.
(its pretty easy to plop a binary file onto the sd card, and then use a tool to find its start address, then inject that start address into the mbr at pre-defined location.)
Is this something a new user to the p2 will be able to easily do? No, not at first.
But then after the guru's here hack on it, they will develop a tool that allows one to automate most of the process, by just supplying the drive letter of the sd card, and the prop2 program to be booted.
A tool could be developed for different sd formats also.
The same Prop (P1 or P2) can be the tool:
1) serially upload to prop ram the firmware for this purpose
2) send the information on what pins the SD is wired
3) send data to write to SD