test-drb October 2010

test-drb@ccmp.vtda.org

175 participants
274 discussions

by bqt＠softjar.se

On 2010-10-30 23:18, "Chuck Guzis"<cclist at sydex.com> wrote: > > On 29 Oct 2010 at 21:14, Johnny Billquist wrote: > >> > If your program vrites data to address 0, and reads it back, and get >> > the same data back, and another program on the same machine, at >> > roughly the same time, write to address 0, and reads the same data >> > back, and that data is different than the first programs data, then >> > I'd say you have virtual memory. > So, your definition ties virtual memory into multi-user access? > That's not the way I learned it. No no no. You miss my point. It don't directory tie in to multiuser access. It's about presenting to you a memory which in reality does not exist as you perceive it. As a follow on benefit of this is the fact that you can have multiple instances at the same time. But that is not the definition. The definition is that you appear to have a linear space of memory that maps the whole virtual address range, and that this memory is yours alone. It is your own private memory. Just as a virtual machine is your own private machine. No matter the fact that in reality, this is not the case, and your memory (or machine) is just something running under the control of an underlying operating system, which gives you this service. > Consider (again folks, I'm sorry for the reference) the CDC 6600 > (circa 1964). Every user is given a relocation address (called RA) > and field length (FL) as a way of partitioning main memory. Each > user's memory addressing space is kept isolated from every other's > and this fits your definiton because one user's location X was > different from every other user's location X and there was no way for > a user to tell what his RA was; i.e. each user was safely "boxed in". The important question here - are the programs aware of the RA register, and can they change it? And can they address the full range of memory addresses as perceived by the program. > That's not virtual memory by any stretch of the definition. Over- > committing memory meant writing/reading the entire FL of a user to > disk ("rollout" and "rollin"). Another word for swapping in and out? Anyway, I'm not sure if this would qualify as virtual memory or not without knowing a few more details. But it might very well be virtual memory, as far as I can tell. > Now consider the STAR-100 (I think it would qualify as the first > virtual memory machine of CDC), circa 1969. Defined by whom? CDC? Or you guys? ;-) > Every user got an > addressing space of 48 bits, but the machine itself had only > 512Kwords (64 bit) of physical storage. For production use, most of > the time the system was run in single-user mode (kept thrashing down > with large data sets). That fits my definition of VM because the > user was fooled into thinking that there was more physical memory > than there really was. You know, my definition and yours don't necessarily disagree on all points. Both would define the VAX as having virtual memory (well, except for the fact that yours might not, if you have a VAX with enough physical memory). We just disagree about what when there is more physical memory than you have virtual memory space. For you, that means it can't be virtual memory. but for me it can. For me, what is relevant is whether the program is presented with his own private memory space, which contains all addresses he can address, and where all those addresses are valid and working. A memory space which he don't have to share with anyone else. That's what virtual memory is, as opposed to physical memory, which you can point at, and which all running code on a computer needs to live on. And that means that the OS is always there. And possibly other processes as well. Using the same addresses you are. If that means that you cannot have your own memory for a specific address, then it's not virtual memory. But then you probably aren't talking about virtual memory either, but physical memory. > Aside from expanding program storage, the large addressing space was > used to map file space (another type of "memory-mapped I/O"), so file > access was actually performed through the paging hardware/software. > That was kind of cool, as the STAR was a memory-to-memory vector > machine, so you could use vector instructions on entire files, rather > than have to issue reads and writes for pieces of a file. > > So I think we differ considerably in our definitions. On some parts, yes. So, do the VAX not have virtual memory? After all, I can fill a VAX with more physical memory than you can address virtually. 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

14 years, 1 month

PDP-11 firsts?

by bqt＠softjar.se

On 2010-10-30 01:12, ard at p850ug1.demon.co.uk (Tony Duell) wrote: > >> > I have not seen anyone comment any of the other things I listed as >> > possible firsts on the PDP-11. >> > Can anyone come up with an earlier machine that used condition codes? >> > How about general registers with addressing modes, which is totally >> > orthogonal? How about having the PC as a general register? > The Philips P800 series has the PC as a general register (register 0). Could you use it like any other register? > There are 16 registers, some instructions can only use the first 8, others > can use all 16. Addressing modes (simpler than the PDP11, I admit) are > pretty much orthogonal. Sounds like the registers were atleast not as orthogonally used as on a PDP-11. If an instruction could take a register, it could take any register. And all addressing modes are valid (well, almost) anywhere. The one exception that pops into my head is that you cannot do a "JMP R0" on a PDP-11. (Well, there might be a model or two where it was allowed, since some models actually exposed the registers in the address space, and you could execute from those addresses, but that is kindof weird). One wonderful thing about the PDP-11, which unfortunately did not get copied, was the nice things that happened because the PC was e general register. Thus, the PDP-11 never had special versions of instructions to implement immediate mode operands, and so on. All that was solved because the PC was a general register. (Well, the VAX sortof have it, but no other machine I know of.) > I am not sure wheterh the PDP11 or P800 was first,m they both appeared in > 1970 I beleive. Would be interesting to find out more. > What do you mean by condition codes here? The four low bits of PSW. 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

14 years, 1 month

cctalk Digest, Vol 86, Issue 68

by dm561＠torfree.net

----- Original Message ----- From: <cctalk-request at classiccmp.org> To: <cctalk at classiccmp.org> Sent: Saturday, October 30, 2010 4:18 PM Subject: cctalk Digest, Vol 86, Issue 68 > 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. Re: Happy Birthday VAX 11/780 (influence of) (Chuck Guzis) > 2. Re: TTL HEX LED driver chip (Chuck Guzis) > 3. Re: TRS-80 Model II Manuals (Fred Jan Kraan) > 4. Re: DiscFerret: First working hardware, firmware and > microcode! (Philip Pemberton) > 5. Re: TRS-80 Model II Manuals (Tony Duell) > 6. Re: TRS-80 Model II Manuals (Chuck Guzis) > 7. Re: DiscFerret: First working hardware, firmware and > microcode! (Dave McGuire) > 8. Re: Happy Birthday VAX 11/780 (influence of) (Dave McGuire) > 9. Re: DiscFerret: First working hardware, firmware and > microcode! (Philip Pemberton) > 10. Re: TTL HEX LED driver chip (Brent Hilpert) > 11. Re: Happy Birthday VAX 11/780 (influence of) (Brent Hilpert) > 12. Fall cleaning, some small machines for free (Bob Rosenbloom) > 13. Re: DiscFerret: First working hardware, firmware and > microcode! (Chuck Guzis) > 14. Need to find parts 82S23 / 74S188 (alan canning) > 15. Re: Happy Birthday VAX 11/780 (influence of) (Chuck Guzis) > 16. Re: DiscFerret: First working hardware, firmware and > microcode! (Philip Pemberton) > 17. Re: TTL HEX LED driver chip (Tony Duell) > 18. Re: Nuclear Data ND 6600 (Tony Duell) > 19. Re: TRS-80 Model II Manuals (Tony Duell) > 20. Re: TTL HEX LED driver chip (Tony Duell) > 21. Re: TTL HEX LED driver chip (Tony Duell) > 22. Re: Wanted : Monitor Capable of TTL RGB (Tony Duell) > 23. Re: I/O models (was RE: Happy Birthday VAX 11/780 (influence > of)) (Tony Duell) > 24. Re: Fall cleaning, some small machines for free (Brent Hilpert) > 25. Re: Need to find parts 82S23 / 74S188 (ben) > 26. Re: TRS-80 Model II Manuals (Geoffrey Reed) > 27. Re: Need to find parts 82S23 / 74S188 (Tony Duell) > 28. Re: Need to find parts 82S23 / 74S188 (Chuck Guzis) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 30 Oct 2010 10:08:19 -0700 > From: "Chuck Guzis" <cclist at sydex.com> > Subject: Re: Happy Birthday VAX 11/780 (influence of) > To: "General Discussion: On-Topic and Off-Topic Posts" > <cctalk at classiccmp.org> > Message-ID: <4CCBEE93.7369.1A49AC at cclist.sydex.com> > Content-Type: text/plain; charset=US-ASCII > > On 29 Oct 2010 at 21:14, Johnny Billquist wrote: > >> If your program vrites data to address 0, and reads it back, and get >> the same data back, and another program on the same machine, at >> roughly the same time, write to address 0, and reads the same data >> back, and that data is different than the first programs data, then >> I'd say you have virtual memory. > > So, your definition ties virtual memory into multi-user access? > That's not the way I learned it. > > Consider (again folks, I'm sorry for the reference) the CDC 6600 > (circa 1964). Every user is given a relocation address (called RA) > and field length (FL) as a way of partitioning main memory. Each > user's memory addressing space is kept isolated from every other's > and this fits your definiton because one user's location X was > different from every other user's location X and there was no way for > a user to tell what his RA was; i.e. each user was safely "boxed in". > > That's not virtual memory by any stretch of the definition. Over- > committing memory meant writing/reading the entire FL of a user to > disk ("rollout" and "rollin"). > > Now consider the STAR-100 (I think it would qualify as the first > virtual memory machine of CDC), circa 1969. Every user got an > addressing space of 48 bits, but the machine itself had only > 512Kwords (64 bit) of physical storage. For production use, most of > the time the system was run in single-user mode (kept thrashing down > with large data sets). That fits my definition of VM because the > user was fooled into thinking that there was more physical memory > than there really was. > > Aside from expanding program storage, the large addressing space was > used to map file space (another type of "memory-mapped I/O"), so file > access was actually performed through the paging hardware/software. > That was kind of cool, as the STAR was a memory-to-memory vector > machine, so you could use vector instructions on entire files, rather > than have to issue reads and writes for pieces of a file. > > So I think we differ considerably in our definitions. > > --Chuck > > > > ------------------------------ > > Message: 2 > Date: Sat, 30 Oct 2010 10:21:07 -0700 > From: "Chuck Guzis" <cclist at sydex.com> > Subject: Re: TTL HEX LED driver chip > To: "General Discussion: On-Topic and Off-Topic Posts" > <cctalk at classiccmp.org> > Message-ID: <4CCBF193.19364.2603DF at cclist.sydex.com> > Content-Type: text/plain; charset=US-ASCII > > On the same topic here, can anyone interpret the "state table" on the > second page of the National DM74LS447 7-segment decoder datasheet? > > http://pdf1.alldatasheet.com/datasheet- > pdf/view/149198/NSC/DM74LS447N.html > > I tend to think of state diagrams as belonging to things such as > counters and don't have a clue as to what to make of the one > furnished. > > --Chuck > > > > > > ------------------------------ > > Message: 3 > Date: Sat, 30 Oct 2010 20:05:06 +0200 > From: Fred Jan Kraan <fjkraan at xs4all.nl> > Subject: Re: TRS-80 Model II Manuals > To: cctech at classiccmp.org > Message-ID: <4CCC5E52.9000802 at xs4all.nl> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Thanks to the ever-useful JP Hindin, I've obtained a set of TRS-DOS >> disks and other application disks for my TRS-80 Model II system, which >> is the entire setup pictured here, plus a bit more: >> >> http://oldcomputers.net/pics/TRS-80-II_table.JPG >> >> It's been sitting, covered, pretty much since I obtained it, but now I >> can try reviving it and actually seeing what it can do. I'm going to >> tear into it and clean the drives and so forth, document what it has, >> etc. and then boot 'er up and see what we can see. >> >> I'm looking for a copy of the Technical Ref manual for it; despite >> finding scans of the covers and so forth online, I'm unable to actually >> locate one. In addition to that, if someone has a Shugart 8" Service >> Manual, that might come in damned handy for making sure those are up to >> speed as well. >> > See > http://electrickery.xs4all.nl/comp/mirror/trs-80_archives/Manuals/Hardware/…. > The Shugart stuff should be included. > > Essential this is from a modified copy of the files that were available > from http://www.trs-80.com/ (copied without permission). >> Many thanks, >> >> Nathan >> >> > Success, > > Fred Jan > > P.S. My own adventures with the Model II: > http://www.xs4all.nl/~fjkraan/comp/trs80m2/ > > > > ------------------------------ > > Message: 4 > Date: Sat, 30 Oct 2010 19:35:32 +0100 > From: Philip Pemberton <classiccmp at philpem.me.uk> > Subject: Re: DiscFerret: First working hardware, firmware and > microcode! > To: General Discussion: On-Topic and Off-Topic Posts > <cctalk at classiccmp.org> > Message-ID: <4CCC6574.8010103 at philpem.me.uk> > Content-Type: text/plain; charset=UTF-8; format=flowed > > On 30/10/10 17:26, Al Kossow wrote: >> If it's going to be an adapter, could you add holes for SA1000-style 8" >> drives (50pin/20pin cabling)? > > I almost mistook that for a floppy drive until I looked it up on > Bitsavers...! > > I can't see any real reason why SA1000 support couldn't be added to the > bridge-board. Looks like the only changes required would be: > - An oscillator to generate the 3.6866us +/- 0.1% timing clock > (270982 to 271524Hz, nominal 271253Hz). Although I have no idea what > standard crystal frequencies could be used to generate that signal. The > FPGA's PLL might be persuaded to do it, though, I'll have to check. > - Two jumpers to disconnect the Timing Clock from the ST412/506 Data > connector when these are not in use (or maybe just a second connector?) > - A 50-pin connector for the SA1000 control cable > > The extra cost probably isn't worth worrying about... though I might > have to restrict drive selection to Drive 0 only in order to get enough > I/O pins for head selection. > > Thanks, > -- > Phil. > classiccmp at philpem.me.uk > http://www.philpem.me.uk/ > > > ------------------------------ > > Message: 5 > Date: Sat, 30 Oct 2010 19:47:54 +0100 (BST) > From: ard at p850ug1.demon.co.uk (Tony Duell) > Subject: Re: TRS-80 Model II Manuals > To: cctalk at classiccmp.org > Message-ID: <m1PCGTE-000J3xC at p850ug1> > Content-Type: text/plain > >> locate one. In addition to that, if someone has a Shugart 8" Service >> Manual, that might come in damned handy for making sure those are up to >> speed as well. > > ...And if they;'re not, it's most likelyto be the drive belt. Yes I know > 'up to speed' wasn't meant to be taken literally, but that seemed too > good to miss :-) > > More seriously, what model of Shugart8" drive? Are there not manuals for > them on bitsavers? > > -tony > > > ------------------------------ > > Message: 6 > Date: Sat, 30 Oct 2010 11:55:03 -0700 > From: "Chuck Guzis" <cclist at sydex.com> > Subject: Re: TRS-80 Model II Manuals > To: "General Discussion: On-Topic and Off-Topic Posts" > <cctalk at classiccmp.org> > Message-ID: <4CCC0797.19723.7C011E at cclist.sydex.com> > Content-Type: text/plain; charset=US-ASCII > > On 30 Oct 2010 at 19:47, Tony Duell wrote: > >> ...And if they;'re not, it's most likelyto be the drive belt. Yes I >> know 'up to speed' wasn't meant to be taken literally, but that seemed >> too good to miss :-) > > Well, he could have a 220V 50Hz model and be running it on 120V 60Hz > (the motor will develop sufficient torque to spin the disk). I've > made that mistake once. The results from the reverse would be > "interesting"... > > --Chuck > > > > ------------------------------ > > Message: 7 > Date: Sat, 30 Oct 2010 15:29:06 -0400 > From: Dave McGuire <mcguire at neurotica.com> > Subject: Re: DiscFerret: First working hardware, firmware and > microcode! > To: General Discussion: On-Topic and Off-Topic Posts > <cctalk at classiccmp.org> > Message-ID: <4CCC7202.6050705 at neurotica.com> > Content-Type: text/plain; charset=UTF-8; format=flowed > > On 10/30/10 2:35 PM, Philip Pemberton wrote: >> I can't see any real reason why SA1000 support couldn't be added to the >> bridge-board. Looks like the only changes required would be: >> - An oscillator to generate the 3.6866us +/- 0.1% timing clock (270982 >> to 271524Hz, nominal 271253Hz). Although I have no idea what standard >> crystal frequencies could be used to generate that signal. The FPGA's >> PLL might be persuaded to do it, though, I'll have to check. > > You could stick a little AD9833 (or similar) DDS chip on there. It's > overkill, but they're pretty cheap now, and you'll get the desired > frequency spot-on. > > -Dave > > -- > Dave McGuire > Port Charlotte, FL > > > ------------------------------ > > Message: 8 > Date: Sat, 30 Oct 2010 15:34:25 -0400 > From: Dave McGuire <mcguire at neurotica.com> > Subject: Re: Happy Birthday VAX 11/780 (influence of) > To: General Discussion: On-Topic and Off-Topic Posts > <cctalk at classiccmp.org> > Message-ID: <4CCC7341.1090704 at neurotica.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 10/30/10 1:08 PM, Chuck Guzis wrote: >> Aside from expanding program storage, the large addressing space was >> used to map file space (another type of "memory-mapped I/O"), so file >> access was actually performed through the paging hardware/software. >> That was kind of cool, as the STAR was a memory-to-memory vector >> machine, so you could use vector instructions on entire files, rather >> than have to issue reads and writes for pieces of a file. > > That functionality is in use all over the place today as mmap(), > accessing files as if they were memory, pushing the read/write burden > out into the VM system. It's extremely effective. > > I'd not consider it to be "memory-mapped I/O" at all, though, in the > context of "a processor reading and writing I/O ports". Sure, file I/O > is a sort of I/O, and mmap() and similar techniques map that file I/O > into the address space, but the context of this discussion...and indeed, > most, it not all use of the term "memory-mapped I/O" doesn't refer to > this sort of thing. > > -Dave > > -- > Dave McGuire > Port Charlotte, FL > > > ------------------------------ > > Message: 9 > Date: Sat, 30 Oct 2010 20:58:46 +0100 > From: Philip Pemberton <classiccmp at philpem.me.uk> > Subject: Re: DiscFerret: First working hardware, firmware and > microcode! > To: General Discussion: On-Topic and Off-Topic Posts > <cctalk at classiccmp.org> > Message-ID: <4CCC78F6.9040004 at philpem.me.uk> > Content-Type: text/plain; charset=UTF-8; format=flowed > > On 30/10/10 20:29, Dave McGuire wrote: >> You could stick a little AD9833 (or similar) DDS chip on there. It's >> overkill, but they're pretty cheap now, and you'll get the desired >> frequency spot-on. > > ?8.25 each with no quantity discount is *not* cheap. The FPGA only costs > a few quid more than that. > > Digikey have them for ?5.86, but that's still more than a crystal. I > wonder how the host adapters for the SA1000s generated this clock > frequency... it does seem somewhat odd. > > The other thing is, I'd be concerned about releasing hardware with > SA1000 support without testing it on an actual drive. I'm willing to bet > the chances of me finding a working SA1000 in 230V/50Hz configuration > are somewhere between 'slim' and 'nil'. > > I'll guarantee ST506 support though, given that I've got an ST277R RLL > drive and controller here. Just need an MFM controller for it, or the > RLL code tables for the Seagate ST21R or ST22R controller (which IIRC > uses an Adaptec AIC010 chip)... > > -- > Phil. > classiccmp at philpem.me.uk > http://www.philpem.me.uk/ > > > ------------------------------ > > Message: 10 > Date: Sat, 30 Oct 2010 13:23:00 -0700 > From: Brent Hilpert <hilpert at cs.ubc.ca> > Subject: Re: TTL HEX LED driver chip > To: "General Discussion: On-Topic and Off-Topic Posts" > <cctalk at classiccmp.org> > Message-ID: <8534ab06c8e0281a7fcfc54d6a70efa5 at cs.ubc.ca> > Content-Type: text/plain; charset=US-ASCII; format=flowed > > On 2010 Oct 30, at 10:21 AM, Chuck Guzis wrote: > >> On the same topic here, can anyone interpret the "state table" on the >> second page of the National DM74LS447 7-segment decoder datasheet? >> >> http://pdf1.alldatasheet.com/datasheet- >> pdf/view/149198/NSC/DM74LS447N.html >> >> I tend to think of state diagrams as belonging to things such as >> counters and don't have a clue as to what to make of the one >> furnished. > > It's obviously a state diagram for a decade counter, my guess is > someone just screwed up making the datasheet and included the state > diagram from some other device. > > > > ------------------------------ > > Message: 11 > Date: Sat, 30 Oct 2010 13:36:50 -0700 > From: Brent Hilpert <hilpert at cs.ubc.ca> > Subject: Re: Happy Birthday VAX 11/780 (influence of) > To: "General Discussion: On-Topic and Off-Topic Posts" > <cctalk at classiccmp.org> > Message-ID: <d40186fd9ded72a101d654d9516da0f5 at cs.ubc.ca> > Content-Type: text/plain; charset=US-ASCII; format=flowed > > On 2010 Oct 30, at 12:34 PM, Dave McGuire wrote: > >> On 10/30/10 1:08 PM, Chuck Guzis wrote: >>> Aside from expanding program storage, the large addressing space was >>> used to map file space (another type of "memory-mapped I/O"), so file >>> access was actually performed through the paging hardware/software. >>> That was kind of cool, as the STAR was a memory-to-memory vector >>> machine, so you could use vector instructions on entire files, rather >>> than have to issue reads and writes for pieces of a file. >> >> That functionality is in use all over the place today as mmap(), >> accessing files as if they were memory, pushing the read/write burden >> out into the VM system. It's extremely effective. > > I remember in the 80's (programming primarily on BSD (and VMS)) > thinking it would nice to have that functionality, how easy it would > make a lot of file-access programming, and that it would be easy to add > on a VM system. Of course, I was in ignorance of the prior histories > such as the STAR that Chuck mentions. A few years later a friend would > tell me about the new mmap function in unix. > > >> I'd not consider it to be "memory-mapped I/O" at all, though, in the >> context of "a processor reading and writing I/O ports". Sure, file >> I/O is a sort of I/O, and mmap() and similar techniques map that file >> I/O into the address space, but the context of this discussion...and >> indeed, most, it not all use of the term "memory-mapped I/O" doesn't >> refer to this sort of thing. > > Well, Chuck did say "a type of". If files are a form of abstracted disk > I/O, then mmap is a form of abstracted memory-mapped I/O. > > > > ------------------------------ > > Message: 12 > Date: Sat, 30 Oct 2010 13:36:53 -0700 (PDT) > From: Bob Rosenbloom <bobalan at sbcglobal.net> > Subject: Fall cleaning, some small machines for free > To: "General Discussion: On-Topic and Off-Topic Posts" > <cctalk at classiccmp.org> > Message-ID: <960487.42595.qm at web80502.mail.mud.yahoo.com> > Content-Type: text/plain; charset=us-ascii > > > Fall cleaning! > > I have a bunch of old computers and some peripherals. Most are not tested > and I expect they may need some work to become operational, though some > may work correctly as-is. Anyway, I'm hoping to find people interested in > restoring these systems. > > There are three Burroughs B25 systems, each has a processor box, disk box, > monitor, keyboard, and power supply. There is one box of docs and > diskettes and one, very dirty, printer. > http://www.anifur.com/clist/misc-b1.jpg > http://www.anifur.com/clist/misc-b2.jpg > http://www.anifur.com/clist/misc-b3.jpg > http://www.anifur.com/clist/misc-b4.jpg > > IBM convertible, an early laptop type system. > > A Computer Products portable, thermal, serial terminal. > http://www.anifur.com/clist/misc-ptr.jpg > > A Radio Shack TRS-80 model I with expansion chassis and monitor. I believe > this has a bad power supply. > http://www.anifur.com/clist/misc-rs.jpg > > A NEC Spinwriter terminal. This is like a Diablo daisywheel terminal > except the print element is a cylinder. I know this one needs work but > does power up. > http://www.anifur.com/clist/misc-spin.jpg > > Some kind of cartridge tape system. I think it's SCSI interfaced. I don't > believe this has ever been used. > http://www.anifur.com/clist/misc-tape.jpg > > A large flatbed scanner that I also believe is unused. It's SCSI > interfaced. UMAX 3000. > http://www.anifur.com/clist/misc-scanner.jpg > > Digitech RS-232 analyzer with manuals. This runs CP/M 86 but I don't have > the boot disc for it. Does power up. > http://www.anifur.com/clist/misc-anal.jpg > > Kaypro 2, powers up and ask for a system disk. > http://www.anifur.com/clist/kaypro1.jpg > > Hitachi pen plotter. This has a parallel interface. It powers up and works > from the front panel. Light weight. > http://www.anifur.com/clist/hitachi1.jpg > > Panasonic NV-A960 VCR editing unit. > http://www.anifur.com/clist/a960-1.jpg > > Nicolet Zeta 8A pen plotter. 8 pens. Also powers up and works from the > front panel. Serial interface. > > All of these are located in the Santa Cruz, CA mountains, near the Bonny > Doon airport. I can possibly bring something into Santa Clara where I > work. Best to come visit and check them out here. I really don't want to > ship anything as I just don't have the time or energy. > > Please rescue these before I scrap them, I really need the space and these > are now outside, but covered under a Quonset hut. > > Bob > > > ------------------------------ > > Message: 13 > Date: Sat, 30 Oct 2010 13:39:13 -0700 > From: "Chuck Guzis" <cclist at sydex.com> > Subject: Re: DiscFerret: First working hardware, firmware and > microcode! > To: "General Discussion: On-Topic and Off-Topic Posts" > <cctalk at classiccmp.org> > Message-ID: <4CCC2001.27472.DB6112 at cclist.sydex.com> > Content-Type: text/plain; charset=US-ASCII > > On 30 Oct 2010 at 15:29, Dave McGuire wrote: > >> On 10/30/10 2:35 PM, Philip Pemberton wrote: >> > I can't see any real reason why SA1000 support couldn't be added to >> > the bridge-board. Looks like the only changes required would be: - >> > An oscillator to generate the 3.6866us +/- 0.1% timing clock (270982 >> > to 271524Hz, nominal 271253Hz). Although I have no idea what >> > standard crystal frequencies could be used to generate that signal. >> > The FPGA's PLL might be persuaded to do it, though, I'll have to >> > check. >> >> You could stick a little AD9833 (or similar) DDS chip on there. >> It's >> overkill, but they're pretty cheap now, and you'll get the desired >> frequency spot-on. > > Also, aren't the read/write data signals on the SA1000 differential? > Or do I have them confused with the ST506 interface? > > --Chuck > > > > ------------------------------ > > Message: 14 > Date: Sat, 30 Oct 2010 13:52:12 -0700 > From: alan canning <scanning.cc at gmail.com> > Subject: Need to find parts 82S23 / 74S188 > To: "General Discussion: On-Topic and Off-Topic Posts" > <cctalk at classiccmp.org> > Message-ID: > <AANLkTinzHd-NW1yL2LFuNG1=1q7s3hKOdxe2VLr7uXLH at mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Anybody no where to score some Sig 82S23 / Nat 74S188 parts ? I've tried > all > the usual suspects ( Ebay, local parts houses, Digikey, etc. ) with no > joy. > I believe this part was used on old S100 boards. > > Part also known as ( a.k.a. ) Fu 7111, AMD 27S18, MMI 6330, TI 18SA30 and > Harris 7602. Need this part to fix an old computer controlled RF Power > amplifier. > > Thanks for any and all help. > > Best regards, Steven > > > ------------------------------ > > Message: 15 > Date: Sat, 30 Oct 2010 13:54:40 -0700 > From: "Chuck Guzis" <cclist at sydex.com> > Subject: Re: Happy Birthday VAX 11/780 (influence of) > To: "General Discussion: On-Topic and Off-Topic Posts" > <cctalk at classiccmp.org> > Message-ID: <4CCC23A0.9876.E985BD at cclist.sydex.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On 30 Oct 2010 at 15:34, Dave McGuire wrote: > >> I'd not consider it to be "memory-mapped I/O" at all, though, in >> the >> context of "a processor reading and writing I/O ports". Sure, file >> I/O is a sort of I/O, and mmap() and similar techniques map that file >> I/O into the address space, but the context of this discussion...and >> indeed, most, it not all use of the term "memory-mapped I/O" doesn't >> refer to this sort of thing. > > I'm sure and I'd never seriously call it "memory-mapped I/O"--but > sometimes our world seems akin to that of Humpty-Dumpty: "When I use > a word it means just what I choose it to mean--neither more nor less" > > Uh-oh, here comes another story... > > After I left CDC and the STAR project in 1977, my past came back to > haunt me in the form of doing an optimizing FORTRAN for the ETA-10 in > about 1983. We got a leased-line linkup to ETA in St. Paul and I > asked what text editor they were using. > > Much to my surprise, it turned out to be the same editor I'd written > for a lark around 1975 when the STAR had lots of really interesting > byte string instructions and I could exploit file-mapped I/O to use > them. Mind you, this was in the day of 16-line 1200 bps terminals. > > But the ETA-10 had none of those instructions, essentially having > evolved out of the "everything but the kitchen sink CISC" state of > mind of the original architecture. Some programmer had been detailed > off to replace all of those cool vector instructions with their > scalar equivalents! > > I was stunned and opined that with that way of thinking, the software > end of the ETA project was doomed. > > --Chuck > > > > ------------------------------ > > Message: 16 > Date: Sat, 30 Oct 2010 21:58:20 +0100 > From: Philip Pemberton <classiccmp at philpem.me.uk> > Subject: Re: DiscFerret: First working hardware, firmware and > microcode! > To: General Discussion: On-Topic and Off-Topic Posts > <cctalk at classiccmp.org> > Message-ID: <4CCC86EC.8040906 at philpem.me.uk> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 30/10/10 21:39, Chuck Guzis wrote: >> Also, aren't the read/write data signals on the SA1000 differential? >> Or do I have them confused with the ST506 interface? > > They're both differential. It's just that the SA1000 expects you to feed > it a reference clock signal. It doesn't have to be locked against > write-data, it just has to be there, and be accurate to 0.1%... > > Assuming the OEM manual is accurate, of course. > > -- > Phil. > classiccmp at philpem.me.uk > http://www.philpem.me.uk/ > > > ------------------------------ > > Message: 17 > Date: Sat, 30 Oct 2010 21:23:40 +0100 (BST) > From: ard at p850ug1.demon.co.uk (Tony Duell) > Subject: Re: TTL HEX LED driver chip > To: cctalk at classiccmp.org > Message-ID: <m1PCHxn-000J3xC at p850ug1> > Content-Type: text/plain > >> >> On 29 Oct 2010 at 22:10, Tony Duell wrote: >> >> > Anyother thought I had is to use a 7447 for the lower 8 or 10 >> > patterns (as it's designed to do!) and add logic for the higher ones. >> > I don't know if that saves chips. >> >> The 7447 has a problem in that the "6" doesn't have the top crossbar, >> so that it's indistinguishable from a "b". The '247 does include the >> top segment when displaying '6', which is why I mentioned the 247 and >> not 47. > > Yes, I should have remembered that... > > >> >> This brings to mind an ancient "fix" for the 47 "6" display--a >> pulldown diode connected between segment "e" and segment "a"--in the > > Been there, done that :-) > >> display of 0-9 there is no time when segment "e" is active that >> segment "a" isn't also active. The converse, however isn't true--and >> this "fix" will mess up your display of "b" if you use the method >> described previously to display 0-F. > > Of course. For 'b' you mmed the 'e' segment without the 'a' segment. > That's what distinguishes it from '6' > > >> >> But if you allow diodes, then there's no reason not to use a 4-to-16 >> demux and a mess of diodes to do the decoding for 0-F, is there? > > while my original question didn't preclude the use of discrete > components, and while I happly ageee that the odd diodes, pull-up > resisotrs, etc can lead to interesting solutions, I do feel that such a > diode matrix is outisde the spirit of the problem. After all, you could > say it can be solved with no ICs at all, just lots of discrete > transistors, etc. :-) > > -tony > > > ------------------------------ > > Message: 18 > Date: Sat, 30 Oct 2010 21:27:54 +0100 (BST) > From: ard at p850ug1.demon.co.uk (Tony Duell) > Subject: Re: Nuclear Data ND 6600 > To: cctalk at classiccmp.org > Message-ID: <m1PCI1t-000J3yC at p850ug1> > Content-Type: text/plain > >> eons ago at a TRW a friend bought a nice box that looked much like an >> ADM3a with nice case, integrated CRT and keyboard, and gleefully gave >> the guy selling it about $40 for it. This was in the day of $700 >> terminals new prices. >> >> It was a Vector graphics console. Unfortunately he had not looked at >> the back, or thru the cracks, but it was a plastic case with a keyboard >> and CRT inside, no PS, electronics or anything else. I suspect when he > > I am suprised there wasn't the standard driver circuits for the CRT (from > composite vidoe, say). My guess is that there should have been, and they > were msising. > >> moved east some years ago it got dumpstered, but it was about the same >> sort of thing, no brains in the "terminal" but in the box. > > ICL did something similar. They had 'terminals' that consisted of encoded > keyboards and composite monitors. The case was painted a horrible orange > colour ... I think I still have one of the keyboards somewhere, but I > mangaged to give the monitor away some years ago (thankfully...) > > -tony > > > ------------------------------ > > Message: 19 > Date: Sat, 30 Oct 2010 22:07:02 +0100 (BST) > From: ard at p850ug1.demon.co.uk (Tony Duell) > Subject: Re: TRS-80 Model II Manuals > To: cctalk at classiccmp.org > Message-ID: <m1PCIdm-000J4HC at p850ug1> > Content-Type: text/plain > >> >> On 30 Oct 2010 at 19:47, Tony Duell wrote: >> >> > ...And if they;'re not, it's most likelyto be the drive belt. Yes I >> > know 'up to speed' wasn't meant to be taken literally, but that seemed >> > too good to miss :-) >> >> Well, he could have a 220V 50Hz model and be running it on 120V 60Hz >> (the motor will develop sufficient torque to spin the disk). I've >> made that mistake once. The results from the reverse would be >> "interesting"... > > Actaully, a lot of the 8" drives I have have 120V motors, but of course > the right pulleys for 50Hz mains. They are run from an > (auto)transformer, often the primary winding of the syatem mains > transformer. > > So I suppose he could have something like that :-) > > -tony > > > ------------------------------ > > Message: 20 > Date: Sat, 30 Oct 2010 21:41:27 +0100 (BST) > From: ard at p850ug1.demon.co.uk (Tony Duell) > Subject: Re: TTL HEX LED driver chip > To: cctalk at classiccmp.org > Message-ID: <m1PCIF1-000J48C at p850ug1> > Content-Type: text/plain > >> >> On 2010 Oct 29, at 2:10 PM, Tony Duell wrote: >> > >> > For those who are wondeirng, the 'trivial' solution I mentioned uses 7 >> > off 74150 16-input multiplexers, one for each segment. You tie the >> > inputs >> > high low to determine if that segment is on or off for a given set fo 4 >> > input bits. >> > >> > After posing that, I thought of other solutions that make no >> > assumptions >> > about the segment patterns -- they always work. For example 7 off >> > 74151 8 >> > input muxes and a single inverter (1/6 of a 7404) That has the >> > advantage >> > of automatically providing actrive high and active low outputs. >> >> That only gives you 8 patterns, not 16 .. ? > > Err, no. That's what the extra inverter is for. > > You know hos to use a 2^n input mux to make an arbitrary combinartorial > function of n signals. Feed the n signals to the select inputs of the > multiplexer and wire the 'data' inputs high or low as the truth table > requires. > > But you can also yuse a 2^(n-1) input mux and maybe a single inverte, you > connect n-1 of the input lines to the select inputs of the mux. And then > for each of those combinations you consider the 2 truth table lines that > apply (the last input, the one you've not used yet, of course > distinguishes between the 2 lines in each pair). There are 4 possibilites > : > a) The output of the function is 0 in both cases (it doesn't depend on > the last input at all) --> wire that input of thr mux to ground > > b) It's 1 in both cases -> wire the input to Vcc > > c) It's 0, 1 , it follows the last input in this case -> Wire that last > input signal to the appropraite input of the multiplexer > > d) It's 1,0, it's the opposite of the last input. This is when you need > that inverter. Invert the last input signal and wire the appropriate > multiplexer input to the ouptu of the inverter. > > If oyu requre several functions of the same inputs (as here), you only > need 1 ivnerter (assumeing there are no fan-out problems), since it's > always thge same singal (say the 2^0 data input) you need to invert. > > Son yes, you can use 8 input multiplexers here (and 4 input ones if you > only want to generate 6 or 8 patterns). > > Now, another silly aside... > > If you want to use a 2^(n-2) mux, you may need any or all of the 16 > possible functions of the last 2 inputs (you split up the truth table > into sets of 4 lines, and see which function of the last 2 inputs gives > the right paattern, of course). This makes it less useful :-). But it's > made me think pof a chip that AFAIK never existed... If you think of those > 16 possible functions of 2 inputs, then 4 of them are 'trivial' in the > sense that you can produce them with no logic at all. Namely 'always 0', > 'always 1', 'equal to the A input' and 'equal to the B input'. Which > leaves 12 non-rtrivial ones/ Now that means there could have been a 16 > pin IC with 2 power pins, 2 inputs and 12 outputs, the 12 non-trivial > functions of the 2 inputs. Use that witha 74150 for an arbitrary fucntion > of 6 inputs... > > -tony > > > > ------------------------------ > > Message: 21 > Date: Sat, 30 Oct 2010 21:44:22 +0100 (BST) > From: ard at p850ug1.demon.co.uk (Tony Duell) > Subject: Re: TTL HEX LED driver chip > To: cctalk at classiccmp.org > Message-ID: <m1PCIHq-000J49C at p850ug1> > Content-Type: text/plain > >> >> On 29 Oct 2010 at 16:13, Brent Hilpert wrote: >> >> > I too realised that halfway thru the exercise and went scrambling back >> > to the databook to check on the 247. >> >> Another reason to lament the passing of the hardcopy databook. I >> used to sit and read them cover-to-cover. Not really possible in > > Absolutely. Of cousre I've kept all my old paper databooks, and still > read them from time to tieme. > > Yes, it's very useful being able to get data on just about any standard > IC over the internet. But it's useful in a different way being able to > flip through a data book, see what's available, etc. I've yet to find a > manufacturer's site that lets me browse in the same way. > > -tony > > > ------------------------------ > > Message: 22 > Date: Sat, 30 Oct 2010 21:48:01 +0100 (BST) > From: ard at p850ug1.demon.co.uk (Tony Duell) > Subject: Re: Wanted : Monitor Capable of TTL RGB > To: cctalk at classiccmp.org > Message-ID: <m1PCILO-000J4AC at p850ug1> > Content-Type: text/plain > >> >> On 30/10/10 03:08, Dan Williams wrote: >> > I am on the lookout for a monitor something similar to a Phillips >> > cm3388 does anyone near London have one they would like to sell or >> > trade, or know of anywhere I could get one. >> >> Surely you mean the CM8833? >> Those were fairly extensively re-badged -- Acorn, for instance, sold a=20 >> variant of the CM8833 Mk.II as the AKF17. > > Is CM8833 a TTL-input monitor? I think it was available as an option, > but most of them take analogue RGB on the SCART socket. > > Most of the time the SCART inputs, for all they're supposed to be 1V will > stand TTL (the CM8833 ones certainly will). Or since they're terminated > to ground through a 75 ohm resistor, connect a 300 Ohm (or so) resistor > in series with each TTL signal. Done that many times :-) > > Is there any reason a TV with a SCART socket isn't suitable? Most, if not > all, LCD and plasma TVs should haev RGB inputs on the SCART socket, for > example. > > -tony > > > > ------------------------------ > > Message: 23 > Date: Sat, 30 Oct 2010 21:52:09 +0100 (BST) > From: ard at p850ug1.demon.co.uk (Tony Duell) > Subject: Re: I/O models (was RE: Happy Birthday VAX 11/780 (influence > of)) > To: cctalk at classiccmp.org > Message-ID: <m1PCIPM-000J4BC at p850ug1> > Content-Type: text/plain > >> >> OK, it's fair to say that there's nothing that precludes memory-mapped >> I/O = >> in any machine (except perhaps physical memory architecture, although I >> can= >> 't think of an example). But port-mapped I/O machines had specific >> instruc= > > The obvious problem would be if the memroy map is already totally full. > If you've got a Z80 systme with 64K of memory, it would be perverse to > try memory mapped I/O (you could have some kind of MMU, but why...). > Similarky trying to emmeroy map any kind of I/O on a 2MByte PERQ would be > an 'interesting' exercise... > > -tony > > > > ------------------------------ > > Message: 24 > Date: Sat, 30 Oct 2010 14:09:44 -0700 > From: Brent Hilpert <hilpert at cs.ubc.ca> > Subject: Re: Fall cleaning, some small machines for free > To: "General Discussion: On-Topic and Off-Topic Posts" > <cctalk at classiccmp.org> > Message-ID: <981998b8f30737dece941bd3fc38a0c1 at cs.ubc.ca> > Content-Type: text/plain; charset=US-ASCII; format=flowed > > On 2010 Oct 30, at 1:36 PM, Bob Rosenbloom wrote: >> >> Panasonic NV-A960 VCR editing unit. >> http://www.anifur.com/clist/a960-1.jpg > > I dismantled one of these a few years ago, it contained an > (NEC-branded) 8080, a whack of NEC 8255's (PIO), half-a dozen ceramic > Fujitsu MB8516's (2K*8 EPROMS, 2716-like), all socketed, for anyone > that might take an interest in such stuff. > > >> All of these are located in the Santa Cruz, CA mountains, near the >> Bonny Doon airport. I can possibly bring something into Santa Clara >> where I work. Best to come visit and check them out here. I really >> don't want to >> ship anything as I just don't have the time or energy. >> >> Please rescue these before I scrap them, I really need the space and >> these are now outside, but covered under a Quonset hut. >> >> Bob > > > > ------------------------------ > > Message: 25 > Date: Sat, 30 Oct 2010 15:11:06 -0600 > From: ben <bfranchuk at jetnet.ab.ca> > Subject: Re: Need to find parts 82S23 / 74S188 > To: General Discussion: On-Topic and Off-Topic Posts > <cctalk at classiccmp.org> > Message-ID: <4CCC89EA.1000405 at jetnet.ab.ca> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > looks for 74S188 with google > http://www.futurlec.com/Memory/74S188pr.shtml > > > ------------------------------ > > Message: 26 > Date: Sat, 30 Oct 2010 14:17:16 -0700 > From: Geoffrey Reed <geoffr at zipcon.net> > Subject: Re: TRS-80 Model II Manuals > To: cctalk <cctalk at classiccmp.org> > Message-ID: <C8F1D96C.2E65E%geoffr at zipcon.net> > Content-Type: text/plain; charset="US-ASCII" > > Y'all are making me miss my tandy model 16 and 6000. > > > > > ------------------------------ > > Message: 27 > Date: Sat, 30 Oct 2010 22:21:08 +0100 (BST) > From: ard at p850ug1.demon.co.uk (Tony Duell) > Subject: Re: Need to find parts 82S23 / 74S188 > To: cctalk at classiccmp.org > Message-ID: <m1PCIrQ-000J3xC at p850ug1> > Content-Type: text/plain > >> >> Anybody no where to score some Sig 82S23 / Nat 74S188 parts ? I've tried >> all >> the usual suspects ( Ebay, local parts houses, Digikey, etc. ) with no >> joy. >> I believe this part was used on old S100 boards. >> >> Part also known as ( a.k.a. ) Fu 7111, AMD 27S18, MMI 6330, TI 18SA30 and >> Harris 7602. Need this part to fix an old computer controlled RF Power >> amplifier. > > IIRC, this is a PROM, 32*8 I think. Do you have a copy of the data to > program into it? A blank chip is not a lot of use to you otherwise... > > Also while all the derives you've mentioned are I think compatible when > being read (that is, as they are normally used in the circuit), the > programming algorithms are different for differnet manufacturers. You need > to get one that your programmer can handle > > -tony > > > ------------------------------ > > Message: 28 > Date: Sat, 30 Oct 2010 14:18:38 -0700 > From: "Chuck Guzis" <cclist at sydex.com> > Subject: Re: Need to find parts 82S23 / 74S188 > To: "General Discussion: On-Topic and Off-Topic Posts" > <cctalk at classiccmp.org> > Message-ID: <4CCC293E.2099.FF7864 at cclist.sydex.com> > Content-Type: text/plain; charset=US-ASCII > > On 30 Oct 2010 at 13:52, alan canning wrote: > >> Anybody no where to score some Sig 82S23 / Nat 74S188 parts ? I've >> tried all the usual suspects ( Ebay, local parts houses, Digikey, etc. >> ) with no joy. I believe this part was used on old S100 boards. >> >> Part also known as ( a.k.a. ) Fu 7111, AMD 27S18, MMI 6330, TI 18SA30 >> and Harris 7602. Need this part to fix an old computer controlled RF >> Power amplifier. > > If you'd like something a bit closer to home, you might try ACP-- > they're listing some IM5603s on eBay for $7.95 the each. > > --Chuck > > > > End of cctalk Digest, Vol 86, Issue 68 > **************************************

14 years, 1 month

I/O models (was RE: Happy Birthday VAX 11/780 (influence of))

by IanK＠vulcan.com

OK, it's fair to say that there's nothing that precludes memory-mapped I/O in any machine (except perhaps physical memory architecture, although I can't think of an example). But port-mapped I/O machines had specific instructions for I/O, which might well facilitate the process beyond the simple mechanics of memory-mapped I/O (think about polling on a skip flag on a PDP-8) but also potentially limited one in either range or capability. It's also important to recognize that the PDP-11 *enforced* memory-mapped I/O in an upper region, which limited working store (and it was not the only machine to do so, e.g. Alto). And we're discussing this because...? :-) ________________________________________ From: cctalk-bounces at classiccmp.org [cctalk-bounces at classiccmp.org] On Behalf Of Dave McGuire [mcguire at neurotica.com] Sent: Friday, October 29, 2010 10:31 PM To: On-Topic and Off-Topic Posts Subject: Re: Happy Birthday VAX 11/780 (influence of) On 10/29/10 4:55 PM, Tony Duell wrote: >>> Just because a CPU architecture has IO instructions doesn't mean you >>> can't do memory-mapped I/O. > > I beleive Steve Ciarcia said in one of the Circuit Cellar articles in > Byte many year ago that any processor that could access memory could have > memory-mapped I/O. He certainly did, I remember that article well. He started the article by relating a conversation that he'd had with a fellow computer guy, and they were arguing (I think) 6800 vs. Z80. He said something like "When he said the 6800 had memory-mapped I/O and the Z80 didn't, I knew he didn't know what it was". :) -Dave -- Dave McGuire Port Charlotte, FL

14 years, 1 month

Memory mapped I/O

by bqt＠softjar.se

On 2010-10-30 01:12, ard at p850ug1.demon.co.uk (Tony Duell) wrote: >>> > > Just because a CPU architecture has IO instructions doesn't mean you >>> > > can't do memory-mapped I/O. > I beleive Steve Ciarcia said in one of the Circuit Cellar articles in > Byte many year ago that any processor that could access memory could have > memory-mapped I/O. Good point. Was the PDP-11 the first computer that did not have dedicated I/O instructions then? Thus relying on memory mapped I/O, instead of just having it as a potential (as any computer do). Did anyone before the PDP-11 actually utilize memory mapped I/O before? The fact that lots of machines do it today (even the x86 I guess) could just be a legacy of the PDP-11 making it popular? (Oh, and I'm not counting the IOT instruction on the PDP-11 as an I/O instruction... :-) ) > I would add that in the case of a system (rather than a bare processor), > it helps if there's some spare space in the memroy map:-). Indeed. :-) >> > And there were other PC displays, that didn't use memory-mapped video > if by 'PC' here you mean something descended from the IBM5150 then I am > curious. All the IBM dipslay adapdaters that I can think of were memory > mapped. Yes, even the PGC had a memory-mapped CGA emulation. 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

14 years, 1 month

Happy Birthday VAX 11/780 (influence of)

by bqt＠softjar.se

On 2010-10-28 23:02, Rich Alderson<RichA at vulcan.com> wrote: > From: Brad Parker > Sent: Thursday, October 28, 2010 10:12 AM > > On Oct 27, 2010, at 11:31 AM, William Donzelli wrote: > >>>> >>> You could insert a small paragraph here about the role of unix and how >>>> >>> unix and the pdp-11 and vax interacted. >>> >> Are you saying that the PDP-11 and VAX were the first machines where >>> >> the hardware and software were both considered and designed together? >>> >> Once again, I think a lot of people would not agree with that. >> > No, I didn't say that at all. I was just saying that the it would be >> > interesting to explore how the pdp-11 and VAX architectures influenced >> > the design of unix, and how unix, in turn, influenced software >> > development as a whole. I thin the two are interrelated. > From what Thompson and Ritchie have written about the origins of Unix, > the PDP-11's architecture had very little to do with how it was created. > The original PDP-7 Unix (specific I/O ports addressed in I/O instructions, > 18-bit words, word addressing) was taken up and ported to the PDP-11 with > few or no user-visible changes. Indeed. Well, I don't know about few or no user-visible changes, but there is no denying that Unix started on a PDP-7, and not a PDP-11. > Because the VAX offered a virtual memory capability (hi, Johnny!:-), it > did change the way Unix developed, but so did other ports (Interdata, for > example, and even the IBM Series/1). Hi. :-) I hope you do remember that early versions of Unix (even on the VAX) did not do demand paging. Are you saying that they didn't have virtual memory either, then? :-) BSD3 anyone? As for what PDP-11 might have innovated, we have covered the memory mapped I/O at some length now, and it appear that the PDP-11 might atleast have a half claim to fame there. But, as some pointed out, the x86 do not use memory mapped I/O (and shared memory with a graphics subsystem is not the same thing). Most RISC machines did/do use memory mapped I/O anyway, but I digress... I have not seen anyone comment any of the other things I listed as possible firsts on the PDP-11. Can anyone come up with an earlier machine that used condition codes? How about general registers with addressing modes, which is totally orthogonal? How about having the PC as a general register? I don't know of any machines before the PDP-11 that had these. Admittedly, the only one of these attributes the x86 inherited (from wherever) is condition codes, but I think it might be interesting to hear the collective wisdom on some more details than just memory mapped I/O... 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

