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?

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

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?

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

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

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

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

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.

_________________
Regards, KM
https://github.com/floobydust

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

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!

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

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



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.

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?

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.

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.

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.

_________________
Modules | Processors | Boards | Boxes | Beep, Beep! I'm a sheep!