Omnimaga
Calculator Community => TI Calculators => Grammer => Topic started by: Xeda112358 on November 08, 2011, 11:27:59 am
-
I figured a Questions and Answers topic for Grammer might be useful now that Grammer is picking up new programmers :)
So if anybody has questions, feel free to ask! I will try to be on often enough to answer questions with code or comments :D
-
:D
How long should the interrupt code be :D
-
Hmm, I'm not actually sure :/ I don't seem to have a problem with having multiple DispGraphs in there (I tried 6) and those are the slowest commands. I will have to test code to see what works and what doesn't...
EDIT: That is a very good question, by the way XD
-
I'm asking this because most of the time, it just crashed if I put too much in interrupt label D:
-
Ah, okay. I've only ever used interrupts to toggle two buffers, so I only had something like this as my interrupt:
DispGraphH
DispGraphI
End
-
Now I come to think of it, Grammer should actually have it's own forum.(I don't think it does, right?)
-
No, it doesn't yet XD That is why I have been avoiding making a topic like this >.>
-
Ok, I guess my biggest question is how do I make an array that I can access?
-
First, you can create program or appvar like this:
Send(size,"UTEMP->B
This will create appvar TEMP and store it into pointer B.
and then:
B[4,4,4,4,4,4,4,4,4,4
This will store 4 into first 10 bytes of that appvar TEMP.
-
Well if you wanted to create a 128 byte array for temporary storage, I would create a TempProg (the prefix byte is V or 6). Since Send( will let you do this and it returns the pointer to the var, this is what you would want to do:
Send(128,"6Temp→Z ;Z now points to the Array
Lowercase is allowed in the name and weird symbols are encouraged to avoid conflicting with preexisting programs
Now you can use Z as a pointer. There are several commands that might be useful:
int(Z,A will write the lower 8-bits of A to the memory location Z
iPart(Z,A will write A to the memory location Z in little endian
(Z will read the byte at Z
{Z will read the word (little endian) at Z
IS>(Z will read the byte at Z and then increment Z
There are also various other commands if you need other specific things done...
EDIT:Also what Yeong said ^_^
-
Ok, so how would I access the information?
would B + 1 get me the 2nd byte? Also, how would I add more data to the end?
Edit: Ninja'd :P
-
accessing byte XD
if it's 8bit number, do (B+1)
if it's 16bit number, do {B+1}
EDIT: didn't see that post XP
-
Adding more data to the end... there is not a command yet (I plan to eventually add that as augment(, though).
And yes, B+1 will access the second byte :)
Also, the ) and } are solely for aesthetics. Grammer doesn't actually recognise them XD
-
What are the differences between the app version and the program version? (or is there only the app version now?)
-
Also, the ) and } are solely for aesthetics. Grammer doesn't actually recognise them XD
But it looks nice and clean that way :P
-
The app version has more features and lets you run the programs from archive and whatnot. So it is more crash resistant XD
-
Ahh, okay. I shall give it a try soon, then. :)
-
I just took a look through the documentation and how do I get the user input of a string or a number?
-
With the latest version, you would use Input →A to let the user input a string. You can use expr( to convert the string to a value (by executing the string as code).
So for example:
Text(0,0,"Name
DispGraph
Input→A
or:
Text(0,0,"GUESS
DispGraph
expr(Input →A
The input routine isn't great, but it is rather adequate :)
-
can you write down all the prefixes? so far, all I know is that e is program, and v is appvar.
-
@Xeda: with those commands, it would be possible to create an interactive grammar interpreter (although impractical), right?
-
@Yeong: I should remember to include the chart in the readme... For now:
D=Str
E=Program
F=Protected Program
G=Picture
H=GDB
U=Appvar
V=Temp Program
W=Group ;be careful with this one!
@C0deH4cker: I've no clue what that means, but Grammer is Turing Complete (I believe) and so can emulate other Turing machines, so you can create a new interpreter from Grammer :)
-
wait....I could do group? and Pic? O.o
:banghead:
I feel like Full'd (no pun intended)
-
No, you should not write to a group O.O Only read from it unless you know exactly what you are doing! Creating a group could cause some serious issues...
-
yet another question:
Is there a way to "jump" to another Grammer program?
(Except for the not putting "stop" in end of the program and let it "naturally" run the program right below it. :P )
-
Yes, actually. All you need is a pointer to the program and then you use either Goto or prgm like you would a label. So to jump to prgmSubEnd:
Goto Get("ESubEnd
This is actually the main reason for why the program header starts with a decimal as that line will be ignored when calling the program.
-
I actually found the other way to deal with it...>:D (Check Grammer2 APP thread)
but there was an easy way O.O
-
Feature request: is there a way to "include" the TI-BASIC command? I know that Grammer 1 let me do so, but I don't know about the Grammer 2.
-
Hmm, I am not sure what you mean... I think you mean allow BASIC and Grammer to be mixed? I could try to whip something up for you :) You will need to have a program in RAM to do it, but yes.
Also, I will make a Feature Request topic as you requested on IRC :P
-
I think you mean allow BASIC and Grammer to be mixed?
That's exactly what I meant. :D
Also, you got 2k posts XD
-
Okay, I made the topic and the first post should have the program that works.
-
So using C[0,0,0,.... How do I store the data from the specific offset? :D
-
I am not sure what you mean by that :/ Could you clarify?
-
so if I do
C[0,0,0,0,0,0
It stores the data from the first byte, right?
Is there a way to store it from the 3rd byte this way?
-
Do you mean like doing 3+C:[0,0,0,0,0,0 ?
I also think 3+C[0,0,0,0,0,0 is valid, but I cannot remember what I did with that code :/
-
You can do that? D:
-
Yes :) the actual command is [. What that does is take the address in Ans and copies the bytes there. It won't let you put a number directly before the [, but you can do 3+C[0,0,0,0,0,0. (I just checked). I like to do something like pi9872[a,b,c,d,... if I need to store to a specific memory address
-
Ah. I was afraid that lotsa IS< thingy was an answer X.x
BTW, I can do solve(0,pi9872,"UTEMP , right?
-
Only if the name of the program to copy to is at 9872h. Do you need a command to copy data from a variable to a spot in RAM?
-
and vice versa? That would be nicely since I could save pictures in appvar that way. (and display them other than DispGraph Pointer) :D
-
Well if the var is in RAM, you can use the Fill( commands for a picture and solve(1 for arbitrary data. solve(1 is used to copy data from one RAM location to another, so it can copy to and from vars if you have the pointers.
-
Questions:
1. How do I access big fonts w/o using custom fonts?
2. Can I do this?
:Get("EAR03 →A
:Goto Lbl "BS",A
or
:"EAR03→A
:Goto Lbl "BS",A
-
1) Use Output(1 unless you mean using the OS big font instead of the built in big font
2) Use the second one (as long as you have the latest Grammer version). You can also do Goto Lbl "BS","EAR03
-
1) I'm meaning OS big font
2) I am aware of fact that I can do Goto Lbl "BS", "EAR03 . However, since the prgmAR03 works just like prgmAR02, I'll have to go back to different labels, so if I can store prgm name into pointer, it'll be much easier for me to code. :D
-
Ah that is a smart idea... however you might then need to add that to the list of pointers you need to update D:
-
Don't worry. I'm keeping the track of my pointers in my composite notebook XD/me loves to write down stuff in his composite notebook :D
-
Ah, I meant with that call that you have .M19. At the end of that you will want to update your pointer.
-
I thought I have to update my pointer only after I augment or reduce the data size D:/me just makes a separate label that updates the pointer
-
Yes :) That is why all the other pointers are updated at the end of .M19 It is when augmenting or deleting any data.
-
oh. I never knew that deleting var counts as reducing data size XP
All right! problem solved! XP
-
0→B
ClrDraw
Repeat getKey=15
If !randInt(0,4
Then
randInt(0,11→C
For(A,0,C
Pxl-On(0,randInt(0,92 //GIVES ME ERROR HERE
End
End
Text('50,0,B
DispGraph
Tangent(1,1
B+1→B
End
Stop
I don't think I did anything wrong, but it kinda freezes.
-
I used solve(3 to make an error handler to figure this one out o.o It isn't really freezing, it is doing a For( loop from 0 to 0. The simple fix is to use randInt(1,12 and For(A,1,C. :)
-
oh, crap. That's what it was XP
Okee. I'll fix that. thanks. XD
-
No problem, I like trying to find these little quirks. I should start documenting stuff like this...
-
Sooo, I need to be able to first grab the number of bytes free in the RAM, then have a large tilemap (its a set of 8x8 sprites, but it needs to be pretty large) that will initially be blank unless otherwise specified. Then I need to edit that tilemap in-game by changing the tilemap data every time a sprite is drawn. It would kind of go like this:
://Code for free bytes of RAM.
://Code for generating tilemap (later will be stored into an appvar)
:Pt-Off(0,S,0,0,1,8)
://Code for editing tilemap with new sprite.
:ClrDraw
://Code for showing tilemap
:DispGraph
-
Hmm, well to get the amount of free RAM, you would need to use assembly. You can use the AsmPrgm command to do it:
AsmPrgmEFE542444DC9
You will probably need to remove about 17 from that if you are going to create a var with all the RAM. As for drawing tilemaps, there is actually a built in command for that. Use Pt-Change( and it will let you draw a tilemap using 8x8 tiles on the screen. I made two tools to help you here, too. One of them will help you create the tileset, easily, the other is a tilemap editor that will let you make very large tilemaps:
Map Editor (http://www.ticalc.org/archives/files/fileinfo/444/44407.html)
Sprite Editor (http://www.ticalc.org/archives/files/fileinfo/444/44408.html)
The screenies look like this:
(http://www.ticalc.org/archives/files/ss/826/82679.gif) (http://www.ticalc.org/archives/files/ss/826/82672.gif)
If you need help on how to change those programs to output to a specific variable or use a certain size, let me know :) I also tend to put the editable stuff at the beginning of the program using vars like W and H for Width and Height.
Also, you can draw the tilemap each frame and then just draw the character after that so you won't have to put the character in the tilemap data itself.
EDIT: Fixed a typo
-
I guess it would help to know why I'm asking!
http://www.ticalc.org/archives/files/fileinfo/446/44632.html
Currently I'm using an alternate buffer and drawing the block sprites to that buffer, than recalling it as a background when I need to. All of the physics is determined by pixel tests, so I don't need to know what sprites are where. But if I'm going to be making the levels larger, I need to use tilemaps so I can change the view of the map when the player gets close to the edge (which I could do, if I knew how to use tilemaps!)
I want to know what the tilemap data is composed of, and how I could edit it based on the coordinates of the cursor. For example, say the cursor is at the 8th row and 8th column. How could I replace the tile at that position with the current block's sprite data?
I would like to know how the tilemaps are created so I could eventually create random tilemaps. Also, some info on the amount of memory tilemaps take up would be nice, so I can limit the generated tilemap size at the beginning of the code.
-
IIRC, tilemap data are stored as series of number (aka tile numbers). so if you have 12x8 tilemap, you'll have 96 bytes of number from 0 to 255.
Also, for tiles, it's just a series of sprites in order.
Also, I once posted the scrolling tilemap routine for Grammer. Do you want it?
-
For the sprite data, is it hex or token?
And for the tilemap data, would 00 be the first sprite, and 01 be second sprite, and 10 as the 16th?
So if I have a set of sprites and wanted to have tile data that shows the first, second then third, would it look like this?:
000102
As for the routine, sure!
-
for routine: http://ourl.ca/15015
sprite data, it can't be hex (unless you're storing in appvar or something, then ur fine.)
Same goes for map data.
-
Okay. One more thing. How could I change a specific tile in the tilemap? Like say I want to replace the tile at position (8,8) with a different tile, how could I do that?
-
I am now officially back from vacation, so here goes (be prepared). First off, though, O.O I like your game!
I completely forgot to add in a description of how maps are stores, so I will try to do it properly here :) First, each tile is stored as a single byte. The byte tells which tile to draw using the tile set you define. You can use the program I gave to make the tile set, too (it will be in the proper format for tilemaps). Tilemaps can be variable sized as long as it is big enough to fit the screen (8 down, 12 across). To edit the tilemap, I used this code in my map editor:
If getKey(9
int(G+C+X+W*Y+B/8,F
err, sorry, I accidentally clicked to submit the post. Continuing:
G points to the map data
C is the x-offset into the current region displayed
X is the x-offset into the map data
W is the width in tiles of the map
Y is the y-offset into the map
B is the y-offset (in pixels!!) into the current region displayed
F is the tile number to write
So if you want to use a 128x128 tilemap, you would need 16384 bytes of RAM free. I hope this helps a bit more?
EDIT: Also, I have been playing with GramCrft and I like it! You should post a new topic about it sometime!
-
Can the number be a variable? Say I want to change the byte to 2 and 2 is stored in F will that work?
-
Indeed it will :) That is the exact code I use in the editor, so feel free to change it up as you need and use your own variables. The tiles are stored row by row, so an offset of 2 into the tilemap data will change the tile on the top row, 3rd from the left. (the first tile is 0). So if you wanted to change the tile below that and the map had a width of 20, you would change byte 22.
EDIT: Also, I am looking at your code, and your technique is quite good so far ! I will see if I can find things to be picky about >:D Still, I am glad you search for the labels outside of the loop, that is good coding practice for Grammer :)
Hmm, found stuff! lets see, if you want to optimise for size , you can remove ending parantheses and whatnot (Grammer ignores them, anyways). Also, doing If A means "If A is not equal to zero." That is a trick that is valid in Grammer and can save a few bytes. Also, If !A means "If A is equal to zero."
Also, you have If J>0, that can be shortened to If J
(I should make a document shortcuts and whatnot sometime)
EDIT2: Oh, I see... Grammer doesn't do much with signed numbers. -1 is seen as 65535, so -1 is greater than 0 .___.
-
Cool!
But I'm still kind of new to this data editing stuff with appvars and hexcode and stuff like that. So are appvars solely hexadecimal? And when I create a new one is it just a series of zeros until I write other data to it?
And are tokens one byte each?
You say the tilemap data is series of numbers, so is it 0000 for four tiles or 00000000 for four tiles? And is zero the first tile or no tile at all? And do I need to convert the hex to token? I plan to store everything in appvars.
To save space, how can I have no tiles at a position, without having a blank sprite in the tileset? Or do I need to do that, have the blank sprite as the first sprite?
-
I think I am about to complicate matters .__.
But I'm still kind of new to this data editing stuff with appvars and hexcode and stuff like that. So are appvars solely hexadecimal? And when I create a new one is it just a series of zeros until I write other data to it?
Appvars are whatever you want it to be. However, in Grammer, you have a few ways of editing them, including writing bytes to it through hexadecimal and numbers. For example, if Z points to the appvar:
int(Z,37 will write to the first byte of data the value 37. The number is 0 to 255 and can be a variable.
Z[(111213 will write 3 bytes to Z in hexadecimal. They are 11h, 12h, and 13h. in decimal, that is 17,18, and 19.
Z[77,23,47 will write three bytes to Z, also
And there are a few more ways to do this. Basically, if you write a byte at Z+13, when you read it, it should be the same.
As for creating new vars, the data is filled with all zeros until you write to it :) It used to contain data that was not necessarily all zeros, but changed that, so that is a good question.
And are tokens one byte each?
Not all tokens are 1 byte each. Some are 2 bytes :/
I am curious about what you are going for here :D
You say the tilemap data is series of numbers, so is it 0000 for four tiles or 00000000 for four tiles? And is zero the first tile or no tile at all? And do I need to convert the hex to token? I plan to store everything in appvars.
Hmm, tilemap data is a series of bytes. So however you want to think of bytes is how tiles are stored. If you think of them as two hexadecimal digits smushed together, then 00000000. If you think of them as just solitary bytes, they can be 0000.
0 is the first tile, indeed. And there is no need to write hex or tokens as you can just do something like int(Z,0. However, if you have the data sitting somewhere you can copy it using the solve(1 command. It might be a bit tricky, though.
To save space, how can I have no tiles at a position, without having a blank sprite in the tileset? Or do I need to do that, have the blank sprite as the first sprite?
You will need a blank tile in the set :/ it does not need to be the first sprite, technically, but I normally do that. If you make it the second sprite, for example, then to write a blank tile, you would use tile 1 instead of tile 0.
-
You didn't complicate things! They make a little more sense now!
Okay final question (I think). Can I read from archived appvars? Or will I need to the unarchiving command to unarchive it before I read it?
-
Awesome! I was worried XD
If you just want to read it (and not write to it) you can copy it to a var using solve(0. So for example, if your appvar is called Data, you can do:
solve(0,"UData","V.
That will copy to a tempprog (that is what the V means) called "." Temp programs are automatically deleted by the OS, so it won't clutter up RAM. if you want to edit it, you will need to have it unarchived :/
You can also copy portions of a variable to RAM instead of the whole thing using two optional arguments to specify the size and offset :)
-
So if I wanted to copy it to a real var, would I leave out the prefix? Would it just be:
solve(0,"UData",V
...assuming V is the variable I want to put it into?
If that won't work, then how would I read the tempprog like I would a normal real variable? Do I just store the pointer into a variable for reading it?
Also, my sprite data didn't seem to work across the sprite editor to the map data. When I use the tile editor it seems to have shifted all of the sprites up 4 rows, so I have two halves of two different sprites as one sprite...
-
Okay, for your first question, you would have to copy the var to another var and then get the pointer to that var in RAM. In your example, it would use V as a pointer to the name of the var to copy to. You could do this:
solve(0,"UData","V.→D
D will point to the newly created var :)
As for the sprite editor, the actual sprite data starts 4 bytes in :) The first 4 bytes hold the data for the size and number of sprites so that the editor can read them properly. So what you can do, if the sprite file is the appvar TILES:
4+solve(0,"UTILES","V:→T
I hope that helps!
-
also, for extra facts:
solve(0,"UData","V.",40,4→D
This copies the 40 bytes starting 4th data (beginning is 0th byte, btw) to temp prgm . and stores it in pointer D.
I believe it's not in the readme but it's really helpful. :D
-
It is indeed in the readme :D Also, Apparently Ɵ' will contain the size of the created var O.o I didn't even remember adding that XD
-
Adding 4 worked! Thanks much! :D
-
Awesome! I am sure people will enjoy larger maps :D
-
Hmmm... I don't know what happened, but at first the tilemap works fine. I have a blank level and I can run around on it. However, when I reopen the program after I've run it once, it doesn't work. I have to do a RAM clear to get it working again. I'd send you the program, but I spontaneously lost it. I edited it in Doors, closed out of Doors, and I couldn't find it. Luckily I have a backup of the original that I uploaded, and the tilemap data is intact.
Also, give me a quick tutorial on grayscale. I think I want to have a background so you can have a sense of where you are in the level.
-
Okay, I am trying to think of what could be wrong D:
As for grayscale, here is what you can try:
Store pi9872 to a pointer-- this is where a 768-byte buffer is located. I'll call the pointer G, for Gray.
Now do this: Disp oG to set the gray buffer.
Now when you draw, you draw the gray stuff to buffer G and black to the normal buffer. To make white, you need to erase on both buffers.
You also need to be constantly updating with DispGraph for it to appear gray. To draw to the gray buffer, most drawing instructions will let you use an extra argument to point to the buffer. For example, to draw a rectangle to the gray buffer:
Lined(0,0,8,8,1,G
I hope that helps!
-
I'll rewrite the code and see if the problem persists...
-
Also, I am not sure if DCS7 and Grammer play poorly together. (You won't be able to run a Grammer program from DCs7, anyways, though)
-
yes. when you run dcs7, you'll have to run grammer app again in order to run grammer apps.
-
I'm aware of that. I might have lost the program because I was being really careless in my exiting of Doors. I don't like to wait, so I press the clear button about a thousand times before Doors closes. :P
But the problem might have been with the temporary programs. I'll try rewriting the code and adding a Delvar function for both temporary programs at the end, or even changing the names to something better.
-
I'm gonna get back into working on this. First I want to make a title screen so it looks all purty, and make a feature that generates an empty level tilemap and the tile set along with it, if they do not exist. That'll be a New Game, and Load Game will only appear if the two variables exist.
Just need to know how I could generate the two files in game. I guess assume I'll have the tile set at Lbl "TILESET, and I just want a tilemap variable with all tiles being the first tile. And in case I didn't say tile enough:
:While "Tile"="Tile"
:Disp "Tile
:End
I'll also eventually have an options screen where you can change the size of the generated levels, and eventually choose to have randomized or flat levels! :O
-
Well, if you already have the tileset, why copy it twice? You could also store it in an appvar and package it with your program :)As for detecting if there is a save file, here is what I do, normally:
"USave→A ;Name of the var. Save to a pointer because it'll be used a lot
Unarchive A ;Unarchive the var. (A points to the name)
If !Get(A ;Finds the var. Returns 0 if it doesn't exist.
Then
Send(4098,A ;creates the var
iPart(Ans,16448 ;writes the first two bytes as 40h,40h which is the size of the map
End
Get(A→Z ;Z points to the var
As for generating random maps, how do you want to generate it? You could do some crazy cool stuff using math to make regions of similar tiles (so you could have ponds, rock areas, and others).
Also, there is an Axe coder now doing something like this, too XD
-
Question: For tempprogs will I have to keep copying the appvar to them before I read them, or do they stay there while the program is running?
-
They remain while the program is running :) Once the program stops and control is handed back over to the OS, they get deleted.
-
Good!
Finished the title screen. I'll show this off wherever I can because I'm super proud of it. ;D
The code for drawing it is a monster, though. So many lines! :O
-
Haha, nice! :D If it is too big/slow, you could store the pic to an appvar and recall it that way. There isn't a recallpic function, but you can do something like this:
//Store Pic on screen to Appvar
Fill(8,Send(768,"UMain
If appvarMain is in RAM or does not exist, that will store the buffer to it. If appvarMain exists, but is in flash, it won't work.
To recall it, you will need to use solve(1:
Get("UMain
solve(1,Ans,37696,768 ;37696 is the graph buffer. If you are using another buffer, replace this.
-
Alright, new idea. It might play out, it might not. I think instead of using appvars I want to use programs. This would make outside editing a lot easier. Maybe even allow for a BASIC level editor. Also, I want to be able to see what the program is doing in terms of data editing, so I can understand it. Otherwise, it's just happening and I can't see it happen, I just have to trust that it's working. I think I'll start with the programs for now, and unless you think appvars are faster I'll keep on using them.
(Started playing around with Send( and Get( with programs, and when I make a program with 768 bytes, and look at it in the PRGM menu, the menu is kind of messed up. I scroll up to see the bottom of the page, and the first programs' names overlap the last ones... Otherwise it's working fine. Question marks all the way through, so must be stored as token data!)
-
Ok, I probably am to lazy to search it, but what's the best Grammer tutorial?
-
(Started playing around with Send( and Get( with programs, and when I make a program with 768 bytes, and look at it in the PRGM menu, the menu is kind of messed up. I scroll up to see the bottom of the page, and the first programs' names overlap the last ones... Otherwise it's working fine. Question marks all the way through, so must be stored as token data!)
That is weird, do you have a screenie and some code?
Ok, I probably am to lazy to search it, but what's the best Grammer tutorial?
There is one with the download that I wrote, but it isn't really good. That is currently the only Grammer tutorial that I know of :/ I have to rewrite it sometime .___.
-
That is weird, do you have a screenie and some code?
I tried to recreate it but it doesn't seem to be happening anymore. I'll keep working with it and if the problem comes up again I'll take a GIF of it.
Btw, I should make a game called Zello. It looks REALLY nice in Doors with that font. I don't know what kind of game it would be, but it just looks so good...
-
That is weird, do you have a screenie and some code?
I tried to recreate it but it doesn't seem to be happening anymore. I'll keep working with it and if the problem comes up again I'll take a GIF of it.
Btw, I should make a game called Zello. It looks REALLY nice in Doors with that font. I don't know what kind of game it would be, but it just looks so good...
Ah, okay then :) Also, which font?
EDIT:
Ok, I probably am to lazy to search it, but what's the best Grammer tutorial?
Also, TBO_Yeong is now working on a new, better tutorial :) It can be found here: http://ourl.ca/15753
-
Yes I have a question :) (sorry, I just found this topic, all my other questions were asked in other topics)
You said pointers can be numbers between 0 and 65535.
So, it would mean that we can store 65536 bytes of data in a 83+ Ram...
But I thought 83+ calc only have 32 Ko of RAM... where are the 33 other Kos ?
-
Don't know if you read this (http://ourl.ca/16064/299788) so I give you the link :)
There is nothing wrong with asking questions here of course but you'd better send her an email too and don't expect an answer within the day :)
-
eh, thanks, Hayleia...
But...
The topic or board you are looking for appears to be either missing or off limits to you.
:/
What is the problem ?
-
eh, thanks, Hayleia...
But...
The topic or board you are looking for appears to be either missing or off limits to you.
:/
What is the problem ?
According to Art of Camelot, you need 100 posts to see this topic. To sum up, Xeda has a very limited access to internet for now.
-
This question is not only for Xeda....
An Axe programmer could answer, it's the same problem...
pointers can be numbers between 0 and 65535.
So, it would mean that we can store 65536 bytes of data in a 83+ Ram...
But I thought 83+ calc only have 32 Ko of RAM... where are the 33 other Kos ?
-
Question:
This code won't work properly.
Send(760,"VBuf3→Y
Send(768,"VBuf→Z
"GPic1→A
Unarchive A
solve(1,A,Y,760
Archive A
Disp 'Z
solve(1,Y,Z,760
DispGraph
It kinda doesn't work. The screen looks kinda shifted.
What did I do wrong here?
-
pointers can be numbers between 0 and 65535.
So, it would mean that we can store 65536 bytes of data in a 83+ Ram...
But I thought 83+ calc only have 32 Ko of RAM... where are the 33 other Kos ?
There are 65536 bytes of memory, but the first 32768 are Flash pages and the last 32768 are RAM :)
@Yeong: I cannot see the problem off the bat, yet. I will see if I can figure it out.
-
But, there are more than 32768 bytes of Archive ! O.O
-
You have to switch between flash pages in order to access different parts of the archive.