14 years, 1 month

TRS-80 Model II Manuals

by fjkraan＠xs4all.nl

Thanks to the ever-useful JP Hindin, I've obtained a set of TRS-DOS > disks and other application disks for my TRS-80 Model II system, which > is the entire setup pictured here, plus a bit more: > > http://oldcomputers.net/pics/TRS-80-II_table.JPG > > It's been sitting, covered, pretty much since I obtained it, but now I > can try reviving it and actually seeing what it can do. I'm going to > tear into it and clean the drives and so forth, document what it has, > etc. and then boot 'er up and see what we can see. > > I'm looking for a copy of the Technical Ref manual for it; despite > finding scans of the covers and so forth online, I'm unable to actually > locate one. In addition to that, if someone has a Shugart 8" Service > Manual, that might come in damned handy for making sure those are up to > speed as well. > See http://electrickery.xs4all.nl/comp/mirror/trs-80_archives/Manuals/Hardware/…. The Shugart stuff should be included. Essential this is from a modified copy of the files that were available >from http://www.trs-80.com/ (copied without permission). > Many thanks, > > Nathan > > Success, Fred Jan P.S. My own adventures with the Model II: http://www.xs4all.nl/~fjkraan/comp/trs80m2/

14 years, 1 month

More A4000 that I forgot to put in the previous message

