jinx
another thought,
If i were designing an ECU, it would consist of two parts.
First would be initialization, followed by a recursive main program. As such, there would be two addresses of concern. The first line of the initialization, which is hard coded in the CPU.
The second would be the first line of the recursive section. There may be yet another section for subroutines or for calls that lead to terminal error routines.
For the nay sayers that complain about the 8-bit processor, the primary limitation is the ability to address only 64k bytes of code directly without some form of memory paging scheme. If you can't write a decent ecu program in 64k bytes, you need to go work for microsoft and write bloat code in C++. Assembly is a real man's language!
Best of luck,
sunrotor

 

still reading about the HD6303 for clues,

There are two modes of operation with regards to addressing. Based on the presence of a TC40H373P OCTAL TRISTATE LATCH, the cpu operates in multiplexed mode.

The cpu also uses interrupt requests, which are triggered through a 4013 flip-flop from the HD46821P PIO/PIA which generates an interrupt request on IC606-02 PA0 IRQ_EN connecting to RP612-01 & IC608-10(flip-flop)

Between looking at the ecu interconnect list and the cpu specification (and other IC specs), it should be possible to eventually develop the theory of operation, but what a job. I'm gaining more respect for reverse engineering every day i look at this.

keep on trucking
sunrotor

 

Has anyone thought about asking Mazda for the original (commented) assembly code? By this point they can't be liable for any rx7, and I doubt they'd be worried about giving away engineering secrets from an ecu this old.

If someone has a good adress (snail mail) to contact them at, lets put together a petition for them to release the code.

 

Guys, the code entry points of interest are the reset location and the interrupt service routine vectors. (And maybe one or two other things, TBD.)

These are all stored at the very end of the rom.

Here are the entry points from my mazda.sym file.

;Program entry points via reset or interrupt

vector 0xFFFE reset
vector 0xFFFC NMI_(non-maskable_interrupt)
vector 0xFFFA SWI
vector 0xFFF8 IRQ1
vector 0xFFF6 IRQ2_ICI
vector 0xFFF4 IRQ2_OCI
vector 0xFFF2 IRQ2_TOI
vector 0xFFF0 IRQ2_SIO

;this jumps to somewhere outside of the ROM
;vector 0xFFEE TRAP_(undefined_instruction)

;this may or may not be a program entry point
vector 0xFFDE No_idea

 

One thing I would really like to know about is the copyright status of the original mazda ROMs. Are they copyrighted?
They do not bear a copyright notice, either on the chip or in the ROM contents. Before 1989, this was required on copyrighted items.

 

Hmmm, I don't know if anyone has evr tried that approach.

Loudroom. I've found a few things that I'll be posting here later this Evening.

 

guess that wont work :X

 

Yeah I was gonna say, it's probably all proprietary. Just like Honda. I don't even think Mugen had access to the code, but I could be wrong.

We'll get it damn it!!!!!!!

 

it will be great when you do.. i look for new posts everyday, so dont give up at all

 

Loudroom, were you able to do dumps of the two eproms? IC04 and IC05?

 

Yes. The data in my ROMs was identical to those on the 16paws site. Then I combined the two ROMs and started disassembling them.

I need to hunker down and translate some of the code by hand, as a sanity check of the disassembly, but I haven't had time yet.

If one was to download the 2 images from the 16paws site, join them into one large image and then disassemble them using dasmx and the symbol files I've uploaded, they'd be at the same point as me.

 

Ok, think I'm back on track. Loudroom try to do the dasm using the symbol file for the other two roms and see what you think. I've checked some things and they seem the same so try it and let me know what you think.
I'm just hoping that this would save tome time, if the are essentially the same.

 

I don't understand any of the computer stuff, but I get the idea and I like what you guys are doing. Keep it up. I appreciate it.

 

I' ve managed to trace most of the signals from the middle connector through the analog board. Once I finish all of them, I'll need a place to post the schematics.

Also, mazdaspeed7 is being nice enough to give me a ford MAF to do some testing

 

That's awesome, have to do something nice for him in return. I'd like to compare notes on the dasm, just so we can synch up on where we are.

 

I haven't really done more than I've posted here, as far as disassembly goes. I want to finish up these schematics first.

 

