test-drb

test-drb@ccmp.vtda.org

101090 discussions

by pete＠dunnington.plus.com

On 26/07/2010 19:22, J.G.Harston wrote: > Rick Murray wrote: >>> ".bbc" - Russell format >>> ".bas" - Text >>> "." - Acorn format >> No, very *BAD* to use *.bas - double click on those, I'll have the fun >> of watching Visual Basic trying to load a tokenised BASIC code. :-) "Well, don't do that, then," said the helpdesk techie. > .bas is the standard extension for textual representation of BASIC (*any* > BASIC) code. If some application decide to stupidly associate themselves > with it and try to execute it, that's their stupid fault. I'm with Jonathan. .bas is the accepted extension for all sorts of BASIC files, and using something else is only going to cause confusion elsewhere. Double-clicking is supposed to "run" a file or cause it to be executed; if the only BASIC interpreter you have is the VB executable and it tries to load the file you double-clicked, well that's because the doubler-clicker was daft enough to do an inappropriate thing :-) The appropriate thing, if you want to edit a file, would be to right-click and select "open with" -- assuming we're talking about a Windows OS. Or use whatever weird combination of key and mouse performs "open" rather than "run". -- Pete Peter Turnbull Network Manager University of York

15 years, 8 months

Fwd: [alt.sys.pdp11] VHDL implemenentation of a PDP-11/70 available on Open

by legalize＠xmission.com

This message has been forwarded from Usenet. To reply to the original author, use the email address from the forwarded message. Date: Mon, 26 Jul 2010 21:12:41 +0200 Groups: alt.sys.pdp11 From: "Walter F. J. Mueller" <w.f.j.mueller at gsi.de> Org: Technische Universitaet Darmstadt Subject: VHDL implemenentation of a PDP-11/70 available on OpenCores Id: <i2kmn9$vhj$1 at lnx107.hrz.tu-darmstadt.de> ======== A VHDL implementation of a PDP-11/70 with MMU but without FPP, and a basic set of UNIBUS peripherals is available under GPL on OpenCores, see http://opencores.org/project,w11 The core is FPGA proven, boots UNIX 5th edition and 2.11BSD Unix. The I/O sub-system is emulated via a backend server which currently communicates via a serial port with the FPGA board. Walter

15 years, 8 months

Help with international shipping

by pontus＠update.uu.se

Hi There is a DEC manual the size of VMS manual ring binder for sale on Ebay. I would really like to have it! The seller wont ship internationally, but I'm in Sweden. Would anyone like to be my proxy? I'll bid and pay the seller but I need someone to receive it in United States and ship it to me. Obviously I'll pay for shipping to Sweden and a bit extra for the trouble. Please contact me offlist. Kind Regards, Pontus.

15 years, 8 months

Micro-Systems magazines for free

by tosteve＠yahoo.com

For the cost of shipping: S-100 "Micro Systems" magazines Issues 1/1 (Jan 80) through 3/4 (Jul 82). Issue 1/3 is missing. I am in southern California 92656

15 years, 8 months

Lot of PDP-11/84 on ebay in Boston

by tshoppa＠wmata.com

I think (bigger than 50% chance) that I recognize the seller and the origin of the machines, and I think it's very likely that some of the machines have some specialized communications hardware that was for some period very hard to get at and may even still be worth considerable $ to those in need of it, if the cab kit and remote mux distribution panel is present. But to anyone outside that industry it's very unlikely the board itself would be considered wanted at all, and I think it's 99% likely that the seller is not including the remote mux distribution panel, it often gets trashed in the "decommisioning". It's a little sad to see machines "parted out" in a way that separates the Unibus backplane board from the part of the peripheral that's actually needed in industry, but this "parting out" phenomenon is so widespread on E-bay and those who do it tell me that it's the only way to make money. So PDP-11's get chopped off the actually interesting and valuable system they control, and as a result neither end is desirable by itself.

15 years, 8 months

Lot of PDP-11/84 on ebay in Boston

by mdavidson1963＠gmail.com

