This project comprises a 65c816 Soft Core SoC with Serial SRAM Driver (23LC512) and XMODEM Bootloader to load your programs into RAM from a PC via a terminal program. The target here is a Xilinx Arty A7, using a soft 65c816 core, with block memory for the RAM and ROM, though the design has an additional 64k mapped from 0x10000-0x20000.

The 65c816 is the 8/16-bit big brother of the 65c02, used in the SNES and Apple II GS. https://www.westerndesigncenter.com/wdc ... 5c816s.pdf The 65c816 core is adapted from a SNES FPGA project.

The SoC has a small monitor in ROM ($C000-$FFFF), a soft ACIA at $8000, and (distributed) RAM from $0000-$7FFF. The LEDs indicate reset status, and BTN0 serves as the reset (active high). The constraints file shows which pins to connect from the 'c816 to the Arty. The monitor resides in the COE file.

This design also requires a 1.8432mhz external oscillator (clock) to be connected to the Arty so that the ACIA will work properly (currently at pin IO33).

Note: You must clock the device itself ABOVE 2mhz. I've tested it up to 7mhz.

You can load your programs into RAM as .prg files. Enter "X" at the monitor prompt, and you can load your program via the XMODEM protocol. I use ExtraPuTTY. Note: you can control where in RAM your programs load via your .prg files. I've been coding using Visual Studio and RetroAssembler. https://enginedesigns.net/retroassembler/

Run your program by using the address + "R" at the monitor prompt. For example, if you load your program at $1000, you would type 1000R and then enter. Make sure to jump or rts out to $C385 at the end of your program. This is the exit point that will return you to your monitor.

The project includes a QSPI (Quad SPI) driver written for the specs of the 23LC512 by Microchip. The SRAM is connected to PMOD JA.

"L" clears the Zero Page and resets the stack from the monitor. I am currently working on a design that allows the user to replace the ROM monitor at will.

The other monitor function work as a typical WozMon would: (e.g.), https://www.sbprojects.net/projects/apple1/wozmon.php

Feel free to contact me through the 6502 forum: memberlist.php?mode=viewprofile&u=3597

I don't know of any '816 test suite, but perhaps there's something in the land of SNES which gives an '816 a good workout?

Dear Dave and Ed:
Of course, the whole issue of being able to upload a new ROM image at will, without having to do an entirely new bitstream, is driving me batty. I've tried things like using a switch to change all the "enables," to re-jigger the address map, but it just corrupts everything.

I'm not completely sure I understand the issue here, but are you aware of the Xilinx DATA2MEM tool, which allows the initial contents of the block RAMs in a bitstream to be updated?

Ed,

Yes, I would like help with that! I was a bit stumped, because the SNES implementation does not contain any sort of attribution as to the source (of the processor core). Moreover, I've never done that sort of thing before.

Hi Jon, if your upstream was the SNES_Mister project then it's very easy: just copy their LICENSE file into your repository, and that's enough. Ideally, but optionally, you add the boilerplate from that file to the top of each of your source files, and that includes a one-line copyright notice which lists the contributors. In this case you might need to attribute them as "various contributors" as you don't know who they are - but as you make meaningful changes and additions you can add your name, or handle, to the copyright notice. As I say, that bit is optional, it just helps people who might want to reuse the work. (Edit: and it makes you famous!)

Yes, I think that's enough - thanks!

No, I'm not familiar. Can you use it to swap the .COE memory file? Remember, I'm using Vivado here.

Ah yes, sorry, data2mem is ISE specific.

But there is, I think, an Vivado equivalent called UpdateMem.

There is some documentation here.

If you need to do lots of iteration on the ROM (for example you were developing a machine code monitor, it's worth trying to get this tool working. It reduces the iteration time from minutes to a couple of seconds.

Dave

No, what I need to figure out is how to find (or define) somewhere in the memory map where I can upload, via Xmodem, a 16K ROM image, and then somehow create an engine that copies that block over the existing 16K "ROM" block - sort of like writing an EEPROM. Thereby, the ROM is replaced with the new image.