Com3 for me is one of those USB to serial plugs. I bought 10 of them recently and one day if the dracblade sells some more I might make up a kit of parts and I'd include that adaptor in the kit as they only cost $2. I jsut tested it on com3 with about 20 downloads and it works reliably. So maybe a USB to serial plug might be an option?
His cheeks are bigger than mine (my chin is fat [noparse]:)[/noparse], his glasses are dark (mine are bright), and he seems to be dark blonde (I am black haired). No, that couldn't be me if I was to pass some border and had this photo in my passport.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Dr_Acula said...
Com3 for me is one of those USB to serial plugs. I bought 10 of them recently and one day if the dracblade sells some more I might make up a kit of parts and I'd include that adaptor in the kit as they only cost $2. I jsut tested it on com3 with about 20 downloads and it works reliably. So maybe a USB to serial plug might be an option?
I have a cheapo USB to serial adapter. Unfortunately this caused even more trouble on Linux. See the "Proposed Z80..." thread more towards the beginning for that drama No, I'm happy with how it is now and I think the problem can be cured by BradC in some way. And if not, I can live with the workaround I found.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
I would like to integrate the SD card driver to get something loaded into the DracBlade RAM before the Z80 runs it. Memory access seems to be working, but the RAM contains nothing useful so far [noparse]:)[/noparse]
I intend to not use the fsrw stuff, but rather pull the boot image right from a separate SD range after the first sector.
The FAT boot sector on an SD card can contain a number of sectors to ignore before any special FAT32 sectors and 2 FAT copies. This area is usually called hidden sectors and for Linux there is mkdosfs which allows to specify the number when creating a new filesystem (i.e. formatting). That value would be set to skip over the boot sector (512 bytes of which 256 are used), 32K image as an optional bootstrap image for the Propeller, and up to 8 x 8MB images of the CP/M hard disks.
I think that optionally also the Propeller's hub RAM should be bootable off the SD. I have to look at sdspiFemto.spin how to do that. A flag in the first sector could indicate if a Propeller boot image is there. This way you could later use CP/M to update the boot image without the need of re-writing the EEPROM.
The primary boot loader for the Z80 PC=$FF00 (the file DSKBOOT_.ROM) should be loaded from the first sector after the DOS/FAT boot sector, i.e. LBA #1 if counting from zero. This Z80 boot sector could then have up to 8 HD images' offsets (LBAs) stored inside it, e.g. at the end of the 256 bytes. 8 longs should suffice. That way no file system access would be required and I could entirely leave out fsrwFemto.spin or other filesystem drivers.
Dr_A's MyName.txt stuff could also be done by just patching the name into a fixed location of the Z80 boot sector for simplicity. I would like to just define the (extended) layout of the 256 byte Z80 boot sector this way (request for comments):
offset meaning
----------------------------------------
00..ce Boot loader code
cf <> 0 means a 32K Propeller RAM image follows this sector.
d0..df Name of the machine (former MyName.txt)
e0..e3 LBA of the first HD image
e4..e7 LBA of the second HD image
..
fc..ff LBA of the eigth HD image
If an LBA value is 0, this image isn't present. Otherwise the LBA is the first sector of a fixed size 8MB (16384 x 512 bytes sectors) image on the SD. Drive A: is mandatory, so the LBA at e0..e3 cannot be 0.
I think this allows for maximum flexibility, as you can even swap drives by swapping their LBA start sector numbers.
Please comment,
Juergen
PS: I tried formatting an SD card and it looks like the value "hidden sectors" doesn't do anything at all, at least not what you would expect. If I let my digicam format an empty 1GB SD card, it writes a value of 0x000000E3 to the hidden sectors field in the boot sector, while there is no space at all between the boot sector and the first FAT. I have to try to build some image that the camera still understands and which leaves room at the start of the SD. Alternatively we could use the end of the SD by decreasing the size of the DOS/FAT volume by the required number of sectors. The first sector of a Z80 region could then be calculated from the DOS/FAT boot sector values.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Why not use standard PARTITIONING system and create first partition as BIG as needed as no Windows partition and sacond as FAT16.
One problem with that is as it will not be posible to directly copy files to that Partition on Windows system.
In that partition You can create CPM partitions that can be directly accesible from CPM.
But all files that needs to CPM in that case if needed for it must be copied by CPM to it.
And You need after formating of that partition and Delate it in needed CPM portions initiate first drive with CPM boot DRIVE A else First HD partition To be posible to boot CPM and have all files in it to comunicate betwen PC - Linux-Windows by Serial Com's
Regards
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
I've just uploaded an experimental version of bstc (bstc-0.15.4-pre6) with some minor timing and sequence changes for reset. It's been lightly tested here.
It has a bug in the command line parsing so if you are going to use a list file it's now -ls (list + source). Due to the bug, that option can *not* be immediately prior to the file name. It must be either last on the line or followed by another option.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Why not use standard PARTITIONING system and create first partition as BIG as needed as no Windows partition and sacond as FAT16.
One problem with that is as it will not be posible to directly copy files to that Partition on Windows system.
In that partition You can create CPM partitions that can be directly accesible from CPM.
But all files that needs to CPM in that case if needed for it must be copied by CPM to it.
And You need after formating of that partition and Delate it in needed CPM portions initiate first drive with CPM boot DRIVE A else First HD partition To be posible to boot CPM and have all files in it to comunicate betwen PC - Linux-Windows by Serial Com's
Regards
Christoffer J
It looks like there are no partitions on a SD media. There's just one volume beginning at sector #0, so it looks more like a huge floppy disk.
Otherwise your suggestion was of course right, but I think SD card with a parition table isn't going to work with anything else.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
BradC said...
I've just uploaded an experimental version of bstc (bstc-0.15.4-pre6) with some minor timing and sequence changes for reset. It's been lightly tested here.
It has a bug in the command line parsing so if you are going to use a list file it's now -ls (list + source). Due to the bug, that option can *not* be immediately prior to the file name. It must be either last on the line or followed by another option.
Thank's a bunch! This one is looking good! My SPINC_FLAGS is now -Ox -ls -e -p0 -d/dev/ttyS0, so it won't hit the bug.
Edit: Err, no, actually it tells me it uploaded successfully to RAM but the DracBladeProp starts the image from the EEPROM. I was wondering why a message that was no longer in the source still appeared, that's how I realized it. Here's the output of my make:
bstc.linux -Ox -ls -e -p0 -d/dev/ttyS0 -L.. -o yaz80_demo yaz80_demo.spin
Brads Spin Tool Compiler v0.15.4-pre6 - Copyright 2008,2009,2010 All rights reserved
Compiled for i386 Linux at 13:15:13 on 2010/03/20
Loading Object yaz80_demo
Loading Object yaz80
Loading Object io
Loading Object FullDuplexSerial_rr004
Loading Object sdspiFemto
Loading Object dracblade
Program size is 4899 longs
Compiled 6285 Lines of Code in 0.469 Seconds
We found a Propeller Version 1
Propeller Load took 4.857 Seconds
gtkterm
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Thank's a bunch! This one is looking good! My SPINC_FLAGS is now -Ox -ls -e -p0 -d/dev/ttyS0, so it won't hit the bug.
Try 0.15.4-pre7 (which is uploading now). I've tightened the timing up even further. This one flips the DTR both ways on startup so it's in a known state. Then it transitions it again with 2ms. Hopefully it's slow enough to get the reset pulse through, but fast enough that it will work comfortably with both polarities. It survives a quick torture test with my Prop Plug here. Feedback gratefully accepted. Previously I was waiting 20ms until the second transition (the one that causes the reset with the FTDI chip) which meant the circuit you guys were using would be waiting 20ms longer and likely to fall outside the timing window.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Why not use the x86 boot sector, sector zero, instead of the first sector after the DOS/FAT boot sector?
I know nothing much of FAT but if understand correctly a in PC that boots from FAT the BIOS loads the first physical sector from the boot device into memory and transfers CPU execution to the start of that memory address. At offset zero there is located a jump instruction passed the BIOS Parameter Block (BPB).
Now your PC and none of your cameras etc are going to boot from this SD card so why not put the primary boot loader for the Z80 PC=$FF00 (the file DSKBOOT_.ROM) in there?
That is put ZIBOOT.COM in the DOS/FAT boot sector there because we are not going to use it to boot DOS.
Have HD images' offsets (LBAs) stored inside it as you suggest along with the MyName stuff. We have 512 bytes to play with minus the BPB size.
Am I right in assuming these (mB HD images will actually be in FAT files with pointers to them patched into the boot sector or are you intending to shrink the FAT and put them at the end?
Am I repeating myself? I'm tired...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
pullmoll: I never reprogram RamBlade. It locates and boots a program(s) (i.e. file under FAT16) directly from the uSD card. See the RamBlade thread for the description. The version there uses a modified PropCmd but here I am using SphinxOS now. No need to re-create the concept.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Why not use the x86 boot sector, sector zero, instead of the first sector after the DOS/FAT boot sector?
I know nothing much of FAT but if understand correctly a in PC that boots from FAT the BIOS loads the first physical sector from the boot device into memory and transfers CPU execution to the start of that memory address. At offset zero there is located a jump instruction passed the BIOS Parameter Block (BPB).
Now your PC and none of your cameras etc are going to boot from this SD card so why not put the primary boot loader for the Z80 PC=$FF00 (the file DSKBOOT_.ROM) in there?
That is put ZIBOOT.COM in the DOS/FAT boot sector there because we are not going to use it to boot DOS.
Have HD images' offsets (LBAs) stored inside it as you suggest along with the MyName stuff. We have 512 bytes to play with minus the BPB size.
Am I right in assuming these (mB HD images will actually be in FAT files with pointers to them patched into the boot sector or are you intending to shrink the FAT and put them at the end?
Am I repeating myself? I'm tired...
We can't use the DOS/FAT boot sector easily, because this one contains info about the drive geometry that is required, i.e. the BPB, and a camera or other device may change that or do weird things with Z80 code in there. I would leave the real boot sector alone. I actually prefer to use the space beyond the logical end of the DOS volume, as this should cause the least trouble with anybody else.
It is easy to find the first sector for CP/M this way. Its number is stored as a long at offset 0x20 in the DOS/FAT boot sector. So all you have to do is:
read sector 0 to a buffer
fetch the long at buffer offset 0x20 and call it e.g. LBA0
read sector LBA0 to Prop RAM at $FF00
let the Z80 jump there - or patch RAM[noparse][[/noparse]0..2] to jump there.
No, my intention was not to keep the images accessible as files, because then they may be moved (defrag) or otherwise damaged.
I wrote a little C program that reads ROM and DSK files and places them at ascending sectors at the LBA0++
The only thing I had to do was format the SD, look at its size in sectors (offset 0x20), subtract the number of sectors I need (1+8*16384) from this number and format it again, this time with the new, lower number of sectors as size. On Linux you can give the number of 1K blocks as 2nd parameter to mkdosfs, so I divide the sector count by 2.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Cluso99 said...
pullmoll: I never reprogram RamBlade. It locates and boots a program(s) (i.e. file under FAT16) directly from the uSD card. See the RamBlade thread for the description. The version there uses a modified PropCmd but here I am using SphinxOS now. No need to re-create the concept.
I don't know if you got what I intended: I wanted to get rid of any DOS/FAT filesystem code, because that is wasting hub RAM and possibly a cog for no reason. Therefore I was thinking about ways to make use of an SD card without a filesystem. To just make the DOS/FAT smaller by the size I want to use seems reasonable and should be compatible with any application or gadget that accesses such a card. It may, of course, indicate some "unused space", but hopefully leave this space alone anyway.
Edit: I think even if I used the SD card's space after a shrunken FAT volume, that should be compatible with Sphinx!? I could place the image to run in the FAT section and then have it looking for the boot sector and calculate resp. find the offsets for the HD images.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
In sector zero the drive geometry info is at byte 03 up to byte 89 (decimal) for FAT 32. This is the BIOS Parameter Block (BPB).
At bytes 0, 1, 3 is placed an x86 jump instruction to the rest of the boot code.
So the Z80 boot code and your image pointers, MyName stuff can be placed AFTER that at offset 90.
There should be a "signature" of 55 AA at byte offsets 510-511.
BradC said...
Try 0.15.4-pre7 (which is uploading now). I've tightened the timing up even further. This one flips the DTR both ways on startup so it's in a known state. Then it transitions it again with 2ms. Hopefully it's slow enough to get the reset pulse through, but fast enough that it will work comfortably with both polarities. It survives a quick torture test with my Prop Plug here. Feedback gratefully accepted. Previously I was waiting 20ms until the second transition (the one that causes the reset with the FTDI chip) which meant the circuit you guys were using would be waiting 20ms longer and likely to fall outside the timing window.
It looks like with the DracBlade the Prop is now reset after the image is uploaded to RAM. It may be that me starting gtkterm after the compilation is causing this, because gtkterm raises DTR when it starts.
I haven't seen -pre7 yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
heater said...
Yes you can use the DOS boot sector.
In sector zero the drive geometry info is at byte 03 up to byte 89 (decimal) for FAT 32. This is the BIOS Parameter Block (BPB).
At bytes 0, 1, 3 is placed an x86 jump instruction to the rest of the boot code.
So the Z80 boot code and your image pointers, MyName stuff can be placed AFTER that at offset 90.
There should be a "signature" of 55 AA at byte offsets 510-511.
Move 256 bytes from offset 90 in the buffer to Prop RAM at $FF00
Let the Z80 jump there - or patch RAM[noparse][[/noparse]0..2] to jump there.
That 256 bytes also contains the CP/M disk image offsets etc.
No matter if you put the images inside FAT or at the end of SD after a shrunken FAT.
Ok, this may work. It only prevents one from using the same SD to boot anything on a PC or some gadget from it.
I can easily change my tool to read the boot sector and patch the Z80 BOOT.ROM to offset 90 and write it back.
If you don't want to shrink the size of the FAT image, and if you don't defrag your SD, you can certainly find the first sector of the respective files and patch the end of the 256 bytes with these numbers.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
pullmoll: heater started out using an SD without FAT16. We have progressed so much further than that. IMHO I think to ditch the FAT16 is a grave mistake. Otherwise we cannot use other prop tools like SphinxOS, etc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Cluso99 said...
pullmoll: heater started out using an SD without FAT16. We have progressed so much further than that. IMHO I think to ditch the FAT16 is a grave mistake. Otherwise we cannot use other prop tools like SphinxOS, etc.
Well, it looks like we can stay all compatible without any trouble. You don't use the DOS/FAT boot sector in SphinxOS I assume, so heater and I can (ab)use it to contain the BOOT.ROM image plus the info where to find the HD images. You can still use the same SD for anything else, you just can no longer x86 boot from it. Does that sound like a deal?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
He is not proposing to ditch FAT on the SD card.
On the card the will be FAT as normal but possibly not occupying the entire card.
The CP/M images go in FAT files as we do now...
..OR the images go at the end of the card with a slightly smaller FAT space.
What PullMoll is saying is that the will be no FAT software needed in the Prop when running CP/M as it can get the images offsets from the boot sector. No need to search for the files.
In that system you can still keep CP/M inside FAT if you want and the the resulting SD's are compatible with what we have now.
Sounds cool to me.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
And why not put it in the VOLUME LABEL in the BIOS Parameter Block?
Dr_Acula uses it to give a name to his multiple DracBlades to distinguish them when they communicate via wireless.
Is the volume label at the same position in all BPB versions (FAT12, 16, 32)? Answering myself: no, it isn't, so for me this is a bad place to put the MyName info. I don't want to have to deal with FAT.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Here You have FAT32 Template tabele. Look on my previous post on FAT16.
Regards
Christoffer J
Ps. FAT12 and FAT16 have same template ONLY diference is in FAT table sector count.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
heater said...
Ah.. It's a host name for the Drac Protocol. dracp:://MyName....
Volume label is at bytes 43-53 for FAT 16 but bytes 71-81 for FAT 32.
I'd prefer to keep it inside the Z80 boot sector. That way it ends up in Z80 RAM at 0xffd0 and can be used right away.
I updated my sdinit.c to write the DOS boot sector with the embedded Z80 boot block: http://pmbits.ath.cx/cgi-bin/cvsweb/yaz80/sdinit.c
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
D'OH! There actually is a partition table on the SD. I was confused because I always looked at the device that Linux created for the partition table entry.
This of course means we can have a very clean solution by creating a separate partition with a specific type for CP/M and do in there whatever we want.
I realized this when reading the MBR and not finding the expected LBA0 value at offset 32. Of course, the MBR of the SD contains all 00s, except for the 16 bytes at 0x1be, which is partition slot 0, and the bytes at 0x1fe/0x1ff which are 0x55 and 0xaa. So you only have to create a partition for use with FAT16 (or FAT32) that leaves like 64MB for the CP/M stuff. Any non-Microsoft fdisk tool should be able to create such a partition. I would then change sdinit.c to look for that type of CP/M partition and copy the specified (or default) files there, including the BOOT.DSK 1 sector at the very start.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
My 2 GB FAT16 SD has no partitions with default formating.
But my 16 GB FAT32 has 2 Partitions as default as on all Windows drives.
Partition 0 as Data partition
and
Partition 1 as litle hiden spare partition (If I know that partition are only used on NTFS as Reserved spare sectors).
Regards
Christoffer J
Ps. (Partitions) It was my thinking at time I proposed it as I know as only FD drives can't be partitioned on Win system.
BUT in Default SD/Flash HD formats that neds be patched manualy as System handler on HD's not alow Partitioning them but if You format THAT Flash HD stick it automaticaly Partition it to that 2 partitions. Without posibility to Repartition IT.
Ps. ADDED 4 Pictures that give You correct info on organisation of Partitioning IN Windows
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
His cheeks are bigger than mine (my chin is fat [noparse]:)[/noparse], his glasses are dark (mine are bright), and he seems to be dark blonde (I am black haired). No, that couldn't be me if I was to pass some border and had this photo in my passport.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
I would like to integrate the SD card driver to get something loaded into the DracBlade RAM before the Z80 runs it. Memory access seems to be working, but the RAM contains nothing useful so far [noparse]:)[/noparse]
I intend to not use the fsrw stuff, but rather pull the boot image right from a separate SD range after the first sector.
The FAT boot sector on an SD card can contain a number of sectors to ignore before any special FAT32 sectors and 2 FAT copies. This area is usually called hidden sectors and for Linux there is mkdosfs which allows to specify the number when creating a new filesystem (i.e. formatting). That value would be set to skip over the boot sector (512 bytes of which 256 are used), 32K image as an optional bootstrap image for the Propeller, and up to 8 x 8MB images of the CP/M hard disks.
I think that optionally also the Propeller's hub RAM should be bootable off the SD. I have to look at sdspiFemto.spin how to do that. A flag in the first sector could indicate if a Propeller boot image is there. This way you could later use CP/M to update the boot image without the need of re-writing the EEPROM.
The primary boot loader for the Z80 PC=$FF00 (the file DSKBOOT_.ROM) should be loaded from the first sector after the DOS/FAT boot sector, i.e. LBA #1 if counting from zero. This Z80 boot sector could then have up to 8 HD images' offsets (LBAs) stored inside it, e.g. at the end of the 256 bytes. 8 longs should suffice. That way no file system access would be required and I could entirely leave out fsrwFemto.spin or other filesystem drivers.
Dr_A's MyName.txt stuff could also be done by just patching the name into a fixed location of the Z80 boot sector for simplicity. I would like to just define the (extended) layout of the 256 byte Z80 boot sector this way (request for comments):
If an LBA value is 0, this image isn't present. Otherwise the LBA is the first sector of a fixed size 8MB (16384 x 512 bytes sectors) image on the SD. Drive A: is mandatory, so the LBA at e0..e3 cannot be 0.
I think this allows for maximum flexibility, as you can even swap drives by swapping their LBA start sector numbers.
Please comment,
Juergen
PS: I tried formatting an SD card and it looks like the value "hidden sectors" doesn't do anything at all, at least not what you would expect. If I let my digicam format an empty 1GB SD card, it writes a value of 0x000000E3 to the hidden sectors field in the boot sector, while there is no space at all between the boot sector and the first FAT. I have to try to build some image that the camera still understands and which leaves room at the start of the SD. Alternatively we could use the end of the SD by decreasing the size of the DOS/FAT volume by the required number of sectors. The first sector of a Z80 region could then be calculated from the DOS/FAT boot sector values.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/20/2010 3:53:50 AM GMT
Why not use standard PARTITIONING system and create first partition as BIG as needed as no Windows partition and sacond as FAT16.
One problem with that is as it will not be posible to directly copy files to that Partition on Windows system.
In that partition You can create CPM partitions that can be directly accesible from CPM.
But all files that needs to CPM in that case if needed for it must be copied by CPM to it.
And You need after formating of that partition and Delate it in needed CPM portions initiate first drive with CPM boot DRIVE A else First HD partition To be posible to boot CPM and have all files in it to comunicate betwen PC - Linux-Windows by Serial Com's
Regards
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
It has a bug in the command line parsing so if you are going to use a list file it's now -ls (list + source). Due to the bug, that option can *not* be immediately prior to the file name. It must be either last on the line or followed by another option.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
It looks like there are no partitions on a SD media. There's just one volume beginning at sector #0, so it looks more like a huge floppy disk.
Otherwise your suggestion was of course right, but I think SD card with a parition table isn't going to work with anything else.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Thank's a bunch! This one is looking good! My SPINC_FLAGS is now -Ox -ls -e -p0 -d/dev/ttyS0, so it won't hit the bug.
Edit: Err, no, actually it tells me it uploaded successfully to RAM but the DracBladeProp starts the image from the EEPROM. I was wondering why a message that was no longer in the source still appeared, that's how I realized it. Here's the output of my make:
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/20/2010 5:38:53 AM GMT
Try 0.15.4-pre7 (which is uploading now). I've tightened the timing up even further. This one flips the DTR both ways on startup so it's in a known state. Then it transitions it again with 2ms. Hopefully it's slow enough to get the reset pulse through, but fast enough that it will work comfortably with both polarities. It survives a quick torture test with my Prop Plug here. Feedback gratefully accepted. Previously I was waiting 20ms until the second transition (the one that causes the reset with the FTDI chip) which meant the circuit you guys were using would be waiting 20ms longer and likely to fall outside the timing window.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Why not use the x86 boot sector, sector zero, instead of the first sector after the DOS/FAT boot sector?
I know nothing much of FAT but if understand correctly a in PC that boots from FAT the BIOS loads the first physical sector from the boot device into memory and transfers CPU execution to the start of that memory address. At offset zero there is located a jump instruction passed the BIOS Parameter Block (BPB).
Now your PC and none of your cameras etc are going to boot from this SD card so why not put the primary boot loader for the Z80 PC=$FF00 (the file DSKBOOT_.ROM) in there?
That is put ZIBOOT.COM in the DOS/FAT boot sector there because we are not going to use it to boot DOS.
Have HD images' offsets (LBAs) stored inside it as you suggest along with the MyName stuff. We have 512 bytes to play with minus the BPB size.
Am I right in assuming these (mB HD images will actually be in FAT files with pointers to them patched into the boot sector or are you intending to shrink the FAT and put them at the end?
Am I repeating myself? I'm tired...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 3/20/2010 5:50:37 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
We can't use the DOS/FAT boot sector easily, because this one contains info about the drive geometry that is required, i.e. the BPB, and a camera or other device may change that or do weird things with Z80 code in there. I would leave the real boot sector alone. I actually prefer to use the space beyond the logical end of the DOS volume, as this should cause the least trouble with anybody else.
It is easy to find the first sector for CP/M this way. Its number is stored as a long at offset 0x20 in the DOS/FAT boot sector. So all you have to do is:
No, my intention was not to keep the images accessible as files, because then they may be moved (defrag) or otherwise damaged.
I wrote a little C program that reads ROM and DSK files and places them at ascending sectors at the LBA0++
The only thing I had to do was format the SD, look at its size in sectors (offset 0x20), subtract the number of sectors I need (1+8*16384) from this number and format it again, this time with the new, lower number of sectors as size. On Linux you can give the number of 1K blocks as 2nd parameter to mkdosfs, so I divide the sector count by 2.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/20/2010 6:05:33 AM GMT
I don't know if you got what I intended: I wanted to get rid of any DOS/FAT filesystem code, because that is wasting hub RAM and possibly a cog for no reason. Therefore I was thinking about ways to make use of an SD card without a filesystem. To just make the DOS/FAT smaller by the size I want to use seems reasonable and should be compatible with any application or gadget that accesses such a card. It may, of course, indicate some "unused space", but hopefully leave this space alone anyway.
Edit: I think even if I used the SD card's space after a shrunken FAT volume, that should be compatible with Sphinx!? I could place the image to run in the FAT section and then have it looking for the boot sector and calculate resp. find the offsets for the HD images.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/20/2010 6:41:09 AM GMT
In sector zero the drive geometry info is at byte 03 up to byte 89 (decimal) for FAT 32. This is the BIOS Parameter Block (BPB).
At bytes 0, 1, 3 is placed an x86 jump instruction to the rest of the boot code.
So the Z80 boot code and your image pointers, MyName stuff can be placed AFTER that at offset 90.
There should be a "signature" of 55 AA at byte offsets 510-511.
I'm just going by the FAT boot sector layout I find here www.win.tue.nl/~aeb/linux/fs/fat/fat-1.html
So
That 256 bytes also contains the CP/M disk image offsets etc.
No matter if you put the images inside FAT or at the end of SD after a shrunken FAT.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
It looks like with the DracBlade the Prop is now reset after the image is uploaded to RAM. It may be that me starting gtkterm after the compilation is causing this, because gtkterm raises DTR when it starts.
I haven't seen -pre7 yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Ok, this may work. It only prevents one from using the same SD to boot anything on a PC or some gadget from it.
I can easily change my tool to read the boot sector and patch the Z80 BOOT.ROM to offset 90 and write it back.
If you don't want to shrink the size of the FAT image, and if you don't defrag your SD, you can certainly find the first sector of the respective files and patch the end of the 256 bytes with these numbers.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Actually this whole approach is compatible with what zicog_cpm does now with images in FAT files.
I do like the idea of not having to depend on un-fragmented images files. That always seemed a bit clunky.
With a shrunken FAT of known size it makes it easy for us dd users to just blat new CP/M disk images onto the SD at known offsets.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Well, it looks like we can stay all compatible without any trouble. You don't use the DOS/FAT boot sector in SphinxOS I assume, so heater and I can (ab)use it to contain the BOOT.ROM image plus the info where to find the HD images. You can still use the same SD for anything else, you just can no longer x86 boot from it. Does that sound like a deal?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
On the card the will be FAT as normal but possibly not occupying the entire card.
The CP/M images go in FAT files as we do now...
..OR the images go at the end of the card with a slightly smaller FAT space.
What PullMoll is saying is that the will be no FAT software needed in the Prop when running CP/M as it can get the images offsets from the boot sector. No need to search for the files.
In that system you can still keep CP/M inside FAT if you want and the the resulting SD's are compatible with what we have now.
Sounds cool to me.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Maybe that info help You on FAT16
Regards
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
And why not put it in the VOLUME LABEL in the BIOS Parameter Block?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Dr_Acula uses it to give a name to his multiple DracBlades to distinguish them when they communicate via wireless.
Is the volume label at the same position in all BPB versions (FAT12, 16, 32)? Answering myself: no, it isn't, so for me this is a bad place to put the MyName info. I don't want to have to deal with FAT.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/20/2010 7:03:46 AM GMT
Here You have FAT32 Template tabele. Look on my previous post on FAT16.
Regards
Christoffer J
Ps. FAT12 and FAT16 have same template ONLY diference is in FAT table sector count.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
Post Edited (Sapieha) : 3/20/2010 7:03:00 AM GMT
Volume label is at bytes 43-53 for FAT 16 but bytes 71-81 for FAT 32.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I'd prefer to keep it inside the Z80 boot sector. That way it ends up in Z80 RAM at 0xffd0 and can be used right away.
I updated my sdinit.c to write the DOS boot sector with the embedded Z80 boot block:
http://pmbits.ath.cx/cgi-bin/cvsweb/yaz80/sdinit.c
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
This of course means we can have a very clean solution by creating a separate partition with a specific type for CP/M and do in there whatever we want.
I realized this when reading the MBR and not finding the expected LBA0 value at offset 32. Of course, the MBR of the SD contains all 00s, except for the 16 bytes at 0x1be, which is partition slot 0, and the bytes at 0x1fe/0x1ff which are 0x55 and 0xaa. So you only have to create a partition for use with FAT16 (or FAT32) that leaves like 64MB for the CP/M stuff. Any non-Microsoft fdisk tool should be able to create such a partition. I would then change sdinit.c to look for that type of CP/M partition and copy the specified (or default) files there, including the BOOT.DSK 1 sector at the very start.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/20/2010 8:05:28 AM GMT
My 2 GB FAT16 SD has no partitions with default formating.
But my 16 GB FAT32 has 2 Partitions as default as on all Windows drives.
Partition 0 as Data partition
and
Partition 1 as litle hiden spare partition (If I know that partition are only used on NTFS as Reserved spare sectors).
Regards
Christoffer J
Ps. (Partitions) It was my thinking at time I proposed it as I know as only FD drives can't be partitioned on Win system.
BUT in Default SD/Flash HD formats that neds be patched manualy as System handler on HD's not alow Partitioning them but if You format THAT Flash HD stick it automaticaly Partition it to that 2 partitions. Without posibility to Repartition IT.
Ps. ADDED 4 Pictures that give You correct info on organisation of Partitioning IN Windows
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
Post Edited (Sapieha) : 3/20/2010 8:43:41 AM GMT
Forgot to make upload. It's there now.
Not sure what to do about the terminal program hitting the DTR. Have to think about that a bit.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.