test-drb November 2007

test-drb@ccmp.vtda.org

229 participants
508 discussions

by oldcpu2＠rogerwilco.org

While I may have cut my teeth on an original Apple II (still in working condition!), but I think I'll pass on this. Looks like just the hardware...no doc or software. But for those that are interested... 150187810446 150187813983 - Jared (I have no connection with the seller).

16 years, 7 months

available Fw: vax equipment... (vax, teletype, tektronix, TI980 mini)

by jwest＠classiccmp.org

Here is a deal that I may want a part of, interested parties contact me off-list please.... Jay West > VAX 11/730 (with Bravo 3 CAD software) > The VAX also has a separate magnetic tape drive in another cabinet > A spare parts VAX > 2 spare hard drives > a couple teletype style terminals > 3 or 4 Tektronix terminals (with stylii for cad work) > a plotter > a couple paper tape punches > a large number of the large disc catridges > TI-980 w/ an ST-1 terminal

16 years, 7 months

Access to IOPAGE Registers using PDP-11 Opearting Systems

by bqt＠softjar.se

"Jerome H. Fine" <jhfinedp3k at compsys.to> skrev: > > >Johnny Billquist wrote: > >>> ons 2007-11-21 klockan 12:00 -0600 skrev "John A. Dundas III" >> dundas at caltech.edu>: >> >>> Jerome, >>> >>> I can speak for RSTS with some authority, RSX with somewhat less authority. >>> >>> At 9:17 PM -0500 11/20/07, Jerome H. Fine wrote: >>> >>> >>>> I doubt that RSX-11 or RSTS/E allow a user access to the IOPAGE >>>> even via PREVIOUS DATA space. Can anyone confirm this assumption? >>>> >>>> >>> Address space in the I/O page for RSTS jobs (processes) was not >>> directly available. The APRs are always controlled by the OS. It >>> MIGHT be possible for a privileged job to use PEEK/POKE SYS calls to >>> access the I/O page in the way you suggest but it would be >>> particularly difficult. >>> >>> >> I thought RSTS/E had some way of remapping the address space as well. >> Can't you remap parts of your memory to some shared region, for example? >> >> > Jerome Fine replies: > > I am replying to Johnny's response, but I had also read the other > replies as well. > Thank you all for your help. > > The first point is that using a PEEK/POKE SYSTEM (EMT? - RT-11 has such > a call) > is so high in overhead that it becomes almost useless. In fact, the key > point about the > use of the EMEM.DLL under RT-11 is the efficiency. While it is possible > to access > normal "emulated PDP-11" memory (using E11 on a 750 MHz Pentium III) in > about > 0.3 micro-seconds, it takes about 1.2 micro-seconds to reference an > IOPAGE address > in some sort of way - including the PSW or the EMEM.DLL values or about > 4 times > as long. Since this is a huge improvement over using a PEEK/POKE, it is > even worth > giving up 8192 bytes of address space to a dedicated APR (of the IOPAGE) > for that > purpose. True. From an efficiency point of view, using system calls to read/write memory is very inefficient. > On the other hand, with RT-11, it is possible and easy to set the > PREVIOUS DATA > space in the PSW to KERNEL even when VBGEXE is used - more to the point, > it is actually unnecessary since that is the default for a so-called > privileged job (which > all programs are by default). This allows the instruction: > Mov @#BaseReg,R0 ;Get the current value from PC memory > to be replaced by: > MTPD @#BaseReg ;Get the current value > Mov (SP)+,R0 ; from PC memory > with almost the same time for execution. It also avoids losing that > 8192 bytes for APR7 > being available just for the IOPAGE registers. That's not possible with OSes that maintain any kind of protection between processes, along with virtual memory. The PSW as such, is not possible to manipulate. If you could, you can also change your mode to kernel even though it's currently something else. Actually, you must be in kernel mode in order to modify the PSW with any other instructions than SEx and CLx. > Obviously, a SYSTEM request avoids all of the problems at a heavy cost > in overhead > estimated at between 50 and 500 times the above two examples. > > That was sort of what I was thinking about when I asked if there was an > "fast method > (only a few instructions)" to access an IOPAGE register. Well, in RSX, you have a rather high overhead to set up the mappping to the I/O page, unless it's already mapped in when the task starts. But from there on, there is no overhead at all. It's located somewhere in your 16-bit address space. (Note that you really don't have to map the I/O page at APR7 in RSX. You can get it mapped anywhere if you use the CRAW$/MAP$ or TKB options.) However, with normal privileged programs, the I/O page is always present at APR7 even if you don't do anything. >>> RSX had a bit more flexibility (opportunity) in this regard. I >>> believe you can set up a CRAW$ (create address window) directive in >>> either Macro or Fortran to achieve the desired result. >>> >> Yes with reservation. CRAW$ (create address window) is as a part of >> doing dynamic remapping of your address space. >> However, CRAW$ always required a named memory partition. You cannot >> create an address window to an arbitrary memory address. >> Also, the memory partitions have protections and ownership associated >> with them. >> >> On most systems, CRAW$ cannot get you access to the I/O page, simply >> because normally you don't have an address space and a partition >> associated with the I/O page. >> >> But if such a partition is created, then CRAW$, in combination with MAP$ >> would allow you to access the I/O page. >> >> The same thing can also be achieved even without CRAW$/MAP$, since you >> can specify mapping that your task should have already at task build >> time, with the COMMON and RESCOM options to TKB. >> >> > This seems to be the answer if it is allowed. Obviously it does require > giving up > that 8192 bytes the have APR7 mapped to user space. Correct. > There is also another option with E11 that I will make use of when I > have finished > with the HD(X).SYS device driver for RT-11. It turns out that if the > memory is > being accessed sequentially, the average time to reference a single 16 > bit value > in the file under: > MOUNT HD: FOOBAR.DSK > is actually less than the time to get/store a single value under > EMEM.DLL when as > few as 8 blocks (2048 words at a time) are being referenced. > Consequently, setting > up a small 4096 byte buffer and the associated code to handle to calls > to the HD: > device driver (all standard calls to .ReadF and .WritF in RT-11) is > actually more > efficient since after the values are in the buffer inside the program, > the values can > be referenced and modified at "emulated PDP-11" memory speeds. You mean that using a device driver, and a device that can access the "normal" memory instead is better. Well, I'm not surprised. What this essentially turns into, is that you're emulating DMA. > Of course, the above solution for sequential references does not work > when the > references are random or when references are at regular but very large > intervals > (thousands and even millions of successive values). For this latter > situation, it > may be possible to modify EMEM.DLL so that a single reference to the IOPAGE > register modifies all of the specified values (over a range of up to > many billions of > values). Can't comment much, since I don't know exactly what you're trying to do. But speedwise, if you really want something to act like fast disk, writing something that behaves like proper DMA is the best. You give the device a memory address, a length, and a destination address on the device, and let it process the data as fast as it can, without involving the PDP-11 after that point. > Of course, the result would no longer really be a PDP-11 except for the > controlling > code which would still be 99% of the required code since the EMEM.DLL > changes > are really quite trivial, yet consume 99% of the time to execute. In > case anyone > does not appreciate what I refer to, it is back to my other addiction - > sieving for > prime numbers. I realize that I should probably switch to native > Pentium code, > but is seems more of a challenge and much more fun to run as if a PDP-11 > is being > used with a few GB of memory somewhere out there that can be easily > fiddled with > as if there is a very fast additional CPU similar to those that used to > be available for > special math applications - anyone remember SKYMNK for FFTs? Hmm, are you just creating a sieve for primes? Ok, then you need large memory somehow. Several ways of doing that. For your specific needs, a simple device in the I/O-page with a command register, an address register and a data register would probably be just about the best. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

