Paul Koning wrote:
I think F4 don't need FPP, but might also be restricted to integer only if you don't have an FPP.
I think it simply worked fully even without FPP (or it might not ever use it even if one exists). F4 started in RT-11 which was aimed at small machines.
Hmm. I should probably check some documentation, but I think it can use
one if wanted.
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
No, definitely not. BP2 was used as the compiler for all RSTS utilities as pre-compiled by DEC (though B+ could be used by customers if desired).
Sigh. My memory once more plays tricks with me. BP2 can use FPP or not,
depending on which version of the library you install.
...
MAIL-11
MAIL-11 was written in Basic-Plus (or BP2) so it would work on non-FPP machines. That assumes you're not counting the earlier one that was used only internally, written in TECO and distributed by some field office clown who was fired for it...
Yes. Inferred by the above.
*Sigh*
Sorry for the misinformation. My brain is playing tricks on me.
I didn't know there was ever one written in TECO. Yikes... :-)
There was the one written in a mix of FORTRAN and BASIC, which was
distributed through DECUS. That should also be possible to use without
FPP then, I guess...
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
All of the interfaces "supported" are "oldish", i.e. they were implemented in TTL without any local "interface processor". Later interfaces were more or less all based on some embedded CPU to do the shuffling.
So, in taking this great work further, some suitable "soft processor hardware" needs to be implemented.
I realize there are several "commercial" alternatives, some supplied by chip vendors etc, some requiring costs, licensing etc... None of that is worthy to be a part of an open design, in my opinion...
Would it be more feasible to us in this community to use some design we already can master, and that we already have the tooling for? Should a PDP-11 be used for peripheral needs? If so, which model of the 11 should this "I/O-slave" be designed around?
Or is there already any "better" alternative (architecture so superior that it's worth learning/getting tools for) that I should put my eyes upon for this task?
A full 11/70 (for each interface) core feels just a little to much to myself. What about a 11/40 design??? Would 256 kB of (max) memory be to small to design an efficient Ethernet interface? Would the lack of separate I & D - space be to much of a problem. Or should a yet simpler design be enough. Not even implementing 18-bit MMU (thus max 64 kB of memory) should be enough to do several interfaces - just like DEC used 8080 on some boards (!?)
If such a design where used, should it be programmed upon RT-11? These "systems" should behave like embedded systems once finished, running from "PROM".
I have found a POP-11 online, that's seems to be open source, though not written in VHDL (that by the way also includes an IDE interface). Could this after all be a starting point?
I'd like to hear your thoughts on my ideas, even though I'll have to learn VHDL and get myself some hardware to get going - this is the starting-point I've been waiting for quite a while, dreaming of implementing like a 11/93-based system in FPGA. Beeing a spare-time dream, don't expect any of my dreams to come real "next week", though ;-)
/G ran
I think F4 don't need FPP, but might also be restricted to integer only if you don't have an FPP.
I think it simply worked fully even without FPP (or it might not ever use it even if one exists). F4 started in RT-11 which was aimed at small machines.
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
No, definitely not. BP2 was used as the compiler for all RSTS utilities as pre-compiled by DEC (though B+ could be used by customers if desired).
...
MAIL-11
MAIL-11 was written in Basic-Plus (or BP2) so it would work on non-FPP machines. That assumes you're not counting the earlier one that was used only internally, written in TECO and distributed by some field office clown who was fired for it...
paul
Joe Ferraro wrote:
Hi Johnny,
Please add snow:: to 20.513 at your convenience (VMS/IA64 8.4).
WOPR$ search MIM::[DECNET]NODENAMES.* snow
%SEARCH-I-NOMATCHES, no strings matched
Hi. Done.
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
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