Yeah, and in the description he says: Any offers below $450 for single systems will be rejected. Nice. On Sun, Jul 25, 2010 at 9:38 AM, Zane H. Healy <healyzh at aracnet.com> wrote: > If I read that right, that's $550 per system. > > Zane > > > > At 11:23 AM -0400 7/25/10, Patrick Finnegan wrote: >> >> Someone should try to snap these up: >> >> http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=140431577078 >> >> I doubt scrap value is over (or even near) $50/each, so maybe you can >> deal with the guy if you're willing to pick them up. > > -- > | Zane H. Healy ? ? ? ? ? ? ? ? ? ?| UNIX Systems Administrator | > | healyzh at aracnet.com ? ? ? ? ? ? ?| OpenVMS Enthusiast ? ? ? ? | > | ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| Photographer ? ? ? ? ? ? ? | > +----------------------------------+----------------------------+ > | ? ? ? ? ? ? ? ? ? ? My flickr Photostream ? ? ? ? ? ? ? ? ? ? | > | ? ? ? ? ?http://www.flickr.com/photos/33848088 at N03/ ? ? ? ? ? | >

15 years, 8 months

RTEM-11

by bqt＠softjar.se

"Jerome H. Fine" <jhfinedp3k at compsys.to> wrote: > >Johnny Billquist wrote: > >>> >> My reference to a specific "feature" is with respect to the actual >>> >> details of >>> >> the RTS in question. For RSTS/E, the RTS to handle RT-11 EMT requests >>> >> does not support even all of the RT-11 EMT requests which the RT11SJ >>> >> monitor in RT-11 supports. For example, the .CStatus request is ignored >>> >> and the .SaveStatus request return the "dev:filnam.typ" and [PPN] for >>> >> the >>> >> file in question rather than the five Channel Status words used in an >>> >> RT-11 >>> >> environment. So there are significant differences between the RT-11 RTS >>> >> under RSTS/E and an actual RT11SJ monitor running under a PDP-11 >>> >> instruction set (specified so as to include both a DEC CPU and an >>> >> emulator >>> >> such as SIMH). >> > >> > Yes. And RTEM-11 will also behave slightly differently that vanilla >> > RT-11 for some of those calls. And assuming there is a product called >> > RTEM, which runs under VMS, it too will behave differently than RT-11. >> > However, RTEM-11 and this RTEM will not necessarily behave the same >> > way, since RTEM-11 and RTEM are different products, and different >> > implementations, written by different people (assumingly) at different >> > times. > > 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. > The RSTS/E RTS system for RT-11 EMT requests is fairly well > documented in the RSTS/E documentation. The only areas which > are a bit hazy is when the [PPN] (at offset zero in the Common > Area) is not specified (left at zero). If the [PPN] is included, then > it is used correctly along with the file name that is specified. > > 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) >> > RTEM-11 is not an RTS. RTEM-11 is a product that ran (runs) under RSX. >> > If I were to make a qualified guess, I'd suspect that RTEM-11 is a >> > program that you start just like any other program under RSX. That >> > program then looks like an RT-11 environment, so you can run RT-11 >> > programs inside that. >> > RTEM-11 will catch EMTs and other traps, and do something appropriate >> > to those traps. It's not difficult to catch traps in an RSX program. >> > Exactly what it does, and how, is another issue. And that is something >> > you are asking about, and which I cannot answer, and it seems noone >> > else can either, since noone around here have RTEM-11, or have used >> > it. As I said, I think Megan mentioned that she had used it, but she's >> > the only one I know of who have admitted to any knowledge about this >> > product. > > I suspect that Megan is no longer available for help. I have not seen or heard from her for a long time. You know anything? >>> >> On the >>> >> other hand, I doubt that anyone will be likely to even test the >>> >> RTEM-11 handling >>> >> portion of the code, so I am probably going to just assume that what >>> >> works for the >>> >> RT-11 RTS system under RSTS/E will also suffice for the RTEM-11 RTS >>> >> under >>> >> RSX-11. >> > >> > Not an RTS, but anyway, you are most probably very correct in the >> > assumption that no one will test you code under RTEM-11. > > That should make the situation fairly simple. I will ask anyone who > actually > does run under RTEM-11 to contact me if it does not work. Since I will > be 72 years old in a few days, and I doubt that the code will be finished > very soon, they won't have many years to check in. Do that. I very much doubt you'll get any response though. >>> >> That is what I had assumed, however, I am curious how RSTS/E decides >>> >> which RTS to use - or none at all as the case might be. >> > >> > Are you not reading what I am writing? >> > This is an attribute of the file. You *tell* which RTS a program >> > should run under. Normally you do not need to do this explicitly, >> > since every file always have an RTS associated with it, and it's >> > normally already correct, so no need to change it. > > 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... 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. I don't have any better answer off my head, and I am not going to install RSTS/E to figure this out for you. You can do the work yourself. It shouldn't be hard. But by now it should be obvious that no one around here is offering the answer so you'll have to figure it out yourself. > Under V7, RSTS/E has a program named FIT which I use to copy > a program from an RX02 device to an RL02 device. Based on your description, > FIT must attach the RT-11 attribute to the file during the copy. Yes, it's a fairly good assumption that FIT will create all copied files >from an RT-11 formatted disk on the RSTS/E system assigned to the RT11 RTS. Assigning any other RTS to the files would probably be a mistake, since the files most probably are coming from an RT11 system. > It would be appreciated if you could confirm that I finally have it > correct. If you mean the guess that FIT would copy the files and assign them to the RT11 RTS, then yes. That is most likely correct. It might even be that FIT is an RT11 program itself as well... >>> >> Well, I am having difficulty finding the "new" program under V10.1 of >>> >> RSTS/E. >>> >> I finally managed to figure out how to MOUNT the RL02 drives I am >>> >> "using" >>> >> (don't forget that all the code is being run under SIMH or E11) under >>> >> V7 of >>> >> RSTS/E when I am running V10.1 of RSTS/E. Since FIT had already copied >>> >> to file to the RL02 drives, I could then used PIP to copy the program >>> >> in I am >>> >> testing to the correct [PPN] on the DU0: drive which is being "used" >>> >> to run >>> >> V10.1 of RSTS/E. A bit inconvenient, but fortunately faster than on >>> >> a DEC >>> >> system. >> > >> > That sentence makes no sense. Either you are running RSTS/E V7, or >> > RSTS/E V10, you cannot run RSTS/E V10 when you are running RSTS/E V7, >> > or vice versa. You'll have to reboot the machine in order to run >> > another version of RSTS/E. > > AGREED!! When I tested the program under V10.1 of RSTS/E, the only > way I managed to copy the program after booting V10.1 of RSTS/E on the > DU0: device was to MOUNTed the RL02 device which had the program I > wanted to test. The RL02 device had previously been booted to V7 of RSTS/E > and FIT had been used to copy the program from the RX02 device to the RL02 > device. > > So YES, two boots were required, the first to copy the program from the RX02 > device (with an RT-11 file structure) to the RL02 with a RSTS/E file > structure > using FIT under V7 of RSTS/E. Then I SHUTUP V7 of RSTS/E, booted the > DU0: device which has V10.1 of RSTS/E, MOUNTed the RL02 and copied > the program from the RL02 to the DU0: device. Since this will not be done > except for testing, it is acceptable. Aha. So what you actually are saying is that you booted RSTS/E V7, copied the files from an RT11 formatted disk into the RSTS/E system. You then booted RSTS/E V10, and accessed the files previously copied. Yes, that would work just fine. >> > With ODT linked in to the program, just as you mentioned that people >> > normally did with RT11 in the past as well. >> > >> > The same type of development cycle is still what people use to this >> > day. You build a special debug version, which you run through the >> > debugger, and when you are happy, you build a new, leaner version, >> > without debug support. > > I agree that this was also done in the past with RT-11. 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). 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. >> > I'm not sure how you use that device driver under RT11, nor how useful >> > it actually is... > > 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? > Based on some of the comments in the SDX.SYS source file, it looks > like it is also available under both RSTS/E and RSX-11. However, > since I have almost no knowledge of RSTS/E and even less of RSX-11, > I can't even begin to speculate why those comments are in the source > file. I dare say that it would be impossible to do the same in RSTS/E or RSX. The reason is that the BPT vector that the CPU uses is set up by the operating system, and is always used. Any program running does not use that vector, but has a dynamically installed debug vector defined as a part of the system image, or set up by a system call by the running program. You do not, and can not, access the hardware related things directly in RSX or RSTS/E and hope that anything will contiue to work. The hardware BPT vector is used by the executive debugger in RSX (XTD), which is a OS debugger somewhat similar to ODT, but specifically designed to debug the OS. It is always there, and if you mess with that, you are going to be sorry. When a user program executes a BPT instruction, the kernel gets called. It checks wether the program have installed a debug handler, and if so, that handler is being called in the context of the user program. If no debug handler have been installed for that program, the program aborts. You can have any number of programs running in parallel, all with their own installed debug handlers, which can actually be different debuggers that have nothing to do with each other. How on earth do you think a common device driver could ever handle such a situation? 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. Johnny

