PT_ wrote:
Which hook is called (or none) if you press + on a token (not necessary via the Catalog)? Is there already documentation about it?

http://wikiti.brandonw.net/index.php?title=83Plus:Hooks:Catalog
Well, when opening the program editor from ICE, it leaks memory, about 13K, way too much Sad
Can anyone help me please? I used the routine from https://www.cemetech.net/forum/viewtopic.php?p=171310#171310 and this is my code:
Code:
OpenEditBuffer:
   push hl
      scf
      sbc hl, hl
      ld (hl), 2
      ld hl, OP1+1
      ld de, progToEdit
      call _Mov8b
      ld a, kPrgmEd
      call _EnoughMem
      ld a, kPrgmEd
      call _NewContext
      call _EnoughMem
   pop hl
EditBufferSMC = $+1
   ld de, 0
   or a
   sbc hl, de
   push hl
   pop bc
   ld de, (editTop)
   ld hl, (editTail)
   jr z, +_
   ldir
   ld (editCursor), de
   ld (editTail), hl
_:   push bc
   pop hl
   push hl
EditorLoop:
      ld de, (editTop)
      or a
      sbc hl, de
      jr z, EditorFound
      call _BufLeft
      ld hl, (editCursor)
      ld a, (hl)
      cp tEnter
      jr z, EditorFound
   pop hl
   inc hl
   push hl
      jr EditorLoop
EditorFound:
      call _BufRight
      call _DispEOW
   pop hl
   call _SetAToHLU
   or a, h
   or a, l
   jr z, EditorMon
EditorScroll:
   dec hl
   call _SetAToHLU
   or a, h
   or a, l
   jr z, EditorMon
   push hl
      call _CursorRight
   pop hl
   jr EditorScroll
EditorMon:
   res 2, (iy+50)
   res 7, (iy+20)
   res 3, (iy+5)
   jp _Mon
So, to double check, are the steps something like this?
1) ICE decides to edit a program.
2) ICE invokes the routine above, jumping _Mon.
Do you try to catch the change-of-context out of the editor, or do you assume that the OS now has control forever? The obvious answer is that if you're handing control over to the OS, need to _DelMem size_of_ICE - 2 bytes at UserMem. Another option would be to exit ICE, but leave a key hook installed that will delete itself and launch the editor as soon as the cursor starts flashing at the homescreen again.

Edit: It's worth mentioning that the _DelMem at UserMem approach only works if you're positive that the OS was the one running your program, not a shell. The OS copies your program to UserMem, while shells swap the program to UserMem, allowing you to run programs with very little free RAM. The hook approach might be preferred in case the OS/shell/whatever has other cleanup tasks it wishes to run.
I'm curious about linking at the TI-84+CE. Let's say I want to get some bytes from the linked calc, how would I do that? And how would I even check if a calc is linked? Are there some calls for it? Thanks in advance Smile Good Idea

EDIT: Mateo gave me one call that checks if the USB is powered, _usb_BusPowered, and he said there is another call somewhere in the OS that can write/read bytes, but he didn't explore it yet. I don't really mind, because I can't even test things, since I don't have 2 CE's.. Sad
I'm struggling with Z80/ADL mode and prefixes etc. When I'm reading the documentation, I see (all in both Z80 and ADL mode):
call
call.sis
call.lil
call.is
call.il
but where are call.lis/call.sis and call.lil/call.sil? What happens if the CE triggers such opcode (in both modes)?
This is not really ASM-related, but I have a question about spasm. I have a lot of sprites (AoCE) which takes up one giant appvar. All these sprites are (compressed and) compiled with ConvPNG. But I need to display these sprites, and thus I need to know the offset in the appvar. So my idea was to include the sprite data in the main program, such that the names/widths/heights are defined, but not included in the output. I tried .nolist and .list, and that works fine for the labels, but the sprite data is still included. Can someone help me? Smile
You could have an offset table at the beginning of your appvar, pointing to where each sprite starts
That will work, indeed, but the sprites might change a little bit, and updating the offsets each time is a hell Sad
You could write yourself a script to create dynamic labels for each sprite, like _sprite_offset_<num> and then in the offset table thing do like

Code:

for i in range(num):
    print("\t.dw _sprite_offset_"+str(i)+"\n")
Indeed, a table containing offset expressions computed by the assembler is simple and makes perfect sense, especially when coupled with a C enum to define the indices Smile

