Paul Koning wrote:
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.
Same as RSX then, I'd say. Which is what I suspected.
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.
F4+ out of the box requires the FPP. However, there was information in the manuals on how to get F4+ to run without FPP, with some restrictions. The same is true for F77, which later replaced F4+. (The restrictions basically being that you'lll be limited to integer operations only.)
I think F4 don't need FPP, but might also be restricted to integer only if you don't have an FPP.
That Basic+ can live without it don't surprise me, nor that it can use it if it do exist.
Having said that, the following do needs FPP, as far as I know:
Basic+2
C
COBOL-11, COBOL-81
DIBOL-11
Datatrieve-11
FMS-11
MAIL-11
PASCAL-11
Hmm, what else existed...? Can't remember offhand, but for some other products, FPP probably wasn't neccesary, while for some it is.
Then again, I must admit I don't know all that much about this. I've only rarely used FP myself...
I can't say I use it that often, since I mostly sit and hack in the kernel for RSX, or right next to it on my TCP/IP.
I do, however, implicitly use it a lot, since I occasionally play around in BASIC+2, F77 and C on my PDP-11s, and the FPP is involved even when I'm hardly aware of it. :-)
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
Bob Armstrong wrote:
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.
Hey, I don't mind the discussion, and I understand where you come from.
It's always a problem. One the one hand, I suspect that you don't mind the interest generated, and the potential users discussing how something can be used. On the other hand, you can start to feel like people whine about something given free.
However, you should never forget that just because people might not know how to do one thing (like write VHDL) don't stop them from having opinions on what might be needed to make something someone else did being more useful. And wanting to provide feedback is not neccesaily the same thing as whining.
Take things for what they are. Peoples opinions. People who take an interest. I don't think that is bad. You just need to step back and take a deep breath sometimes when things might sound very negative, and try to look at things in a larger perspective.
Of course, you are free to disagree with me on this too, and I won't stop writing about things even if you do. I do, however, sincerely hope that people take what I write as more than just whinings... :-)
Oh, and I do use more of my energy to more than write emails. This whole list exist because I do so... :-) I just don't have time to go diving in yet another direction. I have enough with just doing stuff on HECnet, improving RSX in all corners I can think of, bugfixing and improving 2.11BSD, contributing to NetBSD, and keep my own machines up and running and providing help for others to keep their machines up and running.
Don't assume that all people do is write mails complaining about stuff, just because they think that something they see could be improved. :-)
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: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