15 years, 8 months

TEAC FD-55GFR and Deviceside

by silent700＠gmail.com

Last night I finally had time to assemble my Deviceside USB->5.25" floppy interface. I decided to do it all slick-like and put the drive in the shell of an old Sony USB CDRW. I have two examples of the TEAC FD-55GFR drive laying around, which is the drive recommended on the developer's site. I attached one to the ext drive carrier and powered on. The drive head started seeking back and forth, not the full travel of the disk, maybe 1/4 of it. It made a loud, steady click and flashed the panel light of the bay, as if it was drawing too much power from the little PSU. However, I went ahead and hooked it up and read disks (DOS 1.2mb, AppleDOS and C64 1541) to images. I haven't fully tested the images yet but they didn't error out during the read. The DOS one was mountable in WinImage, the C64 one in CCS64 (don't have an Apple II em handy.) Still bothered by the noise, I attached a Panasonic JU-475-4 drive instead. It was quiet, no blinking light. I imaged the same disks with that drive and that appeared to work fine, too. Does anyone know the FD-55GFR well? It seems to have an auto-sense mech of some kind, and one of the two I have has a spring-eject (the other may have had it too but the spring is missing?) It seems likely that it would click continuously, searching for a disk. Maybe this is normal behavior for this drive and it seems loud because it's open? It does the head-seek continuously whether there is a disk inserted or not, lever-down or not. This seems bad to have happening on top of the exposed disk surface. Or, again, maybe it's normal for this drive? The easy solution is go with the Panasonic and not worry about it. But I'd like to stick to the developer's recommended drive unless I can be sure the Panasonic is 100% compatible too. -j -- silent700.blogspot.com Retrocomputing and collecting in the Chicago area: http://chiclassiccomp.org

