Omnimaga
Calculator Community => Other Calc-Related Projects and Ideas => TI Z80 => Topic started by: thepenguin77 on May 04, 2011, 10:51:30 pm
-
Every thread needs a creative title.
Lately, between track and homework for the AP tests, I have had almost no time to program. So I decided to start programming during school in Mimas. I decided to do Conway's Game of Life because I saw the demo for the Prizm and it looked like it would be fun to use. So I've been working on this during school for about two weeks now and finally today, it actually worked. Although, I probably would have finished this way sooner if I could have used a debugger. It's pretty frustrating to just make changes and hope the program doesn't crash.
If you don't know what Conway's game of life is, here is the general idea: Every pixel is a cell acting independently, whether the cell lives or dies is decided by a set of rules:
1. If three of the eight cells surrounding a dead cell are living, it is born
2. If there are 0 or 1 cells surrounding a living cell, it dies of loneliness
3. If there are 2 or 3 cells surrounding a living cell, it lives on
4. If there are 4 or more cells surrounding a living cell, it dies of overpopulation
To make all this happen, I use most of the extra ram page (13,608 bytes) as well as about 900 bytes of hard-coded routines to do all the checks for every bit. I use the concept of active and not active cells to speed up my simulation (if none of the cells around a cell are alive, it won't do anything next round either). I also make extensive use if IX.
Some stats:
- 160 x 160 board
- goal 16 fps (it typically does this until about 200 active cells)
Controls:
- 2nd - toggle pixel
- Y= - clear board and recenter
- Zoom - step
- Graph - start/stop
- Clear - quit
Here is the game, I've been using it all day, so it works. I'll get the source later, it was written in Mimas after all. And I think my favorite part of this game is that while the actual game is only 1,042 bytes, it expands to about 1,900 bytes of code and uses 14,000 bytes of ram.
Ironically, my name makes a pretty awesome design.
-
Nice, I like this game :D
-
Wow! Looks great! :)
Stop making epic programs. Give someone else a chance >:(
-
That is pretty darn fast. Great work ^^
-
Is that at 15MHz? Also, I never understood the game of life :(
Nice job, though, using Mimas to code games looks cool, I only use it to learn.
-
I use mimas all the time :)
-
That is pretty darn fast. Great work ^^
That was my primary goal in writing it. I wanted this thing to go as fast as possible. Although, I did get it down to about 4 fps with a space filler that filled the entire 160x160 with zebra stripes. It collapsed in on itself and the entire board was in chaos running at 4 fps.
Is that at 15MHz? Also, I never understood the game of life :(
Nice job, though, using Mimas to code games looks cool, I only use it to learn.
Yes, it's at 15MHz. There's no reason to use 6MHz because of my huge RAM requirements. I just added in a save state today, so now I'm up to 19KB.
I prefer not to use Mimas because I feel the small screen will end up leading me to make small games, but if you don't have time at a computer, it works great. I put out like 3kb of code in 4 hrs on chess, whereas this thing is only up to 1kb after 3 weeks.
-
I am very impressed! Very small and fast and i love the idea of a larger game field!
Wondering what tricks you have used in coding, and are your rules customizable at all?
-
Thanks.
As for coding tricks. My buffer is laid out like this. <Active byte> <real byte> <future active byte> <future real byte> Where the active byte is just flags to tell me which pixels I need to check and the real byte is what is actually alive. The future bytes are for calculations.
When I go to calculate it, I first search the buffer for any bytes that are active, I have this loop down to 4 t-states per empty pixel, so there's some speed. Then, when it finds an byte with active pixels in it, it calls a subroutine that throws the location in IX and puts the location of a JP table in HL. (LABEL) It then works through each bit of (IX) while increasing HL by 3 each time. When it encounters an active bit, it RET's into HL which JP's it to one of my 8 bit checking routines. These routines check the necessary 8 bits around the pixel with IX and tally up the number of living cells. When they JP back to the finishing routine. They have D = bit mask as well as E = (bit * 3). The game then sees how to handle this cell, and if it deems it alive, it OR's D into (IX + 3), sets D = $80, and JP's to DE. Which of course, JP's to a routine that sets the 8 bits around the current one as active. This all returns back to LABEL where it finishes off the byte.
When that's all done, I use a stack hack to pop and push the future bytes into the current ones and zero the futures.
My rules are currently not customizable. If I can find an efficient way to make them customizable I will though.
-
No one steal this, but I've been working on wireworld. (Read: Cellular Automata, but different) :P Axe's Arbitrary buffers are so useful! It's going to use px-test a lot :P
Nice GOL! I like the scrolling screen, but I can't use it in mine with my current method. :P
Here's an easy way to customize it, if your code is like this: Assuming your code does a sum of the pixels near it, the numbers which it checks for are variables. As in:
If Cell = Dead
If sum = a:
Birth
End
End
If Cell = Alive
If sum = b:
StayAlive
End
End
But I don't know how yours works.
-
Wow, this looks incredible. I think it's the best (and quickest) game of life I've seen. ;D
-
Willrandship, that isn't the slow part, that's actually the really easy part. :D
Here's my code: (commented for the non asm'ers.)
bitFinal: ;label
ld a, c ;variable transfer, A now equals the number of live cells around the current one
jr nz, checkDeath ;if it's living, go to checkDeath
;>>asm: most often, we will come through here with a non-living pixel
; so the fall through for jr is the fastest way to do this
cp 3 ;act like we are subtracting 3 from A
jp nz, activeRet ;if A != 3, go find the next pixel
;>>asm: most often will not be birthing a new cell, so jp is fastest
jp setIt ;go to setIt
checkDeath:
cp 2 ;act like we are subtracting 2 from A
jp c, activeRet ;if A < 2, go find the next pixel
;>>asm: this is first because most pixels that won't survive will have
; 0 or 1, not >= 4
cp 4 ;act like we are subtracting 4
jr nc, activeRet ;if A >= 4, go find the next pixel
;>>asm: 2 and 3 are more likely than 4+
setIt:
ld a, d ;if you don't know asm, stop reading
or (ix+3)
ld (ix+3), a
push hl
ld hl, activeRet
ex (sp), hl
ld d, setJPHigh
push de
ret
This is the fastest way to do these checks. There is one spot where I could shave off 10 t-states, but that would involve duplicating the setIt routine. And 10 t-states doesn't really apply here because most paths through that routine right there average to about 40 t-states, the routine that leads here takes on average 300 t-states, and the routine it runs if it is setting a live pixel is 200 t-states.
So 550 t-states is pretty good for a worst case scenario where we are making a live cell. At that worst rate, I can handle about 27,000 pixels per second.
-
Aw man wow this is cool! (Now I really want a TI-84+)
-
I'd say buy it. The casio part of the omni community is really, really focused on Prizm. I see that you every time get disappointed because the projects here are all TI-8x/NSpire. The Prizm is coming up, but there is hardly any casio fx-xxxx development.
-
The Prizm is coming up, but there is hardly any casio fx-xxxx development.
Hey, the Prizm is technically an fx- calc too :P
It's named fx-CG10 or fx-CG20 depending on your region.
-
I know, I forgot to add 'except the Prizm'
-
That is pretty darn fast. Great work ^^
That was my primary goal in writing it. I wanted this thing to go as fast as possible. Although, I did get it down to about 4 fps with a space filler that filled the entire 160x160 with zebra stripes. It collapsed in on itself and the entire board was in chaos running at 4 fps.
Is that at 15MHz? Also, I never understood the game of life :(
Nice job, though, using Mimas to code games looks cool, I only use it to learn.
Yes, it's at 15MHz. There's no reason to use 6MHz because of my huge RAM requirements. I just added in a save state today, so now I'm up to 19KB.
I prefer not to use Mimas because I feel the small screen will end up leading me to make small games, but if you don't have time at a computer, it works great. I put out like 3kb of code in 4 hrs on chess, whereas this thing is only up to 1kb after 3 weeks.
Yeah, ASM Code is indeed long but Mimas has a label assistance.
-
Update!!
Changes: (I change this every day, so I hope I get them all)
- [Window] saves and [Zoom] recalls, when you quit it is in appvar LifeSave
- Added visible playing field boundaries
- [Mode] toggles FPS limiting (you can get it up to about 30 fps with small shapes)
- [ 0 ] Recall Pic0
- About 5% increase in overall speed
Have fun.
-
Wow! This is awesome! :D
I like to play THE GAME (of life, of course).
-
Looking at your code on the previous page, might it be a good idea to replace
cp 2
jp c,activeRet
cp 4
jr nc,activeRetwithsub 2
cp 2
jp nc,activeRet?
-
This looks great ThePenguin! I like how it's possible to scroll around
-
Love the speed! :).
-
Ok, it's finally time to post the source. It's been converted from Mimas, so I'm not sure how easy it is to compile, but it's there.
This looks great ThePenguin! I like how it's possible to scroll around
Love the speed! :).
Thanks, those were actually my two goals in making this: biggest possible playing field and raw speed.
Calc84, I've actually made the code more optimized than that, but it was in a place you couldn't see. To get a look at how I handle it now, place a breakpoint at $8100 and run it :D
Edit:
Ok, I just did that, I didn't realize that BIT change s.
-
Nice, is it the same version as in the first post? If not, are you planning to post a new 8xp soon?
The Prizm is coming up, but there is hardly any casio fx-xxxx development.
Hey, the Prizm is technically an fx- calc too :P
It's named fx-CG10 or fx-CG20 depending on your region.
Indeed, also I think fx-9860G is still not dead. It's just not super active and most projects are never completed. :P
-
Well, the source and the latest version I released are exactly the same. And luckily, the little glitch I talked about doesn't really affect the program at all, so I won't put up another version until I make some more changes.
-
Ah ok cool. Good luck on fixing the glitch. :D
-
Nice, is it the same version as in the first post? If not, are you planning to post a new 8xp soon?The Prizm is coming up, but there is hardly any casio fx-xxxx development.
Hey, the Prizm is technically an fx- calc too :P
It's named fx-CG10 or fx-CG20 depending on your region.
Indeed, also I think fx-9860G is still not dead. It's just not super active and most projects are never completed. :P
I see a fx-9860g emulator on the horizon. It would very similarly to wine in that native cpu instructions would run as normal, but new code would be used to manage the hardware. Or you could say similar to TI-Boy too.
-
It would be nice indeed. If I remember the calc is pretty much the same hardware aside from the screen used and the flash memory size, right?
-
It would be nice indeed. If I remember the calc is pretty much the same hardware aside from the screen used and the flash memory size, right?
Right and this would be easier than TI-Boy because the fx-9860g does't have any opcodes the Prizm doesn't support. Plus the screen is smaller so it is easier to draw.
-
Ah ok. Would it still need a lot of extra cpu ressources, though? I'M wondering because Emu8x ran like 2-3x slower than the real calc, even if you emulated a TI-83 on a 83+SE
-
Ah ok. Would it still need a lot of extra cpu ressources, though? I'M wondering because Emu8x ran like 2-3x slower than the real calc, even if you emulated a TI-83 on a 83+SE
Well the Super H has more interrupts available and more triggers for the interrupts so that the emulator does not have to parse all of the code and can just let most of the code run as normal. It should only then be a fraction slower at the same cpu speed.
-
Ah ok, that's good then. We should probably keep this discussion for another topic, though, since we're getting a bit off-topic now. ;)
-
Wait, this isn't a Game? Another awesome project. I'd suggest making vertical scrolling hop by 8 too though, so it's more consistent.