Brian Hechinger wrote:
On Tue, Aug 10, 2010 at 06:50:32AM -0400, Paul Koning wrote:
http://opencores.org/project,w11
Think that can run RSX/RSTS?
I'll have to take a look... a second reason to get an FPGA eval board...
It only runs on two boards, but at $100 for one, it's not a bad price, really.
Definitely an attractive price, yes.
I have just a few gripes with this implementation. If they matter to you
or not is for you to decide:
1) No FPP. I think this is important, others might disagree.
I get the feeling that's something he'll be adding. Does the lack of FPP affect
me currently? Probably not, but of course it would be nice to have.
Both from reading his information that he has published, and from my discussions with him, I get the impression that this is not high on his list, and might never be. But I might be wrong, which would be nice.
For me, this is definitely something that for means that I'm not interested. But as I said, others may very well have other views. I'm just giving my view on it.
2) Small disks. Only RK05 for now, and no plans for MSCP at all. While
future massbus is cool, by todays standards, fixed size, rather small
disks, are not that useful.
Yes, this I can agree with, most definitely.
Non-MSCP disks can be done in logic; MSCP has always been implemented as firmware running on the storage controller. Presumably you'd want to do likewise here. That's certainly possible, with the help of an embedded processor inside the FPGA. Then you'd have to implement the MSCP firmware, which is a fair chunk of code. (I don't suppose anyone has the UDA50 firmware available? Then all you'd need is an FPGA model of the hardware, which would be easy by comparison.)
I *think* I've got a UDA50 laying around (or know someone who does), what would
be required to extract the firmware from it?
I really don't see the point. The firmware is located in a bunch of proms. Might be 2732 or something similar, if I remember right. But extracting the data from these will not be much help. You need to remember that the UDA50 is a "computer", so this will be the firmware for that machine. And it's a specific machine for just doing the UDA50. So, in order to have this firmware useful, you would need to implement the same "computer" as the UDA50 is.
Or else decode the machine code of that hardware, so that you then can disassemble the firmware. But what good would that be? The MSCP protocol as such is already known (with a few exceptions), so all this will give in addition is how the UDA50 Unibus interface is implemented, and how the SDI interface works. Neither of which is that useful information either.
I don't think the UDA50 use any common microprocessor even, but is implemented with bitslices, and logic.
3) Backend very dependant on some host machine with OS. I guess it helps
to make it doable faster, but for me, the really nice thing would be
something like USB interface to mass storage, which looks like MSCP from
the PDP-11 side. That would be *really* cool.
By far the easiest storage interface is IDE (ATA); is that still around? Well, it is, in CompactFlash cards... which would do nicely actually.
Yes, I agree, the backend server bothers me a bit as well. I've love to have
something I could plug a CF card and an ethernet cable into and be done with
it.
I would not mind a IDE, ATA, or any other kindof common modern interface with small, solid state mass storage. The backend is, in this case, not for me important. Just having one that is common, for which storage is cheap and small would be enough. But unless you go MSCP for the PDP11 side, you'll be talking disks with sizes that are just a fraction of any storage existing today. The absolutely largest non-MSCP storage is the RP07, which is Massbus, and that's still only about 0.5G.
That all being said, I'm sure this guy isn't done and who knows, send him your
suggestions, he might be up for it. :-D
Oh, he definitely don't mind suggestions and opinions. Go ahead and talk with him.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Aug 10, 2010, at 1:09 PM, Brian Hechinger wrote:
On Tue, Aug 10, 2010 at 06:50:32AM -0400, Paul Koning wrote:
http://opencores.org/project,w11
Think that can run RSX/RSTS?
I'll have to take a look... a second reason to get an FPGA eval board...
It only runs on two boards, but at $100 for one, it's not a bad price, really.
I have some other reasons for getting a much higher end (and unfortunately more expensive) board... any changes needed for that should be easy enough.
The larger FPGAs will be able to have main memory on-chip. That makes the cache unnecessary, though the effort to take it out might not be worth the trouble.
...
Non-MSCP disks can be done in logic; MSCP has always been implemented as firmware running on the storage controller. Presumably you'd want to do likewise here. That's certainly possible, with the help of an embedded processor inside the FPGA. Then you'd have to implement the MSCP firmware, which is a fair chunk of code. (I don't suppose anyone has the UDA50 firmware available? Then all you'd need is an FPGA model of the hardware, which would be easy by comparison.)
I *think* I've got a UDA50 laying around (or know someone who does), what would
be required to extract the firmware from it?
Actually, on reconsideration I spoke too fast. While that would give you a reference for the host end (PDP-11 end) of MSCP, it would also give you lots of extraneous stuff that would only make things harder: Unibus interface machinery, interfacing to the disks and the SI links, etc.
The simpler answer is probably to pick up a disk emulation from one of the emulators, and run that in an embedded CPU inside the FPGA. Various embedded small processors are readily available; some even come with GCC support.
3) Backend very dependant on some host machine with OS. I guess it helps
to make it doable faster, but for me, the really nice thing would be
something like USB interface to mass storage, which looks like MSCP from
the PDP-11 side. That would be *really* cool.
By far the easiest storage interface is IDE (ATA); is that still around? Well, it is, in CompactFlash cards... which would do nicely actually.
Yes, I agree, the backend server bothers me a bit as well. I've love to have
something I could plug a CF card and an ethernet cable into and be done with
it.
CF card interface is just like an old ATA disk; it's quite easy. Ethernet is a bit harder. Ethernet cores are available for many FPGAs, either hard dedicated logic (like in the Xilinx Virtex series) or as soft cores. Come to think of it, some are available on opencores.org. Eval boards may well come with this, including the necessary VHDL.
And I'll echo what Bob Armstrong said: consider this an opportunity to do some neat hacking. VHDL is not that hard to learn. http://www.ashenden.com.au/vhdl-book/DG3E.html is a very good textbook. (I can't find it on Amazon for some reason, though I'm pretty sure that's where I got it originally...)
paul
I'm not going to quote anybody's posting here, but there have been several
that motivated me to speak up. I have say that this is really pathetic. A
guy (Walter Mueller, the original author it looks like) does all the work to
implement a 11/70 in VHDL, gives it away to you _for free_, and all you guys
do is sit around and make lists of the stuff he didn't do. If you want an
FPU, write the VHDL for one. If you want an MSCP disk, then implement one.
Contribute. Help. Take some of that energy you use to write these emails
and use it to make the core better. That's what Open Source is all about,
guys.
</soapbox> Sorry. I see this attitude the time with Spare Time Gizmos
and I've become kind of sensitive to and intolerant of it. I'll go back to
sleep now.
Bob
On Tue, 10 Aug 2010, Brian Hechinger wrote:
On Tue, Aug 10, 2010 at 06:50:32AM -0400, Paul Koning wrote:
http://opencores.org/project,w11
Think that can run RSX/RSTS?
I'll have to take a look... a second reason to get an FPGA eval board...
It only runs on two boards, but at $100 for one, it's not a bad price, really.
Hmmm, that isn't a bad price.
Yes, it should run most software just fine.
Excellent.
I'd personally be the most interested in RT-11 and RSTS/E. From the sound
of things, RT-11 at least should work.
2) Small disks. Only RK05 for now, and no plans for MSCP at all. While
future massbus is cool, by todays standards, fixed size, rather small
disks, are not that useful.
Yes, this I can agree with, most definitely.
Non-MSCP disks can be done in logic; MSCP has always been implemented as firmware running on the storage controller. Presumably you'd want to do likewise here. That's certainly possible, with the help of an embedded processor inside the FPGA. Then you'd have to implement the MSCP firmware, which is a fair chunk of code. (I don't suppose anyone has the UDA50 firmware available? Then all you'd need is an FPGA model of the hardware, which would be easy by comparison.)
I *think* I've got a UDA50 laying around (or know someone who does), what would
be required to extract the firmware from it?
Even on the PDP-11, an RK05 is a bit tight. In fact it means that running
any semi-current OS would be challenging. I don't believe I have a UDA50,
but I'm pretty sure there is a KDA50 in my MicroVAX III (yes, I know that is
Q-Bus rather than Unibus).
Yes, I agree, the backend server bothers me a bit as well. I've love to have
something I could plug a CF card and an ethernet cable into and be done with
it.
Considering that I can plug SD cards, and an ethernet cable into my
Commodore 64, I couldn't agree more.
Zane
On Tue, Aug 10, 2010 at 06:50:32AM -0400, Paul Koning wrote:
http://opencores.org/project,w11
Think that can run RSX/RSTS?
I'll have to take a look... a second reason to get an FPGA eval board...
It only runs on two boards, but at $100 for one, it's not a bad price, really.
Yes, it should run most software just fine.
Excellent.
I have just a few gripes with this implementation. If they matter to you
or not is for you to decide:
1) No FPP. I think this is important, others might disagree.
I get the feeling that's something he'll be adding. Does the lack of FPP affect
me currently? Probably not, but of course it would be nice to have.
2) Small disks. Only RK05 for now, and no plans for MSCP at all. While
future massbus is cool, by todays standards, fixed size, rather small
disks, are not that useful.
Yes, this I can agree with, most definitely.
Non-MSCP disks can be done in logic; MSCP has always been implemented as firmware running on the storage controller. Presumably you'd want to do likewise here. That's certainly possible, with the help of an embedded processor inside the FPGA. Then you'd have to implement the MSCP firmware, which is a fair chunk of code. (I don't suppose anyone has the UDA50 firmware available? Then all you'd need is an FPGA model of the hardware, which would be easy by comparison.)
I *think* I've got a UDA50 laying around (or know someone who does), what would
be required to extract the firmware from it?
3) Backend very dependant on some host machine with OS. I guess it helps
to make it doable faster, but for me, the really nice thing would be
something like USB interface to mass storage, which looks like MSCP from
the PDP-11 side. That would be *really* cool.
By far the easiest storage interface is IDE (ATA); is that still around? Well, it is, in CompactFlash cards... which would do nicely actually.
Yes, I agree, the backend server bothers me a bit as well. I've love to have
something I could plug a CF card and an ethernet cable into and be done with
it.
That all being said, I'm sure this guy isn't done and who knows, send him your
suggestions, he might be up for it. :-D
-brian
--
"Coding in C is like sending a 3 year old to do groceries. You gotta
tell them exactly what you want or you'll end up with a cupboard full of
pop tarts and pancake mix." -- IRC User (http://www.bash.org/?841435)
On Mon, 2010-08-09 at 17:25 +0100, Sampsa Laine wrote:
Dunno about VMS, but I use fetchmail on Unix to do just that - you can
then tell fetchmail to feed it to the VMS box over SMTP.
It's exactly how CHIMPYMAIL.COM works.
I got fetchmail setup ok - how do I forward to the VMS box?
Cheers for the help, Mark.
Dunno about VMS, but I use fetchmail on Unix to do just that - you can then tell fetchmail to feed it to the VMS box over SMTP.
It's exactly how CHIMPYMAIL.COM works.
Sampsa
On 9 Aug 2010, at 17:17, Mark Wickens wrote:
On Thu, 2010-08-05 at 23:10 +0200, Sampsa Laine wrote:
I use Google Apps for all my domains, which I then pull down using
fetchmail onto a Unix (in this case OS X server).
On Thu, 2010-08-05 at 23:10 +0200, Sampsa Laine wrote:
I use Google Apps for all my domains, which I then pull down using
fetchmail onto a Unix (in this case OS X server).
At 3:46 PM +0100 8/5/10, Mark Wickens wrote:
Collective Wisdom,
I'd like to bring email from my current remote hosted IMAP server
in-house. Can anyone provide guidance on solutions? I'd like access from
standard email clients but would also like to be able to ssh into a
local box and read mail via a character terminal.
I have an OpenVMS and Linux server available to serve.
Thanks, Mark.
I used OpenVMS for about 10 years at home for an email server. I started with a AlphaStation 200 4/233 and ended with an XP1000/667.
I did run into one problem where some worthless SOB spoofed my domain for spamming and I got a *LOT* of bounces. The resulting DOS attack took the box down for a couple days. I think it was an AlphaStation 600/433au at the time.
The only reason I'm not currently running the system is that it costs to much to run a XP1000/667 with 6 10k SCSI drives 24x7, and since buying a house, I've not sorted out cooling. I've been thinking about bringing an AlphaStation 200 4/233 back online for this and a couple other things that I need VMS for. It is driving me crazy not having my own VMS system running.
Zane
--
| Zane H. Healy | UNIX Systems Administrator |
| healyzh at aracnet.com | OpenVMS Enthusiast |
| | Photographer |
+----------------------------------+----------------------------+
| My flickr Photostream |
| http://www.flickr.com/photos/33848088 at N03/ |
