From: Jim Brain (brain_at_jbrain.com)
Date: 2008-11-07 18:05:24
ruud.baltissen@apg.nl wrote:
> Hallo Jim,
>
>
>
>> On powerup, an onboard uC will ....
>>
>
> If you allow me to add an idea: why not monitoring the RESET line?
> Otherwise I have to power-cycle the C= every time I want to change the
> image. A reset is more friendly for the electronics.
>
I'm not sure how that is different from:
"On powerup, an onboard uC will isolate the RAM from the bus, holding
the target machine in a RESET state, and load an image into the RAM from
a small 4MB Flash ROM or an SD card. When finished, the RAM will be
connected to the bus and the RESET line de-asserted."
> With all respect, what is the added value for the average user? How many
> kernals will someone use? I myself use three, which fit in one 27256. A
> 27512 can contain up to eight. A small trick allows you to use a
> 27256/27512 in a C128 having 3/7 kernals at your disposal. Only some
> dipswitches are needed to choose the wanted Kernal.
>
To the average user, it would provide a way to buy a solution for
orphaned disk speeders without putting the manufacturer in a legal
bind. As well, no offense to those on this list, but most folks don't
own an EPROM programmer. My initial thought for this project was the
BehrBonz/MegaCart game cart projects. I thought it would be better to
build an MMC64-like solution for that use, rather than stuff everything
into an EPROM as in those projects. But, as I got to looking at the
required components, I thought I might have a chance to build it all in
a 28 pin EPROM footprint, meaning that other uses (and other platforms)
were targets, increasing the viability of the project.
> For developers it certainly has a value: the device can be used to
> develop new kernals, games or whatever. But then IMHO a SD-card should
> be used; extracting and refitting a FlashROM every time has it risks.
> (FYI: I put a textool socket in my 1541 to be able to test new kernals
> for the harddisk project)
>
I've had pushback on using SD for the kernal-ROM usage, since folks
would probably not have that many kernals and the removability is not
that desirable. It's OK, because the design can accomodate either a
small FlashROM or an SD card. Developers could buy the sd variant,
while normal users can buy the Flash version. The flash version would
be in-circuit programmable, so no removal would be needed.
> Yet another thing to think about: some cartridges use I/O for disabling
> itself on command, changing the EPROM etc. If VICE can handle this using
> CRT files, what about your device?
>
Since this unit replaces an EPROM, it can only do what an EPROM can do.
If the cart needs to bank itself out and does so via some latch on the
cart board, then a cart board with such a latch would be needed.
>
> If you allow me to add another idea: what about adding a kind of
> communication port, like USB or RS-232? In this way you can upload the
> needed software into your RAM/FlashROM using a PC or other device.
> Having developing in my mind, it is even quicker then exchanging
> SD-cards IMHO.
>
No more IO. If I go to the next larger uC with more IO pins, it's too
large for the footprint. But, as noted above, the goal is to allow
programming in circuit.
Jim
--
Jim Brain, Brain Innovations (X)
brain@jbrain.com
Dabbling in WWW, Embedded Systems, Old CBM computers, and Good Times!
Home: http://www.jbrain.com
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.