Show Posts

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.


Topics - Xeda112358

Pages: 1 ... 7 8 [9] 10 11 ... 13
121
Grammer / Grammer Examples
« on: February 05, 2012, 09:13:36 pm »
Okay, so at request, I started this topic for example codes :) I will try to post a link in this post when I add new codes. The first one is a bouncing circle:
Code: [Select]
.0:Return
1→X→Y→B→C
Repeat getKey(15
Circle(Y,X,12,1   ;Draws a circle of radius 12 using pxl-On
DispGraph
ClrDraw
X+B→X
If >95            ;Since negative numbers are really big (>32768), this tests if it is negative, too
-B→B
Y+C→Y
If >63
-C→C
End
Stop

122
TI Z80 / Cellular Automata (Assembly)
« on: February 04, 2012, 04:17:34 pm »
Stemming from my attempt in Grammer, I ported my automata generator to assembly. This version takes an input through Ans for the rule set (0 to 255)  and modifies the graph screen accordingly. it starts at the top of the screen and makes its way to the bottom. Oh, and the program 114 bytes :)


EDIT: I added a picture of rule 57 because it looks so cool!

123
TI Z80 / Grammer Cellular Automata
« on: February 04, 2012, 11:39:59 am »
So Spyro543 managed to get me to create a cellular automata generator after he saw my program AUTOCELL. It isn't nearly as fast, but it works! I am going to experiment some more with this, too. Like, after scanning down, scan in the reverse!

So, to change the pattern, open up the program and modify the xx→N to a number from 0 to 255 for your favorite automata :3

Also, it messes up usually at the bottom-right because it is "testing" off screen pixels which are always zero x.x I want to make an assembly version sometime, too :3

124
TI Z80 / CODEM4
« on: February 03, 2012, 03:25:46 pm »
Okay, this a program I made a while ago (two or three years ago) that may still be useful to folks. It is a cheat code program based off of a program called CODEM that I made for an RPG (about 5 years ago). What the original did was it would take two strings (the name of the codes and the actual codes). It would then let the user select codes to use through a fancy-shmancy menu and then it would perform the codes.
The drawbacks:
Names were 16 chars, codes were 8 chars-- always
The undrawbacks:
The menu was really nice o.o It let you scroll through large numbers of codes (the program I made this for had 89 codes or something like that)


So why is CODEM in any way something you might want? Imagine this scenario:
You make a great game
You spread said game around your friends/school/internet/world
Some said folks try to cheat by modifying source codes and/or savefiles if they can figure it out
Said folks fail
Said folks break program
Said folks make an D: face and flood you with questions on how to fix it


So you might want to make the codes for them... After a few years I learned about Celtic 3 and that was when I made CODEM4 (there were a few versions before). Codem4 was a project in itself because I made a file system, code editing screen, error handling of almost any possible error (there were a few I could not do). I made all the code compressed, easy to select. It wasn't a graphical wonder, but it did have a lot of neat features that a programmer would appreciate (if not a regular person). Plus, I made it spit out a program that had everything precalculated (instead of converting codes on the fly) so running the cheat code could be done quickly and seamlessly without modifying any other variables.

Anyways, features:
If there are no code databases found, you will be prompted to create one.
You can add a description to it
if the name is already taken, you will be prompted again for a name
If you select a database with no codes, you will be prompted to add codes or not (selecting yes will take you to the code input screen).
When you select your codes and finish, the program (locked) CODEM will be created.

Now to run your cheats, you can just run prgmCODEM upon a special keypress or what have you. Of course, it is necessary that your program allows CODEM4 XD

125
Grammer / Grammer Animations
« on: February 03, 2012, 07:55:11 am »
I couldn't figure out where to put this because it is an animation that while it looks cool, probably isn't too useful for games and such. So, I figured I would make a general topic :) Plus, I have a few other animations I can dig up from a program I made a while ago called PsychaD... So the first one is interactive and based on a program Yeong made:

Controls:
Arrows move
[F1] shrinks it
[F2] makes it grow
[2nd] speeds it up
[Alpha] slows it down
[ +] adds more lines
[-] removes lines
[4] shifts the point right
[6] shifts the point left
[8] shifts the point up
[2] shifts the point down

Lots of options :3
EDIT: Okay, here is another thingy to watch .___.

127
TI Z80 / Ricochet
« on: January 25, 2012, 03:29:09 pm »
Okay, I have a game idea using a program I call Ricochet. It is coded using Grammer and it relies solely on the contents of the graph screen. I have been having fun for the past few days playing with it so far, but I finally remembered to put it on my computer to upload :)

