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.
Messages - Jerros
Pages: 1 ... 3 4 [5] 6 7 ... 10
61
« on: October 03, 2010, 03:47:05 am »
Whenever I download some random programm, there's usually a version history like this:
V0.13B.54: blablabla
V3.15A.12: blablabla
or
V1.1.4C.2443: blablabla
or just
V0.2A
V1.3B
My question is, where do these random numbers come from?
I get that the higher the number, the more recent the version is.
But after an update, the version numbers seem so random...
Is there a structure or rules for this?
62
« on: October 03, 2010, 03:42:34 am »
I learned it with the 28 days too, though I didn't understand most of it. The best way to learn is to copy-paste some existing script, and then try to modifie it to see how that affects the outcome. You should really provide some standard routines with it, and then explain each line seperately. That greatly helps, and gives the reader a place to start. Also, try not to give more how's and why's than nessacery, that greatly confused me in the 28 tut. I'm making a big game now, it's nearly over 10000 lines, and I know crap about how and why it works, just that it does.  Just throwing my experiences out here, hope that helps you!
63
« on: September 19, 2010, 04:18:02 am »
Okay, didn't knew that.
In this case, problem solved.
The error was that (score) was 2 bytes, so doing ld (score), A with A=0 only resetted the least significant byte.
There's no error in the codes that I posted in the first post, so feel free to use it.
64
« on: September 16, 2010, 03:00:32 am »
Please, safe your effords untill I've checked what I stated in the third post.
Don't want to bother anyone with a problem that's already solved >.<
If, however, what I said in the third post doesn't help I'll state that.
Unfortunately I can't acces my stuff right now, but please don't waste your time on a problem that *might* not exist.
Good to see so many helpfull people though.
65
« on: September 14, 2010, 12:46:48 pm »
I think I've narrowed down the problem... I feel silly to say, but the problem might not be the way I store/show the number, but the actuall content of (score) itself... To reset the number, I simply do: LD A, 0
LD (score), A
This of course fails as soon as (score) gets bigger than 255... It also explains why only the most significant byte seems messed up, but isn't random. I haven't tested it yet (don't have acces to my stuff right now) but that's probably the whole problem... /ashamed  Hmm, I don't entirely follow your code.
It would be easier to debug if you posted the entire code and a binary.
I just don't want to be that guy that posts infinite strings of code and then states "it doesn't work". You people got better things to do than debugging over 7000 lines. But what part you don't understand? The first part is how to show a number stored in an AppVar at the 24th Byte. The second part is how to store a number there. Seems pretty straight forward to me, but if I need to clarify some things, please say so  If there's indeed no miskate in there, feel free to use these routines.
66
« on: September 12, 2010, 11:38:55 am »
Okay, the idea was to store a 1 or 2-byte number in an AppVar, then compare it to a new 2-byte number and store the biggest number (the idea of a Hi-Score:))
Secondly, I wanted to show that number.
Now, what I'm doing works only "half", in that it does show the correct number, but it's always an increment of 256 off.
This suggests that when using "b_call _DispHL" the "H" is off.
I have no idea why it randomly fills in H (it's not randomly though, but to keep things simple I won't explain/elaborate too much)
Basically, without posting the whole script, this is what I'm doing to show the stored number:
CALL Appvarstartcall ; These 3 lines just set HL to the Hi-Score, so that it's now at the adress of the 2-byte score.
LD B, 23 ; "B" is just how many times I want to inc hl to get to the right adress. For exemple's sake I use 23 here.
CALL lookup ; INC HL a couple of times to get to the right adress...
ld D, (hl) ; Load the most significant bute in D
inc hl ; inc HL to get to the adress of the least significant byte
ld E, (hl) ; And load the least significant byte in E.
ex DE, HL ; Put DE in HL so the next line works :P
b_call _DispHL ; It should show the stored hiscore now, exept that it doesn't. "D" seems to be a bit off.
.........rest of stuff.......
Appvarstartcall:
ld hl, "NameOfTheAppVar"
rst 20h
bcall(_chkFindSym)
inc de
inc de
ex de, hl
ret
lookup:
inc hl
djnz lookup
ret
The problem is either at how I show the number, or at how I store it.
If I'm not doing horrable things above at displaying the number, it must be the way I store it.
Above is how I display the number, the way I store it is:
Score .equ AppBackUpScreen
CALL Appvarstartcall
LD B, 23
CALL lookup
ld D, (hl)
inc hl
ld E, (hl)
LD HL, (score) ; Score is the current score, to be compared to the previously stored hi-score.
or a
sbc hl, de
add hl, de
CALL p, NewHiScore ; if "Score" > Hiscore, store it.
........rest of script........
NewHiScore: ; Basically store "Score" at the given adress.
CALL Appvarstartcall
LD B, 23
CALL lookup
LD DE, (score) ; score is the "new" number to store. It can hold any value between 0-9999
LD (HL), D
inc hl
LD (HL), E
ret
So one of the two (or both) is/are wrong.
Either I don't store "Score" correctly, or the way the number gets displayed is wrong.
Anyone that can shine his light and brighten my day here?
Thanks in advance!
67
« on: August 27, 2010, 02:15:12 am »
Wasn't offended, haha. People are making a big deal out of this. Sorry that my incapability of reading things right has caused trouble for you, HotDog >.< That being said, back on-topic. Though there's not much to be said anymore, thanks to you helpfull people I can now go on with my work. 
68
« on: August 26, 2010, 03:44:17 am »
Don't bother us with questions if you have problems simply because you decided to try a different route."
Q_Q Sorry, my origional question has been answered. It's just that someone else said I was doing it wrong when I posted the piece of script. So I just asked why it was wrong, because it was working fine. I know I've been a nuisance throughout the last couple of months. But look at it on the bright side, if a new programmer would read all my questions and all your answers, they can just skip all tutorials and get right at it 
69
« on: August 25, 2010, 02:32:33 am »
Oh, and I forgot to mention this earlier. If your branch table isn't right after the app header, you do need to make sure it is at an address divisible by three after subtracting $4000.
... Never paid attention to that, but even after editting it still works. Maybe I'm lucky and it the adress is divisible by 3 each time, though I don't know.
70
« on: August 24, 2010, 08:54:10 am »
Don't you need ($-$4000)/3 rather than $-$4000, though?
($-$4000)/3 doesnt work. $-$4000 does. I don't know why, I just like it when things do. Anyway, if you edit AsmDev's batch files somewhat (and change your source a bit), you won't have to go away from AsmDev and TASM.
In short, you'll need to change the compilation order to compile the first page last, add export directives to all pages except the first, and add an #include to the file for the first page so it includes the labels exported from the other pages.
Huh...? I'm sorry, but I think I'm going with my nooby "jump tree at start of second page" plan. It's slower, takes more space, but works NOW without me having to learn anything new ^_^ That a completely wrong attitude, and I'm prbably shooting myself in the foot with it, but I just love it when things work. I don't know why or how, they just do. (which has often resulted in random crashes because I had no idea what the heck I was doing). You've helped me ALOT though, thanks.
71
« on: August 24, 2010, 02:30:46 am »
The branch table is the pairs of .dw's and .db's. Unless you're not using the code you posted, you have a branch table.
My layout: - Header - Bunch of .equ's and #define macros - Program just starts, in my case with: b_call _RunIndicOff
b_call _GrBufClr
- rest of programm - somewhere in the middle there's: JumpToPage2 = $ - $4000
.dw $4000
.db 1
- and then rest of programm So I don't see why the JP as first line of the programm is necessary with this. That's slower, not to mention unnecessary.
The speed difference is neglectable, right? Besides, there's no need a that point in my program to be fast, so that shouldn't be a problem. As for the size difference, it might be ~20 more lines, hardly worth noticing. It absolutely unnecessary, no can argue with that. As calc84 said, labels pretty much are offsets. The assembler doesn't like it because it's in a different file.
I know, but there should be a way to get the actul offset of the labels right? I'd rather do the nooby jump table at the start of the second page than switching to another assembler...
72
« on: August 23, 2010, 12:29:36 pm »
Just put the label after the .dw statement. That's what labels are for, so you don't have to calculate manual offsets
Ye, but I'm pissing off my assembler with that. When I put the name of a label there, it gives the "label not found" message. I HAVE to put the offset there. But like I said, if there's really no way to check the offstes of my labels, I'll just make a jump table at the top of Page2. It might even save space, since I don't need the branch table.
73
« on: August 23, 2010, 11:35:10 am »
About the branch table thing - I dont put that at the start of my programm, and it still jumps to the right place on page 2. Since I dont put it at the start, there's no need for the JP to the ProgStart either. And appearantly my assembler doesn't want the label name after the .dw, it wants the offset. Like I said, If my label is the first thing on Page2 i just put $4000 there, but I don't want to manually count every line to calculate what offset the other labels are at, that's insane! Of course I could load a number in AppBackupScreen and then make a jump table at the first label of Page 2, which isnt much work or takes much room, but it's still cheating and a way of hiding my incompetence as a programmer, ghehe... And I'm not having ANY problems at the moment, everything is working fine. Well, I still can't jump to anyhing but the first label on page 2, but you now know why that is And don't worry, you aren't sounding rude. I should've made muself much much more clear, you're no psychic. I'm already overwhelmed by the many people willing to help me, and they're helping me ALOT, so thank you!
74
« on: August 23, 2010, 11:12:49 am »
author=calcdude84se link=topic=4102.msg57402#msg57402 date=1282575320]
Ah, that's the problem. Since they're assembled one page at a time, each page is unaware of the other's labels.
Nono, fixed that already. This assembler works like a charm, and I don't really feel like spending another week learning the psychology of a new assembler >< My only problem is that it needs to know the offset. AppDev doesn't even need me to do the: JumpToLabelPage2 = $ - $4000
.dw $4000
.db 1at the start of the program, anywhere will do. (saves a JP statement n_n) My problem is that I only know the offset of the first label on page 2 ($4000, duh), but I'd like to know how to point at any other label too! And for that, I need to know the offset of a label, which I don't. Of course it's possible to do everything with only that one jump, but that's rediculous since there's got to be a way to check the offsets of my labels. ^_^
75
« on: August 23, 2010, 10:43:12 am »
One .z80 file per page.
Page 2 looks like this:
#DEFINE NOAPPHEADER
#INCLUDE "DWEDIT.INC"
...
Long list of #defines and .equs
...
FirstLabel: ; When I need to call this one it's easy, gotta fill in $4000 and it works
; Becomes a problem when I need the offset of"labels further down.
Pages: 1 ... 3 4 [5] 6 7 ... 10
|
Show Posts