test-drb July 2010

test-drb@ccmp.vtda.org

162 participants
213 discussions

Start a nNew thread

N8VEM project with my son?

by gerhard.kreuzer＠liftoff.at

13 years, 9 months

Serial interfaces (was Re: Any former Psion 5 owners out there?)

by ethan.dicks＠gmail.com

On 7/19/10, Liam Proven <lproven at gmail.com> wrote: > I am very happy to say that I have not used a serial port for anything > in a good 2-3y now, and not for anything more than a very occasional > sync of my Psion 7book... I use serial ports every week. > I really hate RS232. It is the most troublesome interface of any kind > on any computer I've ever used. I celebrate its disappearance with joy > and I hope never to have to use such a port again. All the crap with > baud rates, stop bits, parity bits, flow control and all that hateful > 1960s-ish nonsense is just a fading memory now and I hope I never have > to refresh it. It may be hateful 1960s nonsense, but if you know how it works, presuming you have the ability to control all the parameters of one end of a connection (software-controlled params, jumpers, straps, solder bumps, etc), you can still take something made in 1968 and attach it to something made in 2008. One recent case in point - After a couple of nights studying the schematics and the present state of the wiring (they mostly matched, after a fashion) of a 1970s Bridgeport Series II CNC mill (that has an embedded LSI-11 CPU!), I was able to build a round-8-pin-connector to DE-9 serial cable and interface the Bridgeport to a modern Dell that was also being used to drive a Shopbot. One thing relevant to this discussion about it was that we struggled with verifying that it worked when we tried to talk to it via a handy Thinkpad with a USB serial adapter (communication worked from the Bridgeport, but not to it). On a hunch, once we located a 6' extender cable, it worked on the Dell the first try. I'm reasonably certain the voltages on the USB serial adapter were out of spec for "true" RS-232 - the Bridgeport uses 1488s and 1489s, not modernish MAX232 drivers or other wiildly-forgiving line drivers/recievers. So for wiring up a passive cable, I was able to breathe life into a 30+ year old three ton machine. I was possible because I had a machine with a proper RS-232 port that stepped in where a machine that only had USB failed. > Apple did serial ports right on the Mac. You plugged things in, they > worked, thankyou and goodnight. Mac-designed things, sure, but Apple didn't make it easy to talk to the world full of "standard" serial devices (of which there were *lots* in the 1980s). > But try interfacing non-Apple kit to > Macs, or to anything else, and the horror-story of RS232 dropped you > into the nightmare of RS423 and so on. I shudder to recall. Exactly. Around the time the Mac switched from DE-9s to DIN8s, I was in the business of manufacturing serial interfaces for DEC hosts. I worked with sync and async RS-232 cables and ports and drivers and application code every day. I still found it to be a pain to get the right arrangement to hook a Mac up to some foreign device. It got easier later when you could just buy a suitable cable off the shelf, but for a time, it was difficult. > I really like USB. I really do not like USB. It takes hundreds of cycles and more to move a simple message, it's a host-based, not bi-directional design, and it's only available on somewhat newish kit. The host-based aspect of it is probably my biggest peeve - with a serial port, it's just TxD, RxD and perhaps some handshaking lines (more likely in the past, but sometimes supported in recent products). What that means to me is that I can buy a device that might be intended as a client (a Palm Pilot, to give a specific and handy example) and by dropping an app on it, turn what was manufactured to be a "receptive" device into an "active" device - such as use it as a VT100 replacement for configuring Cisco routers (boy my boss's eyes bugged out when I pulled a Palm out of my pocket, clicked in a serial cable and fixed something in seconds instead of leaving the room, retrieving a laptop, setting it up, etc., etc.) A USB-equipped Palm is meant to be addressed as a 'peripheral' and cannot be a 'host' - that limits its usefulness to me. > For storage, I preferred Firewire, but that's going away now, sadly. I will agree with you there. Just last night, I was helping a friend with a dying LaCie drive on a Macbook and I was happy we had a Firewire 800 cable that walked into the door at the right moment - it turned a 55 hour copy job via USB into a 31 hour copy job (dd to a container file - hopefully there's enough left of the old drive to extract enough files from to make the exercise worthwhile). > But USB works, is wonderfully versatile, fairly > idiot-proof and does everything I want or need: keyboard, mice, > scanners, printers, storage, modems and networking once in a blue > moon... It's terrific. It has some advantages - power for light-duty peripherals is great, simple connectors is great, not having to worry about DCE and DTE orientation is handy. It's great for mice and keyboards, sure, but I'm less convinced about higher-bandwidth uses. And lest you think this is all some sort of neo-luddite rant, I've built and programmed USB-based peripherals like the USB4LCD. I participate (occasionally in recent years) on the libusb developers' mailing list. I've written user-mode USB drivers with libusb. I've debugged USB command packets and initialization code. I'm using a USB mouse right now. USB still drives me nuts. I'm hardly advocating the death of USB (though I don't think I'd shed a lone tear over it). What disappoints me is the loss of a "real" serial port on portable hardware (starting with old Macbooks, but now across the Intel world as well) and the massive overhead that comes with using a "USB serial port" (like the well-documented problems that Makerbot folks have with FTDI driver issues - things work better when you don't have a USB physical layer between your application code and your Makerbot, but few people run that way, in part because for many bot owners, their Netbooks or Macbooks or whatever have any sort of way to talk to the outside world except WiFi, Ethernet or USB). I also do a lot with microcontrollers, MCS51-family and Atmel AVR, mostly. You _can_ make an 8MHz Atmel do USB in software (cf USB4LCD), but it's a whole lot easier to tell that same chip that there's someone connected on its UART and speaking async at 9600 8N1 - you get lots more of your ROM available for application code, and you can attach that MCU to a much larger field of devices with a simple serial port. -ethan P.S. - I know USB is "consumer-friendly" and I know I fall far, far outside the definition of a "consumer", but that doesn't change the fact that ubiquitous RS-232 ports make my life easier and USB comes with a bag of hassles.

13 years, 9 months

AW: N8VEM project with my son?

by gerhard.kreuzer＠liftoff.at

