[thunderstruck]

Hey everyone,

I wrote a simple Padder to support the new bigger carts. It’s a commandline tool but you can just drag and drop your vb file onto the Padder.exe as well.

I used .Net Core 2.1 this time which allowed me to create a linux and mac version. I’m not sure if this works for everyone but in theory it should. If someone can try these out, that would be great.

Edit: the gif preview on planetvb seems to be broken but you can watch it but clicking on the gif.

• This topic was modified 6 years, 2 months ago by thunderstruck.

Attachments:

1. 

   padder.gif
   

1. padder.linux-x64.zip
2. padder.osx-x64.zip
3. padder.win-x64.zip
4. padder.src_.zip

Thank you sir!!!

Not that I have a problem with it, but I don’t see why this program was necessary. The existing padding tools (DogP’s and mine – which I made around the same time as the ROM shrinker, but doesn’t seem to be hosted on PVB) have both always supported padding to theoretically any “power-of-two” size (limited, of course, by RAM and HDD space, among other things).

I just did a test with mine (which is attached), and I was able to pad to 128MB (16Mbit) and 512MB (64Mbit) easily. I even used my shrinker to automatically reduce the 128MB to 64MB. I started with a 128KB ROM.

Run the tool by itself to see how to use it. For reference, passing a value of 27 results in a 256MB ROM (adding one will double the size, subtracting one will halve it, and so on). Passing no number (e.g. dropping the ROM on the executable) should automatically pad the ROM to the next power-of-two size.

The source is included with both programs (the shrinker is here on the site), and they should, in theory, also be cross-platform, since they use the C standard library.

Attachments:

1. padromvb.zip

RunnerPack wrote:
Not that I have a problem with it, but I don’t see why this program was necessary. The existing padding tools (DogP’s and mine – which I made around the same time as the ROM shrinker, but doesn’t seem to be hosted on PVB) have both always supported padding to theoretically any “power-of-two” size (limited, of course, by RAM and HDD space, among other things).

Haha, I actually didn’t know that. I wrote this in half a hour while being on a boring conference call. Some people asked for it as well. I think it would be best to have the padding as part of the programmer firmeware.

RunnerPack wrote:
I just did a test with mine (which is attached), and I was able to pad to 128MB (16Mbit) and 512MB (64Mbit) easily. I even used my shrinker to automatically reduce the 128MB to 64MB. I started with a 128KB ROM.

I keep confusing this but I think 16 Megabit are 2 Megabyte. 64 Megabit would be 8 Megabyte.

RunnerPack wrote:
Run the tool by itself to see how to use it. For reference, passing a value of 27 results in a 256MB ROM (adding one will double the size, subtracting one will halve it, and so on). Passing no number (e.g. dropping the ROM on the executable) should automatically pad the ROM to the next power-of-two size.

I only added output options for 16, 32, 64, 128 and 256 to not confuse people. The code is simple enough to support other sizes though.

RunnerPack wrote:
The source is included with both programs (the shrinker is here on the site), and they should, in theory, also be cross-platform, since they use the C standard library.

I’m really impressed by what Microsoft is doing with c#. Asp.net and the core for console applications is now open source and can be compiled to other systems then windows. With 3.0 they want to include WPF which means my GUIs could be compiled for Mac.

Not sure why your padder was not on the site yet, RunnerPack, but I just added both yours and thunderstruck’s to the database.

[RunnerPack]

KR155E wrote:
Not sure why your padder was not on the site yet, RunnerPack, but I just added both yours and thunderstruck’s to the database.

Thanks, KR155E!

thunderstruck wrote:

I think it would be best to have the padding as part of the programmer firmware.

That’s a good idea. It would minimize the data sent down the wire (or space on the SD card). Supporting compression would be even nicer, perhaps using LZO or LZ4.

thunderstruck also wrote:

I keep confusing this but I think 16 Megabit are 2 Megabyte. 64 Megabit would be 8 Megabyte.

You’re right, of course… I divided when I should have multiplied (or vice versa).

Anyway, nice work on the padder. It’s a great way to use otherwise-wasted meeting time 🙂

• This reply was modified 6 years, 2 months ago by RunnerPack.
• This reply was modified 6 years, 2 months ago by RunnerPack.

Maybe I’ve been using the wrong padder this whole time. I have one thats called Pad_VB.exe and it won’t pad up to 256Mbit on my machine. Says padding size is too large.

I was using Python the pad the files before burning them.

I’ve tried using all 3 and can’t get any of them to work that are on the site and it’s maddening.

The one in this thread spits up some garbage about missing files.

The other two if you do as it says and use the default (21) to get a 16mbit file (for flashboy sizes) it acts like it does, no error, but back to a prompt and no file.

I don’t see why this has to be complicated but it is. I’m just trying to pad out that file for the english translated Innsmouth Mansion and would like to get it going for other odd files from the demo world and so forth.