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 - chickendude

Pages: [1]
TI Z80 / [contest '13][asm] Digger
« on: September 27, 2013, 07:17:40 am »
I don't know if i'll actually follow through with this, but i've been trying to come up with an idea for the contest. So far i've got a small engine written, i'm not sure what will really come of it though. Originally i wanted to try making one of those games where you have to dig in the ground to collect items/weapons, kill bad guys, etc., but i sorta tossed that idea. I haven't changed the name of the source file, though, so that's why the project's still called "Digger".

Now what i've got in mind is some sort of graffiti game, i was thinking you'd have to go around collecting paints, dodging police (and maybe rival crews), finding nice walls, etc. It's not all mapped out, but i'm thinking something like that would be feasible.

And a screenshot:

There are still quite a few glitches with the jump detection, but for now it supports tiles with variable (Z) heights (you can see the two tables, one has a height of 8 the other a height of 4, and the trash can has a height of 5).

Anyway, we'll see where it goes.

Other Calculators / CMonster 152
« on: May 10, 2013, 12:32:47 pm »
Has anyone tried it out? It seems Patrick Davidson's made the first (?) full assembly game for the CSE, unfortunately i don't have one to test it out.

Edit: Oh, and of course the source is included :D

This was my take on the Whack-a-mole game that we had to do for the asm category of TI-Concours:

Essentially, you're a prisoner trying to escape from prison and you have to kill the guards before they kill you. The guards match up to the keys 1-9, while you work your way through the level you'll have to press the matching button to kill the guard, if you take too long they'll pull out their gun and shoot at you. Currently there's only 3 levels (and the last level has no ending) because there was a 4kb limit and i was right at it. I already had to remove lots of text and other features to fit everything in :P It's pretty difficult and kinda frustrating, if i get around to adding more levels (and an ending) it might be worthwhile to let you save your progress/turn it into more of a Mario-style thing. Initially i'd wanted to add in items and other enemies to the actual map, but i decided against it for two main reasons:
1. lack of space (now that's not so much of an issue)
2. it's super hard as it is!

Anyway, if you've got any commentions/suggestions/ideas, i'd love to hear them. :)

ASM / Calculating angles?
« on: October 23, 2012, 08:45:26 am »
I'm trying to put together a routine that will calculate the appropriate X/Y velocity to go towards an object. What i've got now is really buggy, i think the general algorithm/idea is ok though. My biggest hurdle so far has been handling negative numbers, as none of my routines for multiplication/division seem to like negative numbers. What i'm currently doing is really just adjusting the Y velocity and not bothering with the X velocity. The general equation is something like this:
(object Y - bullet Y)/(object X - bullet X)

The X/Y velocities have 5 bits which act as a decimal place, but this doesn't let me use it. I hacked in the ability to handle negative numbers in the division routine (essentially turning all negative numbers positive, then negating the result afterward), but my multiplication routine doesn't like negatives numbers either.

ASM / Reading data directly from archive
« on: October 16, 2012, 01:46:07 pm »
Alright, so i wrote a little piece of code to swap the ROM page of the level file in and locate the first bits of data and it seems to be working perfectly. However, i am pretty sure this is only because on the emulator my FLASH is pretty much empty and it's getting loaded into the low values of $4000. Am i right in assuming that this is just "luck" and that on a regular calculator where the archive is fuller that it's possible the data file (well over 8k) will span two pages?

This is the code that i wrote, it finds the file in archive, swaps it in, and reads maplocations from a map table at the start of the data file:
Code: [Select]
push bc
ld hl,levelName_txt
rst 20h ;9 octets à (hl) dans OP1
bcall(_ChkFindSym) ;chercher le programme dans OP1
;hl = VAT, de = addresse du data
ret c ;c armé si pas encontré
in a,(6) ;il faut sauvegarder la page FLASH actuelle
ld (savePort),a
ld a,b ;b = 0 si le fichier est dans RAM
or a
ret z ;si pas dans le RAM, b = la page FLASH
out (6),a ;a = la page FLASH où est notre fichier
ex de, hl
ld de,20-6 ;-6 parce que b=1 est la première carte, on va ajouter 6
add hl,de ;il y a 20 octets avant le début du data, le nom du program, sa taille, addresse, page de FLASH, etc.
pop bc
;début du data
ld e,6
add hl,de
djnz $-1
; Aller prendre les informations dans les infos et mettre dans hl, de bc avant de lancer chargerCarte

; stuff

savePort = $+1
ld a,0
out (6),a
What can i do to handle cases where it spans more than one page? I can check to see if hl passes $7FFF, but how do i know what the next page is?

TI Z80 / Robot War 84+
« on: October 09, 2012, 09:53:02 am »
EDIT: Updated the download here with the latest version. The port is more or less complete, though i haven't added in linkplay yet (there's no more space in RAM to add it ;) ).


