This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Xeda112358
Pages: 1 ... 132 133 [134] 135 136 ... 317
1996
« on: March 28, 2012, 12:02:41 pm »
Delete it and recreate it?
1997
« on: March 28, 2012, 12:01:58 pm »
Open it in another tab and it will scale to fit 
1998
« on: March 28, 2012, 10:11:04 am »
I like the visual o.o
1999
« on: March 28, 2012, 07:41:57 am »
Good point >.> The half carry will be fun to work through 
2000
« on: March 27, 2012, 02:47:19 pm »
Cool I started a tutorial a long time ago (that I never finished). It had a similar style, but it was aimed at BASIC programmer learning to program in hex/assembly. Here is an example from it:
-------------------------------------------------------------------
Experiment 4 Memory Editing (v.1)
-------------------------------------------------------------------
214093 ;ld hl,plotSScreen ;9340h is the address* of the graph screen buffer*
3EAA ;ld a,$AA ;$AA→a Feel free to change the "AA"
77 ;ld (hl),a ;a→(hl) This stores the value of "a" to the address at "hl"
23 ;inc hl ;hl+1→hl
77 ;ld (hl),a ;same as before
C9 ;ret ;Stop
To Use:
Simply run the program. This will edit the top left corner of the
graph screen.
Explanations:
Address- People can send you mail from anywhere because they know
your address. Your address tells where you are. Similarly, in
assembly, an address tells where each byte of memory is. Using a
hex number between 8000h and FFFFh will give you access to the RAM
(which can be edited). This is the address. It just so happens
that the graph screen has all of its data stored at address 9340h
There are 768 bytes of data for the screen and 768=0300h. So
plotSScreen (Plot Save Screen) is 9340h to 963Fh. Whenever you see
(), whatever is inside the parentheses is the address. If you see:
ld (xx),y
"y" is being stored at address "xx" and if you see this:
ld y,(xx)
Then the value at address "xx" is stored to y
PlotSScreen-The way the data is set up is that each byte is 8
pixels. If the value is 3Eh, then in binary it is 00111110. All of
the 1's are dark pixels and all of the 0's are light pixels. These
are stored in rows, so there are 12 bytes per row (96/8=12). With
64 rows, there is 768 bytes in plotSScreen (12*64=768).
That is the most complicated one out of the four sections finished (I planned to have 25 to 50, but then I never finished).
2001
« on: March 26, 2012, 03:37:30 pm »
I think that is a good idea... maybe you could have .inc files for the other z80 calcs and for shells for the calcs.
2002
« on: March 26, 2012, 03:19:16 pm »
Ah, cool. I wonder how it would be applied to Chambers...
2003
« on: March 26, 2012, 03:07:56 pm »
Ooh, FoW would add a neat element o.o I've only ever seen that in Advanced Wars, but I don't play many games, so I wouldn't have seen it elsewhere.
2004
« on: March 26, 2012, 03:05:41 pm »
That is what makes this so beautiful  It is another way of looking at things Plus, I saw the link somebody posted to the wikipedia article, and this goes through that checklist super fast in only a few steps! All you need to do is row addition, then get the 10th column of the transpose (in TI-BASIC: Matr>List([A] T,10,A to store it into list A). Then you check the list for the appropriate numbers
2005
« on: March 26, 2012, 11:43:57 am »
A few are curious about my Tic-Tac-Toe algorithm, so here it is First, I would like to give credit as well to Michael Macie. We designed this last year for a linear algebra project and it is very beautiful indeed I have modified it a bit to make it work even better with matrix row operations. First: In Tic-Tac-Toe, there are 9 positions and 8 wins. What we did is something that we have seen nowhere else and makes things amazingly less complex. As in, a child with rudimentary math skills might be able to get it. Each position we label as a to i like this: a b c d e f g h i We then assigned a matrix of win contributions to each position. I changed this to using a row of 8 elements. So, in my example, we can do: [[D1,H1,H2,H3,V1,V2,V3,D2]] where D1 is the main diagonal, H1~H3 or horizontal wins, V1~V3 are vertical wins, and D2 is the other diagonal. If a position corresponds to a win, give it a 1, like so: [a]=[[1,1,0,0,1,0,0,0]] [b]=[[0,1,0,0,0,1,0,0]] ... Et cetera. Now, reform this into a giant 9x8 matrix. This matrix remains constant. Here is where the actual algorithm come in :D Get ready... Now, the game matrix starts clean, with 0s: [[0,0,0,0,0,0,0,0]]. These are the wins. Now, say player one selects position [a]. Add its matrix to the game matrix and you get [[1,1,0,0,1,0,0,0]]. Player two will subtract from the game matrix, so it tries to: 1) Make a -3 2) Make as many -2s as possible without leaving any 2s. If you leave 2 -2s, this will make a trap for next turn. If you leave a 2, then X will win next turn. 3) Make as many 2s into 1s if you cannot do any of that. Remember, a 2 now will turn into a 3 the next move and 3 means X got 3 in a row! See how beautiful that is? For X, it follows the same algorithm, but use the negative of any of the numbers :) The really nice part is that: -You can easily include random choices of moves that fit the highest criterion. -When the game is over, use the winning matrix and any 3s or -3s are wins, so you will know exactly where to strike through for wins! Now, I would post my tic-tac-toe program, but I apparently never saved my final version (which was in english instead of french and had the bugs fixed). Instead, I will show you a screenie :)
2006
« on: March 26, 2012, 10:58:57 am »
Haha, nice!  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.
2007
« on: March 26, 2012, 09:36:52 am »
They remain while the program is running Once the program stops and control is handed back over to the OS, they get deleted.
2008
« on: March 26, 2012, 07:01:20 am »
Wow, excellent 
2009
« on: March 26, 2012, 06:59:08 am »
* Xeda112358 has jitters Just saw the email-- this is going to be an epic round two
2010
« on: March 25, 2012, 06:36:00 pm »
Well, with CPU emulators it's best to write one specifically for the CPU you're using, in Asm. That way, commands can be directly linked, like how AND functions virtually identically across instruction sets. In C, doing an AND command is much more than the single operation.
Yes, exactly. Emulating a CPU in assembly is a cakewalk because of that. The z80 is a very simple cpu that has structures that exist on almost all other newer CPUs. For example, loads, bit operations, and addition/subtraction are available on almost all CPUs and that is the brunt of the operations available on a z80. Emulating the hardware is the tough part, especially the link port (which is a little different on the Prizm, but this may be possible), the LCD, timers, and USB (which I probably won't even attempt). I hope to have enough time for this in the summer (but then again, I hope to be doing GSoC which will eat up a lot of my time).
Pages: 1 ... 132 133 [134] 135 136 ... 317
|
Show Posts
