I have an endless loop in this part of code

lines 3898-3916

Easy68k v5.16.1

Thanks for the great MCZL8 solution! I am having a lot of fun using it with my MSX.
It looks like the HALT instruction is not working as it should. When a HALT is issued, it gets repeating the halt instruction.
I think the 'register_pc--' should not be there?

`void opcode_0x76() { // Halt

digitalWriteFast(PIN_HALT,0x0);
halt_in_progress=1;
register_pc--;
return;

}
`

Tested this code in 'IM 1' mode. After a HALT is issued, an interrupt should resume the CPU but it does not.

`
ei // Enable interrupts
halt // Wait for interrupt
ret

`

I get an error trying to synthesize mclwr1.v in Diamond 3.6 or 3.12:

documents/impl1/source/mclwr1.v(120): net rx_fifo_wr is constantly driven from multiple places at instance RX_FIFO, on port WrEn. VDB-1000
Done: error code 2

And programming directly from the JEDEC in the repo produces transmit checksum errors and results in a non-functional board.

Hi, did you buy or make the 40 pin dip breakout that you would connect the jumper wires with?
Just to be clear, this is the board that you inserted into the motherboard 40 pin dip sockets.

nn shall not be a fetched opcode (no /M1 = 0 and R shall not increase).

The comparison operator for "BLTU" in riscv.c (l. 91) should be "<" instead of ">=" (this line is identical to the "BGE" line below it except for the instruction name):

if (opcode==0b1100011 && funct3==0b110) { if (rv5_reg[rs1]**>=**rv5_reg[rs2]) rv5_pc = ( (B_immediate_SE) + rv5_pc) - 0x4; printf(" BLTU "); } else // BLTU

Hey,
for better reach of the community, I would like to suggest to add the following topic to the repository: motorola-68000

How to do this

This function is called too often wrongly to retrieve immediate values, displacements or offsets in an instruction. You should use a MEM_READ_BYTE (3 T-states) and not an OPCODE_READ_M1 (4 T-states) for them!

There is no M1 = 0 and no refresh when retrieving immediate values, displacements or offsets in an instruction!

See here a complex example here: https://floooh.github.io/2021/12/06/z80-instruction-timing.html#dd-and-fd-prefixes. Be aware the table are showing steps per half-cycle (half T-state) so a MEM_READ_BYTE would be 6 rows for 3 T-states.

Can SN74LVC573AN be replaced by other series? On the schematics is written 74LS573, but I am not sure will it work?