A couple days ago i decided that i finally wanted to play Robot War. I've been wanting to play it ever since i first heard of it nearly 6 years ago. The main issue wasn't the code (it's very well commented/organized and really easy to follow), it was the SIZE of the program. I've finally gotten the size down enough that it'll fit within the RAM of your calculator (as long as you have no other programs loaded, and you may need to delete L1-6), and thanks to Crabcake you no longer have to worry about RAM clears everytime code past $C000 tries to execute :)

There are still a couple bugs, notably there're some random tiles that get drawn to the screen during the battle engine, and i haven't tested very much. I'd really appreciate if you all could help me look for things that still aren't working, since the main part of the program has been fixed up to run under the 83+. Save files are also working, on the 83+ you'll only be able to fit one in right now (and i had to restructure the data quite a bit just to allow that). Because the 84+/SE version of Crabcake is slightly smaller, i can post an 84+/SE only version which should leave you another couple hundred bytes to play with.

This is just the Standard Edition (no linkplay), eventually it would be best to convert it into an app but i just wanted to throw together a quick playable version first.

Also, please note: i don't recommend putting this on your real calc, for a couple reasons. 1) it's largely untested and it's possible (very likely) that at some point it will crash. 2) you probably won't have enough memory (RAM) to fit it on there ;)

And if anyone knew how to get in touch with DigiTan, i'd be very grateful as well.