Hi Tom, Nice idea. Now lets think a moment, that your son fell in love with writing software during your project. You teach him pretty old stuff, so he find himself back in the 80's, and his friend calling him 'grandpa'..... Maybe it's a better approach to start out with modern equipment, I will give you a link. This is modern hardware, like boards built in the smartphones, you can create pretty little apps and you almost learn something about hardware step by step. After that, your son finds himself in 2011 and if he look around for some job, he will be welcome to companies. I think, he isn't that interesting for companies, when he notes down 'Skills in Z80 Assembler and CP/M'. Maybe the people there didn't know what he talking about .... On the other hand, I grow up with pdp8, Z80 and CP/M, we build the very first microprocessor based systems here in Austria as a very small company, which I founded with a friend during my studies at university, so I like this old stuff and I am a collector too and I also think, thats fine if there were young people knowing to use this stuff, but as a jump start for a main carrier, ....?? Look at: Hardware, especially look for 'development systems' http://www.antratek.com/EmbeddedMaster.html http://www.ghielectronics.com/ Software: http://www.microsoft.com/netmf/default.mspx With best regards Gerhard OE3GKC -----Urspr?ngliche Nachricht----- Von: cctalk-bounces at classiccmp.org [mailto:cctalk-bounces at classiccmp.org] Im Auftrag von cctalk-request at classiccmp.org Gesendet: Donnerstag, 29. Juli 2010 07:04 An: cctalk at classiccmp.org Betreff: cctalk Digest, Vol 83, Issue 48 Send cctalk mailing list submissions to cctalk at classiccmp.org To subscribe or unsubscribe via the World Wide Web, visit http://www.classiccmp.org/mailman/listinfo/cctalk or, via email, send a message with subject or body 'help' to cctalk-request at classiccmp.org You can reach the person managing the list at cctalk-owner at classiccmp.org When replying, please edit your Subject line so it is more specific than "Re: Contents of cctalk digest..." Today's Topics: 1. AT&T Eo (was Re: Before the iPad, there was the Newton) (Ray Arachelian) 2. M68000 ASM to machine code table (Andrew Burton) 3. RE: M68000 ASM to machine code table (dwight elvey) 4. Re: M68000 ASM to machine code table (Ray Arachelian) 5. Re: M68000 ASM to machine code table (Ray Arachelian) 6. Re: M68000 ASM to machine code table (Dennis Boone) 7. RE: Colour Digital Logo on DECwindows Login (Rob Jarratt) 8. Re: M68000 ASM to machine code table (Andrew Burton) 9. Re: Serial interfaces (was Re: Any former Psion 5 owners out there?) (Tony Duell) 10. Re: Colour Digital Logo on DECwindows Login (Richard) 11. Osborne HD distro floppy? (Chuck Guzis) 12. Re: gopher access from modern systems was Re: Coherent 3.1.0... (Jacob Dahl Pind) 13. Re: Colour Digital Logo on DECwindows Login (Dave McGuire) 14. Re: Colour Digital Logo on DECwindows Login (Dave McGuire) 15. X from a distance (was Re: Colour Digital Logo on DECwindows Login) (Ethan Dicks) 16. Re: X from a distance (was Re: Colour Digital Logo on DECwindows Login) (Pete Turnbull) 17. Re: Colour Digital Logo on DECwindows Login (Sridhar Ayengar) 18. Re: X from a distance (was Re: Colour Digital Logo on DECwindows Login) (Dave McGuire) 19. RE: Worth exhibiting at Maker Faire? (Erik Klein) 20. Re: Worth exhibiting at Maker Faire? (Evan Koblentz) 21. Re: retr0brite not so right? (Martin Goldberg) 22. N8VEM project with my son? (The Pitlog) 23. Re: RTEM-11 (Johnny Billquist) ---------------------------------------------------------------------- Message: 1 Date: Wed, 28 Jul 2010 13:45:20 -0400 From: Ray Arachelian <ray at arachelian.com> Subject: AT&T Eo (was Re: Before the iPad, there was the Newton) To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org> Message-ID: <4C506CB0.4070300 at arachelian.com> Content-Type: text/plain; charset=ISO-8859-1 On 07/28/2010 03:40 AM, Adrian Burgess wrote: > Admission : I have an EO 440... and I've still not got it working, it > came with batteries (long exhausted, obviously), and I don't have a PSU. > You can easily replace the batteries in that with standard NiCAD C cells (I think). I suppose in a pinch you could just replace it with regular alkaline C cells just to get it to power on - but obviously NEVER try to plug in a charger. The battery pack is just a heat sensor + all of the C cells wired together in series held together by shrinkwrapped plastic. Not sure about the power supply (don't have it infront of me, but if I remember, I can lookup the specs when I get home.) The Eo 880 has completely different sized NiCAD batteries, I'm not sure you can easily make replacements. Might be A or B cells. The 880 has a scsi port and a completely different internal hard drive - not sure what kind either are, but they don't look like anything standard. The 440 and 880 aren't that different otherwise, the 880's slightly faster and might have a larger hard disk, plus the scsi port. I vaguely remember them having a floppy port, but not sure which machine (or maybe both) had it. They also might have had parallel ports. My 880 came with a dead ROM, but I was able to get it to work using the ROM board from a 440 - I hope there's no extras on the 880 ROM card. The ROM card looks sort of like a PCMCIA card, but with a different connector. The dead ROM looked like it had a manufacturing defect, as if there was extra paint that prevented the soldering from working. They were awesome machines, and the Penpoint OS was quite nifty. Looked like a tabbed notebook, with each tab being a different application. I recall there was a tab UI for Windows 3.1 that resembled it. Penpoint's HWR sucked when compared to even an original Newton - you had to write each letter in a specific box, and even that didn't work right. Of course Newton Intelligence 2.0's HWR killed everything else's hand writing recognition, too bad the ipad doesn't use that. Rumor has it it's still (or was?) part of OS X, but I've no idea how to enable it, or use it. There was a copy of PenPoint for a specific black and white IBM Thinkpad (TP730?) which had an intel 386SX chip that ran at a faster clock rate, but was of course much slower than the Eo's Hobbit CPU. That Thinkpad could run a Pen version of Windows 95 as well. The magnetic pen from this machine could work on an Eo, but had a button that acted as the right click mouse button. I think there was some issue with the sensitivity of this pen when used with Eo's - if you got too close to the Eo's screen it would misread the location. Both sets of machines used a magnetic digitizer, so a regular stylus wouldn't work. If you don't have that specific pen, or one similar to it, your Eo is going to be unusable. Maybe some early Wacom (or other) tablets use this, not sure. The Hobbit CPU is an interesting beast. Not quite CISC, not quite RISC, they called it a CRISP processor I think. It's actually a stack based CPU that uses the stack (and of course the cache) instead of registers. Beautiful assembly on this beast... The only other machine that uses it AFIK was the original pre-release BeBox. This was originally designed to be friendly to C and C++, but of course Apple went with ARM instead for the Newts... If you had the cellular module you'd know it. It adds quite a lot of extra plastic to the bottom and has a desk phone handset on top. It's completely worthless now - at least in the US as analog cell service has been shut off. see: http://www.pcworld.com/article/188228/atandt_eo_440_personal_communicator_19 93.html AT&T even had a data service for it (beyond the fax application) that was based on the uucp commands. Was probably just email. Not sure. If you do manage to power it up, see if there's any interesting software on the hard drive (if it has one). I think there was a spreadsheet and some other office software for it. ------------------------------ Message: 2 Date: Wed, 28 Jul 2010 19:39:40 +0000 (GMT) From: Andrew Burton <aliensrcooluk at yahoo.co.uk> Subject: M68000 ASM to machine code table To: cctalk at classiccmp.org Message-ID: <760226.31289.qm at web23402.mail.ird.yahoo.com> Content-Type: text/plain; charset=utf-8 Hi, I am attempting to create an assembler to machine code table, something along the lines of: move.l a3,$12345678 -> $23 $CB $12 $34 $56 $78 Has anyone already done this? I don't mind whether the machine code is referenced in hexadecimal, octal or binary. I just need this to help me out with something - I have tried some disassemblers, but since they often (always?) turn data/text into ASM instructions and create false jumps etc. I am attempting to do it by hand. But before I can do that, I of course need the machine code references to start with! Failing that I will just have to create it myself - I have started, but having realised the number of possibilities for just the move.l instruction I feel that this could be another long project.... Regards, Andrew B aliensrcooluk at yahoo.co.uk ------------------------------ Message: 3 Date: Wed, 28 Jul 2010 12:49:08 -0700 From: dwight elvey <dkelvey at hotmail.com> Subject: RE: M68000 ASM to machine code table To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org> Message-ID: <SNT129-W53B323B806EEA4E6A32A07A3A80 at phx.gbl> Content-Type: text/plain; charset="iso-8859-1" Hi I have code in Forth that will assemble 68K code. Dwight > Date: Wed, 28 Jul 2010 19:39:40 +0000 > From: aliensrcooluk at yahoo.co.uk > Subject: M68000 ASM to machine code table > To: cctalk at classiccmp.org > > > Hi, > > I am attempting to create an assembler to machine code table, something along the lines of: > > move.l a3,$12345678 -> $23 $CB $12 $34 $56 $78 > > > Has anyone already done this? I don't mind whether the machine code is referenced in hexadecimal, octal or binary. I just need this to help me out with something - I have tried some disassemblers, but since they often (always?) turn data/text into ASM instructions and create false jumps etc. I am attempting to do it by hand. But before I can do that, I of course need the machine code references to start with! > Failing that I will just have to create it myself - I have started, but having realised the number of possibilities for just the move.l instruction I feel that this could be another long project.... > > > Regards, > Andrew B > aliensrcooluk at yahoo.co.uk > > ------------------------------ Message: 4 Date: Wed, 28 Jul 2010 15:55:45 -0400 From: Ray Arachelian <ray at arachelian.com> Subject: Re: M68000 ASM to machine code table To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org> Message-ID: <4C508B41.1070802 at arachelian.com> Content-Type: text/plain; charset=UTF-8 On 07/28/2010 03:39 PM, Andrew Burton wrote: > Hi, > > I am attempting to create an assembler to machine code table, something along the lines of: > > move.l a3,$12345678 -> $23 $CB $12 $34 $56 $78 > > > Has anyone already done this? I don't mind whether the machine code is referenced in hexadecimal, octal or binary. I just need this to help me out with something - I have tried some disassemblers, but since they often (always?) turn data/text into ASM instructions and create false jumps etc. I am attempting to do it by hand. But before I can do that, I of course need the machine code references to start with! > Failing that I will just have to create it myself - I have started, but having realised the number of possibilities for just the move.l instruction I feel that this could be another long project.... > See if you can grab it out of gas or as sources. as can be found here: http://john.ccac.rwth-aachen.de:8000/as/ or this: http://www.easy68k.com/ Generator ( http://squish.net/generator ) has these as well, plus a disassembler, but the above links are probably easier. Generator code is part of LisaEm, so grabbing LisaEm source would get you this too. ------------------------------ Message: 5 Date: Wed, 28 Jul 2010 15:58:06 -0400 From: Ray Arachelian <ray at arachelian.com> Subject: Re: M68000 ASM to machine code table To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org> Message-ID: <4C508BCE.5090201 at arachelian.com> Content-Type: text/plain; charset=UTF-8 actually this is probably exactly what you're after: http://goldencrystal.free.fr/M68kOpcodes.pdf ------------------------------ Message: 6 Date: Wed, 28 Jul 2010 16:01:17 -0400 From: Dennis Boone <drb at msu.edu> Subject: Re: M68000 ASM to machine code table To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org> Message-ID: <20100728200117.74956DA6001 at yagi.h-net.msu.edu> > I am attempting to create an assembler to machine code table, something > along the lines of: > move.l a3,$12345678 -> $23 $CB $12 $34 $56 $78 It appears the reason this doesn't exist in the form you describe is because of a somewhat bit-by-bit encoding. You already stumbled over this. But googling (hint) finds: http://goldencrystal.free.fr/M68kOpcodes.pdf http://www.ticalc.org/pub/text/68k/68kpm.zip De ------------------------------ Message: 7 Date: Wed, 28 Jul 2010 21:24:07 +0100 From: "Rob Jarratt" <robert.jarratt at ntlworld.com> Subject: RE: Colour Digital Logo on DECwindows Login To: "'General Discussion: On-Topic and Off-Topic Posts'" <cctalk at classiccmp.org> Message-ID: <009501cb2e92$d5fad6c0$81f08440$@jarratt at ntlworld.com> Content-Type: text/plain; charset="US-ASCII" > -----Original Message----- > From: cctalk-bounces at classiccmp.org [mailto:cctalk- > bounces at classiccmp.org] On Behalf Of Dave McGuire > Sent: 28 July 2010 00:06 > To: General Discussion: On-Topic and Off-Topic Posts > Subject: Re: Colour Digital Logo on DECwindows Login > > On 7/27/10 6:09 PM, Rob Jarratt wrote: > > I would agree that it sounds odd, but the person telling me knows his > stuff > > and this has been his experience. > > I'm sorry for how terrible this will sound, but I don't know how else > to say it...Where X is concerned, I know my stuff as well, and it > really > doesn't sound like your friend does. I mean no disrespect either to > you > or to him by that statement. I have an X11 window directly to the > right > of the window I'm typing this message in, it's showing colors, and it's > being displayed here from another system on the network. I run like > this all day, every day. I'm not running Exceed, but a different > (current technology) X server, but the concepts and protocol are the > same. > > > I suspect the SHM thing could be why it works on a real workstation, > > Nope. SHM (more properly "MIT-SHM") is only used for images. > (XImage > objects in particular, and sometimes pixmaps) Background colors or > drawn objects don't use SHM. It's used where image transfer speed is > important, like video and animations. > > > or perhaps it is some DEC-specific thing? > > Nope. I've run color X terminals (which is essentially what you're > doing with Exceed) from DEC X implementations, and they work fine. > This > is where it call came from, after all: DEC was a member of MIT's > Project > Athena, where X originated. I've never seen anything DEC specific > there > with the exception of DDX (device-dependent) code and their window > manager. The former is almost by definition vendor-specific, and the > latter is too, but perhaps less so depending on your point of view. > > Some background: An X client program (which includes your login > window, it's an X client too) initiates a connection to the X server > and > does a few things, including optionally making a call to > XGetVisualInfo() to get the list of "visuals" that the server supports. > A "visual" is basically a target display type that specifies the color > depth of the display, and might be something like "monochrome", "8-bit > greyscale", "8-bit pseudocolor", "true color", etc. Most X servers > support many different visuals simultaneously. The X client then > selects the visual it wants to use. (a note for the pedantic: yes, > I've > skipped many Xlib calls and details here for brevity) > > It's possible that Exceed does not have any color visuals that the > login window X client supports or wants to select. > > Note that I typed "OPTIONALLY makes a call to XGetVisualInfo()" > above. > It's possible for an X client to just use the "default" visual, and > that is server-specific, and usually configurable. On most X servers, > the default visual (actually visual "class") is set on the command line > when the server is started. I have no idea of how to set the default > visual for Exceed. > > We can drill down a bit further if you'll log into the machine via > Exceed, and run "xdpyinfo" and look at the output. Pay attention to > the > visual names and IDs that it reports as being available. Are there any > color visuals present? Also, look at the default visual ID for the > first "screen" entry. See if that visual ID is that of a color visual. > If it isn't, but if there are in fact color visuals present, it's > possible that the login window X client was written to only use the > default visual, which may not be a color visual under Exceed, but might > be a color visual on the workstation. It's also possible that the > login > window X client is configurable via its app-defaults file. We can > check > on that if you strike out with the visuals described above. > > -Dave > > -- > Dave McGuire > Port Charlotte, FL Well I definitely know very little when it comes to X. I don't have xdpyinfo as far as I know (it seems to be a Unix thing, I am running VMS 5.4). Exceed offers the following settings for the server visual: Auto Select GrayScale PseudoColor StaticColor StaticGray StaticGray (Depth 1) TrueColor I got Exceed to create a trace file, this is what it showed after I started the login program: Exceed for Win32 Version 11.0.0.0 Transports DLL For Network And Local Loopback Copyright C 1991-2005 Hummingbird Ltd. All Rights Reserved. 8:21pm Wed, Jul 28, 2010 Windows XP Version: 6.1 CJK installed Machine Class: 686 Model 23 Stepping 6 Num. of Processors: 1 Computer Name: WIN7TEST User Name: RobAdmin User Path: C:\Users\RobAdmin\AppData\Roaming\Hummingbird\Connectivity\11.00\Exceed\ Keyboard File: uk102.kbf Alternate Keyboard: us.kbf Imm32.dll status: Loadable CJK Input: Available. RENDER: Enabled Trace Initially On: Yes PC Address: 192.168.0.11:0 (TCP/IP) PC Address: fe80::1cba:bfa:3f57:fff4:0 (TCP/IP6) -1 > Set Font Path: default Load FDB report: Screen 0: Physical Monitor 1 (RDPDD Chained DD) - Video Capabilities: Primary Monitor : TRUE Depth : 32 Palette Manager : Not present Server Class : TrueColor Screen 0 Dimensions: top:0, left:0, width:1024, height:728. -1 > OpenFont: fixed -1 < C:\Program Files\Hummingbird\Connectivity\11.00\Exceed\Font\misc\6x13.fon -1 > OpenFont: cursor -1 < C:\Program Files\Hummingbird\Connectivity\11.00\Exceed\Font\misc\cursor.wff 3 > OpenFont: -*-menu-medium-r-normal--*-120-*-*-p-*-iso8859-1 3 < C:\Program Files\Hummingbird\Connectivity\11.00\Exceed\Font\dec100\menu12.fon Connection read error at 41988 3:Window (login_db) Cannot find color 'decwblue' Clearly that last entry is of some significance! I found a definition of decwblue and added it to the Exceed rgb.txt file. With that I got a colour logo. However I still get a horrible fine-grained black and white pattern for the background, rather than a smooth colour as shown here: http://toastytech.com/guis/DWlogin.gif. It is the background you get when you start the X server and before a client has connected. There don't seem to be any errors related to that though. There is also an error in the log above reading a font, is the font supposed to be on the X server or downloaded from the client? After I got the colour logo, I then logged in and got some other errors in the log too: 3 > OpenFont: decw$cursor 3 < C:\Program Files\Hummingbird\Connectivity\11.00\Exceed\Font\misc\deccurs.wff Warning: Access refused on ChangeHosts request based on security setting in Xconfig. Warning: Access refused on ChangeHosts request based on security setting in Xconfig. Connection read error at 144525 Not sure what ChangeHosts means and what the implications are. Anyway I have some colour now and it looks more like I would like it. Thanks Rob ------------------------------ Message: 8 Date: Wed, 28 Jul 2010 20:32:14 +0000 (GMT) From: Andrew Burton <aliensrcooluk at yahoo.co.uk> Subject: Re: M68000 ASM to machine code table To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org> Message-ID: <732996.66171.qm at web23406.mail.ird.yahoo.com> Content-Type: text/plain; charset=utf-8 Yes, that's exactly what I'm after. Thank you (and everyone else) for the help. I did try googling, but my choice of keywords kept sending me to wikipedia and various sites containing just assembler information. Regards, Andrew B aliensrcooluk at yahoo.co.uk --- On Wed, 28/7/10, Ray Arachelian <ray at arachelian.com> wrote: From: Ray Arachelian <ray at arachelian.com> Subject: Re: M68000 ASM to machine code table To: "On-Topic and Off-Topic Posts" <cctalk at classiccmp.org> Date: Wednesday, 28 July, 2010, 20:58 actually this is probably exactly what you're after: http://goldencrystal.free.fr/M68kOpcodes.pdf ------------------------------ Message: 9 Date: Wed, 28 Jul 2010 20:55:26 +0100 (BST) From: ard at p850ug1.demon.co.uk (Tony Duell) Subject: Re: Serial interfaces (was Re: Any former Psion 5 owners out there?) To: cctalk at classiccmp.org Message-ID: <m1OeCj0-000J1sC at p850ug1> Content-Type: text/plain > > On 7/27/10, Tony Duell <ard at p850ug1.demon.co.uk> wrote: > > Goin back ot the very early Unibus devices, there were 3 cards -- the > > device controlelr itself, an M105 address selector (which had jumpers to > > set the device address) and an M782/M7820/M7821 Interrupt card which had > > the jumpers to set the vector. > > Good point. I had forgotten about those - all of my comments apply to > SPCs (Small Peripheral Controllers), not backplane-sized devices > (there were a few SPCs even in the earliest days, like the LP11 I > mentioned). > Actually, the original SPCs were 3 boards. A dual-height board containing the specific device control/interface circuity that went in connectors C and D of the SPC slot, an M105 address selector module in connector E and a M782 (or M7820, M7821) interrupt logic module in connector F. That's why there are connections betweeen the various connectos on the SPC slot. I hae a DR11-A that's like that, and I think I have a KL11 (current loop only console port) done that way too. And possibly some others. Even when everything went on one quad-height SPC card, some devices still consisted of 3 independant circuits on that card, connected via the backplane connecotrs only, In other words there would be an address selector circuit on the quad card conencted to connector E only. It would output the approrpiate eanble signals on fingers of connector E, they would then be routed to connector C/D via the backplane and thus to the device logic. My PC11 is built that way. I also have some 3rd party dual height cards that combine the functions of the address sekector and interrupt logic and which go in connectors E?F, along with a dual-height SPC card in C/D -tony ------------------------------ Message: 10 Date: Wed, 28 Jul 2010 14:35:55 -0600 From: Richard <legalize at xmission.com> Subject: Re: Colour Digital Logo on DECwindows Login To: cctalk at classiccmp.org Message-ID: <E1OeDM3-0001bS-Od at shell.xmission.com> In article <009501cb2e92$d5fad6c0$81f08440$@jarratt at ntlworld.com>, "Rob Jarratt" <robert.jarratt at ntlworld.com> writes: > Well I definitely know very little when it comes to X. I don't have xdpyinfo > as far as I know (it seems to be a Unix thing, I am running VMS 5.4). Exceed > offers the following settings for the server visual: xdpyinfo is a standard X11 client. I would be very surprised if it wasn't on VMS, assuming you have the X11 client programs built for VMS and installed. > Clearly that last entry is of some significance! I found a definition of > decwblue and added it to the Exceed rgb.txt file. With that I got a colour > logo. However I still get a horrible fine-grained black and white pattern > for the background, rather than a smooth colour as shown here: > http://toastytech.com/guis/DWlogin.gif. It is the background you get when > you start the X server and before a client has connected. There don't seem > to be any errors related to that though. Usually this stuff is configurable with scripts. Last time I ran X11 regularly in the early 90s I had scripts that changed the background of the login screen. DEC has probably customized their standard login screen in a similar fashion. > There is also an error in the log above reading a font, is the font supposed > to be on the X server or downloaded from the client? The font database is maintained by the server. In X11, fonts are never on the client. > > After I got the colour logo, I then logged in and got some other errors in > the log too: > > 3 > OpenFont: decw$cursor > 3 < C:\Program > Files\Hummingbird\Connectivity\11.00\Exceed\Font\misc\deccurs.wff > > Warning: Access refused on ChangeHosts request based on security setting in > Xconfig. > > Warning: Access refused on ChangeHosts request based on security setting in > Xconfig. > Connection read error at 144525 > > Not sure what ChangeHosts means and what the implications are. It looks like your initialization script is attempting to do xhost to add hosts to the list of hosts to be trusted by this X server. See <http://www.netadmintools.com/html/xhost.man.html> This is the "old school" way of doing security with X11; I think they now have a public/private key pair based way of doing things. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/> Legalize Adulthood! <http://legalizeadulthood.wordpress.com> ------------------------------ Message: 11 Date: Wed, 28 Jul 2010 13:40:00 -0700 From: "Chuck Guzis" <cclist at sydex.com> Subject: Osborne HD distro floppy? To: cctalk at classiccmp.org Message-ID: <4C503330.3210.CF636E at cclist.sydex.com> Content-Type: text/plain; charset=ISO-8859-1 I've been asked by a collector not on this list if anyone has a copy of the floppy " "Drive C for the Osborne Computer" kicking around. Let me know and I'll pass it on. Thanks, Chuck ------------------------------ Message: 12 Date: Thu, 29 Jul 2010 00:05:20 +0200 From: Jacob Dahl Pind <rachael at telefisk.org> Subject: Re: gopher access from modern systems was Re: Coherent 3.1.0... To: cctalk at classiccmp.org Message-ID: <4C50A9A0.8030309 at telefisk.org> Content-Type: text/plain; charset=ISO-8859-1 On 07/26/2010 08:03 AM, Cameron Kaiser wrote: > The servers out there now typically either use a bespoke implementation, > since the protocol is so simple to implement (I believe Jacob's is written > in Rexx), or Bucktooth (my Perl implementation) or pygopherd (John > Goerzen's python implementation). I imagine also there are a few forgotten > sites out there still running UMN gopherd. John did some work on updating > the UMN gopher distribution and you can get it from > have actual been using UMN with my own patches here, have changed to gophernicus yesterday, after I had changed the code a bit to use loging to a file instead of syslog, and changed the logging format somewhat. I looked at bucktooth and had actual wanted to use the same format, but I couldnt find any descript of it. The one I wrote in arexx was mostly used to handle local transfers between machines here. -- Jacob Dahl Pind | telefisk.org | fidonet 2:237/38.8 ------------------------------ Message: 13 Date: Wed, 28 Jul 2010 17:55:49 -0400 From: Dave McGuire <mcguire at neurotica.com> Subject: Re: Colour Digital Logo on DECwindows Login To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org> Message-ID: <4C50A765.5000307 at neurotica.com> Content-Type: text/plain; charset=ISO-8859-1 On 7/28/10 4:24 PM, Rob Jarratt wrote: > Well I definitely know very little when it comes to X. I don't have xdpyinfo > as far as I know (it seems to be a Unix thing, I am running VMS 5.4). Ahh, for some reason I assumed you were running Ultrix. The xdpyinfo program is a fairly standard part of the X distributions, though, and it's likely there somewhere. > Exceed offers the following settings for the server visual: > > Auto Select > GrayScale > PseudoColor > StaticColor > StaticGray > StaticGray (Depth 1) > TrueColor Ok, that's a good selection that should support pretty much any client. > I got Exceed to create a trace file, this is what it showed after I started > the login program: ... > Cannot find color 'decwblue' Ah-HA! > Clearly that last entry is of some significance! I found a definition of > decwblue and added it to the Exceed rgb.txt file. With that I got a colour > logo. Excellent! Good sleuthing! > However I still get a horrible fine-grained black and white pattern > for the background, rather than a smooth colour as shown here: > http://toastytech.com/guis/DWlogin.gif. It is the background you get when > you start the X server and before a client has connected. There don't seem > to be any errors related to that though. Yes, that's the default X backround pattern. The default background for xdm should be settable in its resources via its app-defaults file. But...does DECwindows use something other than ordinary xdm by default? Do SHOW PROCESS and find out; I don't recall. > There is also an error in the log above reading a font, is the font supposed > to be on the X server or downloaded from the client? Standard X fonts reside on the server. I say "standard X fonts" because there's a trend in current X development to do font handling on the client side. That won't be happening here, though. > After I got the colour logo, I then logged in and got some other errors in > the log too: > > 3 > OpenFont: decw$cursor > 3 < C:\Program > Files\Hummingbird\Connectivity\11.00\Exceed\Font\misc\deccurs.wff > > Warning: Access refused on ChangeHosts request based on security setting in > Xconfig. > > Warning: Access refused on ChangeHosts request based on security setting in > Xconfig. > Connection read error at 144525 > > Not sure what ChangeHosts means and what the implications are. I'm not sure what that is either; I've never seen a message like that. I'm betting it's Exceed-specific. > Anyway I have some colour now and it looks more like I would like it. Excellent! -Dave -- Dave McGuire Port Charlotte, FL ------------------------------ Message: 14 Date: Wed, 28 Jul 2010 17:55:51 -0400 From: Dave McGuire <mcguire at neurotica.com> Subject: Re: Colour Digital Logo on DECwindows Login To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org> Message-ID: <4C50A767.6060201 at neurotica.com> Content-Type: text/plain; charset=ISO-8859-1 On 7/28/10 4:35 PM, Richard wrote: > The font database is maintained by the server. In X11, fonts are > never on the client. This (unfortunately) isn't the case anymore. There's a big trend nowadays toward moving font handling into the client. This is a bad idea for a bunch of reasons, but there's just no convincing the GTK crowd of anything. The results are gorgeous, but heaven help you if you try to run an X client from a few hundred network-milliseconds away. I regularly run X clients in Wisconsin and display them in Florida...thank heaven that stuff isn't using client-side font handling! > It looks like your initialization script is attempting to do xhost to > add hosts to the list of hosts to be trusted by this X server. See > <http://www.netadmintools.com/html/xhost.man.html> This is the "old > school" way of doing security with X11; I think they now have a > public/private key pair based way of doing things. Yes, xauth. Xauth has been around for about twenty years, though; it's just that it's sometimes not used because it's a pain in the butt. There's also a standardized method to use Kerberos 5 to authenticate clients to X servers, believe it or not! -Dave -- Dave McGuire Port Charlotte, FL ------------------------------ Message: 15 Date: Wed, 28 Jul 2010 18:00:38 -0400 From: Ethan Dicks <ethan.dicks at gmail.com> Subject: X from a distance (was Re: Colour Digital Logo on DECwindows Login) To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org> Message-ID: <AANLkTikz3RxyEhdwjYFmAW-t6wBLkU2=y5XuEWxn0gYx at mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 On 7/28/10, Dave McGuire <mcguire at neurotica.com> wrote: > ... heaven help you if you > try to run an X client from a few hundred network-milliseconds away. I > regularly run X clients in Wisconsin and display them in Florida... I used to occasionally run X clients in Wisconsin and display them at Pole via ~1mbps sat link (1200-1600ms RTT). It was painful but it would usually (eventually) work. -ethan ------------------------------ Message: 16 Date: Wed, 28 Jul 2010 23:16:37 +0100 From: Pete Turnbull <pete at dunnington.plus.com> Subject: Re: X from a distance (was Re: Colour Digital Logo on DECwindows Login) To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org> Message-ID: <4C50AC45.1020405 at dunnington.plus.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 28/07/2010 23:00, Ethan Dicks wrote: > I used to occasionally run X clients in Wisconsin and display them at > Pole via ~1mbps sat link (1200-1600ms RTT). It was painful but it > would usually (eventually) work. I didn't have quite that time problem, but I sometimes used to test external connectivity and do offsite troubleshooting from my desk at work by connecting to my SGI machine at home over dialup, or later over ISDN (one channel into home, one channel out from there to my ISP). That's when you realise how much Netscape is doing :-) -- Pete Peter Turnbull Network Manager University of York ------------------------------ Message: 17 Date: Wed, 28 Jul 2010 18:39:51 -0400 From: Sridhar Ayengar <ploopster at gmail.com> Subject: Re: Colour Digital Logo on DECwindows Login To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org> Message-ID: <4C50B1B7.1010604 at gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Dave McGuire wrote: >> It looks like your initialization script is attempting to do xhost to >> add hosts to the list of hosts to be trusted by this X server. See >> <http://www.netadmintools.com/html/xhost.man.html> This is the "old >> school" way of doing security with X11; I think they now have a >> public/private key pair based way of doing things. > > Yes, xauth. Xauth has been around for about twenty years, though; > it's just that it's sometimes not used because it's a pain in the butt. > There's also a standardized method to use Kerberos 5 to authenticate > clients to X servers, believe it or not! Let's also not forget about "ssh -X". Peace... Sridhar ------------------------------ Message: 18 Date: Wed, 28 Jul 2010 19:44:18 -0400 From: Dave McGuire <mcguire at neurotica.com> Subject: Re: X from a distance (was Re: Colour Digital Logo on DECwindows Login) To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org> Message-ID: <4C50C0D2.7020007 at neurotica.com> Content-Type: text/plain; charset=ISO-8859-1 On 7/28/10 6:00 PM, Ethan Dicks wrote: >> ... heaven help you if you >> try to run an X client from a few hundred network-milliseconds away. I >> regularly run X clients in Wisconsin and display them in Florida... > > I used to occasionally run X clients in Wisconsin and display them at > Pole via ~1mbps sat link (1200-1600ms RTT). It was painful but it > would usually (eventually) work. <keanu> Whoa. </keanu> -Dave -- Dave McGuire Port Charlotte, FL ------------------------------ Message: 19 Date: Wed, 28 Jul 2010 18:10:00 -0700 From: "Erik Klein" <classiccmp at vintage-computer.com> Subject: RE: Worth exhibiting at Maker Faire? To: "'General Discussion: On-Topic and Off-Topic Posts'" <cctalk at classiccmp.org> Message-ID: <065f01cb2eba$c6aca8b0$5405fa10$@com> Content-Type: text/plain; charset="us-ascii" I've displayed vintage computers at 3 of the last 4 West Coast Maker Fairs and it has gone very, very well. This year a number of CHM docent trainees "worked" the booth with me and had a blast. We got a fairly large display space (3 tables in a big booth) and we were packed open to close both days. I had folks playing with machines during setup and teardown! You are well within the spirit of the Maker Faire even if you aren't actually "making" things. You are still keeping them alive and happy and the attendees love the nostalgia vintage machines offer. I've gone totally hands-on with each display and made sure to include as many familiar machines as I can since the audience isn't quite as geeky as we are. So, for me anyway, lots of Apples, Atari's and Commodores and fewer Northstars, Eagles and IBM 5100s. That said, I did have people switching in programs on an Altair 8800 this year, alongside the Apple ][e, C-64, IBM PCjr and Atari 800. (Sorry so slow with a reply, but I'm still recovering from my vacation.) ----- Erik Klein www.vintage-computer.com www.vintage-computer.com/vcforum - The Vintage Computer Forums marketplace.vintage-computer.com - The Vintage Computer and Gaming Marketplace -----Original Message----- From: cctalk-bounces at classiccmp.org [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Evan Koblentz Sent: Sunday, July 25, 2010 7:52 PM To: General Discussion: On-Topic and Off-Topic Posts Subject: OT: Worth exhibiting at Maker Faire? Hi all -- My club (MARCH) is scheduled to exhibit at the inaugural Maker Faire NYC. I'm starting to have second thoughts because we don't "make" anything, we just make old things work again. Who here has been to a Maker Faire event, and if so, would a vintage computers exhibit be well received by the audience? ------------------------------ Message: 20 Date: Thu, 29 Jul 2010 00:09:45 -0400 From: Evan Koblentz <evan at snarc.net> Subject: Re: Worth exhibiting at Maker Faire? To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org> Message-ID: <4C50FF09.3070705 at snarc.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed > I've displayed vintage computers at 3 of the last 4 West Coast Maker Fairs and it has gone very, very well. Thanks Erik. Of all the people who replied, you're the only one who answered the actual question that I asked! :) ------------------------------ Message: 21 Date: Wed, 28 Jul 2010 01:13:59 -0500 From: Martin Goldberg <wgungfu at gmail.com> Subject: Re: retr0brite not so right? To: "General Discussion: On-Topic Posts Only" <cctech at classiccmp.org> Message-ID: <AANLkTimGPnpM3wmG+8AJzQWgFBhjqJFsXtrd-kZJ3Dze at mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Well, the process was first introduced in January of '09, so the year test would have been passed on those done in the first six months. The only thing that's been reported so far is in some cases is a reversal of the whitening process, with some of the treatments starting to yellow again. Merlin (the originator) said: "Retr0bright reverses the yellowing process, it's not a permanent cure. If the surface of the plastic is still open to the air, it will yellow again, as the bromine free radical reaction is reversible. The permanent fix it is to coat it with clear satin acrylic lacquer to seal the surface off from the air. No oxygen, no oxidation; simple, really." It's available in hobby shops (in spray form) and usually used my modelers and the like to protect paint, it's not a heavy varnish or something similar. As far as blooming, that usually occurs in areas where the spreadable version of the mixture was left on for to long or allowed to dry. I have not heard of it happening when submerging in the pure liquid version. In other cases, some people have decided not to use the actual mixture and simply use the peroxide portion as a shortcut which has caused blooming. The process will also caused blooming on dark colored plastic, and as such is only for white/tan colored plastics. I've personally used it on an Apple III, and white Bally Computer case with stellar results, which you can see here: http://www.atariage.com/forums/topic/138244-how-to-remove-yellowing-from-an- old-atari-case/page__view__findpost__p__1912172 That entire thread is also full of further discussion, testimony (and pictures) as well as comments by some who have had blooming as result of one of the reasons mentioned above. Marty On Tue, Jul 27, 2010 at 3:30 PM, Teo Zenios <teoz at neo.rr.com> wrote: > > ----- Original Message ----- From: "Fred Cisin" <cisin at xenosoft.com> > To: "General Discussion: On-Topic and Off-Topic Posts" > <cctalk at classiccmp.org> > Sent: Tuesday, July 27, 2010 4:09 PM > Subject: Re: retr0brite not so right? > > >>> This appeared on the cbm-hackers list today. Anyone have a thought on it? >> >> The fact that too much will cause damage does NOT mean that half as much >> causes half the damage. ?It is far from linear, and there may be >> thresholds. >> >> >> To quote Paracelsus: >> Poison is in everything, and no thing is without poison. The dosage makes >> it either a poison or a remedy. >> >> Admittedly, Paracelsus was expert on neither computers nor plastics. >> >> -- >> Grumpy Ol' Fred ? ? cisin at xenosoft.com >> > > Depends on what you are talking about. > > If the concentrations are enough to cause visible damage in 2 hours then I > would think that 1 hours use would cause some damage that might take a while > to show up. You also have to assume that the chemicals are being used up as > the process is going meaning the concentration is slowly dropping while it > is sitting, so damage can be going on the second the plastic is being > dropped in. Plastic soaks up chemicals that stay even when you rinse them > out (I can smell pineapple in a plastic container long after it has been > washed and dried), which is why you never store water in anything that seen > chemicals. So I can see some reactions still going on inside the plastic > (depending on its density) even after you have cleaned it off. > > If you mean X concentration will cause damage then .5X concentration will > cause half that damage, then no. > > Long term damage could be as simple as the plastic decaying from UV ?light > after you leached the UV inhibitor from the surface using retro-bright. > Since everyone mixes up a slightly different batch of > chemicals/concentrations, does different prep work, ?and uses it for varying > lengths of time in different sunlight and heat conditions on all kinds of > plastics (which might have UV inhibitors or none at all depending on the age > and manufacturer) who knows if there will be damage or not either short term > or long term. > > Personally if the item is rare and would be worth more "whiter" for a quick > sell, then clean it up. If you are going to keep that same item as a > permanent part of the collection then you might as well wait a few years and > see how this all pans out. > > > > > > ------------------------------ Message: 22 Date: Wed, 28 Jul 2010 08:58:01 -0400 From: The Pitlog <tom.manos at gmail.com> Subject: N8VEM project with my son? To: cctech at classiccmp.org Message-ID: <10C9B55E-86C1-4081-98DC-4A78F38F5B59 at gmail.com> Content-Type: text/plain; charset=us-ascii Hi, I'm about to embark on building a single board computer (an N8VEM) as a project with my 15yo son. My son is a typical gamer kid who spends most of his waking moments either in front of a computer playing WOW, or reading SF and fantasy. I'm trying to find something a bit more positive about technology for him to enjoy. The operative word is enjoy. Anyway, he's agreed to give it a shot, and I'm thinking through how to make this a great experience for him. I've got a fair amount of background (BSEE and MSCS), and understand the technology, at least theoretically, from bare silicon to flip flops, to computer block diagrams. I'm reasonably well versed in Z80 assembly language programming and the CP/M operating system, which is what the N8VEM runs. I've got the equipment (electronics soldering station, good DMM, logic probe, bench power supply, etc) and have access to an OScope if I need one. And I actually sort of remember how to use them :) My question for you folks is: At what level, and in what order should I try to teach some theory to my son? Should I do some background before we start soldering sockets and ICs to boards and wiring things up, or just jump right in to building? I've been thinking jump in and fill in the theory as I can as we go along. In the end we should have something that looks like an Altair with more modern HW: solid state drives, and maybe IDE, but still has a front panel and which runs traditional CP/M 2.2. I have lots of old software to run there, languages, editors, games, etc. Have any of you tried something like this with your children? Experiences and wisdom gratefully accepted! Cheers, Tom ------------------------------ Message: 23 Date: Wed, 28 Jul 2010 18:06:05 +0200 From: Johnny Billquist <bqt at softjar.se> Subject: Re: RTEM-11 To: cctalk at classiccmp.org Message-ID: <4C50556D.8060605 at softjar.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed "Jerome H. Fine" <jhfinedp3k at compsys.to> wrote: >Johnny Billquist wrote: >>> >> Agreed! The problem is that I have been unable to locate any >>> >> documentation for which RT-11 EMT requests are handled by >>> >> the RTEM-11 RTS along with the differences between RT-11 >>> >> and the RTEM-11 RTS. >> > >> > *sigh* Still not an RTS... RTEM-11 is a program, not an RTS. There is >> > no RTS concept in RSX. > > I agree. I forget to use the correct terminology. If you can indulge me > now that I have turned 72 years old, that would be appreciated. I'll try. But please try to read, understand, and apply what I write, or else we'll not get anywhere. >>> >> But for RTEM-11, I don't have any documentation at all. >> > >> > The obvious answer is that this is documented in the manual that came >> > with RTEM-11. Now, you just need to find someone who has it... (not me) > > Well, since we both agree that it is extremely unlikely that RTEM-11 will > ever be used, ... > >>> >> I have access to both V7 and V10.1 or RSTS/E. However, I have not >>> >> found the >>> >> program in V10.1 which copies files from RT-11 files structures to >>> >> RSTS/E file >>> >> structures. >> > >> > And this has just about nothing to do with the question on how RSTS/E >> > determines which RTS a program runs under, but anyway... > > Obviously, but it is difficult to test a program when I can't even "RUN" > it. Yes, but don't mix questions. Keep the thread of each question intact, and start a new question when you have something else you wonder about, or use whatever thread already exists that deal with that specific topic. And I use "thread" very loosely here. This mail have several different threads dealing with different topics related to RT-11, RSTS/E, RTEM and various other issues. So, for the question on how RSTS/E figures out which RTS a program should run under should not suddenly be the question on how to copy a file from an RT-11 media into RSTS/E V10. >> > As I've said before, I know about FIT. If DEC replaced FIT with >> > something else in RSTS/E V10, then you just have to search around in >> > the system. Look at the help files. That's usually a good place to >> > start searching. Read the manuals. I think the V10 manuals are online >> > somewhere as well. > > The work around that I use is to MOUNT DL0: which already has > the files (Having been copied by FIT from DY0: to DL0:). Yes. You have a working work-around. Which is good. > If anyone else is reading this, can you suggest anything? I did suggest how you should go about finding the answer yourself. You are of course free to keep asking if someone else already have the answer for you, but noone have responded yet... >> > And is still done to this day in RSTS/E and RSX. And while exactly the >> > same, something similar is done in Unix systems, Windows systems, VMS >> > systems, and any other system I can think of. >> > The reason being that for debugging you don't want a compiler to >> > optimize things, and you want to include symbol tables in the compiled >> > image for debugging purposes, while you do not want that stuff for the >> > finished program, since it takes space and makes the program slower >> > (symbol table and non-optimization). > > Actually, for VMS systems, if my faulty memory is able to remember > correctly, the > compiler builds symbol tables outside of the code and data in a manner which > does not impact at all on the program when debugging is NOT taking place. Well, not entirely true. You will still take up a lot more space on disk for the image. And the symbol table is still around in memory even when not needed. It is true that it does not impact on the speed, nor the actual physical memory used by the program, since pages are only mapped in when needed, but there is (as always) more to it than that. In a way, the same is always true. The symbol table is always outside of the actual image. Be it in a separate section of the binary, or a separate file (RSX places the information in a separate file, which is only created if you ask for it). But for the optimization, that you cannot avoid. When you want to debug a program, you do not want the compiler to optimize the code, because that can, and normally will produce code that is very different from what you wrote. > From what I remember, the FORTRAN compiler set up the symbol tables for > debugging so that there was no impact on the code when debugging was not > active. Your view of "impact" is way to narrow. >> > Modern systems however, usually allows the debugger to be dynamically >> > attached to a running program so you don't have to include that bit >> > already at the link stage. > > Under RT-11, the SD(X).SYS device driver traps the BPT instruction when > it is executed no matter what state the hardware is in. Of course, this > also > STOPS ALL other code from executing as well. This is not considered a > problem under RT-11. No, but it would be a major problem under RSX and RSTS/E, which is why a similar solution cannot exist for them, despite what you think you read in the sources of the SD(X).SYS driver for RT-11. > Under TSX-Plus, the debugger STOPS only the code for that job on that > terminal from running. There is also a separate debugger for the TSX-Plus > operating system which does stop everything in the system. Correct me if I'm wrong, but don't TSX more or less provide like a virtual PDP-11 for each user, so that it appears as if they have all of a machine for them self, so in essence, it would work just as fine as on a real RT-11 system? >>> >> However, by V05.04 of RT-11, DEC developed the SD(X).SYS device >>> >> driver which allowed a program to have a BPT instruction without the >>> >> requirement to include ODT as part of the code. If the user LOADed >>> >> SDX.SYS prior to executing the program with the BPT, but without >>> >> ODT included, the code in SDX.SYS initialized the required VECTOR >>> >> to trap the BPT instruction when SDX.SYS was LOADed. The code >>> >> in SDX.SYS then performed all of the functions that ODT supported >>> >> (and a few others as well) without adding any extra code to the program >>> >> being tested. It is even possible to place a BPT in the monitor code >>> >> and test those instructions as well. >> > >> > Ok. So, no symbol table stuff, and no possibility to add breakpoints, >> > watchpoints and other stuff in the program until you hit atleast one >> > BPT in the code which cause the code in SDX to be called? > > Actually, no! A symbol table is allowed, but I normally never use one > since the listing of the program has always been sufficient. Also, if the > code is already loaded into a known location in memory (e.g. the RT-11 > Resident Monitor), it is possible to place a BPT in the desired instruction. How does the device driver know what symbol table to load? Or is it just that you can load a symbol table when you are in the debugger, if you want to? And hopefully you will load the right symbol table at that point, if you are interested? >> > RT11 is a single user system, where the OS do so much less for you >> > that this concept is even possible. For more complex systems, you >> > cannot do things this way. > > AGREED!! Good. So then we can perhaps lay the idea of this SD(X).SYS driver in any form being available, or even possible, under RSTS/E or RSX to rest. :-) Johnny End of cctalk Digest, Vol 83, Issue 48 **************************************

