| Author |
Message |
|
darkstone knight
Advanced Member
Joined: 07 Sep 2008
Posts: 438
|
 Posted: 20 Feb 2009 02:32:26 pm Post subject: |
|
|
ok, i created an appvar, but how do i archive it, als update size?
and, what does (FPS) stand for?
edit: ok.. it stands for floating point stack :D
i assume i t can be any size i want? (assuming you have enough memory)
edit: soo...
Code:
ld hl,AmountOfRAMINeed; where AmountOfRAMINeed is a multiple of 9
B_CALL _EnoughMem
jr c,MemoryError
ld de,AmountOfRAMINeed
ld hl,(FPS)
ld (iMathPtr1),hl
add hl,de
ld (FPS),hl
creates an "var" that is AmountOfRAMINeed bytes long, located at (imathptr), which end is (FPS)?
Last edited by Guest on 20 Feb 2009 02:41:18 pm; edited 1 time in total |
|
| Back to top |
|
|
Galandros
Active Member
Joined: 29 Aug 2008
Posts: 565
|
| Posted: 20 Feb 2009 02:41:15 pm Post subject: |
|
|
darkstone knight wrote: ok, i created an appvar, but how do i archive it, als update size?
and, what does (FPS) stand for?
edit: ok.. it stands for floating point stack :D
i assume i t can be any size i want? (assuming you have enough memory) O.o
Why not see TI documentation or try z80heaven? There is a bcall to archive things, you know... |
|
| Back to top |
|
|
darkstone knight
Advanced Member
Joined: 07 Sep 2008
Posts: 438
|
| Posted: 20 Feb 2009 02:51:12 pm Post subject: |
|
|
everything on wikiti is uncategorized atm...
and there is NO info about bcalls on z80 heaven.. |
|
| Back to top |
|
|
WikiGuru
ADOS (Attention deficit... Oh! Shiny!)
Elite
Joined: 15 Sep 2005
Posts: 923
|
| Posted: 20 Feb 2009 03:12:55 pm Post subject: |
|
|
To create an appvar with name "AVDATA":
Code:
;omit header
ld hl,AmountOfRAMINeed; where AmountOfRAMINeed is a the number of bytes you need
bcall(_enoughmem)
jr c,MemoryError; located somewhere
ld hl,AppVarName
rst rMOV9TOOP1
ld hl,AmountOfRAMINeed
bcall(_CreateAppVar)
AppVarName:
.db AppVarObj,"AVDATA",0
HL = pointer to variable’s symbol table entry
DE = pointer to variable’s data storage, size bytes
Last edited by Guest on 20 Feb 2009 03:14:15 pm; edited 1 time in total |
|
| Back to top |
|
|
Galandros
Active Member
Joined: 29 Aug 2008
Posts: 565
|
| Posted: 20 Feb 2009 03:13:32 pm Post subject: |
|
|
darkstone knight wrote: everything on wikiti is uncategorized atm...
and there is NO info about bcalls on z80 heaven.. Well, I thought that could be possible some example on Appsvars to see how to archive, it is a useful and very used thing in apps games.
Anyway remains Ti documentation... |
|
| Back to top |
|
|
WikiGuru
ADOS (Attention deficit... Oh! Shiny!)
Elite
Joined: 15 Sep 2005
Posts: 923
|
| Posted: 20 Feb 2009 03:20:57 pm Post subject: |
|
|
| wikiti doesn't have documentation on the bcalls you need. They seem to document the ones TI didn't. TI has a list of tons of bcalls, though some of there documentation is incorrect (some routines destroy registers than stated, some less) |
|
| Back to top |
|
|
FloppusMaximus
Advanced Member
Joined: 22 Aug 2008
Posts: 472
|
| Posted: 20 Feb 2009 04:15:42 pm Post subject: |
|
|
CreateAppVar (as with other system routines that create variables) does check for free memory, so you don't necessarily need the call to _EnoughMem in that case. You do, however, have to call ChkFindSym first, because CreateAppVar does not check for duplicate variable names.
Code:
AllocateAppVar:
ld hl,AppVarName
rst rMOV9TOOP1
bcall(_ChkFindSym)
jr c,AllocateAppVar_DNE
bcall(_DelVarArc); or _DelVar if you prefer
jr AllocateAppVar
AllocateAppVar_DNE:
ld hl,AppVarSize
bcall(_CreateAppVar)
AppVars are the way to store persistent data, like high scores and saved games. If you just want some temporary space for decompressing levels, I would probably use the FPS for that. (The nice thing about using the FPS is you don't have to worry about cleaning it up when the app exits.) That's not to say you can't use an appvar if you want to, it just seems like overkill.
Last edited by Guest on 20 Feb 2009 04:36:16 pm; edited 1 time in total |
|
| Back to top |
|
|
darkstone knight
Advanced Member
Joined: 07 Sep 2008
Posts: 438
|
| Posted: 20 Feb 2009 04:19:14 pm Post subject: |
|
|
so, if i understand the ti-documentation (which doesnt work in portable firefox for some reason  ), the flowing code will increase my 333-size appvar whit 1k bytes:
Code:
ld hl,1000;check if the user has enough memory
bcall(_enoughmem)
jp c,exit
LD HL,AppVarName;look up the var
rst 20h
BCALL(_ChkFindSym)
push DE
LD HL,2+333
ADD HL,DE
EX DE,HL
LD HL,1000
BCALL(_insertmem);inserts memory at (DE)
POP HL
LD DE,333+1000;update size bytes
LD (HL),E
inc HL
LD (HL),D
RET
this will be, hopefully, my last quistion :)
of course, i already checked if it works, but im not sure about all the memory fuck...
edit: drat, post conflict
using the FPS might be a better idea.. whatever
edit: actualy, i might be able to insert ram at some location, using _insertmem
this preserves all pointers and such, as the data is always on the same place (do dynamic allocation in the program)
so i can, say, insert 2000 bytes of ram in $A000, will that screw me up?
as long i dont use the VAT, ofc
Last edited by Guest on 20 Feb 2009 04:34:23 pm; edited 1 time in total |
|
| Back to top |
|
|
FloppusMaximus
Advanced Member
Joined: 22 Aug 2008
Posts: 472
|
| Posted: 20 Feb 2009 04:35:05 pm Post subject: |
|
|
| That looks like it would work. |
|
| Back to top |
|
|
darkstone knight
Advanced Member
Joined: 07 Sep 2008
Posts: 438
|
| Posted: 20 Feb 2009 04:38:30 pm Post subject: |
|
|
now in confused about _insertmem, does it actualy check what var it is "expanding"?
i mean, serious bugs happen if it tries to move itself, to free more ram |
|
| Back to top |
|
|
FloppusMaximus
Advanced Member
Joined: 22 Aug 2008
Posts: 472
|
| Posted: 20 Feb 2009 04:53:16 pm Post subject: |
|
|
What InsertMem does is to move a chunk of memory starting at the address you specify, and ending at (FPS), forward in memory by the specified number of bytes. It then looks through all of the VAT entries and all of the system managed pointers (such as the iMathPtrs) to find pointers to the area of memory that was just moved, and updates them to point to the new addresses.
It doesn't actually figure out what variable is being expanded; that's why you need to update the length yourself.
Quote: edit: actualy, i might be able to insert ram at some location, using _insertmem
this preserves all pointers and such, as the data is always on the same place (do dynamic allocation in the program)
so i can, say, insert 2000 bytes of ram in $A000, will that screw me up?
as long i dont use the VAT, ofc
You shouldn't just insert memory at A000, because that is most likely in the middle of some variable or other. You could insert a temporary block of memory at 9D95 if you want to, but then you have to be especially careful to clean it up properly.
Last edited by Guest on 20 Feb 2009 04:57:18 pm; edited 1 time in total |
|
| Back to top |
|
|
darkstone knight
Advanced Member
Joined: 07 Sep 2008
Posts: 438
|
| Posted: 20 Feb 2009 05:01:10 pm Post subject: |
|
|
ok..
now, i image the FPS is a var, that is not stored at a fixed plaxe
then the whole theory of "no dynamic allocation" breaks down
however, your explanation of _insertmem suggests that you can use insertmem $A000 (right before the first VAT entry.. i think) or _insertmem (FPS)-amount_of_mem
that means that you can deteminate the location of all decompressed data while programing, rather than calucating it 60 times a second
(yes, i know my english sucks  ) |
|
| Back to top |
|
|
FloppusMaximus
Advanced Member
Joined: 22 Aug 2008
Posts: 472
|
| Posted: 20 Feb 2009 05:06:10 pm Post subject: |
|
|
darkstone knight wrote: that means that you can deteminate the location of all decompressed data while programing, rather than calucating it 60 times a second
Yes, that is one advantage of static allocation. I don't know how big of an advantage it is for you, as I don't know how your level data is structured. But I would guess it's not a very substantial one. (If you're only doing it 60 times a second, you shouldn't be worried about speed.  ) |
|
| Back to top |
|
|
darkstone knight
Advanced Member
Joined: 07 Sep 2008
Posts: 438
|
| Posted: 20 Feb 2009 05:15:53 pm Post subject: |
|
|
<shameless advertising>
[attachment=2596:supaplex3.gif]
it allows for maps of 4096 width, and runs at 70 fps :biggrin:
(ignore the crappy, made-in-60-seconds title screen :/)
</shameless advertising>
annyway, if only using it for the tilemap, the game features 111 levels of 1200 bytes, thats why i need all the compressing/memory fetch..
..wait, im advertising again
so... i asume the data start at $A000? i dont want to insert 2k of ram inside a list element....
edit: wait, it doesnt even matter
you can just _DelMem whit exacly the same arguments to remove the space, cool 
Last edited by Guest on 20 Feb 2009 05:38:43 pm; edited 1 time in total |
|
| Back to top |
|
|
FloppusMaximus
Advanced Member
Joined: 22 Aug 2008
Posts: 472
|
| Posted: 20 Feb 2009 05:42:34 pm Post subject: |
|
|
| No. Like I said, do not just insert memory in the middle of user memory; you never know what might be broken that way. If you must, do the insertmem at the very beginning of user memory. |
|
| Back to top |
|
|
darkstone knight
Advanced Member
Joined: 07 Sep 2008
Posts: 438
|
| Posted: 20 Feb 2009 05:53:20 pm Post subject: |
|
|
| that brings me to my unanswered question: where does memory begin? $A000? |
|
| Back to top |
|
|
FloppusMaximus
Advanced Member
Joined: 22 Aug 2008
Posts: 472
|
| Posted: 20 Feb 2009 05:54:25 pm Post subject: |
|
|
| 9D95 |
|
| Back to top |
|
|
darkstone knight
Advanced Member
Joined: 07 Sep 2008
Posts: 438
|
| Posted: 20 Feb 2009 06:15:04 pm Post subject: |
|
|
ew... i saw you already wrote that...
annyway, i can continune on making my game, thanks  |
|
| Back to top |
|
|
|
Z80 & 68k Assembly => z80 & ez80 Assembly
