1. Thinking about it now, to allow for newer programs to run on older shells the size of a packet should be the second word included that way Walnut can skip past unfamiliar packets. Otherwise Walnut was going to rely on knowing the size of the packet based off the SDK version but that can now be fixed.

Good.

2. The SDK version number allows for Walnut to know which version of the packet layout is being used. Having an SDK version number higher than the shell number shouldn't prevent a program from running but may cause some errors in displaying data. The way each packet is arranged shouldn't change once Walnut is released so that is why I want to get all the issues out now by making this public.

I don't see how it would be necessary to know the version if the packet layout if the packets aren't going to change...

Also for the "wnut" that is just an identifier that the shell uses so it knows that the file was designed for Walnut and uses the Walnut packet layout. It is just like how java .class files start with 0xcafebabe as an identifier.

So if future shells want to have backwards compatibility with Walnut, would they need to include the wnut string? Wouldn't it be better to use something that doesn't refer to the name of this shell?

3. That can be moved easily to another packet but even if the developer doesn't want to include a description that field will only take 1 byte if blank. The description is like a subtext that can be displayed with the title.

Moving it to another packet makes the layout a bit more flexible. If everything is going to be put in the same packet, the advantage with the packet layout is not being used.

4. The reason for the checksum being there was that if there was a binary error in the header or executable then there is a possibility that the calculator could crash or even brick. For example if the FRQCR field was corrupted Don't forget that the SDK will calculate that on it's own when a project is built similar to what mkg3a already does.

But what if someone quickly wants to hack together a program without using the SDK? The file format is supposed to remove the limitations of the .g3a format, and the checksum is one of them.

5. A packet for main is also doable. The reason for having the offset was so that it could be quickly located and wouldn't have to be searched for.
6. Size of main just means the size of the executable. This is very important as it affects what Walnut will write to the MMU when the program begins.

This makes sense. I'm fine with having it the way it is now.

7. The first 4 letters could also be more like their initials. This data will never be displayed to the user but is so that Walnut has the ability to organize programs by author if the user wishes to do so.

Why can't authors be sorted based on their full name?

8. They don't have to include an icon. By setting the icon compression mode to 0 it means that there is no image and Walnut will not expect one.

Just like with 3., I think that splitting things up into multiple packets makes things more flexible.

PS3 equivalent: JosJuice
Wii equivalent: 5959 9095 3634 1960, 0989-5589-5105, 528548636740, 3996 3999 5504, 2578-3369-9618, 266389 118870, 0645-4377-4479, 4811-8393-9707, 1371-4285-7949, 532703 808230

Based on what you've written in this post as well as the reply to Kerm's post on Cemetech, it seems like you're losing quite a bit of the flexibility that Qwerty.55's format was going to have. You have identifiers for which shell the program is for, and even what version of the SDK it was made with... These don't really have a purpose, unless you plan to treat programs that are for different shells/made with different versions of the SDK in separate ways. This is bad, because then old versions of shells won't be able to read those new files!

On the 8x calcs, programs from old shells work in new shells, but not vice-versa. Sometimes someone might want to use an older shell because they like it better, but they won't be able to do that. If we design this format in a good way, we might be able to avoid that problem completely on the Prizm. Programs should be made for all Prizm shells - not a specific shell on the Prizm. The format that Qwerty.55 suggested allowed new shells to add new features in files by adding new packages, while still allowing the files to work correctly with older shells, unless the packet was "critical", as indicated by a list.

There are also a few things with the packets that you currently have that I would like to be changed. (It's a good idea to split your packets a bit so that you don't have everything in one packet!)

1. Unlike Qwerty.55's format, the size of the packets don't seem to be stored anywhere. How is the shell supposed to know where they end in cases where the size of the packet isn't obvious?
2. Like I said before, I don't see the point in storing the SDK version and the program's shell.
3. The description of the program shouldn't be in the critical packet, because it's not necessary to include a description for every program.
4. The checksum should also be optional. Don't place it in the critical packet.
5. It's better to indicate main() by giving it a packet ID. "file offset to main" shouldn't be necessary.
6. Does "size of main" have a purpose?
7. Why do we need to include the first four characters of the author's name?
8. Please don't require programmers to include an author icon if they don't include an author name. The icon should be a separate packet.
9. Why is the author's name stored twice, once before the icon and once after?

