I've moved it to here:

http://wasabi.dynu.com:8080/wiki/ind...HC11Addressing

It should be up most of the time. It's running off my cable modem so it may be slow sometimes.

All of the pages in the Wiki are free to edit, so if you have something to add, please do so!

The main page is here:

http://wasabi.dynu.com:8080/wiki/index.php/68HC11

 

Awsome thread! This is definatly sticky material.

 

The addressing mode is definatly something you need to remember. Its real easy to get burned by not or fogetting to declare what mode you intend to use (example: forgetting the # sign). I make that mistake all the time and then wonder why something doesnt work.

 

What do people think about using a wiki for this?

http://wasabi.dynu.com:8080/wiki/ind...HC11Addressing

A wiki is basically a web page that anyone can edit, so feel free to ask questions at the bottom of the page, make corrections to my stuff, or add helpful links.

 

Sounds like a great idea!!! but, I can't get there, page not available?

 

Hmmm... weird, I can see it.

I've posted up an intro on how the checksum is calculated, can you see it?
http://wasabi.dynu.com:8080/wiki/ind...68HC11Checksum

 

Still cannot reach your site, these are the messages I receive.

Cannot find server The page cannot be displayed

I'm sure the problems on my end, I'll try later from another network.

89350STRO

 

Try this:

http://d154-20-206-110.bchsia.telus.net:8080/wiki/

Make sure you're getting the full URL, Internet Explorer doesn't like it if you use port 8080 without the http.

 

Tried from Home, I am now able to reach the site!! I used the original site you posted earlier.

Great Page's, Fantastic info, give us more!!, Please

89350STRO

 

Good examples! I especially thank you for that pointer about indexed. I always was a tad confused about it, it made sence but your explination answered a few questions I had. This is how you look through tables stored in the eprom, very useful for the source code that operates our EFI.
Your comments on the limitations were a huge help.

 

Thanks! I'm getting a better idea of this all works now!

 

I went looking through the wiki site and I must say there's some good info there!! I corrected a couple typos for ya too in the checksum section....typos in load-to-register commands are bad.


Speaking of the BUA checksum routines.....the two addy's that are stored to the X and D registers that have no known use....they look suspicious to me. $C008 is obviously the addy where the mask ID is stored, but isn't it also the first byte added to find the checksum? $3FF8 is the total number of bytes to the end of addressing, if you start with $C008 as the first byte. I'm thinking this could be used in a decrementing counter so that the code knows when it has all the bytes added to the checksum that it needs. Maybe this was an early idea for a checksum calc. that got scrapped in favor of the current subroutine?? It's well known that GM didn't mind patching the code to get things to work.

I'm afraid I don't know the commands well enough to go through it all to find out......I just started digging into the code a couple weeks ago. I don't even have a pink book yet.

 

New article is up:

http://wasabi.dynu.com:8080/wiki/ind...C11Subroutines

 

I'm stupid... I'll post a fix in a minute...

Thanks a lot for the typo fix!!

 

I think it's a typo in the BUA hac.

I think this should actually read

maybe it was deliberate... I can delete it if people in the know want it to be there.

I searched through the code and it looks like the subroutine is used a few times in the code for different things like PROM checks and NV (non-volatile) RAM checks.

TheGreatJ: You are exactly right about the uses. Read up on the checksum subroutine doc in the hac and you will see how it is used.

Note that the A and B register can be treated as a single 16 bit register called D.

 

http://wasabi.dynu.com:8080/wiki/ind...68HC11Checksum

Y'all are lucky America's Next Top Model is on right now, otherwise the wife would have me doing some housework tonight.

 

Which would be the best $58 hac to start working on? I see two on Moates.net, 58.zip and 58Turbo.zip.

58Turbo.zip has 2 asm files in there, but only one bin file. Of course, I can only get the other .asm to assemble, and I don't see the BCC listed in it any more. It's the one with the filename "58 Disassembly.asm".

On my system it assembles into a 16k file.

For the other file "AYBN_hac.src", the assembler barfs on this:

C7EE F96: fcb $22,$00,$00,$00,$00,$00,$00,$00
C7F6 fcb $00,$00,$00,$00,$00,$00,$00,$00
C7FE fcb $00,$00,$00,$00,$00,$00,$00,$00
C806 fcb $00,$00,$00,$00,$00,$00,$00,$00
C80E fcb $00,$00,$00,$00,$00,$00,$00,$00
C816 fcb $00,$00,$00,$00,$00,$00


And I don't really understand what it means either. Should they be labels?

Does anyone want to help on this project, or have anything further along that I can help with? What I'd like to do is put together a memory map so we can find out where there is extra space on the PROM and in RAM so we can do some cool stuff like add extra tables, put new stuff in the data stream, etc.

 

I might be able to help with a few of the open ends.

I havnt looked at that ecm specifically, but the prom area is added up in order to verify that each byte can be read and isnt corrupt. The computer checks its result against the stored checksum on the prom and if the two match, it continues w/o any error so long as the mask ID isnt set to $AA. The checksum routine probably works by starting at 0xC008 and adding every hex value at each address untill it gets to teh end and then passes the result in one of the registers or accumulators. Overflows arnt an issue as one only cares about the lowermost byte or two. A bad address read or a bit that has changed will reflect in the 16 bit result, causing a checksum error.

I think there probably is a factory test routine that also performs teh checkum again if its requested. I have that in mine, anyway.

EDIT: if you have an ecm that has onboard hardcoded rom then those routines like the mask ID check make alot more sense since some of the extra code is on the prom and the prom and rom need to match.

 

I know how it works, just haven't had time to do it.

If you want to change it, feel free, just click the Edit link at the top of the page.

 

Check your mail

 

Don't bother checking you mail.
Neither address accepts the file. One quarantines it, and the others too small.

Got another address of then the one from here, and where you've written me from?.

 

My bad... From the way you wrote it it sounded like you had some questions.

If I can get around to it, Ill try and do an edit.

BTW, anyone think there should be some standards for doing edits, like maybe a section for people to leave their screen names or whatever, a short blurb about the edit, and the date the edit was done? Maybe itll help keep some order and allow someone to be contacted if there are some questions about material added. Just a thought...

EDIT: saw there is a section there that records the IP of those who do edits.

 

I should have put a smiley in the previous reply, was in a hurry this morning..

Yeah, the wiki software is really cool, I've been playing with it a lot recently.

If you login with a username, it shows your name on the edit page rather than your IP. I'm not sure if this can be avoided, but I'll check in the documentation page. Some people might not want their IP addresses revealed...

EDIT: Checked the docs, you need to create an account if you don't want to reveal your IP.

 

What would happen if you didn't run the checksum code at all and the eprom fell out. Would the RFD be triggered still or would the processor just keep chugging along with 0ms pulse widths and just turn the car off?

 

Good question!!

I don't know what RFD means, I'm still learning all of the GM terms...

If the PROM fell out, the code wouldn't run because it wouldn't be there.

I think it would try to jump to the bus error interrupt vector. After that I don't know what it would do, somehow it needs to fall back on the CALPACK. I know that my car still runs if I pull out the PROM, the CEL goes on, etc.

dimented24x7, thanks for the changes!

Grumpy, I've put up some details on the 68HC11 registers:

http://wasabi.dynu.com:8080/wiki/ind...8HC11Registers

 

RFD (Redundant Fueling Device). When the prom gets kicked out the ecm stops sending the signal to the ESC which means you have a really cruid ignition curve based only on engine speed. Next the RFD takes the fueling over based on the raw inputs and the netres (resistor network).
Without the checksum routines, what would the processor know to fall back onto the RFD?
I've been using $AA for my mask ID for years now .
I don't see any reason for the checksum, I'd rather just remove it all together. Anybody have a reason not too?

 

The computer would jsut read in 0x00 and probably lock up and keep resetting for the total time that it remained on. once that happens, the RFD would probably take over. Its like what happens if the prom takes a dump while your driving the car.

 

RTD, from what I've gathered is Redundant Fuel Devise. It's used when the processor fails. No inputs are needed, since there's nothing to process the information. It's an analog, failsafe.


I usually run a checksum. Do enough chips, long enough, and you'll have some fail between engine run cycles. And it when there's no check sum, and no SES it can waste some time trying to figure out what happened. Usually happens on a none cell phone covered area, in lousy weather.

 

The checksum is just to validate that the prom is ok at startup. It doesnt do much good when the car is already running since its only run once. Basically, the ***umption is that the computer will stop processing and the COP will reset it. Then itll peform the checksum again when it reboots (or maybe not if you dont have the rom) and give an error. Here is where it pays to have the mask ID set. This keeps teh computer from executing garbage that appears as legitimate code.

Rumer has it that the 6809s, similar to whats in in our ecms, posess the Halt Catch Fire command. According to legend, this instruction can cause the computer to toggle an address line or something so fast that it burns up. Imagine if one of the corrupt values was the hex value for the HCF instruction?

In reality I dont even think our ecms have this.

 

That was alot of typing . My fingers need to go on vacation now.

 

Now THAT clears up some confusion I had about the register usage.....thanks!! I couldn't figure out how they got the MSB and LSB of the checksum into the A and B registers....now it makes sense.




And that JSR typo would explain it very well. If I could get my disassembler to work I'd check the .bin myself to see if you're right.

 

Great job AlexJH !! Thanks.
Really good reading.
:yourock:

 

Thanks Grumpy!

I found a free assembler that will build the 58.zip code. Although I'm not working on that one any more

http://www.mgtek.com/miniide/download/