gotcha, i'm jumping in feet first on the dasm. When you get a chance, look at your dasm and tell me what you think about the fuel map(s) I'm having a little trouble figuring out where they actually begin. In my dasm there are quite a few, it's kinda weird and I'm just trying to get an idea of the structure. Are they 16 X 16 or something else?

 

I figured I should probably post a link to this thread here:
http://forums.corvetteforum.com/zero...&id=1546201287

specfically for this post by me:
"Thanks. It's been a decision between the '88 Corvette and the '88 Mustang MAF's.

It looks like I'll be going with the mustang unit, for 3 reasons:

1) They're both physically about the same size, but the Mustang MAF has an aluminum body, meaning it doesn't have the heatsink inside the sensor like the 'vette.
2) The Mustang MAF is cheaper $90 vs. $200 at Pep boys or Adv. Auto Parts.
3) I'm getting one for free.

I liked the fact that the 'vette sensor is made by bosch and has a burn off cycle, but I'm trying to keep things cheap and simple."



Do we have a consensus on this? I think we should both use the same sensor, this would allow us to share the same conversion table.


Also,
I need to find datasheets for some of the parts inside the ECU. There are about 4 ICs that I need info on.

If anybody know of a good datasheet search engine, I'd appreciate a link.

 

loudroom,
If you want assistance tracking down old\obsolete parts, just post them, and we'll try and dig something up. I have 25 years of electronics manufacturing, and some contacts, that may help get the data you need.

It isn't uncommon to try this kind of thing when your customer is trying to build spare printed circuit boards years after the original units were made. I've spent more time at this than i care to admit. Shame I can't charge my going rate!!

sunrotor

 

Loudroom... I'd be will to send you my performace chip that I got of ebay, if you pay the cost to send it back to me...after you copy it.....I'm not even sure if it is the real thing..

e-mail me morphious@satx.rr.com

 

Sounds great.

Here are the chips I'm battling with right now. I'd like datasheets on them, or at least a description.

If I can get datasheets one these chips, I'll be able to complete my schematics for the analog board.

IC500:
nonstandard 24 pin DIP package, 0.070" between pins, 0.300" between rows
Two lines of text on the package:
First line:
D 151821-0020
Second line (smaller print than the first, lower right corner):
701AH
The second line is probably just a datecode.

IC450:
standard 8 pin DIP package
Three rows of text on the package
First line:
NEC JAPAN
Second line:
C1251C
Third line:
645C

IC100:
standard 16 pin DIP package
Two rows of text on the package
First line (the ND looks like a manufacturer's logo):
ND SE057
Second line (right justified):
1G07A

IC000:
Weird, ten pin, single row package, 0.10" pin spacing, plastic package is 0.7" high, .29" wide, beveled at the top of the package on the left and top edges.
One line of text
D HC131 1G21
(the 1G21 is in smaller text, probably a datecode)

IC400:
Weird, twelve pin, single row package, 0.10" pin spacing, plastic package is 0.68" high, .20" wide, beveled and notched at the top of the package on the left edges.
One line of text:
D HC128 1G20
(the 1G20 is in smaller text, probably a datecode)

All packages are black plastic. All are thru-hole devices.

 

I might be interested in this, but I'll need to get further along first.

 

Just an update here.

I've started looking at the disassembled code from the ECU. It looks like the fellow on the 16 paws site is right again, and this processor is some variant of an HD6303, not described in the datasheets posted on the site.

I've started trying to get a register map for the lower addresses and it looks like these two addresses are like this, NOT like the datasheet:

0x001B Output compare register 2 (high)
0x001C Output compare register 2 (low)

Has anybody tried to get ahold of this guy?

 

It seems there were a crapload of different verison of this CPU.

http://members.tripod.com/kmi9000/kmi_proc.htm
http://www.212cafe.com/download/8051...S32_/E6800.ASM
http://www.cpu-museum.com/630x_e.htm
http://www.geocities.com/TheTropics/...srguide-5.html
http://www.geocities.com/TheTropics/...lator/sim68xx/
http://www.d1.dion.ne.jp/~ytera/1chipCPU.htm

Above are some links about it.

The 16paws site has datasheets for 3 types of this processor but I'm going to be looking for more.

 

I've emailed him numerous times with no reply. He posts on the RXTech Yahoo forum as well, so I've been looking around there to get ideas. I also know that he was somehow in cahoots with the Henrick guy too, which I've also emailed a bunch of times. Seems like either they don't want to be bothered with it anymore, or they have other plans for this project.