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.
Okay, this isn't too big of an update, but it uses some commands from the latest version of Grammer. There are two added contols:
[xtƟn] is used to fill a rectangular region of the screen with particles. It will ignore any preexisting pixels in that region, so barriers will still remain [STAT] is used to convert the pixels in a rectangular region to particles
When you press either of these, you must move the cursor to change the size of the rectangle, then press enter.
EDIT: Also, at this point Partex is up to 462 bytes
Show Posts
Maybe I can help folks, too, but this technoplaza link is really good for me 
Oh well, maybe chickendude and I can bring life back to 68k Asm development 
