Re: Switchless ROMs

All are very good points.  I even momentarily considered counting any
transition on any address bit but that would be triggered by DMA refresh.
What an interesting challenge!

Pardon my ignorance if this has been brought up, but have we considered
using a method similar to a no-slot clock chip?  They use a sort of serial
interface where two address lines provide a clock and data in, and a data
bit provides a data out.  /cs enables the serial interface state machine so
that the processor can run code outside of the rom without resetting the
overall machine.

As I remember, the smartwatch IC uses a 64-bit key that must be shifted in
to enable the device, after which it's basically a SPI style I/O device.
If we're not interested in data feedback for just changing banks up, it
would be possible to do this with just a few input lines (/cs, a2, a6 or
some other arbitrary address bits).

With that configuration, the bank could be switched by clocking the key in,
and then the new bank address.  At that point the state machine would go
back offline.  The key and address bits would be carefully chosen to make
the chance of spurious activation incredibly small.

-David

On Thu, Dec 29, 2016 at 4:57 AM, <silverdr@wfmh.org.pl> wrote:

>
> > On 2016-12-28, at 23:19, Jim Brain <brain@jbrain.com> wrote:
> >
> > On 12/28/2016 12:20 PM, smf wrote:
> >> On 28/12/2016 17:34, Jim Brain wrote:
> >>>
> >>> access $fffd (jmp)
> >>> <lots of time elapses for VIC badline>
> >>> access $fffd (low byte of vector)
> >>
> >> How do you tell between <lots of time elapses for VIC badline> and
> >>
> >> access $fffd
> >> <lots of time elapses when CPU only accesses RAM>
> >> access $fffc
> > Not sure you do.  Would ther be an issue in not worrying about it?
>
> If we want to keep compatibility - I am afraid the answer is "yes". A
> simple example: a program uses the RAM area under KERNAL as a temporary
> storage and reads from the consecutive addresses there. I know for a fact
> that such programs exist. So you would need to monitor the configuration
> bits or the _CS or ... The next example is copying KERNAL from ROM to RAM -
> lots of programs to this in order to modify a few things in the KERNAL.
> Here monitoring the _CS won't help as the program reads from ROM locations
> and you know what happens when you don't differentiate between the _RST
> induced reads and the same done by the program.
>
> --
> SD!
>
>
>        Message was sent through the cbm-hackers mailing list
>


       Message was sent through the cbm-hackers mailing list