Finding free memory to put stuff...
02-11-2006, 09:57 PM
#1
Member
Thread Starter
iTrader: (2)
Join Date: Jun 2002
Posts: 248
Likes: 0
Received 0 Likes
on
0 Posts
Finding free memory to put stuff...
I guess I sidetracked the WB patch thread enough... sorry about that.
My question is this - once you get an A/D conversion output, for instance, how do you know where to store the data without causing your engine to instantly put a piston through your intake?
I mean, in the beginning of disassemblies, are the lists of RAM addresses (I think?). Now at first I thought that if it wasn't listed there, that it would be a free slot...but... now I see that isn't the case. The actual program code points to several RAM(?) locations that aren't declared(?) in the beginning.
(Sorry for all the question marks, I'm working on terminology)
My question is this - once you get an A/D conversion output, for instance, how do you know where to store the data without causing your engine to instantly put a piston through your intake?
I mean, in the beginning of disassemblies, are the lists of RAM addresses (I think?). Now at first I thought that if it wasn't listed there, that it would be a free slot...but... now I see that isn't the case. The actual program code points to several RAM(?) locations that aren't declared(?) in the beginning.
(Sorry for all the question marks, I'm working on terminology)
02-11-2006, 10:25 PM
#2
Supreme Member
iTrader: (1)
Join Date: Apr 2004
Location: Browns Town
Posts: 3,178
Likes: 0
Received 3 Likes
on
3 Posts
Car: 86 Monte SS (730,$8D,G3,AP,4K,S_V4)
Engine: 406 Hyd Roller 236/242
Transmission: 700R4 HomeBrew, 2.4K stall
Axle/Gears: 3:73 Posi, 7.5 Soon to break
They are all declared at the beginning from what I know but they do not indicate the size. They could be double words but listed as a single entry.
Best to avoid using a non "=" address if you can't confirm it is a single byte being used on the one before it.
If the code is looking at an address that is not "EQU" or "=" at the begining, then the assembler may have a problem with it and throw errors. Maybe the dis-assembler did not pick them all up?
Best to avoid using a non "=" address if you can't confirm it is a single byte being used on the one before it.
If the code is looking at an address that is not "EQU" or "=" at the begining, then the assembler may have a problem with it and throw errors. Maybe the dis-assembler did not pick them all up?
02-12-2006, 03:46 AM
#4
I went through the declaration section and looked for skips.
Some things you know are FDB's. The rest you can do a search on the address and see if any STD commands are used. There are a few values that are mostly used as LDAA.
But if you search, you'll find that the initial loop where the value is calc'd uses a STD. RPM/12.5 is one that I know of in 8D. Then you can also edit your aldl list to monitor that location to see if it gets used.
I still need to get around to moving the stack in our version of aujp. We're almost out of the stock free stuff.
A dedicated text editor is invaluable for this kind of stuff.
Some things you know are FDB's. The rest you can do a search on the address and see if any STD commands are used. There are a few values that are mostly used as LDAA.
But if you search, you'll find that the initial loop where the value is calc'd uses a STD. RPM/12.5 is one that I know of in 8D. Then you can also edit your aldl list to monitor that location to see if it gets used.
I still need to get around to moving the stack in our version of aujp. We're almost out of the stock free stuff.
A dedicated text editor is invaluable for this kind of stuff.
02-12-2006, 08:50 AM
#5
Supreme Member
iTrader: (1)
Join Date: Apr 2004
Location: Browns Town
Posts: 3,178
Likes: 0
Received 3 Likes
on
3 Posts
Car: 86 Monte SS (730,$8D,G3,AP,4K,S_V4)
Engine: 406 Hyd Roller 236/242
Transmission: 700R4 HomeBrew, 2.4K stall
Axle/Gears: 3:73 Posi, 7.5 Soon to break
I was playing with stack last night in the sim to see how much it was being used. Starts at $01FF and goes to $01C3 (actually $01C2 in case 1C3 is a dw)
Stack operates backwards from the $01FF and after doing some checking, it never went beyond 10-15 positions. Having 30 dw slots there definatly leaves a few to play with.
Couldn't sim all functions but need to look at the comm and MUX routines to see if they do go deeper.
Also I looked at using $01A9 to $01AC as free in AUJP.
Stack operates backwards from the $01FF and after doing some checking, it never went beyond 10-15 positions. Having 30 dw slots there definatly leaves a few to play with.
Couldn't sim all functions but need to look at the comm and MUX routines to see if they do go deeper.
Also I looked at using $01A9 to $01AC as free in AUJP.
02-12-2006, 09:10 AM
#6
Supreme Member
iTrader: (1)
Join Date: Jan 2002
Location: garage
Posts: 4,432
Likes: 0
Received 1 Like
on
1 Post
Engine: 3xx ci tubo
Transmission: 4L60E & 4L80E
Originally posted by Z69
I still need to get around to moving the stack in our version of aujp. We're almost out of the stock free stuff.
A dedicated text editor is invaluable for this kind of stuff.
I still need to get around to moving the stack in our version of aujp. We're almost out of the stock free stuff.
A dedicated text editor is invaluable for this kind of stuff.
Emacs seems work well. It does both text and binary. I only view binary with it. It also does split windows and makes it easier moving text between two files. It is a great code editor for many programming languages. Using one editor for everything makes you learn more features and become more efficient.
02-12-2006, 09:17 AM
#7
Supreme Member
iTrader: (1)
Join Date: Apr 2004
Location: Browns Town
Posts: 3,178
Likes: 0
Received 3 Likes
on
3 Posts
Car: 86 Monte SS (730,$8D,G3,AP,4K,S_V4)
Engine: 406 Hyd Roller 236/242
Transmission: 700R4 HomeBrew, 2.4K stall
Axle/Gears: 3:73 Posi, 7.5 Soon to break
Originally posted by junkcltr
MonteCarSlow's NVSRAM module changes everything.
MonteCarSlow's NVSRAM module changes everything.
but it does create some nice oportunities.
Trending Topics
02-12-2006, 09:40 AM
#8
Member
Thread Starter
iTrader: (2)
Join Date: Jun 2002
Posts: 248
Likes: 0
Received 0 Likes
on
0 Posts
You guys are talking over my head again... 
I don't understand the stack completely, but wouldn't it be a bad idea to use it? For instance, what if your addition skewed the stack by one?
I guess what I can do is find some useless value like EGR position (
) and delete any references to it, but I would much rather find a black space to put it...
I don't understand the stack completely, but wouldn't it be a bad idea to use it? For instance, what if your addition skewed the stack by one?
I guess what I can do is find some useless value like EGR position (
) and delete any references to it, but I would much rather find a black space to put it...
02-12-2006, 10:29 AM
#9
Supreme Member
iTrader: (1)
Join Date: Apr 2004
Location: Browns Town
Posts: 3,178
Likes: 0
Received 3 Likes
on
3 Posts
Car: 86 Monte SS (730,$8D,G3,AP,4K,S_V4)
Engine: 406 Hyd Roller 236/242
Transmission: 700R4 HomeBrew, 2.4K stall
Axle/Gears: 3:73 Posi, 7.5 Soon to break
Sorry, referencing an add on part that gives you a TON of free memory to work with. https://www.thirdgen.org/techbb2/sho...64#post2740464
Unfortunatly that bin you are working is not one I'm familiar with (or not many others I guess) so you'll be doing allot of checkin addressing and usage to confirm a location is available for use.
Confirmed black space would be the best so nothing else is possibly boogered up.
The stack location in your code should be the first "LDS" you see.
From that address backwards you can look in your EQU "=" 's to see the end of it. It will be the next address down from that stack
Code section starting point
LDS $01FF ; Loads the stack
See how the numbers jump to the $0400's.
the value just before the $0400 is the end of the stack.
Using a single entry two addresses above that (bottom) value "should" be ok (ie: $01C2 $ $01C3 for a 16 bit use).
You would be using space that is allocated for the stack but is never used.
Get it ?
Unfortunatly that bin you are working is not one I'm familiar with (or not many others I guess) so you'll be doing allot of checkin addressing and usage to confirm a location is available for use.
Confirmed black space would be the best so nothing else is possibly boogered up.
The stack location in your code should be the first "LDS" you see.
From that address backwards you can look in your EQU "=" 's to see the end of it. It will be the next address down from that stack
Code section starting point
LDS $01FF ; Loads the stack
Code:
L01C1 EQU $01C1 ; LO OCTANE RETARD MOD'ER, FINAL L01C2 EQU $01C2 ; STACK LOCATION 01C2 TO 01FF L0456 EQU $0456 ;Save Main spark advance, (HU ADDR) ; EXTERNAL HUD RAM L0457 EQU $0457 ;COOL COMP SPK ADV FM 3D LU(HU ADDR); EXTERNAL HUD RAM L0458 EQU $0458 ; HI WAY SA, (HU RAM) ; EXTERNAL HUD RAM L0459 EQU $0459 ; SAV SPK FOR (HU ADDR) ; EXTERNAL HUD RAM
the value just before the $0400 is the end of the stack.
Using a single entry two addresses above that (bottom) value "should" be ok (ie: $01C2 $ $01C3 for a 16 bit use).
You would be using space that is allocated for the stack but is never used.
Get it ?
02-12-2006, 01:19 PM
#10
Member
Thread Starter
iTrader: (2)
Join Date: Jun 2002
Posts: 248
Likes: 0
Received 0 Likes
on
0 Posts
Got it.
But the way the stack was explained to me (perhaps incorrectly), was it was sort of a pile of papers. Things get sent to the stack, and you can only see what's on top.
But assuming you're correct, in that it's just a standard memory location, how would I go about confirming that:
1) Nothing is already using that location (i.e. double word like you mentioned before)
and
2) Sending something to that address won't muck it all up?
But the way the stack was explained to me (perhaps incorrectly), was it was sort of a pile of papers. Things get sent to the stack, and you can only see what's on top.
But assuming you're correct, in that it's just a standard memory location, how would I go about confirming that:
1) Nothing is already using that location (i.e. double word like you mentioned before)
and
2) Sending something to that address won't muck it all up?
02-12-2006, 02:40 PM
#11
Supreme Member
iTrader: (1)
Join Date: Apr 2004
Location: Browns Town
Posts: 3,178
Likes: 0
Received 3 Likes
on
3 Posts
Car: 86 Monte SS (730,$8D,G3,AP,4K,S_V4)
Engine: 406 Hyd Roller 236/242
Transmission: 700R4 HomeBrew, 2.4K stall
Axle/Gears: 3:73 Posi, 7.5 Soon to break
Originally posted by ryan.h
Got it.
But assuming you're correct, in that it's just a standard memory location, how would I go about confirming that:
1) Nothing is already using that location
Got it.
But assuming you're correct, in that it's just a standard memory location, how would I go about confirming that:
1) Nothing is already using that location
Just check that anything using the Previous address is not using a store D or other command that would make the value a 16 bit.
Testing by sending something there would work if you could tell if something got messed up from it. Not easy to have all conditions happen to be sure.
02-12-2006, 06:03 PM
#12
Supreme Member
iTrader: (1)
Join Date: Apr 2004
Location: Browns Town
Posts: 3,178
Likes: 0
Received 3 Likes
on
3 Posts
Car: 86 Monte SS (730,$8D,G3,AP,4K,S_V4)
Engine: 406 Hyd Roller 236/242
Transmission: 700R4 HomeBrew, 2.4K stall
Axle/Gears: 3:73 Posi, 7.5 Soon to break
Your other Post
[i] quoted from Ryan.h[i]
Okay, new question... I have the code I need.
I picked the memory location as above...
An ALDL address that was pointing to a redundant TPS A/D raw count will be changed to this stack value. (Who needs TPS% AND TPS raw?) Now, changing that address using the patch method is simple enough. BUT, when you have new code like above, that you need to add to the program loop....
How do you do it? I'm guessing I have to disassemble the whole binary, stick that in the main loop, and assemble it. I HOPE that's not the case, because I have had extreme difficulty just disassembling the stupid binary.
edit: The disassembly shows subroutines at the bottom, followed by a few dozen lines of
I assume this just means "woohoo! free space!". But then the question remains, which line(s) do I change to call the new sub I create here?
Okay, new question... I have the code I need.
Code:
:-------------------------------------------------------------------------------- ldaa #0x00 ;select channel 00 jsr LF642 ;DO MUX READ staa L01DE ;store value in stack --------------------------------------------------------------------------------
An ALDL address that was pointing to a redundant TPS A/D raw count will be changed to this stack value. (Who needs TPS% AND TPS raw?) Now, changing that address using the patch method is simple enough. BUT, when you have new code like above, that you need to add to the program loop....
How do you do it? I'm guessing I have to disassemble the whole binary, stick that in the main loop, and assemble it. I HOPE that's not the case, because I have had extreme difficulty just disassembling the stupid binary.
edit: The disassembly shows subroutines at the bottom, followed by a few dozen lines of
Code:
:-------------------------------------------------------------------------------- FDCC .byte 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00 FDD4 .byte 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00 FDDC .byte 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00 --------------------------------------------------------------------------------
Go to http://www.moates.net
File uploads and downloads
Hacs and stuff (whatever its called and look for "AUJP_JP2.zip"
There are good note in the beginning of the file that explain some memory locations. Will help clarify what I'm saying.
Last edited by JP86SS; 02-12-2006 at 09:36 PM.
02-12-2006, 06:26 PM
#13
Check out the 8d ve patches.
They stick the new VE table in blank space.
The easiest way to find empty space is to look at the bin in hex. Then just track down a ram value and get to writing.
They stick the new VE table in blank space.
The easiest way to find empty space is to look at the bin in hex. Then just track down a ram value and get to writing.
02-12-2006, 07:35 PM
#14
Member
Thread Starter
iTrader: (2)
Join Date: Jun 2002
Posts: 248
Likes: 0
Received 0 Likes
on
0 Posts
Re: Your other Post
Originally posted by JP86SS They are hardware control of the ECM (Trouble will result 
)
)
btw, the AUJP_JP2 commented disassembly is brilliant. I wish mine was so well done, it would make everything so much easier.
I downloaded the 8D VE patch, but I don't have a AUJP disassembly to compare to...
A little help?
02-12-2006, 09:06 PM
#15
Supreme Member
iTrader: (1)
Join Date: Apr 2004
Location: Browns Town
Posts: 3,178
Likes: 0
Received 3 Likes
on
3 Posts
Car: 86 Monte SS (730,$8D,G3,AP,4K,S_V4)
Engine: 406 Hyd Roller 236/242
Transmission: 700R4 HomeBrew, 2.4K stall
Axle/Gears: 3:73 Posi, 7.5 Soon to break
Re: Re: Your other Post
Originally posted by ryan.h
AUJP_JP2 commented disassembly...
.. but I don't have a AUJP disassembly to compare to... A little help?
AUJP_JP2 commented disassembly...
.. but I don't have a AUJP disassembly to compare to...
A little help? The file is good but still has errors like shift light commenting etc.
should be able to directly compare them.
02-12-2006, 09:10 PM
#16
Supreme Member
iTrader: (1)
Join Date: Apr 2004
Location: Browns Town
Posts: 3,178
Likes: 0
Received 3 Likes
on
3 Posts
Car: 86 Monte SS (730,$8D,G3,AP,4K,S_V4)
Engine: 406 Hyd Roller 236/242
Transmission: 700R4 HomeBrew, 2.4K stall
Axle/Gears: 3:73 Posi, 7.5 Soon to break
Edit: WAIT, My brain is on eggs!
You had $F*** addresses, could have sworn they said 3f** numbers.
OK then that area is free to use for code.
Anything after your main code section could be used. It is not dynamic ram, meaning it can't change on the fly. Can be used for code that manipulates the "ram" values though.
don't go into the very bottom area where the interrupt vectors are located.
That stuff at the very bottom.
You had $F*** addresses, could have sworn they said 3f** numbers.
OK then that area is free to use for code.
Anything after your main code section could be used. It is not dynamic ram, meaning it can't change on the fly. Can be used for code that manipulates the "ram" values though.
don't go into the very bottom area where the interrupt vectors are located.
That stuff at the very bottom.
Last edited by JP86SS; 02-12-2006 at 09:17 PM.
02-12-2006, 09:16 PM
#17
Member
Thread Starter
iTrader: (2)
Join Date: Jun 2002
Posts: 248
Likes: 0
Received 0 Likes
on
0 Posts
Re: Re: Re: Your other Post
Originally posted by JP86SS
Ok, I'm hanging on to that one
The file is good but still has errors like shift light commenting etc.
should be able to directly compare them.
Ok, I'm hanging on to that one
The file is good but still has errors like shift light commenting etc.
should be able to directly compare them.
bahahahaha! I had no idea what you were talking about there, then it hit me.
So do I come across as an idiot, or just stupid?
Yeah, it's been one of THOSE days.
02-12-2006, 09:18 PM
#18
Supreme Member
iTrader: (1)
Join Date: Apr 2004
Location: Browns Town
Posts: 3,178
Likes: 0
Received 3 Likes
on
3 Posts
Car: 86 Monte SS (730,$8D,G3,AP,4K,S_V4)
Engine: 406 Hyd Roller 236/242
Transmission: 700R4 HomeBrew, 2.4K stall
Axle/Gears: 3:73 Posi, 7.5 Soon to break
That's ok, I just typed a whole post that was incorrect and had to be changed because I didn't read it correctly.
02-12-2006, 09:18 PM
#19
Member
Thread Starter
iTrader: (2)
Join Date: Jun 2002
Posts: 248
Likes: 0
Received 0 Likes
on
0 Posts
Originally posted by JP86SS
[B]Edit: WAIT, My brain is on eggs!
OK then that area is free to use for code.
[B]Edit: WAIT, My brain is on eggs!
OK then that area is free to use for code.
I was scared for a while, trying to figure out where I'd put the "new code"...
02-12-2006, 11:21 PM
#20
Member
Thread Starter
iTrader: (2)
Join Date: Jun 2002
Posts: 248
Likes: 0
Received 0 Likes
on
0 Posts
Okay, one more question. (and then several more after)
I'm starting to pull together a patch file. Here's what I have so far:
Here is the O2 read code from the original bin:
I figure this little routine would be a good chance to jump to my WBO2 reading routine.
So, if I change the "jsr LF5C2" to my new routine at $FDDA (by changing it to "jsr LFDDA"), then I should be good to go... right? riiiight?
Additionally, how do I change the start of my sub to a label? Or is that done automagically when it's compiled? Fweew... now I think I can get some sleep.
I'm starting to pull together a patch file. Here's what I have so far:
Code:
;READING WIDEBAND: ;--------------------------------- ORG $FDDA ;location of free EPROM memory ldaa #0x00 ;select channel 00 jsr LF649 ;DO MUX READ (LF642=ARUR bin) staa L01DE ;store value in stack jsr LF5C2 ;Do original O2 read jump rts ;return to original O2 read sub ;---------------------------------- ;--------------------------------------- ;Change: addr 9019 from 00 ->01 ; addr 901A from 6D ->DE (222) ;This is to output WB to ALDL datastream, instead of 2nd TPS ORG $9019 FCB 1 FCB 222
Code:
;------------------------
; GET O2 A/D COUNTS
;------------------------
B844 LB844:ldaa #0x20 ;SEL CH #2 O2 SENSOR
B846 jsr LF0C9 ;GET A/D READ
B849 staa *L0063 ;STORE O2 A/D COUNTS
B84B jsr LF5C2 ;GO LOOKUP O2 VOLTS AND FILTER
B84E jsr LF169 ;GO SETUP MAP VARIABLES AND MALF CHECK So, if I change the "jsr LF5C2" to my new routine at $FDDA (by changing it to "jsr LFDDA"), then I should be good to go... right? riiiight?
Additionally, how do I change the start of my sub to a label? Or is that done automagically when it's compiled? Fweew... now I think I can get some sleep.
02-13-2006, 10:59 AM
#21
Member
Thread Starter
iTrader: (2)
Join Date: Jun 2002
Posts: 248
Likes: 0
Received 0 Likes
on
0 Posts
Okay, figured most of it out. AS11 is VERY temperamental when it comes to spacing and tabs... Anyways, I can't figure out how to apply a sub label...
My patch code:
My patched, disassembled binary:
The LFDAA label didn't transfer?? Everything else looks good...
My patch code:
Code:
ORG $FDDA ;location of free EPROM memory LFDAA: ldaa #0x00 ;select channel 00
Code:
FDDA: LDAA #$0000
02-13-2006, 11:18 AM
#22
Supreme Member
iTrader: (1)
Join Date: Apr 2004
Location: Browns Town
Posts: 3,178
Likes: 0
Received 3 Likes
on
3 Posts
Car: 86 Monte SS (730,$8D,G3,AP,4K,S_V4)
Engine: 406 Hyd Roller 236/242
Transmission: 700R4 HomeBrew, 2.4K stall
Axle/Gears: 3:73 Posi, 7.5 Soon to break
The LDAA did transfer, it shows $00 there fir the channel #.
Did the code below that show up? It should have, then you are ok.
Be careful where you insert the routine that a value that is needed in memory may be used in the subsequent operation.
I'm thinking it may be better to jump to your new code at the point where LB844 is called from.
Then just have a BR LB844 at the end of your new code.
Everything has finished at that point in your new code and will not return to the middle of the existing o2 routine with an incorrect value in memory that the next JSR might use.
Existing addresses will not get shifted either, have to watch for that.
Did the code below that show up? It should have, then you are ok.
Be careful where you insert the routine that a value that is needed in memory may be used in the subsequent operation.
Code:
:--------------------------------------------------------------------------------
;------------------------
; GET O2 A/D COUNTS
;------------------------
B844 LB844:ldaa #0x20 ;SEL CH #2 O2 SENSOR
B846 jsr LF0C9 ;GET A/D READ
B849 staa *L0063 ;STORE O2 A/D COUNTS
B84B jsr LF5C2 ;GO LOOKUP O2 VOLTS AND FILTER
B84E jsr LF169 ;GO SETUP MAP VARIABLES AND MALF CHECK
-------------------------------------------------------------------------------- Then just have a BR LB844 at the end of your new code.
Everything has finished at that point in your new code and will not return to the middle of the existing o2 routine with an incorrect value in memory that the next JSR might use.
Existing addresses will not get shifted either, have to watch for that.
02-13-2006, 12:30 PM
#23
Member
Thread Starter
iTrader: (2)
Join Date: Jun 2002
Posts: 248
Likes: 0
Received 0 Likes
on
0 Posts
yes, all the code transfered, but there is no label for the "select channel 0" code at $FDAA. How can I jump there, if there isn't a label there? Know what I mean?
For instance, in the "get o2 counts" routine in the original bin, it shows "LB844:", the label for that sub. That isn't there in my patched bin's new sub.
What's the difference between a "BR" and a "JSR"? I was a little concerned about interrupting a sub, in case any memory gets rewritten, but it appears as though in this sub, that it is stored in RAM before "looking up the o2 volts"... There aren't any immediate memory values "in que", so to speak I guess...
I mean, obviously if it read the value, and THEN jumped to a new sub, I wouldn't touch that. But since it stores the value before jumping, I think it's safe.
For instance, in the "get o2 counts" routine in the original bin, it shows "LB844:", the label for that sub. That isn't there in my patched bin's new sub.
What's the difference between a "BR" and a "JSR"? I was a little concerned about interrupting a sub, in case any memory gets rewritten, but it appears as though in this sub, that it is stored in RAM before "looking up the o2 volts"... There aren't any immediate memory values "in que", so to speak I guess...
I mean, obviously if it read the value, and THEN jumped to a new sub, I wouldn't touch that. But since it stores the value before jumping, I think it's safe.
02-13-2006, 01:22 PM
#24
It would be JSR LFDAA in the patch file.
If looking at the bin in hex it would be (JSR) FD AA
I forget the JSR code.
Coincidently the address $FDAA and your label are the same.
They don't have to be.
You could declare:
ReadWB EQU $FDAA instead at the top of the patch.
Then you'd use JSR ReadWB.
If looking at the bin in hex it would still show up as (JSR) FD AA
AS11 and the others expect a label to be in the first column of the line. So don't put anything else there but a label.
Some assemblers want a .ORG instead of just ORG also.
I forget which one currently.
When you stick in your JSR, you'll need to add a few NOP's in to keep the addresses inline.
It's odd that the L for the label didn't show up.
Did the : actually show up?
That means it's a label.
If looking at the bin in hex it would be (JSR) FD AA
I forget the JSR code.
Coincidently the address $FDAA and your label are the same.
They don't have to be.
You could declare:
ReadWB EQU $FDAA instead at the top of the patch.
Then you'd use JSR ReadWB.
If looking at the bin in hex it would still show up as (JSR) FD AA
AS11 and the others expect a label to be in the first column of the line. So don't put anything else there but a label.
Some assemblers want a .ORG instead of just ORG also.
I forget which one currently.
When you stick in your JSR, you'll need to add a few NOP's in to keep the addresses inline.
It's odd that the L for the label didn't show up.
Did the : actually show up?
That means it's a label.
02-13-2006, 01:44 PM
#25
Member
Thread Starter
iTrader: (2)
Join Date: Jun 2002
Posts: 248
Likes: 0
Received 0 Likes
on
0 Posts
here's an actual excerpt from the actual patched, then disassembled code:
This may be different from the code I posted above, I may have changed addresses to reflect the ones of the actual binary I'm using vs the commented disassembly I have.
There's nothing that shows FDAA as a label at all...
Code:
; ----------------------------------------------------------- FDD3: TEST FDD4: TEST FDD5: TEST FDD6: TEST FDD7: TEST FDD8: TEST FDD9: TEST FDDA: LDAA #$0000 FDDC: JSR LF649 FDDF: STAA L01DE FDE2: JSR LF5C9 FDE5: RTS ; -----------------------------------------------------------
There's nothing that shows FDAA as a label at all...
02-13-2006, 04:40 PM
#26
What software are you using?
The" : "means label in AS11.
Your showing all labels.
Or are you dis'g the patch itself?
Why is test in there? I don't think that cmd works IIRC.
The" : "means label in AS11.
Your showing all labels.
Or are you dis'g the patch itself?
Why is test in there? I don't think that cmd works IIRC.
02-13-2006, 05:06 PM
#27
Supreme Member
iTrader: (1)
Join Date: Apr 2004
Location: Browns Town
Posts: 3,178
Likes: 0
Received 3 Likes
on
3 Posts
Car: 86 Monte SS (730,$8D,G3,AP,4K,S_V4)
Engine: 406 Hyd Roller 236/242
Transmission: 700R4 HomeBrew, 2.4K stall
Axle/Gears: 3:73 Posi, 7.5 Soon to break
Test shows up from the dis assembler if it finds the area to be code.
Would be $00 if deemed to be data.
I was just figuring a JSR needs to return to where it started from and a BRanch would just continue.
That's why I suggested it.
10 ways to skin that one
Z69 is right in that the lables are one thing, the actual address of that line could be made something else.
When you first disassemble the code all of the addresses and labels are the same. The disassembler "Named" the labels to match the line numbers. When you begin adding/changing things in the middle the existing lines will shift from the changes.
Labels will no longer line up to the addresses. code can still work by calling an address, just can't jump to a label if it is not there.
Would be $00 if deemed to be data.
I was just figuring a JSR needs to return to where it started from and a BRanch would just continue.
That's why I suggested it.
10 ways to skin that one
Z69 is right in that the lables are one thing, the actual address of that line could be made something else.
When you first disassemble the code all of the addresses and labels are the same. The disassembler "Named" the labels to match the line numbers. When you begin adding/changing things in the middle the existing lines will shift from the changes.
Labels will no longer line up to the addresses. code can still work by calling an address, just can't jump to a label if it is not there.
02-13-2006, 05:19 PM
#28
Member
Thread Starter
iTrader: (2)
Join Date: Jun 2002
Posts: 248
Likes: 0
Received 0 Likes
on
0 Posts
Originally posted by JP86SS
just can't jump to a label if it is not there.
just can't jump to a label if it is not there.
My patch:
Code:
ORG $FDDA ;location of free EPROM memory LFDAA: ldaa #0x00 ;select channel 00
Code:
FDDA: LDAA #$0000
I know what a label looks like, in the same binary disassembly, there's 3 right above FDAA...
Code:
FDCB: LFDCB CLRA FDCC: LFDCC SEC FDCD: LFDCD BSET $0000,X,#$08
I'm using AS11 to compile the patch.
OHHHH... crap, I think I see my mistake. I called it LFDAA instead of LFDDA. Stupid me.
I hope it works now,*nope, doesn't work.
It might be that because there are no references in the patch to that label, that it's not put into the assembled code. <--- that was it.
Works now.
TESTING TIME!!
Last edited by ryan.h; 02-13-2006 at 06:11 PM.
02-13-2006, 07:01 PM
#29
Supreme Member
iTrader: (1)
Join Date: Apr 2004
Location: Browns Town
Posts: 3,178
Likes: 0
Received 3 Likes
on
3 Posts
Car: 86 Monte SS (730,$8D,G3,AP,4K,S_V4)
Engine: 406 Hyd Roller 236/242
Transmission: 700R4 HomeBrew, 2.4K stall
Axle/Gears: 3:73 Posi, 7.5 Soon to break
Originally posted by ryan.h
[code]
ORG $FDDA ;location of free EPROM memory
LFDAA: ldaa #0x00 ;select channel 00
TESTING TIME!!
[code]
ORG $FDDA ;location of free EPROM memory
LFDAA: ldaa #0x00 ;select channel 00
TESTING TIME!!
don't you love it when you look at something ten times then on the 11th you say "what the $%#^ am I doing!"
Good luck with it.
02-14-2006, 10:07 PM
#31
Member
Thread Starter
iTrader: (2)
Join Date: Jun 2002
Posts: 248
Likes: 0
Received 0 Likes
on
0 Posts
Welp, it works! I tested it with a pot on the correct input, and it showed a full 0-5v sweep on the correct ALDL byte.
Now I'm trying to copy this over to another binary, different code altogether. Anyone have any idea what this L02DE business is?
I'm trying to locate the stack once again... Same computer. Did GM "borrow" a part of the stack as well??? Seems odd. I have no idea if the stack starts at 01DE or 02DF...
Thank you all for your help btw, one small step for you, one giant leap in my understanding!
Now I'm trying to copy this over to another binary, different code altogether. Anyone have any idea what this L02DE business is?
Code:
L01DA EQU $01DA
L01DB EQU $01DB
L01DC EQU $01DC
L01DD EQU $01DD
L02DE EQU $02DE
L040D EQU $040D
L0455 EQU $0455 Thank you all for your help btw, one small step for you, one giant leap in my understanding!
Last edited by ryan.h; 02-14-2006 at 11:28 PM.
02-15-2006, 04:04 PM
#32
Search the dis and find where L02DE is called. Then see what's going on. It might be some aldl mode test thingy.
Also, IIRC the control file for m6811dis JP used is listed in the aujp_JP2 file. You can use it to dis all the aujp bins up to S_V3.
It won't work on V4. Which isn't out yet btw.
Then you can use some difference finding software to find the mods people have done.
Or you can use TP and the difference tool.
Then just copy those sections and get your cmd code list out and have some fun.
I used TP for the Davis WB patch and dis'd a bunch of 8D bins
to find the code differences.
Also, IIRC the control file for m6811dis JP used is listed in the aujp_JP2 file. You can use it to dis all the aujp bins up to S_V3.
It won't work on V4. Which isn't out yet btw.
Then you can use some difference finding software to find the mods people have done.
Or you can use TP and the difference tool.
Then just copy those sections and get your cmd code list out and have some fun.
I used TP for the Davis WB patch and dis'd a bunch of 8D bins
to find the code differences.
02-15-2006, 05:17 PM
#33
Member
Thread Starter
iTrader: (2)
Join Date: Jun 2002
Posts: 248
Likes: 0
Received 0 Likes
on
0 Posts
Originally posted by Z69
Search the dis and find where L02DE is called.
Search the dis and find where L02DE is called.
My disassembly shows:
Code:
A74D: F1 02 DE CMPB L02DE
Code:
A74D $F102 ;? UPDATE HUD DISPLAY A74F $DE70 ;ESC ROUTINE AND MALF CHECK
02-16-2006, 10:30 AM
#35
Supreme Member
iTrader: (2)
Join Date: Jan 2002
Location: Moorestown, NJ
Posts: 9,962
Likes: 0
Received 3 Likes
on
3 Posts
Car: 88 Camaro SC
Engine: SFI'd 350
Transmission: TKO 500
Axle/Gears: 9-bolt w/ 3.23's
Originally posted by ryan.h
Yeah, it's so wierd... In the commented disassembly I have, it doesn't show a reference to it at all! In my disassembly, it shows it, but I think it's all a mistake now.
My disassembly shows:
The commented disassembly shows:
Notice the 02DE is shifted around. The running theory I have now, is L02DE isn't referenced at all, it was just mistakenly put in there by the disassembler (code was shifted by trying to disassemble some data table), but not taken out by the human
Yeah, it's so wierd... In the commented disassembly I have, it doesn't show a reference to it at all! In my disassembly, it shows it, but I think it's all a mistake now.
My disassembly shows:
Code:
A74D: F1 02 DE CMPB L02DE
Code:
A74D $F102 ;? UPDATE HUD DISPLAY A74F $DE70 ;ESC ROUTINE AND MALF CHECK
02-16-2006, 07:05 PM
#38
Do a search on SEG in an 8D hac.
It's a list of addresses for ea 100ms loop that have subroutines in each loop. We re labeled the aujp table so it might be easier to see what's going on.
Some of the routines are the same between masks.
So once you become familiar with one. And then see it in another mask. You know what it is for pretty quick.
It's a list of addresses for ea 100ms loop that have subroutines in each loop. We re labeled the aujp table so it might be easier to see what's going on.
Some of the routines are the same between masks.
So once you become familiar with one. And then see it in another mask. You know what it is for pretty quick.
Thread
Thread Starter
Forum
Replies
Last Post
db057
TBI
10
08-11-2015 10:11 PM