A more complex approach would be to use some form of archive file with an index and a bit of extra metadata for every chunk, in the same vein as ZIP files / tarballs. There's precedent in the TI community: for instance, TICT eBooks for the TI-68k series are stored as an introductory image, then multiple eBook parts, into a so-called "TTArchive" container supporting optional per-part compression with PuCrunch, created by a computer-side generator driven by a config file.
However, given that the approach listed by Sorunome works beautifully for your use case, I won't elaborate further unless you want me to Wink
Okay, I made a PHP script that does this automatically, and generates this output:


Code:
Trying to open "graphics.asm"...
Succesfully opened!
Reading lines...
File found: "gfx/Buildings/gfx_buildings.inc"
  Trying to open "gfx/Buildings/gfx_buildings.inc"...
  Succesfully opened!
  Reading lines...
  File found: "gfx/Buildings/barracks.asm"
    Trying to open "gfx/Buildings/barracks.asm"...
    Succesfully opened!
    Reading lines...
      _barracks .equ 0000000h
      _barracks_height .equ 81
  File found: "gfx/Buildings/farm.asm"
    Trying to open "gfx/Buildings/farm.asm"...
    Succesfully opened!
    Reading lines...
      _farm .equ 0001E62h
      _farm_height .equ 49
  File found: "gfx/Buildings/house.asm"
    Trying to open "gfx/Buildings/house.asm"...
    Succesfully opened!
    Reading lines...
      _house .equ 00030C4h
      _house_height .equ 56
  File found: "gfx/Buildings/lumbercamp.asm"
    Trying to open "gfx/Buildings/lumbercamp.asm"...
    Succesfully opened!
    Reading lines...
      _lumbercamp .equ 0003EC6h
      _lumbercamp_height .equ 46
  File found: "gfx/Buildings/mill.asm"
    Trying to open "gfx/Buildings/mill.asm"...
    Succesfully opened!
    Reading lines...
      _mill .equ 0004A48h
      _mill_height .equ 48
  File found: "gfx/Buildings/miningcamp.asm"
    Trying to open "gfx/Buildings/miningcamp.asm"...
    Succesfully opened!
    Reading lines...
      _miningcamp .equ 000564Ah
      _miningcamp_height .equ 41
  File found: "gfx/Buildings/towncenter.asm"
    Trying to open "gfx/Buildings/towncenter.asm"...
    Succesfully opened!
    Reading lines...
      _towncenter .equ 000608Ch
      _towncenter_height .equ 97
File found: "gfx/Gameplay/gfx_gameplay.inc"
  Trying to open "gfx/Gameplay/gfx_gameplay.inc"...
  Succesfully opened!
  Reading lines...
  File found: "gfx/Gameplay/resources.asm"
    Trying to open "gfx/Gameplay/resources.asm"...
    Succesfully opened!
    Reading lines...
      _resources .equ 000910Eh
      _resources_height .equ 15
File found: "gfx/Tiles/gfx_tiles.inc"
  Trying to open "gfx/Tiles/gfx_tiles.inc"...
  Succesfully opened!
  Reading lines...
  File found: "gfx/Tiles/tile_test.asm"
    Trying to open "gfx/Tiles/tile_test.asm"...
    Succesfully opened!
    Reading lines...
      _tile_test .equ 000A3D0h
      _tile_test_height .equ 17
File found: "gfx/Main/gfx_main1.inc"
  Trying to open "gfx/Main/gfx_main1.inc"...
  Succesfully opened!
  Reading lines...
  File found: "gfx/Main/AoCEI.asm"
    Trying to open "gfx/Main/AoCEI.asm"...
    Succesfully opened!
    Reading lines...
      _AoCEI_compressed .equ 000A5F2h
      _AoCEI_compressed_height .equ 85
  File found: "gfx/Main/soldier.asm"
    Trying to open "gfx/Main/soldier.asm"...
    Succesfully opened!
    Reading lines...
      _soldier_compressed .equ 000EB02h
      _soldier_compressed_height .equ 222
  File found: "gfx/Main/playhelpquit.asm"
    Trying to open "gfx/Main/playhelpquit.asm"...
    Succesfully opened!
    Reading lines...
      _playhelpquit_compressed .equ 0014610h
      _playhelpquit_compressed_height .equ 116
  File found: "gfx/Main/singlemultiplayer.asm"
    Trying to open "gfx/Main/singlemultiplayer.asm"...
    Succesfully opened!
    Reading lines...
      _singlemultiplayer_compressed .equ 0016968h
      _singlemultiplayer_compressed_height .equ 80
