• General

  • Is It Possible To Access All Of The Storage?

The cheap way would be to copy all files off the SD card, delete the FAT32 partition and create a new one that spans the whole disk. HOWEVER, you have to make sure that the new partition doesn't overwrite the firmware!
On Linux, partitioning tools typically start the first partition at sector 2048 (1MB from the start) unless you specify something else. That is way too early; the H3 firmware binary is currently well over 2 MB. The nightly SD card image starts the partition at sector 8192 (4 MB from the start).

I have just tried using fatresize on Linux to increase the size of the nightly image's file system after recreating the default partition with a larger size, but it doesn't work for me at all. I only get increasingly pointless error messages, or outright segfaults.

The reason why nothing of this sort is implemented in Engine BASIC is that it is both complicated and highly destructive if it goes wrong...

Thank you for your assistance, @uli !

Windows' inbuilt disk management tools aren't up to the task 🙁 After burning the firmware to a fresh 64GB uSD card, I just now used AOEMI Partition Assistant to clone the 64MB partition in some unused space, and then extended that partition to 32GB. It booted just fine. This uSD card goes in my GoPro, so this needs to be done again. At that point I will record the screen and post the video.

Link to photo of 32GB BASIC Engine NG uSD card 🙂
![https://drive.google.com/file/d/1LTCOOjVpOeK8zlR9MT4uBUjJ4sUzvBE1/view?usp=sharing](https://)

painintheworld In answer to your second question regarding USB drives, I think this thread has the information you want...H3 News.

On the USB side, there is now support for mass storage devices (CHDIR "/usb0") and USB controller 3. (The latter has a strange issue, at least on my OPi PC, in that devices plugged in on boot are not recognized. When they are attached while the system is running, they work...)

      Hawk I missed that somehow, thank you very much!

      Oh man, that will make things soooooo much easier as far as having tons of the free assets that I've been collecting.

        Agreed. I can see that having a simple version of a File Browser (like XTree Gold) would be very useful for copying and moving files around.

        Ahoy,
        So I have Engine BASIC NG on a 4GB uSD card. If I look at it in GPARTED in Linux I should say the FAT32 partition starts at 8192 and ends 63MB after that. What is there to stop me from just resizing to the end of the card space? The firmware at the beginning should either be shown as empty space or used unknown format right? GPARTED will only let you resize the last partition into empty space. It can resize without having to reformat the partition so it should work ok to use all the card. Many Linux distros commonly do a resize automagically with a new install.

        I'll have a look at my EB NG card when I boot my RPi 400. This main system is having some probs with the SSD sectors and won't even backup so I hesitate to touch GPARTED on it while it still boots and runs.
        daveyb

        • uli replied to this.

          MC10Guru What is there to stop me from just resizing to the end of the card space?

          In theory, nothing. But, as I have said, fatresize (which AFAICT uses parted) only produces errors and crashes for me.

          MC10Guru The firmware at the beginning should either be shown as empty space or used unknown format right?

          It's outside the partitioned space, so I assume it would show up as empty.

          I guess I should change that and make it a partition of some kind of "don't touch me" type to make it less easy to overwrite the firmware. (And slightly easier to update it without rewriting the entire SD image...)

          MC10Guru Many Linux distros commonly do a resize automagically with a new install.

          Most Linux installations nowadays do not have to deal with FAT32 file systems at all. If you have a Windows installation that you want to move out of the way, you have to shrink an NTFS file system. If you want to expand an SD or USB image to fill the medium, you have to enlarge an ext4 (or some other Linux-specific) file system.
          One potential reason to touch a FAT32 partition in a modern system would be to install an bootloader there, but that doesn't require resizing.

                Ahoy,
                I use FAT32 often as it is a common denominator for all my systems: Linux, Android & Windows. NTFS & EXT4 support is spotty at best between them. I've resized FAT32 in Win10 and Linux and never had a problem. Perhaps PARTED is doing something with the partition table that is corrupting the firmware area. I'll BU & try to resize my uSD card when I'm on my RPi 400. Today is a dead day as it is doctor & big-C testing time (again).
                daveyb

                  MC10Guru To the major stuff first: I hope your Big C testing works out as good as possible. I sympathize and empathize zettabytes worth.

                  To the minor stuff, I have the full capacity of the 32GB uSD card and 32GB USB flash drive at my program's disposal 🙂 I'm not exactly sure what I will do with all the space? Earlier today I was playing about with seeing how fast I could loading a series of downsized to SCREEN 14 JPGs (around .071 seconds per image in this particular test). It did pique my interest in learning more of how one might display old school FMV in a BASIC Engine game...

                      painintheworld I like the idea of if not FMV, then just have parts of the image animated, like the early 90s games. 0.071s is more than fast enough.
                      Hijacking this thread, is it possible to manipulate the colour palettes of images?

                          Hawk Uli indicated that color cycling, a la Atari 8 bit indirect color registers, isn't directly possible.

                          I did some really simply, brute force color cycling here >> `https://youtu.be/oAwZ6gl8RKE

                          Something like the two color Amiga bouncing ball should be trivial swapping between background layers and blitting, shouldn't it? From looking through the manual it should be. I've not yet played with multiple backgrounds, but I have done some stuff with blitting relatively large images and moving them about very quickly. The test in the following video moves a 320x240 PNG image (on a 640x480 screen) of the original Xbox logo nearly 18,000 pixel increments in 10 seconds (later to find out that I was running not full bore), so the horsepower is there to do some interesting stuff >> `https://www.youtube.com/watch?v=TN25QmnTxQ4 . I'm not sure how of the memory map that the graphics engine uses. It'd be neat to try drawing the differently colored components off-screen to RAM and brute force the cycling via blits.

                          Even on SCREEN 16 and loading 800x600 JPGs (120KB each, reduced from 16MP images, at 85% JPG quality. From this folder >> `https://drive.google.com/drive/folders/1WmbS29yyqVDfNWpTa41D7v0LidvmCvFO ) from the uSD card, we can get as fast or faster animations than a Genesis or SNES. Certainly it can be done from RAM and at an order of magnitude - or more - faster than pulling it across the uSD card. In the off chance that you might need some mountain images and such, those images are mine and you are free to use them as you wish. I have lots of pretty good images that I will pull over to that BASIC Engine assets folder soon, in full unadulterated quality, just in case anyone in the community can use something.

                          Do you know if there is a fixed address or an offset address for the start of video memory? VPEEK, VPOKE, and VREG are original BASIC Engine only, but would be awesome if implemented on the NG.

                          Sorry for rambling 🙂

                          Edit: I've brought a couple of my capture devices home. My apologies for the quality and sound on the videos above.

                              painintheworld That looks interesting. I wondered whether it would be possible to manipulate the palette of an image and make it fade in or out.
                              I like your image speed demos. It shows that it has more that enough speed for the sorts of programs I'm planning to write.

                                Fading out would be super easy. Not sure how the fade in would work. I reckon it could be split into tiles, use some sort of dithered replacement tiles, and PLOT MAP. That would be insanely fast, with the horsepower under the hood 🙂

                                If you were able to manipulate the palette associated with the image, then they could both be more or less the same.
                                Fade out would gradually change the colours towards whatever colour you wanted to fade to.
                                Fade in would need to keep track of the final palette of the image, and gradually change to values towards the final value.
                                Either way, you would probably backup the palette for the image and restore it when finished.
                                This thread should probably be moved into the BASIC Programming section.

                                Powered by: FreeFlarum.
                                (remove this footer)