My question is, how can I turn this into an even better, more addicting game?

Also, that isn't lag or anything you see in a few spots, it is just the tail uncurling once it has been smushed XD

To edit the size, the part that says 92→N can be changed to any other number bigger than 1. The size doesn't change the speed much at all as it only worries about the start and end of the snake thing.

128
TI Z80 / Liquid Screen
« on: January 24, 2012, 07:59:57 am »
You might be familiar with my avatar and the previous avatar, both of which make use of a neat effect. Pretty much, the screen falls and melts into a puddle. If you want to give it a try, here it is, the program I have used for these effects :) I tweaked it a little, so here is the setup:

The picture to liquefy is in Pic1. If Pic1 does not exist or is in archive, the graph screen is used instead. A horizontal line on the bottom row of pixels is drawn as a barrier. When converting the screen to particles, all of your remaining RAM is used. If you have less than 775 bytes of RAM left, though, it will not create a var and it uses AppBackUpScreen instead (holds 366 particles).

Press CLEAR to exit. Don't worry, you get your RAM back :)

If you have 12106 bytes of RAM left, you can convert the whole screen if it was all black. My logo didn't even use the 2048 byte buffer I assigned originally, though XD

129
TI Z80 / Fire
« on: January 21, 2012, 02:36:31 pm »
Okay, after having some fun with Builderboy's Flame tutorial and Deep Thought's ORG ide, I put together this little program (136 bytes). Pretty much, you send a number in Ans and this program uses that picture as fuel for a fire. If the picture doesn't exist, it just disintegrates the screen. It will keep burning until the user presses a key, too, so you can use this for an intro screen in a game!

Things I am wondering if I should add:
-making white fire instead
-using the current screen as fuel
-seeing if I could add this in as an interrupt to be disabled or enabled
-Adding in 15MHz mode

130
TI Z80 / Tic-Tac-Toe (Grammer)
« on: January 16, 2012, 12:54:52 pm »
A new game to add to your Grammer collection is here! I still need to better the animation, optimise some code out, and make a menu so users can select options (such as who is the AI). Anyways, for now, there is an AI that you can play against, so have fun :)

When you finish the game, press clear to exit, press Enter to play again.

131
ASM / Comparing bits in a register
« on: January 15, 2012, 09:51:37 pm »
I want to compare bit 5 to bit 1 and bit 4 to bit 0 in the A register (the other bits are always 0). in other words, I want to xor the two nibbles of A or something similar, but as fast as possible. To start, here is one idea:
Code: [Select]
     ld c,a
     and $F0
     sla c
     sla c
     sla c
     sla c
     xor c
That is 47 cycles, 12 bytes-- too big/slow/inelegant for me to accept as the best method.

132
ASM / I/O Help
« on: January 15, 2012, 09:29:16 pm »
Okay, I have been having a tough time with this, so I need help. I am trying to send data between two calculators and I can easily send a single bit or two bits, but nothing longer seems to work. The protocol idea that I was working with looked like this (this is an outline):
Code: [Select]
         ld b,8
Send:
         rlc c                ; get the next bit of C
         ccf                  ; inverts the c flag since writing to the port will be inverted
         adc a,a            ; rotate the bit into a
         scf                  ; sets the carry flag
         adc a,a            ; sets the first bit
         out (0),a          ; send it to the port
         dec b              ; decrements the counter
         ret z                ; ends if the counter hits 0
CheckLoop:
         in a,(0)            ; Check the port
         rra                  ; We test bit 0
         jr c,Send          ; Ready to send the next bit
         jp CheckLoop    ; Eh, keep checking
Receive:
         ld b,8
Loop:
         in a,(0)            ; check the port
         rra                  ; check the bit to see if the data was being sent
         jr c,$-3
         rra                  ; get the bit that was sent
         rl c                 ; rotate it into C
         out (0),a          ;since A is 0, this will set both bits in port 0 signaling that another bit can be sent
         djnz Loop
         ret
Actually, I just typed that up and is only vaguely like the codes I have come up with before. In any event, if I take out the counters and only send one bit, it works fine and I receive it, bit if I try to send all 8 bits, it freezes (I think the receiving end).

Thanks much! I'd love to figure this out :)

133
Grammer / Grayscale in Grammer
« on: January 11, 2012, 11:49:10 am »
I finally learned how to do grayscale properly and now I want to pass on that knowledge for Grammer programmers. This has been possible with Grammer for a while, I just never understood the theory behind making it flickerless and beautiful looking. So here goes:

For three level grayscale, we have it very easy. You have a gray buffer and a black buffer In the gray buffer, you set any gray pixels to on and leave the rest alone. In the black buffer, you set the black pixels on and leave the rest alone. Now you need to display it and this is where it gets fun.

Normally, you would have flicker and if you have ever attempted and failed grayscale like me, you know what I am talking about. So how do you get around this? You set any gray pixels on an alternating cycle. How is this achieved? You use a checkerboard pattern and use AND logic on the buffer. So every other cycle, a gray pixel is displayed, but you want to display black pixels every cycle. So you OR the black buffer with that buffer, too. So here is an example using a tilemap:
Code: [Select]
!E→E                               ;This makes E alternate between 0 and 1. This tells us the cycle we are on.
Fill(+2                              ;This uses one of the checkerboard patterns. It alternates with E
Pt-Change(0,M,G,W,X,Y,1   ;Draws a tilemap using the gray tileset with AND logic
Pt-Change(0,M,B,W,X,Y,3    ;Draws the same tilemap with the blcak tileset with OR logic
DispGraph                         ;Now display
As long as you display it enough, this will make rather beautiful 3 level grayscale. I am currently working on other levels of grayscale as well as additions for grayscale drawing (possibly).

Anyways, here are some programs to play with. I would show a screenie, but WabbitEmu cannot capture it nearly as well as it looks on an actual calculator.

EDIT: Posted a pic and that is pretty accurate with how it look on an actual calc :)

134
ASM / 68K ASM Help
« on: January 08, 2012, 08:46:14 pm »
I am just learning Assembly for the 68K series and I was wondering if anybody could provide a breakdown of how certain things work. I have a TI-89 Titanium, I consider myself a decently experienced z80 programmer, and I understand math. I have difficulty learning mnemonics, so I will probably ask questions multiple times about how certain instructions work until I solidly understand it.

The assembler I am using is an on-calc assembler that seems to work beautifully. It is the only thing I could understand how to install because my computer skills are massively lacking. Anyways, I looked at the source for a "hello world" program and I was just absolutely confused. I think that move instructions move data between registers and RAM and I believe the stack and PC, but there are operators and whatnot that I am not following. The instructions used are all unfamiliar to me:

movem.l       d4/a5,-(a7)
I am assuming this writes using d4 and a5 to the address pointed to by a7? Does the negative mean it decrements A7 ? I saw somewhere that A7 was a stack register
move.l         HeapAllocPtr*4(a5),a0
I have no clue what this syntax means. I checked out the hex and that helped me realise that it is like a 2 byte instruction followed by 0288h (which is HeapAlloc*4). But what does it mean to be right before (a5) ?
jsr              (a0)
Is this some kind of relative jump?
pea.l           3840
Does the .l mean it is a "long" operation? The hex has a 32-bit value equal to 3840. But what does pea mean and what does it do?
tst.l            d4
I cannot even begin... "tst" looks like test, so is this some way to check if an event has happened with d4?
beq.s          nomem
I haven't a clue, but since nomem is a label, does this jump
move.l        #3840,(a7)
Does this push an immediate value to the stack?
pea.l          LCD_MEM
I've not a clue... LCD_MEM seems to have a value of 4C00h, but this seems to be different from the last pea.l instruction (the hex is 4079h as opposed to 4879h, so this tells me that it is just a flag difference or a slight difference in operation from my experience with z80 hex)

lea.l          12(a7),a7
I don't get the syntax :/
pea.l          Hello_World(pc)
again, I is slightly different from the first pea.l (the hex is 487A versus 4879). This tells me that it is the same style if it were like z80
clr.l            -(a7)
I am not sure what clr.l is...


Sorry for all of the questions :/ tutorials don't generally help me much and I am still not understanding them yet, so this is why I turn to y'all. I am sure that, left to my own devices long enough, I could figure it all out on my own (I did that with z80), but I think it would be a lot neater if I could start programming soon. I am hoping that I can port some of my better known z80 attempts to 68K and  I also think this experience will be very helpful for understanding assembly on other processors. Thank you much in advance!

135
TI Z80 / Checkers (Grammer)
« on: January 06, 2012, 11:56:13 pm »
This is my so far biggest attempt at programming in Grammer. It has the basics at the moment, but when I have time I will explore adding AI (AI should not be difficult). The controls are:

-Arrows will let you move around the board
-Enter/2nd will select a piece
-Alpha ends your turn
-Clear exits the game

When you have highlighted a piece, an enlarged image is shown on the right of the playing board.

Pages: 1 ... 7 8 [9] 10 11 ... 13