Re: Jeri board and extra things
Date: 2001-05-03 05:35:57

On Wed, 2 May 2001, Professor Dredd wrote:

> Okay Ruud,
> --- Ruud Baltissen <> wrote:
> > If one can reprogram his PC's FLASH-BIOS, it cannot
> > be so difficult to add
> > this feature to our new design as well.
> > On the other hand I like the suggested idea of
> > loading the KERNAL in SRAM
> > but not from EPROM but from disk like an OS. Even a
> > combination should be
> > possible.
> He're what I had in mind. At power up the entire
> KERNAL is copied from a ROM into RAM. Then patches are
> loaded from a special RAM area that is not part of the
> main map and is not succeptible to power loss.

Or, given you'll have high speed storage online, load patches according to a
list stored on your 'boot' media into (far) cheaper (S/D)RAM.

> The special RAM should be outside the main memory map
> in the same way C-128 VDC RAM is. It could be made

UHS will (hopefully) be able to bank blocks of its external ram in at the
game rom and basic rom spaces.  This will leave them accessible even when
the scpu's online - iirc, the only thing you cant override is the kernal. 
Of course, if you cant bank it in, you can still DMA to/from it. ;)

> "power-safe" a number of ways like (just off the top
> of my head":
> battery-backup like in Apple IIgs

The IIgs stores its PRAM data in a (small) ram onboard a CMOS clock.  Note
taht my IIgs has a dead "pram" battery, and in so always forgets the time
and settings :/

> NOVRAM like in modems
> FlashROM like in PC BIOS
> That is what I mean by PRAM and I am not sure what
> technology would be best suited for such a design.
> Whatever technology is used, here is the type of thing
> the PRAM will be used for:
> custom key matrix

64 keys, plus restore.  65 entries, mapped to 104 keys.  Have you considered
special functions mappable to the keyboard, since all those extra keys are

> system clock

This has CMOS clock written all over it ;)

> user customizeable KERNAL patches

You'll need a potentially large chunk of memory for my patches.

> Another good thing to put there would be system I/O
> configurations defaults. For instance, what if you
> want to address a second SID chip at $DE00, but you
> already have Turbo 232 registers mapped there? Suppose
> you could map them both there and select between the
> two with a softswitch? Then, you'll need someplace to
> store your user-defined default configuration so the
> KERNAL can set the softswitches on powerup.

now THIS I find to be a GREAT idea!  I've devised a (somewhat complex) PnP
system, which will allow one to move UHS around in the I/O map.  This
assumes, of course, that the spaces you map it to are valid and decoded.. 
Depending on luck, I might be able to pull some fancy cart port trickery to
put UHS any place above $1000, overriding what would normally be there.

> Just an idea. I have no clue how it might be done.

You've got some great ideas here.  I can see them useful in any system.

A note needs to be made, however, that the IDE64 crew have already made a
(nonremappable) pc-keyb->c64matrix encoder.  It consists of a PIC and a 12x8
crosspoint switch.  The microcontroller reads the PC keyboard, and
opens/closes connections on the crosspoint, which is hooked to the
row/column lines on the keyboard port.

This message was sent through the cbm-hackers mailing list.
To unsubscribe: echo unsubscribe | mail

Archive generated by hypermail 2.1.1.