Date   : Sat, 24 Jan 2004 15:01:04 +0000
From   : Richard Gellman <splodge@...>
Subject: Re: BBC Hard Drive Package Update

Sprow wrote:

>>P.S. "any part of memory" -- what devices have IO addresses outside 
>>the 0xFC00-0xFEFF area?
>>    
>>
>
>Sideways RAM upgrades? Shadow screen memory upgrades?
>The latter often used the fact that the 6502 PC was in a top bit set address
>as a prompt to page in the shadow screen - much like the Master which paged
>it in automatically based on the VDU code being in a fixed region in ROM,
>Sprow.
>  
>
Sorta.

The Master 128's screen memory is actually done using 3 bits in ACCCON 
(ACCess CONtrol) at FE34. These bits are in fact directly set by *FX 
108, 112, and 113.

One bit is the VDU access bit, and writes to a control line used as a 
bank selector, which is in turn only enabled when the CRTCMUX select the 
6845. The other two bits are used when the CRTCMUX is on the side of the 
6502, and work somewhat strangely.

One bit is actually semi automatic, and works on the premise that when 
enabled accesses to the screen will be redirected to the shadow RAM only 
if the last instruction address (latched by one of the status lines on 
the 6502) is in the C000-DFFF range, where the VDU routines lie.

The remaining bit is a straight "enable to access shadow ram" bit. This 
bit override the previous bit, and states that all access will go to 
shadow ram (if enabled. If disabled, accesses follow the rules of the 
previous bit).

In response to the "what other areas of memory?" question, my thoughts 
were that since hardware would be able to choose which memory addresses 
it can latch onto between FC00 and FEFF, Ithought there should be no 
reason why they cant use the whole address space. Checking a list of 
attached areas to see if a byte should be redirected to a plugin 
wouldn't take a great deal of time.

One of the things I thought of was 32k ROM images that sit in 16k slots. 
I seem to remember something about InterWord using a latch at one of the 
ROM addresses to switch between "halves", thus making them extremely 
difficult to copy. Being able to access memory in this way would permit 
such a ROM to run.

Meanwhile, does anyone fancy writing a plugin to emulate the Prism 3? :)

-- Richard Gellman