You should definitely have a look at the kernel jump table below $ffff in the kernel! For example instead of $e716 you should use "$ffd2", which outputs a character to the current output file (normally the screen), but this can be redirected to any file - e.g. to print to a file or a printer.
Besides that, the could would be more portable. I have written programs that were actually portable between C64 and PETs by just using the jump table (i.e. those parts that are identical).

The interrupt routine is routed through an interrupt vector. You can route this around to patch into the interrupt routine without even changing the ROM.

Also $Ea87 should be replaced with $ffe1 (or $ffe4, don't remember at the moment), which works as a "GET", i.e. returns even if no key is pressed, and returns the PETSCII code directly, no need for shift/ctrl key handling. Or you can use $ffcf, which is the counterpart to $ffd2. It waits until a character is available and returns it then. On interactive mode on the screen it actually enables the full screen editor, when you press return, it reads the line where the cursor is into a buffer, converts it and allows you to read the character with further calls to $ffcf.

The kernel jump table is one of the really great things in the kernel, please use it if you don't have any compelling reason.

André

Right. The CBM kernel jump table has been part of their eight bit machines since inception. The jump table was Commodore's equivalent of what we would nowadays call the kernel API. All of the key subs referred to by André have the same entry addresses, regardless of which machine is being used. Direct jumps into the ROM instead of going through the jump table can result in bizarre behavior in some cases. For example, the C-128 was released with two different kernel ROMs during its lifetime, and some routines were relocated to allow inline patching of bugs. Direct jumps into the ROM could fail because a routine was no longer in the same place.

Direct ROM jumps were particularly a problem with Lt. Kernal systems due to the LK copying the kernel into shadow RAM and then changing some key routines to allow the LK DOS to intercept them. Diving right into the ROM (which was no longer ROM but write-protected RAM) usually was fatal (to the computer, not the user).

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

Nice, I never knew this... I do plan to use the Jump Tables, I definately see the usefulness of it! May have to get into the IRQ loop too.

So.... The 64 had an IRQ going active 60X/sec to monitor the keyboard, tape drive, and some other functions. I don't wish to have this load on my CPU.
You guys think it would be ok to use the IRQ that is generated on the PS2 Core, so the Kernal would only be bothered during keypresses?

You would miss that functionality that happens during interrupts.

Forget about the tape stuff, that only happens when a LOAD from or SAVE to tape or other tape I/O is triggered by the user or a program (then the interrupt vector is modified IIRC).

You would miss time keeping. I.e. the BASIC TI/TI$ variables. I've only seen that used in BASIC games, so you could probably ignore that as well.

Most important ;-) you'd miss the blinking cursor.

Can't think of anything else right now, so you'll probably be save with that (with the usual grain of salt...)

André

I re-rethought about putting the entire BASIC and KERNAL in the FPGA. I decided against it. If I could fit the entire 64K inside this FPGA AND if I had a 6510 core with separate IRQ and BRK interrupts, I would've given it a go. Wait you say, 'doesn't he have a 6510 core he used in the 6502-Core comparison thread?'. I do, but believe I would have to purchase a license in order to use it. Which I am not prepared to do. I noticed the core has been removed from their site with a notice to contact the author for a commercial license, so I'll respect their wishes and not tinker with it.

After alot of searching, I finally got the C-64 monitor program called Micromon onto the PC. Loaded it in MK's assembler and after a little bit of editing, I recompiled it back to a .bin file. Comparing it to the original, a few bytes were skewed for some reason, but only after the actual code at the end of the 4K. I'll have to investigate a little more to find out why.

Looking through the entire code, I found out it only uses 6 C64 Kernal routines: (The one in parentheses go through the jump table)

JMP $FFCF ($F157) ;input a character
JMP $FFD2 ($F1CA) ;output a character
JSR $FC93 ;restore default IRQ routine
JSR $FFE4 ($F13E) ;get a character
JSR $FFCC ($F333) ;restore default devices
JSR $F4A5 ;used to load RAM from a device
JSR $F5ED ;used to save RAM to a device

EDIT1: I also found a single routine called from the C64 Basic ROM.
JMP $BDCD :Output a line number

I don't think this is going to be too difficult to integrate into the 6502SoC, but these are the questions I have now:

Do these JMP's end with a BRK to send control back to wherever the BRK Vector is?
What's the difference between $FFCF and $FFE4?

EDIT: Added EDIT1 on 5/7/11

The JMPs return with a RTS. In your code, the only thing you do is something like

to output a character $65 ("a"). FFD2 actually preserves X and Y.

The difference between FFCF and FFE4 I have explained above (in a previous message in this thread)

André