16 years, 7 months

possibly OT: Styli

by chrism3667＠yahoo.com

did I spell styli correctly? Anyway does anyone know what's inside these things? That is the "radio frequency" type. I ordered a *bare* Stylistic 1000 and if I want to play etch_a_sketch on the screen I'm going to have to build one. No way I'm pay $40-75 for one seeing the unit cost $30! The Hacker Ethic says "how hard could it be to build my own stylus?". God made the whole Universe in 6 days, so... ____________________________________________________________________________________ Get easy, one-click access to your favorites. Make Yahoo! your homepage. http://www.yahoo.com/r/hs

16 years, 7 months

Programming skills (was: Teaching kids about

by dm561＠torfree.net

--------Original Message: Date: Sun, 25 Nov 2007 17:09:36 -0500 (EST) From: der Mouse <mouse at Rodents.Montreal.QC.CA> Subject: Re: Programming skills (was: Teaching kids about computers...) >> Although some people apparently disagree, dBase is not an application >> program; it's very similar to BASIC (and grew and matured just like >> BASIC did) but with fairly extensive file-handling and >> screen-handling capabilities. >How does that make it "not an application program"? >I suppose this really amounts to "just what do you understand an >`application program' to be?". Certainly my own understanding of the >term leaves room for something like dBase (or a Lisp engine, possibly >even with a text editor attached...or for a C compiler...or for that >matter for a BASIC engine). ---------Reply: You're absolutely correct of course; *any* piece of software written to make a computer do a certain task, including compilers, assemblers etc. is an "application program" and I thank you for pointing out that there is no distinction to be made between an accounting package or an MP3 player or the software controlling a car's engine and a computer "language" with defined words and symbols, rules of grammar and syntax etc. designed and used specifically to "program" some of those very applications (and which I mis-understood to be something distinct from an "application program")... And of course there's no categorical difference either between a hammer and saw and the chest of drawers one might build with them; both items intended for a specific "application." I've learned an important lesson (mainly: to as of right now try *very hard* to stop wasting time with these picayune "discussions") and I thank you again. m

16 years, 7 months

Commodore Watches (was Commodore PET first shipemnt in mid October 1977.

by dm561＠torfree.net

Date: Fri, 23 Nov 2007 17:12:44 -0500 (EST) From: bpope at wordstock.com (Bryan Pope) Subject: Re: Commodore PET first shipemnt in mid October 1977. >> Does anyone collect Commodore wristwatches? Do any working ones >> survive? >> >I know TPUG (http://www.tpug.ca) was selling a bunch of NOS C= >wristwatches a few years back... >Cheers, >Bryan --------- They're still (again?) available, although you'd have to be quick with your order; contact: Ben Kayfitz - downtownben at hotmail.com m

16 years, 7 months

classiccmp / cctalk / cctech (fwd)

by ard＠p850ug1.demon.co.uk

I have been asked to forward this to the list, since for some reaon the original poster is having problems doing so. -tony > The classiccmp moderation system is out of action. This mainly affects > the cctech list, but there are a few subscribers who post from an > address different to the one they are subscribed with and their postings > must be manually moderated through to cctalk. Sorry! > > Thanks, > -- > Lawrence Wilkinson lawrence at ljw.me.uk > Ph +44(0)1869-811059 http://www.ljw.me.uk > >

16 years, 7 months

IBM 5251 keyboard

by lynchaj＠yahoo.com

Hi, I still have this IBM 5251 keyboard. Does anyone want it? It is just taking up space in my basement now. I have not made any modifications to it but I do not know whether it works or not. Since I have fixed a different parallel ASCII keyboard to work with my Vector Graphic restoration I no longer need this IBM 5251 keyboard. I would like to trade the IBM keyboard for a case to put my parallel ASCII keyboard in but other items gladly considered. Thanks! Andrew Lynch Vector Graphic Mail List: http://h-net.msu.edu/cgi-bin/wa?A0=VECTOR-GRAPHIC NorthStar Mail List: http://tech.groups.yahoo.com/group/NorthStar_Computers

16 years, 7 months

Programming skills (was: Teaching kids about computers...)

by dm561＠torfree.net

Date: Sat, 24 Nov 2007 23:54:44 +0000 (GMT) From: ard at p850ug1.demon.co.uk (Tony Duell) Subject: Re: Teaching kids about computers... >> Tools are developed to make a job easier and do it better; in my opinion taking >> advantage of those tools and doing things "the easy way" makes you more >> professional, not less. >I would agree, but... >1) Being able ot use the tools, however proficiently, does not >necessarily equate with being able to design/make those tools. -------- Why do my recent posts seem to generate such odd responses... Or is it just me? Why the "but"? Did I imply anything of the sort? Did I say that a carpenter should know how to make an electric saw or even repair it when it would be a more efficient use of his time and skills to just take it to a shop or buy a new one? ------ >I haev never used dBase (or any other database for that matter), so I can't >comment on that, but I will claim that being able to use _some_ >application programs does not make you a programmer. -------- A claim that seems pretty obvious; why make it? Although some people apparently disagree, dBase is not an application program; it's very similar to BASIC (and grew and matured just like BASIC did) but with fairly extensive file-handling and screen-handling capabilities. -------- >2) The initial question was about education. Education is not production. -------- Of course not! That may have been the initial question but by the time of my reply it had moved to opinions about what defines a "programming professional," specifically whether someone who codes in dBase or doesn't know or care about how disk drives work can call him/herself one. -------- >When you're prodcuing something, of course you use all the applicable >tools. When you're leaning about things, you have to do things 'by hand' >to understand them (and example of this, from another context, is that >photography couses used to insist that the students used cameras with >manaul focuessing and exposure cotnrol, so they could learn what said >adjustments meant, even though if you were being paid to take photographs >you would _probably_ welcome some automation). >In fact I will go further and say that the true professionals not only use the right >tools, but also fully understnad how those tools work and behave, because that >way they can use them more effectvely. ----------- I kind of thought that being "proficient," i.e. "having an advanced degree of competence" in their use of tools expressed the same sentiment. Of course as a professional you should know what those camera adjustments mean and do, but you don't necessarily have to know *how* they work unless you're interested or plan to go into camera design or repair, or expect to have to repair it in the middle of nowhere; "how they behave" is not at all the same as "how they work." And although you may know all the arcane details of your camera and probably look down on someone who only points-and-shoots, he or she may well take better pictures than you, which is after all the whole point of having a camera (for most people anyway ;-) ----- >> A programming professional's job is to deliver a product that meets the client's >> needs, is well documented and easily maintained, and is delivered on time and >> within budget. Knowing or caring about the arcane details of a disk drive or being >> able to program an OS-less computer in binary may matter if you're working on >> an embedded controller but it's pretty irrelevant if the project is a client accounting >> system for a large financial institution. ---------- >Tuew, but a 'client system for a large finanicail instution' is hardly >the only type ofr computer application. --------- Again, I thought that was obvious and that my mentioning embedded controllers would suggest that even I knew that and don't need you to point it out... My point was that there's more to being a programming professional than being able to code in binary; furthermore, different tasks require different tools and skills and different people have different interests and abilities, and I find the tendency for some people here to denigrate others with different goals, interests, abilities and tastes annoying enough on occasion to comment. m

16 years, 7 months

Babbage Calculating Machine Article 1833

by ed＠ed-thelen.org

> From: "B. Degnan" <billdeg at degnanco.com> > Subject: Babbage Calculating Machine Article 1833 > To: cctalk at classiccmp.org > Message-ID: <5.1.0.14.0.20071125093356.03328d50 at mail.degnanco.net> > > New York Weekly Messenger 2-13-1833 > Babbage Calculating Machine Article 1833 > On the back page of this newspaper is an article that describes in some > detail the eye-witness account of a *working* machine: "...the greater part > of the calculating machine is already constructed....I have had the > advantage of seeing it actually calculate, and of studying its construction > with Mr. Babbage himself..." The machine was never completed - long story > Does this account describe a working computer? No - to see more than you ever wanted to know about Babbage Difference Engine #2 see http://www.ed-thelen.org/bab/bab-intro.html > To help make this > determination I would want to learn more about the error checking > capability of this machine, which I assume was used for calculation of > significant digits. Error prevention was the name of the game. Bars and detents prevented motion at wrong times. The machine would jam rather than make a mistake. > A[s] described, Babbage's calculating machine could be > described as "computer-like" at least. I believe that this article reports > the closest Babbage got to a actual working computer. Or just an elaborate > calculator. There are no references in the article to what we today would > identify as punch cards or programming. Fixed program "Calculator" seems a good word. It was basically a seventh order polynomial evaluator. > Download the PDF > http://www.vintagecomputer.net/babbage/charles_babbage_2-13-1833.pdf > ...and read for yourself. The article describes error checking and how > results are viewed and how log tables could be calculated accurately, for > use in astronomy. The article noted that regarding the printer "..less > progress was made...". The second incarnation of the Babbage Difference Engine #2 (the 1st is in the London Science Museum) is now due in spring 2008 on loan to Computer History Museum, Mountain View, CA courtesy of Nathan Myhrvold. Doron Swade is currently Guest Curator :-)) http://www.computerhistory.org/about/staff/swade/

16 years, 7 months

← Newer
1
...
11
12
13
14
15
16
17
...
51
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 November 2007