65c816 Machine Language Monitor

[A0CBM]

I am trying to locate a machine language monitor for my VIC 20 with a 65c816 in it. My preference is to have it written in 6502 assembly, so it can run in emulation mode. I don't have any operating system for this except the Basic 2.0. I just need a simple monitor that works on Commodore hardware. Jamaica-mon looks good, but I don't have any source code and I can't disassemble it correctly with the monitors I do have. Supermon 816 uses a tty monitor, which wouldn't work on Commodore hardware. Any help out there?

[BigDumbDinosaur]

A0CBM wrote:

I am trying to locate a machine language monitor for my VIC 20 with a 65c816 in it...Supermon 816 uses a tty monitor, which wouldn't work on Commodore hardware.

Sure it will...with some minor tweaking. Read the source code to find the “hooks” that have to be changed to make use of the VIC-20's GETIN ($FFE4) and BASOUT ($FFD2) kernel functions for terminal I/O.

As for the escape sequences that perform display procedures, e.g., clearing to end-of-line, you'll need to create some code that performs those actions, since the VIC-20's display subsystem is very primitive and lacks such capabilities.

See the attached for more info.

supermon816.pdf

Supermon 816 Documentation

(241.07 KiB) Downloaded 104 times

[A0CBM]

How do I handle the new location of the system vectors ? Moving them to $ffeo will interfere with the kernal's jump table won't it?

[BigDumbDinosaur]

A0CBM wrote:

How do I handle the new location of the system vectors ? Moving them to $ffeo will interfere with the kernal's jump table won't it?

You do have the alternative of modifying the page 3 vector for BRK, as well as other vectors as needed. That's why they are there. I'm not super-familiar with the VIC-20's memory map, so my ability to help you on this is limited. See attached and look for the kernel vectors starting at $0314.

mapping_the_vic.pdf

Mapping the VIC-20

(34.11 MiB) Downloaded 85 times

[handyandy]

I had a similar issue with a Laser 128ex and 65c802. I enabled upper 16k ram, copied rom to ram and then wrote whatever addresses for native mode vectors (BRK, IRQ, COP).
If all you have is rom you might consider a rom twice the size and use the E bit as a high address bit so half the rom is native and remaining is emulation.
I think BBC micros had a similar issue with native vector space.

There’s also the VPB pin if you want to go that route…

Cheers,
Andy

[drogon]

handyandy wrote:

I had a similar issue with a Laser 128ex and 65c802. I enabled upper 16k ram, copied rom to ram and then wrote whatever addresses for native mode vectors (BRK, IRQ, COP).
If all you have is rom you might consider a rom twice the size and use the E bit as a high address bit so half the rom is native and remaining is emulation.
I think BBC micros had a similar issue with native vector space.

I 'solved' the native mode vectors in my Acorn MOS (BBC Micro) compatible (ish) OS for my Ruby '816 systems by relocating a few entry points then scanning ROMs for JMP or JSRs into those vectors and patching them.

It doesn't work for all ROMs but BASIC (1,2,3,4) works well.

-Gordon

[floobydust]

Not sure if you have Commodore's Vicmon, but you could disassemble the input initialization routine for that, which would give you some input on how to insert some vectors into the Vic-20. Using this, plus the Supermon816 code from BDD might give you a decent monitor running on the Vic-20.

Years ago, I managed to figure out how to relocate the Vicmon monitor and saved out numerous versions at different load addresses. It wasn't that difficult.

[xlar54]

Can you tell us more about this 65816 in a vic-20?

[xlar54]

BDD - Im looking at modifying this for the C64 and 128. One question - if the machine is running in emulation mode, does the monitor brk into emulation mode as well? I was working on an ML monitor before, and ran into this very issue. Thanks!

[BigDumbDinosaur]

xlar54 wrote:

BDD - Im looking at modifying this for the C64 and 128. One question - if the machine is running in emulation mode, does the monitor brk into emulation mode as well? I was working on an ML monitor before, and ran into this very issue. Thanks!

Supermon 816 doesn’t change the MPU’s mode when intercepting BRK or COP. If running in emulation mode it’ll remain in emulation mode.

That said, Supermon 816, as written, expects the MPU to be running in native mode. SM816 will not run in emulation mode without modification.

[A0CBM]

xlar54 wrote:

Can you tell us more about this 65816 in a vic-20?

What I am attempting is to give the VIC 20 the power of the 65C816. I started by adding logic to put RAM under the kernal and basic roms, plus two 4K blocks of RAM under the character rom. This is all controlled by a register that I mapped to $9200. This was done by further decoding from $9000 with a 2 - 4 decoder. This shadow memory has been tested using a modified assembler for the C64 and runs from RAM under the kernal and basic. Now I'm trying to get the 65C816 to do this also. I am using a 128K static ram chip for now and plan to increase that once the '816 can perform the same test. I'm using Xilinx XC9572's, the 5v version.

