Re: Xerox Star emulator (Darkstar) released today
Just wow. Congrats Josh. Marc > On Jan 19, 2019, at 9:09 PM, Scott Kevill via cctalk > wrote: > > Josh didn't mention this, and I didn't see it linked on the GitHub repo, but > he's also written a fantastic intro article about it here: > > https://engblg.livingcomputers.org/index.php/2019/01/19/introducing-darkstar-a-xerox-star-emulator/ > > Covers some of the Xerox Star's history, challenges of the emulation > development process, photos, diagrams, and screenshots of it in action. > > Highly recommended! > > (even if you're not that familiar with the Xerox Star) > > Scott. > >> On 19/01/2019, at 11:36 AM, Josh Dersch via cctalk >> wrote: >> >> Hi All -- >> >> Thought you folks might be interested -- I've been working on a Xerox Star >> emulator at LCM+L on and off over the past year and I've finally unleashed >> it upon the world. It's called Darkstar, it's open source and it runs all >> the Star software I'm aware of. The Ethernet interface is still mostly >> untested, however. >> >> You can grab the emulator and its source code on our GitHub site >> here:https://github.com/livingcomputermuseum/Darkstar. Disk images are >> available on Bitsavers as always. Thanks to Al for providing a lot of >> assistance on this project. >> >> Please let me know if you have any questions or suggestions. >> >> Thanks! >> >> Josh >> >
Re: Xerox Star emulator (Darkstar) released today
Josh didn't mention this, and I didn't see it linked on the GitHub repo, but he's also written a fantastic intro article about it here: https://engblg.livingcomputers.org/index.php/2019/01/19/introducing-darkstar-a-xerox-star-emulator/ Covers some of the Xerox Star's history, challenges of the emulation development process, photos, diagrams, and screenshots of it in action. Highly recommended! (even if you're not that familiar with the Xerox Star) Scott. On 19/01/2019, at 11:36 AM, Josh Dersch via cctalk wrote: > Hi All -- > > Thought you folks might be interested -- I've been working on a Xerox Star > emulator at LCM+L on and off over the past year and I've finally unleashed it > upon the world. It's called Darkstar, it's open source and it runs all the > Star software I'm aware of. The Ethernet interface is still mostly untested, > however. > > You can grab the emulator and its source code on our GitHub site > here:https://github.com/livingcomputermuseum/Darkstar. Disk images are > available on Bitsavers as always. Thanks to Al for providing a lot of > assistance on this project. > > Please let me know if you have any questions or suggestions. > > Thanks! > > Josh >
VCF PNW 2019: Exhibitors (still) needed!
This is not quite last call, but it is getting close ... We have 16 exhibits so far and we need a few more to make the show work. (20 would be nice, 25 would be ideal.) The event is March 23-24th in Seattle. Soon I'm going to start working on the exhibit floor plan, set the event schedule, and start to do the prep work that makes the show possible. But I need to know who is participating before I get too deep into that. If you know you are definitely going to participate then please help me out and formally register. If you have questions or are on the fence then let me know and I'll try to help you decide. Maybe this is not the right year for you, and that's fine ... but if there is something I can help you with let me know. I'm not fussy but if you can exhibit Commodore 8 bitters or Amiga equipment then I really want to talk to you. :-) (We seem to have a gap in the show there. Amazingly, nobody is doing an IBM PC related exhibit either.) A description of the event can be found at http://vcfed.org/vcf-pnw . General information for exhibitors including pictures from last year, a link to the registration form, and a FAQ can be found at http://vcfed.org/wp/vcf-pnw-exhibitor-registration/ . Thanks, Mike mbbrut...@brutman.com or mich...@vcfed.org
Re: Houston stash sorting this coming Saturday
On 1/14/19 11:20 AM, Electronics Plus via cctalk wrote: > The 2 sheds will be sorted next Saturday morning, early, in Katy, TX. Did this end up happening? I've not seen any postings or updates.
Re: DEC Rainbow / Pro video on VGA monitors?
On Sat, Jan 19, 2019 at 2:38 PM Paul Koning wrote: > > > > On Jan 19, 2019, at 1:57 PM, Warner Losh via cctalk < > cctalk@classiccmp.org> wrote: > > > > Greetings, > > > > I'm trying to find a way to get my DEC Rainbow's monochrome output onto a > > newer monitor than my aging VR201 (especially since I zapped something in > > it and my diagnostic efforts to date haven't fixed it). > > > > So, I found the bit in the Rainbow docs that said the output was DC > Coupled > > RS-170 signals and to convert to RS-170 (NTSC black and white) I needed > to > > put a 10uF cap inline to make it RS-170. So I did this, and fed it into a > > generic NTSC composite video to VGA thing, and got only a little joy. The > > first few lines seem to be missing, then the next few are OK and then > > nothing else. > > I'd be interested in the answer also, for my Pro. > > What device do you use for NTSC to VGA conversion? > I'm using https://www.amazon.com/gp/product/B00M4JY722/ref=oh_aui_search_asin_title?ie=UTF8&psc=1 and it's the one that's not working. Look to be dozens of clones of this though.. My NTSC camera works with it.. Warner
Re: PDP-11/45 RSTS/E boot problem
> On Jan 19, 2019, at 4:17 PM, Fritz Mueller via cctalk > wrote: > > ... > Looking into the parity issue some last night has raised a few questions: > > - There is a lot of inconsistent and incomplete information in the > documentation about memory CSRs. They appear to come in different flavors > depending on memory hardware; some of the earlier ones support setting a bit > to determine whether parity errors will halt or trap the CPU, while some of > the later ones (like my MS11-L) simply have "enable" and don't distinguish > between halt and trap. I'm curious how OS init code sniffs out what memory > CSRs there are, determines their specific flavors and, in a heterogeneous > system, determines how much address space is under the auspice of each CSR? > Maybe Paul and Noel can comment here wrt. RSTS and Unix respectively? I know essentially nothing about memory parity handling, but I quickly skimmed some RSTS INIT code (for V10.1). Two things observed: 1. At boot, INIT determines the memory layout. It does this by writing 0 then -2 into each location to see if it works. If it gets an NXM trap (trap to 4) or a parity trap (trap to 114) it calls that 1kW block of memory non-existent. For the case of a parity error, it tells you that it saw a parity error and is disabling that block for that reason. 2. In the DEFAULT option (curiously enough) there is a routine that looks for up to 16 parity CSRs starting at 172100. This happens on entry to the memory layout option. You can display what it finds by using the PARITY command in response to the "Table suboption" prompt. It checks if the bits 007750 are active in the parity CSR, if so it takes that to be an address/ECC parity CSR. It figures out the CSR to memory association by going through memory in 1 kW increments, writing 3, 5 to the first 2 words, then setting "write wrong parity" in each CSR (007044), then doing BIC #3,.. BIC #5,... to those two test words, then reading them both back. This should set bad parity, and it scans all the CSRs to see which one reports an error (top bit in the CSR). If no CSR has that set, it concludes the particular block is no-parity memory. I probably got some of the details wrong, the above is from a fast skim of the code, but hopefully it will get you started. Good to hear you're making progress with the hardware debug! paul
Re: DEC Rainbow / Pro video on VGA monitors?
> On Jan 19, 2019, at 1:57 PM, Warner Losh via cctalk > wrote: > > Greetings, > > I'm trying to find a way to get my DEC Rainbow's monochrome output onto a > newer monitor than my aging VR201 (especially since I zapped something in > it and my diagnostic efforts to date haven't fixed it). > > So, I found the bit in the Rainbow docs that said the output was DC Coupled > RS-170 signals and to convert to RS-170 (NTSC black and white) I needed to > put a 10uF cap inline to make it RS-170. So I did this, and fed it into a > generic NTSC composite video to VGA thing, and got only a little joy. The > first few lines seem to be missing, then the next few are OK and then > nothing else. I'd be interested in the answer also, for my Pro. What device do you use for NTSC to VGA conversion? paul
Re: PDP-11/45 RSTS/E boot problem
Happy weekend, all! Latest updates on this issue: Identified and replaced a faulty 4116 DRAM (E204) on my MS11-L. After this, my small hand-rolled standalone diagnostic passes the full 256K. I'll post my diagnostic source over on my blog soon. After this repair, tried MAINDEC ZQMC, called out as the appropriate diagnostic by the MS11-L docs. This was interesting... First, it would barely run at all unless I disabled parity checking with front panel switch settings. Second, it flagged a bunch of memory locations that weren't reported by my much simpler diagnostic (which only does all-ones/all-zeros passes looking for stuck bits at this point.) The MAINDEC memory diagnostic is bulky and complicated, and it takes several minutes to re-download it after a power cycle, so it's not exactly convenient to use while troubleshooting. I'll probably be beefing up my smaller diagnostic with a few more tests (including parity). Went ahead and tried both RSTS and Unix again after the above repair, and saw the same fault behaviors from both (sadness). Oh well, not there yet... So, smokiest gun I have right now is the parity issue. Could be I still have a bad DRAM on my MS11 in one of the parity banks... I tried enabling trap on parity error in the MS11 CSR before running my diagnostic, but it didn't trap, even though it did flag parity error(s) in the CSR. So maybe I *also* have a bug I haven't yet addressed in parity handling within CPU. I realized there is a MAINDEC specifically for this (CKBR) which I had previously overlooked. May give that a look today. Also, parity is one significant difference between SIMH and my real hardware: SIMH emulates a memory system with no parity hardware. Looking into the parity issue some last night has raised a few questions: - There is a lot of inconsistent and incomplete information in the documentation about memory CSRs. They appear to come in different flavors depending on memory hardware; some of the earlier ones support setting a bit to determine whether parity errors will halt or trap the CPU, while some of the later ones (like my MS11-L) simply have "enable" and don't distinguish between halt and trap. I'm curious how OS init code sniffs out what memory CSRs there are, determines their specific flavors and, in a heterogeneous system, determines how much address space is under the auspice of each CSR? Maybe Paul and Noel can comment here wrt. RSTS and Unix respectively? - The 11/45 prints show a jumper (W1, lower left of sheet UBCB) that looks like it would entirely disable Unibus parity error detection if removed. This was an obvious thing to check, but when I pulled and examined my UBC board (and also looked over my spare) no such jumper or any associated pads were anywhere to be found! So maybe this was either added/removed from later etches of the UBC? Anybody know more on this? My UBC has required three separate repairs so far in the course of restoring this machine, in order to address various independent issues. Now we may now be coming up on #4... Based also on the rat's nest of green wires on these boards and the frustrated-looking engineer scrawl *all* over this page of the prints, the UBC really is the heart of darkness of the KB11-A :-) cheers, --FritzM.
DEC Rainbow / Pro video on VGA monitors?
Greetings, I'm trying to find a way to get my DEC Rainbow's monochrome output onto a newer monitor than my aging VR201 (especially since I zapped something in it and my diagnostic efforts to date haven't fixed it). So, I found the bit in the Rainbow docs that said the output was DC Coupled RS-170 signals and to convert to RS-170 (NTSC black and white) I needed to put a 10uF cap inline to make it RS-170. So I did this, and fed it into a generic NTSC composite video to VGA thing, and got only a little joy. The first few lines seem to be missing, then the next few are OK and then nothing else. I tried to google this, but found nothing. My google foo has failed me. Does anybody else have a working setup? Warner
Re: How to refurbish plotter pens?
On 01/19/2019 03:57 AM, Mattis Lind via cctalk wrote: All my pens were obviously dry. Refurbish a pen seems to be impossible. Well, leaving them in alcohol for a few days seems to slowly seep in and soften the dried ink. Most have hair-thin wires that run down through the pen "needle" and these will break if too much force is applied. Once the ink softens enough to allow the weight to be pulled out safely, then the pen can be cleaned more easily. An ultrasonic cleaner helps a lot with this. But, I have to admit, my success rate is no better than 50% (but I don't have an ultrasonic cleaner.) Jon
Re: How to refurbish plotter pens?
On 2019-01-19 04:57, Mattis Lind via cctalk wrote: > So I concluded that the best option is to make a new pen holder plunger > which could take standard ball point refill. The Pilot BRFV-10M seemed to > be very common refill and would probably work well if I had another pen > holder. I asked around and found a guy with a lathe that made one for me. > Unfortunately it wasn't working immediately. I hadn't thought of certain > mechanical properties of the mechanism. I did something like that 20 years ago for my HP plotters. Back then, I found some ball points, which had a pressurized cartridge, so you could draw pretty quick lines ;-) Yes, I did it with an aluminum holder, today, I would probably ask somebody to 3d print some plastic piece, to reduce the weight of the moving part > Then I had a problem that the pen stayed in the up position. Most likely > held by some kind of remaining magnetism that could withstand the force of > the spring. A couple of M3 washers was used to reduce the contact area > between the pen holder plunger and the top lid which made it work. > > http://i.imgur.com/PRGUa9U.jpg You're not planing on getting this through TSA? ;-) > And in action: > > https://i.makeagif.com/save/QCDG_W Pretty COOL !!! > controlled by a quick and dirty PDP-11 program : > https://github.com/MattisLind/pdp11-plot One day I have to set up gcc for my pdp11 ... Cheers!
Re: How to refurbish plotter pens?
It has been almost two years since I visited this topic. But just before christmas i got around doing something about it. I interfaced it to the PDP-11/05 using an XY11 board. It seems to be very little information on the XY11 board saved. At least I didn't find anything. But the board is a quite simple dual module so I made a schematic of the circuit and then got the understanding how it should be connected to the plotter and how it should be programmed. Created a quick program for the PDP-11 and tested it. It worked just fine but then the problem was the pens. All my pens were obviously dry. Refurbish a pen seems to be impossible. The type of ink used is quite thick and I couldn't figure out how to get it into the ball point pens. Even though it was possible to clean them reasonably well using an ultrasonic cleaner there was no way I could get the ink in there. The other option is to find compatible pens. I searched google for pen refills with dimensions that would fit but couldn't find matching pens to modify and use. So I concluded that the best option is to make a new pen holder plunger which could take standard ball point refill. The Pilot BRFV-10M seemed to be very common refill and would probably work well if I had another pen holder. I asked around and found a guy with a lathe that made one for me. Unfortunately it wasn't working immediately. I hadn't thought of certain mechanical properties of the mechanism. Essentially it is two parts. The pen holder plunger itself and a small plastic part to insert into the cut off ball point refill. This latter part will reduce the exterior diameter of the pen from 4 mm to 3.2 mm so it will work with the spring in the lid. It also has a small 1 mm hole in it to let air through. Then I had a problem that the pen stayed in the up position. Most likely held by some kind of remaining magnetism that could withstand the force of the spring. A couple of M3 washers was used to reduce the contact area between the pen holder plunger and the top lid which made it work. http://i.imgur.com/PRGUa9U.jpg And in action: https://i.makeagif.com/save/QCDG_W controlled by a quick and dirty PDP-11 program : https://github.com/MattisLind/pdp11-plot Next is to draw some nice things on the plotter. Den mån 24 apr. 2017 kl 06:59 skrev Philipp Hachtmann via cctalk < cctalk@classiccmp.org>: > > > On 22.04.2017 15:21, David Gesswein via cctech wrote: > > Felt tip was also available. > > picture here http://ferretronix.com/1627/ > > Wow, great page! I think I also have the felt tip metal thing somewhere. > I have to find that plastic box with Calcomp stuff again! > >
