Search found 125 matches

by tvrfan
2025 Feb 16, 18:01
Forum: Hardware, Programming & Disassembly
Topic: EEC V file conversion
Replies: 674
Views: 281588

Re: EEC V file conversion

SAD 4 (most versions) - BUG.
Shows inconsistent operand size for divide and multiply, maybe others.
NORM show operands the wrong way round?

Will fix these in next release (h/t sailorbob, jsa)
by tvrfan
2025 Feb 16, 14:00
Forum: Hardware, Programming & Disassembly
Topic: EEC V file conversion
Replies: 674
Views: 281588

Re: EEC V file conversion

Just a thought here -

Note that the CPU ITSELF runs the extra code in the cal console, so the console doesn't need to see any banks directly, it can do what the EEC code does, and set ROMBANK and/or R11, saving and and restoring CPU state at the end before the RET. This is the same as an interrupt handler subroutine will do.

So only the code within the cal-console itself would have to change to enable and see banks, not any physical interface. I reckon there will be EEC-IV versions and EEC-V versions, because of updated code, but it's just a guess from me.
by tvrfan
2025 Feb 16, 04:14
Forum: Hardware, Programming & Disassembly
Topic: EEC V file conversion
Replies: 674
Views: 281588

Re: EEC V file conversion

could be true - earlier bins tend to check a flag somewhere else, but checking for PUSHP at call address is just as good I reckon.
by tvrfan
2025 Feb 15, 21:09
Forum: Hardware, Programming & Disassembly
Topic: EEC V file conversion
Replies: 674
Views: 281588

Re: EEC V file conversion

Have a look in the Ford handbook (via https://github.com/OpenEEC-Project/Usef ... C_handbook) Near the end, (section H) there are a set of memory maps. You can see there are several 'reserved' address and ranges of addresses defined for cal console and related stuff.

Unfortunately, the code listings don't always show the same addresses being called/checked for cal_console and special chips, so I haven't built them into SAD. The details differ a little too. The good news is that the overall address range of 0x1800 to 0x1ffff DOES seem to apply to all bins, and especially 0x1f00 to 0x1fff, how the banks map onto these isn't clear either (jsa above), some seem to call bank 8, some call bank 1 (?). So if you spot something around those addresses (ignoring the bank), it's probably a plug-in console.

What we can work out is that the cal console announces it's there in one address, and then ROM in the cal console itself is CALLed as if it was just another subroutine. This allows extra functions in the cal console to be run by the CPU, and gives cal console full access to everything the CPU can see. It also seems to be a standard technique in all bins.

You can see the special add-on chips (page H4) also have different address range options too. I think these turn up in bank 1, but not sure...

Hope that helps !!
by tvrfan
2025 Jan 18, 13:55
Forum: Hardware, Programming & Disassembly
Topic: EEC V file conversion
Replies: 674
Views: 281588

Re: EEC V file conversion

More bug fixes to 4.13.8, but note that I have now put in a limited 'gap scanner' for missed code, which should reduce the need for extra SCAN commands. It's not finished yet, but it seems to work quite well, so released it as is.

Still more to do........
by tvrfan
2025 Jan 17, 03:18
Forum: Hardware, Programming & Disassembly
Topic: EEC V file conversion
Replies: 674
Views: 281588

Re: EEC V file conversion

After some more bugs found (and ones I caused by screwing up), SAD now at 4.13.7
by tvrfan
2025 Jan 09, 17:24
Forum: Hardware, Programming & Disassembly
Topic: Clock speeds of any/all boxes**.
Replies: 4
Views: 765

Re: Clock speeds of any/all boxes**.

(as Decipha says)
From what I understand, if you could overclock it hardware-wise, for software/code you would only have to change a few fixed params to get timing to work right. Every bin has to convert CPU I/O Ticks (main clock/16 or 28 for 8065...or something like that) to milliseconds. Code (almost) always uses a 32 bit long divide. Once this is done, I think everything would work ? Not entirely sure.

Hardware is the limit I reckon (as already said).
Also not if there is some stuff driven directly from clock or IO ticks though, probably RAM, any special chips, etc. but it's all Hardware.
Also overclocking would produce more heat, and so there is probably a risk you would fry something.

I don't think it would improve anything engine-wise. In CPU terms (even the old ones), there's about 2 weeks elapsed between each spark.
by tvrfan
2024 Dec 30, 13:54
Forum: Hardware, Programming & Disassembly
Topic: EEC V file conversion
Replies: 674
Views: 281588

Re: EEC V file conversion

Boosted.... Yes - SAD is displaying both columns as decimal, but that last 32768 is wrong, should be negative. Damn....

released 4.13.2 to fix this problem.

Thanks.
by tvrfan
2024 Dec 29, 16:27
Forum: Hardware, Programming & Disassembly
Topic: EEC V file conversion
Replies: 674
Views: 281588

Re: EEC V file conversion

As always, if you do find something weird, report it here and I will (try to) find if it's a bug and fix it.

I do test new versions, but there's many different bin versions and 'tricks', so errors can still sneak through.
Last big SAD change was for the discovery that some bins have RAM at the top of their Bank 1 (RZASAMA series).
FM20M06 still doesn't work, and still unclear how some of the 'special chips' work from the raw code perspective.

Boosted - Sorry I did misunderstand what you were reporting, but your post cleared that up, and then I found code that didn't look right.

There are still some 'catch 22' situations which I haven't worked out how to resolve yet ...

Note - I decided to add some 'maths operators' to options , so 'V' now has a '/' (divide) and added a '*' for multiply, which is new, and maybe will add a '+' for 'D' (offset by) and maybe a '-' (minus) too, so it's more obvious to everyone. Complex formulas in Version 5, but tough to bolt onto V4.
by tvrfan
2024 Dec 28, 13:07
Forum: Hardware, Programming & Disassembly
Topic: EEC V file conversion
Replies: 674
Views: 281588

Re: EEC V file conversion

Just released 4.13.1 in Github.

Status is -

4.0.13.1 changes

1. Add - Allow options bank (K) and pointer (R) in data items for word, args, subr commands.
2. Add - add options / for divide, and * for multiply (both floating point)

3. Fixed - Symbol names not appearing. Caused by incorrect bank handling in print (may not fix all cases yet) - word,args,struct, vect commands
4. Fixed - comments assigned at end of bank (e.g. 1ffff ) do not get printed correctly (or at all).
5. Fixed - bins with missing bytes at front may not be processed correctly. Added extra checks for end of bank.

6. Change - tighter checks for faulty data or pointers whilst emulating code.

NOT FIXED - For subroutines which jump into another subroutine (instead of a CALL) arguments occasionally get missed. Still working on this.