When it is all up to snuff, I will need a machine language monitor. I am looking at JamaicaMon, but it has code for the SuperCPU that references bank 1. I don't know anything about the ROMs in the SuperCPU, so I don't know what this code references

Code: Select all

; ** INITIALIZATION ** 
SUPER CLC  
XCE`;NATIVE MODE  
REP #$30`;EVERYONE 16-BITS  
PER VBREAK  
SEI  
PLA  
STA BKVEC  
PER BREAK  
PLA  
STA $01FC9D`;NBRK
STA $017C9D  
LDA #0000  
DFB $5B`;DP -> ZERO-PAGE  
SEP #$30`;EVERYONE 8-BITS  
STA $01FC9F`;BANK 0  
STA $017C9F  
CLI  
LDA #$80  
JSR SETMSG  
SEC  
XCE  
JSR INIT`;INIT PPP 
BRK  

Since my project doesn't have all the special features of the SuperCPU, I'm trying to find out what I need to keep and what can go. I do have WinVICE for the SuperCPU, but know nothing about the roms locations.

Thanks for any help anyone can offer.

[A0CBM]

Does anyone have a Super CPU and know what is in bank 1, where the STA is referencing in the above code snippet? Can these values be stored elsewhere, or even at all, since I'm not using a SuperCPU? It looks like it could be a new brk vector. Is there code in bank 1 of the SuperCPU, or is it SuperCPU trickery?

[xlar54]

Its a little confusing...

The SCPU has its own RAM on board (and you can add up to 16mb).

Bank $00, $01, $f8-$ff are found in all SuperCPUs, with or without expansion RAM. Bank $00 and $01 are built-in static RAM, and banks $F8-$FF are used by or reserved for system ROM (SuperCPU ROM, not c64 ROM).

Expansion RAM (DRAMs) - called "SuperRAM" goes into bank $02-$F5 ($f6 and $f7 are reserved for future system use)

Basically, banks $00 and $01 are used by the SuperCPU to mirror portions of the 64's RAM and ROM. You could almost say that it emulates a c64, and uses those banks to do so. If you just coded (in native or 6502 mode) without switching to other banks, your code would live in bank 0. Bank 1 is used by the SuperCPU to mirror ROM and some other optimization stuff. Documentation just says "PseudoROM-RAM". You can probably play here depending on the optimization mode settings. But I prefer to steer clear of all that and have wide-open range available to me starting in bank 2.

Just remember that direct page has to be somewhere in bank 0 (I usually just leave it where it is by default), and that calls to kernal routines are also in bank 0.

To answer your core question...there is indeed code there...or data.. but no clue what its doing. I dont know that anyone knows other than the author of that monitor perhaps.

[BigEd]

Aha, so the addresses $01FC9F and $017C9F as seen by the '816 will correspond to - be mapped to - some similar addresses in Bank 0, appearing or not appearing according to the C64 memory map at the time. There's perhaps a fairly good chance the corresponding address ends in 9F and perhaps even C9F.

[Sheep64]

You're got the familiar problem of teasing apart conflicting uses of page $FF. drogon recommends patching binaries. Indeed, it is worthwhile to patch Acorn binaries such that $20,$VV,$FF is replaced with $20,$VV,$FB and Commodore binaries to $20,$VV,$FD.

I found that it is possible to devise a ROM with common vectors for 6502/6800 systems. This works quite easily because byte endian order differs. Two byte hardware vectors and three byte jump tables is a more difficult case. If every three bytes is JMP abs then 1/3 of the hardware vectors will have $4C in the least significant byte and 1/3 of the hardware vectors will have $4C in the most significant byte. The latter is unworkable.

I found that it is possible to echo I/O in all 65816 banks and run a legacy binary outside bank zero. This allows Acorn/Commodore/65816 vectors to exist at the same address in different banks. Unfortunately, JMP (abs,X) always indirects via bank zero whereas JMP (abs) uses the current bank. Therefore, it is trivial to run multiple ABIs outside of bank zero - if they never use JMP (abs,X). Unfortunately, this may break interpreters, such as BASIC.

If you want full downward compatibility with VIC20 (with unpatched ROMs and unpatched applications) it may be preferable to run in bank zero and connect 65816 /VP to one ROM address line. In this case, 65816 vectors are in their own inaccessible address-space. Implementation requires half a ROM which is quite wasteful. It also means not using the original DIP chip.