• Please review our updated Terms and Rules here

Wrote my own emulator, have a weird bug! Help!

mechaniputer

Experienced Member
Joined
May 23, 2015
Messages
59
Hi fellow vintage Apple enthusiasts,

I wrote a 6502 emulator from scratch so that it can appear in a coding game I am writing (well also for the challenge). To test it I am emulating the text mode I/O of the Apple 2 and using an Apple 2 ROM.

I am able to run the original Integer basic ROM. The one where you need to do "ctrl+b, enter" to start BASIC from the monitor prompt. For the most part it is working great. However there is a problem with the "LIST" command. It's weird since everything else seems to work. I've attached a screenshot of the error.

It would seem that one of my 6502 instructions probably has an bug in it. I was thinking I could narrow it down by looking at exactly which opcodes are used in the LIST routine. Is anyone familiar with how that part of the code works? I've looked at the disassembly. There is a symbol table containing the names of the various operators, backwards. I'm guessing it scans the tokenized program and looks up the string associated with the tokens from that table somehow. Based on my output, it looks like an offset is wrong or something. I'm not able to make sense of it so I'm hoping that one of you can fill me in on which opcodes to investigate. Thanks in advance for help tracking this down.

-mechaniputer
 

Attachments

  • Screenshot_2021-07-21_13-37-44.png
    Screenshot_2021-07-21_13-37-44.png
    16.4 KB · Views: 1
This is why it is difficult to write an emulator at the "macro" level rather than locate a CPU validation suite and test the emulator incrementally using the CPU validation suite.

I had this problem when I co-authored the SuperPET 6809 add-on for VICE. I was fortunate in that I found a 6809 CPU validation suite and used that with some available 6809 emulators. They all failed! So I picked the one that was the best of the bunch and fixed the errant instructions.

Look around for something for the 6502 CPU and see what you can find.

EDIT: Try the 6502 CPU instructions found under here: https://sourceforge.net/p/vice-emu/code/HEAD/tree/testprogs/general/Lorenz-2.15/. You will have to 'tweak' the test environment to suite your specific needs.

Dave
 
Last edited:
Thanks, I will try to look into using these tests this weekend. However, I'd still really appreciate it if anyone who might be familiar with the Integer BASIC code could explain to me how it works. I found the symbol table, I just can't figure out how it retrieves those characters based on the "verb" tokens. I have a hunch that I could find the problem in 20 minutes if I understood what it was doing there. I also have an academic curiosity about it at this point.
 
I don't know if these are the tests I used or not for mine. But I certainly did find something, and it did find a problem.

https://github.com/Klaus2m5/6502_65C02_functional_tests

I have also used these tests for emulators that I have written- they're pretty comprehensive, and they were able to find bugs in some of my instruction code. (example: The 65C02 BIT Immediate instruction does not set N and V like the other addressing modes do)
 
I am used to the Commodore PET BASIC source - but I have taken a look and would suggest looking at the flag settings for instructions such as:

CMP, CPX, CPY, SBC and BIT and look at the flag usage for the following branch instructions:

BCS, BCC, BPL, BMI, BNE and BEQ (remembering that a result of 0 is positive).

Are you using at least two (2) completely different sources for the 6502 instruction set documentation? When I have written emulators - one of the consistent things that I have found is very poor and inconsistent description of the instruction set itself (or is that deliberate I ask myself).

I would compare three sources for the 6502 instruction set - and pick the two that agree for the specific item you are looking at. However, just watch that one source of documentation is not a blatant "rip-off" of another source if you are relying on the internet. I would go with some internet scans of 'reliable' publications.

Dave
 
I have also used these tests for emulators that I have written- they're pretty comprehensive, and they were able to find bugs in some of my instruction code. (example: The 65C02 BIT Immediate instruction does not set N and V like the other addressing modes do)

Yea, the BIT instruction is a...ahem..."bit" notorious. Decimal handling is extra fun as well. And just the V flag in general. These are all places worth studying and verifying.
 
With the 6809 it was the DAA (Decimal Adjust Accumulator) instruction that was 'fun'...

But - yes - I can see on a 6502 that the 'D' flag would complicate the instruction somewhat and provide hours of fun also...

Dave
 
Fixed it! Thanks everyone. Turns out I was failing to set the carry flag in CPX/CPY Immediate mode. I still plan to look into those tools this weekend to catch any other bugs.
 
Fixed it! Thanks everyone. Turns out I was failing to set the carry flag in CPX/CPY Immediate mode. I still plan to look into those tools this weekend to catch any other bugs.

When I was doing mine, it turned out I was testing against a Web based simulator that was buggy as well (so that doesn't help). I was also using my home grown, buggy assembler (so that doesn't help either) and code that turned out to have known, but uncorrected bugs in the first place!

So, buggy CPU tested against another buggy CPU using buggy code assembled by a buggy assembler.

Amazing I got anything to work at all!

Good times
 
