On Aug 10, 2010, at 5:23 PM, Johnny Billquist wrote:
Zane H. Healy wrote:
On Tue, 10 Aug 2010, Brian Hechinger wrote:
On Tue, Aug 10, 2010 at 06:50:32AM -0400, Paul Koning wrote:
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.
RT-11 will probably be the best use of this in it's current form.
I think RSTS/E can run reasonably well without an FPP, but I'm sure Paul will correct me if I'm wrong.
RSTS doesn't much care if an FPP is present or not. Basic uses it if available, which makes float calculations significantly faster.
Lots of layered products require the FPP though.
I remember being told that Fortran-4-Plus requires FPP, while everything else either doesn't care or can be configured either way.
Then again, I must admit I don't know all that much about this. I've only rarely used FP myself...
paul
Zane H. Healy wrote:
On Tue, 10 Aug 2010, Brian Hechinger wrote:
On Tue, Aug 10, 2010 at 06:50:32AM -0400, Paul Koning wrote:
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.
RT-11 will probably be the best use of this in it's current form.
I think RSTS/E can run reasonably well without an FPP, but I'm sure Paul will correct me if I'm wrong.
Lots of layered products require the FPP though.
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).
One, or even four RK05 is definitely a challenge to run anything on. :-)
RT-11 is once more probably the best choice.
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 5:14 PM, Johnny Billquist wrote:
...
I don't think the UDA50 use any common microprocessor even, but is implemented with bitslices, and logic.
Correct. The main ingredients are AMD 2901 bitslice ALUs plus a 2910 sequencer.
Apparently the designer had a bunch of flexibility how those pieces go together. The UDA used a particularly interesting approach, where the micro-instruction would instruct the ALU part (2901) separate from the sequencer part (2910). The assembly language had two fields per line, one for each part.
There was a one clock delay between ALU result and branch control input. So you could read odd statements like this (paraphrasing... I don't remember the exact syntax):
clr r0 ; bne foo
because the bne would act on the ALU output from the preceding line.
I doubt that the processor part of the UDA50 would be all that hard to implement in an FPGA, but as you said, that isn't all that helpful if what you're after is MSCP support in the W11 FPGA.
paul
Paul Koning wrote:
On Aug 9, 2010, at 10:05 PM, Johnny Billquist wrote:
Brian Hechinger wrote:
If so I'm SOOOO buying a bunch of FPGAs to run that on. :-D
Yes, it should run most software just fine.
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.
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.
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 you'll go with something akin with firmware for whatever storage you choose, since it will not map easily with any backend you choose anyway.
That said, MSCP is still more complex than anything else, I agree. But it's also more useful.
Doing the whole UDA50 hardware in an FPGA would not be useful, since then you'd have something that would talk SDI. You'll not find anything today that talks SDI.
More meaningful in that case to do the CDU720, which uses SCSI as the backend. But I still think just implementing the basic needed for MSCP straight away is easier. We have enough of MSCP already figured out, and implemented for this to not be that hard today. The sources for simh is around, which implements enough of MSCP needed. Use that as the base.
And then map it to whatever backend you want to use.
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.
CF would be equally cool.
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
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.
