floooh / v6502r

visual6502 remixed

v6502r

Visual6502 and VisualZ80 Remixed

WASM Version for 6502: https://floooh.github.io/visual6502remix/

...and for the Z80: https://floooh.github.io/visualz80remix/

TL;DR: Take the visual6502 project and turn it into a native+wasm app via perfect6502, Dear ImGui and Sokol.

Feature Gallery

6502 simulation:

Z80 simulation:

2A03 simulation:

Log CPU state and revert to a previous cycle:

Integrated assembler:

I/O pin timing diagram:

Visualize difference between two cycles:

Explore netlist nodes by their name, group or number:

...and a kickass About box ;)

How To Build:

Make sure python and cmake is in the path.

To get an idea about additional required tools, first run

> ./fips diag tools

To build and run the native version, run:

> ./fips build
...
> ./fips run v6502r
> ./fips run vz80r
> ./fips run v2a03r

Linux may require additional development packages for X11 and OpenGL development.

To build the WASM version:

> ./fips setup emscripten
> ./fips set config wasm-ninja-release
> ./fips build
> ./fips run v6502r
> ./fips run vz80r
> ./fips run v2a03r

Software used in this project:

Many thanks to:

• visual6502: https://github.com/trebonian/visual6502
• perfect6502: https://github.com/mist64/perfect6502
• Dear ImGui: https://github.com/ocornut/imgui/
• ImGuiColorTextEdit: https://github.com/BalazsJako/ImGuiColorTextEdit
• ImGuiMarkdown: https://github.com/juliettef/imgui_markdown
• asmx: http://xi6.com/projects/asmx/
• The Sokol Headers: https://github.com/floooh/sokol
• The Chips Headers (UI): https://github.com/floooh/chips
• Tripy: https://github.com/linuxlewis/tripy
• IconFontCppHeaders: https://github.com/juliettef/IconFontCppHeaders
• Font Awesome 4: https://github.com/FortAwesome/Font-Awesome/tree/fa-4
• visual2a03: http://www.qmtpro.com/~nes/chipimages/visual2a03/

Please be aware of the various licenses in the respective github repositories, subdirectories and files.

v6502r's Issues

VS Code extension

It would be more useful if the CPU emulator could be used from VS Code as a generic executor of 6502 assembly because it's not easy to write assembly and move it into the emulator and the UI is not as good as VS Code's could be. When I run C code from VS Code, I can see register values in the debug view. If I could also see a diagram of the CPU executing the code along side that, that would be cool.

Antialiasing on high pixel density displays

I have a retina (i.e. high pixel density) monitor and it seems like v6502r isn't using all the pixels. Compare the anti aliasing on the purple wire with the antialiasing of text in my terminal window:

even straight lines are visibly blurry because of the anti aliasing when they could be pixel perfect. Here's a better comparison of an SVG file open in Chrome vs v6502r running locally:

I only changed the Contrast theme to be pure white and compiled it with ./fips build && ./fips run v6502r. The v6502r window is a bit darker on top because macOS adds a drop shadow under windows.

Looking at https://floooh.github.io/sokol-html5/shadows-sapp.html it seems like this might be a problem with sokol itself.

Zoom in/out on cursor instead of middle of screen

also, the scroll zoom physics could be better. When you zoom out it zooms very fast and when you're zoomed in it zooms too slowly.

Edit registers

It would be nice to be able to modify the registers (and potentially other nodes). Looking at the code it seems like it should be possible (using writeNodes in perfect6502.c, etc.) but somewhat tedious to plumb through.

WASM version: Assembly window not resizeable or movable anymore.

Something is weird with the Assembler window on the WASM version.

Resizing doesn't work, and sometimes windows movement doesn't work either.

Some regression related to a Dear ImGui update?

...seems to have to do with the window already being active or not when attempting to grab the title bar.

PS: consider switching to this maintained fork of ImGuiColorTextEdit: https://github.com/santaclose/ImGuiColorTextEdit (not an option, depends on boost/regexp)

Add processor overlay display

A "?" icon in one of the corners, that when you mouse over it, it makes the processor a bit dimmer and overlays boxes around the different logical parts of it, like in the diagram on this page

https://sites.google.com/site/h2obsession/CBM/Hardware/6500-cpus

or more detailed like the diagram on this page

https://davidmjc.github.io/6502/bcd.svg

Like this:

Freeze when WAIT line is asserted and Step to next instruction is clicked

When the WAIT line is asserted and the "Step to next instruction" button is clicked, the whole application freezes.

Inconsistent state after step back to the beginning

When stepping back to the beginning in visualz80r, there seems to be some inconsistency.

I hadn't seen the Reset button before so I stepped back to the beginning via the step back buttons instead. This has led to some kind of inconsistent state where all registers display as 0000 and all checkmarks get ticked. Then, after stepping 2 half-cycles, suddenly all values change at once.

Steps to reproduce:
Reset
Step half-cycle
Step back half-cycle

Add 3rd dimension

It would be cool if the processor could be rotated to reveal the stack of layers.

The source code for visual ARM1 mentions that it used to do this https://github.com/verhovsky/visual-arm1-highres/blob/ff33b4d1fc79837d2ae6bd5cfeea2d056796fb0f/sim/varm/geom.js#L21

Watch multiple nodes in the trace log