Probably the monitor you analyzed "re-used" the RTS from FFD2 to not having to do

Optimizing this code results in a singe JMP $FFD2

André

That's nice to know! especially from the monitor's perspective, which is currently my angle right now...

The $FFD2 (Character Out) routine is pretty much straightforward. Shouldn't have a problem there...

I realized while tracing the $F157 (Character-In) Kernal code, how ready it is for variables to change during the interrupts...
I have always avoided IRQ's and NMI's in my old designs. I had, instead, always pushed for higher CPU speeds first and foremost, and then had a tight loop to monitor everything that needed to be controlled. And that is my intent here as well. Eventually all variables/routines used within Micromon that deal with interrupts will be stripped out.

I have possession of 2 6502 monitors now. Both found in binary form, and edited/compiled in MK's assembler in order to compare and contrast the coding and C64 Kernal usage. The first one is Micromon I've mentioned before. The second is Hashmon that I just found, purportedly a modified version of Hesmon.

Both are very nice assemblers/disassemblers made FOR a 6502 system ON a 6502 C64 system.

I've tested both images in VICE successfully. Also, for my own use, I've imported their code into MK's assembler. Then edited and compiled the code back into binary and compared against the original binaries. 99% matched, except where the data is present that represents the opcodes, towards the very end of code for both monitors. I think MK's assembler is trying to piece together code instead of a data string (for the opcodes)... I don't know. What I do know is 99% of these monitors are intact in MK's assembler...

Both are a few bytes shy of 4K, and a nice feature of both is that they have up & down scrolling. Say you want to disassemble $C000-$C040, they both will disassemble the code. Then, if you want to see assembly code before $C000, you move the cursor to the top of the screen and repeatedly push the cursor up to disassemble code before $C000...

One added feature of Hashmon is that upon startup, it asks you where to relocate itself. Of course you have to know if it will fit successfully within the C64 memory map before relocating, but it is a nice feature
I've tried successfully, on VICE C64 emulator, at $8000 and $C000.

The source code for Supermon is available on The Fridge.

Regards,
Mike

_________________
- Mike Naberezny (mike@naberezny.com) http://6502.org

Note that the Supermon posted at the Fridge is actually Supermon64, which was a C64-specific version of the original written for the PET/CBM computers. The original Supermon did not have an assembler or disassembler. Needless to say, Supermon64's assembler does not recognize any of the enhanced instructions of the 65C02. Owing to the way in which the assembly/disassembly tables have been organized, reworking Supermon64 to support the 65C02 would not be a trivial exercise.

Also, the code at the Fridge is not the original source code for Supermon64. Someone "Merlinized" it (that is, butchered it a bit to work with the somewhat strange Merlin assembler), making the source code partially incompatible with many 6502 assemblers. Supermon64 was developed with the Commodore MADS package, which was 100 percent compatible with the official MOS Technology assembly language standard.

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

This version isn't merlinised. (Described as "Jim Butterfield's SUPERMON source, alpha-quality port 20100806", from Chris Baird's sym-1 resources)

Cheers
Ed

Thanks Mike, BDD, and BigEd for your interest!

I knew the merlinized version was abit hacked to work with the 20MHz superCPU IIRC.

This is probably the monitor I will pursue because it has comments to help porting. Many thanks to Chris Baird's work in commenting Jim Butterfield's software, and BigEd for finding that original!

I was going to pursue it on the 6502SoC...

I am still going to pursue it, but for use in the 65Org16 dev board. Arlet's original 8-bit core can be used and dedicated for SuperMON64. Then a very simple translator program could make 65O16 code from that code and store it somewhere else in memory for the 65Org16 core. Then control the reset for the core to boot properly... The 65Org16 Development Board has this capability, although with multiple cores inside a single FPGA the top speeds will be lower. I have designed it wanting the greatest flexibility.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

I eventually plan to make my native mode 65C816 machine language monitor source code, which is fully commented and runs to about 6,000 lines, available to 6502.org. Right now, the monitor is sort of "welded" into the BIOS ROM of my POC design, but has been modularized to a point where it shouldn't be too tough to make it a standalone package. There are some I/O functions within that are necessarily system-dependent. However, when I'm ready to make it available I'll fully document these requirements, which any reasonably proficient programmer will be able to fulfill.

My plan is to put the source code together in a single large file (right now it's a bunch of INCLUDEs), assemble it on my development system and ship it over to the POC to run in RAM. This procedure will allow me to verify my handy-work and, it is hoped, save others the indignities of stray bugs. This project is steadily percolating toward the top of the "to do" pile. I do have few errata to track down, one of which has been obstinate.

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

That would be great! Look forward to it.
Cheers
Ed