13 years, 9 months

IBM RS6000 ( Power Server 520) parts

by dm561＠torfree.net

A while back I offered a '92 vintage RS6000 (Power Server 520, Type 7013, Model 26-10855); as expected there was no interest considering the weight, so it was scrapped (as well as the x-series 205 eServers also mentioned). However, I did keep some cards and a few parts in case someone needs one some day, including the following RS6000 cards: 4 - Memory cards (53F3091, 8 x 68X6271 modules on each card); AFAIK these are 4M x 40 bits. 2 - 16 port RS-232 cards (59F3824) and one matching 16 port distribution panel and cable. 1 - SCSI I/F card (31G9729). mike (in Toronto)

13 years, 9 months

Colour Digital Logo on DECwindows Login

by mcguire＠neurotica.com

On 7/29/10 5:46 PM, Rob Jarratt wrote: >> Usually this stuff is configurable with scripts. Last time I ran X11 >> regularly in the early 90s I had scripts that changed the background >> of the login screen. DEC has probably customized their standard login >> screen in a similar fashion. > > Someone else has made a similar suggestion. I will have a hunt round, but > again, because this is an old version of VMS it may not have this. The program you're looking for there is "xsetroot". It's a very old program and a standard part of the X Consortium's distribution, so it was likely included in your DECwindows distribution. -Dave -- Dave McGuire Port Charlotte, FL