It seems like the values of all nodes are tracked in the trace log, but you can only watch one node at a time. It would be nice to be able to display more than just one value here (maybe there's already a way?)

Reminder: Z80 tracelog disassembly is confused by DD+CB/FD+CB ops

In DD+CB or FD+CB instructions (e.g. SET 1,(IX+1)) the disassembly in the tracelog and timing winow doesn't detect the end of the instruction and "leaks" into the next instrucion.

Probably related to the "fake" opcode fetch machine cycle in those instructions (the opcode after the DD+DB prefixes is loaded with a regular memory read machine cycle).

Z80 Errata

Current theory: the netlist is probably from a Zilog Z8400, not an original Z80.

Triggering an IM1 interrupt during a JR instruction jumps to 0x30, not 0x38:

	ei
	im 1
l0:	jr l0	; triggering INT in this loop...

	org 30h
l1:	jr l1	; ...jumps here

	org 38h
l2:	jr l2	; ...but should jump here

WZH should be set to 0x33 (value of A), but is set to zero at end of LD (nn),A:

	ld a,33h
	ld (1111h),a

Same here: WZH should be 0x33, but is zero.

	ld a,33h
	ld bc,1111h
	ld (bc),a

Note that the differing WZH behaviour could be an indication that the netlist is actually from a Russian (or East German?) Z80 clone, see memptr_eng.txt.

The undocumented XF and YF flags are cleared in BIT instructions: According to z80-documented.pdf the X/Y flags should both be set after the following BIT instruction (because bit 3 and 5 in A are also set):

	ld a,0xFF
	bit 1,A
	nop

After the BIT instruction, only HF and CF are set, XF and YF are unset (these could also be differences between a Z80 clone and an original Z80?).

Pinch to zoom on touch screen devices

and tap+drag don't work.

Highlight PC and SP memory addresses

The PC register could be highlighted yellow and then the memory address it contains should be highlighted yellow as well, so that you can tell visually why the memory address is being highlighted and which register it is. The stack pointer register should get the same treatment with a different color:

Make max zoom out level the same size as the real life processor

If my monitor is 227 pixels per inch (8.93 pixels per mm) and the processor was 3.9 mm × 4.3 mm then if I zoom out all the way, the processor should take up 35 pixels by 38 pixels. This would have to take into account .high_dpi = true.

Reminder: missing Z80 state

See here:

https://stardot.org.uk/forums/viewtopic.php?p=350126&sid=b716fab8439114bb3df73a53597215a2#p350126

According to this:

• IFF1: 181
• IFF2: 206
• NMI detected: maybe 135
• IM: 179 and 205

Also: I quickly checked IFF1 and in DI this flips at the second half cycle of the next instruction, while my own guess (231) flips in the middle of the DI instruction (which I think is the better guess, because interrupts are already disabled at the end of DI). Needs more investigation!

Regarding the IM nodes:

• IM 0 (ED 46): 179=>0, 205=>0
• IM 1 (ED 56): 179=>1, 205=>0
• IM 2 (ED 5E): 179=>1, 205=>1

...probably related to the weird 'IM decode table':

im_map = [ '0', '0', '1', '2', '0', '0', '1', '2' ]

PS: complete 179/205 state for all IM instructions:

        179     205 
ED 46:  0       0    (IM 0)
ED 4E:  0       1    (IM 0)
ED 56:  1       0    (IM 1)
ED 5E:  1       1    (IM 2)
ED 66:  0       0    (IM 0)
ED 6E:  0       1    (IM 0)
ED 76:  1       0    (IM 1)
ED 7E:  1       1    (IM 2)

Adding signals to timing diagrams?

I've just started using the visual6502remix and its very useful indeed. Was wonder if phase 2 out can be added to the timing diagrams so I can see exactly what's going on during each instruction?

Add scale bar

It could be as simple as a 1mm line under the processor, like this (it should be themed, white on dark backgrounds, dark on white themes):

or it could adjust with the zoom like on google maps, putting it in the top bar would be best but that's probably complicated

Light theme

Can you add a theme with a white background please?

Here's some suggestions for the colors (red green blue) from https://ai.eecs.umich.edu/people/conway/VLSI/VLSIText/PP-V2/V2.pdf page 215

rgb(102, 156, 124)
rgb(105, 188, 232)
rgb(207, 87, 129)

I used this svg file to color match https://4004.com/4004-50th-1st-cut-svg.html

JSON-based fuzz tests

Hi! I maintain some JSON-based fuzz tests for various processors ( https://github.com/raddad772/jsmoo/tree/main/misc/tests/GeneratedTests ) including the Z80, based on TomHarte's tests ( https://github.com/TomHarte/ProcessorTests ) which include 6502.

My test generation is all done in JavaScript, and although it's pretty good, it's not perfect. I had the idea that maybe it would make sense to combine our powers and create the closest thing possible to hardware-based fuzz tests, using the Visual simulators!

Is it possible to use the Z80 and 6502 source kind of like processor cores? In order to generate tests like this, I'd need..

1. The ability to cycle the core 1 cycle at a time (or 2 half-cycles)
2. The ability to read and write all registers and relevant internal state
3. The ability to intercept and replace any memory and I/O reads and writes

In essence, a test is created by choosing an opcode and writing it to a random part of memory (which is treated as flat 64K of RAM). The processor core is setup with random starting conditions except pointing to the next opcode. As memory or IO reads come in, they are serviced with random data, which is recorded, and any writes or relevant pin activity is also recorded each cycle. So you get an initial state for the processor and RAM, the expected bus activity for the length of the instruction, and a final state for the processor and RAM.

These tests are a huge help to emulator authors, both before you have enough of a system going to run a ROM-based test, and also for the final word if you're trying to verify your CPU core's accuracy.

Would you like to collaborate?

Add ARM1

http://visual6502.org/sim/varm/armgl.html

Is it a copyright issue?