ijor / fx68k Goto Github PK

SRMC_RES is defined as:

So it must have a value of 6 and at least 3 bits. Then it is used in this if condition:

What is the meaning of that? Clks.enPhi2 and bcComplete are single bits, the SRMC_RES is, well, 32 bit as an integer with a value of 6. What is the meaning of having it in the expression?

Toni Wilen's cputest flags a possible issue with UNLK instruction.

CPUlvl=0, Mask=00ffffff Code=007c0000 SP=007ffbc0 ISP=00800000
 Low: 00000000-00008000 High: 00ff8000-01000000
Test: 00780000-00800000 Safe: ffffffff-ffffffff
UNLK.L:
data/68000/UNLK.L/0000.dat. 0...

8:	4e5f    unlk     sp
A7: expected f01f007c but got e993f600
Registers before:
D0: 00000010 D1: 00000000 D2: ffffffff D3: ffffff00
D4: ffff0000 D5: 80008080 D6: 7fff7fff D7: aaaaaaaa
A0: 00000000 A1: 00000080 A2: 00008000 A3: 00007fff
A4: fffffffe A5: ffffff00 A6: 007bff00 A7:*007ffbc0
SR: 0000   PC: 007c0000 ISP: 007fff80
T1=0 T0=0 S=0 M=0 X=0 N=0 Z=0 V=0 C=0
000   PC: 007c0000 ISP: 007fff80
T1=0 T0=0 S=0 M=0 X=0 N*0 Z!0 V*0 C=0

Registers after:
SR:*000e   PC: 007c0002 ISP: 007fff80
T1=0 T0=0 S=0 M=0 X=0 N*1 Z!1 V*1 C=0
OK: No exception generated
Registers after:
SR:*000e   PC: 007c0002 ISP: 007fff80
T1=0 T0=0 S=0 M=0 X=0 N*1 Z!1 V*1 C=0
OK: No exception generated
Registers after:
A4: fffffffe A5: ffffff00 A6: 007bff00 A7:*e993f600
SR: 0000   PC: 007c0002 ISP: 007fff80
T1=0 T0=0 S=0 M=0 X=0 N=0 Z=0 V=0 C=0
OK: No exception generated ```

With respect to the following comments:

	// Simulation problem
	// Sometimes (like in MULM1) DBH is not set. AU is used in these cases just as a 6 bits counter testing if bits 5-0 are zero.
	// But when adding something like 32'hXXXX0000, the simulator (incorrectly) will set *all the 32 bits* of the result as X.

If you look at IEEE1800-2017, you will see the following, in section 11.4.3 Arithmetic operators :

For the arithmetic operators, if any operand bit value is the unknown value x or the high-impedance value z,
then the entire result value shall be x.

That means that although in your case you naturally expect the low 16 output bits to not be affected by Xs on the upper 16 bits, this is not what the SystemVerilog spec says, so this is not a simulator bug, but more like a SystemVerilog gotcha.

Other than that, I would avoid the use of `synthesis translate_off altogether, and replace them with an `ifdef ... `endif:

1. They are not defined by the language spec
2. They do not nest.
3. (My personal opinion) They are ugly, because we should never carry information in comments that cannot be ignored. (but it's OK to put optimization hints, for example, because you can safely ignore it).

Icarus Verilog cannot be used for simulation with fx68k, even when using the -g2005-sv option. As Icarus Verilog is the main FOSS tool for verilog simulation, it would be good to be able to use it.

Will support for the HALT input signal and RESET/HALT signals combination be added?

I am running fx68k on a Tang Nano 20k. It worked out of the box and at least boots a MiSTery core to the desktop. Still there are a few warnings which might be worth looking at:

WARN  (EX2420) : Latch inferred for net 'ccrMask[4]'; We do not recommend the use of latches in FPGA designs, as they may lead to timing problems("fx68k/fx68kAlu.sv":830)
WARN  (EX3101) : 'ccrMask' inside always_comb block does not represent combinational logic("fx68k/fx68kAlu.sv":830)

This warning only refers to bit 4. But from similar cases i've learned that this may also apply to lower bits which aren't reported. This is related to the default case in line 805 in fx68kAlu being commented out:

			row[14]:	ccrMask = KNZ00;
			row[15]:	ccrMask = 5'b0;			// TAS/Scc, not used in col 3
			// default:	ccrMask = CUNUSED;
			endcase		

Why is this commented? Enabling line 805 will at least still boot to the TOS desktop. So it doesn't break the CPU completely.

A similar warning is

WARN  (EX2420) : Latch inferred for net 'stype[1]'; We do not recommend the use of latches in FPGA designs, as they may lead to timing problems("fx68k/fx68kAlu.sv":742)
WARN  (EX3101) : 'stype' inside always_comb block does not represent combinational logic("fx68k/fx68kAlu.sv":742)

Why is stype a reg? Isn't it all supposed to be just combinatorics? And instead of

				reg [1:0] stype;
				
				if( size11)					// memory shift/rotate
					stype = ird[ 10:9];
				else						// register shift/rotate
					stype = ird[ 4:3];

				case( {stype, ird[8]})

use something like

case( { (size11?ird[ 10:9]:ird[ 4:3]), ird[8]})

This change also doesn't seem to affect the very basic functionality and the resulting CPU also boots to TOS desktop.

I have been trying to catch a bug in a new arcade core I'm working on. In one stage, the game enters a loop and stays there for 20 minutes or more until it eventually gets out, and the gameplay continues.

I am starting to think that this could be a bug in the fx68k softcore. I don't have any replacement I can just swap and test, and I am not sure what the best way to debug this is.

Maybe you have some reference emulator that you can simulate side by side with your core in a system Verilog environment. If that's the case, please share it and I will try to reproduce the problem in simulation so we can catch the discrepancy.

More a question than a verified bug...

I inadvertently left BGACKn input unassigned (0) (BRn=1'b1) and the processor wouldn't start out of reset because the busArbiter dmaPhase transitioned to dBA and spun there.

Is that how a real 68000 would behave, given there was no prior bus request or bus granted?

Excuse my ignorance, but why do you assign an X to a register? Why have this in synthesizable logic?

I am trying to implement DMA in a system with fx68k (CAPCOM SYSTEM 1). I have read the MC68000 manual about the signals, and I have tried to replicate them as follows:

The CPU starts by signalling data available to the DMA controller (signal obj_dma_ok at the bottom). Then the DMA controller requests the bus: busreq. This gets translated into signal BRn going down, soon after BGn goes down too and BGACKn goes down and stays down during the whole DMA transaction.

I am not sure whether the fx68k core is expecting this signals to occur at specific times or right at the clock edges, or whether anytime is ok. Once I implement this scheme, some games continue working normally (like 1941) but others like Mercs or Street Fighter 2 just fail. Nemo shows a "1111 EXCEPTION" message on screen. Ghouls'n Ghosts fails the OBJ memory check.

I would like to understand better what are the assumptions made on the fx68k core about bus arbitrion and what signals are expected for the handshaking. Could you comment, please?

Thank you

The subq instruction in the code:

is not executed correctly by fx68k. Look at the following signal dump:

The CPU has to read the value in memory address $FFF310, decreased it by one and write it back. The value read is $8401, but the value written back is $0000 instead of $8400.

This is how the same instructions look like through the J68_CPU module, to serve as a reference:

You can see how the ram_data bus is decreased by one in this case.

Could you please look into this bug?