jim_in_dorris

I am officially stuck. I have downloaded the $0D_Hack.src from moates and edited it to clean it up for running thru the ashc11 assembler. I get 26900 lines assembling cleanly then run out of symbol space. I have deleted all the unnecessary labels I can find. There is nothing left to delete (at least not enough to get the entire 47000 lines to assemble). I would really like some of the people on this forum that have assembled their own code to give me some hints or point me at a better assembler or something.

This is $0D code that I am editing to reflect the code I will be burning to run in the upgraded computer (from 7747 to 8625) in my 87 TBI 305 4x4.

JP86SS

iTrader: (1)

From the guide book under Source Code section.
https://www.thirdgen.org/forums/diy-...mmies-ask.html
Look at post #6 for the link to the Dewtronics assembler.
I've used it allot with pretty big files but not the $0D code though.
Use switches -XLOSF for all the documentation files to be created, then use Bincvt.exe to get the final bin output from the S19 file.
There's more instructions throught the thread on usage etc.
Jp

jim_in_dorris

Thanks, I will give that a try. I hope it doesn't require that I re-edit%2

jim_in_dorris

Ok, I already had that assembler. I can't make it assemble. I get "o" "u" or "a" on every line. What is up? I am sure that I am going to have to re-edit this source code(ughh)

junkcltr

iTrader: (1)

I think at one point you had to re compile that assembler with a large memory model. It couldn't handle large files.
The $0D code also needed some tweaks for the syntax and the blank code space. Use an editor find and replace tool for the changes.

jim_in_dorris

If I knew what changes I had to make, I could do that, the problem is I don't know what those changes are, and I am running the assembler with the large memory model I believe, at least that is what I downloaded from the link.

junkcltr

iTrader: (1)

Post up the errors. I did the initial assemble of the $0D years ago now and can't remember the exact syntax errors. I think it was something to do with the hex representation or addressing syntax.

Why are you assembling the $0D for the 305ci TBI? There is no need to. You just need to tweak the calibration area and not the code area.

jim_in_dorris

22 ; 0050,#$80 IDLE FLAG |
23 ;===========================================
o 0000 24 ORG $4000 ;
o 0000 25 L4000 FDB $1581 ; ID BYTE, 9135d
26 ;
o 0000 27 L4002 FDB $0000 ; Platform ID
o 0000 28 L4004 FDB $0000F ; Platform ID
29 ;
o 0000 30 L4006 FDB $6D2E ; CK SUM
31 ;
o 0000 32 L4008 FCB $0D ; CK BYTE
33 ;
o 0000 34 L4009 FDB 0191 ; 5.66 SEC TMR, 11.76 msec/BIT ************* This is the shutdown timer value to kill RAM and Communica
o 0000 35 tions **************
36 ; ************* Leave this value alone, not important ****************************************
37 ;===================================================
38 ; AIR FUEL MODE WORDS
39 ; MY87 L05, TYPE $0D 700r4 3.73 gears
40 ;===================================================
o 0000 41 L400B FCB $04 ; MODE WD, AFR 1 0000 0100
42 ; b7 1 = DE-LATCH
43 ; b6 1 = MAT SENSOR
44 ; b5 1 = 180 DEG OFFSET
45 ; b4 1 = ASDF CRANK
46 ;
47 ; b3 1 = ACCEL ENRICH LMT OPTION
48 ; b2 1 = SYNC FUEL AT IDLE (TBI)
49 ; b1 1 = AIR MANANGE
50 ; b0 1 = CPI/PFI MODE
51 ;---------------------------------
o 0000 52 L400C FCB $11 ; MODE WD, AFR 2, 0001 0001
53 ; b7 1 = CAN PURGE
54 ; b6 1 = CONDITIONAL INT R/S ON BLM CELL CHNAGE
55 ; b5 1 = INT R/S IF ACCELL ENRICH
56 ; b4 1 = INT RESET I


Here is a sample of my errors, the code part is similar. I am assembling the source for 2 reasons. First to learn the code better, and second to allow me to add features at a later date. I have done a lot of main frame and 808x assembly in the past, so this doesn't scare me any. Besides, I prefer changing source to patching a binary file.

JP86SS

iTrader: (1)

Not sure on this but with the amount of errors shown it could be that you do not have the "equate" addresses at the beginning of the file for memory locations.
Anything that has a L**** for a memory location should be listed.
Without the memory addresses defined at the beginning the assembler will throw a "u" for undefined address, that will cascade to other errors.
HTH

JP86SS

iTrader: (1)

