| Author |
Message |
|
DigiTan
Unregistered HyperCam 2
Super Elite (Last Title)
Joined: 10 Nov 2003
Posts: 4468
|
 Posted: 12 Aug 2008 04:10:30 pm Post subject: |
|
|
| I've got a Spasm question. Exactly how do you get code in one page to read other pages. Like if my code is in page 0 and a sprite is in page 1, could it draw the sprite without getting the RAM involved? |
|
| Back to top |
|
|
fourchanb
Advanced Newbie
Joined: 24 Sep 2006
Posts: 93
|
| Posted: 12 Aug 2008 04:14:19 pm Post subject: |
|
|
DigiTan wrote: I've got a Spasm question. Exactly how do you get code in one page to read other pages. Like if my code is in page 0 and a sprite is in page 1, could it draw the sprite without getting the RAM involved?
[post="125950"]<{POST_SNAPBACK}>[/post] Probably not, the calculator has to switch pages to read from the second page. So if you'd have the address of the sprite on the second page, but your code is on the first page, the address would point to entirely different data when you execute your code. |
|
| Back to top |
|
|
Liazon
title goes here
Bandwidth Hog
Joined: 01 Nov 2005
Posts: 2007
|
| Posted: 12 Aug 2008 06:45:56 pm Post subject: |
|
|
put the sprite routine on the same page as the sprite.
you're passing a pointer to the sprite through a register, which will be preserved regardless of page change. the sprite routine would be on the same page as the sprite and when the page change occurs during the bcall, it will point to the right place in flash.
the down side is that you actually have to bcall (or create your own version of bcall) to use the routine like that, since it's on another page.
Last edited by Guest on 12 Aug 2008 06:47:51 pm; edited 1 time in total |
|
| Back to top |
|
|
c_plus_plus
My Face Hertz
Active Member
Joined: 30 Jan 2006
Posts: 575
|
| Posted: 12 Aug 2008 07:31:15 pm Post subject: |
|
|
Liazon wrote: the down side is that you actually have to bcall (or create your own version of bcall) to use the routine like that, since it's on another page.
[post="125964"]<{POST_SNAPBACK}>[/post]
Spasm has a pcall (page call) feature. |
|
| Back to top |
|
|
DigiTan
Unregistered HyperCam 2
Super Elite (Last Title)
Joined: 10 Nov 2003
Posts: 4468
|
| Posted: 12 Aug 2008 08:14:41 pm Post subject: |
|
|
| Is it possible to copy the graphics to from Page 1 to RAM and have the Page 0 code use it that way? |
|
| Back to top |
|
|
calc84maniac
Elite
Joined: 22 Jan 2007
Posts: 770
|
| Posted: 12 Aug 2008 08:38:13 pm Post subject: |
|
|
DigiTan wrote: Is it possible to copy the graphics to from Page 1 to RAM and have the Page 0 code use it that way?
[post="125969"]<{POST_SNAPBACK}>[/post]
You'll still need a routine in RAM to change the page for copying. |
|
| Back to top |
|
|
Liazon
title goes here
Bandwidth Hog
Joined: 01 Nov 2005
Posts: 2007
|
| Posted: 12 Aug 2008 10:40:15 pm Post subject: |
|
|
theoretically, I think you could just bcall a routine on the same page as the sprites and retrieve what you need based on register parameters.
that being said, TI-OS ALREADY has a bcall: _flashtoRAM, which iirc can copy anything on any page to any location in RAM, correct me if I'm wrong. So you can just ignore what I just said above unless you have specific reasons not to.
don't worry about RAM usage with apps. I imagine most people have at least 5-8k free to play some of their favorite games. you should copy speed critical things to RAM (aka crash's mapper, cuz iirc it has a lot of SMC) and level dependent data (so you don't have to flip pages all the time in the same area).
spasm provides a lot of tools for relocating code to RAM.
oh btw, RW2 for 83+ will be so sweet i know it! :biggrin: :biggrin: :biggrin:
Last edited by Guest on 12 Aug 2008 10:40:58 pm; edited 1 time in total |
|
| Back to top |
|
|
Cryzbl
Newbie
Joined: 20 Jun 2008
Posts: 46
|
| Posted: 13 Aug 2008 06:54:38 pm Post subject: |
|
|
lolwut.
Why use a B_CALL when you can LDIR the data?
I don't believe SPASM can relocate code dynamically... And every compiler can relocate...
$=$9D95
done :P
And you should worry about RAM since 1) you need to check if there actually IS enough memory and 2) if you touch $9D95 and onward without 'inserting mem' you WILL screw things up. Personal experience 
Last edited by Guest on 13 Aug 2008 07:01:31 pm; edited 1 time in total |
|
| Back to top |
|
|
magicdanw
pcGuru()
Calc Guru
Joined: 14 Feb 2007
Posts: 1110
|
| Posted: 13 Aug 2008 07:21:40 pm Post subject: |
|
|
Cryzbl wrote: lolwut.
Why use a B_CALL when you can LDIR the data?
I don't believe SPASM can relocate code dynamically... And every compiler can relocate...
$=$9D95
done :P
And you should worry about RAM since 1) you need to check if there actually IS enough memory and 2) if you touch $9D95 and onward without 'inserting mem' you WILL screw things up. Personal experience
[post="125994"]<{POST_SNAPBACK}>[/post]
Do you know how flash pages work? You can't ldir the data on a page that isn't swapped in, and once you swap the second page in, the first page stops executing code, and it can't do the ldir anymore.
No assembler can relocate code dynamically, but perhaps spasm provides directives that will handle pointer changes when code is copied to another location before being executed?
Also, touching $9D95 and won't screw things up unless you don't know what you're touching. For instance, if you decide to treat it as free ram, which it isn't (it's user memory, which stores programs and variables), then obviously the calculator will go wonky. But if you know what you're doing, you can do tons of stuff beyond $9D95! |
|
| Back to top |
|
|
Cryzbl
Newbie
Joined: 20 Jun 2008
Posts: 46
|
| Posted: 13 Aug 2008 07:38:11 pm Post subject: |
|
|
magicdanw wrote: Do you know how flash pages work? You can't ldir the data on a page that isn't swapped in, and once you swap the second page in, the first page stops executing code, and it can't do the ldir anymore.
I do, I guess I misunderstood, I was under the impression he meant to copy data on the same page to RAM which I found quite strange.
And I'm kinda anti TIOS, I prefer to swap pages myself. :P
Quote: No assembler can relocate code dynamically, but perhaps spasm provides directives that will handle pointer changes when code is copied to another location before being executed?
I'm not sure what exactly you are talking about... How would that work?
Quote: Also, touching $9D95 and won't screw things up unless you don't know what you're touching. For instance, if you decide to treat it as free ram, which it isn't (it's user memory, which stores programs and variables), then obviously the calculator will go wonky. But if you know what you're doing, you can do tons of stuff beyond $9D95!
[post="125998"]<{POST_SNAPBACK}>[/post]
Agreed, if you use it as a place to put your routines that use SMC then you will screw up which is the thing someone tried to use it for I believe.
Last edited by Guest on 13 Aug 2008 07:38:43 pm; edited 1 time in total |
|
| Back to top |
|
|
Liazon
title goes here
Bandwidth Hog
Joined: 01 Nov 2005
Posts: 2007
|
| Posted: 13 Aug 2008 09:08:40 pm Post subject: |
|
|
ya, nothing like the _insertmem trick, by far the most useful bcall imho  although like i said, I'd be surprised if someone maxed out their ram that so much you can't play most of the good games. once again, there are bcalls for checking if there's enough RAM too lol.
i guess if you only make relative jumps in your code, you can probably place it anywhere in RAM provided you can somehow change the address for each call to that code. that's probably more difficult said than done if the call was made from flash.
and as some say, why reinvent the wheel? using rom calls can save some space if it's not speed critical and you're doing the exact same thing. |
|
| Back to top |
|
|
Cryzbl
Newbie
Joined: 20 Jun 2008
Posts: 46
|
| Posted: 14 Aug 2008 05:05:00 am Post subject: |
|
|
Liazon wrote: i guess if you only make relative jumps in your code, you can probably place it anywhere in RAM provided you can somehow change the address for each call to that code. that's probably more difficult said than done if the call was made from flash.
If you put some limitations on how the code looks, relocation would work just fine:
1) Seperate data and code
2) Don't use jp (hl) or smc to calculate the destination address (unless you do it right)
In that case it should be perfectly possible to analyse the code and change the addresses of CALL and JP.
Quote: and as some say, why reinvent the wheel? using rom calls can save some space if it's not speed critical and you're doing the exact same thing.
[post="126002"]<{POST_SNAPBACK}>[/post]
I only use B_CALLs if it's something calc related, for all other small stuff I do it myself. (ex. I used Sigma's SDRs but wrote my own getcsc). |
|
| Back to top |
|
|
WikiGuru
ADOS (Attention deficit... Oh! Shiny!)
Elite
Joined: 15 Sep 2005
Posts: 923
|
| Posted: 14 Aug 2008 09:30:31 am Post subject: |
|
|
I use bcalls when i'm feeling lazy 
but yeah, the best way is to put any code that accesses data on the same page as the data it's accessing. If it's not possible, I'd go with flash_to_ram. Use it to copy data (not code) onto the flash page that has the code.
Last edited by Guest on 30 Jul 2010 05:02:48 am; edited 1 time in total |
|
| Back to top |
|
|
Cryzbl
Newbie
Joined: 20 Jun 2008
Posts: 46
|
| Posted: 14 Aug 2008 09:53:55 am Post subject: |
|
|
| There's one problem though. What in the case your data is compressed? (Which should be the case ) |
|
| Back to top |
|
|
WikiGuru
ADOS (Attention deficit... Oh! Shiny!)
Elite
Joined: 15 Sep 2005
Posts: 923
|
| Posted: 14 Aug 2008 12:37:36 pm Post subject: |
|
|
| Well, there are always these. You can do whatever you want in appvars, and since they can be put in RAM, it's possible to create a temporary appvar and do all your data manipulation from different pages in the appvar, then delete it when quiting. |
|
| Back to top |
|
|
Cryzbl
Newbie
Joined: 20 Jun 2008
Posts: 46
|
| Posted: 14 Aug 2008 01:12:26 pm Post subject: |
|
|
Well, if you copy the compressed data to RAM first you're wasting a lot of memory.
If you decompress the data into the appvars you can't use the bcall and you have to do it manually.
:D |
|
| Back to top |
|
|
WikiGuru
ADOS (Attention deficit... Oh! Shiny!)
Elite
Joined: 15 Sep 2005
Posts: 923
|
| Posted: 14 Aug 2008 01:35:54 pm Post subject: |
|
|
Yeah, but in that case, it's easy enough to make a call to the page the data is on that will decompress into the appvar, and then technically there's no need for flash-to-ram at all. All you need is a pointer to the data in the appvar.
Code:
page0:
;sprite routine bcalls "decompress"
page1:
decompress:
;decompress and put into appvar
ret
data:
...
|
|
| Back to top |
|
|
Cryzbl
Newbie
Joined: 20 Jun 2008
Posts: 46
|
| Posted: 14 Aug 2008 01:38:16 pm Post subject: |
|
|
True.
Anything else you want to know cjgone? |
|
| Back to top |
|
|
|
Z80 & 68k Assembly => z80 & ez80 Assembly