13 years, 9 months

Colour Digital Logo on DECwindows Login

by legalize＠xmission.com

In article <00ba01cb2f67$90c5f320$b251d960$@jarratt at ntlworld.com>, "Rob Jarratt" <robert.jarratt at ntlworld.com> writes: > > xdpyinfo is a standard X11 client. I would be very surprised if it > > wasn't on VMS, assuming you have the X11 client programs built for VMS > > and installed. > > This is a pretty old version of VMS and I can't find that utility. An old version of VMS most likely won't install these utilities by default. I believe there are optional packages you can apply to VMS on top of the base installation. Chances are you'll find an optional package of X11 client programs. Do you have xterm? If you don't have xterm, then it sounds like its the optional package thing. (Pretty much *everyone* needs xterm.) If you do have xterm, then it sounds like they opted not to install xdpyinfo for VMS, or its still an optional package of "less used utilities for X11" that you have to find. Or you could just compile it :-). -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/> Legalize Adulthood! <http://legalizeadulthood.wordpress.com>

13 years, 9 months

PC Tech Journals to go

by dave＠mitton.com

I offered these twice before, but arrangements fell through. I have the following collection of magazines to give for the cost of shipping. USPS Media Mail works best (source zip code 01845) or pickup in Lawrence MA area. PC Tech Journal 1984 - 1988 1984 V1 n: 8/May,9/Jun 1984 V2 n: 1/Jul,6/Dec 1985 V3 n: 1,2,2,3,3,4,4,5,5,6,7,8,9,10,11,12 1986 V4 n: 1-13 1987 V5 n: 1-13 1988 V6 n: 1,2,3,4,5,6,7,8,10,11,12 1989 V7 n: 1,2,3,4 Extras: PC Products: Jan 84, Jan 85, Feb 85, Jul 85 The volumes fill a typical printing paper carton. ---- Dave.

