Prog Code at mem locations 0000-0001 destroyed


The first two bytes of the program code at memory locations 0000 to 0001 are destroyed after running the program (starting at memory location 0000).

sample program:

0000 86 01 LDAA #01
0002 B7 C1 10 STAA $C110
0005 3E WAI

after running the program:

0002 B7 C1 10 STAA $C110
0005 3E WAI

file attachments


RickNungester wrote Jun 30, 2016 at 8:06 PM

astrocodeplex: Good bug report. You made the problem easy to replicate.

RupertAvery: I replicated the problem and have more information. Running the program on a real ET-3400 results in the rightmost 7-segment display ("$C110") having its center segment on ("#01") and all other display segments off. On the emulator, do the following:

RESET AUTO 0000 86 01 B7 C1 10 3E RESET
View, Debugger, left pane to "Display ($C110)", see images 1a,1b.
DO 0000
See images 2a,2b for about a second, then 3a,3b.

Notice images 2a,2b (correct 7-segment display with addresses 0000 and 0001 equal to 01). Setting the Debugger left pane to "Display ($C110)" seems to help this intermediate state last longer.

The problem seems to be with the processing of the WAI instruction.

RupertAvery wrote Jul 5, 2016 at 1:10 PM

WAI is an instruction that I never got around to implementing properly. Right now it simply pushes some registers on the stack and continues interpreting opcodes. My guess at what happens then is that the program counter probably hits the stack and executes some code that writes over 0000 and 0001.

The reason I haven't implemented it is due to the difference in architecture of the source code I based it off of (the MAME (Multiple Arcade Machine Emulator) m6800 core engine) which is written in C versus C#. There are a some parts shared with other emulators that are not part of the core engine and the WAI and other interrupt-related functions happen to be included in these parts.

I'm trying to port these features over, but I may need to rewrite them.

RupertAvery wrote Jul 5, 2016 at 11:29 PM

I have a fix in place, and it seems to do the job. It's not entirely accurate as compared to the MAME implementation, but it works for the simulator. The only thing is that I don't have a way to raise an IRQ or NMI in the GUI yet, in order to trigger the interrupt sequence.

I need your help in confirming the operation of the WAI instruction, and interrupts in general.
  • Does the WAI immediately push the microprocessor state (PC,X, A, B, CC) on the stack AND set the PC to the UIRQ vector stored at FFF8, or is an IRQ needed for this to happen?
  • If the interrupt flag is set for example using SEI, and WAI is called, when IRQ is pulled low, is the IRQ ignored? The manual states that in this case, a NMI is required to exit the wait state.

RupertAvery wrote Jul 6, 2016 at 12:14 AM

This has been fixed in Release 1.0.5

RickNungester wrote Jul 7, 2016 at 1:12 AM

"Does the WAI immediately push the microprocessor state (PC,X, A, B, CC) on the stack AND set the PC to the UIRQ vector stored at FFF8, or is an IRQ needed for this to happen?"

Motorola Semiconductors MC6800 data sheet (1984, 32 PDF pages), Figure 11 "WAIT INSTRUCTION TIMING" shows the PC being loaded with the UIRQ vector after the assertion of IRQ' or NMI', not as part of the WAI instruction.

(I don't know about your second question.)

I tried release 1.0.5 and verified that the issue being discussed here seems to be fixed. I also did some regression testing using several of my previously-working ET-3400 programs and found no problems.

To RupertAvery: Thank you for all your work on this!