Relative dithering seems to be the best one, but absolute dithering also pretty decent.

Quote from: graphmastur on March 21, 2011, 01:14:36 pm

So, is this dead, or do you just have to make up 12 days?

4 months now

Hmm, I wonder if there are that many instructions...

Nice! I don't think can test it (as I don't have any .tns files, and I forgot to install Python on this computer), but I hope that it will be useful for others. Does this only work on 3.0.1-only files, or does it also support files that support 3.0.2?

Quote from: JosJuice on July 07, 2011, 07:35:53 am

Quote from: ephan on July 07, 2011, 06:21:40 am

Downgrading Pocket and emulating other calcs on it? Sweeeet, nice job BrandonW!

I don't think this allows us to emulate other calcs... You can't just take the boot code from another calc and expect it to work, because of all the small hardware differences.

Can't we emulate the 84+ and 83+ OSs?

The Pocket.fr is exactly like an 84+ hardware-wise, so you can just put the 84+ OS on it, and it'll work. The 83+ has some differences in hardware, plus the archive size is different, so it doesn't really work.

[14:31:45] * +geekbozu pokea thep
[14:31:48] <+geekbozu> *pokes a
[14:31:53] <+geekbozu> i run the code to set the jump
[14:31:58] <+OmnomIRC> (O)<thepenguin77> yes
[14:32:01] <+OmnomIRC> (O)* Freyaday jumps
[14:32:02] <+geekbozu> and it just spazzes and makes something else
[14:32:12] <+OmnomIRC> (O)<thepenguin77> lol, paste bin
[14:32:16] <+geekbozu> in the last few cases a jr <some random adress>
[14:32:31] <+OmnomIRC> (O)<thepenguin77> wait, was it a jr or a jp?
[14:32:38] <+OmnomIRC> (O)<thepenguin77> because jr would be hard to get right
[14:32:40] <+geekbozu> it was a jr in dissasembly
[14:32:51] <+OmnomIRC> (O)<thepenguin77> oh, pastebin
[14:32:52] <+geekbozu> but i put in C3 which should be a jp
[14:32:56] <+geekbozu> if your code was right
[14:33:01] <+OmnomIRC> (O)<thepenguin77> yes, it's right
[14:33:19] <+OmnomIRC> (O)<thepenguin77> it's probably getting overwritten by something
[14:33:44] <+OmnomIRC> (O)<calc84maniac> @z80 poop af
[14:33:44] <+Runer112> [Z80] ERROR \ Could not assemble: poop af
[14:33:50] <+geekbozu> http://pastebin.com/wxJhN2GT
[14:33:51] <+OmnomIRC> (O)<thepenguin77> hahahaha
[14:33:59] <+OmnomIRC> (O)<calc84maniac>
[14:34:04] <+OmnomIRC> (O)<thepenguin77> calc84, that always makes my day when I do that by accident
[14:34:14] <+OmnomIRC> (O)<calc84maniac> yeah, I did it by accident in my code just now
[14:34:17] <+OmnomIRC> (O)<thepenguin77> come on geekboy lol
[14:34:23] <+OmnomIRC> (O)<calc84maniac> the @z80 was on purpose
[14:34:25] * +geekbozu is a tart
[14:34:32] <+OmnomIRC> (O)<thepenguin77> ld a, $C3, not the value at ($C3)
[14:34:34] <+Runer112> I don't think I've ever typed poop instead of poo
[14:34:36] <+Runer112> pop*
[14:34:37] <+Runer112> lol
[14:34:44] <+geekbozu> oh wow
[14:34:44] <+Runer112> as I was about to say
[14:34:46] * +geekbozu facepalms
[14:34:49] <+Runer112> I do mistype it as poo =p