13 years, 9 months

Colour Digital Logo on DECwindows Login

by legalize＠xmission.com

In article <009501cb2e92$d5fad6c0$81f08440$@jarratt at ntlworld.com>, "Rob Jarratt" <robert.jarratt at ntlworld.com> writes: > Well I definitely know very little when it comes to X. I don't have xdpyinfo > as far as I know (it seems to be a Unix thing, I am running VMS 5.4). Exceed > offers the following settings for the server visual: xdpyinfo is a standard X11 client. I would be very surprised if it wasn't on VMS, assuming you have the X11 client programs built for VMS and installed. > Clearly that last entry is of some significance! I found a definition of > decwblue and added it to the Exceed rgb.txt file. With that I got a colour > logo. However I still get a horrible fine-grained black and white pattern > for the background, rather than a smooth colour as shown here: > http://toastytech.com/guis/DWlogin.gif. It is the background you get when > you start the X server and before a client has connected. There don't seem > to be any errors related to that though. Usually this stuff is configurable with scripts. Last time I ran X11 regularly in the early 90s I had scripts that changed the background of the login screen. DEC has probably customized their standard login screen in a similar fashion. > There is also an error in the log above reading a font, is the font supposed > to be on the X server or downloaded from the client? The font database is maintained by the server. In X11, fonts are never on the client. > > After I got the colour logo, I then logged in and got some other errors in > the log too: > > 3 > OpenFont: decw$cursor > 3 < C:\Program > Files\Hummingbird\Connectivity\11.00\Exceed\Font\misc\deccurs.wff > > Warning: Access refused on ChangeHosts request based on security setting in > Xconfig. > > Warning: Access refused on ChangeHosts request based on security setting in > Xconfig. > Connection read error at 144525 > > Not sure what ChangeHosts means and what the implications are. It looks like your initialization script is attempting to do xhost to add hosts to the list of hosts to be trusted by this X server. See <http://www.netadmintools.com/html/xhost.man.html> This is the "old school" way of doing security with X11; I think they now have a public/private key pair based way of doing things. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/> Legalize Adulthood! <http://legalizeadulthood.wordpress.com>

