New Project: 65c816 Soft SoC with Serial SRAM 23LC512

[Jmstein7]

Hi, all - long time. I just uploaded the above-captioned project to GitHub (https://github.com/jmstein7/soft_65c816 ... oC_23LC512), and I thought some of you might be interested in toying with it.

Here is the description:

Quote:

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'm particularly proud of the Serial SRAM (QSPI) driver - it took a bit to get that right.

Enjoy!

Jonathan

PS I really want to design a method of replacing the ROM via XMODEM, without having to re-synthesize and implement the whole darn thing each time I update the Monitor ROM.

[hoglet]

Well done getting this working.

For anyone interested in looking at the top level design for this project, here's a direct link:
https://github.com/jmstein7/soft_65c816 ... p_level.sv

Dave

[BigEd]

Very good to see this - well done!

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?

Any idea what license the original core uses? It should be easy for you to inherit that license, and might be possible to switch to another license of your choosing. I'm happy to discuss how to do that. With a bit of license boilerplate in your sources it will be possible to inherit the core into other projects - hopefully that's something you'd welcome!

[hoglet]

BigEd wrote:

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?

Drass has been working on a 65816 test suite.

It's at an early stage, but I was able to run this on the 65816 Core in PiTubeDirect and it found a bug. It also ran successfully on the real 65816 in Beeb816.

I think the latest version is attached to this post.

Dave

[BigEd]

Great! If only I could remember things!

[Jmstein7]

Dear Dave and Ed:

Dave,

I'm going to try and "slim it down" by using block RAM instead of distributed RAM, except for the ROM portion, which is small enough not to waste too many LUTs. Currently, I think the memory portion is too big and inefficient.

Also, you may have noticed that, on the serial SRAM, when you do a "read," it passes the address to the Serial RAM on the first clock and reads back dummy bytes ("EA") until the 23LC512 starts getting valid data. I've only done "byte mode" so far, for the 23LC512, and, on my todo list, is doing page and sequential modes. But, hey, it works - it could just be more efficient.

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.

Jon

----------------------------------------------------------------

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.

Jon

[hoglet]

Jmstein7 wrote:

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?

[Jmstein7]

hoglet wrote:

Jmstein7 wrote:

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?

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

Jon

[BigEd]

Jmstein7 wrote:

Quote:

...licensing...

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!)

[Jmstein7]

BigEd wrote:

Jmstein7 wrote:

Quote:

...licensing...

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!)

Cool! I dropped the license file into the top of the repository. I will add the language to the files going forward.

Is that all I need to do?

Jon

[BigEd]

Yes, I think that's enough - thanks!

[Jmstein7]

BigEd wrote:

Yes, I think that's enough - thanks!

Thank YOU!

PS I cleaned up the repository: https://github.com/jmstein7/soft_65c816 ... oC_23LC512.

Dave,

I replaced the distributed RAM with block ram. It's now a fraction of the size

[hoglet]

Jmstein7 wrote:

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

[Jmstein7]

hoglet wrote:

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

Dave,

Thanks. I took a look, but that's not quite it. I also messed around with the "Dynamic Function Exchange" (reconfigurable modules), but a) you can't do it on IP like block RAM and b) it requires floorplanning that is way above my pay grade

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.

Jon

[hoglet]

Jmstein7 wrote:

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.

What about implementing a single bit register mapped into I/O space (0x8000-0xBFFF), which swaps the ROM at 0xC000-FFFF with the RAM at 0x4000-7FFF? Then you would just need to upload the new ROM image to 0x4000, toggle the register bit, and reset the system. That seems much more straightforward than actually copying the data.

Another even simpler idea would be to just make the "ROM" writeable! Then you could so the copy in software.

Dave