hi, MCL64 seems to be a great thing but i got some errors on checking a working c64 board (250407).
Before I started with MCL64 I was checking the hole hardware with my UfD Set (https://www.forum64.de/index.php?thread%2F127712-ufd-cartridge-dual-diagnose-cartridge-mit-spannungs-und-frequenzmessung%2F=&pageNo=1 which reports no error on the rams and roms.
After that I run some tests with my MCL64 the roms got a passed status.

But a check of the DRAM fails

Ans the initial test also reports failures inside the roms, which passes the single test before

Is it possible to solve these errors?
I also think that all the different board releases out there (250407, 2050425,250466, 250469 and the older ones) maybe report other results. The most of them are in my collection so I can so some tests if you would be so glad to update the code.
happy hacking and kind regards
znarF54

I'm mostly interested in the SuperCPU potential of the MCL64.
Today I just found out about the RAD cartridge project: puts a Raspberry Pi 3A/3B or Zero 2 on-board a cartridge and it supersedes the 6510.
What would it take to put the MCL64 onto a cartridge board?

Hi Ted,

Great work on all of these projects.

With the Teensy having 1024KB of RAM (albeit only 512KB tightly coupled) and with relatively mild RAM usage in the main accelerator, is there any reason we couldn't have Internal_RAM be 0x80000 or even 0xA0000? The latter would bust the tightly coupled RAM but should still fit?

Regards,

Greg

GitHub has some information about this topic at https://help.github.com/en/github/creating-cloning-and-archiving-repositories/licensing-a-repository

Hi, I just stumbled upon your eprom emulator project. It looks like at the moment the max size is 64KB (27C512). I have a project that needs 512KB (27C040). I wanted to see if it would be possible to scale this design up for that and if you had any recommendations to accomplish this?

Having trouble compiling this core. I cannot locate the ROM_2Kx32 module.

I've soldered up one of these MCL64 boards, and am getting a black screen on power up on a 64. I programmed the Teensy successfully, and am certain there are no bridges (did the soldering under high magnification under a microscope). Triple checked my soldering, and used the mouser part numbers from the BOM.

The only thing I can think of is that somehow I haven't oriented the chips correctly as I don't see anything on the board that indicates where pin 1 should be. I assumed that the top of the chip, with the pin 1 dot, is towards the Ux designation for each chip.

If my chip orientation isn't an issue, I am otherwise at a loss as to why it doesn't work for me. Any suggestions on troubleshooting would be appreciated.

Using the MC68000_test_all_opcodes.X68 test rom, the MOVE from SR test does

move #$275A, SR        * Initial value
move SR , d0
cmpi.w #$275A , d0

But from the M68000RPM, on the MOVE from SR instruction

Unimplemented bits are read as zeros.

Since the bit 6 of the SR is unimplemented, the test should compare with $271A instead.

Also this has been proved to be wrong on an actual hardware (Philips CD-i, having a 68000-based CPU) :

About the other instructions that fails on hardware, we are not sure yet why they fails.

About the screenshot : your test ROM has been modified so that when a test fails, instead of doing an infinite loop, it prints the name of the test that fails on the serial port of the console, and continues with the next tests.

I used the zexall from: https://github.com/anotherlin/z80emu/blob/master/testfiles/zexall.z80!

To do so, I tweaked the firmware so it can run on my SHARP MZ-80 K this way:

1. Mode 3 for RAM to speed up ZEXALL execution as it may be quite slow on a 2MHz machine,
2. Virtual RAM from $0000 to $CFFF since ZEXALL starts from $0100,
3. I/O memory from $D000 to $FFFF is kept but never used,
4. IN A,(n) is tweaked to output a string to Serial USB terminal,
5. OUT (n),A is tweaked to issue a HALT forever (interrupts are ignored),
6. $0000 and $0005 are also tweaked to issue OUT and IN.

So when booting the machine, here is what I get:

According to Teensy 4.1 specs all pins are not 5V tolerant. I have noticed that only data bus is buffered between 5V and 3.3V with two 74LVC573 latches. Address bus is connected directly which means 5V signals will reach Teensy inputs and can theoretically damage it. Moreover I have found that MCL64 version intended for Commodore C64 has buffers for both data and address bus. Could you please explain this?

Sorry to raise this as an issue...
Is there any chance MCL64 can be adapted to run on a Raspberry Pi Pico? MCL64 could become a real alternative to a MOS6510 for C64 enthusiasts, but is see the Teensy4.1 being just too expensive. I would consider 1x speed emulation of a MOS6510 through a Pico acceptable.
For the time being there is this alternative available: https://monotech.fwscart.com/MOS_CPU_Replacer_(65108501)/p6083514_21591072.aspx

The memory access to the byte for displacement jump (or not) is taken one T-state too early compared to a genuine Z80. For Z80 machines which are very sensitive to /WAIT pattern (e.g: AMSTRAD CPC), it may alter the whole timing and so the behavior of the CPC program counting very much about the cycle accuracy regarding the memory access.

That extra T-state at the end of M1 M-cycle is due to an internal "dec b". In mode 0, the MEMORY READ M-cycle for memory access to displacement byte should happen 5 CLK cycles after M1 M-cycle, not the usual 4 CLK cycles.

See DJNZ: https://www.manualsdir.com/manuals/753749/zilog-z08470.html?page=287

It is not the only instruction to have extra T-states inserted in the middle of the whole instruction T-states.

Could you please upload the file usercode_rom.hex for RISC-V core:

Hi -

I am wondering if you have checked your (beautifully neat) 6502 implementation against a respected test such as Klaus2m5?

I ask because I have been testing my own emulation, and I have trouble with the notorious ADC/SBC opcodes. When I tried your implementations it also failed.

I see in your code the line:

if ((0x00FF&bcd_total) > 0x09) { bcd_total=bcd_total+0x010; bcd_total=bcd_total-0x0A; }

which contains a reference bcd_total before it has been assigned a value, thus the condition is never true. Maybe you missed something?

thanks!

-John

Just a thought, have the C64 version use writes to $d030 control which cache mode to use, somewhat like the C128, SuperCPU and Ultimate64 kits do to switch between 1 MHz and whatever speed they run at?

(ref: comments a few lines down in this thread https://www.lemon64.com/forum/viewtopic.php?t=75567&sid=f14af11e92b12b174d17ca269f6ef23a )