Simulating the MECB

[djrm]

Hi Emil,
When using the disassembler in mecb for mame the default line count of 24 is too many to prevent the first line scrolling off the screen and being lost. I have changes this to 22 in my version to leave one line of whatever was there before and 20 lines of disassembly and the next prompt. That was I can see the first line. The value to change is called PAGELEN and appears as a constant equate near the beginning of the source file.

Code: Select all

PAGELEN EQU     24              ; Number of instructions to show before waiting for keypress

The display now looks like this:

HTH David.

[djrm]

e.g. You can put a $20FE flag (BRA *), at the location 2K below the start of the ASSIST09 ROM code, and the address following will be called as a subroutine (after vector table initialisation), with the U register pointing to the vector table.

This feature combined with the ability to perform a vector swap of the otherwise empty second command list table CMDTB2. The only problem I can see with this is that the disasm code is 3k and the default location for the BRA instruction is 2k below the monitor start, maybe i'll change this offset to 3 or 4k and see how it goes. Otherwise I would need to put an org directive the middle of the second rom, yuk.

Im struggling to get the simulation to recognise an NMI from the single step function, I think Ive added the required code to the maim source but cant be sure. I may need to get some hardware to play with before long if the simulation isnt playing nicely.

I'll try some simple software tests before I give in. The 6850 and 6522 should also generate IRQ interrupts if programmed to do so and enabled.

D

[djrm]

I'm seeing a problem with assist 09 when trying to dump rom including the range fff0 to ffff
when the d command includes this area the display wraps around back to 0 and continues seemingly endlessly, or at least until ^x is pressed.
I expect some kind of arithmetic bug somewhere. Has anybody seen this or maybe is it just my simulated system?
here is an example, first a good dump, and then one showing the bug:

Code: Select all

>D EF00 FF

      0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F  
EF00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
EF10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
EF20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
EF30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
EF40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
EF50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
EF60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
EF70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F  
EF80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
EF90 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
EFA0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
EFB0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
EFC0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
EFD0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
EFE0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
EFF0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>D FF00 FF

      0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F  
FF00 5A 2B 32 AC A1 26 F9 AE A1 AF 3C 5A 2A F9 0A FA  Z+2..&....<Z*...
FF10 8D 2E 27 E9 30 A1 3F 05 5A 26 F9 3F 06 39 8D 20  ..'.0.?.Z&.?.9. 
FF20 C1 08 27 11 A6 84 E7 84 E1 84 26 09 A7 84 5A 2B  ..'.......&...Z+
FF30 07 AC A1 26 F9 16 FA 24 AF A4 6F 31 0C FA 20 D0  ...&...$..o1.. .
FF40 9E 9B 31 8D C0 6C D6 FA 39 6F E2 5F 30 8C 3F 3F  ..1..l..9o._0.??
FF50 00 81 5B 26 06 86 10 A7 E4 3F 00 81 0D 27 0C 6D  ..[&.....?...'.m
FF60 84 2B D2 A1 81 26 F8 EB 1F 20 EE 30 8C 49 1F 98  .+...&... .0.I..
FF70 84 60 AA E4 A7 E4 C4 9F 6D 84 27 B9 E1 81 26 F8  .`......m.'...&.
      0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F  
FF80 E6 1F EA E4 E7 E4 30 E4 3F 04 3F 06 35 84 41 04  ......0.?.?.5.A.
FF90 42 05 44 06 48 01 48 01 48 01 48 00 2C 00 2D 09  B.D.H.H.H.H.,.-.
FFA0 2D 01 53 70 59 30 55 50 58 10 2B 07 2B 01 50 80  -.SpY0UPX.+.+.P.
FFB0 43 00 52 00 5D 00 FF 10 84 11 00 12 88 13 89 14  C.R.]...........
FFC0 86 15 85 16 8B 17 80 18 81 19 82 1A 83 82 8C 83  ................
FFD0 8D 03 9F 00 6E 9D BF EE 6E 9D BF EC 6E 9D BF EA  ....n...n...n...
FFE0 6E 9D BF E8 6E 9D BF E6 6E 9D BF E4 6E 9D BF E2  n...n...n...n...
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  ................

its a blumin nuisance when trying to see the reset vectors!

[Editor]

... The only problem I can see with this is that the disasm code is 3k and the default location for the BRA instruction is 2k below the monitor start, maybe i'll change this offset to 3 or 4k and see how it goes. Otherwise I would need to put an org directive the middle of the second rom, yuk.

I'd probably approach this by working out how much ROM I have to play with. So, given 2K + 3K is >4K, I'd guess this combination is well matched for the 56K RAM / 8K ROM memory map.
On this basis, can you position the 3K disasm at, say, $E400 - $EFFF, allowing ASSIST09 to sit at it's usual $F800, and 2K still free for "customisation space" from $F000 - $F7FF (i.e. 2K below ASSIST09)?

Im struggling to get the simulation to recognise an NMI from the single step function, I think Ive added the required code to the maim source but cant be sure. I may need to get some hardware to play with before long if the simulation isnt playing nicely.

I'll try some simple software tests before I give in. The 6850 and 6522 should also generate IRQ interrupts if programmed to do so and enabled.

You guys are really tweaking my curiosity. I really must pause my hardware design / firmware coding fun, to take a closer look at all this!

[epaell]

Strange, I thought I just posted a reply but it seems to have disappeared. Anyway, I was just mentioning that I have tested the IRQ side of things on the MAME emulation and can confirm that it works on the emulated MECB 6502 with the emulated PTM (6840) using the timer code in my GitHub. I also tested it on the emulated MECB 6809 with the emulated VDP (working off the vertical blanking interrupt) using the plasma code in my GitHub.

I also noticed that I had my modified version of Assist09 in my repository (which is the same as the original but with minor changes to adjust for the MECB I/O and to add some code to allow my SD-card module to work with FLEX). I didn't include this one in the simulator because I adjusted the I/O to allow for more RAM and also because I don't have simulator code for the SD-card module.

[Editor]

I'm seeing a problem with assist 09 when trying to dump rom including the range fff0 to ffff
when the d command includes this area the display wraps around back to 0 and continues seemingly endlessly, or at least until ^x is pressed.
I expect some kind of arithmetic bug somewhere. Has anybody seen this or maybe is it just my simulated system?

its a blumin nuisance when trying to see the reset vectors!

Yes, you tweaked a memory of this frustration using ASSIST09.

I just tried it out on my 6809 PLCC hardware, and observe the same thing.

e.g. if I do:

Code: Select all

D FF00 F0

I get everything except the last 16 bytes of memory (as expected).

But, if I do:

Code: Select all

D FF00 F1

I get the endless wrap-around, requiring Ctrl-X to stop.

So, yes, difficult to just observe the 6809's vector table.

Not nice, but the easiest way to observe last 16 bytes of memory (if not quick enough on Ctrl-X), seems to be to:

Code: Select all

M FFF0

... followed by 15x Space key presses.

It would be interesting to take a look at whether there is an easy fix for this (after 40 odd years! LOL).

[epaell]

I expect some kind of arithmetic bug somewhere. Has anybody seen this or maybe is it just my simulated system?

I had noticed this before as well and I thought it was user error on my behalf (because by the time everything flew off the top of the screen I couldn't check if I had maybe inadvertently typed the wrong command).

Anyway, I just checked it on the real system now and the same thing happens - so likely it is an overflow error that isn't checked for.

[epaell]

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.

[Editor]

I may need to get some hardware to play with before long if the simulation isnt playing nicely.

Funnily enough, I was just thinking that I really need to assemble some more MECB Cards.

I seem to be always swapping PLDs, when reconfiguring my MECB system.

So, it would probably be smarter for me to just assemble a couple more Cards, so I can just swap Card's instead of PLDs.

But, I do enjoy playing with "hands on retro hardware", more than emulation (although emulation no-doubt fast-tracks software development).

[epaell]

So, it would probably be smarter for me to just assemble a couple more Cards, so I can just swap Card's instead of PLDs.

That was my lazy approach (and how I tested the above) as I have one card set up with the combined Assist09 and another with the OS-9 set-up (minimal ROM to maximise RAM) and the latest version of the 6309 card (once I get a few bits in the mail) - it's so very convenient to test various things (even more so because the only way I can program the PLDs is to take the windows machine out of storage and set it up - which in itself is a major undertaking). It also helps having the MAME simulation for other quick checks.

Ah, I just looked up LEAX and it seems it doesn't deal with overflows ... so that aspect of the code would have to be done differently. Perhaps checking whether the end address is less than the start address at label CDISPS and if so forcing the end address to 0xFFFF.