The range $DE00-$DFFF is available at the C-64's cartridge port for what you want to do. You assert /IO1 to map into $DE00-DEFF or /IO2 to map into $DF00-$DFFF (also applies to the C-128 in native or C-64 mode). Since you most likely won't be using the fake RS-232 kernel routines, you could enlist CIA #2 ($DD00) to act as a communications controller. However, it would probably be not much more difficult to place some sort of bi-directional bus transceiver on the '816 board to handle the DMA stuff. Take a look at a 74xx245.

Actually, it's not easy unless the two machines are phase-locked to each other (and, even then, you still need synchronization logic). Otherwise, you're essentially implementing a 4-phase asynchronous bus interface for both sides, plus bus arbitration logic in between them.

It's better to use some deep FIFOs, but they're pretty rare. So, with the Kestrel-1, I implemented a DMA interface using 74ACT595 shift registers. To work with the Commodore 64, you'd replace the shift registers with parallel registers.

However, even here, you still need:

(1) A means to synchronize the 6510A against the 65816's clock, which even if running at the same speed, may well be out of phase. (And, were I building this, you can bet I'll be driving the 65816 at 16MHz or faster.) A 4-phase asynchronous interface is ideal.

(2) A means to let the 65816 interrupt the 6510A unambiguously. (Relatively easy)

(3) A means for the 6510A to trigger an interrupt on the 65816.

(2) and (3) are used to establish communications between the two computers. (1) is needed to not blow either side up doing so.

This is an issue I've run into when initially considering designs for my Kestrel-2 computer. In subsequent designs, I've dropped the asynchronous bus design and instead am phase-locking the VGA and CPU (which means the CPU runs at 12.6MHz -- period. No means of up- or down-grading the speed).

The 6510's 1 MHz Ø2 clock is present at the 64's cartridge port, so why not run both processors from the same clock. If you want to run the '816 faster, you should be able to use the C-64's Ø2 clock to trigger a clock generator circuit on your external board that runs at some multiple of the 64's clock (which is 1 MHz on the 128 whether in slow or fast mode). This should take care of your phase concerns.



Simple logic on your external board can assert /IRQ or /NMI, both being present at the cartridge port, assuming you want an interrupt. Or you can assert the 6510's /RDY line and tri-state the buses so the '816 can take control.



You'd need something on the '816 board mapped into C-64 I/O space at a particular address that when written would ultimately toggle the '816 IRQ line for at least one clock pulse. Since writes on the 64 I/O space are always synced to the 1 MHz Ø2 clock, the effect of the write should persist long enough to gate your IRQ circuitry on the '816 side.

It sounds as though you're heading in the general direction that was taken with CMD's SuperCPU cartridge.

Well, there's only one way to really do this sort of thing correctly, so it doesn't surprise me.

OTOH, this all would require me to acquire a C64 or C128 again (probably I'd get the 128, because it just doesn't get the love it deserves). I doubt that will be occurring any time too soon due to space limitations. Besides, the Kestrel-2 is my current 65816 project, and I already have a software emulation of the machine running on my Linux box.

I just can't seem to get around to writing the system software for it.

The hardware aspects of connecting anything to the 64's or 128's cartridge port are pretty rigid, although all address and data lines are present. You could, in theory, map a piece of hardware into memory anywhere you want, but in practice bus conflicts between the port itself and RAM would arise. That's why /IO1 and /IO2 exist. Otherwise, decoding and bus arbitration would become a nightmare.


Not to mention the paucity of 128s in reasonable condition.


When do you plan to turn it into real hardware?

Good question. As I work on it only in my spare time, and only after higher-priority projects complete, it could well be never.

I know of 2 C64 lisps (micro lisp and lisp 64), neither of which have source.

One of the links mentioned earlier http://www.hugbox.org/lisp8/
gives source it seems.


http://www.1541ultimate.net/content/index.php in the next version is rumored to have '816 functionality. Yet with an fpga, you might as well implement a lispmachine in vhdl

As for cross assembling w/ 2 C64s, it would be much easier to use an SD card interface like the above 1541U (expensive) or the uIEC (cheap - check http://groups.google.com/group/uIEC-users for availability, usually ~$50).

Thanks for all the cool links guys!

micro lisp
http://cbm.csbruce.com/~csbruce/cbm/transactor/disks/disk-23.html

lisp 64
http://www.c64-online.com/phpbb/downloads.php?view=detail&df_id=163

You may also want to check comp.sys.cbm and csdb forum for advice.

Good luck!

You can also look for Oric Lisp. Oric was a European 6502 computer.

another lisp for C64:

LIMP (Lisp Interpreter written in ML and Promal) D64 image (with docs)

http://www.lyonlabs.org/commodore/onrequest/limp.d64

"Jecel Assumpcao Jr." posted on the FONC mailing list about PICOBIT (non-native LISP for micros) and also aboutPDP-1 LISP:

Yay, Lisp!

One idea I had about the type tags was a compromise between the two (24-bit elements vs static memory ranges). Each page in memory would hold one type of entry. The type could either be stored in $xx00 on the pages that are used, or in a static table $KKxx. I haven't implemented it, but it is more dynamic than the fixed ranges, if you allow the system to dynamically allocate pages as needed.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

This looks interesting. Does anyone know where I can find documentation for it?

Out of random curiosity, what's the status of this project now?