Android application to manipulate sd image from the site
Pages: 1 2 3 4 5 6 7 8 9 10 11 ... 15
h0bby1 (2567) 480 posts |
aaaa |
Chris Hall (132) 3554 posts |
UnTarBZ has been fixed and should work correctly. |
h0bby1 (2567) 480 posts |
aaaa |
Rick Murray (539) 13806 posts |
Android?!? As has been mentioned, extracting files on something that isn’t RISC OS will fail because RISC OS uses metadata to hold file type information. Why complicate things with Android? Here’s a rough guide of how to do it on RISC OS native… |
Steve Pampling (1551) 8155 posts |
I believe that the U-boot startup is capable of loading the boot OS from a network (TFTP) server in which case you could have several different files on the server and swap as required. |
h0bby1 (2567) 480 posts |
aaaa |
Steve Pampling (1551) 8155 posts |
The Pi OS image is 4MB, the other baggage in the NOOBS image is disc content that is largely applications, utilities, games. I was thinking you’d be working to produce small modules to hook into the OS or a revised OS image around 4MB and loading that, once that’s loaded any disc content can be loaded locally. |
h0bby1 (2567) 480 posts |
aaaaa |
h0bby1 (2567) 480 posts |
aaaa |
h0bby1 (2567) 480 posts |
aaaaa |
Rick Murray (539) 13806 posts |
It depends upon how much you value your time. I’m assuming that you have a generic PC. You can pick up fairly inexpensive USB→SD adaptors, and there are even tiny USB→µUSB things too. Performance won’t set the world alight, but it’s better than other options. Then, you can just use the image reader/writer applicable to your system (Win32DiskImager for Windows).
Which file did you download and attempt to unpack?
Pretty much, no. I believe there is some rudimentary support for Filecore media in ArmLinux, so you might be able to write a filing system? Otherwise, no. I’d like to be able to use Filecore content natively under Windows; but it isn’t possible, too many differences (and Windows historically is crap and anything non-Microsoft).
…buy a little USB SD interface for your main computer. Set up the RISC OS machine as you like it, then take an image of the SD card. If something should happen, just re-image the SD card. Additionally – be sure that when you copy your custom ROM image to the FAT partition, you keep the previous one (rename it “riscos.old” or something). That way, if it all goes wrong and won’t boot, you just need to pop the card into the reader, and on the PC, rename “riscos.img” as “riscos.kak” (or whatever you like) and “riscos.old” as “riscos.img”. It will then boot with the previous (good) version. No wasting hours and hours. I don’t know about your neck of the woods, but E.Leclerc sells these things for about €7,00 for a basic model. If you have a specialist shop you might be able to get one cheaper. Some µSD cards come with a reader. Or the cheapest way of all, hit eBay. €7 is about an hour at SMIC rates, so… yeah… it’s a better option, really. ;-) |
h0bby1 (2567) 480 posts |
aaaa |
h0bby1 (2567) 480 posts |
aaaaa |
h0bby1 (2567) 480 posts |
aaaaa |
Rick Murray (539) 13806 posts |
Sounds interesting. Do you need to have a rooted device, or can this run as an app on generic Android? Mmmm, would generic Android even attempt to do anything with an SD card in an unknown format? Well, it will mount the FAT part, but the rest?
I don’t think we use MBR at all (any confirmation?) and generic Filecore doesn’t support partitioning. It has always just assumed that a connected drive will be such and such a type of drive. It is possible to partition with other people’s firmware – my RiscPC has a large drive (8GiB?) in five partitions via a Simtec IDE card, but it is a mechanism specific to Simtec. For all I know it lies and fakes there being five harddiscs? The way the dual format SD card works is, essentially, smoke and mirrors. Thanks to luck, the sectors important to SDFS are not the same as the ones important to FAT. So an SDFS format volume is created first. Then with a lot of care, a smaller FAT volume is created within the SDFS volume. Both start “at the beginning of the media”. From the RISC OS side, the FAT partition is marked out by wiping the space out of the free space map and mapping it out as “there is a file here”. RISC OS believes that the FAT volume is “just a file” and since DOSFS can access FAT images, we can access it via RISC OS in that manner. Note: As a result of this, the FAT volume ($.!Boot.Loader) can be opened and the files within changed, but the Loader file itself must not be altered (copied, deleted, etc). You can move it (say, from an old !Boot to a new one) but if you copy it, it will copy as a regular file and all of the specific and important associations with the FAT side will not be preserved. That would be a bad thing. When inserted into anything non-RISC OS, the device will see the FAT partition and mount it. I wanted to make my own software to create a 4GiB SD image (as 2GiB cards are harder to come by these days) and maybe to make a Beagle xM compatible version. It is… really complicated. Deep magic, smoke and mirrors type stuff. ;-) Make life easier on yourself if you want larger SD cards → http://piccolosystems.com/disctools/systemdisc |
h0bby1 (2567) 480 posts |
aaaaa |
h0bby1 (2567) 480 posts |
aaaa |
h0bby1 (2567) 480 posts |
aaaaa |
Steve Pampling (1551) 8155 posts |
For smallish drives that is true, however modern drives are tending to be rather large and partitioning to keep map sizes down is useful. (See the bounty page for the requirement to make the system partition aware). |
h0bby1 (2567) 480 posts |
aaaaa |
David Feugey (2125) 2709 posts |
True. But Filecore should also be simplified/optimised for SSD as hard drive are EOL products now. |
Chris Evans (457) 1614 posts |
Early Acorns were limited to 31 files per disk (BBC B & Master etc.). All RISC OS computers were limited to 77 entries per directory until RISC OS 4 appeared. RISC OS machines rarely spend noticeable time accessing discs. The operating system and native applications very rarely have more than 40 entries per directory and programs normally load as single file so the type of filing system optimization you are talking about weren’t really necessary. |
h0bby1 (2567) 480 posts |
aaaaa |
David Feugey (2125) 2709 posts |
+ TRIM support of course. I hope Picollo Systems will ad this some day. |
Steve Pampling (1551) 8155 posts |
Windows users saving images on a windows server in a file structure referenced by a database with naff indexing complain that the network is slow when trying to retrieve one of the 7,000 plus images all held in one directory. Cynical? What? Anyone would think I maintain the network and get annoyed about the misattribution of the problem. Wireshark delta values for request in to server and data send from server didn’t convince the database authors. Idiots. |
Pages: 1 2 3 4 5 6 7 8 9 10 11 ... 15