15 years, 8 months

The Chipophone

by lproven＠gmail.com

Not exactly retro in its build, but it might interest folk hereabouts. http://www.linusakesson.net/chipophone/index.php The Chipophone is an electronic organ whose guts have been replaced with a pair of microcontrollers to make it into a 1980s-style 8-bit synthesizer, for playing classic videogame chiptunes live. It helps that its creator is an excellent player of such things. For example, Rob Hubbard's /Spellbound/ from 1986: http://www.linusakesson.net/chipophone/spellbound.php -- Liam Proven ? Profile & links: http://www.google.com/profiles/lproven Email: lproven at cix.co.uk ? GMail/GoogleTalk/Orkut: lproven at gmail.com Tel: +44 20-8685-0498 ? Cell: +44 7939-087884 ? Fax: + 44 870-9151419 AIM/Yahoo/Skype: liamproven ? MSN: lproven at hotmail.com ? ICQ: 73187508

15 years, 8 months

Diablo 630 ECS Printer in need of a good home

by mardy＠pernetics.com

I have a mint condition Diablo 630 ECS printer that I purchased NEW a couple of years ago. Yes, new. It still had the shipping tie-downs on the carriage. I've never done anything with it other than run the self-test so it's time to let it go. Before I put it up on eBay, I thought I'd mention it here. It also comes with 12 daisy wheels and the optional automatics sheet feeder which is still sealed in plastic. If someone is willing to come pick it up, I'll let it all go for $100.00. (That's less than what I paid for the daisy wheels.) I'm located in Southern New Hampshire (USA). I've got pictures, if anyone's interested. -Mardy

15 years, 8 months

Jump to page:

2026

2025

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