SUPERMON 816

[xjmaas]

BigDumbDinosaur wrote:

From where did you download the source code?

Here

[BigDumbDinosaur]

A recently-discovered bug in Supermon 816's instruction encoding/decoding table would not allow an ORA <abs>,Y instruction to be assembled and would cause such an instruction to be improperly disassembled. The problem has been corrected and the updated source code, version 1.1.1, has been uploaded to my POC website's downloads area. The source code has been modified as necessary to assemble with the most recent version of the Kowalski assembler (also linked on my POC website in the downloads area). Note that this version of Supermon 816 has a VT-100 display driver. If you are in need of the version with the WYSE 60 driver please contact me via PM.

Attached below is a guide for using Supermon 816. The description on page 3 incorrectly states the WYSE 60 is supported. As noted above, support is for the VT-100.

supermon816.pdf

Supermon 816 User Guide

(199.49 KiB) Downloaded 206 times

[akohlbecker]

Hi!

I've recently started playing with Supermon 816 on my system. It looks great and I intend to show it off in a future video. I'm having some issues with the integration though:

1. Are register sizes intended to be fixed when calling getcha/putcha? I found it to be M=1/X=0 in a lot of cases, but I found at least one where it is M=1/X=1. I've wrapped my subroutines with php/plp to ensure known values, but I'm thinking this may be indicative of a bug. I can find the exact spot again if you want.

2. I'm having issues with multiple commands misbehaving (`A`, `M` that I know of). I tracked it to the `getbyte` subroutine, which is doing `lda [addra],y`. However, if you look at `dpymem` for example, Y seems to contain the number bytes per line. Shortly after the call to `getbyte`, Y is decremented. `addra` is also incremented because `getbyte` falls through to `incaddra`. Which means it ends up reading every byte from the same location, the end of the line.

Code: Select all

calling M 008000...
first iteration of the loop is reading from 0x8010 

00 9bf6 r b7  LDA [dp],Y
00 9bf7 r 8f  
00 008f r 00  
00 0090 r 80  
00 0091 r 00  
00 8010 r 24  <--- here

... next iteration reads from the same location

00 9bf6 r b7  LDA [dp],Y
00 9bf7 r 8f  
00 008f r 01    <-- contents of addra have incremented
00 0090 r 80  
00 0091 r 00  
00 8010 r 24   <-- still reading from 0x8010 since Y has decremented

So this is what I end up seeing

Code: Select all

.m008000
>008000 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24:$$$$$$$$$$$$$$$$

I'll keep digging but in case you have ideas, let me know!

[akohlbecker]

Assembly is also failing in a weird way which I think may be related (haven't dug into it yet)

Code: Select all

.A 002000 LDA # $55 
... gives...
A 002000  A9 B9        LDA #$B9

[BigDumbDinosaur]

This is the first report I’ve had of bugs in Supermon 816 in some eight years—a number of people have adapted it to their systems since I originally posted it, with only one bug being reported to date (and fixed). In other cases, what were reported as bugs turned out to be conflicts over direct page usage.

I can’t duplicate what you are describing on my POC V1.3 unit, which runs an almost exact copy of the downloadable source code. When time permits, I will assemble the downloadable copy, run it as a process on V1.3 and see what happens.

As for the getcha/putcha calls, their behavior would be system-dependent. Supermon 816’s requirement is that operating-environment calls to read and write the console return with .X and .Y retaining their entry values. That requirement implies that the x bit in SR must also be unchanged. Additionally, getcha (and getchb, if used) should clear carry to indicate that data is available, or set carry if no data is available. The Supermon 816 guide describes what is expected of the local operating system. You may have to do some mods to the Supermon 816 source code if your operating environment exhibits different behavior.

One caution is if your operating environment switches the 65C816 to emulation mode to process calls and then switches it back to native mode before returning to the caller, you may be trashing registers without realizing it. A switch to emulation mode defaults DB and DP, and partially defaults SR. Additionally, if .X and .Y are wide when the 816 is switched to emulation mode, the MSB of both registers will be lost. All of this amounts to a major change in the operating environment, which will possibly cause Supermon 816 to go off the rails.

[akohlbecker]

Thanks for the reply!

It looks like removing `,y` from `lda [addra],y` in `getbyte` fixes all my issues, both for memory dump and assembly. It makes sense to me, if `addra` contains the working address and is being incremented at each iteration, and Y contains the remaining bytes to read.
But of course a few people have used this code so a bug that visible is weird. Here is how I integrated it. I'm not using the BRK integration and just jumping directly to the top of the monitor (`jmon`)

in supermon816.asm

Code: Select all

_origin_ =$009000
vecexit  =$00FF00
vecbrki  =$0224
hwstack  =$0003ff
zeropage =$80
getcha   =$00ff20
putcha   =$00ff40
chanbctl =$00ff80
ibuffer  =$000400

My own code:

Code: Select all

!address vecbrki = $0224 ; 2 bytes

                  stz vecbrki
                  stz vecbrki+1
                  jmp address($9000)

*=$9000

                  !bin "prgm/supermon816.65b", 8192, $9000

.pc=*
*=$ff00

vecexit           stp

*=$ff20
getcha
getchb            php
                  +x_16_bits
                  phx
                  phy
                  +x_8_bits
                  jsr acia_async_getc
                  +x_16_bits
                  ply
                  plx
                  +x_8_bits
                  bcc +
                  plp
                  sec
                  rts
+                 plp
                  clc
                  rts

*=$ff40
putcha            php
                  pha
                  +x_16_bits
                  phx
                  phy
                  +x_8_bits
-                 jsr acia_async_putc
                  bcs -
                  +x_16_bits
                  ply
                  plx
                  +x_8_bits
                  pla
                  plp
                  rts

*=$ff80
chanbctl          rts

*=.pc

[akohlbecker]

I'm still investigating the above issue.

In the meantime, I've translated Supermon816 to the ACME assembler. I've attached the file here in case that is helpful to anyone. This is the latest version available on BDD's website as of writing, and the binary output is identical between building the original with the Kowalski assembler, and building the file below with ACME.

Most of the changes revolve around the use of unique local labels, and making sure the right addressing mode is used (+1, +2 or +3 hints...)

EDIT: This file contains the straight port, without the fix I'm discussing above.

[akohlbecker]

Another person has confirmed in DM that the fix I mention above (removing `,y` from `lda [addra],y` in `getbyte`) also helps them.

BigDumbDinosaur, did you have a chance to look at this section of code? I'm curious to hear if I'm interpreting it correctly or if this is hiding another problem.

[BigDumbDinosaur]

akohlbecker wrote:

Another person has confirmed in DM that the fix I mention above (removing `,y` from `lda [addra],y` in `getbyte`) also helps them.

BigDumbDinosaur, did you have a chance to look at this section of code? I'm curious to hear if I'm interpreting it correctly or if this is hiding another problem.

The ,y should not be there. The correct code is lda [addra]. I don’t know how that ,y sneaked in there.

I will upload the corrected source code to my website ASAP.

[BigDumbDinosaur]

BigDumbDinosaur wrote:

I will upload the corrected source code to my website ASAP.

The corrected code is now available at my POC website. Also, it’s attached to this post.

supermon816.zip

Supermon 816

(829.18 KiB) Downloaded 100 times

[akohlbecker]

Thanks for taking a look!

Please find attached the updated port to ACME

[xlar54]

Ill be working on porting this to the supercpu for the C64 and C128. Very impressive work!

[BigDumbDinosaur]

xlar54 wrote:

Ill be working on porting this to the supercpu for the C64 and C128.

That should be an interesting project, especially with the C-128, given that machine’s rather baroque design.  I’m not at all familiar with the SuperCPU’s architecture and have only seen it in use a couple of times.  I’d think most of the work will be in reconciling Supermon 816 with the target machine’s use of zero/direct page.

In any case, please post your source code.

Quote:

Very impressive work!

Thanks!  Supermon 816 was actually born of necessity.  As I described in the documentation, I tried adapting “Supermon C02” to use with the 816, but too much rework was involved.  It was easier to just start from scratch.

I’ve been thinking about the possibility of adding one or two new features, but am leery of doing so because it will increase Supermon 816’s already-large memory footprint.  One of those features would be a four-function “calculator” to compute memory address offsets and other values in any of the four supported number bases.

The impetus for such a feature is that I often find myself manually performing address offset arithmetic when debugging a program that uses stack frames to call functions.  For example, if parameter ‘X’ has a stack offset of $13, DP is pointed to SP+1 and SP currently is $BF79, what is the absolute address of ‘X’ so I can examine it?  Right now, I have to use a real calculator or something like bc on one of my Linux machines to compute that—doing math in hex in my head is not one of my skills. 

This calculator would be quasi-algebraic (sorry Garth ) and would require that I change the radix for decimal values to something other than +.  The calculator would be invoked by typing ?, followed by an arithmetic expression, e.g.:

• ? $BF7A + $13

Evaluation would be strictly left-to-right.  Supported operators would be + (addition), - (subtraction), * (multiplication), / (division) and % (modulus).  Operands can, of course, be entered in any base.

It’s just out-loud thinking right now.