[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Redesigning a new PROM for //e and //c hardware

Subject: Re: Redesigning a new PROM for //e and //c hardware
From: Steven Hirsch <snhirsch@gmail.com>
Date: Mon, 05 Nov 2012 18:24:16 -0500
In-reply-to: <ba4fe8dc-0500-4850-86b6-9be5e6420e79@googlegroups.com>
Newsgroups: comp.sys.apple2
References: <benoit0123-1352118213@macgui.com> <k78lub$u5s$1@news.xmission.com> <ba4fe8dc-0500-4850-86b6-9be5e6420e79@googlegroups.com>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2

On 11/05/2012 11:06 AM, BLuRry wrote:


Seems it is virtually identical to a 65816 minus the bank-address byte.
Since the 65c02 used in the //e didn't have the SC bit-operator opcodes
(bbr and so on) dropping in a 65802 shouldn't make any difference to any of
the software.  (note: Jace emulates the SC opcodes... just in case. ;-)

I used MVP for faster 80-col text scrolling in the CardZ180 host BIOS. Itmade a small but noticeable difference from a simple loop.

References:
- Redesigning a new PROM for //e and //c hardware
  - From: Benoit0123 <bgilon@free.fr>
- Re: Redesigning a new PROM for //e and //c hardware
  - From: Egan Ford <datajerk@gmail.com>
- Re: Redesigning a new PROM for //e and //c hardware
  - From: BLuRry <brendan.robert@gmail.com>

Prev by Date: Re: TransWarp GS repair questions
Next by Date: "Tribute", a new section on brutaldeluxe.fr
Previous by thread: Re: Redesigning a new PROM for //e and //c hardware
Next by thread: Re: Redesigning a new PROM for //e and //c hardware
Index(es):
- Date
- Thread