I just looked at an $OD_DIS.asm file, might/might not be the one you started with.
Change the "EQU" to "space = space" with a replace all.
Change "$" to 0x with replace all
Should fix that part for use with that assembler.
Also if there are sections that look like this
The items on the left need to be removed. Looking at the last line in the code above the actual code for assembly should be only
The left is the machine code for the same thing as listed when disassembly was done.
Leaving the whole line intact will not work. Hopefully your hac file won't need all the editing to remove it.

jim_in_dorris

Man that su**s. The reason I need to change over is because the ASHC11 assembler runs out of symbols space at 64k. That's at least 32k symbols. The ASHC11 assembler doesn't have any problems with my source code except for that. I really don't want to add 32k lines to this source.

jim_in_dorris

Can I use an include file with this assembler and then just create the symbols in the include file?

jim_in_dorris

Bump.....
I would like to get this to work, will an include file work with the as11 assembler?


Thanks again

jim_in_dorris

Ok, I just found an updated version of the ashc11 assembler that I like, I now have over 30,000 lines and no problems with symbol space. I do have problems with labels not in col 1, but that is a simple edit fix. When I get this done, there will be a $0D source file that can be assembled into an S17 file then converted to a binary. Yahoo!!. I still have a lot of editing to go turning it into a file that matches the BIN file I am starting with for tuning purposes, but I am getting there. Thanks for all the replies JP86SS, and for the rest of you out there getting into assembling your own BINs, google the ashc11 assembler and try it, I really like it.

junkcltr

iTrader: (1)

That assembler is not used around here because of what the author did years ago. Do a google of DIY WBO2. The dewtronics assembler is a better choice. It litterally took a few hours to get the $0D to assemble with it. Using emacs would make it even quicker.

jim_in_dorris

Thanks for the heads up junkcltr, I don't want to bring up old hard feelings. I was completely unaware of the problem that occurred because I just started doing this. I just tried Baldwins AS6811 assembler, and all I get is "out of space". I have 4 different assemblers loaded and have been very frustrated with the quality of the user interface on 3 of them. I will refrain from posting anything about the ashc11 assembler here and on fullsizechevy, but I would appreciate extra help with these other assemblers ( as a professional programmer I really dislike having to set every label). I will also try the emacs editor, although I have been using MS .NET editor for a while now (since I was teaching VB for a while).

dimented24x7

iTrader: (2)

I already have a fully assembleable (and fully commented) stock $0D hack here on TGO and on moates.net that assembles in mgtec's mini IDE DOS based assembler. If you search for my threads on the $0D code and patch tutorial, you should be able to find the assembler and source code already posted. The source code I made served as teh basis for my MAF TBI project, so it already has pretty much all teh bugs worked out of it. No sense in re-inventing the wheel.

Also, many assemblers will not handle the size of the $0D code and the number of lablels used. The one I have above is 32-bit, so space is not an issue.

Edit: Its not on moates.net for some reason. I can re-upload it along with the assembler if you would like.

jim_in_dorris

That would be great. That way the only editing I would have to do is to make it match the bin I am using. Thanks

dimented24x7

iTrader: (2)

Its small enough to post here. Here is the assembler and $0D hack. You'll have to use firefox to DL it, as IE does not work properly.

jim_in_dorris

WOW!!!! Thanks a lot, now I just have to spend some time matching it to the bin I will be using. Hopefully I can do that with a lot of cut and paste for the 7000 lines I already modded but if that doesn't work, I will just re edit everything.

jim_in_dorris

