29 Jul
2004
29 Jul
'04
12:05 p.m.
From: "John Honniball"
<coredump(a)gifford.co.uk>
Jay West wrote:
Hi John
Most of the applications Jay is talking about require faster
than 100ns someplace. Most EPROMs just are not in that range.
Dwight
Since the blank chips are nigh impossible to find
anymore... is it possible
to use something like a PIC chip on a small DIP carrier card, that could be
plugged into an existing loader rom or microcode rom socket and function
just like the "real thing" to the system?
You wouldn't use a PIC chip for something like this. A PIC would be
used in a microcontroller-type application, where program-controlled
behaviour is required. To replace a ROM, we could simply use another
ROM (or PROM, EPROM, EEPROM, Flash ROM, etc.) with a pinout adaptor.
People are already doing this for PROMs in mobile radios. These PROMs
are in fact the same chips as one finds in a PDP-11 for booting (M9312)
and for storing the 8008 firmware in an 11/34 console card. The
PROMs in question are 82S131, 74S571 or Am27S13 types (512x8). I have
some blanks here to fix a console card, as it happens.
Scroll down here:
http://www.open.org/~blenderm/syntorx/legacy.html
to the section headed "EPROM Conversion" to read about the PROM
replacements for Syntor radios. And see this page:
http://www.open.org/~blenderm/syntorx/legacyeprom.html
for photos of a completed adaptor.
Do you know the chip numbers and/or specs for the ROMs you wish to
emulate?
--
John Honniball
coredump(a)gifford.co.uk
1 Aug
1 Aug
9:18 a.m.
On Thu, 2004-07-29 at 17:05, Dwight K. Elvey wrote:
Most of the applications Jay is talking about require
faster
than 100ns someplace. Most EPROMs just are not in that range.
How about: a fast RAM, with a PIC (and optionally E/EPROM) on the
backside. Upon reset, the PIC owns the RAM chip(s); it loads the RAM
with data from the EPROM/EEPROM, or serial line to a peecee, flips
control of the RAM interface to the "ROM" socket, and goes to sleep.
A cute trick commonly used in the CP/M days (and later) was to put a
boot EPROM board in the same (conflicting) memory space with RAM; the
EPROM code would proceed to "block copy" itself in place (read: EPROM;
write: RAM) then reset a flipflop that enabled the EPROM board.
EPROM board read access generated many wait states; the trick was the
EPROM board ignored write cycles but the underlying RAM didn't. I forget
how we handled the EPROM 'read' cycle but it was buss-safe (S100) and
simple.
10:36 a.m.
On Sun, 1 Aug 2004, Tom Jennings wrote:
A cute trick commonly used in the CP/M days (and
later) was to put a
boot EPROM board in the same (conflicting) memory space with RAM; the
EPROM code would proceed to "block copy" itself in place (read: EPROM;
write: RAM) then reset a flipflop that enabled the EPROM board.
EPROM board read access generated many wait states; the trick was the
EPROM board ignored write cycles but the underlying RAM didn't. I forget
how we handled the EPROM 'read' cycle but it was buss-safe (S100) and
simple.
I'm not sure if it's an apt analogy (or an analogy at all) but an Apple
][ with 64K has 16K ROM at the top of memory and a 16K bank of RAM shared
with the ROM. If you poked to the upper locations it would be stored to
the RAM, but if you peeked you'd get the byte in ROM. You could enable
RAM read by flipping some soft switches.
PEEK and POKE: what wonderful command names! I wish computers were that
much fun today.
--
Sellam Ismail Vintage Computer Festival
------------------------------------------------------------------------------
International Man of Intrigue and Danger http://www.vintage.org
[ Old computing resources for business || Buy/Sell/Trade Vintage Computers ]
[ and academia at www.VintageTech.com || at http://marketplace.vintage.org ]
1:56 p.m.
A cute trick commonly used in the CP/M days (and
later) was to put a
boot EPROM board in the same (conflicting) memory space with RAM; the
EPROM code would proceed to "block copy" itself in place (read: EPROM;
write: RAM) then reset a flipflop that enabled the EPROM board.
EPROM board read access generated many wait states; the trick was the
EPROM board ignored write cycles but the underlying RAM didn't. I forget
how we handled the EPROM 'read' cycle but it was buss-safe (S100) and
simple.
I believe that was the "PHANTOM" line... pin 67 (according to _THE_S-100_
AND_OTHER_MICRO_BUSES_ by Poe and Goodwin).
2 Aug
2 Aug
7:42 a.m.
> A cute trick commonly used in the CP/M days (and
later) was to put a
> boot EPROM board in the same (conflicting) memory space with RAM; ...
> EPROM board read access generated many wait states; the trick was the
> EPROM board ignored write cycles but the underlying RAM didn't. I forget
> how we handled the EPROM 'read' cycle but it was buss-safe (S100) and
> simple.
On Sun, 2004-08-01 at 18:56, Bill Sudbrink wrote:
I believe that was the "PHANTOM" line... pin
67 (according to _THE_S-100_
AND_OTHER_MICRO_BUSES_ by Poe and Goodwin).
Ugh! I remember now! >shudder< S100 interfacing dribbles back into
brain... not good! :-)
(I should go buy an S100 book though for reference. I have nothing from
that era at all except one WordStar book.)
7211
days inactive
7215
days old
4 comments
4 participants
participants (4)
-
dwight.elvey＠amd.com -
tomj＠wps.com -
vcf＠siconic.com -
wh.sudbrink＠verizon.net