I just received and assembled the romulator but it doesn’t work in my Pet 8032. The FPGA flashes once and then nothing, not even the chirp. This is in a working PET with a working 6502.

Tested with - Standalone Programmer-Debugger D1-mini

When the D1-mini tries to read the last 8 bytes of vram, the first 7 bytes read from this section of the FPGA are correct but the last byte is wrong.

This is due to an incorrect vram size parameter calculation in verilog code "enable_logic.v". The size should be 1024 bytes, but 1023 is set.

Change :
wire [10:0]vram_size = vram_end[config_byte] - vram_start[config_byte];
to
wire [10:0]vram_size = vram_end[config_byte] + 1 - vram_start[config_byte];

With this change, once the FPGA has sent the last byte the address rolls over from 1023 to 0 when the code adds 1 to 1023 (11 bit wide address bus). This additional change is therefore required.

Change line from
else if (vram_address == vram_size)
to
else if ( (vram_address == vram_size) || (vram_address == 0) )

Issuing the command 'BASEURL=http://bitfixer.com make fetch_roms' I get the following error.
I also get this trying to use the zimmers pet rom directory as the base.

user@ubuntu-compiler:~/bf-romulator$ BASEURL=http://bitfixer.com make fetch_roms
mkdir -p roms
#cd bin; python ../tools/fetch_roms.py /home/user/bf-romulator/config/memory_set_default.csv http://bitfixer.com
cd roms; python ../tools/fetch_roms.py /home/user/bf-romulator/config/memory_set_default.csv http://bitfixer.com
Traceback (most recent call last):
File "../tools/fetch_roms.py", line 26, in
for row in romreader:
_csv.Error: iterator should return strings, not bytes (did you open the file in text mode?)
make: *** [Makefile:85: fetch_roms] Error 1

Any suggestions?

Hello Michael,

many thanks for the romulator 6502. it really is a great tool.

I have a problem with creating my own custom firmware. The "make program" process is always aborted with an error message. I just can't find the problem and hope you could give me a hint.

I am using a Raspberry Pi 3+ with the latest RaspianOS (64Bit).

When I generate the files via your website, the firmware works on the romulator.

Best regards Frank

Logfile:

