Re: C-128 and Jeri board
Date: 2001-05-03 06:13:34

On Wed, 2 May 2001, john/lori wrote:

> > > 
> > > I'd go for a new motherboard as well, provided I can fit it into my C128
> > > Tower case ;-)
> > Hey bogax, How about submitting our ideas? :)
> I have no objection, I think I'd like to hear them myself :)
> I'd just point out that, at this point it's all talk
> (unless you've gotten a lot farther than I have)
> Presumably they all know what talk is worth.
> The idea is, basically, a baby AT form mother board to take
> the chips from a C64, with the idea of moving to bigger and
> better things eventually, and including some enhancements.
> enhancements that would be included intially would be:
> 16 bit ISA bus
> multiple cartridge ports
> integrated expansion RAM
> seperate RAM for the VIC
> some sort of fast "serial" bus (ie something to serve the same
>  function as the C64 serial bus, but faster, this would be in
>  addition to or an enhancement of the serial bus)(Nate favors SCSI)
> bigger and better things would be stuff like:
> VIC compatible VGA (I don't envision anything as elaborate as what
>  Jeri's doing, I'd prefer 800x600 but I'd settle for 640x480 with
>  256 colors)
> 16 bit CPU (jbev wants 65816, no doubt that would be easiest,
>  but I'm ambivalent.  I'm not interested in getting tied to
>  proprietary hardware)
> Everything in programmable logic
> So jbev, what did I leave out?

I dont believe too much was left out.  I'd like to add a note that an REC
would be included, supporting up to 16M of its own ram.  There was also
speculation about different speeds of I/O devices, marked by page in a
control register.  This would allow a 14mhz device to share the bus with a
1mhz device without problems.  The REC for example would run at a swift
14mhz.  Bogax and I also covered some memory protection and opcode
protection hardware, which on my end was geared mostly for the 65816's abort

Further wishing included a fully remapping MMU, allowing a larger (32bit in
the 816's case) memory area to be mapped in, 4k at a time, to the 24bit
address space of the 65816.  This eliminates the concept of memory
fragmentation, a common problem on the amiga and classic mac, and a
potential issue on the scpu.

> I'll just speculate breifly on RAM expansion (since that's what
> I've been thinking about just recently).
> Initially I had thought to start with an 8 bit to 16 bit memory
> mapper in discrete logic.  This would be something that could
> be pieced together out of junk (mostly) (stuff from a couple
> of old mother boards) and fit the cartridge port on the C64
> Basically using UMAX to map in memory upto 16 meg in 256 byte
> pages with a rudimentary DMA capability for swapping the bottom
> 4K (mostly for zero page and the stack, probably no more than
> 256 bytes at a time)

Oops.. I should have read before I posted ;)

> Mapping would be done with 32K cache chips, and allow you to
> map the maps ie you set up a bunch of 56K maps (64K minus
> the bottom 4K and IO) and then select maps with a single byte.

 ..allowing you to switch memory maps (one each for up to 255 separate
prcesses plus one more for the kernEl) with sub-microsecond speeds. 
Multitask, protect, the works.

> DMA would use a single presettable 8 bit bi directional counter
> that stopped on roll over.
> Initially it would only support 4 and 8 meg 72 pin simms
> Later the scheme would be integrated with a full blown REU
> compatible, 16MB DMA capability (jbev wants multi gigabytes
> and memory protection) and incorprated on the new mother board
> (at which point DMA for swapping zero page becomes moot)

muahaha >:-)

> Now I'm wondering if it doesn't make more sense just to go
> straight to an integrated mapper and REU style DMA controller,
> in CPLDs.

My thoughts.  However, given Watson's repeated failures to get the CIA to
fit in the larger xilinx cpld, it might be tough to fit all this in one IC.

> I'm also wondering what the unused spots in the memory map
> (those locations in the SRAM that correspond to the bottom
> 4K and IO) could be used for. (DMA reload registers comes
> to mind)

Map the 4k into a shadow rom where you can load character sets to replace
the onboard ROM.  I've always been a fan of using the vic20 characters on my
beloved 64.  The c64's chars look kinda crappy and low-rez to me, while the
vic20's are refined, thin, and light.

> Also trying to decide how to fit in gobs of IO in the most
> compatible way possible.

Sadly, Commodore never intended on more than one device being in the cart
port at once.

> A discrete version of the mapper would take 40-50sq" of board
> and a lot of soldering and wouldn't do much in the way of
> usefull DMA. Any savings from using junk would be offset by
> the additional cost of the board, if nothing else, but junk
> is more accessable.  

> Plus I think you could fit in fast memory to memory DMA in the
> expansion memory (eg 32 bits wide at the dotclk rate)
> Besides, Watson wants an REC done NOW ;)

and NOW someone tells me.  Where's the ol' boy hanging out anyway (reply in

> bogax

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

Archive generated by hypermail 2.1.1.