Hi,
I have both Panasonic Hand Held Computer RLH1400 & Printer/Rom Extender
RL-P1005. Both items are in a case and look in great shape. Does have 3 chips
(new) along with owners manual. Some paper in printer. What is all this worth ?
Will you direct me to anyone interested in purchasing all of the above ?
Thank You,
Leo
> -----Original Message-----
> From: cctalk-bounces at classiccmp.org
> [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Josef Chessor
> Sent: Friday, February 29, 2008 11:53 AM
> To: General Discussion: On-Topic and Off-Topic Posts
> Subject: Re: front panel display for a modern PC
>
[snip]
>
> I do dabble in PIC programming, and I've got at couple of 40-pin PICs
> that would probably fit the bill with a minimum of other electronics
> (or use smaller PICs with more support electronics). Heck, a
> sufficiently simple microcomputer emulator could probably be
> implemented on said PIC, at some point. (Those are ideas I've been
> rolling around in my head for quite some time.)
>
[snip]
Hi,
I do not have much PIC programming experience but based on a little bit of
study and a small project, I cannot help but wonder a similar thing.
Recently I built a PIC 16F628 serial to parallel converter to change my
spare KayPro II serial keyboard to parallel output with the application
being to attach it to a Vector Graphic FlashWriter II video/keyboard card.
So far, I have gotten the program to run and can convert the serial stream
to light up 8 LEDs and a strobe LED but haven't attached it to the VG FWII
yet.
While working on this rather simple project, it kept occurring to me that
the PIC is practicaly begging to be made into a general purpose low chip
count computer. Add some address and data bus latches, static memory, an
EPROM, maybe a peripheral or two. The parallel and serial ports are
practically built in already. Yes, the PIC doesn't have your traditional
data and address bus but with a small 40 pin PIC protoboard like this, it
doesn't seem like it'd be all that hard to interface one to a small SRAM
like a 6264.
http://cgi.ebay.com/Microchip-PIC-Prototyping-Board-40-Terminal-PIC_W0QQitem
Z360012737667
The idea keeps kicking around in my head. It sounds like fun.
Thanks!
Andrew Lynch
I stopped holding my breath for creation of a Q-Bus IDE
controller a long time ago. While I like to think that I
do a reasonable job troubleshooting some problems,
I'm definitely not a hardware/software engineer.
It would have been nice, but it makes more sense
these days to go Q-Bus to SATA. I would imagine
that it would be alot less hassle, and certainly alot less
real estate on the board, with the smaller connectors,
and fewer traces.
At any rate, back to the topic, Q-Bus to Compact Flash.
If you can do Q-bus to Compact Flash, then you can do
Q-bus to IDE, because CF *is* an IDE interface.
Those wonderful CF to IDE adapter boards generally don't
have any circuitry on-board, except to drive status LED's.
Right now, I have Compact flash / IDE on my Q-bus,
albeit in a round-about way.
I have older CMD SCSI controllers (CQD-200's).
Attached to those are ACard 7720U SCSI <> IDE adapters.
http://www.acard.com
The CMD controllers don't have any problems with them,
and it seems to be happy with older IDE drives that I've tried.
And finally, I have ACS IDE <> Compact Flash adpaters.
http://www.acscontrol.com
You can use any IDE <> CF adapter you want,
and you can certainly get them alot cheaper elsewhere.
I chose the ACS unit, since they were one of the few
that I could find that offered it in a 3.5" drive frame.
They also offer them in a 5.25" form factor, but I think
they're just using a readily available 3.5" to 5.25" frame.
I use a SCSI removeable chassis, so I had to modify my
Acard 7720U in order to fit everything into the tray.
There is at least one vendor that offers a direct
SCSI to CF adapter, but they were a bit pricy
compared to my homebrew version.
I have tested my configuration with CF cards
ranging from 4MB up through 2GB, and find
that it works adequately for my needs.
I could see no discernable speed increase between
using real SCSI drives, and the IDE <> CF adapter,
although I wasn't trying to do any significant benchmarking.
(The CQD-200's are kind of poky controllers anyway,
so this didn't really surprise me.)
Now, if I only I could use PUTR to dump a disk image
onto a RAW IDE device, I'd be a happy camper. . . ;-)
T
Time to finally clean out some file cabinets; what should I do with
sales brochures, price lists, etc. from the 80s? Nothing exciting,
not very informative, but hate to just toss 'em into the recycle bin.
m
>
>>Subject: Re: Qbus to CF / IDE
>> From: Doc Shipley <doc at mdrconsult.com>
>> Date: Fri, 29 Feb 2008 19:09:12 -0600
>> To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org>
>>
>>tiggerlasv at aim.com wrote:
>>>
>>>
>>>> You could have, for example, four RL02s each capable of being
>>>> assigned a "pack" from the card.
>>>
>>>> What were the biggest non-MSCP-attached drives?
>>>> How hard would they be to emulate?
>>>
>>>
>>> While RL02's would probably be easy to emulate,
>>> at 10MB a pop, you don't get alot of bang for your buck.
>>
>> Forgive me if this is a silly question, but is 10MB a limitation of
>>the firmware and drivers, or of the disk technology?
>
>None of the above. There is a limit of 32mb for RT11 disks because
>because the sector pointer is only 16bits and sector size is 512bytes
>(65536*512=32mb).
>
>The real problem is few people know how to write a driver and if they
>do it's only for one OS and the list of OSs [UnixVn, RT11, RSTS,
>RSX11, VMS, Ultrix, other?] means a driver for each. Once you have
>a working driver a booter is possible.
>
>The RL driver cant be used as it's dependent on DMA and a simple IDE
>interface will not likely include that. So the model for the driver
>is more likely DD[tu58], DX [rx01], DY[rx02] or maybe some other but
>with the dimension table altered as they used PIO for the transfer.
>
>
>Allison
>
>
>>
>> Doc
>
>--m21CTBEw048667.1204374551/keith.ezwind.net--
anyone do or know of anyone doing repairs on vaxstations?
is this a lost art, and I should just buy another one off ebay or what?
I'd love to find someone who did hardware repairs/engineering for dec or still knows the stuff.
Thanks,
Dan.
_________________________________________________________________
I know, I know; I should have kept the contents and thrown out
the binders. What can I say...
Anyway, if anyone wants some binders with the Burroughs logo,
some generic and some machine-specific (L series, B80, B800)
enough to pay postage, let me know.
mike
There has been alot of discussion, as well as some good
(and not-so-good suggestions) with regards to the construction
of a Q-bus to IDE interface.
No doubt a good portion of it is from people in the field
with the knowlege and experience to take on such a project.
Being an end-user, I tend to look at things more from
the standpoint of convenience, practicality, and feasability.
We don't really need to know if it CAN be done,
because we already know the answer.
The REAL challenge is to design something that can be readily assembled
without the need for very specialized or high-end equipment,
and doesn't rely on obsolete or hard to find parts.
After all, what is the point of designing something really cool,
if it can't be easily reproduced by the average person, without
spending tons of money? At that point, it's cheaper and easier
to buy something that is already made.
With that said, here are some things that would be important to me,
when considering the design of such a device.
I've heard on more than one occasion that MSCP isn't convenient
to implement because of it's bad block replacement scheme,
and that it would be easier to use an older emulation.
For practicality purposes, that narrows it down to either
MASSBUS (RM/RP), RK05/RK07, or RL01/RL02 emulation.
To that end, my questions and suggestions are based on that premise.
Note that some of these things are "easier said than done",
but are nonetheless "something to think about".
1.) Construction
Can it be easily assembled by someone with a
modicum of technical skill, and resources?
Some examples would be -
Will the layout be relatively simple? i.e,
can it be constructed on a a single or double-sided
circuit board, rather than a multi-layer board?
Can it be constructed with readily available parts?
i.e., parts that aren't 20 years old, or hard to find?
Will components be standard DIPS, or SMT?
How easy will it be to get the firmware onto the prom?
2.) Ease of use
How will you tell it what it needs to emulate?
Obviously, a fixed emulation would be the easiest
to implement. RM05, RP06, or whatever.
One capacity, one prom.
However, I don't think it's that much of a stretch
to create selectable emulations via dip switches.
Obviously NVRAM is nicer, but may add to the overall
cost and complexity.
3.) Compatability
Whatever the design, I'm sure most of us will agree that it
should use STANDARD, unmodified DEC drivers for operation.
From what I hear, RT11 drivers are a snap to create,
but I personally dread the thought of trying to
add an unproven driver into an operating system
such as RSTS/E or RSX. I think from a compatability
standpoint, we're better off trying to "pretend to be"
something that is already supported across multiple platforms,
and the source code for those drivers are readily available.
Going further down the non-MSCP route,
I had some thoughts on some of the basic implementation -
A relatively SIMPLE design would yield something like this:
Basic functions could be driven by a bank of seven dip switches.
You'd have to pick ONE capacity, and stick with it.
Three switches would be used to select the number of drives
being emulated by the controller. (1 through 8)
Four switches would be used to select the drive emulation.
RM02/RM03/RM04/RM05
RP02/RP03/RP04/RP06/RP07
RK05/RK07
RL01/RL02
The controller would be forced as the first (primary controller)
of it's type. Address and vectoring would be tied directly to
the emulation switches, and it would set itself to the primary
address and vectors automatically. Starting LUN is always ZERO.
Are we an RL01? Then set our address to 17774400, vector 160.
(And ignore bit 3 for the number of drives on the controller !)
A more advanced approach would involve using NVRAM instead of switches.
(Storing the parameters ON the drive could be used as well, as long as
there was some sort of redundancy and recovery feature involved,
in the event of a bad sector popping up in the parameters area.)
If NVRAM or disk-based parameters were used, you could select
your address and vectors manually.
Additionally, this would allow you to mix-and-match
some of the drive capacities, effectively allowing you
to emulate two RM02's, and 3 RM05's, for example.
Of course, you'd still have to stay within the same
general emulation.
Flexible drive sizes could cause problems down the road though,
particularly if you want to change the size of a drive,
when there are other emulations already on the disk.
To get around this problem, a fixed partitioning scheme
could be implemented, based on the maximum size drive
for each emulation.
Let's say you wanted RM emulation.
An RM05 is the largest, at ~256MB.
The firmware could be set to create 8 partitions of 256MB each.
(Requiring a minimum of a 2.1GB drive).
Each emulated drive would start at a fixed position on the disk,
regardless of size, on 256MB boundaries.
Then you could change/set the capacity of any of the units
without affecting the others. In this instance, the drive type
doesn't determine the starting position, only the amount of
space
being used by a particular unit. Later, if you decide you want
drive #2 to be am RM03, you simply change it in NVRAM,
and format it from your operating system. The space between
the end of the RM03, and the 256MB boundary is simply ignored.
A mixed RL01/RL02 emulation would work the same way;
taking up ~40MB of space, regardless of drive type selected.
Some other ideas:
40-pin header, and a CF card slot on the front edge of the
board !
It might be trivial to implement RAID 1 (mirroring)
on a 2nd (identical) hard drive set to "slave",
particularly if we're looking at blind writes to disk.
Any thoughts or suggestions?
T
Hello all,
just a question out of couriosity:
Does anybody of you have experience regarding a conversion of a
s/390 coupling facility into a fully usable s/390 server system?
I got a coupling facility Generation 3. The difference between such facilities and
a fully usable server configuration is that it can only use a single type
of interconnections, no ESCON adapters etc.
I think that such a coupling facility is defined by the software installed on
the front-end system (and IBM Thinkpad) and I heard that IBM can perform
a conversion. Can a hobbyist do the same?
And hints or advises are appreciated!
Have a nice weekend and thanks alot in advance for your answers.
Kind regards,
Pierre
_________________________________________________________________________
In 5 Schritten zur eigenen Homepage. Jetzt Domain sichern und gestalten!
Nur 3,99 EUR/Monat! http://www.maildomain.web.de/?mc=021114
Ok, so this barely qualifies for the "10-year rule" but I'm asking it
anyway because you guys are so forgiving of these things :).
Picked up a "Total PowerSMP" PCI card made by "Total Impact" in the
mid-90s. (I think around '96?). From the very limited information I've
found on the 'net (mostly echoed info from press releases) this thing
has four PPC 604e CPUs on it. (233Mhz, if I'm reading the chip
correctly). This is about all the information I've been able to find on
the board.
Anyone have any documentation or software for this thing? Total Impact
seems to have disappeared off the face of the planet.
Thanks,
Josh
