Does anyone know if writing to archive is bad for the memory? I have heard that repeatedly writing to archive will eventually damage it.
Over a long period of time, yes. Flash memory will eventually start failing to hold data after a lot of writes have been performed. For a calculator, I'm going to make a very rough guess of 10,000 garbage collects, although it could easily be off by a factor of 10 in either direction.
On a different subject, how do programs like Doors find the names of all the programs (and how can I do that in Axe)?
This is done by scanning the Variable Allocation Table (VAT). This can be done in pure Axe, as demonstrated in this brief tutorial. However, it's easier to use an Axiom for this, of which there are two. One is bundled in the Axe download under Tools\MemKit, and another can be grabbed here. The latter is nicer in that it produces results alphabetically, although it does so with the same OS calls used to do things like populate the program menu so it could potentially be rather slow with a lot of variables.
After ten minutes of searching (probably in all the wrong places) I can't seem to find a keyhook axiom. Do you know of any good ones?
If such an Axiom existed, I would've suggested it in my earlier response. So if you wanted to create any hooks, you'd have to provide your own assembly backing for it.
SMC generally means modifying the currently-running executable, which is different from the source code. So even if you did this, the results would not be visible later. Simply displaying information like this is the easiest (and the sane) way to go.
I am writing a program to restore some of my files (after RAM clear thanks to zStart) and I am using the copy command.
I'm skeptical that zStart would actually cause a RAM clear unless it was abused a bit... but anyways, you should really keep all your source code archived to keep it safe, since zStart lets you edit archived programs.
Does the size command {pointer-2} not work of files? It works fine if I just manually input the size but otherwise it just copy's one bite.
As far as I know, that works for files. Make sure you're reading a 2-byte value by appending r to the closing brace. If this isn't the issue, I can't immediately offer any ideas to fix it.
On a different subject is there a way to run already compiled programs (including the ability to call subroutines) to bypass the compiled code limit? I know about axioms to circumvent this need but I would like to not have to use them.
I know you said you'd like not to use Axioms, but there's really no easy way to do what you're specifying without one. Specifically, the RunPrgm Axiom lets you run external assembly programs. If you wanted to run specific subroutines, you'd need to create your own convention, but that shouldn't actually be that hard.
But before turning to this, there may be a few less radical ways to solve this problem. If the issue is that you're running into the executable code limit, which is about 8KB, try compiling your code as an application or using the Fullrene Axiom. Both remove the executable code limit, although the total size of your code and data combined is limited to 16KB for applications and however much RAM the user has available (you can generally expect about 20KB) for programs using Fullrene. Also, Fullrene is known be a bit unreliable.
If the issue is that your application or program is too large due to containing lots of data, try externalizing data into appvars to keep the size of your actual program to a minimum. There's no clear/documented way to do this, but if you'd like to, ask and ye shall receive help.
For self modifying code what numbers correspond to which command tokens?
If you're aiming to change more than just a numeric value in code, SMC is probably not the way to go, because code can vary wildly in size and format based on what it's doing. In what context are you imagining using SMC? I'd imagine that there's probably a more reasonable solution.
Now that I think of it. I never used #Realloc because I use custom variables (and because before that, I was a noob) but would Realloc also move a custom variable if it is defined from a default one ? I mean something like °A→°Custom, then #Realloc(L3), would this make °Custom equal to L3 from now on ?
No. Constant assignments are strict, not lazy, meaning they're resolved to a value immediately.
I loaded it in wabbitemu and the version numbers are the same.
Since the small font editor version was not actually officially released, I think the author didn't increment the version numbers. Perhaps the easiest way to know if you have this version or not is that all previous versions of zStart are only one page (16834 bytes) large, while the version with the small font editor is two pages (32768 bytes) large. Also, you can't actually turn the small font editor off, so you'd certainly know if you had it.
Also, through the getcalc( command is is possible to create self modifying code assuming you knew what you were doing?
Self-modifying code is certainly doable in Axe if you know what you're doing. But I'm not sure how GetCalc() would factor into it without knowing more about your intent.
Do you think it would be possible to add keyhook functionality when compiled as an app? getkeyH(key,key state) adding a state feature would let the app test for state like 2nd + mem. It would be a really cool feature (assuming you aren't worried about people creating a bunch of memory protectors)
I've abstained from providing hook functionality for a few reasons. But the main reason is that hooks are simply too low level and too closely tied to the OS.
To operate meaningfully, most hooks need OS RAM and call equates, and there are far too many of these to add as built-ins to Axe. In a similar vein, there are many useful hooks. If one was added, then it would only feel right to add the others, and this would also clog up built-ins. And if only some things existed as built-ins to avoid clogging them up, then you'd probably end up turning to assembly to fill some gaps. In which case, you could reasonably just use assembly for all of it. And you can already implement hooks with a minimal amount of assembly that run Axe code for their main functionality.
On a different subject, I noticed that the Text( command behaved weirdly when performed off screen. Could this just be my bad code or is it something else?
You noticed correctly. Text printing is handled by the OS, which may freak out when attempting to print text offscreen. It's up to the programmer to make sure that the text they print is not offscreen.
Also, what exactly does #Relloc( do? (I know it moves the location of something, but why would you want to do that?)
It redefines the address at which the automatically-defined A-θ variables exist in memory. It's only rarely useful to advanced programmers who need to use the variable's default location in memory for something else, as this allows them to move the variables somewhere else that they know is free.
It's certainly not impossible to build your own program editor. However, there are lots of OS calls that would assist in providing functionality of the OS editor that you don't have access to in Axe. Namely, you'd have to handle input entirely yourself, translating keypresses to tokens and making your own menus.
If there are any specific problems you're running into, ask directly about those.
By the way, if you simply wanted a small font program editor to use, there's a version of zStart that replaces the OS editor with one. It was released in a mostly completed state when the developer was more or less stopping calculator development, so there may be a few things wrong with it that won't be fixed. But I think it works for the most part. And zStart provides other nice features, especially for Axe developers, so you should have some version of it anyways. If you're interested, grab the proper version attached to this post (the first is for the 84+ and the second is for the 83+).
Do you allocate buffers or variables inside of your code, like with Buff()? Because unlike with programs, you cannot modify internal data in an application. Any buffers or variables need to be allocated outside of the application, either in static RAM (like the L1-L6 areas) or in temporary variables (created with GetCalc()).
I've commented the routine. Let me know if you have any other questions.
Spoiler For Spoiler:
p_DrawOr: .db __DrawOrEnd-1-$
;; hl=sprite, (sp)=ret, (sp+2)=y, (sp+4)=x ;; Rearrange inputs. push hl pop ix ld hl,plotSScreen x_DrawOrEntry: pop af pop de pop bc push af
;; c=x, e=y, hl=buff, ix=sprite, (sp)=ret ;; Check if the top of the sprite is offscreen. ld b,7 ld a,63 sub e jr nc,__DrawOrNoClipTop
;; a=63-y, b=7, c=x, e=y, hl=buff, ix=sprite ;; If the top of the sprite is offscreen, abort if the bottom is also offscreen. ld a,e add a,b ret nc
;; a=y+7, b=7, c=x, e=y, hl=buff, ix=sprite ;; The top of the sprite is offscreen (negative) but the bottom is not ;; (nonnegative), so clip y to 0 and advance the sprite pointer past the ;; clipped off data. __DrawOrClipTop: ; xor b ; ld e,a ; add ix,de ; ld e,d ; xor b inc ix inc e jr nz,__DrawOrClipTop
;; a=(y<0 ? y+7 : 63-y), b=7, c=x, e=clipped y, hl=buff, ix=sprite start ;; Calculate the clipped height. __DrawOrNoClipTop: cp b jr nc,__DrawOrNoClipBot ld b,a __DrawOrNoClipBot: inc b
;; a=(y<0 ? y+7 : 63-y), b=clipped height, c=x, e=clipped y, hl=buff, ;; ix=sprite start ;; Abort if the sprite is fully offscreen horizontally. ld a,c add a,7 cp 96+7 ret nc
;; a=x+7, b=clipped height, c=x, e=clipped y, hl=buff, ix=sprite start ;; Calculate the pointer to which to draw the top-right of the (clipped) sprite: ;; buff+((clipped y)*12)+((x+7)/8). ld d,0 sla e sla e add hl,de rra add hl,de rra add hl,de rra ld e,a add hl,de
;; a=(x+7)/8, b=clipped height, c=x, de=clipped y*4, hl=draw start, ;; ix=sprite start ;; Use the aligned drawing code if possible. ld a,c and 7 jr z,__DrawOrAligned
;; a=x&7, b=clipped height, c=x, de=clipped y*4, hl=draw start, ix=sprite start ;; Calculate masks for whether or not to draw the left and right bytes of the ;; unaligned sprite. ld e,c ld c,a ld a,e cp -7 sbc a,a ld d,a and e cp 96-7 sbc a,a ld e,a
;; b=height remaining, c=x&7, d=(x<0 ? $FF : 0), e=(x>88 ? $FF : 0), ;; hl=draw current, ix=sprite current ;; Read a sprite byte and rotate it into the correct alignment. __DrawOrLoop: push bc ld b,c ld c,(ix) xor a __DrawOrShift: srl c rra djnz __DrawOrShift
;; b=0, ca=(sprite byte<<8)>>(x&7), d=(x<0 ? $FF : 0), e=(x>88 ? $FF : 0), ;; hl=draw current, ix=sprite current, (sp)=(height remaining<<8)+(x&7) ;; Draw the rotated sprite byte, clipping horizontally as necessary by writing ;; back unchanged data. and e or (hl) ld (hl),a dec hl ld a,c and d or (hl) ld (hl),a
;; a=0, b=height remaining, c=x, de=12, hl=draw current, ix=sprite current ;; Read and draw a sprite byte, advance the sprite and draw pointers, and ;; decrement the height remaining and continue drawing if it's nonzero. __DrawOrAlignedLoop: ld a,(ix) or (hl) ld (hl),a inc ix add hl,de djnz __DrawOrAlignedLoop ret
I'm aware that operations with file pointers are implemented in an ugly way internally, so I'm not too surprised by this bug. I can look into it more, but honestly I'm not sure if I'll be able to fix it. I've somewhat accepted by now that file pointers are a bit broken.
EDIT: Looks like I unknowingly already fixed this in Axe 1.3.0. I should really get that to a full release state...
Show Posts