Re: x86/DOS system backup via rs232?
On Thu, 12 Nov 2015, Tom Moss wrote: I've never seen anything works on the sector level, but there are plenty of There is DITU (Disk-Image Transfer Utility) for MS-DOS, and it's free including C source code. I use it e.g. to image the hard disk of a DOS PC into a file (either network or parallel ZIP drive). ftp://ftp.oldskool.org/pub/misc/Hardware/IBM/PCjr%20magazines%20and%20resources/Software/Ditu/ I've modified the program a bit to support retries and TurboC. Christian
Re: DECtape reliability?
On 2015-11-13 01:16, Rich Alderson wrote: From: Johnny Billquist Sent: Thursday, November 12, 2015 3:44 PM However, that is still dealing with DECtapes. I'm curious about the ability to deal with LINCtapes, that don't use the same codes on the mark track (or whatever it was called, my memory fails me at the moment). Yes, "mark track". Thanks. I must be getting old. :-) The TD8E do not understand things at all, and everything have to be done in software, which is why I'm saying that it will actually deal with the LINCtape format if you want it to. Right. The TD8E only sees "single line passed" (= 3 bits of data + 1 bit of mark) and "four lines passed" (= 12 bits of data + 1 mark code) and is completely agnostic about the values. Yes, except it is of course kludgier than that, since DECtape mark codes are always 6 bits. The PDP-8 scheme of putting in 12 bit words means they do not align up with the mark codes easily. So, even more bit fiddling and packing... That's also why there are actually 129 12-bit words to a block, even though only 128 is used. (128 12-bit words are not evenly divisible by 18.) However, more "intelligent" controllers do all this processing of the mark track to identify start and end of block/tape, and all other processing, in the controller. Can you make them read out the contents and do the processing if you have different control codes? The state machine implemented in hardware for all the intelligent DECtape controllers will not recognize the 4-bit LINCtape codes at all, since the DECtape codes are 6 bits long. You'll just get a MARK Error. Thanks. That is what I sortof was suspecting. Interesting that the LINCtape use 4-bit codes. That makes it even more incompatible with DECtape. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
R: RE: ICL Quattro
Hi! I'm currently located in southern Italy, near Bari. Feel free to contact me if you're nearby. You can mail me at superv...@libero.it webmas...@supervinx.com Regards Vincenzo (aka Supervinx) Messaggio originale Da: Robert Jarratt Data:12/11/2015 21:38 (GMT+01:00) A: "'General Discussion: On-Topic and Off-Topic Posts'" Oggetto: RE: ICL Quattro > -Original Message- > From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of supervinx > Sent: 12 November 2015 07:21 > To: cctalk@classiccmp.org > Subject: ICL Quattro > > Hi! > I found an ICL Quattro desktop computer. > It looks in good shape, I had to repair only the PSU. > Powering it up, I see disk activity, but I haven't his (proprietary?) monitor. > On the back, I see a bunch of serial ports (DCE? DTE?) and a DB15 connector, I > guess for monitor/kbd attachment. > I tried to connect a terminal to the serial ports, with null modem and > straight > settings, but I had no answers. > Do someone have some infos about the proprietary monitor/kbd port? > Can it be run without the original monitor/kbd system? > Or should I think about it as a... doorstopper? :D > > Thanks! > -- > Vincenzo (aka Supervinx) > > --==ooOoo==-- > My computer collection: > http://www.supervinx.com/OnlineMuseum > > --==ooOoo==-- > You can reach me at: > www.supervinx.com > www.facebook.com/supervinx > http://www.youtube.com/user/supervinx > http://www.myspace.com/supervinx I can't help with the query unfortunately, but I would love to know where in Italy your collection is? In fact, it would be interesting to know where all the interesting collections in Italy are, as I do visit the country with some regularity. Annoyingly, I noticed just now that there is one near Siracusa, and I might have been able to visit that this past summer. Regards Rob
Re: x86/DOS system backup via rs232?
< On Nov 13, 2015 4:47 AM, "Christian Corti" wrote: > > On Thu, 12 Nov 2015, Tom Moss wrote: >> >> I've never seen anything works on the sector level, but there are plenty of > > > There is DITU (Disk-Image Transfer Utility) for MS-DOS, and it's free including C source code. I use it e.g. to image the hard disk of a DOS PC into a file (either network or parallel ZIP drive). > ftp://ftp.oldskool.org/pub/misc/Hardware/IBM/PCjr%20magazines%20and%20resources/Software/Ditu/ > I've modified the program a bit to support retries and TurboC. > > Christian I used to use a program called Laplink, which came with special serial and parallel option cables to transfer files from one dos machine to another. It was useful to "image" DOS computers with it. I don't think these were straight through cables and you needed the laplink software to be running on both sides. I see the cables on ebay, I picked up a set a few years ago to move contents of similar MS DOS system. Serial is much slower than parallel obviously. If you must use Linux, you may find something that emulates dos, or you can rewrite the receiving - end Linux equivalent of laplink if it has not already been done. Bill Degnan twitter: billdeg vintagecomputer.net
Re: Fw: new message
On 11/12/2015 10:25 PM, Jay West wrote: Apologies, not sure how that got through. Maybe a listmember got address-book-malware. Will see if the headers reveal anything that is easy to spot. J No worries. I know enough not to click on suspicious stuff like that... -- --- Dave Woyciesjes --- ICQ# 905818 --- CompTIA A+ Certified IT Tech -http://certification.comptia.org/ --- HDI Certified Support Center Analyst -http://www.ThinkHDI.com/ Registered Linux user number 464583 "Computers have lots of memory but no imagination." "The problem with troubleshooting is that trouble shoots back." - from some guy on the internet.
Re: x86/DOS system backup via rs232?
On 2015-11-13 12:36, william degnan wrote: I used to use a program called Laplink, which came with special serial and parallel option cables to transfer files from one dos machine to another. It was useful to "image" DOS computers with it. Ah, thank you. I have been trying to remember that name since this thread started. I've used extremely little DOS, but I remember seeing LapLink in there. I think it could even bootstrap itself across a serial port to a different machine, as long as DOS was installed. And then it could copy pretty much everything else over. I don't think these were straight through cables and you needed the laplink software to be running on both sides. I see the cables on ebay, I picked up a set a few years ago to move contents of similar MS DOS system. Serial is much slower than parallel obviously. Actually, the cables were straight through. The nice thing was that the serial cable had both the DE9 and DB25 on both sides. And it was combined with a parallel cable as well. So you had two cables and three connectors on each side. (Well, by straight through I mean that they were null-model cables.) Johnny
Re: x86/DOS system backup via rs232?
On Fri, 13 Nov 2015, Johnny Billquist wrote: (Well, by straight through I mean that they were null-model cables.)
Re: Fw: new message
On 11/13/2015 7:13 AM, Dave Woyciesjes wrote: On 11/12/2015 10:25 PM, Jay West wrote: Apologies, not sure how that got through. Maybe a listmember got address-book-malware. Will see if the headers reveal anything that is easy to spot. J No worries. I know enough not to click on suspicious stuff like that... Windows new feature ... Auto Click Sigh.
Re: Fw: new message
On 11/13/2015 09:29 AM, ben wrote: Windows new feature ... Auto Click Sigh. Oh, I don't know if that's a new feature. I recall getting a DSL modem and getting instructions to bring up Internet Explorer after the ethernet cable had been connected to my computer. Well, I don't normally use Windows, but I have a couple of systems with XP installed, so I dragged them out and plugged in the modem. I brought up IE8 without keying in a URL and viewed the display "Configuring your modem" was the message along with the pretty colors of the modem sender. Holy cow! It didn't even ask if I wanted to point the browser at the configuration page. Shades of COFEE. Does anyone else think that this is a great feature and not a security hole? --Chuck
Re: Fw: new message
No problem. Just make sure that emails from my friend the rich Nigerian prince get through! He's been talking to my banker at the UN. On Thu, Nov 12, 2015 at 7:25 PM, Jay West wrote: > Apologies, not sure how that got through. > > Maybe a listmember got address-book-malware. Will see if the headers reveal > anything that is easy to spot. > > J > > >
Z8000 Assembler anyone?
Hi, is someone on the list able to write Z8000 PLZ/ASM code? I have an the following source: u module $segmented $abs %3E00F600 global _u array [%572 byte] end u The problem is, that it is vital that _u has to be located absolute on the virtual memory address 0x3E00F600. The problem is now, that the while the object is compiled, _u is available on 0x0100f600 and I have no clue why.
Re: Z8000 Assembler anyone?
Hi, I found out so far, that %3e00 means, that the data is put on segment 62 (0x3e). Regarding to the Z8000 ASM handbook, segmented adresses are notated as <>offset, so in my case <<62>>%F600 - but of course it does not work and the assembler yields and error :( Oliver Lehmann wrote: Hi, is someone on the list able to write Z8000 PLZ/ASM code? I have an the following source: u module $segmented $abs %3E00F600 global _u array [%572 byte] end u The problem is, that it is vital that _u has to be located absolute on the virtual memory address 0x3E00F600. The problem is now, that the while the object is compiled, _u is available on 0x0100f600 and I have no clue why.
Re: Z8000 Assembler anyone?
Putting things at an absolute address requires putting things into segments that are handle by the linker or loader (depending on what era you are working in). the linker may place the output of your assembler into different segments. They may be set up to be relocatable at run time (most OSs insist on this feature). Once you are dealing with either a debugger or loader, or OS you have to find out how to get that segment assigned to the space you desire in the absolute addressing space. Usually the assembler will have directives to direct things to I/O or such depending on the architecture. I'd use this info to see if you have any luck figuring out what you need to do. you didn't mention whether this is a cross assembly tool, or if you have a working Z8000 OS with the tool. Others may infer that by knowing more about the things you refer to. however working Z8000 systems running an OS are a bit rare these days. thanks Jim On 11/13/2015 12:06 PM, Oliver Lehmann wrote: Hi, I found out so far, that %3e00 means, that the data is put on segment 62 (0x3e). Regarding to the Z8000 ASM handbook, segmented adresses are notated as <>offset, so in my case <<62>>%F600 - but of course it does not work and the assembler yields and error :( Oliver Lehmann wrote: Hi, is someone on the list able to write Z8000 PLZ/ASM code? I have an the following source: u module $segmented $abs %3E00F600 global _u array [%572 byte] end u The problem is, that it is vital that _u has to be located absolute on the virtual memory address 0x3E00F600. The problem is now, that the while the object is compiled, _u is available on 0x0100f600 and I have no clue why.
Re: Z8000 Assembler anyone?
Hi, it is a working Z8000 system with a ZEUS clone (SYSIII UNIX). Somehow the assembler must be able to put the segment information for the absolute adress of this array in the object. No idea how tho, as $abs will only work on segment 1. I have the original .o file from Zilog and there is the fixed adress already in it. But no idea how they did it. The assembler can not be called with a segment number to work on. The linker can, but the linker is not involved in creating the .o file the original object from the system: #67 nm /usr/sys/conf/u.o 3e00f600 A _u 0100 s u_d s u_p my object generated from my u.s: #68 nm u.o 0100f600 A _u 0100 s u_d s u_p Regards, Oliver jwsmobile wrote: Putting things at an absolute address requires putting things into segments that are handle by the linker or loader (depending on what era you are working in). the linker may place the output of your assembler into different segments. They may be set up to be relocatable at run time (most OSs insist on this feature). Once you are dealing with either a debugger or loader, or OS you have to find out how to get that segment assigned to the space you desire in the absolute addressing space. Usually the assembler will have directives to direct things to I/O or such depending on the architecture. I'd use this info to see if you have any luck figuring out what you need to do. you didn't mention whether this is a cross assembly tool, or if you have a working Z8000 OS with the tool. Others may infer that by knowing more about the things you refer to. however working Z8000 systems running an OS are a bit rare these days. thanks Jim On 11/13/2015 12:06 PM, Oliver Lehmann wrote: Hi, I found out so far, that %3e00 means, that the data is put on segment 62 (0x3e). Regarding to the Z8000 ASM handbook, segmented adresses are notated as <>offset, so in my case <<62>>%F600 - but of course it does not work and the assembler yields and error :( Oliver Lehmann wrote: Hi, is someone on the list able to write Z8000 PLZ/ASM code? I have an the following source: u module $segmented $abs %3E00F600 global _u array [%572 byte] end u The problem is, that it is vital that _u has to be located absolute on the virtual memory address 0x3E00F600. The problem is now, that the while the object is compiled, _u is available on 0x0100f600 and I have no clue why.
Software for small-memory PDP-11s?
Hey all -- Now that I have my PDP-11/05 running nicely, I'm curious what others are running on small systems like this -- until this point I've only played with larger (i.e. at least 28KW memory) systems. I have only 8KW of memory (with no viable options for expansion) and there's not much out there that I've found. There's paper-tape BASIC (which is always fun) and FOCAL, and PTS-11 (http://iamvirtual.ca/PDP-11/PTS-11/PTS-11.htm) which is pretty cool if a bit cumbersome. Any other suggestions? I'm also curious if any version of RT-11 that supports the TU58 could be made to run on this system -- I have two SLUs in the system so in theory I can boot from an emulated TU58. However RT-11 4.0's SYSGEN manuals suggest that 12KW is the minimum supported (and experimentation bears this out) and I can't find much in the way of manuals for RT-11 V3B -- which I believe is the earliest version with TU58 support. (V3B seems to be different enough from later versions that I'm not quite sure how the SYSGEN process works.) Thanks as always, Josh
Re: Software for small-memory PDP-11s?
On 11/13/2015 5:45 PM, Josh Dersch wrote: Hey all -- Now that I have my PDP-11/05 running nicely, What did you end up doing to arrive at that functionality? Did I miss some emails? I'm curious what others are running on small systems like this -- until this point I've only played with larger (i.e. at least 28KW memory) systems. I have only 8KW of memory (with no viable options for expansion) Can't MOS memory be put on the Unibus in an expansion chassis? and there's not much out there that I've found. There's paper-tape BASIC (which is always fun) and FOCAL, and PTS-11 (http://iamvirtual.ca/PDP-11/PTS-11/PTS-11.htm) which is pretty cool if a bit cumbersome. Any other suggestions? I'm also curious if any version of RT-11 that supports the TU58 could be made to run on this system -- I have two SLUs in the system so in theory I can boot from an emulated TU58. However RT-11 4.0's SYSGEN manuals suggest that 12KW is the minimum supported (and experimentation bears this out) and I can't find much in the way of manuals for RT-11 V3B -- which I believe is the earliest version with TU58 support. (V3B seems to be different enough from later versions that I'm not quite sure how the SYSGEN process works.) Thanks as always, Josh
Re: Software for small-memory PDP-11s?
On Fri, Nov 13, 2015 at 2:52 PM, j...@cimmeri.com wrote: > > > On 11/13/2015 5:45 PM, Josh Dersch wrote: > >> Hey all -- >> >> Now that I have my PDP-11/05 running nicely, >> > > What did you end up doing to arrive at that functionality? Did I miss > some emails? Total issues over the past year or so were: - Power supply needed some work. - CPU non-functional: traced down to a pair of microcode PROMs with bitrot; regenerated PROM images from the original service manual scans on Bitsavers. (Ugh) - Dead 128 word region in 8KW core plane: Traced down to a broken wire on the core mat; unfixable (by me at any rate). Lucked into a cheap (and fortunately working!) replacement on eBay a couple of weeks back. - Bad Boxer fan (completely dead, likely the cause of the PROM failures due to overheating many years back...) - Failing diagnostics: traced down to operator error on my part (misjumpered SLU interrupt vector). > > > > I'm curious what others are >> running on small systems like this -- until this point I've only played >> with larger (i.e. at least 28KW memory) systems. I have only 8KW of >> memory >> (with no viable options for expansion) >> > Can't MOS memory be put on the Unibus in an expansion chassis? Yes. "viable" in this case translates to "I have the parts on hand, or parts are easy to come by." Thanks, - Josh > > > > and there's not much out there that >> I've found. There's paper-tape BASIC (which is always fun) and FOCAL, and >> PTS-11 (http://iamvirtual.ca/PDP-11/PTS-11/PTS-11.htm) which is pretty >> cool >> if a bit cumbersome. Any other suggestions? >> >> I'm also curious if any version of RT-11 that supports the TU58 could be >> made to run on this system -- I have two SLUs in the system so in theory I >> can boot from an emulated TU58. However RT-11 4.0's SYSGEN manuals suggest >> that 12KW is the minimum supported (and experimentation bears this out) >> and >> I can't find much in the way of manuals for RT-11 V3B -- which I believe >> is >> the earliest version with TU58 support. (V3B seems to be different enough >> from later versions that I'm not quite sure how the SYSGEN process works.) >> >> Thanks as always, >> Josh >> >> >>
RE: Fw: new message
Here Here! Good work Jay!!! ++ Kevin Parker ++ -Original Message- From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Jerome H. Fine Sent: Friday, 13 November 2015 2:29 PM To: General Discussion: On-Topic and Off-Topic Posts Subject: Re: Fw: new message >Jay West wrote: >Apologies, not sure how that got through. > >Maybe a listmember got address-book-malware. Will see if the headers >reveal anything that is easy to spot. > So few get through that the VERY rare exception is a credit to your diligence and choice of a great filter. And as many of us all too often forget to say: THANK YOU FOR A GREAT SERVICE Jerome Fine
Re: x86/DOS system backup via rs232?
On 11/12/2015 05:52 PM, Chuck Guzis wrote: On 11/12/2015 01:54 PM, Jules Richardson wrote: As per subject line, does anyone know of any util that will back up an x86 PC running some variant of DOS (MS, Compaq etc.) via rs232 to a remote system? (Linux preferable on the remote, but other options exist) I'm not finding anything via Google, but it seems like the sort of thing that some of the folks here may have done for their systems in the past. I'm thinking something that will do a sector-by-sector transfer from a given partition (maybe only in-use sectors, implying some minor intelligence on the remote end to covert into a raw image, but "send everything" mentality is better than nothing) - extra points for retrying bad sectors. Any particular reason that RS232C has to be the linkup? Just lowest common denominator and based on what I have sitting around here (e.g. I don't have any MCA Ethernet boards, or ISA ones that will work on an 8 bit XT-type bus, only 16 bit). There are plenty of external drives that can use the parallel port with regular software. For example, hook up a ZIP drive. Hmm, I *might* know where there's one of those available - I'm not sure about cartridges, though (or if it's actually in working condition). The backup operation would certainly be quicker, and I am a bit concerned whether some of the old ST506/412 drives that I have will remain running for the length of time needed to do a serial transfer. Alternatively, you could boot DOS from floppy with INTERLINK/INTERSVR installed and use another DOS/WIN machine to do your backup. My assumption there was that Interlink needs a newer version of DOS, and that some of these systems that I have may be incompatible, but maybe it's worth me putting that to the test. I'm certain that options abound. Yes, I'm sure - just figured I'd ask here as it seems like the sort of nut that will already have been cracked :-) Vintage PCs are just a pain - new enough to make significant use of hard disk technology, but old enough that getting the data off them isn't quite as trivial as it likely would be on a much newer machine. I do find them *just* interesting enough to make it worthwhile trying to create a snapshot of how they were used, though (compared to the Win95-and-newer age where it's all so incredibly dull) cheers Jules
Re: x86/DOS system backup via rs232?
On Fri, Nov 13, 2015 at 5:08 PM, Jules Richardson < jules.richardso...@gmail.com> wrote: > On 11/12/2015 05:52 PM, Chuck Guzis wrote: > >> On 11/12/2015 01:54 PM, Jules Richardson wrote: >> >> >>> > Alternatively, you could boot DOS from floppy with INTERLINK/INTERSVR >> installed and use another DOS/WIN machine to do your backup. >> > > My assumption there was that Interlink needs a newer version of DOS, and > that some of these systems that I have may be incompatible, but maybe it's > worth me putting that to the test. FWIW, DOS 6.xx will boot on anything 100% PC-compatible, 8088 on up, and it shouldn't have a problem reading filesystems created by earlier DOS versions. Assuming you can write a bootable floppy and get INTERLNK onto it, that would probably be the easiest option. - Josh > > > I'm certain that options abound. >> > > Yes, I'm sure - just figured I'd ask here as it seems like the sort of nut > that will already have been cracked :-) > > Vintage PCs are just a pain - new enough to make significant use of hard > disk technology, but old enough that getting the data off them isn't quite > as trivial as it likely would be on a much newer machine. I do find them > *just* interesting enough to make it worthwhile trying to create a snapshot > of how they were used, though (compared to the Win95-and-newer age where > it's all so incredibly dull) > > cheers > > Jules > >
Re: x86/DOS system backup via rs232?
On Fri, Nov 13, 2015 at 5:08 PM, Jules Richardson < jules.richardso...@gmail.com> wrote: > Vintage PCs are just a pain - new enough to make significant use of hard > disk technology, but old enough that getting the data off them isn't quite > as trivial as it likely would be on a much newer machine. I do find them > *just* interesting enough to make it worthwhile trying to create a snapshot > of how they were used, though (compared to the Win95-and-newer age where > it's all so incredibly dull) > > Vintage PCs are ot my field of expertise, so just a random thought.. Could you put a 2nd disk drive in the machine, and copy the disk image to it? -- Charles
Re: x86/DOS system backup via rs232?
On 11/13/2015 05:10 PM, Josh Dersch wrote: FWIW, DOS 6.xx will boot on anything 100% PC-compatible, 8088 on up, and it shouldn't have a problem reading filesystems created by earlier DOS versions. Assuming you can write a bootable floppy and get INTERLNK onto it, that would probably be the easiest option. A couple of weeks ago, I dug out an old XT with a Quantum Q540 drive in it. It didn't want to start at first, but a couple of tapes on the side of the HDA caused the drive to spin up and come ready. Not wanting to tempt fate, I copied over the Interlink files from DOS 6.2 onto the XT system and booted a P3 system here running Win98SE and connected them with a Laplink parallel cable (I've still got a box of them). I think I ran interlnk on the XT and intersvr on the 98SE one (or maybe it was the reverse). At any rate I discovered that it was indeed possible to transfer files over even though the XT was running DOS 4.00 and the 98SE was running from a FAT32 partition. So yes, it can be done. Just in case, I also had a network card in the XT (an Artisoft AE/2T) and MSLANMAN ready. But I didn't need it. I do hope the Q540 will keep running for at least another decade, but if it doesn't, I've got the files backed up. I can always run it with an XTIDE card and a small CF card, if worse comes to worst. --Chuck
