Re: Hardware emulation of 6509 using 6502?

From: smf <>
Date: Tue, 24 Jul 2018 06:21:16 +0100
Message-ID: <>
On 23/07/2018 21:53, Mia Magnusson wrote:
> Since the keyboard has another mapping than a PET, and since the B uses
> triports and a CIA while the PET uses two PIO's and one VIA, and since
> the monitors uses different frequencies, I see little reason to make the
> I/O visible to any non-aware software.

Keyboard scanning will be handled by the kernel, but joystick & sound 
are handled by the application.

You could redirect peeks/pokes in basic, but machine code would require 
hardware redirection.

I'm not sure how important monitor frequency is.

> However the bank registers at $0/$1 might cause trouble since a PET
> uses those addresses for other purposes. IIRC they are the basic USR
> vector (at least they are on the VIC 20), so you might get away with
> having the registers there for most of the time.

Yes it seems they are used for that
> I realize that my attempt at feature creeping is getting a bit out of
> hand, as it would also ideally remap the $0/$1 registers to another
> more "safe" location. Somewhere in the PET I/O area that's unlikely to
> get written to.

You could try to remap 00/01 pokes from basic and patch basic so it uses 
the new address, but there is no unused zero page to put them.

Machine code programs will again cause a problem.

> I'm not sure if my idea is any good, but if it won't add any noticeable
> cost to the final product it might aswell be added. I'm not sure who
> might be prepared to patch a PET kernal for this though.

Possibly a better idea would be to just get a PET and come up with a way 
to stick a 65816 in it.

If you are ok with supporting basic programs and less support for 
machine code then you can remap the basic peek/poke to screen memory & 
joysticks in software & throw an error if anything uses $0/$1.

I think there was a vic20 emulator for the c64 that worked like that.
Received on 2018-07-24 08:00:04

Archive generated by hypermail 2.2.0.