13 years, 9 months

wanted, item or pattern/wiring info for sunn 100u disk/tape bulkhead

by curtis＠hawkmountain.net

Anyone have an extra (yeah right) sun 100U disk/tape bulkhead/connectors/wiring ? (see http://picasaweb.google.com/ducktime2010/MartyComputerStuff#548191063618978…) If not, anyone have a means of making me an accurate patern/scan/etc of the plate(s) and detailing out the ribbon wiring ? (as if I can't find one, maybe I can make one). Thanks, -- Curt

13 years, 9 months

IRQs and such (was Re: Serial interfaces)

by bqt＠softjar.se

Ethan Dicks <ethan.dicks at gmail.com> wrote: > On 7/27/10, Charlie Carothers <csquared3 at tx.rr.com> wrote: >> > Tony Duell wrote: >>> >> All decent buses allow you to share interrupts -- the ''design' of the >>> >> interrupt suystem on the ISA bus is one reason to hate that bus.. >>> >> >>> >> Very well designed buses (Unibus :-)) have each card send an interrupt >>> >> vector which directs the CPU to the right ISR. >> > >> > ... I'm just curious as to how each card knows what interrupt >> > vector value to send? Jumpers/switches on each card? > > Can be done that way... > >> > A "Unibus Interrupt Vector Value Guru" somewhere who assigns the values? > > In a sense, yes.... > > All the way back to 1970, DEC published lists in various system > handbooks about their own breakdown of assigned CSRs (Control Status > Register - typically the first I/O address that the card responds do, > though there's no way to magically know how many addresses a card will > answer at) an interrupt vectors for disk controllers, comms > controllers, etc. For older devices, DEC would reserve up to four > locations for a given interface, allowing for primary through > quaternary cards to be installed on the same bus. Later, there was > typically a primary address given, then a scheme to calculate a > non-conflicting "floating" address, but by then folks were rarely > installing four of anything except perhaps serial interfaces or MSCP > disk interfaces. You drift from the question, Ethan... :-) To answer the original question, it was done in one of two ways. Either you set a bunch of DIP-switches to the value that should be sent as the interrupt vector, or else you programmed the card with the interrupt vector it should send. Older cards usually use DIP-switches, while modern cards usually are programmed. Remember that you don't need the interrupt vector to talk with the card in polled mode, so you can talk with the card, and set up stuff before you allow it to start generating interrupts... What you drift into, Ethan, is then the question of deciding what interrupt vector to actually set on the card. This is also an interesting topic. Very few devices have more than one reserved vector. That is, if we talk of one vector as assigned to one card. Some cards had more than one vector because of the nature of the card, such as a terminal interface which actually use two vectors. One vector for receiving characters, and one vector for transmitting characters. I can only remember one device where more than one set of vectors were reserved, and I think it ran to eight for that one. I'd have to look in a processor book to check the actual name of that device, though. For all other devices, vectors are allocated from the "floating" vector space, which is everything from 300(8) to 774(8). Each vector takes two words, the the lowest two bits of a vector is always 0, and are usually not even available on the switch pack, or register where you program the vector. For a device like a terminal interface, the next bit was also reserved, since it was used to differentiate between transmit and receive, so two vectors were programmed with one switch pack. There was/is a definitive schema for in which order vectors should be assigned, but it is more or less not used since all the OSes that atleast I have tried actually probe what vector each card uses, and use that vector instead of having some fixed scheme. All that is required is that no two devices use the same vector, because that would be bad. > I can give an example of how this worked in practice by describing a > 3rd-party device I used to make and maintain, the COMBOARD. It wasn't > on DEC's list, so we picked an arbitrary CSR up in "unassigned" space. > We gave our customers a list of eight preferred CSR addresses to use, > though any address in the I/O page would work. The user set the CSR > address on a 10-position DIP switch, then, once the machine was > powered on and running, would load the driver and tell it, via setup > files, what CSR the card(s) will respond at. Our product had a 16-bit > double-one-way register we called "the window". If the PDP-11/VAX > wrote a value, the 68000 on the card could read it, and if the 68000 > wrote a value, the PDP-11/VAX could read it (a processor could never > read back the value that it just wrote). One of the values passed > during initialization was the vector to use (as stated in a config > file that was written by the user, or by us as a factory default). > The board would retain that value and drop it on the bus during an > interrupt request. > > So for our product, the CSR was set by switches that were not meant to > be changed, but the interrupt vector could be changed at every reboot. > Real DEC devices did a number of different things, the older ones > typically relying on jumpers or switches, the newer devices relying on > some mechanism to assign or calculate the values dynamically. Well, there are really only two ways. Either dip switches, or programmed. :-) > In practice, there weren't as many kinds of interfaces for the Unibus > as there ended up being for the ISA bus, so it may sound like anarchy, > but it wasn't. I think in 20-ish years of the hey-day of the Unibus, > they only ever reassigned CSR addresses once or twice, but it was > extremely unlikely that you'd have a particular obscure peripheral > from 1970, literally, on the same bus as a stack of c. 1990 disk > controllers and Ethernet interfaces. Electrically, they would work > together, but logically, a user would have no need to use 20-year-old > devices. The only "old" device we ever used on our VAX-11/750 was an > LP11, an original line-printer interface. The rest of the cards in > our machine were manufactured 10-15 years later. Some of our devices, > then, had a DIP switch for CSR assignment, but not for vector > assignment. Something older, like a PDP-11/34, was probably a > different story. No, it's just the same for any PDP-11, just as for VAXen with Unibuses. You *must* use dip-switches for CSRs, or possibly accept that it is at a fixed address, which is a very bad idea. Vectors are either set with DIP switches, or programmed into the card at initialization time. But vectors are the simple part of the Unibus. The fact that it's easy to autodetect the vector makes it even simpler. All you need to make sure is that you don't have a conflict, and your vector issues are done. The interesting part of the Unibus is actually the CSRs. As the I/O address page is only 8K, and some devices use quite a few registers in that area, this is a short resource, so you cannot in general make a permanent allocation in the I/O page for all possible combination of devices you might have. So DEC designed a scheme for automatically detecting and configuring devices on the Unibus. (Plug and play long before the PC saw the light of day.) This do, however, require you to change the CSR address of devices way more often than you might think. The general idea runs like this. For most of the common devices, *one* CSR address is reserved. So, for the first device, you know which address to set it to. Any additional devices of that type goes into the floating address space. Each device additionally have a priority, size and modulo number. This is all on paper. For autoconfiguration to work, you then start with the highest priority device, and starts assigning CSRs to the devices you actually have of that type. When you are done, you go on to the next device, and repeat the exercise. Repeat until you've run through the whole list of device types, and by then you will have the CSR address of all the devices you have in your machine. Now, if you add one additional device of some type, it will probably affect the CSR address of all devices you have which have a lower priority, moving them in the floating address space. The same is true if you remove some device from the machine, which were located in the floating address space. More specifically the algorithm goes like this. (In pseudo-code, all numbers octal) CSR=160010 DEV_PRIO=1 while (! end_of_devices_you_have) CSR = round_up(CSR, device_modulo(DEV_PRIO)) for (number_of_devices(DEV_PRIO)) do this_device_csr = CSR CSR = round_up(CSR+device_size(DEV_PRIO), device_modulo(DEV_PRIO)) next CSR += 2 next Worth pointing out: Floating address space starts at 160010, and goes up. Preallocated CSR addresses are usually very high up in this space, and were allocated downwards. They "end" up somewhere around 174xxx space or so. I'm sure someone could locate the lowest pre-allocated CSR address that DEC assigned by looking in some processor book. Between each device type, one CSR address is reserved. This means that when you scan for devices, you'll run through one type at a time, and stop when you hit an address where there is nothing responding. You then go on to the next type. It's important to understand that the space after this non-existant address do not need to be the same size as that of the actual devices for that prio. That would be wasteful of address space. Once you hit the non-existant address, you start scanning for the next device type, using the modulo of that device type instead. So if you have one device type which uses 20 registers, and you don't have any of that type, you'll only waste one register, plus the modulo of the next device type. Once all the CSRs have been figured out, the DEC official scheme for vector allocation was basically to just allocate all vectors, starting at 300, for all the devices you have, packed together as closely as possible. No need for unused spaces, or anything else here. But this is all about the scheme for actually deciding what to use. The actual method of getting the card to know this info was switchpacks, or for vectors, programming a register. Johnny

13 years, 9 months

← Newer
1
...
4
5
6
7
8
9
10
...
22
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

test-drb July 2010