Re: Hardware emulation of 6509 using 6502?

Den Tue, 24 Jul 2018 06:21:16 +0100 skrev smf <smf@null.net>:
> 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.

Sound would be hard anyways. In theory you could remap the PET sound
I/O pin to the volume control register of the SID if it happens to use
the right bits.

But who did use joysticks on a PET? I've never heard of that.

> You could redirect peeks/pokes in basic, but machine code would
> require hardware redirection.
> 
> I'm not sure how important monitor frequency is.

Well, as there is only one setting of the 6545/6845 that right for a
given monitor it might be best to not expose those registers to old PET
programs.

> > 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
> 
> http://www.zimmers.net/cbmpics/cbm/PETx/petmem.txt
> > 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.

Basic won't use pokes to 0/1 unless it also contains machine code
programs.

> > 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.

... or just just a PET as it is. The point of my suggestion is to be
able to run existing PET programs without modification.

We can't be 100% sure but it's really really likely that all sorts of
"business" software use kernal for reading the keyboard, and it's
likely that the simple games do that too.

As there were no need for fast loaders, we can be almost 100% sure that
the kernal is used for disk and printer I/O.

But we can also be almost 100% sure that many programs write to the
screen memory directly. Therefore I suggest a method of just remapping
the screen but let the rest of the memory space be ram, and load a
patched kernal+basic in the right place and then most PET programs will
probably run.

> 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.

A VIC-20 emulator for C64 would imho be rather useless as you can't
emulate anything near how the display hardware works. If it were
possible to set VIC-II to a variable amount of chars per line it could
work better though.


-- 
(\_/) Copy the bunny to your mails to help
(O.o) him achieve world domination.
(> <) Come join the dark side.
/_|_\ We have cookies.