6801 simulator?

[metertech58761]

Looking for something that can help me single-step through some 6801-specific code... I found sim68xx but I haven't tried it yet... is it any good?

What I'm looking to accomplish is understanding one section of code in the attached dump - specifically, the 'code integrity check' (labels codeck ... chk_09).

It seems to be using the processor stack as a second index register while checking out the on-chip system to make sure everything is okey-dokey.
This is confusing me as the pointer gets reset multiple times (and even gets lowered into space allocated to variables at one point).

If all the checks pass, it calls one routine to cause the status LED to blink three times then continues with the main app code.
If it errors out at any point, it flashes the LED rapidly and re-runs this code check (the effect being that the status LED will then flash continuously to indicate the unit has failed).

[edavid]

You can use the "6800IDE" emulator in 6811 mode to do this.

http://www.hvrsoftware.com/6800emu.htm

[metertech58761]

Parts of the code gives me the strong impression that it does paranoia-level checks to ensure it is in fact running on a 6801 in single-chip mode before it will execute... so I'm not sure 68(HC)11 mode will work.

Edit: I got it figured out... tests RAM by filling it with $80 to $FF, then with inverted values ($7F to $00), cleans out the space normally allocated to variables ($80 to $D3), then does a checksum of ROM.

... it WAS indeed just a POP thing. I'd never seen code before that reset the stack multiple times (as well as temporarily lowering the pointer). Learn something new every day, I guess. 

[brucehoult]

It seems to be using the processor stack as a second index register while checking out the on-chip system to make sure everything is okey-dokey.

Pretty common, I'd think. It's the only way to get a reasonable performance memcpy() or similar e.g.

Code: [Select]

loop:
  pul a
  sta 0,x
  pul a
  sta 1,x
  pul a
  sta 2,x
  pul a
  sta 3,x
  dec b
  bne loop

... can get you close to 10 cycles per byte. Anything involving alternately loading X from src and dst pointers in RAM is going to be far slower.

Of course you need to disable interrupts and have a couple of fixed locations to stash S in while you do it.

6809 made life a LOT easier, in so many ways, including 4 index registers if you did the same trick with S.

[metertech58761]

It seems the 'RAM-less' memory tests are a thing as I can see similar code in some of the other code dumps I have at hand...
at least those other code files are for processors that have the luxury of a minimum of two indexes (i.e., HC11 and as you mention, the 6809).

Just goes to show the level of creativity required when you have a single index register and a mere 128 bytes of RAM!
I've got that section properly commented, now then... time to tackle the remaining unidentified addresses in the definitions.

[metertech58761]

Just gonna leave an updated copy of the source code here - got a few more things figured out.

Edit: POP strikes again - had a major flash of insight and got it 98% figured out... (three variables remain, one likely a vestige of other code)

[metertech58761]

And that should be the finished code. That said, there are a couple things I'm just not seeing.
One is where it counts off the header bits (a '1' for attention, then the preamble: 01010101011).
The other is the timer for the test LED. Supposedly, once the unit sees a valid message (likely meaning that it matched the unit's group address), the test LED is to remain lit for 64 minutes.

And just for some context, here are also schematics of the unit this code was read out of.