DIY PROMDo It Yourself PROM chip burning help. No PROM begging. No PROMs for sale. No commercial exchange. Not a referral service.
Welcome to ThirdGen.org!
Welcome to ThirdGen.org.
You are currently viewing our forum as a guest, which gives you limited access to view most discussions and access our other features. By joining our community, at no cost, you will have access to post topics, communicate privately with other members (PM), respond to polls, upload content and access many other special features. Registration is free, fast and simple, join the ThirdGen.org community today!
ldab $0171 ;get number of data bytes,
; should be between 1<->8
beq @2 ;check for 0
cmpb #$08 ;
bhi @2 ;branch if greater then 8 bytes
@1: decb
ldy #$0174 ;index to first byte in buffer
ldx $0172 ;index to base address
aby ;add offset for databyte
abx ;add offset for databyte
ldaa $00,y ;fetch byte from ALDL buffer
staa $00,x ;store the byte to ram
cmpb #$00
bne @1 ;loop til all bytes copied
; from buffer to ram
@2: clra
staa L0170 ;store 0 in ALDL mode number
bset L0048, #$01 ;set mode 4 flag
bra LB3D3 ;branch always to routine to
; clear mode 4
nop ;padding
nop ;padding
To write a byte (or group of up to 8 bytes) via ALDL, here is the command to send:
$F4-($55+n)-$04(mode 4)-$nn(number of bytes)-$aa(MSB of address)-$aa(LSB of address)-$dd-...-$dd-$cc(Checksum)
e.g.
1 byte write $FF starting at $2000: F4-5A-04-01-20-00-FF-8E
2 byte write $BE $EF starting at $2000: F4-5B-04-02-20-00-BE-EF-DE
ECM responds with: F4-56-04-B2
Not to be used for profit.
Last edited by MonteCarSlow; 09-01-2005 at 12:52 PM.
feature for formatting code. Someone told me about it before and it works
well.
[code} code_here [\code}.
replace the } with a ] to have it show as above.
Originally posted by junkcltr Good job. You can use the
Code:
code_here
feature for formatting code. Someone told me about it before and it works
well.
[code} code_here [\code}.
replace the } with a ] to have it show as above.
J
Ahhh... I was using < stead of [. Thanks.
Last edited by MonteCarSlow; 09-01-2005 at 12:53 PM.
Originally posted by MrDude_1 what does this do? allow you to "flash" a new bin on thru the ALDL port??
Technically, yes...
This is of little value to a stock 730, but if it has been modified with atleast 4kb of extra battery backed ram you can write to that ram. And if the source code is modified to look in that extra ram for the fuel/spark/etc tables, you can then "flash" your new fuel/spark/etc tables through the aldl port (while the engine is running!) You can do this now with Craig's stuff, or a romulator, (and prominator I think?). But they cost lots of $$...
Last edited by MonteCarSlow; 09-01-2005 at 02:02 PM.
Originally posted by MonteCarSlow Technically, yes...
This is of little value to a stock 730, but if it has been modified with atleast 4kb of extra battery backed ram you can write to that ram. And if the source code is modified to look in that extra ram for the fuel/spark/etc tables, you can then "flash" your new fuel/spark/etc tables through the aldl port (while the engine is running!) You can do this now with Craig's stuff, or a romulator, (and prominator I think?). But they cost lots of $$...
Cool hack!
Have you modded your ECM to use the extra RAM? I'm definitely interested in some pics/instructions...
"Perhaps if there is sufficent interest, a diy ram expansion board/kit can be made that plugs into the ecm edge connector"
INTREST ! INTREST !!
X10
I'm looking through the AUJP to match up the code you posted too.
The "@1" and "@2", are those leagal lable names or did you just refer to them to reference an existing lable in the code?
Haven't seen that notation before.
Also, where would you connect an external battery for backup?
Would it be in parrallel with the car battery source at the ECM?
Haven't done the full investigation on it yet. Hopefully I'll have a better handle on what you did this weekend.
Originally posted by MonteCarSlow I'm in the process of modding source code to use the extra memory as the main lookup area for all the calibration data.
Originally posted by JP86SS I'm looking through the AUJP to match up the code you posted too. The "@1" and "@2", are those leagal lable names or did you just refer to them to reference an existing lable in the code?
Haven't seen that notation before.
Those are legal labels. The Lxxxx notation is just something generated by the disassembler.
Quote:
Also, where would you connect an external battery for backup? Would it be in parrallel with the car battery source at the ECM?Haven't done the full investigation on it yet. Hopefully I'll have a better handle on what you did this weekend.
If you look at the pictures in the other thread, you will notice that the ram chip looks really large for a ram chip... that's because it has an internal lithium battery. That kind of ram chip is called nvsram. The battery is good for ~10 years according to the datasheet of the device. If I can't get my car tuned in 10 years, I need another hobby.
Originally posted by Z69 I thought the 730 had a little unused spot on the board for more ram?
Yes the 730 does have a spot for it, but try and find a 2kb sram these days that drops right in. You also need to stuff some other parts that aren't on the board to make it work. I simply moved the h/w memory mapping of that 2kb sram from 1800-1FFF to 2000-2FFF (which doubles the amount of addressable memory).
I have working DOS utilities that can be used to upload and download bins to and from the ECM via ALDL. An upload takes about 25 seconds, and a complete download of the bin takes about 50.
I anyone is doing the nvram expansion modification, I would appreciate hearing from you. More testers = stable hack. So far it's quite idiot (me) proof. If I garable the nvram contents the ecm recovers itself on a reboot.
I haven't yet started on a diy through hole memory expansion board. Too busy at work for the next 2-3 months.
Does anyone know how to use serial ports in a DOS program that is running inside a DOS box on Win9x? My tools only work if I boot into DOS only mode.
Originally posted by MonteCarSlow Just a quick update for those interested.
I have working DOS utilities that can be used to upload and download bins to and from the ECM via ALDL. An upload takes about 25 seconds, and a complete download of the bin takes about 50.
I anyone is doing the nvram expansion modification, I would appreciate hearing from you. More testers = stable hack. So far it's quite idiot (me) proof. If I garable the nvram contents the ecm recovers itself on a reboot.
I haven't yet started on a diy through hole memory expansion board. Too busy at work for the next 2-3 months.
Does anyone know how to use serial ports in a DOS program that is running inside a DOS box on Win9x? My tools only work if I boot into DOS only mode.
what language are you writing it in?
if you want it to be stable across windows platforms, you're going to have to go the windows route of talking to the OS, not the port itself...
Originally posted by MrDude_1 what language are you writing it in?
if you want it to be stable across windows platforms, you're going to have to go the windows route of talking to the OS, not the port itself...
I wrote it in C using Borland Turbo C v2.01 because it was free to download from their website.
Are there free windows libraries that I can use to access the serial port that are backwards compatible to DOS? I used an old public domain serial comm library (asyclib2 I think it was called).
I'll warn you now, I'm a newbie with C-programming, so please use idiot proof mode when you reply.
honestly, ive never even seen a Borland compiler.. lol. ive been a microsoft developer since i started on PCs...
theres probly some freeware out there for the Borland compiler, but as far as i know, all of the Microsoft stuff you have to pay for.. heh, im so far away from the actual machine its not even funny anymore.. lol.. i really dont know where exactly to point you... when i talk out the serial port (rarely) i just use a predefined microsoft object.. easy and quick..
Originally posted by MonteCarSlow Here is the source code for the hack, note that it is written for AXXC
and addresses will need to change for other $8D bins.
ldab $0171 ;get number of data bytes,
; should be between 1<->8
beq @2 ;check for 0
cmpb #$08 ;
bhi @2 ;branch if greater then 8 bytes
@1: decb
ldy #$0174 ;index to first byte in buffer
ldx $0172 ;index to base address
aby ;add offset for databyte
abx ;add offset for databyte
ldaa $00,y ;fetch byte from ALDL buffer
staa $00,x ;store the byte to ram
cmpb #$00
bne @1 ;loop til all bytes copied
; from buffer to ram
@2: clra
staa L0170 ;store 0 in ALDL mode number
bset L0048, #$01 ;set mode 4 flag
bra LB3D3 ;branch always to routine to
; clear mode 4
nop ;padding
nop ;padding
To write a byte (or group of up to 8 bytes) via ALDL, here is the command to send:
$F4-($55+n)-$04(mode 4)-$nn(number of bytes)-$aa(MSB of address)-$aa(LSB of address)-$dd-...-$dd-$cc(Checksum)
e.g.
1 byte write $FF starting at $2000: F4-5A-04-01-20-00-FF-8E
2 byte write $BE $EF starting at $2000: F4-5B-04-02-20-00-BE-EF-DE
ECM responds with: F4-56-04-B2
Not to be used for profit.
Just some extra notes about this hack:
1) The ECM sometimes replies with F4-56-00-B6 to this mode 4 byte write, this seems to be a valid reply and if you look at the locations, the bytes did get written properly. I still haven't figured out why I get a mode 0 reply sometimes. But hey - it works...
2) Wait ~10msec before sending the next mode 4 packet because the bytes get written from the aldl packet buffer to memory during the 6.25msec interrupt routine. I haven't clobbered myself yet with this but it something I noticed last night that I didn't think of before.
Originally posted by MonteCarSlow Just some extra notes about this hack:
I still haven't figured out why I get a mode 0 reply sometimes. But hey - it works...
This could be due to the logic (BRA LB3D3) B3BF in AUJP , that does not clear Mode 4 until Mode 0 has been requested.
You may be getting the confirmation of the Mode 0 change.
Code:
;--------------------------------------------------
LB3BF: brclr *L0048,#0x01,LB3D1 ; BR IF ALREADY OUT OF ALDL MODE 4
; ... else
ldaa L0170 ; GET CURRENT ALDL MODE <----****
bne LB3D1 ; BR IF NZ
; (don't clr mode 4 till mode 0 req)
; .... else
bclr *L0048,#0x71 ; CLR 0111 0001, MODE 4 FLAGS
bclr *L0039,#0x01 ; CLR b0, SKIP ERR 42 FLAG
clr L00D7 ; CLR EST FEEDBACK COUNTER
;--------------------------------------------------
There is also a ALDL timeout of 5 seconds of no activity that will revert it back to Mode 0.
The address of the timer is $019E in AUJP. The 5 second value is hard coded just below.
I don't have my lst file to get the exact addy right now.
Originally posted by JP86SS This could be due to the logic (BRA LB3D3) B3BF in AUJP , that does not clear Mode 4 until Mode 0 has been requested.
You may be getting the confirmation of the Mode 0 change.
Code:
;--------------------------------------------------
LB3BF: brclr *L0048,#0x01,LB3D1 ; BR IF ALREADY OUT OF ALDL MODE 4
; ... else
ldaa L0170 ; GET CURRENT ALDL MODE <----****
bne LB3D1 ; BR IF NZ
; (don't clr mode 4 till mode 0 req)
; .... else
bclr *L0048,#0x71 ; CLR 0111 0001, MODE 4 FLAGS
bclr *L0039,#0x01 ; CLR b0, SKIP ERR 42 FLAG
clr L00D7 ; CLR EST FEEDBACK COUNTER
;--------------------------------------------------
Nope, thats definitely not the culprit. That code is overwritten by my mode 4 byte write hack...
It's not a timed out reply, I get the mode 0 or 4 reply right after my mode 4 request.
Good ideas though...
As an aside, I was able to insert my mode 4 hack into another position in the code and generate a variable length mode 3 reply to my variable length mode 4 request. Still needs to be debugged though, it's not working 100%. In other words, the aldl reply read back the data bytes I wrote.
Last edited by MonteCarSlow; 10-18-2005 at 01:40 PM.
have you ever thought of writing the whole bin to sram using mode4 instead of just the calibration we do it with the 808 ecu and modified holden code with a max232 based serial board and and an sram mounted on a second board that plugs into the memcal socket and are realtime tuning with tunerpro R/T and an extra little software program can drag a spark map point or ve table graph point and update in realtime just like using an autoprom can load whole bins as well
have you ever thought of writing the whole bin to sram using mode4 instead of just the calibration we do it with the 808 ecu and modified holden code with a max232 based serial board and and an sram mounted on a second board that plugs into the memcal socket and are realtime tuning with tunerpro R/T and an extra little software program can drag a spark map point or ve table graph point and update in realtime just like using an autoprom can load whole bins as well
Initially, yes, but the risk of being stranding on the side of the road wasn't something I wanted to take. What you describe is prone (in my opinion) to corrupting the code space. Do you guys still keep the eprom or has the whole eprom been replaced by nvram?
i should of worded that differently thought of running the whole bin on sram .nope the whole bin is in the nvsram we have a memcal plugged onto the side of our board but only to use the cylinder select netres and limp home mode resistors and the knock filter and allows for changing from v6 to v8 just by sliding in the suitiable memcal and when finished tuning its tuned to that memcal so we can burn a chip and slot it in the memcal and plug it in an ecu.no strandings on the side of the road yet there have been cases before with similar boards of the sram getting corrupted but nothing to do with tuning more to do with power surges to the ecu from loose battery terminals or earths but not very often(i think ive heard of it happening 3 times)and theres thousands of people running with the whole bin on sram no problems.and nothing a memcal in the glove box wont fix it if did happen the ecu can still take a memcal even with the write line wire attached under to board.we can change 1 byte or we can write the whole bin whatever needs doing.ive sent a little package of goodies via JP86SS just now for you guys to have a look at has all the software to link to tunerpro for realtime tuning hes got my contact details and is going to foward the stuff to you anyway but im willing to help out if need be.heres a pic of my realtime ecu with the shell off.and the realtime kit with both boards and all componants are about $160 dollars australian unassembled need to solder them together pretty cheap with the difference in the dollar
yeah the 1227808 doesnt have 8192 buad aldl as its missing the uart that the 165 has so we have the max232 to give us 8192 buad aldl and its got seperate TX and RX lines to the ecu so im not sure how this will effect you as the software we use to realtime with tunerpro is setup for this type of setup if you sre sending down 1 wire aldl its going to see the bytes you sent and would need to be told to disreguard them.and your email rejected my package of software goodiness good old gmail does it all the time
hey montecarslow theres a modified version of antusprom over on www.delcohacking.net for 1 wire aldl now should help you guys better than our seperate transmit and recieve version its in the tools section with the other version.cant wait to see if it works with your setup.shame you guys are in the middle of winter.
hey montecarslow theres a modified version of antusprom over on www.delcohacking.net for 1 wire aldl now should help you guys better than our seperate transmit and recieve version its in the tools section with the other version.cant wait to see if it works with your setup.shame you guys are in the middle of winter.
So let me get this straight. If I use the modified version of antusprom + tunerproRT & scannerpro with a montecarslo style nvsram I can do realtime tuning with tracing as well as aldl all at the same time, through a single usb aldl cable?
So it goes like this: tunerpro -> antusprom_software -> ALDL -> NVSRAM_read/writes
All done realtime.
Since the antusprom is using the ALDL resource. Can tunerpro see past it and connect to the ALDL to do data logging at the same time as doing the emulating?
sorry for the late reply guys.antusprom is emulating part of the moates autoprom and works as a passthrough/autoprom emulator for aldl it makes tunerpro think there is an autoprom attached.it can log and tune at the same time via the one usb or serial aldl cable.i dont use montecarslows version of board or bin but it is similar to what i use.as far as i know even montecarslow hasnt tested the antusprom for his version bins yet.but it is a nice setup when its all going.antusprom automaticallly sucks out the bin and then your away tuning.any questions or problems with it ant will be more than happy to answer any for you guys on our forum theres pretty good instructions on that page for setting antusprom and com0com up too work
