And so, after that minor mathematical misdemeanour, I tried it with the call to putchar removed. It now takes ten seconds to complete (mechanically timed with an analogue stopwatch!) so I'm reading 33.6kB/second. Which feels like it could be fast enough for something like virtual memory for a file ...

Thanks, merged.

Does anyone know why the fix wasn't implemented, and what the consequence of the DIHOLD logic being commented out is? It's been this way for years so I'm guessing that the core is working fine without the fix. But is there is anything I should look out for? Or should I just apply the suggested fix ...

Sorry, my bad. The last character got chopped.

Thanks to Garth for posting a working link.

Dave

The Rockwell 6512 in the B+ is an NMOS processor, so has the same instruction set as the 6502.

FYI, the datasheet is here:
http://archive.6502.org/datasheets/rock ... x_r651x.pd

Dave

One recommendation: don't leave unused inputs of 74HC series (or any CMOS logic device) floating. Connect them to ground directly, or if you think there is a chance you might want to use the gate (e.g. as a patch) then connect them to ground or VCC via a pullup resistor.

Are the two different reset ...

Screenshot from 2025-06-29 22-13-53.png
To my surprise, it needs 592 diodes, probably because of all the zero page addressing references.

You could save some soldering by using ZP addresses with lots of ones for:

org 0
leds ds 8 ; led will display patterns stored here
mem_ptr ds 2 ; where are ...

Seems like a live thread.
I am wanting to re-assemble the disassembly listing of the Acorn Atom OS ROM (modified to move the start of the video memory, where the address is hard coded).

In case it's of any use to you, here's a copy of the Acorn Atom OS that can be re-assembled using ca65.
atom ...

Most of my experience is with Arlet's core -- any my own... Never had that issue.

The 65c02 system is fine with everything on posedge, and Arlet's core puts the signals on the bus and expects a reply next cycle, and other inputs are timed accordingly.

Arlet's core is fairly unique in that ...

I don't understand why I had to invert the clock. The core, 6809p going back to John Kent, is in VHDL. I know next to nothing about VHDL, just enough to incorporate it into my verilog. I don't want to know anything else about VHDL. But it looks like it is working off the posedge of the clock, so ...

I'd be tempted to knock together a quick GHDL simulation of the complete system.

Dave

There's a global attribute called syn_looplimit that should allow this to be increased.

Dave

hoglet, have you had any luck specifying which PLL should be engaged?

I've not had any problems using both of the PLLs being driven from the 27MHz oscillator connected to pin 4. You can see the way the PLLs are instantiated in the VHDL here:
https://github.com/hoglet67/BeebFpga/blob/dev-tang ...

The examples show pin 4 as clk input, and I am getting a warning that it is not a proper pin for connecting to the clock routing, etc:
WARN (TA1132) : 'clk' was determined to be a clock but was not created.

I think this warning means you are missing a create_clock constraint from the SDC file ...

For a while there was an FPGA carrier board from a seller called eepizza but I think supplies dried up.
Yes, even just a replica of this "eepizza" board using a more available FPGA (Artix-7 or ECP5) would allow allow the project to be resurrected (using the existing daughter boards for level ...