ALRIGHT!!!!! I folded in my table changes to match my starting bin (I'm only part way thru, but put in the ones I had complete) and ran asm11 and found a couple of minor errors. I fixed them and got an S17 file. Now I can run the converter and compare to my starting bin. I feel like I just won the lottery. Dimented THANK YOU... If I can have your permission, I would like to put this on moates for the BDWM.bin when I get it complete so that other people will have access to it. If you do not want me to do that, I will not.

jim_in_dorris

Ok, now I have a different problem. I have been assembling every 1000 lines or so to check for errors. I convert the S19 file to a bin and do a compare to my original bin to check for errors. It works fairly well until I get to Address 556C at the start of the instrumentation calibration. My original bin has a zero fill for the unused sections and the asm11 file that I create is "FF" filled. While I can see this easily, and understand what is going on, it would be much easier if it zero filled this section. At the beginning of both bins, they are "FF" filled, so I don't want to just blanket switch the fill value. Can I use a compiler switch inside the source to make the change?

jim_in_dorris

Never mind, I figured it out. A DS opcode generates no code, but will zero fill to block size.

JP86SS

iTrader: (1)

Using the ".ORG 0xAddress" can remove section of fill and maintain location of code also if you don't want to wade through pages of 00 or FF.

jim_in_dorris

Thanks JP86SS, I understand that. I wanted to zero fill because I am building a bin then comparing it to my original bin and since the original bin was zero filled, I wanted to zero fill. At some locations in the $0D source, a section of tables would end, then an ORG $XXXX would be inserted to start at the next location. When I assemble that, it would fill from the end of the tables to the ORG with "FF" and then when I compared bins they would be different there. It is the same thing since it is unused space, but much easier to see differences if they both match.

dimented24x7

iTrader: (2)

I have no issues with posting the hack on moates. Provided the header remains intact, and any changes you make are called out, your free to post what you wish.

jim_in_dorris

ok, I am going to try this again, early this morning I made this post and just before I hit the reply button I lost my network. Dimented, thank you again. I think I will probably not post it, while I haven't changed the header, I have made literally hundreds of changes to tables, much too much to document getting it to match my starting bin. D@@@ you guys did a lot of work getting these hack files built. I would rather not post it if there was any risk whatsoever of creating hard feelings. I have a question about forcing extended addressing. I have all the tables edited and thought, great, there shouldn't be any miscompares in the code itself... WRONG!!! So I started wading thru that. At around C330 I have a problem that cascades throughout the entire code segment. Your hac source uses immediate mode addressing because the referenced location is below $100. The bin I am using was assembled with the following piece of code using extended addressing thereby dropping 2 bytes out and throwing all offsets in the coding off. here is the code and the hex as well as what I tried to do.

LC330 LDAA 0,X ;Load desired state
;
LC332 LDAB L004C ;Load I/O port D word
ANDB #$FC ;Mask all but lower two bytes
ABA ;Update shift solenoid states
STAA L004C ;Save it

this assembles to A6 00 C6 4C C4 FC 1B 97 4C
what I need is A6 00 F6 00 4C C4 FC 1B B7 00 4C

I tried this
LC330 LDAA 0,X ;Load desired state
;
LC332 LDAB #$004C ;Load I/O port D word
ANDB #$FC ;Mask all but lower two bytes
ABA ;Update shift solenoid states
STAA #$004C ;Save it

and I get an error message trying to assemble it saying that the STAA cannot use immediate mode addressing. How do I force extended addressing?

jim_in_dorris

Ok, I figured that one out the way to force it is like this

LDAB >$004C

That worked perfectly. All my address offsets (almost ) are resolved.

What is left is fairly minor with a couple of exceptions.

One that is puzzling me is at $9426 the opcode is BITA #$08 but the hex code says it is ANDA #$08 The difference between these 2 instructions being the zero/negative flag.

The other major problem is in the downshift tables. Dimented I especially need to question you about this (even though I don't use a e-tranny) The table at LD64E is

High Temp trans
Manual Pattern
Cruise Control-Performance
Cruise Control-Standard
Standard - Performance
Standard - Standard
where the last 4 catagories all point to the same routines wereas in the Hac I got off moates has different routines for cruise control and standard. I know I won't be using these, just trying to clear up my confusion.

dimented24x7

iTrader: (2)

There are errors and oddities in the stock code that I corrected as I was using it as a base for my own custom code project. Those addressing modes and the BITA are some of them. The extended addressing is not technically correct for the processor as the memory is internal, and not on an external device like a ROM or a flash chip. It may work properly, anyway, as the 68HC11 is pretty simple. But, on other processors, this would result in addressing the wrong device, or a protected/reserved address. As for the BITA, in hindsight, the ANDA is OK, as it will still set/clear the Z flag and give the same result.

At one point, I had a version that had No Operation opcodes that maintained the offsets, but I lost it. Since the hack has indirect addressing, its OK to omit any filler once youve gotten through the stage of checking the hack against your target bin.

dimented24x7

iTrader: (2)

Which hack is it?

jim_in_dorris

The $0D_HACK.SRC in the 0D.zip folder. I don't know that it is correct, just that they are different. Thanks for the info on the addressing modes. It must work, because the bin I am comparing it to used it and it is a stock BHMC bin.

jim_in_dorris

Ok, last problem and this one may be a doozy. I checked this with 3 stock bins, BHMC, BUZX, and BJYN and they all are the same, and I think it is a GM bug. At FF92 in the interrupt vector table is FCB L7C7E. If i remember my interrupt processing correctly the interrupt loads that address into the instruction pointer and executes the instruction at that address. The problem is that in all 3 bins, 7C7E is in the middle of an instruction, and the instruction actually starts at 7C7F. That instruction is JSR LCC1E or BD CC 1E in hex All 3 bins match. When I assemble it I get 7C7F in FF92 which is correct. Is this an unused interrupt line and hence never gets used?

jim_in_dorris

bump! anybody????