ASM / Any 82 programmers around? And questions about ChkFindSym
« on: October 07, 2012, 12:24:51 am »
I'm trying to port a game from the 82 to the 83/+ but none of the ROM_CALLs are equated (they all use hex addresses). I've found names to most of them in the file, but am unsure how some of them relate (or don't) to the 83+. In particular, those around the VAT/memory:
Code: [Select]
DEL_MEM      = $258D ;Deletes a region of allocated memory: HL = address DE = size
DEL_TMP      = $3606 ;Delete temporary use memory region
INSERT_MEM   = $2258 ;Allocates a region of memory: HL = size DE = address
CREATE_TMP   = $38D0 ;Create temporary use memory region
What's the difference between the the MEM and TMP versions? The program is trying to allocate memory for something but it always crashes here. It's using the CREATE_TMP/DEL_TMP routines. There's a little bit of info here:
It seems like the program is trying to recopy itself into a new program.. or something along those lines. I haven't had time to look through it too closely yet, but i've noticed in the emulator that after the ChkFindSym it returns the VAT entry for the program in HL, which seems to be correct, but the address in de pointing to the data points to somewhere in  $FEXX. Is it that the shell (zStart) is doing something funny? Because i don't see any data. I'm not too familiar with the memory routines or the structure of the calculator, i think i could just _InsertMem to the end of the program (it's for saved games), but it's such a large program (>22k) but i can't seem to find it in memory! I think in the end i will try to convert it into an app and just use app vars to save the games, but i wanted to try and get things up and running first since i don't feel like trudging through all the complications that would bring (SMC, text routines, multiple pages, etc.) just yet.

ASM / Keeping track of events in RPGs
« on: October 01, 2012, 12:38:24 pm »
I've been wondering how you can keep track of all the things you've done in a game, how you can advance while unlocking new places, opening treasure chests, NPCs coming and going, maps changing (for example, maybe a house gets built while you were out of town, or a rock gets moved). It's a lot of information to track and i don't think you want to make a second copy of every map in your game. Maybe my problem is that i have a lot of these things built into my maps when i need to somehow separate them?

ASM / Menus
« on: August 31, 2012, 05:24:47 am »
I spent a while last night trying to figure out a simple way to select the closest option beneath the currently selected option in a menu when the x coordinates aren't aligned.

Here's what i came up with:
1. Starting from the saved coordinates of the currently selected option, read the remaining coordinates.
2. If there are coordinates below, compare those coordinates to see which has the closest x value.
3. Compare the x values.

The code (for going down):
Code: [Select]
call checkEOM
ret z

ld a,(numOptions)
dec a
sub (hl)
ld b,a ;(numOptions-1)-curOption = número máximo de coordinadas que buscar

ld a,(hl) ;cur option
add a,a ;x2 por el tamaño de las coordinadas: 2 bytes por cada opción
ld e,a
ld d,0
ld hl,buttonCoords
add hl,de ;añadir offset
ld a,(hl) ;x value of current option
ex af,af' ;guardar coordinada x en a'
inc hl
ld a,(hl) ;y value of current option
inc hl ;saltar valor x de la siguiente opción
inc hl ;valor y
cp (hl) ;compare current y coordinate to the next option until we reach an option on the next line or there are no more entries
jr nz,w2Down_found
djnz w2Down_loop ;repeat until no more entries left
;si no hay más opciones debajo de nosotrxs, simplemente avanzar a la próxima opción
ld hl,curOption
inc (hl)
dec hl ;retroceder a la coordinada x
ex af,af' ;a = x value of curOption
sub 4 ;ajustarlo un poco porque las coordinadas son guardadas unos 9 píxeles a la izquierda del texto
jr nc,$+3
xor a
ld b,a ;guardarlo
ld c,$FF ;c = the nearest x value to our current x
;basically repeat until the next value is further away from the current x than the previously checked value.
; since we only check the line below, if one entry starts to get further away, all the rest of the entries on
; that line must also get further away
ld a,b ;recall x value
sub (hl) ;subtract x value of the new coordinate
jr nc,$+4
neg ;if it's negative, make it positive
cp c ;check if it's closer or further away
jr nc,w2D_update ;if it's further away than the previous coordinate, exit
ld c,a ;otherwise, update c and continue
inc hl
inc hl
jr w2D_f_loop
ld de,buttonCoords+1
sbc hl,de
ld a,l
rra ;/2
ld (curOption),a

ld a,(numOptions)
dec a
cp (hl) ;check if numOptions-1 = curOption (ie si quedan más opciones)
I have a list of coordinates for each menu item, (x,y). What i do is check first if we are at the end of the coordinates list, load how many items are left after the currently selected item into b. Then loop until we get to either the first item with a higher y coordinate or reach the end of the list. If we reach the end of the list and we're still at the same y coordinate, just move to the next item. Otherwise, compare the items on that row until they start getting further away from the current x value, and jump to that item.

I think my algorithm is a little bloated, or at least it seems like a lot of code for something that doesn't seem all that complicated.

ASM / Normal stack range on the 83+
« on: July 05, 2012, 09:07:09 am »
I'm pretty sure in the normal running of the calculator, you rarely will have more than 50 bytes of data pushed onto the stack. Where exactly does the stack start? I always assumed it started (or rather, ended) at $F000, but that's like 4kb of stack space. Is there any reason you shouldn't touch this area if you know your program won't come close to touching it? And where exactly does the stack... end? I was just looking through the source to a program and i think it uses that area for variables/as a gbuf for its grayscale routines.

ASM / My first 68k asm program: a small sprite routine
« on: June 13, 2012, 02:41:03 am »
Last night i spent several hours writing a really simple sprite drawing routine. I'm curious if anyone could give me any comments or suggestions on the code. For some reason, i had a lot of trouble trying to rotate the pixels from one register into another so i just doubled the size of the sprite  :-[ (initially i was using all bytes)
Code: [Select]
move.b #0,d0 | X
move.b #20,d1 | Y
lea spriteBox,a1
jsr drawSprite

movea.l AMS_jumptable,%a5 | load the AMS jumptable to a5
movea.l 4*ngetchx(%a5),%a5 | ngetchx()
jsr (%a5)
bra exit

| drawSprite: draw a sprite to LCD
| d0 = X position
| d1 = Y position
| a1 = sprite location
move.b d0,d2 | save X coord
and.b #0x07,d0 | how much we need to rotate the sprite
mulu #30,d1 | i think the screen is 30 bytes wide?
lea LCD_MEM,a0 | start of LCD_MEM
add d1,a0 | add the Y offset to a0
lsr #3,d2 | shift d2 (xCoord) right 3 bits
add d2,a0 | add X offset to a0
move.b #7,d2 | display 8 rows
move.w (a1)+,d1 | put the byte of data into d1
lsr.w d0,d1 | rotate byte of data 'd0' bits to the right
eor.w d1,(a0) | xor (ExclusiveOR) the byte (well, word) into a0 (the LCD)
lea 30(a0),a0 | shift down a row
dbra d2,screenLoop | it's beyond me why d2=7 will draw 8 rows... it must break on -1?

.byte 0b11111111,0
.byte 0b11111111,0
.byte 0b11100111,0
.byte 0b11000011,0
.byte 0b11000011,0
.byte 0b11100111,0
.byte 0b11111111,0
.byte 0b11111111,0
It's also kinda weird that the dbra/deq both break on -1 and not 0. Being able to rotate a byte by X/register number of bytes is pretty cool, though :D How exactly does that work? Will rotating a byte 5 times take longer than rotating it 3 times? I assume so, but i don't know anything about the size/speed of 68k instructions... I also don't know if "lea 30(a0),a0" is faster than "adda #30,a0", but i like being able to use all the address registers sort of like the z80's index registers (ix/iy).

And, the LCD: it took me a long time to get the sprite drawn right, the screen is 160 pixels wide, or 20 bytes, why does it seem like it's 30 bytes wide? How many bytes tall is LCD_MEM? Could you use the bytes to the right of the screen for smoothscrolling in a tilemapper, for example? Next up, a simple tilemapper :D

I may have asked this before, too, but why do numbers (except addresses?) need to be prefixed by a pound (#) sign? At first i thought it was to signal a decimal value, but later i realized you need to put it before all numbers.

And does anyone have a list of saferam areas for the 89? Is there a graph buffer somewhere?

ASM / Enemies and objects
« on: June 05, 2012, 02:10:20 pm »
Currently what i do is just load a list of enemies when i go to load the map and run through and update the entire list each frame. Really it doesn't take so long and even with maybe 20 enemies the slow-down isn't that noticeable, but i think i will probably just build them into the map so that they are triggered when you reach a certain tile. I'm not sure how large the final levels will be. Anyway it wouldn't be too difficult to do, i've just been lazy and not really sure if there are better ways to do it.

I've also never done enemy routing/paths, will i need to touch any trig? Right now the enemies just kinda fly around and bounce off the walls, which i think is pretty interesting and a little funny even but maybe not so practical for the final game.

I guess it's not really anything i desperately need help with as most of the code's already written, but it'd be fun to talk about something here and hear your ideas (and not just ASM programmers, since i imagine the concept would be basically the same), i learned a lot from the old tilemap discussions over at RevSoft and MC.

ASM / [68k] TIGCC under Linux?
« on: January 29, 2012, 06:32:47 pm »
I've been trying to get tigcc/ktigcc and tiemu installed all day, but can't get anything to work. I found some precompiled binaries on the tigcc website and they seem to work (spits out a .89y file), but i can't actually test as i can't get TiEmu running (it complains about some kde libs, i think my version is too new?) and the same with ktigcc. Does anyone currently have either running on their Linux distro? Thanks :)

Pages: [1]