Nistune Forums

I have successfully re-written a portion of the ka24e code to take control of Port 6 of the 6303 (address 0017). This output port is connected to the outside world via the PU4424 high speed darlington transistor, with ample load ratings for various solenoids and relays.

Originally this port controls both of the diagnostic LED outputs, AIV, EGR, A/T, and SCV solenoids along with the HA18xx variant on the ka24e board.

I have removed the majority of these emission related routines, by first setting the designated bits "off" for each indicated emission routine and then using the huge surplus of code area to rewrite switching algorithms to my liking.

So far I have 2 regular rpm based outputs (shiftlights, etc.), a reversed rpm output (for SCV control), A temperature based output (Rad. fan), and a MAP sensor based switching output testing out on the bench. Simple assembly routines are very easy to patch in.

This surplus of code area within subroutine of main program is also very useful for other code patches. (very)

While it is not extremely useful for me to post what I have done with the ka24e here, I would be glad to help anyone trying to do the same thing with their 6303 based system.

Here is the port 6 description for ka24e (jecs board).

PORT6:
p67-HA1831P
p66-AIV sol.
p65-Press. Reg sol.
p64-EGR sol.
p63-SCV sol.
p62-Diag LED #1
p61-Diag LED #2
P60-A/T control

'Ex. 6303 assembly to set port 6 to all output (or to confirm it is, rather) soon after reset.

Ldaa #$FF
Staa x0016 '(port6DDR)


'Ex. 6303 assembly to turn LED #2 (p61) "on"

aim #$FDx0017 'set bit 11111101 port 6

'Ex. 6303 assembly to turn LED #2 (p61) "off"

oim #$02x0017 'set bit 00000010 port 6

sounds good. btw i made a fix for the KA24E where consult didnt stop streaming. had to rewrite how and where it was being done.

i'll have to send it through for you to try out

Hey there Gabe,,

Do all the USDM 90-92 stanza ecus interchange with the 240sx KA23E ?

Do they all have consult capabillities?



Cheers
Rune

Hey Rune,

All U12 ka24e ecus 1990-1992 (all yrs) have consult capability.

This includes north american U12 stanza and australian U12 pintara/trx/corsair.

These ecus are pin for pin plug-n-play for 1989-90 north american s13 240sx.

Also with minimal pin changes these ecus can run:

90-93 D21 ka24e
91-94 S13 ka24de
91-93 U13 ka24de
Obd1 Sr20de

Consult wiring is the same as Sr20/KA24de, there are some other relevant wiring diagrams on the ECCS forum, datasheet section I think.

I would love some help doing similar things on my r32 ecu.

I want to build in launch control and shift light wouldnt be too bad.

Where do i get the fireware from? Can i download if from the ecu using nistune?

What program are you using to disasemble? and do you have a pdf with all the ecu's supported ops code?

I'll put some of the disassembly tools and documentation that I use up on the website so you can have a look

ROM images are available in the download directory under 'Type 2' since I collect them all

NIStune boards are code write locked. Ie you can only change data areas of the board. This is to prevent accidental corruption of code if the wrong address file was loaded

It is best to use an emulator such as moates and do uploads via NIStune to this device. This is how I've done my development

(a) compile firmware code
(b) Using NIStune hex editor "insert" button to put code into ROM image
(b) upload updated ROM image to ECU
(c) restart ECU
(d) monitor RAM locations you are using for debugging

Im wanting to maybe do some other mods to my r32 gtr ecu. Changing the fuel cut to an ignition cut would be very very usefull expecially for drag racing any ideas?

I am a hobbiest 3g game programmer so would mind getting down and dirty with some assembly

start with the 6303 datasheet available online. if you want to develop, easiest way is with an emulator

if you want to reprogram your board then getting a base image programmer will allow you to burn new ENT files

i've added ENT regeneration to the software in the last version, but it only copies the maps area based from the address file at this time.

i am thinking of adding some parameters to allow regeneration of ENT files with code section changes allowed to allow tinkering and custom ENT files for programming

First of all, let me apologize for derailing a thread, but I registered here because I felt the need to thank GZ for his post... (the first one in this thread) In his post, he explained the OIM, and AIM usage for activating ports on the 6303, and I have been pounding my head on my keyboard for a week trying to figure out exactly that...

The reason for this isn't a Nissan tho, not even a car.. It's for a snowmobile.

Pretty much none of the mapping software or any other car tuning software will help, and nowhere can I find a snowmobile forum where people are tearing apart the ECU's like this, so I'm essentially on my own on this, from start to finish. I have no experience at any of this, so I REALLY appreciate being able to grab a bit of info from here or there to help!!

When I got into this, I assumed there was 1 or 2 maps for a sled. HAH!!! Not so..