The first thing you should do before writing an emulator - or at least develop it in parallel with the emulator - is an instruction set validation suite that tests both the instruction set and the addressing modes out. I find that by developing the validator - you find an awful lot more out about the instruction set itself...

Dave
 
The first thing you should do before writing an emulator - or at least develop it in parallel with the emulator - is an instruction set validation suite that tests both the instruction set and the addressing modes out. I find that by developing the validator - you find an awful lot more out about the instruction set itself...

Dave

After reading this thread I was thinking about trying my hand at this. Any other advice for a first timer?
 
After reading this thread I was thinking about trying my hand at this. Any other advice for a first timer?

Start simple.

Mine is quite simple. It's essentially an interpreter. It's not cycle accurate. It's not clock accurate, I just let it free run. It's not simulating any real hardware. I have "memory" locations that read the keyboard and write to the "screen", I have memory locations that can read and write to the disk. I have mine wrapped in a simple GUI. I don't have any interrupts. BRK stops the simulation. Have a way to single step. Mind, this doesn't have to be a part of your console, your source code debugger will likely do just fine early on. The command loop is pretty simple. But it can be nice to have a registe, flags, and memory dump.

In the end, I was able to assemble the stock 6502 FIG Forth source code, using my own assembler, and load up the image and...it worked! (Mostly)

It's always good to have a "known" source to test again, so try and find another simulator that you can step through small snippets of your machine code and see that yours is doing what theirs is doing (which is why its nice not to compare against another, buggy, simulator like I did!). Real hardware is always nice.

So, anyway, start simple. You can always make it more accurate, realistic, faster, compact, etc. later.
 
The question is - have you identified a processor or computer you wish to emulate?

Most emulators are interpreters - so they can use binary code images (e.g. ROM images) directly from a machine without having to repackage them.

You then have to emulate not only the CPU itself - but the I/O devices etc. that this particular machine uses.

If you can be a bit more specific - then perhaps we can help a bit more?

It is great fun! I used to write software emulators for a job - very expansive video games (as my boss used to call them). But he wasn't complaining too much when the profits rolled in :)!

Dave
 
Very cool, thanks. I haven’t picked anything, just sounds like fun. Any recommendations on a particular computer that would be a good starting project? For background I have about 20 years of software dev experience mostly in embedded and low level C stuff.
 
I would have said something simple that has a serial port as a console terminal.

Most of these already have some form of emulator for them - but don't let that put you off writing your own of course. It does mean you can use the other emulator (e.g. SIMH) as a reference machine whilst developing yours. You can also take a 'sneak peek' at the source code for SIMH to point you in the right direction!

I would go for something like a 6502 or 6800 of some description to start with. 6800 = SWTPC. Other processors are available of course...

EDIT: For a simple 6502 see http://searle.x10host.com/6502/Simple6502.html. Basically RAM, ROM (including BASIC) and a serial interface.

EDIT: Try here for the 6800 SWTPS https://deramp.com/swtpc.html. This links to another site. You can start off simple with the SWTPC and then add a disk controller and operating system as your emulator skills improve.

EDIT: You could also try a little microcontroller. The Zilog Z8 could run a tiny BASIC interpreter via a serial port. The ROM image is available. See https://www.mikrocontroller.net/atta...C_Part_One.pdf https://www.mikrocontroller.net/atta...C_Part_Two.pdf. I haven't found the BASIC ROM image yet though. There is a FORTH ROM listing here http://www.forth.org/TM-10463.pdf for the Z8. EDIT: Found a patched version of the BASIC ROM at http://www.armory.com/~rstevew/Publi...C_ROM_Main.htm.

Alternatively, you could go for a DEC PDP-8. The advantage of this is the availability of the MAINDEC diagnostic software. This was written by DEC to locate faults within their own hardware - but is a real boon for emulator writers of course! They helped find faults in the work I am doing...

There are other machines as well - but start off simple and get complicated!

Go for something that is well documented and (preferably) has diagnostics readily available.

Dave
 
Last edited:
If you want to see it "do something" other than what you want to write, I'd go with a 8080 or Z80 with the goal of getting it to boot CP/M. It's well documented, there's a bazillion bits of software for it, there's source code, it uses a serial terminal and a floppy. And lots of simulators to compare against. You don't even need a real time clock.

So, even something as simple as what I did should work. You even get IN/OUT ports to make interfacing super simple vs memory.

In contrast to the 6502 machines with mostly their fancy graphics and what not. CP/M machines are pretty basic.

Reading the floppies images can be a trick. What little I've dabbled with it, I haven't been able to read them properly. There's a bunch of parameters like skew and such, the blocks aren't just stacked against each other. I haven't tried in some time, but there's source code out there (cpm tools for unix) that can read the floppies and could show you how it's done.

At the interpreter level, it's not like any of these are spectacularly more difficult than any other.

The really good simulators simulate cycle activity, especially those mimicking real hardware (like game consoles) They mimic not just the CPU, but everything else, at the signal level. Completely different design and architecture than a simple interpreter.
 
Back
Top