> > > o EPROM enable switch.
> > Where is the original PROM ?
> Since I never used it (an 82S123), I'm not certain. It seems to map into
> $0000 - $001F on the original Elf when the PROM switch is set to enable.
> > Use a part of the EPROM constantly maped at $0000 or add an
> > 1824 32x8 RAM ?
>
> I don't get this.
The idea is to map a part of the EPROM permanently to $0000-$001F
as replacemet for the original prom, or to suply a 32x8 RAM (like the
1824, since we want to use as much 'original' Harris stuff as possible
> > > o Circuit to ghost EPROM at $0000 until first address access at $8000
> > I still would go for a better decoding - just the high bit is to short.
> > Maybe there are some spare gates to use ?
> Wait a minute. We have been having an extensive offline conversation
> and you said that 32K of RAM and 32K of ROM is enough. It can be more or less
> of either, at a cost of gates and complexity.
Yep, but AFAIR I never taked about the starting address - my fault.
I assumed a varable starting adress.
> Going over the Quest design, I managed to eliminate a 4049 by redesigning
> the PROM area - the original used several inverters and NANDs to decode A6-A8.
:)) That sounds like fun
> > And I still would like to combine the shadow and boot option.
> If I did not convey that properly, I'm sorry. Yes, the boot option
> is always there because it's software. The hardware echoes the ROM at
> $0000 and $8000 when the PROM enable switch is on, and the act of reading
> a valid ROM address (high memory) resets the flip flop, restoring the
> more normal RAM at $0000 and ROM at $8000. If you make the first two
> instructions INP 4 and PHI 0 (your suggestion), you get the ROM bank select
> feature that you originally proposed.
Ahh ok. Hmm so if we want to use the 'switch-boot' a RAM based function
can never be used ? or do you only map the first 256 (or less) bytes of the
EPROM to $0000 ?
> > > o Sockets for two 1822/2101 256x4 SRAMs, the same style used by
> > > the original Elf.
> > Esential to be as close as possible to the original design.
> One vote for, several against or abstaining.
Adding two sockets wouldnt be a big thing I guess, but one could build
a system with only the 256 Bytes of storage :)
> > > o A 1851 programmable input/output port -or- a pair of 4508 latches
> > > wired as one input and one output port (as in the COSMAC VIP)
> > I would go for two 1852 Ports. They use only one adress each.
> I'm not inclined to do dual 1852's. We you and I have discussed, the 1851
> uses three ports, the switch/display is another port, leaving three left
> over. While ports are scarce, they are no so scarce as to overshadow the
> benefits of a bit-programmable I/O port.
> The space taken up by two 40 pin chips is a bit much when I can implement
> two cheap ports (one in and one out) with octal latches.
You're right.
What about adding a latched solution for all parallel ports like mentioned in
one of the App notes (I think it was with one of the latches).
> > > o A 1854 UART
> > Data transfer via Q is way more fun (Hi Alison :).
> > And since we don't need high speed transfer (2400 is ridicoulous i
> > we can do 110 :) a complete software solution is a great thing to do.
> I have no problems in principle with a software UART, but I do have
> something to say about the speed. 2400 baud is *not* a ridiculous
> speed, especially if you want to talk to an external device that has
> a fixed clock, say, a serial-to-LCD board.
Serious, this was inteded as a joke - Even with software controll
2400 Bd should be no problem at all - and for the LCD, I would realy
like to use one of these ASCII input LCDs
> The other issue with a
> software UART is timing. If you use a hardware UART, it needs a
> crystal of a particular frequency, but the CPU does not. You can then
> "clock chip" the 1802 up (to use a Mac term) and not recode your serial
> routines.
Right.
> > > o Either a dual 4042 address latch or a single 4508 latch. One or
> > > the other is needed to implement more than 256 bytes of memory.
> > > This would be optional in a machine built with dual-256x4 SRAMs.
> > Isn't there already a fiting latch in the 18xx family ? (1883 ??)
> The 1883 is a *7* bit latch with built-in decoders. We need no decoder
> because the low 15 bits of the full address bus are going to each the
> ROM and RAM sockets. There are no individual memory chips to select.
> The 1883 is a great chip if you want to use several 6116's, for example.
Shure, again right. I mixed up two ideas I had.
Anyway, if we use your 32K RAM plus 32K ROM design, I thougt
about adding a kind of CS unit to provide several CS signals for adding
various memory or memory maped areas. For example if we supply
8 CS lines for 8 8K areas, one could bild a system like:
2K EPROM at $8000 (needed to perform the 'boot') and
256 Bytes RAM at $2000 and a memory maped
1851 at $4000 ... or some other configurations.
> > I would prefer 18xx chips prior to all others.
> I'm willing to consider 18xx chips, but they are each several dollars,
> while CMOS 4xxx chips are under a buck each, even in small quantities.
My view of the Elf99 is more fun and hobby than real applications.
Playing with unusual components and using 'real' 18xx stuff is
part of this flair. A 4xxx based I/O is just less 'sexy' than a 185x.
Its like with some of our vintage equipment - connecting a Terminal
to an Altair gives a diferent feeling than to any 12 MHz 64180 system,
even when running the same CP/M and the same Wordstar...
> > But maybe space for two (or better four) 1855 MDU. Playing with such
> > a beast is suposed to be a lot of fun. The same might be true for a
> > 1879 RTC. These parts are still available.
> I still have yet to hear why the 1855 Multiply/Divide Unit is worth
> the real estate. Sure, it's a neat chip, but unless it has a purpose,
> I can't see including it.
Gee the purpose is to multiply and divide - what else :-)
If you just think about the real world usability of an Elf99,
we shold stop it and go for a 80188 design of an equal
level (I like the 8018x CPUs)-
> The 1879 Real Time Clock might be neat, but certainly an optional part.
Even when only thinking about real world apps, a RTC is
essentoil for a lot of controll or household things (just try
to count all devices in your home that utilizes a clock,
visible or not - from microwave to VCR ...).
And for both chips (MDU and RTC), I don't want them to
be esential - just optional. And I think they offer a lot
of possible usages (what about a Elf Basic using the MDU
for speed ?).
(BTW: Just look at the 'front panel' thread - a MDU would offer
a lot of new and excitieing lights :)
> > Also I would like to have an additional 1852 (i/o selectable via
> > switch - but I only need output) to add an LCD display.
> > There are some real cheap displays available with a paralell ASCII
> > input - less than 25 USD for 16x2 characters.
> I have several. BG Micro and other places sell used 20x4 and 16x2 modules
> for $2 to $7. I must say that I hadn't considered that as an optional
> peripheral. It might be worth laying out a 14 pin connector off of
> the output port for that purpose.
USD 2 for a 16x2 (or USD 7 for a 20x4) including controller ?
Thats pretty cheap. If this is true, a 20x4 should be included
for shure. A LCD without controller is not usefull, since a permanent
scann to support output counters the basic static Design.
> > Let's get serious, the Elf99 is not suposed to be the real thing, used for
> > real applications. It's just for the fun of doing it, and experimenting with
> > unusual concepts (unusula from todays view). When ever you want to
> > do real apps, any 6504+6532 or 68xx singlechiper will be more relevant.
> Well... I wouldn't call a 6504/6532 board "relevant". Fun, probably, but
> not current stuff. Fun this is, but if it isn't at least passingly
> practical, nobody can do anything with it.
6504+6532 gives a great system for controll apps of any kind, and is
comparable to most single chip CPUs (128 Bytes RAM, 2 I/O ports,
Timers) , so it is still relevant, and fits for practical use anything you
can do with the Elf99 -ok, maybe use a 6502 instead the 6504
(And my personal choise is still a 80188 :).
> I never really used my Elf
> because I had no I/O beyond the Q LED and the switches. The main reason
> for designing the Elf99 is to satisfy a 20-year-old desire to have a
> "useful" Elf, and to capitalize on the present wave of nostalgia to
> make a PCB cost-effective. I could always just bang out a single board
> for myself with the iron-on transfers, but that's so much work that I'd
> rather make something that I can share with a wider audience. It's risky
> to consider putting up a few thousand dollars on a replica of a classic,
> but if I maximize the appeal of the standard I/O ports, I'm likely to sell
> a few dozen. If I can't sell 60, I can't afford to invest in 100 PCBs.
With to much usefullnes, you might reduce the potential interest.
The apeal lies in having an Elf like computer, but with all the fancy
stuff to draw fun from programming and playing. Thats one main
reason why I suggestet the library and the library boot - ready made
simple applications to play with, to demonstrate to friends and family
members. I bet, everyone of us has sometimes recived a dumb look
when he was explaining how beautiful some function or programm is
and how usefull ...
So my idea of the Elf99 is an easy to use experimentation / training
kit with a lot of interesting features - NOT any kind of very usefull high
powered controller. Something to learn about a microcomputer for
children, to show to friends and relatives, a brain game to try (almost)
all things belonging to a computer - and the MDU is just a part of this
idea - pointing to two (or four) chips and tell someone thats the 'super
high integrated calculator' thing and show _real_ programming of the
I/O of numbers is something complete different than pointing to a pentium
class chip and say 'oh, and in there is a FPU for calculations' or to
add some FPU instructions in your programm (remember, with the
help of a 5 byte programm you could even show them how to feed
the MPU and how to retrieve the result via switches and the TIL 311).
In fact, if the design is a in this direction I plan to use two of them
for children in the age of 11 and 14.
Gruss
Hans
--
Ich denke, also bin ich, also gut
HRK
Received on Thu Nov 26 1998 - 12:43:22 GMT