> I have been working on a couple of different RAM carts over the past couple
> of years. The latest version supports 2K, 4K, 8K (F8), 12K (FA), 16K (F6),
> as well as the SuperChip and RamPlus. It's called the "HappyCart" - I know
> that there was mention of it on this list quite some time ago (I caught it
> in the archive when I did a "reverse" Lycos search - I've been lurking on
> the list for a couple of weeks since..).
This is cool. I wandered past your old page a year or so ago, but didn't
know that you where still working on it.
> http://www.retrocomputing.org/
I must say, I am very impressed with how far you have taken this. The PC
GUI program is quite impressive, and could make for a very nice product.
You don't think that you would be able to sell it then? Besides that
humorous email, have you gotten many/any serious requests for purchase,
even at the >100$ price tag?
> Feel free to shoot any questions to the list and I'd be glad to answer them.
It seems from your pages that your backgroud is in EE as well, so if
no-one else on the list minds some indepth questions, I would like to take
you up on that.
How would you discribe your overall architecture? By this I am asking
about a high level block.
Is it basically: switching chip which handles nothing but address, and a
programming chip?
-------------------
atari Addr ------------------>|bankswitchingchip|
| -------------------
| |(high)
|(Addr) |(Addr)
V V
-------------------
atari Data<----------->| RAM |
^ -------------------
|(data) ^
| |(control)
---------- |
Parallelport<--->|portchip|-----|
----------
Or does your logic sit inbetween the atari and the RAM?
-------------------
atari Addr --------->|bankswitchingchip|
-------------------
| |(high)
|(Addr) |(Addr)
V V
--------------------
| RAM |
--------------------
^ ^
|(data) |
| |(control)
------------
atari Data<----->| |
Parallelport<--->| portchip |
------------
Clearly there has to be some 'glue' connections between the two chips in
the above.
Or something entirely different?
The reason I ask, and the reason I bring it all up is because of what I
was thinking about. At a chips level, I'm thinking along these lines:
--------------
Atari Addr----->| CPLD/ | ------------------
Atari Data<---->| FPGA |<-------->| PC interface |
-------------- ------------------
^ |
|(Data) |(Addr)
V V
-------------
| RAM |
-------------
The clear disadvantage is the shear number connections needing to be
made.(50-60) The main advantage is in flexability. Biggest is that this
allows implementation of Pitfall2. My goal was in the creation of a
supercharger-like device, for the normal user that would allow substantial
technilogical improvements in new games. Thanks to ideas from Crane's
pitfall 2 chip, I've come up with an extremely flexable, and powerfull
hardware backbone for future games. I've worked through some of the
details with John Harvey, and pretty much figured out how we would create
a 2600 version of archeniod(sp?). This would include all the features of
the Nintendo version, which I don't believe is possible on a 2600 w/o
extra hardware. A side inclusion would be addition of RS232 or generic
I/O port for programmers use, thereby allowing local networking, or modem
dialling, or the use of 4 or more joysticks. Or if the PC connection is
left, then the program could support multiple loads.
Do you really support Pitfall II? I note that you have it labeled as
simple F8 switching, which it is not.(It is switching, i'd believe F8, but
with the entire DPC graphics and logic as well) Did you implement the
entire graphics lookups(data fetchers according to Crane, or indirect
addressing) in your switching chip? I don't see a crystal, does the CPLD
have one on it, or do you generate it from the Data/Addr lines?
How do you run your parallel port logic? Crystal, clock in CPLD, or does
it run off of a parallel port clock pin?
The last(so far only) RAM cart I made(a long while back), was only a 4k
version, and had no PLD. Further it supported the printer protocal. By
this I mean that you could load it with the simple DOS command:
copy /b filename.bin lpt1
(/b to force a binary copy, it will fail otherwise). I had used the
strobe line to clock in the data and increment address counters.
Did you implement extended hardware features that programmers could use?
For instance, like being able to write data out of the cart to the
parallel port interface for communcation w/ the PC? Does your
architecture allow this?
Do you have much space left inside your CPLD's, or have you pretty much
maxed them with the switching/loading logic?
Are you still working on this?
Mark
--
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