pi@romulator:~/bf-romulator $ make program
gpio mode 27 out
gpio write 27 1
gpio mode 6 out
gpio mode 10 out
bin/programmer -b
mkdir -p bin
bin/build_enable_table /home/pi/bf-romulator/config/enable_table_default.csv bin/enable_table.bin > bin/enable_table.txt
mkdir -p bin
cd /home/pi/bf-romulator/romulator; rm -f input*.v; rm -f *.pcf
cp /home/pi/bf-romulator/romulator/6502/* /home/pi/bf-romulator/romulator
cd /home/pi/bf-romulator/romulator; rm -f hardware.*; apio build
(DEBUG) Profile path: /home/pi/.apio/profile.json
(DEBUG) Home_dir: /home/pi/.apio

PATH: /home/pi/.apio/packages/tools-oss-cad-suite/bin:/home/pi/.apio/packages/tools-oss-cad-suite/lib:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games

[Fri Jan 12 20:36:50 2024] Processing upduino
------------------------------------------------------------------------------------------------------------------------
yosys -p "synth_ice40 -json hardware.json" -q SPI_Master.v diagnostics.v enable_logic.v input6502.v ramenable.v simple_ram_dual_clock.v spi_flash_reader.v spi_slave.v sram.v sram64k.v
Warning: Yosys has only limited support for tri-state logic at the moment. (spi_slave.v:197)
Warning: Resizing cell port sram.ramfn_inst1.POWEROFF from 32 bits to 1 bits.
Warning: Resizing cell port sram.ramfn_inst1.SLEEP from 32 bits to 1 bits.
Warning: Resizing cell port sram.ramfn_inst1.STANDBY from 32 bits to 1 bits.
nextpnr-ice40 --up5k --package sg48 --json hardware.json --asc hardware.asc --pcf up5k.pcf -q
Warning: unmatched constraint 'spi_clk' (on line 1)
Warning: unmatched constraint 'spi_miso' (on line 2)
Warning: unmatched constraint 'spi_out' (on line 3)
Warning: unmatched constraint 'spi_cs' (on line 4)
Warning: unmatched constraint 'data[0]' (on line 6)
Warning: unmatched constraint 'data[1]' (on line 7)
Warning: unmatched constraint 'data[2]' (on line 8)
Warning: unmatched constraint 'data[3]' (on line 9)
Warning: unmatched constraint 'data[4]' (on line 10)
Warning: unmatched constraint 'data[5]' (on line 11)
Warning: unmatched constraint 'data[6]' (on line 12)
Warning: unmatched constraint 'data[7]' (on line 13)
Warning: unmatched constraint 'phi2' (on line 33)
Warning: unmatched constraint 'rwbar' (on line 34)
Warning: unmatched constraint 'dataoutenable' (on line 36)
Warning: unmatched constraint 'busenable' (on line 37)
Warning: unmatched constraint 'diag_spi_cs' (on line 39)
Warning: unmatched constraint 'rdy' (on line 40)
Warning: unmatched constraint 'rst' (on line 41)
Warning: unmatched constraint 'led_blue' (on line 43)
ERROR: IO 'dataout[7]' is unconstrained in PCF (override this error with --pcf-allow-unconstrained)
ERROR: Loading PCF failed.
20 warnings, 2 errors
scons: *** [hardware.asc] Error 255
============================================= [ ERROR ] Took 9.53 seconds =============================================
make: *** [Makefile:130: bin/hardware_6502.bin] Fehler 2
pi@romulator:~/bf-romulator $

Do you have any available memory map files (or rather the stanzas) for the BBC Micro ( or B), or BBC Master to put in config/memory_set_default.csv?

Custom configurations that use their own non-default files such as: memory_set_apple1.csv, enable_table_apple1.csv
will fail to load when using the new 'c to change configuration' feature of bin/console

This is because the profile value of 'default' is hard-coded in line 39 of console.cpp:
const char* profile = "default";

If possible one solution might be to integrate console into the Makefile and pass profile definition as argument on the g++ line ($(CONFIG))

I tested using the incrementing byte pattern that vram is initialized too by file vram_test.txt, and then loading the canvas.html page on the standalone D1-mini programmer with the relevant "verbose = true" in function romulatorReadVramBlock() in module libRomulatorDebug.cpp to print out the returned data values.

To produce a parity error to test the FPGA I forced a send of 0x22 to the FPGA when a specific vram address was accessed and looked at the data returned by the FPGA.

The error in the FPGA verilog code is in the VERIFY_PARITY_BYTE section of the state machine in "diagnostics.v". Change line 219 from "if (rx_dv <= 1'b1)" to "if (rx_dv == 1'b1)"

VERIFY_PARITY_BYTE:
begin
  tx_dv <= 0;
  // if (rx_dv <= 1'b1)
  if (rx_dv == 1'b1)
  begin
    if (rx_byte == PARITY_ERROR)
    begin
      vram_address <= vram_address - 8;
    end
    state <= NEXT_VRAM_BYTE;
  end
end

Now that "if (rx_dv == 1'b1)" is functioning properly, the D1-mini code needs to be modified in file "libRomulatorDebug.cpp".

Between lines 356 and 357 add
// Advance FPGA so it can prepare the next vram byte for sending over SPI.
xfer(0x0);

A similar change should also be made on the Raspberry Pi code for that version of debugger.

In function handleCharacterRom() in file "rServer.cpp" buffer overflow can occur when reading the config file if a line is longer than 128 characters such as a comment line. This happened to me resulting in a segmentation fault and crash.

Fix is to limit reads to 128 bytes maximum. Add the start of the file add the following

#define MAX_LINE_CHARS 128

Line 158 change
char line[128];
to
char line[MAX_LINE_CHARS];

Between line 215 and 216 add
if (numchars > MAX_LINE_CHARS) numchars = MAX_LINE_CHARS

such that the code now looks like this
while (!found)
{
while (*end != '\n' && *end != 0 && end - tableBegin < enableTableLen) {
end++;
}

    int numchars = end-start;  
    if (numchars > MAX_LINE_CHARS) numchars = MAX_LINE_CHARS;
    strncpy(line, start, numchars);
    line[numchars] = 0;

Hello Michael,

I used your great Romulator 6502 in my Commodore 1541 floppy drive. I can now use many floppy speeders like DolphinDos etc. with it. However, there is a small improvement for your Romulator in a 1541 floppy drive. The IO ICs VIA are at address $1800 and $1C00 and are mirrored by the simple address decoding every 2K in the address space. This has the disadvantage that with the romulator from $2000 - $7FFF I cannot provide any additional memory through the romulator, as the VIAs then interfere with write accesses /WE. But I have found a solution. If you set the A15 on the mainboard address bus to high, then the VIAs no longer interfere and I can insert additional RAM from $2000-$BFFF. Then DOS and KERNAL appear. Maybe that would be a feature for the Romulator. I have an intermediate board running at the moment. But I think that something like this can also be built into the Romulator as a feature.

Logic:
Stop VIAs Mirroring on 1541 Floppydrive
------
CPU A15----+ |
CPU A14----+ OR + ----A15 Mainboard 1541 Floppydrive
CPU A13----+ |
-------

Greetings from Berlin
Frank

Not sure if this is the right place but I just got my romulator put together and tested as working. I was hoping to use this to dig into my Apple IIe (enhanced). I noticed there are through holes for a jumper with the board silk screen showing to connect for a 65c02 which I have done. However there seems to only be a rom entry for the Apple II+ in the default enable and memory mapping.

I was hoping to get some help figuring out how to add an Apple IIe Enhanced entry since I have the system with upgraded rom that's been tested and working 100%,.

My understanding is that the dip switches on the romulator are for selecting the rom / memory map to load. So I would imagine I need to dump the rom from the machine, then somehow figure out a mapping. After that I would need to get those added into the firmware for the fpga?

To be honest I'm new to all this and part of why I want to get this working is to just learn more about the 6502 era of computing. This started with ben eater's fantastic 6502 breadboard computer kit which I also intend to program into the romulator eventually.

Anyways, some advice, steps, or general information would be helpful as I'm still getting oriented.

I found that when modifying FPGA verilog code that even though the code builds correctly without errors using the provided tools and scripts it doesn't always run correctly. Sometimes even removing a few lines of non-called verilog code will result in the FPGA going from working to not functioning at all, or partially functioning. Such as random spi errors causing partially missing data and a distorted image on canvas.html web page.

After going around in circles for many days I found that the recompiled verilog images likely did not meet timing despite no warning.

The installation instructions and script provided forces apio version 0.5.4 and uses the FPGA tools and versions assigned to this apio version. In windows subsystem for linux later versions of apio and tools will build the romulator image but with timing errors. (Note, only Raspberry Pi 64bit OS is supported in the newer tools for those using that for synthesizing/placing/routing). I upgraded to apio version 0.8.1 in WSL debain and timing errors are reported with this latest version. For example :

"ERROR: Max frequency for clock 'romulator.clk': 34.93 MHz (FAIL at 48.00 MHz).

Changing the clk clock frequency from 48MHz to 24MHz resolved the timing error reported by the packages in apio 0.8.1 and converted non-working code built by apio tools installed on version 0.5.4 to working.

I made the following clock change to the verilog code in enable_logic.v :

Change line from :
SB_HFOSC #(.CLKHF_DIV ("0b01")) inthosc(.CLKHFPU(1'b1), .CLKHFEN(1'b1), .CLKHF(clk));
to
SB_HFOSC inthosc(.CLKHFPU(1'b1), .CLKHFEN(1'b1), .CLKHF(clk));

Any chance of building this on a RPi Zero? Looks like apio doesn't support linux_armv6l.