Question about 68k cpu

[Spindizzi]

Hi,

For the time being, my recommendation is to run this 68K from the main thread and simply ensure "-no-sound" and "-no-dsb" are always forced on in your dev build. You're not going to care about sound initially

Thanks for the tips, I can now run the 68k code with that.
My only aim is to init the netboard and pass the first check, but many trouble with it. apparently my ram/reg mapping in model3 doesn't correspond to the mapping of the board -> model3 wait for memory modification at some addresses and board does this at others places. May be because I have processed all the code (convert from 32b to 16b and little indians).
Anyway, It's only preliminary tests nothing more. I now see it's a very complex task (for me, ). I suppose it'll take you only some hours to do what I've done in weeks...
I will post all I find later of course

[Bart]

Do you have code successfully loading into the network board RAM? What do you mean by the reg mapping? Where are you getting it from? I think this is something that Nik deduced himself.

[Spindizzi]

Hi,
Yes the code is loaded successfully
reg mapping <- register mapping
I know Nik has done this some years ago, I saw the video on the tube

What I've found/done. I'm sorry if it's not very very clear
the board is at @0xc0000000 (thx Mame) same as the scsi board
-> I suppose there is no scsi board for stepping > 1.0 nor netboard for stepping < 1.0 to avoid conflict.
model3 tests if it can read/write the netram and then copy the 68k prog into it directly from a part inside the rom (no dedicated rom)
-> when done supermodel prints netboard downloaded at boot and prints also this a master/slave/live text. And finally waits for something. It tests a memory adresse in a loop.I can poke this memory to different values to go out of this loop

On the netboard itself
once i've got the microcode fully loaded in netram, I convert it to 16bit ram and little endians then I reset the board to boot with vector 0xff (reg) and 0x800 (origine of prog) <- the 1st 2 longs words in the netram (vectors for the 68k cpu)
We have the 68k program when looking the dump with IDA 68k with origine at 0x800
it gives us different adresses to understand the rest of the 68k prog (0xC0000 -> A6, 0x40000 -> A5, 0x80000 -> A4, and 0x242c -> A0) According to Mame this is respectively the ioreg ( 0xff long), the ctrl r/w (0xff long) and the communication RAM (0x1ffff long)
the netboard runs the 68k code and enter in loop to test @0x60c (PC=0x834), apparently, the value in 0x60c branches to differents subroutines. If I insert 0x01 at this address, I've got a full flush of the communication memory (it writes a serie of 0x55 and 0xaa). Other values send to differents loops. I've tested 0x02, 0x04, 0x0f, 0x10
0x01 -> flush/test communication ram (128kb)
0x04 -> PC=0x1278 test @0x608
0x08 -> PC=0x1550 and 0x1560
I think the @0x60c is a sort of status code (test, send ready, receive ready). Is it read by the main board ?

Other things, at @0x2000 in the dump, it's seems to be a 2nd 68k program or subroutine

This is all I've got and I'm stuck here (and I'm a little lost too ). I can't debug the 68k in real time because it never shows the netboard cpu in the supermodel debugger, may be I need to completely remove the soundboard from the supermodel code even if I've set -no-sound and -no-dsb parameters

the memory dump of the 68k code from daytona2pe
https://yadi.sk/d/xoWs4ysk3GrMzL

[Bart]

There should be a way to add the net board CPU to the debugger. It's a pretty extensible framework. May take some studying to understand how it works but Nik was able to hook up all the CPUs to it.

Also, depending on how big the 68K program is, it may make sense to try to fully disassemble it and, as you make progress, comment it and turn it into more human-readable equivalent code (with named labels or even C translations of the subroutines). Is it a very large program?

[Spindizzi]

Hello,
How did he do that, that is the question ?
I'll try to "remove" the soundboard, we'll see... but I'm very busy actually
It seems to be a not too long program
I hope the dissassembly from IDA is not too bad, because there is a lot of data (dc.b dc.w dc.l)
https://yadi.sk/i/RwcOD_vM3GtVGH
I'm never touch a 68k since at least 25 years,

[Ian]

Apparently new versions of ida pro can turn powerpc assembly back into C like code ..

[Spindizzi]

Sadly, the version I have doesn't allow that conversion (68k to pseudo C or ppc to pseudo C)
I saw tools exist for asm 68k to pseudo C but I don't have any of them