PAX: Proposed application bundling and IO/Video autoconfig thing
Wuerfel_21
Posts: 5,054
in Propeller 2
Inspired by the parameter passing thread, I jotted down some ideas I had into this draft: https://gist.github.com/Wuerfel21/ff4efb3e824c2744e5fa6d48d50dc28b
Any feedback?
Comments
I'm all for getting some parameter passing going on, and some standard hub usage.
But sorry, this is so far over the top that I didn't even bother to read most of the info.
Have I missed something??
This isn't really about parameter passing, that's just an adjacent topic that inspired me to write my ideas down.
The idea here is basically to make it so I can take the SD card out of one P2 board and plug it into another board and have all the programs on it still work. (I think you had a thing like that going on P1 with your OS?) That means they need to get some info about pins and desired video output from some sort of loader/OS. Instead of choosing a fixed address to dump stuff at, I let the program specify where it wants what. That also lets me move some smarts into the loader (such as figuring out how to get a specific fixed resolution to display on whatever is connected). And to contain that metadata, the binary is packaged into something like a disk image alongside the manifest and whatever else it needs.
It may be conceptually clearer if you discuss this as a proposed layout of files on an SD card (which is what it really is) rather than as an executable distribution format. My first reaction was that ELF would be a better way to package binaries than FAT. Now that you've explained that what you really want to do is take an SD card from one P2 and run it on another P2, your proposal makes more sense.
One thing I would change is that I'd use UTF-8 for non-ASCII file names and/or data. It's a universal standard, and tools will handle it better than some non-standard encoding.
Another suggestion would be to use commas to seperate fields within the data files, as that would make it really easy to parse with BASIC. But that's a pretty minor issue, and probably Spin will be the main target language.
Well, it is an executable distribution format. The FAT-like (for it doesn't actually have a FAT) internal structure is to make it easy to switch between reading data from actual files (as you would for development, since uploading the entire PAX over serial every time may be slow if it contains graphics or music or smth) vs. files embedded into the PAX, as well as making it easier to parse in general.
But yes, I am indeed really bad at explaining things.
Well, the idea is to get a reasonable result when just dumping the data onto a VGA screen or serial or smth. The unicode escape is just a backdoor if you really need something that's not in the PST / P1 ROM font. And it's for user display strings only. All the actual identifiers are ASCII-only.
If it doesn't have a FAT then why use FAT like data structures? I'm a bit confused there. Wouldn't it be more useful to make this a FAT file system image that you can copy directly on to a card? I do understand wanting some restrictions (no fragmented or deleted files, simple directory structure, and so on).
As for UTF-8, the encoding of ASCII characters is trivial so you'll still get something sensible when dumping it to VGA or serial. It is slightly awkward that European characters (those above 128) are encoded in a slightly funny way, but it's easy enough to parse if you want to, and using UTF-8 gives you the option to use any language.
Well, I may have not gotten the point across. This happens to me a lot.
So you ever use a Mac? One of the things they do is put applications, binaries, metadata and all, into a DMG disk image, which is then stored as a file on the hard drive and mounted when the application runs. My PAX idea is basically the same thing, but with the filesystem inside the image simplified (a FAT is not needed if all files are implicitly linear and we never have to write into the image). I want to still use a FAT-like directory because it's really simple and editing existing FAT code to read files from inside a PAX image would be trivial.
Yeah, I guess decoding UTF-8 in there isn't to bad now that I think about it. Especially if I only care about those european characters (I have an ä in my name, I may be biased). Will change that I think.
Yes, I use the very same SD card in both P1 and P2 boards. Can boot either P1 or P2 code - that's why I use the .bix and .biy and .cmd in P2 and .bin and .cm2 in P1.
But your method sounds overly complicated. Why not just use a simple text file and parse it?
FWIW each CPM disk resides totally within an 8MB FAT32 file. The whole CPM FAT structure is within this disk file, as well as all the CPM programs. Is this something like you're after?
You might even want to consider resources that get loaded into external memory too at some point. Soon we should have quite a bit of external memory available on some platforms, either using HyperRAM/HyperFlash, or PSRAM also under development. If your intended applications ever makes use of those resources, a loader parsing this information in your header format may like to know and be able to control things so resources are put where they are intended and/or to setup mapping addresses and pins for memory devices etc. I know that still seems nebulous now so it can wait but this will be readily achievable on the P2 soon (HyperRAM is already going).
It is a simple text file, but inside a disk image of sorts, one per program. An image contains a
_BOOT_P2.BIX, which is the program and aMANIFEST.INI, which tells the OS/loader how to set up the program.Say you write a program that needs to know, say, the USB pins. You think it'd be convenient if the pin assignments were to be found at $7ABCD when the program is loaded. So you'd write a MANIFEST.INI like this:
and the loader would write the "Common IO" pin info structure at $7ABCD. If you don't need it, it wouldn't write it.
The video stuff is kindof complicated because the video capabilities on P2 are complicated...
I am of course thinking of that. That is why it says that an unrecognized attribute that does not begin with an underscore should lead to a load error - so new attributes can be added at will.
All my TAQOZ routines have runtime configuration so that I can change it arbitrarily or read fixed locations in "zero page" pertaining to the hardware. For instance, the SD FAT32 filesystem has a routine called SDPINS that accepts the a long specifying the 4 pins to use. But this can be changed dynamically as in the case of multiple SD card slots which I have on some systems. Of course I could also dedicate a slot to a cog as well. BTW, I normally play video and 44.1k wave audio at the same time from the same cog since the read speed is over 2MB/s at 200MHz and reading and viewing a 640x480x8 bmp file takes 100ms.
The VGA pins are in location $20 for instance and this is read at boot to configure the vga cog.
In this dump you can see 0302_0100 for the hsyn,red,green,blue, and then 04 for vsynch.