Do you want to be the Windows guinea-pig? I can build everything for Windows x64 and you can try it. I still have not found a good front-end to GDB on Windows, so having you kick the tyres would be useful. It's up to you, if you prefer the more tried & tested Linux route you can go that way if you prefer.
Yep, very happy to do that. Linux is a strange universe for me, I have to google for the most basic things (IE, I had to google how to open a shell).
Note the three JEDEC ident bytes 20 20 13. What do you get?
From Windows again, here's what I get:
Code: Select all
D:\Archives\Drivers\UMDK\Tools\umdkv2-bin>"D:\Archives\Drivers\UMDK\tools-bin-20
151220.tar\tools-bin-20151220\tools-bin-20151220\flcli\msvc.x64\rel\flcli.exe" -
v 1d50:602b -a "w1 07;w0 9F;w1 05;w0 FFFFFF;w1 00;r0 3"
Attempting to open connection to FPGALink device 1d50:602b...
Connected to FPGALink device 1d50:602b (firmwareID: 0xFFFF, firmwareVersion: 0x2
0140311)
Executing CommFPGA actions on FPGALink device 1d50:602b...
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
0000 00 00 00 ...
BTW, can you take a look at my above post analyzing Montserrat's Sonic 1 crash?
There's only two other devices in the Mega Drive that can drive the M68K bus, the VDP (during a DMA write), and the Z80, which does it indirectly through the bus arbiter. The Z80 never formally requests and releases the M68K bus, but rather, when accessing the banked memory region at 0x8000-0xFFFF in the Z80 memory space, the bus arbiter requests the bus, and once it gets ownership, it performs the read/write on behalf of the Z80, forwards the result onto the Z80 bus, and releases the M68K bus when it's done. This can occur at potentially any time during system operation. The exact timing of this process is currently undocumented as far as I'm aware, and seeing the number of revisions that device went through, I wouldn't be surprised to find there are differences between models in the behaviour. The VDP will request the bus for DMA in response to fairly recent access from the M68K (and potentially even the Z80 through banked access), and will release it when done. In the case of a currently executing VDP DMA operation, if the Z80 attempts to access the banked memory area, the bus arbiter will wait until the VDP releases the bus before it requests it and forwards the Z80 access attempt, effectively keeping the Z80 suspended waiting for the bus to become available.
From the cartridge port, you may have trouble detecting all of this. the BR, BG, and BGACK lines aren't exposed over any external ports. It's certainly plausible for there to be a glitch on one of the signal lines during "hand-over" of the bus to/from the Z80. It might actually be 68000 related though. When you say the "C_OE" line, which line exactly are you referring to? Is that coming from the "AS" line on the 68000? Because if it is, according to the M68000 User's Manual, under the "3-Wire Bus Arbitration Timing Diagram" (section 5-13), it appears the AS line is left floating for a few cycles during bus hand-over. DTACK however is valid the entire time, and that line is available on the cartridge port. Based on my reading of the timing diagrams, I think you should be able to use DTACK to ignore AS when it's not valid during bus arbitration. Does that look possible to you? Or on a less extreme route, and my knowledge of electronics is unfortunately lacking here, but maybe you can safely "pull up" the AS signal yourself if it's floating, without affecting the rest of the system?