PDP11GUI 1.47
Folks, a new version of PDP11GUI is online. It fixes some errors, including "Error 103", which occured when running MACRO11 without administrator privileges. There were also problems under Win10. Download from http://retrocmp.com/pdp-11/pdp11gui Bug feedback is necessary! Enjoy, Joerg
Re: WTB Miniscribe 3425 (working or parts donor)
On 11/25/2015 12:19 AM, Mark J. Blair wrote: I have the drive spinning up happily, though track alignment is still a crap shoot. I've tried dumping it with the MFM Reader/Emulator, and its software could not make sense of the track format or CRC. I dumped a raw MFM transitions file for more analysis, since the Xebec controller might just use a track format that the emulator software doesn't currently support. I *think* the track format for the S1410 is documented in the board manual, so if you can get raw track data then there's a chance that you might be able to make sense of it.
Re: Oberon and the OberonStation (retro-style FPGA computing)
On Tue, 24 Nov 2015, ben wrote: On 11/23/2015 7:28 PM, William Maddox wrote: The revived 2013 re-issue of Niklaus Wirth's Oberon system is a joy to behold. If you've never heard of Oberon before, it is a minimalistic education-oriented language and operating system designed after Wirth had taken a (second) sabattical at PARC in the 80's. I say WORTH LESS, with out even looking at it, as I am NOT a Pascal FAN It's ok Ben, nobody's perfect. :) g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.diy-cockpits.org/coll - Go Collimated or Go Home. Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://scarlet.deltasoft.com - Get it _today_!
Re: Oberon and the OberonStation (retro-style FPGA computing)
On Tue, 24 Nov 2015, Paul Koning wrote: Pascal is largely obsolete now, but I still appreciate it -- of the 40 or so languages I know, there are only two where I could go from no knowledge at all to having a working program of significant size in one week: Pascal and Python. Um, no. Check out Delphi, Lazarus and FPC. No where near "obsolete". g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.diy-cockpits.org/coll - Go Collimated or Go Home. Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://scarlet.deltasoft.com - Get it _today_!
Re: flash (or ide) storage for unibus 11?
> From: Phil Budne >>> allow the board to be connected to a modern computer as a peripheral? >> Not sure I see the purpose? > Simulated serial port to MCU "console" and/or simulated q/unibus SLU(s) Yes, but... what's the point of being able to gain access to SLU's on the QBUS from a modern machine? Just plug serial ports into the modern machine. Etc, etc. If you meant 'a simulated console for the -11 that some other machine can get to', just run a serial cable from that machine to the real -11 console line. (BTW, which expansion of the "MCU" acronym did you have in mind?) > Simulated ethernet to MCU internal network and/or simulated > q/unibus NIC Not sure I entirely follow this? We had talked about eventually writing code to support a common USB Ethernet interface, and have the QSIC emulate the Interlan NI2010 etc cards, which were very nice to program (unlike all the DEC native Ethernet interfaces). > Block device access to "unmounted" flash partitions Like I said, plug the storage unit (we don't have any that are physically built into the QSIC) directly into the other machine. The QSIC is not intended to provide an SD port for some other kind of machine that doesn't have a native SD port; you can justq buy an SD carrier that is a USB device. Sorry, I'm just not into the whole 'desert topping / floor wax' concept (and a tip of the hatly hat to Marshall Rose for the phrase). 'Can do something' != 'good idea to do something'!! > I suppose "host" ports can used to support physical USB dongles of > various sorts (serial, ethernet), but I guess my orientation is "why > connect extra hardware that can be simulated?" Simulated, how? It's not clear that it's easier to do the simulation (via some complex lash-up) than have the QSIC provide something that looks, programming-wise, just like the DEC originals. Although there are no plans to to serial lines. In general, my philosophy is not to provide things which are still _readily_ available for real - and serial lines fall into that cateory. > ability to halt/reset the q/unibus (PDP-11) processor > (making the MCU into a "front end") If the LSI-11 console is i) plugged into something else, and has 'halt on break' enabled, you pretty much already have that. > If it's possible to make a board that's operable without an MCU Huh? The QSIC is planned to be a standalone QBUS card - i.e. take a running QBUS system with CPU, memory, etc, and plug in a QSIC for 'disk' storage. Or by 'MCU' were you referring to the -11 CPU? Bridgham has at times wanted to do that, but I'm not enthusiastic - see desert-topping/floor-wax point, plus my point about 'only doing things that aren't easily available' - and QBUS PDP-11 CPUs are readily available. > design the board so that it accepts a processor in "gumstix" or SODIMM > form factor, and expose connections for USB/ethernet. More desert-topping/floor-wax. > Linux has "gadget" support for simulating various flavors of USB > devices on a 'device' port. I have zero, none, nada interest in doing a board that can run Linux. > From: David Bridgham > It could then halt the processor and examine memory Not sure about that. I don't know if the CPU processes DMA requests when it's stopped. You can't use go ahead and use the bus without asking because the processor is in tight loop issuing DATI's to the console CSR. Noel
Re: Random question about a Byte Magazine Cover
On Tue, Nov 24, 2015 at 5:48 PM, Mark Wickens wrote: > OK so this has been bugging me for a while. During a stint working at > Morgan-Smith Electronics in Hatfield UK (they made diverse electronic > systems including industrial PCs and radio alarms) I went through the > boss's discarded vintage computer magazine collection and one particular > issue I remember finding very interesting. > > IIRC it was a Byte Magazine (certainly the graphic was very in keeping with > Byte cover artwork). I wonder if anyone recalls it - Google image searches > have pulled a blank which means it either wasn't Byte (and just looked like > it) or hasn't been scanned. > > The cover had a painted image of a white cliff face draped in vines with an > 'Adventurer' in the foreground - you can imagine what the theme was. Anyone > have any ideas? Maybe it wasn't Byte? > > Of course all this really quite irrelevant in the grand scheme of things, > but it would help me scratch an itch at the very least. > > Thanks! Mark. > I'm all too familiar with that kind of itch. I'm glad we have this forum to at least attempt to find answers; hope you find yours. -- Eric Christopherson
Re: flash (or ide) storage for unibus 11?
On 2015-11-25 10:38 AM, Noel Chiappa wrote: > From: Phil Budne ... > Linux has "gadget" support for simulating various flavors of USB > devices on a 'device' port. I have zero, none, nada interest in doing a board that can run Linux. I am sure Phil only meant that it would be easy to interface to a board exposing such USB features *from a separate Linux system* - because of that driver. Watching your project with great interest, Noel. I've been contemplating such a thing myself for more than 10 years but I haven't got the electronics experience myself, so I needed a collaborator. Then of course conditions in life never cleared the space to make it happen, or I just had other priorities. :( I did end up studying MSCP and buses in some detail though. --Toby
Front panels
Hi Guys Ok our front panels are going into production. Meeting went well. We finally worked out how they did the matte layer on the front It appears to be a transparent or translucent white. Its ink base with no colour The effect is like a steamed up window or shower glass panel. It looks a matt grey colour that transmits light but obscures objects behind it. as the panel behind it is black except where the holes are you see a matt black and diffused white light from the lamps are. Neat trick! Rod(Panelman)Smallwood
Re: WTB Miniscribe 3425 (working or parts donor)
> On Nov 25, 2015, at 04:17, Jules Richardson > wrote: > > I *think* the track format for the S1410 is documented in the board manual, > so if you can get raw track data then there's a chance that you might be able > to make sense of it. > The sector format is described. but not in a great deal of detail. David Gesswein has provided some hints to help me begin the challenge of decoding things. It appears that the drive is now seeking off by about 4 tracks, and I think I should be able to use diagnostic output from the MFM Reader/Emulator to get the track 0 sensor readjusted by trial and error. -- Mark J. Blair, NF6X http://www.nf6x.net/
Re: Replacing MicroVAX II PSU With a Modern PSU
On 11/25/2015 01:34 AM, Robert Jarratt wrote: -Original Message- From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Jon Elson Sent: 25 November 2015 02:05 To: gene...@classiccmp.org; discuss...@classiccmp.org:On-Topic and Off- Topic Posts Subject: Re: Replacing MicroVAX II PSU With a Modern PSU On 11/24/2015 05:52 PM, Mark Wickens wrote: I haven't looked into this at all and I suspect it's probably quite tricky indeed. I did look around a while back drew a blank. I built up a Micro-VAX II system out of boards, backplanes and assorted junk. I made my own power supply. The power supply is actually easy, just +5 and +12, with a touch of -12 for serial I/O. The only tricky thing is the power-OK and reset logic, which really wasn't all that tricky, either. I had a power and thermal safety control panel on it repurposed from the original 3rd party IBM mainframe memory box that would shut it down if there was an abnormal voltage or cooling failure. Jon Thanks Jon. I think standard PC PSUs only do +5 and +12, so how did you do -12? I did not use PC power supplies, I used a couple industrial power supplies. I built this system in 1986. But, generic PC power supplies DO have a little bit of -12 V for serial cards. The standard PCI connector has a -12 V pin. PCIe seems to have dropped the -12V supply. For P OK and DC OK I found this: http://home.windstream.net/engdahl/powerup_reset_circuit.htm, but just for test purposes I assume I could connect the +5 direct to P OK and DC OK. BPOK needs to pulse low after power is stable, BDCOK should be high when power is OK. Or, at least, that's what I got from the drawing you linked to. Jon
Re: Oberon and the OberonStation (retro-style FPGA computing)
On 11/25/2015 09:01 AM, geneb wrote: On Tue, 24 Nov 2015, Paul Koning wrote: Pascal is largely obsolete now, but I still appreciate it -- of the 40 or so languages I know, there are only two where I could go from no knowledge at all to having a working program of significant size in one week: Pascal and Python. Um, no. Check out Delphi, Lazarus and FPC. No where near "obsolete". I was really pleased with FPC! Are people actually creating new projects with it? I was grateful to discover FPC so I could update my photoplotter program and move away from the Turbo Pascal / Windows XP executable I have been using. But, I haven't used it for any new projects. (Yet.) Jon
Re: 1980s/1990s 68k C cross (and not so cross) compilers
On 11/21/15 2:38 PM, Al Kossow wrote: On 11/21/15 10:44 AM, Paul Koning wrote: Arg, totally forgot to include the HP 64000 and Tek 8560 development systems though I'm blanking right now on if they did their own or sold third-party C compilers. Third party, I believe. I used one of those for a 68040 (developing the DECbridge 900). I think the compiler was Green Hills. GCC was around, I think, but that isn't the one we used as far as I remember. paul It would have been impossible to use GCC on the 8560, it was a V7 PDP-11 Unix. The 64000 processor is pretty much the same as the HP 9845. In 1983 there was Alcyon on the 8560 :-) (woa. that was a long time ago) It only worked because they #ifdef'd out the floating point support. Split I&D on a pdp-11. Not much space. I'm not aware of any native TEK C compiler for 68k on the 8560. In 1987 gcc would compile to 68k quite well. Before that I seem to recall that there was also a C compiler from Standford, from sumex (wow - do I still have those brain cells?). Remember sumex-aim ? SumMacC. Anyway, I think the Kinetics fastpath was compiled with that and I could swear I was using it as a C compiler on a vax-11/750 running mt. xinu in mid 80's. Find someone from pixar - they were using it to compile Macintosh code. I don't know the lineage of that compiler, but I think it was a port of something older. There was also another C compiler we ran on the vax but I doubt I can remember who wrote it (was it Megamax C?). It was a top down recursive decent compiler with only a peephole optimizer, but it was "good enough". I think I shipped a product or two with its output. It had a native mac version but somehow we got them to port it to the vax since it was written in C (and OMG, all of the token values were hex values in the code - like 0x45 - no use of the preprocessor at all. made my hair catch fire. still, it worked. just don't try and edit it.) Oh, and the sun-2 showed up around 1984. That had it's own C compiler, naturally, but (oddly), I never used it as a cross compiler. I was too busy trying to keep the lisa profile disk going :-) Around that time the lisa was macintosh development environment. But the pain keeps me from remembering it well. The text editor was pretty. That's about all I can say. slow as molasses. No one mentioned Apollo. Ok, their pascal compiler probably had more strength but I know there was a C compiler in there as well, certainly in the 1983-1985 time frame. and who could forget Bill Poduska? There was also that wacky company in cambridge which made a hybrid c-compiler/c-interpreter. It worked really well but it wasn't quite right. I loved the idea but never bought one. That was around 1988, 1989? I always hoped to find the source code for that. I think gcc was the standard for 68k from 1987 on. Yes, greenhills, but it's not clear it produced better code and it was really expensive. Ask anyone at cisco or wellfleet what they used. And trust me, they were worried about code size and code speed. lol. I remember trying to route at "wirespeed" using 10baseT. Makes me laugh now. -brad
RE: Replacing MicroVAX II PSU With a Modern PSU
> -Original Message- > From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Jon Elson > Sent: 25 November 2015 16:37 > To: gene...@classiccmp.org; discuss...@classiccmp.org:On-Topic and Off- > Topic Posts > Subject: Re: Replacing MicroVAX II PSU With a Modern PSU > > On 11/25/2015 01:34 AM, Robert Jarratt wrote: > > > >> -Original Message- > >> From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Jon > >> Elson > >> Sent: 25 November 2015 02:05 > >> To: gene...@classiccmp.org; discuss...@classiccmp.org:On-Topic and > >> Off- Topic Posts > >> Subject: Re: Replacing MicroVAX II PSU With a Modern PSU > >> > >> On 11/24/2015 05:52 PM, Mark Wickens wrote: > >>> I haven't looked into this at all and I suspect it's probably quite > >>> tricky indeed. I did look around a while back drew a blank. > >>> > >> I built up a Micro-VAX II system out of boards, backplanes and > >> assorted junk. I made my own power supply. The power supply is > >> actually easy, just +5 and > >> +12, with a touch of > >> -12 for serial I/O. > >> > >> The only tricky thing is the power-OK and reset logic, which really > >> wasn't all that tricky, either. > >> > >> I had a power and thermal safety control panel on it repurposed from > >> the original 3rd party IBM mainframe memory box that would shut it > >> down if there was an abnormal voltage or cooling failure. > >> > >> Jon > > Thanks Jon. I think standard PC PSUs only do +5 and +12, so how did you do - > 12? > I did not use PC power supplies, I used a couple industrial power supplies. I > built this system in 1986. > But, generic PC power supplies DO have a little bit of -12 V for serial cards. > The standard PCI connector has a -12 V pin. PCIe seems to have dropped the - > 12V supply. Thanks, that should do the job then. > > For P OK and DC OK I found this: > http://home.windstream.net/engdahl/powerup_reset_circuit.htm, but just for > test purposes I assume I could connect the +5 direct to P OK and DC OK. > BPOK needs to pulse low after power is stable, BDCOK should be high when > power is OK. Or, at least, that's what I got from the drawing you linked to. > > Jon My reading of the Qbus spec is that P OK and DC OK are active high. That diagram tells me that both control signals are driven the same way because the two circuits are identical except for the timing caps. When the power is OK the output of the inverters is low, so the transistors are off, presumably allowing the signals to float high. When the power is not OK, the inverters are high, turning on the transistors and shorting the signal to ground. But, I am no expert, and could have interpreted those circuits all wrong. Regards Rob
Re: 1980s/1990s 68k C cross (and not so cross) compilers
On 2015-11-25 11:46 AM, Brad Parker wrote: On 11/21/15 2:38 PM, Al Kossow wrote: On 11/21/15 10:44 AM, Paul Koning wrote: Arg, totally forgot to include the HP 64000 and Tek 8560 development systems though I'm blanking right now on if they did their own or sold third-party C compilers. Third party, I believe. I used one of those for a 68040 (developing the DECbridge 900). I think the compiler was Green Hills. GCC was around, I think, but that isn't the one we used as far as I remember. paul It would have been impossible to use GCC on the 8560, it was a V7 PDP-11 Unix. The 64000 processor is pretty much the same as the HP 9845. In 1983 there was Alcyon on the 8560 :-) (woa. that was a long time ago) It only worked because they #ifdef'd out the floating point support. Split I&D on a pdp-11. Not much space. I'm not aware of any native TEK C compiler for 68k on the 8560. In 1987 gcc would compile to 68k quite well. Before that I seem to recall that there was also a C compiler from Standford, from sumex (wow - do I still have those brain cells?). Remember sumex-aim ? SumMacC. Anyway, I think the Kinetics fastpath was compiled with that and I could swear I was using it as a C compiler on a vax-11/750 running mt. xinu in mid 80's. Find someone from pixar - they were using it to compile Macintosh code. I don't know the lineage of that compiler, but I think it was a port of something older. You are right about gcc; version 1.37 (and I think a later version too) was ported to MPW, where it performed better than, and was more or less a drop in replacement for, Apple's compiler. In fact, when I was porting TeX -- at the time, considered a large program -- only gcc would compile it successfully. Long before that, I used Whitesmiths C, Aztec C, and of course Lightspeed/THINK C on Mac for 68K. --Toby There was also another C compiler we ran on the vax ... I think gcc was the standard for 68k from 1987 on. Yes, greenhills, but it's not clear it produced better code and it was really expensive. Ask anyone at cisco or wellfleet what they used. And trust me, they were worried about code size and code speed. lol. I remember trying to route at "wirespeed" using 10baseT. Makes me laugh now. -brad
Re: Replacing MicroVAX II PSU With a Modern PSU
On 11/25/2015 11:01 AM, Robert Jarratt wrote: My reading of the Qbus spec is that P OK and DC OK are active high. That diagram tells me that both control signals are driven the same way because the two circuits are identical except for the timing caps. When the power is OK the output of the inverters is low, so the transistors are off, presumably allowing the signals to float high. When the power is not OK, the inverters are high, turning on the transistors and shorting the signal to ground. But, I am no expert, and could have interpreted those circuits all wrong. Regards Rob Yup, I read the circuit the same way. Jon
Re: Oberon and the OberonStation (retro-style FPGA computing)
On Wed, 25 Nov 2015, Jon Elson wrote: On 11/25/2015 09:01 AM, geneb wrote: On Tue, 24 Nov 2015, Paul Koning wrote: Pascal is largely obsolete now, but I still appreciate it -- of the 40 or so languages I know, there are only two where I could go from no knowledge at all to having a working program of significant size in one week: Pascal and Python. Um, no. Check out Delphi, Lazarus and FPC. No where near "obsolete". I was really pleased with FPC! Are people actually creating new projects with it? I was grateful to discover FPC so I could update my photoplotter program and move away from the Turbo Pascal / Windows XP executable I have been using. But, I haven't used it for any new projects. (Yet.) You might want to join the fpc users mailing list. It's got decent traffic on it. The range of cpu targets you can compile to is pretty good. You can even compile for Android. :) g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.diy-cockpits.org/coll - Go Collimated or Go Home. Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://scarlet.deltasoft.com - Get it _today_!
Re: 1980s/1990s 68k C cross (and not so cross) compilers
Brad Parker wrote: > Remember sumex-aim ? SumMacC. > Anyway, I think the Kinetics fastpath was compiled with that Perhaps originally But when the FastPath code arrived at Shiva it was using the SunOS 4 native compiler on Sun3. I moved it to gcc on Sun4. The 6/88 KIP release has CC=/usr/stanford/bin/cc68 Rutgers KIP c. 1989 used gcc > There was also that wacky company in cambridge which made a hybrid > c-compiler/c-interpreter. It worked really well but it wasn't quite > right. I loved the idea but never bought one. That was around 1988, > 1989? I always hoped to find the source code for that. Saber-C? It became "Code Center" by Centerline. Steve Kauffer kept it going while working on startups (TripAdvisor being the successful one). It ended up at ICS.COM: https://motif.ics.com/products/codecenter ISTR some product of that ilk that read and patched object code and only worked on RISC platforms... > I think gcc was the standard for 68k from 1987 on. Yes, greenhills, but > it's not clear it produced better code and it was really expensive. I never dealt with that many 68K compilers. I remember a whole slew of problematic compilers and debuggers on 32x32 (Encore) and ROMP (IBM PC/RT). At least of them couldn't handle cfront output and/or "Duff's Device" phil
RE: Replacing MicroVAX II PSU With a Modern PSU
> -Original Message- > From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Jon Elson > Sent: 25 November 2015 17:10 > To: gene...@classiccmp.org; discuss...@classiccmp.org:On-Topic and Off- > Topic Posts > Subject: Re: Replacing MicroVAX II PSU With a Modern PSU > > On 11/25/2015 11:01 AM, Robert Jarratt wrote: > > My reading of the Qbus spec is that P OK and DC OK are active high. > > That diagram tells me that both control signals are driven the same > > way because the two circuits are identical except for the timing caps. > > When the power is OK the output of the inverters is low, so the > > transistors are off, presumably allowing the signals to float high. > > When the power is not OK, the inverters are high, turning on the > > transistors and shorting the signal to ground. But, I am no expert, > > and could have interpreted those circuits all wrong. Regards Rob > Yup, I read the circuit the same way. > Ah, I misread your earlier response, I thought you were saying something different. Regards Rob
Re: Big heap of DEC Flip-Chips modules
Hi Jörg Very enticing. But the link gives me a 404. I think it should be: http://retrocmp.com/flipchipshop /P On Wed, Nov 25, 2015 at 02:34:55PM +0100, Jörg Hoppe wrote: > Hi, > > a year ago or so an inventory of several thousand DEC flip-chip modules > appeared in the neighbourhood. > "Yesss, my preciou, it came too me !!!" > But I couldn't acquire them. At least I help selling them now. > > The inventory is here: > retrocmp.com/flipshipshop > > It was a 2-months-project: most fun was sorting and counting the modules, > then taking the pictures. > A webshop solution seemed the best for online presentation. (Very > interesting, I never did that before) > > Functionality of the shop software is good. On the other hand this project > appears a bit too commercial now. > You even should be able to buy online over Paypal, but I'd prefer personal > contact. > > Joerg
Big heap of DEC Flip-Chips modules: URL update
Correction: typo in the URL, it is retrocmp.com/flipchipshop of course !! Am 25.11.2015 um 14:34 schrieb Jörg Hoppe: Hi, a year ago or so an inventory of several thousand DEC flip-chip modules appeared in the neighbourhood. "Yesss, my preciou, it came too me !!!" But I couldn't acquire them. At least I help selling them now. The inventory is here: retrocmp.com/flipshipshop It was a 2-months-project: most fun was sorting and counting the modules, then taking the pictures. A webshop solution seemed the best for online presentation. (Very interesting, I never did that before) Functionality of the shop software is good. On the other hand this project appears a bit too commercial now. You even should be able to buy online over Paypal, but I'd prefer personal contact. Joerg
Big heap of DEC Flip-Chips modules
Hi, a year ago or so an inventory of several thousand DEC flip-chip modules appeared in the neighbourhood. "Yesss, my preciou, it came too me !!!" But I couldn't acquire them. At least I help selling them now. The inventory is here: retrocmp.com/flipshipshop It was a 2-months-project: most fun was sorting and counting the modules, then taking the pictures. A webshop solution seemed the best for online presentation. (Very interesting, I never did that before) Functionality of the shop software is good. On the other hand this project appears a bit too commercial now. You even should be able to buy online over Paypal, but I'd prefer personal contact. Joerg
RE: Big heap of DEC Flip-Chips modules
> -Original Message- > From: cctech [mailto:cctech-boun...@classiccmp.org] On Behalf Of Jörg > Hoppe > Sent: 25 November 2015 13:35 > To: General Discussion: On-Topic Posts > Subject: Big heap of DEC Flip-Chips modules > > Hi, > > a year ago or so an inventory of several thousand DEC flip-chip modules > appeared in the neighbourhood. > "Yesss, my preciou, it came too me !!!" > But I couldn't acquire them. At least I help selling them now. > > The inventory is here: > retrocmp.com/flipshipshop > > It was a 2-months-project: most fun was sorting and counting the modules, then > taking the pictures. > A webshop solution seemed the best for online presentation. (Very > interesting, I > never did that before) > > Functionality of the shop software is good. On the other hand this project > appears a bit too commercial now. > You even should be able to buy online over Paypal, but I'd prefer personal > contact. > > Joerg I am not in this market, but the URL you gave has an (obvious) typo! Regards Rob
Re: 1980s/1990s 68k C cross (and not so cross) compilers
On 2015-11-25 1:41 PM, Phil Budne wrote: Brad Parker wrote: Remember sumex-aim ? SumMacC. Anyway, I think the Kinetics fastpath was compiled with that Perhaps originally But when the FastPath code arrived at Shiva it was using the SunOS 4 native compiler on Sun3. I moved it to gcc on Sun4. The 6/88 KIP release has CC=/usr/stanford/bin/cc68 Rutgers KIP c. 1989 used gcc There was also that wacky company in cambridge which made a hybrid c-compiler/c-interpreter. It worked really well but it wasn't quite right. I loved the idea but never bought one. That was around 1988, 1989? I always hoped to find the source code for that. Saber-C? It became "Code Center" by Centerline. Steve Kauffer kept it going while working on startups (TripAdvisor being the successful one). It ended up at ICS.COM: https://motif.ics.com/products/codecenter ISTR some product of that ilk that read and patched object code and only worked on RISC platforms... I think gcc was the standard for 68k from 1987 on. Yes, greenhills, but it's not clear it produced better code and it was really expensive. I never dealt with that many 68K compilers. I remember a whole slew of problematic compilers and debuggers on 32x32 (Encore) and ROMP (IBM PC/RT). At least of them couldn't handle cfront output and/or "Duff's Device" Yes. As I hinted in my earlier post on this, bad/buggy/unmaintained vendor compilers are a big part of why gcc came to exist. And then much later, fittingly, it wiped them out and replaced most of them as a standard system compiler. :) --Toby phil
Re: Oberon and the OberonStation (retro-style FPGA computing)
They show sold out for the kits. Didn't see a link to ask if they'll ever get
more in stock.
> On Nov 24, 2015, at 1:46 AM, Mark Wickens wrote:
>
> In answer to Kurts question - the link with boards to purchase is here:
> http://oberonstation.x10.mx/
>
>> On 24 November 2015 at 07:45, Mark Wickens wrote:
>>
>> Thanks for letting us know about this William - I'm sure there is still
>> plenty of interest in Oberon, Modula-2, Modula-3 and other derivatives.
>>
>>> On 24 November 2015 at 04:26, Kurt K wrote:
>>>
>>> Where did you order the Oberon Station. I didn't see a link off the
>>> project page.
>>>
> On Nov 23, 2015, at 8:28 PM, William Maddox
wrote:
The revived 2013 re-issue of Niklaus Wirth's Oberon system is a joy to
>>> behold. If you've never heard of Oberon before, it is a minimalistic
>>> education-oriented language and operating system designed after Wirth had
>>> taken a (second) sabattical at PARC in the 80's.
The new version runs on a custom RISC processor, implemented in an
>>> FPGA, instead of the NS3032 in the orginal Ceres workstations.
>>> Originally, it required a Digilent "Spartan 3 Starter Kit" with a
>>> custom-built daughterboard providing a few additional connectors. This
>>> board is no longer made, however, and no other FPGA development board
>>> appears to provide the 32-bit wide fast SRAM the Oberon CPU required.
Recently, a new board, the OberonStation, has come onto the market
>>> that was designed specifically for Oberon, and will boot up Oberon 2013 out
>>> of the box. It also looks like an excellent platform for other
>>> retro-style FPGA CPU designs that want to stay away from complex SDRAM
>>> controllers and the caches they like to feed.
My OberonStation arrived a couple of days ago, and it's really amazing
>>> to see what can be done with a hardware and software stack that is small
>>> enough to actually read and understand.
https://www.inf.ethz.ch/personal/wirth/
http://www.projectoberon.com/
OberonStation - The Oberon computing platform
--Bill
| |
| | | | | |
| OberonStation - The Oberon computing platform/*{{{*/* html .tiddler
>>> {height:1%;}body {font-size:.75em; font-family:arial,helvetica; margin:0;
>>> padding:0;}h1,h2,h3,h4,h5,h6 {font-weight:bold; |
| |
| View on oberonstation.x10.mx | Preview by Yahoo |
| |
| |
>
Re: 1980s/1990s 68k C cross (and not so cross) compilers
On 11/25/15 8:46 AM, Brad Parker wrote: In 1987 gcc would compile to 68k quite well. Before that I seem to recall that there was also a C compiler from Standford, from sumex (wow - do I still have those brain cells?). Remember sumex-aim ? SumMacC. Anyway, I think the Kinetics fastpath was compiled with that and I could swear I was using it as a C compiler on a vax-11/750 running mt. xinu in mid 80's. Find someone from pixar - they were using it to compile Macintosh code. I don't know the lineage of that compiler, but I think it was a port of something older. SumMacC was based on MIT/LCS/Terman's port of pcc for the NuMachine project. I thought I had the sources, but all I've been able to turn up is the MIT compiler collection tape with a bunch of obscure pcc ports.
Obscure pcc targets - Re: 1980s/1990s 68k C cross (and not so cross) compilers
On 2015-11-25 2:22 PM, Al Kossow wrote: On 11/25/15 8:46 AM, Brad Parker wrote: In 1987 gcc would compile to 68k quite well. Before that I seem to recall that there was also a C compiler from Standford, from sumex (wow - do I still have those brain cells?). Remember sumex-aim ? SumMacC. Anyway, I think the Kinetics fastpath was compiled with that and I could swear I was using it as a C compiler on a vax-11/750 running mt. xinu in mid 80's. Find someone from pixar - they were using it to compile Macintosh code. I don't know the lineage of that compiler, but I think it was a port of something older. SumMacC was based on MIT/LCS/Terman's port of pcc for the NuMachine project. I thought I had the sources, but all I've been able to turn up is the MIT compiler collection tape with a bunch of obscure pcc ports. Actually some of us might be interested in those pcc ports (targets?). The BSTJ Unix issue mentioned a number of exotic Unix ports and I'd always assumed the compilers for those platforms were no longer findable. So it might be interesting to know what is on that tape. --Toby
RE: Replacing MicroVAX II PSU With a Modern PSU
> My reading of the Qbus spec is that P OK and DC OK are active high. That > diagram They are, for a very logical reason. Remember you can wire-AND open-collector signals -- that is link them together so that any driver can pull the line low and the line will only be high if all driver transistors are cut off. Now if you have a large system with multiple boxes and power supplies then any supply can pull P OK and DC OK low if there is a problem. Only if all supplies are present and correct will the signals be high. -tony
Re: Replacing MicroVAX II PSU With a Modern PSU
> From: Robert Jarratt > When the power is OK the output of the inverters is low, so the > transistors are off, presumably allowing the signals to float high. > When the power is not OK, the inverters are high, turning on the > transistors and shorting the signal to ground. That is correct. One thing to watch for: in a machine which does not have bus pullups on the backplane (some do, but many, especially early DEC ones, do not), if you run it without a CPU card plugged in (e.g. to test the power supply), BPOK/BDCOK will be at 0V even if the power is OK because there's no pullup to pull it high (unless driven low). This may also affect some of the lights, e.g. the 'Power OK' light in some DEC boxes - it won't come on, even though power is in fact fine, and working. Noel
Re: flash (or ide) storage for unibus 11?
> From: Toby Thain > it would be easy to interface to a board exposing such USB features > *from a separate Linux system* - because of that driver. Ah, OK - I'm so used to people putting Linux on the embedded processor in their rice cooker that, not clearly understanding what was being talked about, I assumed it was wanted to run Linux on the uC. Still, I guess I don't really see the value in making the QSIC, or some things plugged into it, 'available' from some other machine. AFAIAC, it's only a peripheral to the PDP-11. > I did end up studying MSCP ... in some detail though. Ah, we'll put you in charge of implementing the MSCP controller emulations, then! :-) (Those are something I oersonally have no interest in, but I can see a viable case for doing them.) Noel
Blimey!
£567 for a Research Machines 380Z. Suppose I will have to give up hope ever getting one of those . L http://www.ebay.co.uk/itm/Research-Machine-380Z-RM-380Z-Tested-Working-/2317 54184801? Regards Rob
Re: Blimey!
On 25/11/2015 21:56, "Robert Jarratt" wrote: > £567 for a Research Machines 380Z. Suppose I will have to give up hope ever > getting one of those . L > > > > http://www.ebay.co.uk/itm/Research-Machine-380Z-RM-380Z-Tested-Working-/2317 > 54184801? > Wow. I know the seller of that too, but didn't know he had one of those. Shame, mine still has 'issues' and is on the Todo list once I stop fixing ZX Spectrums and finish the PET4032 and and and :) -- Adrian/Witchy Binary Dinosaurs creator/curator Www.binarydinosaurs.co.uk - the UK's biggest private home computer collection?
Re: flash (or ide) storage for unibus 11?
>Johnny Billquist wrote: >On 2015-11-24 16:35, Al Kossow wrote: >On 11/23/15 11:46 PM, Johnny Billquist wrote: Your native interface have the additional problem that in addition to requiring people to write their own device driver for any OS usage, it will be rather difficult to get booting from it, since that require special support. There is no reason you can't have two simulated controllers, one small enough and early enough to boot a range of operating systems (RL02?), then another which exports a simple block-level interface which would be simple enough to easily write drivers against. True. But having your system on an RL02 is still no fun. It's a rather small disk, which cause some headache for larger systems. Actually, by V05.05 of RT-11, it was impossible to have all of the Source Code files on a single RL02 even just for the RT-11 portion. If you collected all of the binary distributions for V05.07 of RT-11 and the layered products, that would also exceed a single RL02. RL02 is also interesting because there was a 22 bit version for qbus. That's one definition of "interesting". :-) I'm trying to remember if DSD had extended block length or partioning for their controllers Not sure about it, but what I normally observed was that 3rd party controllers using large disks for some DEC disk usually put several logical disks on one physical disk. You could call that partitioning. For example, the DSD 880/30 (from Data Systems Design of course) emulates 3 RL02 disk drives using a single internal (non-removable) hard drive. The box also holds a single RX03 floppy disk drive (8" floppy disk drive which supports using single-sided media specified by DEC as an RX02 floppy in addition to media which have the same physical interface, but which are double-sided). For a Qbus system, the dual module controller was the interface to both the three RL02 hard drives and the single RX03 floppy drive. I don't know if DSD also made a separate controller for the Unibus for the DSD 880/30. With regard to the address support by the controller for the Qbus, the floppy drive definitely supported only an 18-bit address. That 18-bit ONLY support by DSD was identical to the 18-bit support that DEC provided for its Qbus controller for the RX02, so both DEC and DSD needed a bounce buffer managed by software to support the RX02 floppy disk for systems with more than 256 KB of physical memory. As for DSD support for the RL02 for a 22-bit buffer address, a quick look at the DSD manual was not able to say one way or the other. However, it seems more likely the the DSD controller for the RL02 supported ONLY an 18-bit address. I have all the DSD hardware, but it is not operational at this point. If anyone else has experience with the DSD controller for the emulated RL02, let us know if there was 22-bit address support for its emulated RL02 drive. Jerome Fine
Re: flash (or ide) storage for unibus 11?
On Tue, Nov 24, 2015 at 3:13 AM, Johnny Billquist wrote: > The RH11 do DMA, just like all other disk controllers I know of. IIRC, the RX11/RX211 (Unibus) and RXV11/RXV21 (Qbus) don't do DMA.
Re: PDP11GUI 1.47
*goes to URL* Wait, what? 11/70 hardware console functionality? But links are placeholders... work in progress? Mike On Wed, Nov 25, 2015 at 11:52 PM, Jörg Hoppe wrote: > Folks, > a new version of PDP11GUI is online. > It fixes some errors, including "Error 103", which occured when running > MACRO11 without administrator privileges. > There were also problems under Win10. > > Download from http://retrocmp.com/pdp-11/pdp11gui > > Bug feedback is necessary! > > Enjoy, > Joerg > > -- http://www.corestore.org 'No greater love hath a man than he lay down his life for his brother. Not for millions, not for glory, not for fame. For one person, in the dark, where no one will ever know or see.'
RE: flash (or ide) storage for unibus 11?
> > The RH11 do DMA, just like all other disk controllers I know of. > > IIRC, the RX11/RX211 (Unibus) and RXV11/RXV21 (Qbus) don't do DMA. The RX11/RXV11 don't do DMA, but the RX211 and RXV21 do, I think -tony
Re: flash (or ide) storage for unibus 11?
> > On Nov 25, 2015, at 10:41 PM, Jerome H. Fine wrote: > > >Johnny Billquist wrote: > …… > For example, the DSD 880/30 (from Data Systems Design of course) emulates > 3 RL02 disk drives using a single internal (non-removable) hard drive. The > box > also holds a single RX03 floppy disk drive (8" floppy disk drive which > supports > using single-sided media specified by DEC as an RX02 floppy in addition to > media which have the same physical interface, but which are double-sided). > For a Qbus system, the dual module controller was the interface to both the > three RL02 hard drives and the single RX03 floppy drive. I don't know if > DSD also made a separate controller for the Unibus for the DSD 880/30. > > With regard to the address support by the controller for the Qbus, the floppy > drive definitely supported only an 18-bit address. That 18-bit ONLY support > by DSD was identical to the 18-bit support that DEC provided for its Qbus > controller for the RX02, so both DEC and DSD needed a bounce buffer > managed by software to support the RX02 floppy disk for systems with more > than 256 KB of physical memory. > > As for DSD support for the RL02 for a 22-bit buffer address, a quick look > at the DSD manual was not able to say one way or the other. However, > it seems more likely the the DSD controller for the RL02 supported ONLY > an 18-bit address. I have all the DSD hardware, but it is not operational > at this point. If anyone else has experience with the DSD controller for > the emulated RL02, let us know if there was 22-bit address support for > its emulated RL02 drive. > > Jerome Fine Confirming that the original DSD 880 only had support for 18 bits DMA. There are only 2 bits in the CS register for extended addressing. I doubled checked the RT-11 handlers I had. There was a Unibus controller for the original 7.8Mbyte RL02 reduced drive. Google 040018-01 DSD 880 Users Manual May81 The Sigma SDC RXV31 controller supported 22 bit DMA. See 400255-C SDC-RXV31 Floppy Ctrl Man Aug86 I used both, but double sided compatibility between the two products was occasionally spotty. Never did determine if it was a controller, floppy drive or media issue.