Well, since I was layed up with a fractured hip from getting hit by a sled anyway, I dug in and bought a burner, dumped the chip, found out that even though the subaru software would talk to my ECU, the CPU was different so the subaru code disassembler wouldn't work.. Since there were no forums with people disassembling this ECU, I crutched on down to my barn to grab my ECU, cracked it open (the chip I dumped was borrowed), found the CPU, found a disassembler for it, disassembled, and found myself totally lost in 3000 lines of code..

Oh yeah, and 16 maps.. (2 large tables and 14 small)

Nowhere in the data sheets, was anything about using a particular bit to activate or deactivate an object on a port. His post was a guiding light that is helping me cross a hurdle on this project.

Thanks also goes to Matt for activating me, even though I didn't buy any hardware...

If anyone would like to look over my disassembly for curiosity or to help out, just let me know.


Peace, (and thanks again)
Ug~

thanks for bumping the thread! i was trying to figure out how to activate the LEDs for knock warning and gabe had it in here all along... all i need is an hour of free time to try this stuff out

Glad I could help, the extra bit manipulation and test instructions provided by the 6303 are very handy.

Sounds like a cool project uglykid, I have heard that some snowmobile ecus are similar to the nissan/subaru, and also some heavy equipment (loaders, forklifts, excavators, etc.)

If this can be developed for hcr32 ecu, that would be great feature and extra improvement to be able to control relays etc.

GZ@hybridka wrote:Glad I could help, the extra bit manipulation and test instructions provided by the 6303 are very handy.

Sounds like a cool project uglykid, I have heard that some snowmobile ecus are similar to the nissan/subaru, and also some heavy equipment (loaders, forklifts, excavators, etc.)

It is a very cool project, but way more than I thought I was getting into when I started the process. And has been a steep learning curve, since I hadn't really done assembler since high school in the '80s, and not much of it then.. However following the path has opened my eyes to totally new field of hacking stuff. I like hacking stuff!!

The snowmobile this is for is the Polaris RXL, which was produced from '90 to '96 or '97 when Polaris lost a $40 million lawsuit over it. They didn't release another EFI sled till '05 or '06, and it's a totally different beast.


The reason for this whole project, is that Polaris released the EFI only on a single motor, a 650cc triple, 2-stroke. They also produces a carbed version of the motor, but the EFI version of the motor produces about 25 HP more than the carbed version. The EFI are 44mm venturi, while the carbs are 38mm.

My intent is to take that EFI and adapt it to a larger 800cc triple engine (which also uses the 38mm carbs, just different jets), which hasn't been done. Noone actually EVER transplanted the EFI to ANY other motor that I've been able to find.. ..that makes this sort of groundbreaking.

At the same time, I'm thinking of trying to find a spare input to tie in to my EGT gauges, to trigger a failsafe code in case the engine starts to run lean for some reason. If my coding skills aren't up to speed, I'll just use a eep that's twice the size and hold the extra pin hi/low to do it.

Once I get confidence in my control of the maps, I'll get the sled to a dyno and tune the maps there.


Now, when these old RXL sleds were current, you could buy "hot-chips" that remap the EFI and eek out several more horsepower, totalling near 40 over the carbed version. Problem is, noone is coding those chips anymore, only selling used or old stock. I've emailed several of the old chip-sellers and noone is interested in sharing any of the info they had on how they were produced... So I'd really appreciate someone who has some EFI experience to look at my disassembly and give me a few pointers. The maps and data tables are all located and notated, the code is all located, disassembled, the jumps all traced, broken down into routines, and all the port and map table activity is located and noted as well, color coded on an excel spreadsheet. But I am not good enough at assembler to figure out all the codes and routines. Which ones are reading the sensors, how it uses all 16 tables with only 4 sensors, how does it receive, time, and trigger the pulse, etc..

I would just post the disassembly for all to look at, but I've already caught a couple guys sniffing around trying to swipe my 200+ hours of work for their own use. Well, they can have it when I'm darn good and ready, or they can figure it out for themselves. Till then, I'd prefer to just email it to someone if they'd like to give me a few pointers. (obviously noone that's a newbie here... lol)


Anyone interested in helping out with a few pointers?


Thanks,
Ug~

What type of EPROM is this? Just a 27C256?

If you have a Moates Ostrich 2.0 you could use Nistune to hack together an address file and perform hardware tracing using the ostrich. I'm not too sure if TunerPro has the hardware tracing support in there yet? If so then you could use that instead since you could customise it a bit more to you application

Obviously the snow mobile would need to be running or you would need a bench setup to feed inputs. The chipping places most likely found the timing maps and just tweaked them to eek out more horsepower. I dare say if you bought one of the chips and compared the rom images just one of two maps would be changed and you would be disappointed there wasnt more

What hardware tracing would do is show you which maps are getting accessed and when. It would verify disassembly that you have already nutted out.