Page 12 of 13

Re: New bootloader

Posted: Thu May 09, 2019 2:13 am
by Janka
Maybe he could do an image of the first megabyte of the card with dd and upload it somewhere?

Code: Select all

$ diskutil umountDisk /dev/disk2
$ dd if=/dev/disk2 of=image.dd bs=1m count=1

Re: New bootloader

Posted: Thu May 09, 2019 12:38 pm
by rv6502
The first megabyte might contain nothing as partitioning can leave the first 4MB unused by default (other than writing the MBR).

They do this for flash erase block alignment.

You have to force it to use no padding using the command line partitioning utility in Linux (not sure if you can in OSX), format it, then let OSX put the hidden trash entries for the finder metadata.

To get the first partition properly it would be /dev/disk?s1
Which one depends on the system. My macbook at work has /dev/disk0 as system disk and whatever I plug in first shows up as disk1

I'll try to make an tiny image tonight, or this weekend. After I confirm garbage entries shows up on the Uzebox.

Re: New bootloader

Posted: Thu May 09, 2019 7:58 pm
by Jubatian
Thank you, I thought about asking for a disk dump myself, but realized the same quickly, it may need an unreasonably large dump to have a good chance of getting the root directory data in it.

Re: New bootloader

Posted: Fri May 10, 2019 12:00 am
by rv6502
I looked at a USB drive today and OSX puts a bunch of dot-files with the same name as the dos files.

eg:

Code: Select all

autoexec.bat
.autoexec.bat
.config.sys
config.sys
God forbid you want to make a boot SD/USB stick for a dumb embedded system using OSX ...

Re: New bootloader

Posted: Fri May 10, 2019 1:45 am
by rv6502
Jubatian wrote:
Thu May 09, 2019 7:58 pm
Thank you, I thought about asking for a disk dump myself, but realized the same quickly, it may need an unreasonably large dump to have a good chance of getting the root directory data in it.
fdisk wouldn't let me start the partition at "sector" 63 but whatever, I nulled the SD card (TAKE THAT, WRITE CYCLES! NO 0xFF FOR YOU) so it compresses well.

Created a 1MB VFAT partition starting at 1MB and dumped an extra 1MB after.

Incidently posix really needs to add a /dev/twohundredfiftyfive or /dev/minusone to clear flash memory nicely :D
Screenshot_2019-05-09_21-19-16.png
Screenshot_2019-05-09_21-19-16.png (58.52 KiB) Viewed 3021 times
IMG_20190509_212837.jpg
IMG_20190509_212837.jpg (43.75 KiB) Viewed 3021 times
OSX_SD.IMG.bz2
(116.22 KiB) Downloaded 87 times
The image is 3MB of mostly zeroes.

OSX creates those dot file after any GUI program opens the file.

Just copying them using the Finder doesn't create the dot files. You have to open them from some program (like an emulator or a hex editor) for the dot files to be generated by OSX.

Re: New bootloader

Posted: Fri May 10, 2019 3:14 am
by Janka
My wild guess is those ._ files are the resource streams. FAT does not support multiple streams per file but MacOS wants to store some metadata along which each file so it creates that crap. I also found it in archives made on Macs.

Simply ignoring dotfiles should help. How do we do that in 3 byte?

Re: New bootloader

Posted: Fri May 10, 2019 7:03 pm
by Jubatian
rv6502 wrote:
Fri May 10, 2019 1:45 am
fdisk wouldn't let me start the partition at "sector" 63 but whatever, I nulled the SD card (TAKE THAT, WRITE CYCLES! NO 0xFF FOR YOU) so it compresses well.
Thank you! Finally a bit of good old productive bugfixing :)
Janka wrote:
Fri May 10, 2019 3:14 am
Simply ignoring dotfiles should help. How do we do that in 3 byte?
Eh, I almost managed it. I hope the attached version fixes the problem, by what I see, it should. But it took 4 bytes :( . But I still have 4 bytes free for something awesome :D

I checked the disk dump, how the actual FAT16 names look like, what I found is that they all begin with underscore. I guess if it was only a dot in the long filename, there would be no way to tell by FAT16 name whether the file was junk or not, but thankfully there is that underscore there too. It is true there could be valid UZEs beginning with an underscore, but I feel it rather unlikely someone ever found it cool to name his game "____.uze".

Anyway, so the fix is just adding another filtering condition for an underscore as the first character of the filename.

Please check it out, if it works, I will commit it.

Re: New bootloader

Posted: Sat May 11, 2019 12:52 am
by rv6502
I tried it.
Seems to work.
The OSX entries aren't showing and I loaded a few games.

Re: New bootloader

Posted: Sat May 11, 2019 7:20 am
by Artcfox
The filter is just for .uze files correct? I ask because some games use _HISCORE.DAT as a data file.

Re: New bootloader

Posted: Sat May 11, 2019 8:01 am
by Jubatian
Artcfox wrote:
Sat May 11, 2019 7:20 am
The filter is just for .uze files correct? I ask because some games use _HISCORE.DAT as a data file.
It doesn't affect games anyhow, not even those which would use the bootloader interface for SD, it is just the game selector's filter determining from which files it assembles the game list. This filter was already designed so it skips every non-game file, so you can have up to 255 games on one card (regardless of how many extra files or long filename entries or whatever else might reside on it).
rv6502 wrote:
Sat May 11, 2019 12:52 am
Seems to work.
The OSX entries aren't showing and I loaded a few games.
Then it works, after all, it is only a compare and a conditional branch within the filename filter among the rest. I am committing this to master then. Thank you for giving it a go!

EDIT: I committed and updated the top post with the new version.

Janka: I tried out the MMC patched version, however for some reason it behaves really odd (at least in the emulator). It works, but really slow, at the moment I have no idea why (this happens even when I use the hex you provided). I wanted to add the patch to the master repo so it existed as an option directly to build with MMC instead of SDHC, but first this will have to be resolved (I will look into it myself).