Simulating the MECB

[Editor]

I suspect the offending code is this:

Code: Select all

CDISP   BSR     CDNUM           ; FETCH ADDRESS
        ANDB    #$F0            ; FORCE TO 16 BOUNDARY
        TFR     D,Y             ; SAVE IN Y
        LEAX    15,Y            ; DEFAULT LENGTH
        BCS     CDISPS          ; BRANCH IF END OF INPUT
        BSR     CDNUM           ; OBTAIN COUNT
        LEAX    D,Y             ; ASSUME COUNT, COMPUTE END ADDR

It just simply adds the count to the address without any overflow checks.

I've just had a quick look, and I believe the issue is actually in HSDTA.

Specifically at location $FC3A, where it just checks if X is "? PAST LAST ADDRESS"
i.e.

Code: Select all

CPX	2,S		? PAST LAST ADDRESS
BHS	HSDRTN		QUIT IF SO

As HSDTA is dumping 16 byte blocks (on a 16 boundary), the code can (should) specifically check for X = 0 (before the CPX 2,S)

Otherwise, it is missing the overflow and progresses endlessly thinking it's never "? PAST LAST ADDRESS" (when the last address was in the range $FFF1 - $FFFF - due to the 16 byte blocks on 16 boundary).

So, I believe "? PAST LAST ADDRESS" should equate to either X = 0 OR CPX 2,S (BHS)

[djrm]

Trying to fit a correction into less than 2k code will be interesting ,,,.

btw, this reminds me of a problem in the dim & distant past where I had to extend a 16 bit value to properly handle a similar overflow condition and a C program. I wasn't happy having to do that but couldn't find another solution. Number wrapping after works in your favour with arithmetic but not always.

[Editor]

Trying to fit a correction into less than 2k code will be interesting ,,,

Perhaps a good use for a user extension?
I haven't looked any further into a possible fix yet, I've been sidetracked by weekend chores! LOL

[djrm]

If the test were done as signed compare then the list could stop sometime in the wrap around address. I.e d fff0 20 would then print two lines fff0 to ffff and 0 to f.

I like the idea of the fix as an extension rom command override.

[epaell]

I guess I shouldn't be looking at code before I've had my morning coffee

Yes, comparing X with 0 would be a good fix in the HSDTA. I made a quick check of this in the combined code and it seems to work fine. Though I hit the 2 KB limit and had to hack it a bit (I just changed the name of ASSIST09 to AS to save enough bytes to include the fix)

[Editor]

Yes, comparing X with 0 would be a good fix in the HSDTA. I made a quick check of this in the combined code and it seems to work fine.

Awesome. I hadn't gotten around to testing my logic yet.

Though I hit the 2 KB limit and had to hack it a bit (I just changed the name of ASSIST09 to AS to save enough bytes to include the fix)

Yes, the ASSIST09 code is pretty tight. I even like their SKIP2 trick!
But, I like your thinking of stealing some non-functional FCC space. Nice!

When I get to it, I was going to head down the path of implementing a User Extension HSDTA replacement.
Most certainly not a very efficient solution! But, I saw it as a good opportunity to write some simple User Extension VCTRSW example code.
I recall last writing ASSIST09 extensions, many many years ago!

[djrm]

I agree an updated HSDTA is needed. I tried changing the compre from unsigned to signed and this has improved things in most cases, certainly the bug as described is fixed but there are other faults or side effects too. My change is here:

Code: Select all

        BGE     HSDRTN          ; QUIT IF SO (djrm: changed from unsigned BHS to signed BGE)

some test results showing expected and odd behaviour where the number of lines of output gets cut short before the index header line is repeated, or sometimes total output is truncated.

Code: Select all

>D 0 40

      0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F  
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>D C000 40

      0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F  
C000 00 07 00 00 E2 A4 9C 2A 02 0D 02 0D 02 0D 02 0D  .....=..........
C010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>D FFE0 40

      0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F  
FFE0 6E 9D BF E8 6E 9D BF E6 6E 9D BF E4 6E 9D BF E2  n...n...n...n...
>D FFE0 30

      0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F  
FFE0 6E 9D BF E8 6E 9D BF E6 6E 9D BF E4 6E 9D BF E2  n...n...n...n...
>D FFF0 40

      0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F  
FFF0 FF D4 FF D8 FF DC FF E0 FF E4 FF E8 FF EC F8 37  ...............7
      0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F  
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>
CTRL-A Z for help | unix-socket | NOR | Minicom 2.8 | VT102 | Online 0:11 | unix#/tmp/mecb6809                                                          

I have a suspicion that there may be another bug lurking in there somewhere.

I've always used this crib sheet for deciding the appropriate branch instructions etc (link below), I find the layout ok.
My printout is very tatty and needs replacing.
https://archive.org/details/mc-6809-mc- ... ming-model

Another version with individual pages:
https://vtda.org/docs/computing/Motorol ... d_0291.pdf

This one can be printed out, double sided, two pages per sheet. If the pages are printed in this order and later cut in half it makes a neat A5 booklet. 1,3,2,4, 5,7,6,8, 9,11,10,12, 13,15,14,16
I needed to select landscape, and long edge duplex, fit to printable area for it to come out correctly.
The result is an a5 horizontal booklet stabled on the left edge.

extract showing nice layout of branch instructions:

Best regards, David.

[Editor]

I've always used this crib sheet for deciding the appropriate branch instructions etc (link below), I find the layout ok.
My printout is very tatty and needs replacing.
https://archive.org/details/mc-6809-mc- ... ming-model

Just a quick one... Thanks for this link! I have the exact same original MC6809 reference card, which I've used since the early 80's.
Mine's a little (a lot!) faded, but still in very usable condition (I've been very careful with it!).
I had never found a digital copy online before, and have never tried to scan my own.
So, this is a great find! I also have the same style reference card (not coloured) for the MC6800.

[djrm]

In my previous post I mentioned a new problem, it seems that the old version has the same problem too. I also realised that I had not used the same test commands. I've just re-tested my change and can verify that D FF00 FF does not loop forever, the other odd behaviour is the same or similar in both versions. Debugger, heal thyself.

edit: I was getting confused by the automatic insertion of address label lines in the middle of the output listing.
I can not find any fault at all now a bit odd.

[djrm]

Looking at the schematic of the mecb motorola i/o board I see that the NMI signal from the 6840 PTM is inverted. I see no accommodation for this in the MAME implementation. THhs is perhaps causing the problem I have getting the Assis09 single stepping to work. No other device interrupts need inverting.