0

I've been working on an emulator for the MOS 6502, and I nearly have it fully completed at this point. It has one small problem though. It seems to pass all of the tests that I put it through, but for some reason it causes Enhanced Basic to output everything, including characters, in scientific notation.

Enhanced Basic is only supposed to put numbers into scientific notation if they are > 999999.4375.

Where should I start to look? What emulation issues could cause a response like this from EhBasic? I have no idea where to even start with such a large program, and considering my emulator passes all of the tests I have fed it, I can't exactly find problems with the tests.

Here is a sample output from enhanced basic.

6502 EhBASIC [C]old/[W]arm ?



Memory size ? $C000



4.8383E+04 Bytes free


Enhanced BASIC 2.22


Ready

The 4.8383 should actually be 48383.

I took the liberty to re-write the code and comment out anything that was not required to see this issue. It should be much more readable to anyone now.

To reproduce this, run EhBASIC Cold by pressing C, and for the memory size, enter $C000.

EDIT: To clarify

The Accumulator is memory[memory_size]

Some variables have [0] after them because I took advantage of javaScript Uint8 arrays to have unsigned 8 bit integers, and unsigned 16 bit integers.

NAME__
  • 625
  • 1
  • 7
  • 17
  • First, check the obvious, that the binary image running on the emulator is correct. Then - maybe one of your emulated instructions does not set the carry or zero flags properly. Perhaps the BIT instruction is being used and not emulated properly (it's weird). Perhaps a flag bit is being cleared by an instruction when it should be left alone. You should find the routine in EhBASIC that displays the number, disassemble it, and start looking there for clues. – LawrenceC Apr 29 '15 at 18:45

1 Answers1

3

This is indeed the bane of all emulator developers. All the tests helpful in locating errors pass, but the large programs fail.

I am assuming that the source code to the Basic is unavailable, otherwise perusing that can at least find the code which performs the check on the value.

I have found that getting an instruction execution trace can help. If you can isolate the region of memory used to display the values you can limit the trace to just that part of memory.

A trace should output the PC, disassemble the instruction to be executed and, show all register contents. It should also indicate in the trace when output occurs - this helps identify what the different blocks of code do.

Traces can be very large and take time to generate, then even more time to analyse. One way of isolating the problem is to run you emulator with trace and a known good emulator outputting an identical trace. When the traces differ you have a good pointer to the source of the problem.

HBP
  • 15,685
  • 6
  • 28
  • 34
  • When I was working on creating a 6502 clone on an FPGA, I've found it tremendously helpful to run the same code in an established 6502 emulator (VICE in my case) packed full of custom instrumentation, and then compare the trace output to the trace from running an HDL simulator on my design. If you do this right, you can see stuff like 'ah, the internal state for the first 74214 operations are all the same, but there we deviate from VICE' which enabled you to zero in on the problematic part quickly. – Cactus Apr 06 '15 at 02:09
  • The code of Enhanced 6502 BASIC by Lee Davison is available form 6502.org, but I see no direct link from the main page and [the forum says](http://forum.6502.org/viewtopic.php?f=5&t=3024) the author passed away and someone asked about the licensing status. So this is unclear. – mvw Jul 27 '15 at 20:08