by binarydinosaurs＠gmail.com

Hi again, Has anyone got a spare Zorro Ethernet card I can buy/borrow? Cheers! -- adrian/witchy Owner of Binary Dinosaurs, the UK's biggest home computer collection? www.binarydinosaurs.co.uk

14 years, 1 month

Amiga Kickstart 3.1

by binarydinosaurs＠gmail.com

Hi folks, Anyone got some spare Kickstart ROMs for an Amiga 4000? I'm doing an exhibition in a couple of weeks time and completely forgot my A4000 is only on KS 3.0! I have OS3.5 ready to install. I also picked the wrong time to give away my DEC 3000-300s since the one I kept blew up this afternoon, fortunately we have spares for that at work I can 'borrow' :) Cheers! -- adrian/witchy Owner of Binary Dinosaurs, the UK's biggest home computer collection? www.binarydinosaurs.co.uk

14 years, 1 month

VAX addressing

by bqt＠softjar.se

On 2010-10-30 01:12, <arcarlini at iee.org> wrote: > Johnny Billquist [bqt at softjar.se] wrote: > >> > Now, I direct you all to page 4-7 of that document, which talks about >> > physical addresses on a VAX. >> > Notice how a physical address on a VAX can be 34 bits, while the > virtual >> > address is only 32 bits. > > VAX virtual addresses have always been 32-bits although system space S1 > (the top 1GiB) was never defined. The XVA project allowed it to be used > (on some hardware platforms). Yes. And the virtual address space is divided into 4 parts (as you well know :-) ). P0, P1, S0 and S1. Only P0 and P1 is actually process local, while S0/S1 is system wide. > The (related) XPA project allowed the physical address space to grow > beyond > 1GiB but only to 4GiB (32-bits). Well, the design allows it to grow to 34 bits. Specific implementations might have limited it to 32 bits, but that's another story. > DEC STD-032 does allow for a 34-bit PA implementation but I don't know > of > one. The VAX 6000/7000/10000 all only implemented 32-bit PA mode > (afaik). > I don't know (off hand) whether the chipset could do more. Two different things here. The NVAX chip have two different formats of the page address. 21 bits or 25 bits. With 21 bits, you can only get 30 bit physical addresses (the old VAX model). With 25 bits, you get a total of 34 bits of physical address. Now, I don't know if the NVAX brought all 34 address bits out of the chip, but that is the size of the physical address created by the MMU anyway. The actual machines, such as the VAX 7000 on the other hand, clearly only allowed a max of 4G. Of that, 3.5G was for physical memory, and 0.5G was reserved as I/O space. But that is a design decision of a machine, and have less bearing on the architecture. It is a question of the bus used in the machine, as well as where I/O adapters will be present on the bus, and so on. I suspect all software running on a VAX7000 to always have the top two bits of the PFN in the PTE to always be zero. But the bits are there none the less. Anyhow, even with only 3.5G of physical memory, it will be more physical memory than any one process can have virtual memory on the VAX, since a process cannot be larger than 2G (P0,P1) > So (barring any inormation to the contrary) I think it's only a > theoretical > possibility:-) Probably. It would be interesting to see the pinout of the NVAX chip, to see if they brought all 34 bits out on that chip. All existing VAXen restricted physical addresses to at most 32 bits, though. 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

14 years, 1 month

← Newer
1
...
4
5
6
7
8
9
10
...
28
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 October 2010