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