File found: "gfx/Main/gfx_main2.inc"
  Trying to open "gfx/Main/gfx_main2.inc"...
  Succesfully opened!
  Reading lines...
  File found: "gfx/Main/pointer.asm"
    Trying to open "gfx/Main/pointer.asm"...
    Succesfully opened!
    Reading lines...
      _pointer .equ 001ADD8h
      _pointer_height .equ 36
Succes!


<serious stuff> Now that I have everywhere offsets, is it better to have a relocation routine, like the C libs, or a table containing the offsets? I prefer to have a relocation routine, because it is slightly faster during the game itself.
"Relocation routine", as in embedding an array of pointers into your program's image, and at startup time, storing pointer values computed from the base address of the variable (which shall hopefully either not change during one run because of archive memory garbage collection, or be automatically recomputed after an address change if you have a way to catch GC events...) and the contents of the offset table ? Yeah, sure.
Lionel Debroux wrote:
which shall hopefully either not change during one run because of archive memory garbage collection, or be automatically recomputed after an address change if you have a way to catch GC events...)

What are these events and can they happen during the execution of an ASM program?
On the TI-68k/AMS platform, archive memory GC can occur during the execution of an ASM program, when said program wants to archive variables (ROM_CALL EM_moveSymToExtMem), for instance its own savestates, but there's no more suitably usable space within archive memory. Or when calling the EM_GC ROM_CALL directly, of course.
Admittedly, my memory is fading, but I'm not aware of a direct way for the running ASM program to receive notifications from the system when a GC occurred (though I can imagine some dirty and/or heavyweight schemes). Correct programs need to be written in such a way that they're resistant to both RAM heap compaction and archive memory GC, and the main way to do that is to use HANDLEs instead of SYM_ENTRYs.

On the TI-Z80 and TI-eZ80 platforms, I can't see why archive memory GC couldn't occur during the execution of an ASM program, for the same reason. And people even more knowledgeable in TI-(e)Z80 calculators than you are, which is far more than I am, can tell you what happens on these platforms. I was just attempting to point a potential limitation of a scheme based on direct pointers to data in some cases: you might have to recompute after archiving variables, or something like that Smile
So basically such event would only occur if the archive is full?

Other spasm question: like with the C libs, I use \.r , and now I need to know how many times this macro is called. In the C lib, I see something like #define numrelocations numrelocations+1, which works fine for me too, but if I have somewhere in the code ld b, numrelocations, it sets it to 0, causing a crash. Sad
You wouldn't happen to have a multiple of 256 relocations, would you?

If not, then spasm's up to its usual weird define scoping. If you want the value of numrelocations as it would be at that instant, eval(numrelocations) may help. Otherwise, I'm not sure what to suggest without more context.
In notepad++ is it possible to highlight all the label names? Such as highlighting everything before the ":".
PT_ wrote:
In notepad++ is it possible to highlight all the label names? Such as highlighting everything before the ":".

Do you mean inside a User Defined Language?
If so, yes it is possible, as long as you have an underscore starting the label (I haven't figured out if you can without an underscore). If you edit your defined language, and go to the tab called "Operators & Delimiters", choose one of the boxes to use it for. Add these things so it looks like this:

Open: _
Escape:
Close: (( : EOL))

That will do it for you. Obviously, change the Styler settings for highlighting.
PT_ asked for help with a 24-bit ez80 sqrt routine on IRC. I soon realized that my 8.8 z80 sqrt routine already computes a 24-bit sqrt, so I just made some changes to that:

Code:
; uhl = sqrt(uhl)
Sqrt24:
        dec     sp      ; (sp) = ?
        push    hl      ; (sp) = ?uhl
        dec     sp      ; (sp) = ?uhl?
        pop     ix      ; (sp) = ?u, uix = hl?
        dec     sp      ; (sp) = ?u?
        pop     af      ; af = u?
        or      a,a
        sbc     hl,hl
        ex      de,hl   ; de = 0
        sbc     hl,hl   ; hl = 0
        ld      bc,$C40 ; b = 12, c = 0x40
Sqrt24Loop:
        sub     a,c
        sbc     hl,de
        jr      nc,Sqrt24Skip
        add     a,c
        adc     hl,de
Sqrt24Skip:
        ccf
        rl      e
        rl      d
        add     ix,ix
        rla
        adc     hl,hl
        add     ix,ix
        rla
        adc     hl,hl
        djnz    Sqrt24Loop
        ex      de,hl
        ret
What is the fastest way to check if signed HL is in a signed range?
i.e. HL = 2 in range [-1,8] should return true, but range [3,12] and [-20,-11] should return false.

EDIT: Runer solved it. Basically move the range to [0,X] and then unsigned compare HL with X.
  
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 3 of 4
» 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