DCS7 Axiom
» >
»
» View previous topic :: View next topic  
As promised, it's time to work (and of course, get help) on the DCS7 axiom! Very Happy

(If you don't recall, it's part of the Axe GUI library, which will remain in development since DwarfWM is a shell, not quite a GUI library... unless I'm mistaken, anyways. The stance is to continue both the Axe GUI and this project, but under one roof!)

My assembly sucks, so I would really appreciate the help in making this Axiom! That said, let's get started! Very Happy

FOSS, as usual - the source is for the SPASM assembler, and can be found here: http://code.google.com/p/axe-gui-libraries/source/browse/src/dcs7axiom/DCSAxiom.z80


Code:
.nolist
#include "ti83plus.inc"
#include "Axe.inc"
#include "dcs7.inc"
.list

#define B_CALL(xxxx) rst 28h \ .dw xxxx

 .dw AXM_HEADER

 .dw Ax1_End
 .db AXM_ALL
 .dw tok_DrawL   ;DlgBox()
 .db AXM_INLINE
 .db AXM_1ARG
 .org 0
 ; OLD CODE:
 ; call OpenGUIStack
 ; ld hl,SmWinData
 ; ld de,SmWinDataEnd-SmWinData
 ; ld a,GUIRSmallWin
 
 ; OK, so let's first get stuff ready!

 ; Text is stored in HL already, no need to move it around!
 ; Save hl!
 push hl
 ; Now find the length of the string arg!
 call sub_Length

 ; Copy it to the correct place...
 ex de,hl
 
 ; Save DE as well, since the OpenGUIStack call will destroy that too.
 push de

 ; Open the GUI stack! This is done here to prevent a crash.
 ; BUG FIX - OpenGUIStack before "push hl" causes problems, since
 ; it destroys HL when called. Relocating it to a place where arg HL
 ; manipulation isn't needed fixes this bug (and the major crash).
 ; Thanks to KermMartian for the tip!
 call OpenGUIStack

 ; ...and bring back the string arg!
 pop hl
 ; ...and bring back the arg length as well!
 pop de
 ; Set window type!
 ld a,GUIRSmallWin
 
 ; Push the GUI!
 call PushGUIStack
 
 ; It looks like we need to use a macro to enable data retrieving from
 ; the labels inside the Axiom. (The REP_NEXT macro from Axe.inc, that
 ; is!) Thanks to calc84maniac for the nice catch! :D
 REP_NEXT
 
 ; Now, add the close button to the window.
 ld hl,winButtons
 ld de,dat_end-winButtons
 ld a,GUIRWinButtons
 call pushGUIStack

 ; Now, render the GUI and give control (mouse) to DCS!
 ld hl,0
 call GUIMouse

 ret

exitMyProg:
  call ResetAppPage
  ret
winButtons:
 .db 00100000b      ;only displaying a close button
 .dw 0              ;null pointer
 .dw 0              ;another null pointer
 .dw exitMyProg     ;we'll jump to exitMyProg when this button is clicked
dat_end:
Ax1_End:

 .dw AXM_END

.end


I'm basically testing out things at this point, and if successful, moving on to implement the API from there! Smile
Unfortunately, this isn't on the top of my todo list at the moment - piles and piles of HW and projects plague this week, and potentially next week, so I won't be as active. However, I'm am totally open to suggestions, and when I get a snip of time, implement such suggestions/fixes! Smile
So far it looks good, what can I offer in the way of advice to improve or continue the project? Or is this more a placeholder for now?
Somewhat of both. You see, the code doesn't quite work yet. Wink
Here are a few files:
= AXEDCSTE.8xp - the source of my "tester" program. Can be compiled with Axe 0.5.1 and above.
http://dl.dropbox.com/u/1016340/AxeDCSAxiom/files/AXEDCSTE.8Xp
= AXEDCSTS.8xp - compiled code, runs only on the DCS7 shell. This is standalone and does NOT need any support from any other program or appvar - just DCS7 and this. Smile
http://dl.dropbox.com/u/1016340/AxeDCSAxiom/files/AXEDCSTS.8Xp
= DCSAXIOM.8xv - the Axiom appvar.
http://dl.dropbox.com/u/1016340/AxeDCSAxiom/files/DCSAXIOM.8Xv
= DCSAXIOM.8xp - the Axiom program. Including the Axiom for the first time (first time meaning the appvar for the Axiom does not exist) will create the above Axiom appvar.
http://dl.dropbox.com/u/1016340/AxeDCSAxiom/files/DCSAxiom.8xp

If you are concerned about my silly menu contributing to the crash, here's some really quick sample code:

Code:
.AXETEST
#Axiom(DCSAXIOM)
"Hello, world!"->Str1
DrawL(Str1)

This compiles on Axe 0.5.1 and above.
To find this DrawL, Axe must have already loaded its hooks. If not, simply launch it and then exit it.
Press [VAR] [2] (Zoom) [4] (DrawL() to get it. (The original token is ZYmin.)

You may also add ClrDraw (clears the buffer) and ClrScreen (clears the screen) before DrawL.

I don't have a debugger on hand (wxWabbit doesn't exactly have a debugger yet, despite the misleading debugger directory and the almost empty CPP inside it Razz), and Wabbitemu needs debugging. Razz

Hopefully, your experiments and debugging will lead to a fix! Very Happy
I grabbed the latter three programs and ran them under Doors CS 7.2 Beta 1; after choosing the first option, I got "GUI Error: Need RAM". This means that the value you're passing PushGUIStack for the size of the item (namely the value of de) is larger than available RAM, or likely in the dozens of KB range. You have $A028 in DE and $0009 in HL instead of the reverse, and of course looking at your code, you push hl and de, then pop in the same order. Remember, it's a stack (LIFO, Last In, First Out), not a queue (First in, First Out, or FIFO), so the last think you push is the first thing you pop. Also, does Axe always generate such repetitive code? Shock
KermMartian wrote:
I grabbed the latter three programs and ran them under Doors CS 7.2 Beta 1; after choosing the first option, I got "GUI Error: Need RAM". This means that the value you're passing PushGUIStack for the size of the item (namely the value of de) is larger than available RAM, or likely in the dozens of KB range. You have $A028 in DE and $0009 in HL instead of the reverse, and of course looking at your code, you push hl and de, then pop in the same order. Remember, it's a stack (LIFO, Last In, First Out), not a queue (First in, First Out, or FIFO), so the last think you push is the first thing you pop.

Oops! Didn't know that was the case! I must've been thinking about Python/C/C++ arrays when I was writing this... Razz

Anyway, the code has changed from:


Code:
  ; ...and bring back the string arg!
 pop hl
 ; ...and bring back the arg length as well!
 pop de


...to:

Code:
 ; ...and bring back the arg length as well!
 pop de
 ; ...and bring back the string arg!
 pop hl


The result? It (almost) works!
A mouse shows up, and a window is created! Very Happy

But.... the window's title bar is blank, the window is positioned at the top right corner, and only a part of the little X button is seen. The window's contents is blank as well. The first part doesn't sound too bad, since I didn't specify a position nor title at all. However, the button and the blank window are issues. And, the infamous RAM clear occurs when you click that X or press [Clear].

The old URLs still apply, and have been updated with new files!
http://dl.dropbox.com/u/1016340/AxeDCSAxiom/files/DCSAXIOM.8Xv
http://dl.dropbox.com/u/1016340/AxeDCSAxiom/files/DCSAxiom.8xp
http://dl.dropbox.com/u/1016340/AxeDCSAxiom/files/AXEDCSTS.8Xp

Almost there! Very Happy

KermMartian wrote:
Also, does Axe always generate such repetitive code? Shock
It does. I've seen such code when I disassembled an 8Xp to convert to an 8Xk before Axe had the feature to compile to an app. Lots and lots of labels.... :/ I think it does ASM replacement, but I may be wrong. The only optimization I can see is with the routines that get put into the final program. I don't think it does any "serious" ASM optimization... yet. (Probably an Axe 2.0 thing Razz) It also depends heavily on OS calls, whether they are slow or buggy.
For what it's worth, I didn't think that even Axe 1.0 was available yet; isn't it around v0.5 or so? For the sake of simplicity, can you please extract and paste here the 9-byte contents that HL ends up pointing to?
KermMartian wrote:
For what it's worth, I didn't think that even Axe 1.0 was available yet; isn't it around v0.5 or so?
Yes, it's at 0.5.2 right now.
fx-CG10/84+SE user
JosJuice wrote:
KermMartian wrote:
For what it's worth, I didn't think that even Axe 1.0 was available yet; isn't it around v0.5 or so?
Yes, it's at 0.5.2 right now.
Fair enough, thanks for the clarification. Anyway, Alberthro, I'm still waiting for that nine-byte data chunk when you get a chance.
While I'm waiting for wxWabbitemu to get a debugger, I've switched to TilEm for debugging purposes.

How would I get the 9 byte contents that HL points to? Would I start debugging at "GUI Error: Need RAM"?

The debug window lists registers, with HL and HL' being shown.
Here's a screenshot for your convenience:
http://dl.dropbox.com/u/1016340/PublicPictures/TiLEM.png
Didn't fixing the de/hl switch fix the Need RAM thing?
KermMartian wrote:
Didn't fixing the de/hl switch fix the Need RAM thing?
Oops, looks like I used a wrong build! Razz

Trying again, and recompiling in the TilEm virtual calc, I get these terminal messages:

Code:
** executing in restricted RAM area **
** flash error (undefined command 82->07ca08 in read mode) **
** flash error (undefined command 80->07c9ff in read mode) **
** flash error (undefined command da->07c476 in read mode) **
** executing in restricted RAM area **
** flash error (undefined command 82->07ca08 in read mode) **
** flash error (undefined command 80->07c9ff in read mode) **
** flash error (undefined command da->07c476 in read mode) **
** executing in restricted RAM area **
** flash error (undefined command db->07c478 in read mode) **
** flash error (undefined command 06->07c479 in read mode) **
** flash error (undefined command e6->07c47a in read mode) **
** flash error (undefined command 7f->07c47b in read mode) **
** flash error (undefined command fe->07c47c in read mode) **
** flash error (undefined command 1f->07c47d in read mode) **
** flash error (undefined command 20->07c47e in read mode) **
** flash error (undefined command ec->07c47f in read mode) **
** flash error (undefined command db->07c480 in read mode) **
** executing in restricted RAM area **
** executing in restricted RAM area **

...repeating over and over again!

A picture:
http://dl.dropbox.com/u/1016340/PublicPictures/TilEm.png
So what's your current code? And once again, when you push, you're doing de=9 bytes, and hl=what 9 byte string?
The code is correct with the exchange being valid; I pass "Hello, world!" as an argument, which lands into HL, but as for what you want, I have no idea how to dump HL! Razz

I have the debugger open. In the registers panel, it says HL is A371 and HL' is 8440. Do I dump from the first location to the last? (A371-8440)
Nope. HL' is the shadow register of HL, exchanged with HL when you perform the exx instruction. HL is pointing to $A371, so I'm interested in the nine bytes at $A371, specifically the data that you're trying to push onto the stack.
Ahhh OK, thanks for the clarification.

Here's the hex dump (I think):

Code:
01 01 00 00 00 00 01 00 00


http://dl.dropbox.com/u/1016340/PublicPictures/TilEm2.png

Hopefully this is what you want! Smile
Is that what you want it to be? Is it a small window? If we take a look at http://www.dcs.cemetech.net/index.php?title=GUIRSmallWin , we see that would be at (1,1), with an icon of 0000000001 and a title string of 00,00. What I'm trying to ask is what data you're trying to push onto the GUI stack.
  
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
DCS7 Axiom
»
» View previous topic :: View next topic  
Page 1 of 1
» All times are UTC - 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