BrandonW wrote:
I couldn't speculate because I don't know what the drive is doing internally, I can just tell you that it chokes on a sector write command.
I could swear it took more voltage (via a charge pump, so therefore more current) to erase than to write, but a few minutes of researching didn't turn up a solid comparison.
@Brandon Would it be possible to get right/secondary click to pass 15 to getKey? And maybe even up/down arrow or +/- for scroll up/down? B/c it would be epic if you could get a mouse to take full advantage of the DCS homescreen... plus, I would love to write programs that work well with a mouse.
rthprog wrote:
@Brandon Would it be possible to get right/secondary click to pass 15 to getKey? And maybe even up/down arrow or +/- for scroll up/down? B/c it would be epic if you could get a mouse to take full advantage of the DCS homescreen... plus, I would love to write programs that work well with a mouse.
Since he's making an SE, he could do that by in quick succession setting the X, then Y coordinates, then clicking, so it would definitely be useable.
I'm not following, what does getKey have to do with anything?
BrandonW wrote:
I'm not following, what does getKey have to do with anything?
He's just misunderstanding how Shell Expansions work. Smile Do what I said instead?
Except I don't get what you're suggesting either.
BrandonW wrote:
Except I don't get what you're suggesting either.
In order to click on the scroll up or scroll down buttons, I'm suggesting returning d three times in successive iterations, using one of your two safeRAM bytes to signal where you are in the sequence. You'll need to return d once to set the x, again to set the y, and a third time to click.
I see, you were talking about scrolling up and down.
BrandonW wrote:
I see, you were talking about scrolling up and down.
Indeed. An alternative is to take advantage of the fact that I said I'm not going to move MseX and MseY, and just adjust the cursor yourself and then return d to click, but I don't like that quite as much Smile
I have two requests for additions/modifications to DoorsCS, Kerm:

1. You said I wouldn't be able to use certain parts of the DoorsCS GUI because the shell expansion would try to recurse while I was trying to bring up a dialog (or something to that effect). Would this be easily solved by having a flag in memory that I can set/reset to enable/disable loading and execution of the shell expansions?

2. Would it be possible for you to load the name of the currently-executing shell expansion into memory (for example into OP1 or progToEdit or something) when executing SEBoot? So that I'm aware of my own name, should it ever get renamed, and I can consistently look myself up for stuff.
BrandonW wrote:
I have two requests for additions/modifications to DoorsCS, Kerm:

1. You said I wouldn't be able to use certain parts of the DoorsCS GUI because the shell expansion would try to recurse while I was trying to bring up a dialog (or something to that effect). Would this be easily solved by having a flag in memory that I can set/reset to enable/disable loading and execution of the shell expansions?
Actually, the problem is that loading up the GUI system when Doors CS isn't expecting it (ie, in an SE) will almost definitely make it crash and burn when your SE returns. We *might* be able to figure out a way for you to collapse the stack and jump to the beginning of the DCS App, but I'm not sure, and that sounds super-hacky.

Quote:
2. Would it be possible for you to load the name of the currently-executing shell expansion into memory (for example into OP1 or progToEdit or something) when executing SEBoot? So that I'm aware of my own name, should it ever get renamed, and I can consistently look myself up for stuff.
Hmm, that might be difficult. I'll think about how I could implement that.
Progress update: in addition to what's in the video, it now shows a configuration screen when you middle-click allowing for adjusting sensitivity of X direction, Y direction, and the scroll wheel, which automatically clicks up and down on the DoorsCS scrollbar when you scroll the wheel.

It also has the beginnings of support for "gestures", which is really just moving the mouse to any of the 4 corners, which will let you run a program or FLASH application. (Circular motions and so on are difficult and just beyond what I want to put into this.)

Kerm, does runprog work now? If I swap in the base page of DoorsCS (or whichever page it's on), can I call it directly as if I were a MirageOS program? I don't need to regain control after calling it. And if so, could you store the name of the FLASH application (or the page containing the MirageOS jump table) somewhere so I'm not hard-coding "DoorsCS7" or anything?
BrandonW wrote:
Progress update: in addition to what's in the video, it now shows a configuration screen when you middle-click allowing for adjusting sensitivity of X direction, Y direction, and the scroll wheel, which automatically clicks up and down on the DoorsCS scrollbar when you scroll the wheel.
That's epic! And nothing fails from using the GUI in the middle of the desktop?

BrandonW wrote:
It also has the beginnings of support for "gestures", which is really just moving the mouse to any of the 4 corners, which will let you run a program or FLASH application. (Circular motions and so on are difficult and just beyond what I want to put into this.)
That makes sense.

BrandonW wrote:
Kerm, does runprog work now? If I swap in the base page of DoorsCS (or whichever page it's on), can I call it directly as if I were a MirageOS program? I don't need to regain control after calling it. And if so, could you store the name of the FLASH application (or the page containing the MirageOS jump table) somewhere so I'm not hard-coding "DoorsCS7" or anything?
RunProg works beautifully now. You can use Doors CS' RunProg just like MirageOS's, except that it of course supports more filetypes and functionality, such as AP files. Since your SE is getting called from Doors CS, and specifically from the base page (by design), why not just read port 6?
KermMartian wrote:
BrandonW wrote:
Progress update: in addition to what's in the video, it now shows a configuration screen when you middle-click allowing for adjusting sensitivity of X direction, Y direction, and the scroll wheel, which automatically clicks up and down on the DoorsCS scrollbar when you scroll the wheel.
That's epic! And nothing fails from using the GUI in the middle of the desktop?


I'm currently having an issue with the configuration screen, which I think is related to my dynamic loading of SE sections.

KermMartian wrote:
BrandonW wrote:
It also has the beginnings of support for "gestures", which is really just moving the mouse to any of the 4 corners, which will let you run a program or FLASH application. (Circular motions and so on are difficult and just beyond what I want to put into this.)
That makes sense.

BrandonW wrote:
Kerm, does runprog work now? If I swap in the base page of DoorsCS (or whichever page it's on), can I call it directly as if I were a MirageOS program? I don't need to regain control after calling it. And if so, could you store the name of the FLASH application (or the page containing the MirageOS jump table) somewhere so I'm not hard-coding "DoorsCS7" or anything?
RunProg works beautifully now. You can use Doors CS' RunProg just like MirageOS's, except that it of course supports more filetypes and functionality, such as AP files. Since your SE is getting called from Doors CS, and specifically from the base page (by design), why not just read port 6?


I could, now that you've confirmed that's where it is.

Would you recommend running a FLASH application from within an SE? Is there clean-up that you must do first before giving up control to me (and before I give up control to the application)? If so, it could be modified to go into your _PutAway vector, which _ExecuteApp will eventually trigger.
BrandonW wrote:
Would you recommend running a FLASH application from within an SE? Is there clean-up that you must do first before giving up control to me (and before I give up control to the application)? If so, it could be modified to go into your _PutAway vector, which _ExecuteApp will eventually trigger.
If you could sufficiently clean the stack, make the SE put Doors CS back into Bank 1 after you run the other app, and then start it over, then I see no problems with brutally stealing control from it. If that's infeasible, then the main problems would be with hooks like the GetCSC hook and the Parser hook being disabled, since Doors CS wouldn't have gotten a chance to re-enable them on exit.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 2 of 2
» All times are GMT - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement