Good 65816 monitor?

[fachat]

I am looking for a 65816 machine language monitor with 4k size at max (given that load/save/character out/keybd in are provided by the OS). And it should be open source.

I have a 6502 monitor in 4k with some advanced features that I could take out, but I can imagine that a 65816 assembler/disassembler requires quite more space than just 6502.

My goal is to integrate it into my Micro-PET ROM, replacing the @mon I currently use but which is 6502 only.

Any suggestions?

Thanks
André

[8BIT]

My SBC-3 monitor used a modified version of the SBC-2 monitor and included disassembly of 65816 code. I would not classify is as "Good", but the source is given and you can take out the parts you don't need and most likely get it under 4k. it was loosely based on the Apple 2 Monitor. It is dumb in relation to 8 bit and 16 bit immediate values, but I worked around it with 2 disassembly commands - one forced 8 bit and the other forced 16 bit.

Feel free to have a look. https://sbc.rictor.org/download/sbc3.zip ... in the SysMon folder.

Daryl

[BigDumbDinosaur]

fachat wrote:

I am looking for a 65816 machine language monitor with 4k size at max (given that load/save/character out/keybd in are provided by the OS). And it should be open source.

How about Supermon 816?

[barrym95838]

BigDumbDinosaur wrote:

How about Supermon 816?

Undoubtedly brilliant, unfortunately 641 bytes too heavy. Unless 4 KB isn't a strict limit.

[fachat]

The plan is to have it in 4k.

But with all the other extensions I'm building into the ROM I may need to re-shuffle the memory map. I'll have a look what's most needed and maybe try to strip it.

[BigDumbDinosaur]

barrym95838 wrote:

BigDumbDinosaur wrote:

How about Supermon 816?

Undoubtedly brilliant, unfortunately 641 bytes too heavy. Unless 4 KB isn't a strict limit.

If the S-record loader isn’t needed, it wouldn’t be a challenge to excise those bytes.  I haven’t test-assembled without the loader, so I can’t say for sure 641 bytes would be removed.

[BigDumbDinosaur]

fachat wrote:

The plan is to have it in 4k.

But with all the other extensions I'm building into the ROM I may need to re-shuffle the memory map. I'll have a look what's most needed and maybe try to strip it.

How much ROM do you have?  When I morphed my POC V1.1 unit into V1.2 (with four TIA-232 channels and SCSI), I shuffled the memory map to increase ROM space from 8 KB to 12 KB.  That gave me more-than-ample room for the extra code needed to go with the hardware expansion, as well as to accommodate the monitor, to which I had added low-level SCSI command processing.  I retained the V1.2 memory map for V1.3, the latter which has 64KB of extended RAM, for a usable total of 112KB RAM, 12KB ROM and 2KB I/O space.

I wrote Supermon 816 with a focus on functional capabilities, with footprint a secondary consideration.  I suspect there are areas in the code that could be massaged to shrink the footprint, but I haven’t been motivated to undertake that process.  The source code is thoroughly commented, so please feel free to do some massaging if it will help.

I have attached a version that doesn’t have the S-record loader, but is otherwise identical to the version linked in my earlier post.  Removal of the loader shrinks the object code to 4,064 bytes.

supermon816c_no_srec.asm

SUPERMON 816, no S-record loader

(171.66 KiB) Downloaded 68 times

[fachat]

BigDumbDinosaur wrote:

fachat wrote:

The plan is to have it in 4k.

But with all the other extensions I'm building into the ROM I may need to re-shuffle the memory map. I'll have a look what's most needed and maybe try to strip it.

How much ROM do you have?  When I morphed my POC V1.1 unit into V1.2 (with four TIA-232 channels and SCSI), I shuffled the memory map to increase ROM space from 8 KB to 12 KB.  That gave me more-than-ample room for the extra code needed to go with the hardware expansion, as well as to accommodate the monitor, to which I had added low-level SCSI command processing.  I retained the V1.2 memory map for V1.3, the latter which has 64KB of extended RAM, for a usable total of 112KB RAM, 12KB ROM and 2KB I/O space.

I wrote Supermon 816 with a focus on functional capabilities, with footprint a secondary consideration.  I suspect there are areas in the code that could be massaged to shrink the footprint, but I haven’t been motivated to undertake that process.  The source code is thoroughly commented, so please feel free to do some massaging if it will help.

I have attached a version that doesn’t have the S-record loader, but is otherwise identical to the version linked in my earlier post.  Removal of the loader shrinks the object code to 4,064 bytes.

supermon816c_no_srec.asm

I briefly looked at it - looks very nice.

I noticed some macros - which assembler does it need to build?

In the intro it says it's native mode - so if I normally run in emulation, I'll have to create a wrapper. Anything in particular to look at when exiting? Does it exit at a single location only ("X" command)?

Thanks
André

[BigDumbDinosaur]

fachat wrote:

I noticed some macros - which assembler does it need to build?

It builds in the Kowalski assembler, version 1.3.4 or later, available on Daryl’s website.  Kowalski’s macro language is straight-forward, so it shouldn’t represent much of an obstacle to building in some other assembler.  I’m gathering that you want to be able to assemble it in the xa assembler.  That shouldn’t be too difficult to achieve.

Quote:

In the intro it says it's native mode - so if I normally run in emulation, I'll have to create a wrapper.

Yes, the monitor is 100 percent native mode.  It will not run in emulation mode, unless you are prepared to do a lot of modification.

Quote:

Anything in particular to look at when exiting? Does it exit at a single location only ("X" command)?

The exit via the X command is the only exit back to the environment.  The exit uses JML to allow an exit to code in any bank, including the one in which Supermon 816 is running.

Your main concern will be what happens if running in emulation mode and a BRK instruction kicks you into the monitor.  That will not end well, since the monitor implictly expects the 816 to be in native mode when a BRK is processed.  The stack will be all wrong if BRK occurs in emulation mode.

[fachat]

I've been working on porting supermon816 to a Commodore PET clone using a 65816. Here's some notes / comments:

- There's an awful lot of zeropage usage. So I'll set the DP pointer to some free space (actually planning to use page 1, and use the lower half of the stack space for the about 64 bytes of used zp) I found that moving some of those out of zeropage increases overall length of the binary over the desired limit...
- Is clearing the "workspace" required for proper operation? Otherwise this code could be left out.
- How much variable space could potentially be combined? (maybe moot as DP can be relocated)
- I think the entry points should be separated out more: I am not sure setting the brk vector belongs into the monitor proper - maybe good for some 816 systems, but what on systems that do not behave like specified in the comment of that routine?
- vecbrkia is in the middle of the binary - so this prevents write-protecting the address space used for the monitor itself. This should probably also be left to the "outer shell" or "binding" to the host system?
- Some weird kowalski assembler syntax I had to adapt. How active is this assembler actually? Does it make sense to move to another assembler altogether?

I'll keep you posted.

Anyway, here is the repo: https://github.com/fachat/upet_supermon816

André

[fachat]

P.S.: it would be interesting (for me) to have a Jump or Go instruction that jumps to the code in emulation mode.
P.P.S.: terminal control codes could be expected from an "outer" shell as defined macros, to adapt to potentially differenty host systems (edit)

[fachat]

Finally got to a point where I could work on integrating this into the UltiPET/MicroPET ROMs.

So, I was trying to write a small shim around the monitor, by implementing

Code: Select all

getcha

and

Code: Select all

putcha

such that they use the (original 6502) input/output routines from the PET ROM that I am using.

Unfortunately, the 816 mode bits are driving me .....*****

Is there a documentation, what is actually expected from these two calls regarding the M and X mode bits? The specs only state that the registers should be preserved. It also does not help that supermon816 switches modes very often....

As far as I can see it seems at least putcha is being called from different places with different mode bits set (grep from debugger trace, in this build, 1052 is putcha - you see that x is sometimes set and sometimes isn't)

Code: Select all

A003b X0010 Y0033 S01fb D0100 B00 P20 (nvMxdizc) N  00.180b  jsr $1052          (@001052 08 c2 20 ...)
A003b X0010 Y0033 S01f9 D0100 B00 P20 (nvMxdizc) N  00.1052  php 
A0020 X0010 Y0034 S01fb D0100 B00 P20 (nvMxdizc) N  00.180b  jsr $1052          (@001052 08 c2 20 ...)
A0020 X0010 Y0034 S01f9 D0100 B00 P20 (nvMxdizc) N  00.1052  php 
A0030 X0030 Y00e9 S01fd D0100 B00 P30 (nvMXdizc) N  00.17d2  jsr $1052          (@001052 08 c2 20 ...)
A0030 X0030 Y00e9 S01fb D0100 B00 P30 (nvMXdizc) N  00.1052  php 
A0030 X0030 Y00e9 S01fd D0100 B00 P30 (nvMXdizc) N  00.17d6  jmp $1052          (@001052 08 c2 20 ...)
A0030 X0030 Y00e9 S01fd D0100 B00 P30 (nvMXdizc) N  00.1052  php 

I think I got it fixed now using php/plp to restore the M/X bits as they were.

But some hint / documentation would be great. I tried to setup the assembler to have appropriate ".xl/.xs/.al/.as" instructions so it assembles the immediate values in the right size, but still seem to have some mode errors left with some code not really running.

As a best practice for 816 code: I name my labels with a postfix "_al" or "_xl" when they deviate from the 6502 standard.... that makes it very clear what is expected....

André

[BigDumbDinosaur]

fachat wrote:

Finally got to a point where I could work on integrating this into the UltiPET/MicroPET ROMs.

So, I was trying to write a small shim around the monitor, by implementing

Code: Select all

getcha

and

Code: Select all

putcha

such that they use the (original 6502) input/output routines from the PET ROM that I am using.

Unfortunately, the 816 mode bits are driving me .....*****

Does .....***** by chance refer to what comes out of the south end of a northbound Fledermaustier? 

When I originally wrote Supermon 816, I had targeted my POC hardware, whose getcha and putcha BIOS API calls can be called with any combination of register widths.  Since your environment (the souped-up PET) is very different, here’s a suggest procedure for making PET “kernal” ROM calls. The below code includes a call to the PET’s getin sub for fetching a keystroke.  The same framework can be used to make calls to the PET’s basout (aka chrout - $FFD2) sub to write to the screen.  You could also add code to deal with PETSCII.  With a little more effort, you could make this into an all-purpose kernel sub caller.

Code: Select all

;save entry state
;
         clc                   ;assume no error
         php                   ;preserve SR
         rep #%00110000        ;wide registers
         phy                   ;preserve .Y
         phx                   ;preserve .X
         pha                   ;preserve .C
         phb                   ;preserve DB
         phd                   ;preserve DP
;
;Next, describe the above stack frame using local variables,
;which I am prepending with a . to make them local.
;
.reg_dp  =0                    ;16-bit direct page pointer
.reg_db  =2                    ; 8-bit data bank
.reg_c   =3                    ;16-bit accumulator
.reg_x   =5                    ;16-bit .X
.reg_y   =7                    ;16-bit .Y
.reg_sr  =9                    ; 8-bit status
.reg_pc  =10                   ;16-bit return address
;
;End of register stack frame.
;
;At this point, native mode machine state has been saved on the stack.
;However, you need to preserve the stack pointer somewhere in RAM, since
;you will have to revert the MPU to emulation mode to call code in the
;PET’s kernel ROM.  When you switch to emulation mode, the MSB of the
;stack pointer will be set to $01.
;
         tsx                   ;copy 16-bit stack pointer to...
         stx stackptr          ;safe storage...16-bit write to RAM
;
;Next steo is to revert to emulation mode.  Doing so will not only trun-
;cate SP, it will force DP to $0000, & will set the m & x bits in SR to
;1, forcing the accumulator & index registers to 8-bits.  We will also
;force DB back to bank $00, just in case it is pointing to an extended
;RAM bank.  Reason for doing so is the kernel code will be reading &
;writing in the $0000-$FFFF address range.
;
         sep #%00010000        ;8-bit index
         ldx #0                ;force...
         phx                   ;DB to point...
         plb                   ;to bank $00
         sei                   ;no IRQ during mode change...
;
;When you flip the MPU to emulation mode, the IRQ/BRK vectors change to
;that of the 65C02 ($FFFE-$FFFF) & the 'b' bit in the SR copy pushed
;during an IRQ or BRK is now meaningful.  Beware of this change should
;you enable IRQs while in emulation mode.  Also, beware of the changed
;NMI vector; it will now be at $FFFA-$FFFB.
;
         ldx #$ff              ;emulation mode stack pointer...
;
;Set the above to whatever is reasonable.  $FF is just an example.
;However, if Supermon 816 is using $0100-$01FF as its stack, DO NOT
;change the stack pointer after entering emulation mode.  If you do,
;the calls to the PET's kernel ROM will likely trash something on the
;stack & blow up things.
;
         sec                   ;flip the MPU to...
         xce                   ;emulation mode
         txs                   ;stack at $0100-$01FF (see above note)
;
;Now, you can make your kernel ROM calls, e.g., getting a keystroke:
;
         jsr clrchn            ;$ffcc - select keyboard & screen I/O...
;
;Above only necessary if you aren't sure what is defined as the input
;device.
;
         jsr getin             ;$ffe4 - fetch from keyboard...
;
;GETIN will return with a PETSCII keystroke or $00 if the keyboard
;buffer is empty.  We have to write the return in .A back to the LSB
;of the accumulator's entry stack copy & if the buffer was empty, we
;also have to set carry in the entry stack copy of SR.  Before we can
;take any of those steps, we have to return to native mode & restore
;SP so we are working in the right place on the stack.
;
         clc                   ;flip the MPU to...
         xce                   ;native mode...
;
;Returning to native mode doesn’t affect register widths...they will
;remain set to 8 bits.
;
         rep #%00010000        ;wide index
         ldx stackptr          ;restore our native...
         txs                   ;mode stack pointer...
;
;Only do the stack pointer thing if the emulation mode stack was in a
;different place.  See above note about setting up the emulation mode
;stack.
;
         cli                   ;IRQs are okay now
;
;With the MPU back in native mode, we can process what we got from the
;GETIN call.
;
         txs                   ;where we are on the stack
         inx                   ;point to bottom of register frame
         phx                   ;pass it over to DP...
         pld                   ;to make register frame direct page...
;
;You may have to inhibit IRQs while DP is pointed to the stack.  It all
;depends on whether your IRQ handler fully preserves machine state.
;
;Since we pointed DP to SP+1, we can use direct-page addressing modes.
;
         ora #0                ;did we get a keystroke?
         bne .l00001           ;we did (.l00001 is a local label)
;
;No keystroke returned, so set carry to indicate this.
;
         lda #%00000001        ;carry bit mask
         tsb .reg_sr           ;set it in SR stack copy &...
         bra .l00002           ;exit
;
;Return keystroke to caller via accumulator.
;
.l00001  sta .reg_c            ;save keystroke
;
;Now we restore machine state & exit.
;
.l00002  rep #%00110000        ;wide registers &...
         pld                   ;restore everything
         plb
         pla
         plx
         ply
         plp
         rts

Now, I haven’t tested the above code—no souped-up PET, but I see no reason for it not to work.  You may have to fiddle with it to accommodate the way your PET’s hardware is interacting with the MPU.

Quote:

Is there a documentation, what is actually expected from these two calls regarding the M and X mode bits?

I attached the Supermon 816 manual, which is the most complete documentation of the software.  It is included in the distribution that is on my website.

supermon816.pdf

Supermon 816 Documentation

(743.25 KiB) Downloaded 28 times

[fachat]

BigDumbDinosaur wrote:

fachat wrote:

Finally got to a point where I could work on integrating this into the UltiPET/MicroPET ROMs.

So, I was trying to write a small shim around the monitor, by implementing

Code: Select all

getcha

and

Code: Select all

putcha

such that they use the (original 6502) input/output routines from the PET ROM that I am using.

Unfortunately, the 816 mode bits are driving me .....*****

Does .....***** by chance refer to what comes out of the south end of a northbound Fledermaustier? 

Absolutely.

Quote:

When I originally wrote Supermon 816, I had targeted my POC hardware, whose getcha and putcha BIOS API calls can be called with any combination of register widths.  Since your environment (the souped-up PET) is very different, here’s a suggest procedure for making PET “kernal” ROM calls. The below code includes a call to the PET’s getin sub for fetching a keystroke.  The same framework can be used to make calls to the PET’s basout (aka chrout - $FFD2) sub to write to the screen.  You could also add code to deal with PETSCII.  With a little more effort, you could make this into an all-purpose kernel sub caller.

... extensive code snippet cut ...

Quote:

Now, I haven’t tested the above code—no souped-up PET, but I see no reason for it not to work.  You may have to fiddle with it to accommodate the way your PET’s hardware is interacting with the MPU.

Many thanks for that elaboration! I arrived at a smaller version as I used some of the options you mention - like not modifying the stack pointer, or even not saving all registers as the code I call does not use them... (ah that reminds me - emulation mode clears the upper byte in X/Y as well? I should probably push them too... (referring to above of *****)

Quote:

Quote:

Is there a documentation, what is actually expected from these two calls regarding the M and X mode bits?

I attached the Supermon 816 manual, which is the most complete documentation of the software.  It is included in the distribution that is on my website.

supermon816.pdf

Thanks for the good documentation. What I am still fighting with though is, which internal routine is called with which M/X bits set as it seems I may have missed some hints during conversion to xa, and will probably have to insert some mode

Code: Select all

.xs/.xl/.as/.al

pseudo-opcodes... That's where my convention of adding required modes to a lable comes from - make the required mode flags explicit to avoid ambiguities...

Having said that, I will probably have to reverse the control flow anyway - currently the monce routine loops, reads chars into a buffer, and executes them and returns to the loop. My goal is to use the monitor in these settings:

1. when called from BASIC with SYS in the normal BASIC editor
2. when called from a special key shortcut, in a separate screen so you can interrupt running code and look at it
3. when configured from boot, from a serial line interface, running in the interrupt

So, the plan is to extract the monce loop, potentially triple the input routine for the different setups (that should of course be able to run in parallel - you may have noticed sometimes I'm looking for a challenge ), and then just call the command interpreter / executor from the outside, with interrupt flag set.

Related to that I think I would add (optional) "MX" fields in the assembly/disassembly input and output, to replace the internal state that (I think) is held for the disassembly to correctly interpret the binary code for immediate values.
This would also facilitate "scroll disassembly": move the cursor down to the bottom of the screen and scroll up, and the disassembly (or memory dump for that matter) continues. You may know this behaviour from machine language monitors on the C64, where it even works upward, but that is without mode bits.... (re: ******) ....

Also, the 4k limit has fallen - I will move the assembler to a different bank if needed.

So, a lot to do...

Thanks for your support!
André

[barrym95838]

fachat wrote:

You may know this behaviour from machine language monitors on the C64, where it even works upward, but that is without mode bits.... (re: ******) ....

Wasn't scanning 65xx machine code "against the grain" a bit of a crapshoot anyway, even without the M and X bits?