RCA CDP1802 Simulator

In the process of rediscovering the vintage RCA COSMAC CDP1802 microprocessor (RCA 1802 Micro), I decided to create my own simulator (some prefer "emulator", but to me that's something you plug into a circuit in place of a physical CPU). What better way to fully understand the machine code operation of a micro than to write simulation code for every instruction!

I found a few good simulators ("emulators") already out there, but there was always some part I couldn't get to work, or at least the way I thought it should. I just wanted something fairly simple and straightforward that would run the code from the trainer kit that Dave Lang created back in 1984-85 (RCA 1802 Micro). For example; entering programs into it by either loading from a file or by entering the machine codes (hex) directly into memory. 

So I created one. It is written in VB.Net. After taking on board some of Microsoft's recommended .Net app tuning tips, it now performs very well.

Features

• View and Edit contents of all processor registers.

• Load/Save any memory block from/to a file in Intel Hex format (.hex), "memory dump" format (.rom), or raw binary (.bin) (i.e most EPROM burners e.g TL866).
    - Note the .rom file format is a text file formatted as   :<address> <byte1> <byte2> ... <byte16><CR+LF> etc..  for example  :0000 71 00 f8 00 b3 f8 09 a3 d3 c0 02 92 f8 01 b6 f8

• View and Edit entire memory contents (64k) in hex.

• Configurable ROM areas are coloured pale red in the memory display. Cannot be written to by the running sim, but are editable by the user.

• Trace log shows run instruction history (disabled by checkbox, for greatly increased performance).

• Multiple Breakpoints can be set by either Address or Register Value.

• Single Step through running code.

• Serial Terminal. Configurable for 2400/9600 bps, 7/8 bits, Start Bit, Invert/not Q.  Supports Membership Card monitor and "Cenker" RCA Basic3 (see below).
  Transmits on Q and receives on EF3 or EF4. It is asynchronous, so it operates like a UART. The serial inbound character queue is visible to the user.

• Windows 7, Windows 10 (tested on both).  Requires .NET framework.

• High-DPI support (Renders nicely, tested on QHD/WQHD 13" laptop. No fuzziness or overlaid fields)

• I/O Bus current state and history trace shows INP and OUT interactions.

• Significant performance enhancements in Run mode (full speed). Now runs several times faster than previous version.

• Various fixes and improvements to register editing, IDLe mode, interrupt support, execution tracing etc..

• Improved execution tracing vs. performance.

Current v1.4.0.0 May 2021: Fixed some bugs! Added new Serial Terminal parameters. Now runs "Cenker" RCA Basic3 v1.1 and Chuck Yakym's Membership Card Monitor. Details below.

v1.3.3.0 August 2020: Added raw binary (.bin) to the options for memory load/save from/to a file. Prompts for load address. Thanks to Bob.

v1.3.1.0 June 2020: Fixed bug when loading (and saving) some Intel Hex files; Thanks to Kosmas.

v1.2.1.2 October 2019: Fixed some register issues; Thanks to Andy and Jeff.

Video about 1802 testing by Hey Birt! Includes a look at this 1802 simulator. Much thanks to Jeff - watch the video at https://www.youtube.com/watch?v=XPwuwjtjXnk&t=2s 

The simulator is shown above, running Dave Lang's monitor (RCA 1802 Micro).  The serial terminal is running and the monitor command '?0100' has been sent from the terminal. This command means view memory starting at 0100. You can see the monitor has a command buffer processing area at 0F50 which contains the command and the data prepared for sending back to the terminal.

Even though I re-wrote this simulator in WPF (Windows Presentation Foundation), I have decided to only support the WinForms version until I have a better idea. Reasoning is in the discussion further below.

Configuring Serial Terminal

If you want to run RCA Basic3 v1.1 (originally written by Ron Cenker) and/or Chuck Yakym's MCSMP Membership Card Super Monitor Program, then follow the steps below.

You can get Chuck's monitor and RCA Basic3 by Ron Cenker at http://www.sunrise-ev.com/1802.htm Scroll down to the software section and look for MCSMP20.bin and/or MCBASIC3.bin

1. Start 1802sim, File -> Load Memory, choose Binary (*.bin), select the binary file to load.

2. Enter the load address (e.g RCA Basic3 by itself; MCBASIC3.bin at 0000, or Chuck's monitor MCSMP20.bin at 8000)

3. If you're loading Chuck's monitor, then edit memory locations 0000 and 0001 with contents C0, 80 respectively (i.e LBR 8000 jump to the monitor on boot)

4. Uncheck Execution Trace to get best performance.

5. Options -> Serial Terminal

6. Set the terminal options to Echo unchecked, 9600, 8 bits, Start Bit checked, InvertQ unchecked, Receive Line EF3 (all shown below)

7. Select radio button Run

8. Click onto the terminal window to focus it, and press Enter, you should see the prompt for the program you're running.

To run Dave's Monitor (1802mon.hex) configure the terminal to Echo On, 2400bps, 7bits, StartBit off, InvertQ On, and receive line EF4.

Terminal Rate and Clock Speed: 1802sim is set to simulate 2MHz clock speed when terminal rate is 2400bps, and 1.79MHz for 9600bps.

This is to enable compatibility with both Dave's monitor and RCA Basic3 / Chuck's monitor.

If you're interested in knowing more or getting a copy of the simulator, you can contact me. My real name is Greg Newton and I'm in Sydney, Australia. You can email me at: greg dot newton dot oz at gmail dot com (written like that to avoid spam bots).

Performance
Windows Forms (WinForms) vs. WPF (Windows Presentation Foundation) and...
Windows 7 vs. Windows 10

Microsoft have set us back more than 10 years in terms of performance with Windows 10 and WPF. If you don't believe me, read on...

I wanted my 1802 simulator application to work nicely on my high-DPI Toshiba Kira Laptop. After much digging around I decided the best way was to completely rewrite it in WPF. I did this in late 2016 through early 2017.

Luckily I've kept the WinForms version up to date with the changes - why? All I can conclude is that WPF performance is a dog! It must be just me?

Every performance enhancement I've read about and made, I've also implemented the equivalent code change into the WinForms version. As I progressively made these changes, both versions got faster and faster - BUT the WinForms version still absolutely blows the WPF version into the weeds!

Then there's the bloatware that is WPF. The WPF Visual Studio project is just under 1Gb! The WinForms project is just under 3Mb - Whaaat?!

Furthermore there is another performance issue.. I have 3 laptops...All have 8Gb RAM :-

1. Toshiba Kira, Intel Core i7-5500U. A 5th gen "Broadwell" processor with Intel HD Graphics 5500. DDR3 RAM. Windows 10 (v1607)

2. HP EliteBook 820 G3, Intel Core i5-6200U. A 6th gen "Skylake" processor with Intel HD Graphics 520. DDR4 RAM. Windows 7.

3. HP ProBook 430 G4, Intel Core i7-7500U. A 7th gen "Kaby Lake" processor with Intel HD Graphics 620. DDR4-2133MHz RAM. Windows 10.

The test sequence is... load Dave Lang's monitor into 1802 sim. Open the Serial Terminal. Uncheck Execution Tracing to disable it (runs much faster).

In the terminal, enter the monitor command ?0100 0005 (dump 5 lines of memory starting at 0100). Start timing when you press <Enter>. Stop timing when the prompt returns.

The WPF version, when running the above sequence in the 1802 sim at full speed takes...

~9 seconds on the HP EliteBook (6th gen processor Win7).

~26 seconds in the Toshiba Kira (5th gen Win10).

~20 seconds on the HP ProBook (7th gen Win10).

The WinForms version, when running the above sequence in the 1802 sim at full speed takes...

<1 second on the HP EliteBook.

~4 seconds in the Toshiba Kira.

~2 seconds on the HP ProBook.

The little Core i5-6200U (6th gen) is the star performer by far! How does this make any sense? Because it is running Windows 7. The others both run Windows 10.

So to further test the theory, I fired up an old desktop PC that has a Core 2 Duo E6400 Processor (Q2 2006) 4Gb DDR2 RAM. Windows 7.

WinForms version ran this sequence in <1 second! Blowing away both Windows 10 machines even the one with 7th gen processor (Q4 2016) and DDR4-2133 RAM.

Yes, I've read the 'Net articles about improving performance in Win 10 and I've made the relevant adjustments in Control Panel etc... all to no avail - Windows 10 is still slower than Windows 7.

This code sequence previously ran a lot slower on all machines, and in an effort to narrow the gap, I made the application faster and faster - but the gap between the machines (actually the Windows versions) has remained. And so has the gap between WPF and WinForms! 

I've read articles and documentation until my eyes bleed and tried everything - and yes, it got faster and faster, but the WinForms version did too... and remains way ahead of the WPF version!!

So I can only conclude 2 things:-

    1. WinForms significantly outperforms WPF (<1-4 secs vs. ~9-26 secs depending on hardware, OS etc..)

    2. Windows 7 outperforms Windows 10, regardless of hardware. 

Microsoft software has clearly deteriorated on both counts. WPF is a dog. Who exactly is writing this crappy bloatware?

I'm not making this up - you could run the same code written for WPF on Windows 10, i7-7500U 7th Gen processor (Q4 2016) and it takes ~20 seconds, OR you could run the WinForms app on Windows 7 on a crappy old Core 2 Duo E6400 (Q2 2006) in less than 1 second!

Therefore Microsoft have set us back more than 10 years in terms of performance with Windows 10 and WPF.

Worst Performance = WPF on Windows 10.

Better Performance = WPF on Windows 7.

Better Performance = WinForms on Windows 10.

Ultimate Performance  = WinForms on Windows 7.

The differences are significant. The WinForms version on Windows 7 runs this code sequence "in a flash".

Update: Improving Windows Performance

I posted a message on a Microsoft community forum, and got back a reply saying to try turning off some of the Windows Services such as Superfetch. I tried this and discovered there are some services which slow the 1802sim down significantly. This is weird given that the CPU is showing almost no activity (98%+ idle time) in Task Manager - which in itself warrants further investigation. What made the difference for me was "Tablet PC" Service in Win 7 and "Touch Keyboard and Handwriting Panel Service" in Windows 10. You can also wring more speed out by turning off Windows Search service, but that slows down things like searches for apps and Control Panel items etc.. I've now gotten the Windows 10 Toshiba Kira into sub-second territory like the older Win 7 machines. I also set it up to dual-boot into Win 7. Win7 is still slightly faster than Win 10. WPF is still terribly slow compared to WinForms.

Even though you can get Win 10 to perform almost as good as Win 7, I would be skeptical of any claims of Win 10 having better running performance than Win 7 (Micro$oft may have shortened the boot times, but that's about all).

If you're interested in knowing more or getting a copy of the simulator, you can contact me. I'm Greg Newton from Sydney, Australia.
You can email me at: greg dot newton dot oz at gmail dot com (written longhand to avoid spam bot harvesting).