Many people have been trying to convince you to do that for a while.

Another thought how hard would it be to allow of custom UI's like MOS, then you could save some space by having a stripped down on as the main one and have the current one be an extention? I mean finishing RunProg should make that piss easy now that I think about it.

Eh, I really don't think that should be a priority. I really don't take a ton of space with the GUI, other than the GUI API itself. Doors CS's desktop relies on so much of that that on its own it takes negligible memory.

Just based on other things I've read, the problem with that is the way the application is structured. It might make sense to just rip out the GUI or rip out the runprog-like functionality, but it's all kinda integrated and not as easy as it might seem to us.

Just giving Kerm the benefit of the doubt here.

Why modify the VAT entries manually when you can just modify the RAM-based one and archive it?

The man speaks truth. Besides which, making your own DCS-friendly desktop frontend should be absurdly easy with runprog.

Because no one wants to unarchive and re-archive hundreds of programs they already have oncalc just to change the folder...it would be much nicer to click a button and it's done for you.

I meant automatically.

We're talking about ones that are already archived. Unarchiving, modifying, and re-archiving every variable would be an absolute nightmare and you'd be constantly garbage collecting. It's far better on the Flash chip to go the other way.

Calc84, there's no master archived VAT, so you need to unarchive and rearchive each program that gets put into a folder to save its folder designation.

I know...

So how is that better than having a process that goes through and fixes the archived copies directly?

That sounds good in theory, but it's pretty much impossible. That byte, by default is 0. There are no set bits to erase.

I successfully separated DetectType routine from VATProcessEntry routine, which itself has been separated from VATFind. DetectType now takes the address of a VAT entry in hl and returns the program's typemask in a and a pointer to a 16x16 icon in ix. a=$ff indicates the specified program is either hidden to DCS or invalid. This clears the way for the two most immediate items on my ToDo list:

:: Enhance RunProg to only take the address of a program's VAT entry as its input and deduce everything else necessary
:: Implement the RunProg vector.

Interestingly enough, I still have the space constraints listed below, although I have already added and implemented a third (empty) page:


Code:


1.4KB is already taken up by the vector table on page 3 as well as the skeletal ion library I have on each page for swift access to those routines without cross-page calling. After I finish the two items above, my next-most-pressing ToDo items:

:: Homescreen parser hook implementation to call RunProg
:: Chaining, if necessary?
:: Research and list all routines necessary for Celtic III and xLib emulation. Figure out what code can be reused and what needs to be written from scratch.
:: Implement BASIC interface to DCS GUI system

Oooh, the finishing of RunProg would allow for msd8x to be recompiled to use Doors instead of Mirage, or more interestingly, would allow me to actually finish ADRIVE and implement USB drive browsing directly into the Doors desktop.

Ah, you missed the thread or post where BrandonW said he would update MSD8x to look for any shell with a valid RunProg vector and use that. And yes, you should totally finish ADRIVE. Actually, this means that the major obstacles to making RunProg work are done. The hardest part will be faking any necessary initialization like verifying the presence and integrity of the DCS6->7 appvar.

Oooh, excellent. I assume this means there would be a preference for it in case someone has both Doors and Mirage or a similar combo? Or will it just be a matter of alphabetic precedence?


On that note, DetectType should also make that task significantly easier What are the other possible values of a? Actually, hmm, I assume I'd have to copy the program (or at least it's header) to RAM temporarily and create a VAT entry for it, and then call DetectType on the temp program for each program I wanted to display with ADRIVE? Might you be able to create a similar routine that would just take the address of the beginning of program data?

I suppose that's doable, although it would have to make certain assumptions, such as that the program exists in RAM and enough of it is copied such that any fields referenced in the header also exist in RAM. Here's a listing of how the flag mask works:


Code:

Only unarchived programs work, and it's still got plenty of bugs, but woohoo!

nice work! Does it open APs as well (or should I just have watched the screenshot all the way through?)

Running a file doesn't seem to work right, although I'm not sure why. I'm working on it.