KermMartian wrote:
Luckily, thanks to some forethought (plus, actually, a lot of your help in needing features in the GUIMouse routine for iPaint), almost every weird feature like mid-mouse hooks and such already exists in the GUIMouse routine. \o/
hehe, I also remember banging out lots of weirdnesses in the GUI system when I was still developing strategic conquest.
elfprince13 wrote:
KermMartian wrote:
Luckily, thanks to some forethought (plus, actually, a lot of your help in needing features in the GUIMouse routine for iPaint), almost every weird feature like mid-mouse hooks and such already exists in the GUIMouse routine. \o/
hehe, I also remember banging out lots of weirdnesses in the GUI system when I was still developing strategic conquest. True story, thanks for that.
Converted the Properties menu to the GUIMouse system. Memory stats (before Desktop conversion, and now):
Code: Page 0 is 15156 bytes long (1228 bytes to spare)
Page 1 is 15763 bytes long (621 bytes to spare)
Page 2 is 1576 bytes long (14808 bytes to spare)
Page 0 is 15223 bytes long (1161 bytes to spare)
Page 1 is 15981 bytes long (403 bytes to spare)
Page 2 is 1576 bytes long (14808 bytes to spare)
So I've lost 67 bytes on Page 0 and 218 bytes of Page 1. Time to move all the mouse hook stuff into a GUIMouse hook and remove the 1.3K behemoth that is MainMouse.
Woot, nice consolidation.
elfprince13 wrote:
Woot, nice consolidation.
Thanks. It looks like in the end all I'm going to actually be able to save from MainMouse is about 500 bytes, perhaps even less since I plan to integrate TabFuncs directly.
Edit: Partial mouse stuff completed. Working on figuring out how to implement some stuff that's a bit of a headscratcher, specifically keys written out by Shell Expansions. I ended up removing the VatSwap routine that's part of the Mirage OS libraries; I see no need to keep that (it's only really useful for program sorting), and it was taking a good 300 bytes. Not to mention my alphasort already implements a VatSwap.
Code: Page 0 is 14513 bytes long (1871 bytes to spare)
Page 1 is 15882 bytes long (502 bytes to spare)
Page 2 is 1572 bytes long (14812 bytes to spare)
Edit #2: Also, I changed the app name to "DoorsCS7" and the appvar names to "DCS7" and "DCS7b" from "DCS6" and "DCS6b".
KermMartian (which I just realized is martian as in from Mars, not Mar-ti-ahn) wrote:
Edit #2: Also, I changed the app name to "DoorsCS7" and the appvar names to "DCS7" and "DCS7b" from "DCS6" and "DCS6b".
I thought that woulda been the first thing you'd do, unless you really were gonna make a 2-page 6.3 for those who didn't want a 3rd page.
Xeno_Cre8or wrote:
KermMartian (which I just realized is martian as in from Mars, not Mar-ti-ahn) wrote:
Edit #2: Also, I changed the app name to "DoorsCS7" and the appvar names to "DCS7" and "DCS7b" from "DCS6" and "DCS6b".
I thought that woulda been the first thing you'd do, unless you really were gonna make a 2-page 6.3 for those who didn't want a 3<sup>rd</sup> page. You'd be wrong; I started with some functional improvements and memory optimizations instead of the name.
Anyway, finish converting all the hotkey stuff into the GUIMouse system for the desktop. The [1][2][3][4][5][6], [+][-], [F1], [F2], and [CLEAR] hotkeys all work now. Next I need to figure out how to jimmy the InfoPop and MemoryPop functions into the GUIMouse.
Code: Page 0 is 14466 bytes long (1918 bytes to spare)
Page 1 is 15917 bytes long (467 bytes to spare)
Page 2 is 1572 bytes long (14812 bytes to spare)
By Info Pops, I assume you refer to the feature in Windows that brings up the little info window when you hover the cursor over an icon, etc.?
That would be a nice implement.
me2labs wrote:
By Info Pops, I assume you refer to the feature in Windows that brings up the little info window when you hover the cursor over an icon, etc.?
That would be a nice implement.
Yup, that's what I'm talking about, but it was implemented in May 2008. Check out the article:
http://www.cemetech.net/news.php?year=2008&month=5&id=331
I know its been said that applications can't have writeback, but in the process of trying to lookup how the TI's archive works, I wiki-ed this BCALL...
Quote:
Official Name: WriteFlash
BCALL Address: 80C9
Writes data to Flash, but prevent writing to page 1E.
Inputs
* A = Flash page to write
* DE = address to write
* BC = number of bytes to write
* HL = source address, must be in RAM
Outputs
* NZ if the byte could not be written
Destroys
* AF, DE, BC, HL
Comments
Flash must be write enabled first.
Note that you cannot use this to write a 1 bit over a 0.
To write to page 1E, use WriteFlashUnsafe.
and in interest, also wiki-ed this...
Quote:
Port Number: 14h
Function: Flash Write-Lock Control
This port controls whether or not the Flash ROM chip will accept write/erase instructions.
Read Values
* 83+ Basic only: Reads absolutely nothing of any significance.
* 83+ SE/84+ only: Reads 0 if the flash is locked, 1 if the flash is unlocked.
Write Values
* Write 00h to lock the flash. Write 01h to unlock it, but note that writes to this port are only accepted from privileged ROM pages. See Comments for what the privileged pages are.
considering you could locate an apps base page, could it be slightly possible to have writeback? That is, not considering a change in app size...
Err, well, yes. Maybe. I'm not sure. It's not a very clever idea to write to locked parts of flash.
Quote:
Note that you cannot use this to write a 1 bit over a 0.
This makes writeback incredibly limited.
xenonparadox wrote:
considering you could locate an apps base page, could it be slightly possible to have writeback? That is, not considering a change in app size...
You can only flip the bits one way in Flash.
elfprince13 wrote:
xenonparadox wrote:
considering you could locate an apps base page, could it be slightly possible to have writeback? That is, not considering a change in app size...
You can only flip the bits one way in Flash. Translation: in order to write a zero on a Flash page, you have to erase the entire page, then rewrite it without a one on the place where you now want a zero.
If I may post a request, I would like SEs to support modifying the desktop, so that a GNOME type interface may be implemented, for instance. Also, multiple desktops? You don't neccisarrily need multiple windows at once, but maybe you could have one window per desktop, and allow users to split icons up amongst their desktops?
SirCmpwn wrote:
If I may post a request, I would like SEs to support modifying the desktop, so that a GNOME type interface may be implemented, for instance. Also, multiple desktops? You don't neccisarrily need multiple windows at once, but maybe you could have one window per desktop, and allow users to split icons up amongst their desktops?
SirCmpwn WTF do you mean by gnome type? As for the multi desktop, its impractical and the page by page scrolling is basically the same thing. Seriously think about what you are saying before you talk. DCS uses a mouse based GUI just like Windows and X11, you can't make a calculator any more "gnome" like that that other than to put the logo in the background.
Edit: dang typos.
TheStorm wrote:
SirCmpwn wrote:
If I may post a request, I would like SEs to support modifying the desktop, so that a GNOME type interface may be implemented, for instance. Also, multiple desktops? You don't neccisarrily need multiple windows at once, but maybe you could have one window per desktop, and allow users to split icons up amongst their desktops?
SirCmpwn WTF do you mean by gnome type? as for the multi desktop, its impractical and the page by page scrolling is basically the same thing. seriously think about what you are saying before you talk. DCS uses a mouse based GUI just like Windows and X11, you can't make a calculator any more "gnome" like that that other than to put the logo in the background. Yeah, this sounds about right. I'm barely hitting 2KB of free ROM on page 0, so I'm trying to be conservation with new, memory-intensive features.
Do you get what I mean by the TabFunc being seperate from the cursor?
The best way I can describe it is that there are two cursors:
1.) the one controlled by the arrow keys and [2nd], which can move anywhere on screen
2.) the TabFunc one; invisible unless in use; controlled by [F3], [F4], and [ENTER]; basically a 16x16 box (when over a program) that's inverted.
I'll try to get a "screenshot" of what I mean
[EDIT:]
in this screenshot, pressing [ENTER] would run iPaint, but pressing [2nd] would run WorldDom. [F3] would move the square over Paper, [F4] over the Start bar.
[/EDIT]
@Xeno_Cre8or
I'll vote for that.
Xeno, interesting, I'll see if I decide to do something like that when I reimplement TabFuncs after finishing fixing MemoryPop/InfoPop and the SE executionness.
I just finished reimplementing MemoryPop and InfoPop, but there's some kind of bug I need to trace. In addition, I added a new feature to save and restore the last GUIMouse location across a usage of the Hook trick to make the GUIMouse think the user clicked somewhere. This means that if you move the mouse to the upper-right of the DCS desktop, then press [F1] (the DCS Menu shortcut key), the mouse cursor will remain at upper-right instead of now being centered over the DCS Menu button.
I actually like that, and the thought of something similar has crossed my mind in the past. I'd give my vote for that as well.
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
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