o.o Cool! And I know there have suddenly been a lot of TI-89 or other 68K developers suddenly around, so maybe we can make it for all platforms We can be the Board Game Makers Guild
Hmm, if it was a computer, I'd say that appvar name looks pretty suggestive, but if you have known issues with your flash, it could just be getting worse
I am already learning a decent amount, I think and since I learned z80 hex in terms of TI-BASIC, then z80 mnemonics using z80 hex and now M68k in z80 terms, I think I can break it all down to BASIC Maybe I can help folks, too, but this technoplaza link is really good for me
EDIT: Okay, so for now I have been learning C for the TI-89 instead. It was really easy to download and install TIGCC and TiEmu and that really helped a lot. I got excited with it, so I made a program to draw inverted lines whos endpoints bounce around the screen at different speeds. It is 299 bytes on calc, so I think that is a decent size.
Spoiler For Spoiler:
#include <tigcclib.h>
void _main(void) { void *kbq = kbd_queue(); int x, y, c, d, a, b, e, f, key; x=y=key=a=b=0; c=1; d=2; e=3; f=2; clrscr(); while (key != 263) { DrawLine(x,y,a,b,A_XOR); x=x+c; y=y+d; a=a+e; b=b+f; if (x==0) { c=-c; } if (x>149) { c=-c; } if (y==0) { d=-d; } if (y>89) { d=-d; } if (a==0) { e=-e; } if (a > 149) { e=-e; } if (b==0) { f=-f; } if (b > 89) { f=-f; } OSdequeue(&key, kbq); } }
Yeah, I am searching sites like UTI that have a section for z80 and 68k assembly, but I have found almost nothing Oh well, maybe chickendude and I can bring life back to 68k Asm development
Also, the 89's LCD is like the 86's, right? In that you don't have to send data to a port to update, just an address in memory? You could make a grayscale pong
That is what I want to do And yes, the LCD is mapped to RAM, so it should make grayscale fairly easy
EDIT: Oh, and i've also learned quite a bit, so thanks for bringing this discussion up. There's a few boards at yAronet which have (well, had ) a lot of discussion on 68k asm programming, it might be fun to look through their old programming help archives. A lot of really knowledgeable people post(ed) there, you'll probably recognize a few of their names from games you've played.
This has so far been very helpful, thanks! I wonder what my first program should be... maybe a bouncing thing or pong? Thank you much for your help so far!
Wow, thank you much! And I am okay with sharing what I learn, but I may be the weaker individual, so you may be doing most of the sharing Also, I know a little french, so some of the french documentation might help me. I have never had to read any technical stuff in french, though.
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!
Okay, time for a new command, ay? Well here goes: CPIR CPIR can be an extremely useful and powerful command, especially if you are doing a search. What it does: It performs cp (hl) then it decrements BC and increments HL. If the byte was a match, the loop stops and PE is the flag state of the parity/overflow flag and the other compare flags are affected normally. If BC reaches 0, the parity flag is PE.
As an example, if you want to find and jump to a certain line in an executing program, you can do something like this:
;Inputs: ; DE is the line to jump to ; (965Bh) points to the start of the program ; (965Fh) points to the end of the program ;Notes: ; The two addresses above are set accordingly while a BASIC program is running push de ld de,(965Bh) ;This is the start of the currently running program ld hl,(965Fh) ;This is the end of the currently running program or a sbc hl,de ;HL is now the size of the program ex de,hl ld b,d ld c,e pop de dec hl ;HL points to the start of the program ;DE is the line to jump to ;BC are the size of the program ;A is the newline token SearchLoop: dec de ld a,d \ or e jr z,StoLine ld a,3Fh cpir ret nz ;this means BC hit 0. In other words, the line does not exist. ;the byte is 3Fh, but we need to make sure that it is not part of a two-byte token dec hl \ dec hl ld a,(hl) inc hl \ inc hl cp 7Eh \ jr z,SearchLoop+5 cp $AA \ jr z,SearchLoop+5 cp $BB \ jr z,SearchLoop+5 cp $EF \ jr z,SearchLoop+5 cp 5Fh \ jr z,SearchLoop sub 5Ch \ jr c,SearchLoop sub 7 \ jr c,SearchLoop+5 jr SearchLoop StoLine: dec hl ld (965Dh),hl ;this loads the address to the BASIC program counter ret It can probably be optimised a little, but I am sure you get the idea
If it looks good enough, you can probably do 2 scrollable maps to save memory. I think it will still look good. It will just look like you are transferring to a new section, right?
I think I could make a game like that... Hmm, I will have some fun with trying to come up with a game using particles. Also, it is possible to use more than one particle type, you just have to cycle each buffer separately, so I might be able to add a way to use the particles available instead of just toggling them.
Thanks! The "bubbles" are there because that is just how the particle routine works the "bubble" of a blank pixel gets caught underneath all of those falling pixels and makes it look neat
This was to Floppus, but I lost internet connection for a while: Dang, I must have messed up big time somewhere. You are right, that routine really does not work at all. Now I need to figure out where I went wrong because I was sure I had a working version
I think you over counted your cycles, too o.o What I did to make things easier was to remove the code that stripped the leading zeroes and that alone has a worst case of 404 cycles and best case of 327 cycles. pretty much, it is 316+11b where b is the number of bits in A (b=0 is the trivial case and I am not counting that). Your routine is still eluding me how to best analyse it, though, but I think it is a lot faster than you thought and better than the normal routine.
Show Posts
We can be the Board Game Makers Guild 
Oh well, maybe chickendude and I can bring life back to 68k Asm development 