Re: External RAMdisk
- From: "dkelvey@xxxxxxxxxxx" <dkelvey@xxxxxxxxxxx>
- Date: Fri, 23 Jan 2009 10:53:12 -0800 (PST)
On Jan 13, 11:13 pm, Jack Crenshaw <jcr...@xxxxxxxxxxxxx> wrote:
no.s...@xxxxxxxxxxxxxxxxxxxxxxx wrote:
On Sun, 11 Jan 2009 16:09:22 -0500, Jack Crenshaw
<jcr...@xxxxxxxxxxxxx> wrote:
Back in "the day," I bought a third-party RAMdisk for my Kaypro 4 84. I
can't recall the name of the company, but it was based in Bend, OR, as I
recall.
The RAMdisk was 2 Mb, and plugged between the printer and the Kaypro
printer port (which was, contrary to reports, bidirectional). It worked
great, and was lightning fast.
I cant see how it would be bidirectional if it's buffered with an
LS241! The PIO that feeds it can be but the actual printer output for
both 4/84 and II are unidirectional by virtue of the intervening
LS241. Now if you unplug and bridged that LS241 all mannor of
things are possible.
Allison, I think I figured out how the RAMdisk could work with that
LS241 between the PIO and the printer port. See if you agree.
The LS241 is an octal buffer whose outputs can be tristated. There are
two tristate pins, pins 1 and 19. On the Kaypro board, pin 19 is tied
permanently high. But pin 1 comes through as an INPUT from the
Centronics port. My guess is, when the RAMdisk was plugged in, it pulled
that pin low. That would tristate the outputs on bits 0..3 of the bus.
There would be no need for signals to be buffered as long as the RAMdisk
was plugged in. The PIO had its own Centronics port, and could have had
its own buffering, on its output to the printer.
Waddaya think?
On the flip side, it looks like the unit was "parallel" only in the
sense of a 4-bit wide transfer. Which only goes to argue for use of I2C
in a modern implementation.
On the first side again, a modern implementation wouldn't have to be
limited, either to 4 bits or 8 bits or to the disabled tristate pin of
the Kaypro, or even to having a buffer at all.
Jack
I disassembled the driver for the RAMdrive. It was extremely simple, not
unlike writing to flash. You gave it, as I recall, a block number and a
block count, then started streaming data. There was a processor inside
the box. I believe it was an 8085, but not sure. It transferred data
byte-wide. I'm not positive, but I would guess there was a CRC test
going on inside the box.
I mention this only because the concept might be useful for mass
storage, for some of the homebrew projects you guys are working on. Add
battery backup, and you've got yourself a virtual hard drive. Most
(all?) of the micro development systems have a ton of I/O pins, which
could be commandeered to the task.
Hm. Come to think of it, if one were to define/hijack the transfer
protocol, you could use the virtual disk on any system with I/O pins.
The driver in the CPU was quite small.
No question it would be easy. the real hijack would eb to use the
save Kaypro side driver and have a 32mb CF at the other end of the
wires. the remote cpu can sort out the differences.
Allison
Jack
Hi Jack
With the fact that there was not input on the parallel 8 bits, there
is no way it
could have used these lines to read data. You do have to remember that
reading data from the array is actually the smaller part of the task.
The RAMdisk needs to get track/sector information. I'd suspect that
the data bits were most likely used for that. It could also be used
for
the write data.
The printer status bits were most likely what was used for the data
going
back to the computer. I could imaging how such a circuit could be made
without too much difficulty. It would just need a simple software
driver
on the Kaypro side to pack the bits into a byte of data.
Dwight
.
- References:
- External RAMdisk
- From: Jack Crenshaw
- Re: External RAMdisk
- From: no . spam
- Re: External RAMdisk
- From: Jack Crenshaw
- External RAMdisk
- Prev by Date: Re: YADQ (Yet another dumb question)
- Next by Date: Re: What hath c.o.cpm wrought?
- Previous by thread: Re: External RAMdisk
- Next by thread: Re: External RAMdisk
- Index(es):
Relevant Pages
|
Loading