Just want to say off the bat that Ive never worked in assembly before so...

Alright... Trying to assemble a converted over hack with the freeware AS11.EXE assembler. No errors with the mnemonics, but on the second pass through, it wont recognise that the Jump to subroutine command is external. It just keeps putting it an an direct and puts an offset of $00 in. Assembler absolutly refuses to point at the label and put in the hex address of the label itself. Same thing with the all of the branch commands. I can assemble the commands in a seperate file and they all point right to the labels and put in the right addresses and offsets w/o any problem no matter how or where I set the origin in the memory of each command. What gives?

 

Can you post a fragment of the code and where it is doing the mistake?

RBob.

 

OMG all over as soon as it gets to the actual program

For instance the following code should produce this when assembled

Will produce

Someone sent me the techedge compiler and that one gave an error that seemed to pertain to not enough memory. With the motorola one, the branches seem to have the right offsets that go to where they should be but the code telescopes down on itself wehn compiled and the offsets jsut stretch out farther and farther to get to the proper address since each JSR produces one less byte of machine code when compiled. From the problems with the techedge compiler im guessing that the compiler just doesnt have enough ram free to retain all teh labels so it errors out.

 

OK, BTDT, the AS11 assembler isn't good enough to assemble a lot of code. It is limited in the size of the program, and it doesn't error out when memory overflows. So it really only is good for patches and such (and I still use it for that).

As for the other assembler it is running out of symbol space. The reason is that there is an address label on every line. The extra labels need to be removed. This will free up symbol space.

This gets tricky as some labels/symbols need to be left in place. Every address location that is branched to, jumped to, or otherwise referenced needs to stay.

RBob.

 

ok... that makes sense. Ill go though and ditch all the excess labels.

 

Well, I used tunercats to create the actual source code disassembly for hte main program and that, in a fasion, seems to work. The ecm gives the rapid flashing light so theres an error somewhere. I disabed the check sum and tried to data log with it but its reading all the wrong stuff from the eprom. The thing that really blew me away is that the ecm now starts the engine. For whatever reason, before it wouldnt run the injectors with the old source code and now tehy work again. Runs like poop since theres an error somewhere in the upper portion of the code but it works. Damndest thing, especially considering that the code came from the origional rom image of the ecm.

 

nvm... pure coincidence... Mustve jabbed or poked the right thing again to get it working.

 

lol.. its dead again, oh well. Anyway, now taht I know where all the labels should be and what I need to do Im going to start fresh with a copy that hasnt been butchered. Thanks for the pointers about the labels. I didnt realize that it actually kept tabs on each label in the code.

 

There is something else that came to mind. . . If you are trying the ROMLess setup there is a file pad that needs to take place. This is what happens: the original '8746 code is 12kB in size. There is 4 kB in EPROM, 4kB in one ROM and another 4kB in the other ROM. This data/code spans from $D000 through $FFFF, 12kB.

When going ROMLess the area for the EPROM/ROM is expanded to 16kB. There is another 4kB of space available.

The kicker is that it starts at $C000. So if the original binary data/code of 12kB is burned into a 128 kb EPROM the data is offset by 4kB. (little kb is bits, big kB is bytes).

So a 12kB file of the original data/code needs to be padded by 4kB on the front to put everything into the correct place. And the final bin file is 16kB in size.

A fast flashing SES light is an EPROM checksum error.

RBob.

 

I padded it with $FF's. The problem is actually in the code itself. Replacing the chunk of code in the assembled source code with the code on the stock 8746 prom fixes it. Ill be damned if I can ever find the error. Its probably one mnemonic placed instead of another. .