Re: Hardware emulation of 6509 using 6502?

From: Mia Magnusson <mia_at_plea.se>
Date: Wed, 7 Mar 2018 17:52:47 +0100
Message-ID: <20180307175247.00005d58@plea.se>
Den Wed, 7 Mar 2018 16:31:41 +0000 skrev smf <smf@null.net>:
> On 07/03/2018 16:23, Mia Magnusson wrote:
> 
> > Is it just as simple as screen + color ram is read in the "CPU"
> > phase of the clock cycle ("bad line" in C64 lingo), and char data /
> > bitmap data and sprite data is read during the "VIC" phase of the
> > clock cycle?
> I believe so. VIC is quite predictable.
> > I really don't understand why there is a need to split theese cycles
> > though.
> 
> The designer thought it was a neat solution at the time?

Maybe it actually is! This way you can have screen ram and char rom at
the same VIC-II addresses :)

But this is no answer to why they used a chunk of SRAM. They could have
done the same thing by mapping part of the DRAM in the $C000 space in
bank 15.

> They needed to be able to differentiate character generator rom and 
> screen fetches. The c64 does it with magic addresses, which is quite 
> limiting itself.

Yeah, and in the C64 it's even worse by the choice of the memory map.
If the character rom were mapped for VIC in the same place as I/O and
char rom for the CPU, they could have used 49152 and onwards for screen
ram and had another 1k free for basic. (Also they could have changed
the memory map so the 4k ram hole at 49152 were filled with half of the
basic rom, leaving 4k ram from $A000 onwards, giving 4k extra basic
ram). Also it would had been good if they had made the default setup
having screen ram in the top of basic ram, not bottom, making it easier
to move around / expand / shrink graphics memory from basic, and also
getting a memory map slightly more like the PET.

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

       Message was sent through the cbm-hackers mailing list
Received on 2018-03-07 18:06:40

Archive generated by hypermail 2.2.0.