test-drb May 2000

test-drb@ccmp.vtda.org

172 participants
541 discussions

Software rental, "trusted computing", etc. (was Re: Is this for real -- a new C64/128)

by allisonp＠world.std.com

>I am sometimes asked 'what can that 20-year-old machine do'. One correct >answer is 'Everything it did 20 years ago' (I was having this discussion >with Philip Belben the other day, so some ideas here may have come from >that). In other words, that 20-year-old CP/M box with Wordstar was doing >word processing back then. It can still do word processing. Maybe not >with all the fancy fonts and formatting tricks of a more modern machine. >But it can still print letters, books, etc. And quite honestly, that's >all I need (and if people can't accept a plain ascii file from me, I have >no intention of dealing with them!). I would have said the same.... save for now we know that even with older hardware things like fonts and pretty printing are easily doable on hardware like IMSAIs and PDP11s (and often done well!). >It never fails to amaze me that computers are wonderful machines >_because_ they can be programmed to do just about anything. And then >modern OSes/applications (and things like the TCPA) seem to be preventing >you from programmming them. Go figure. The only difference between a PDP-11 and a PIII/750 is how long you may wait for the same results. Granted some software projects are only doable in reasonable time scales as a result of speed. For practical projects I have a 386/16 that does run W95 so speed is not the absolute catalyst. Remember: Stable Mature systems we know how to use, applies here. Allison

24 years, 7 months

Cool AppleSoft BASIC trick I never thought of before

by mranalog＠home.com

Sam said: > On the Apple ][, in AppleSoft BASIC, you can set what the start address > of your BASIC program will be in memory by poking it into location 103-104 > ($68-$69 hex). > The default is 2049 ($801): 103=1 and 104=8 ($68=1, $69=8). > QUESTION: Does anyone know why the default is $801 instead of $800? I > always wondered why that was. Anyway... _MANY_ BASICs have the same format for storing a program line. The first two bytes is the address "link" to the next line of the program. The second two bytes is the "line number" for this line of the program. The line number is followed by the text of the program line, with all of the BASIC keywords tokenized, and terminated with a zero. The next address location after the zero is the address pointed to by the link of the previous line and it's also the beginning of the next line of the program. At the end of a BASIC program, the zero at the end of the last line is followed by two zeros meaning that the next "link" is zero. When BASIC is initialized, (and the start of BASIC is normally $801), the OS usually stores zeros at $800,$801,and $802, and set the beginning of BASIC program space at $801, indicating that $800 is the end of the previous line and $801,$802 is the end of the program. So the BASIC program space DOES start at $800, but the beginning of the BASIC program is $801. _I_believe_ the need for a zero indicating the end of the previous line at the beginning of BASIC program space is probably a hold over from some ANCIENT incarnation of BASIC and is not really necessary, but I have not tried this with different kinds of BASIC. There should be no problem with setting the beginning of the BASIC program area to say.... $4057 before loading your program. As the program is loaded, the links are changed to reflect the new program location. > I run either of the programs and I get an endlessly alternating display of > "PROGRAM 1!" and "PROGRAM 2!". In other words, it works! Cool. BASIC also keeps a pointer to the current line being executed. Instead of "running" each program, try having the first program (at the end) set the current line pointer to $4001 and vicey versy. > It seems to me this could be mutated into a sort of practical method of > multi-tasking BASIC programs. There are quite a few zero page locations you need to save and restore, but multi-tasking BASIC is very possible. You could also write a BASIC program that built it's own custom subroutines in a different memory area on the fly, execute them, and return to itself. --Doug ==================================================== Doug Coward dcoward(a)pressstart.com (work) Sr. Software Eng. mranalog(a)home.com (home) Press Start Inc. http://www.pressstart.com Sunnyvale,CA Curator Analog Computer Museum and History Center http://www.best.com/~dcoward/analog ====================================================

24 years, 7 months

IBEX info? (fwd)

by vcf＠siconic.com

Beau added this info... ---------- Forwarded message ---------- Date: Tue, 16 May 2000 23:40:22 -0500 From: Beau Reichert <tcr1(a)bga.com> To: Vintage Computer Festival <vcf(a)siconic.com> Subject: Re: IBEX info? I system was made by logic systems international, inc. from japan. I guess it would be a mini computer. The system is new in box never been opened. I will get some pictures of it. The model number is 7202. Has big keyboard/cpu, a monitor unit, and a 2 big floppies in one unit - 60lbs. Thanks Beau Sellam International Man of Intrigue and Danger ------------------------------------------------------------------------------- Looking for a six in a pile of nines... Coming soon: VCF 4.0! VCF East: Planning in Progress See http://www.vintage.org for details!

24 years, 7 months

More Stupid AppleSoft Tricks

by foo＠siconic.com

Here's an article I wrote several years back detailing a method I used for list protecting AppleSoft BASIC programs. I'd actually devised this method in the mid-80s but decided to properly document it during a discussion on an Apple ][ newsgroup. It's a little long, and the BASIC program it references near the end is somewhere around here (I'll have to dig it out in case anyone's really interested). The same article can be found at http://www.siconic.com/files/appllock --- A Better Way to Protect Your AppleSoft BASIC Programs with AppleLock by Sam Ismail January 5, 1997 :Introduction: I devised this method of protecting AppleSoft BASIC program listings some years back during my prime Apple programming days. It involves a combination of several different techniques for keeping your program unlistable by the casual to intermediate user. This system is no match for advanced users who understand the internal structure of BASIC, for they could no doubt blast through this protection with little difficulty. Hence, this program is suitable for protecting programs which you wish to keep hidden from users who are less than expert Apple ][ hackers. The following is a technical explanation of the AppleLock protection scheme. If you don't care to read it, you may want to skip to the end of this document to get the source code to the AppleLock program. This discussion will not stop to explain in detail the advanced AppleSoft BASIC and machine language techniques that are employed in this scheme as there are plenty of FAQs around to explain the finer details of the tricks involved. :AppleSoft BASIC Internal Program Storage: AppleSoft BASIC stores your program in memory by tokenizing the keywords in your program into one byte values. So for instance, when you type the follwing line: 10 PRINT "HELLO WORLD!" the BASIC interpreter converts this into the following bunch of numbers in memory (shown in hexadecimal): 15 08 Pointer to program data for next line 0A 00 Line number (in this case, 10) BA The token for PRINT 22 The opening quotation mark 48 45 4C 4C 4F 20 57 4F 52 4C 44 21 The string HELLO WORLD! 22 The closing quotation mark 00 The end of line terminator If this was the first line of the program, it would be stored starting at memory location $0801 (or decimal 2049). As shown above in the first line of bytes, the next program line data would be stored at memory location $0815 (addresses are usually stored backwards in memory, which is the way the 6502 CPU reads addresses, so in this case 15 08 is $0815). :Some Simple Protection Schemes: One of the simplest and most widely known tricks for protecting your program is to POKE a 1 at memory location $0801 (POKE 2049,1). This will trick AppleSoft into thinking that the next line of the program is at $0801 instead of $0815. This will have the effect of listing the first line of your program over and over again, indefinitely, until the user presses Control-C to stop the display. Unfortunately, this trick is not permanent. If you SAVE your program in this condition and then LOAD it into memory again, AppleSoft will "fix" the pointer and make it point to the next line again. So this trick only keeps your program secret as long as the user always runs your program before doing anything else with it (ie. LISTing it) and as long as you perform this POKE as the first command inside your program. Not a very secure method. Another well known trick for keeping your programs secret is to set a flag in AppleSoft which has the effect of ignoring all AppleSoft BASIC commands at the command line and running your program instead, regardless of what the user types (with the exception of DOS commands which ignore the RUN-only flag and execute regardless of its status). This flag is turned on by POKE-ing any value greater than 127 at memory location 214 (eg. POKE 214,255). The flag is turned off by poking any value less than 128 at the same location (eg. POKE 214,0). Again, this method is not effective because your program, or some other program that runs before your program, must set this flag before the user has a chance to list your program. Otherwise, the user could simply load and list your program before it has a chance to set this flag. So what are we to do? Well, unfortunately our options are limited and ineffective unless we know some machine language and a little bit about the AppleSoft BASIC architecture. That's where AppleLock comes in. :Technical Overview of AppleLock: The key to this scheme is adding a special line to the beginning of your program which acts as a gateway to your program listing. This first line will block the rest of your program from being viewed. It seems benign enough to the naked eye. Yet it is performing some special magic to enable your program to run normally and be copied to another disk, but never listed. This scheme uses a machine language subroutine to change the pointers of your program to where your program really is. This machine code is stored right inside the first line, but it is hidden from the user by taking advantage of some features of AppleSoft BASIC. AppleSoft allows you to embed control characters in your program listings, for instance, in REM statements. When your program is LISTed, these control characters are interpreted and output to the display just like in any other circumstance. For instance, if you stuff a Control-H (or backspace) character in a REM statement, it will be interpreted as a backspace when the line is listed, and the character previous will be over-written by the character following the backspace. There are several programs available to allow you to create fancy listings by embedding backspace characters into your REM statements in this manner. The following will demonstrate the effect an embedded backspace will have when your program is listed: LIST 10 REM A CHARACER WILL BE MISSING ^ The backspace occurred here. The 'T' was printed, but it was followed by a backspace character, so the 'E' over- wrote the 'T'. Going back to our protection scheme, we must be able to CALL our machine language subroutine which unlocks the rest of the program, but we don't want the user to know what we are doing to unlock the program. So to hide the CALL command, we follow it with a REM statement with enough backspace characters to over-write the CALL command. As a side benefit, we can now put whatever message we want as the first line of the program, such as "THIS PROGRAM CANNOT BE LISTED". Or, we can get real tricky by displaying what looks like a program line, but in actuality is some dummy text which is hiding the real program line underneath, such as "10 END " (we must put sufficient spaces to over-write both the CALL and REM commands). To illustrate this more effectively, the following is an example of a raw line before we embed the backspace characters: 10 CALL 2100: REM *******************[ CAN'T LIST THIS! ] Now we would replace all the asteriks with a backspace character (ASCII 8). The easiest way to do this is from the monitor. In this case, we would find the first asterik at memory location $080C. We could then replace the asteriks with backspace characters by doing the following: CALL -151 80C: 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 This now changes the 19 asteriks into backspace characters. Nineteen backspace characters is enough to backspace all the way back to the line number at the beginning of the line. If our line number was 1, we would only need 18 backspaces. If our line number was 100, we would need 20 backspaces. If we had other commands after the CALL command, we would need enough backspace characters to backspace over these commands as well, including the formatting spaces AppleSoft prints when it displays your program listing. We have now completed the first step. We have created a line that when listed will only show our message. Now we must create some room for our machine language code which unlocks the program when it is CALLed by the hidden command. To do this, we will add extra asteriks after our message so that we can replace these asteriks with machine code and have the code stored right inside the BASIC program. We must store the code right inside the BASIC program so that it automatically gets loaded when we load our program. Otherwise, if the code was stored in a separate file, the user would be able to stop the program before it had a chance to unlock itself. This would enable the user to possibly figure out what was going on, and we don't want that. In order to do all this, we must hide our machine code from BASIC. Otherwise, BASIC will try to interpret our machine code as BASIC tokens when we list our program and will throw garbage all over the screen. First, let's create the program line we will need to hide our CALL command as well as reserve enough bytes to store our machine language unlock code. We will also add another program line for demonstration purposes later in the tutorial. 10 CALL 2100: REM *******************[ CAN'T LIST THIS! ]********* 20 PRINT "HELLO WORLD!" We have added some asteriks after our message to create the space we will use to store our machine code. There are two extra bytes that will be used to hide this machine code from BASIC as well as to fool BASIC into thinking our program is shorter than it really is, thus hiding the rest of the program. We must now jump back into the monitor to embed our backspace characters and then insert our machine code: CALL -151 80C: 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 Embedded backspaces 834: A9 3D 85 67 4C 65 d5 Our machine language code The machine language code disassembles to the following instructions: 834: A9 3D LDA #$3D ; Get the true start of our program 836: 85 67 STA $67 ; and tell AppleSoft where it really is 838: 4C 65 D5 JMP $D565 ; Now run the real program Basically, this code tells BASIC to jump over our first decoy line and then start running our real program. As you may have guessed, the CALL command that is at the beginning of our decoy line calls this code. Of course, the user doesn't see this CALL command because it is over-written by our message. Now we must hide our machine code from BASIC, or else when we list our program we will see a bunch of garbage. The machine code actually started at the second asterik after our message. We will replace the first asterik with a zero byte. A zero byte indicates to BASIC that it has reached the end of the program line, and should go on to list the next line. When we input a line, BASIC always puts a zero byte at the end of our line before starting a new line. So after the last asterik in our line is a zero byte. But we will also replace the last asterik in our line with another zero byte, resulting in two consecutive zero bytes. Two consecutive zero bytes tells BASIC that it has reached the end of the program, and it should stop listing. We are now going to change the internal pointers of our decoy line to point to these zero bytes so that we can fool BASIC into thinking our program is only one line long! 833: 0 Replace the first asterik with a 0 byte 83B: 0 Replace the last asterik with a 0 byte ($083C has another zero byte already) 801: 3B Change the internal pointer to point to the two zero bytes, fooling BASIC into thinking it has reached the end of the program Now when we list our program, we will see the follwing: [ CAN'T LIST THIS! ] But when we run it, we will see the following: HELLO WORLD! Cool, eh? Now, before we end our program, we must make sure we lock it back up so that we don't defeat our protection scheme by leaving the door open. You can add this line to your program to have it change the pointer to the start of our program back to our decoy line: 30 POKE 103,1 Now this program will run and then re-lock itself when it's done. And now hopefully you understand the basic premise of AppleLock. :Additional Security Requirements: As the programmer, you must also take several steps within your program to ensure nobody can break out of it by hitting Control-C. And we also have to contend with that darn reset button. First though, let's take care of Control-C. To prevent the user from trying to break out of the program and at the same time trap any unexpected errors in your program, make sure the FIRST line of your program is an ONERR GOTO command. ONERR GOTO allows you to tell BASIC to jump to any line in your program whenever an error occurs, and Control-C is considered an error (its error code is 255). The simplest way to handle errors and Control-C attempts is with the following lines: 10 ONERR GOTO 63999 <your program> 63999 RESUME These lines will in effect cause the program to ignore any errors, including attempts to break out of the program by the user. There is still a very minor chance that the user could time a quick Control-C right when the machine language unlock program transfers control to your unlocked program, but before you issue the ONERR GOTO command or possibly set the AppleSoft RUN-only flag (POKE 214,255), thus allowing the user to break into your program. The AppleLock program at the end of this tutorial addresses this problem. Now let's take care of the reset button. The simplest way to prevent a person from using RESET to gain access to your program is by adding a simple POKE command at the beginning of your program, as follows: POKE 1010,0 This will cause the computer to re-boot whenever the reset button is pressed. We could get fancy and re-hook the reset vector so that when the user presses RESET we can restore our program lock and then return them to BASIC. This is exactly what the AppleLock program at the end of this tutorial does. Before your program terminates and returns to the command prompt, it must undo the RUN-only flag (if you have set it) and then re-lock your program. The following program line should be the last thing your program does before it exits: 63999 POKE 103,1:POKE 214,0 The first POKE re-locks your program. The second POKE turns off the AppleSoft RUN-only flag. You should also return the reset vector to its original setting if you have modified it. Otherwise, the next time the user presses RESET, your program will run again. If another program was loaded and then RESET was pressed, the system will most assuredly crash. AppleLock includes a routine which you can call at the end of your program which will restore the reset vector as well as the AppleSoft RUN-only flag and then re-lock your program before exiting. :AppleLock Effectiveness Analysis: Unfortunately, the weakest point of this scheme is that it takes only one well-placed POKE to unlock your program. As an aside, the user can find out what you are trying to hide by changing the character output speed with a SPEED= command. For instance, by setting SPEED=0, and then LIST-ing the program, the user would be able to see that there is a CALL command hidden behind your message. The best and most secure way to protect your program from prying eyes remains the use of a BASIC compiler. However, this is not always a feasible solution. There are a few compilers for DOS 3.3 that will convert your program to machine language. And there is the Beagle Compiler for ProDOS, but this compiler does not create a stand-alone machine language program, but rather requires an interpreter that replaces BASIC.SYSTEM. :Conclusion: Hopefully this tutorial has given you enough information to help you protect your AppleSoft BASIC programs for whatever reason you may have. Enjoy. :The AppleLock Program: This program is very rudimentary and not very pretty. A nice interface can be built around this program to make it more user friendly. The important thing is that it is functional. What it does is creates the machine language unlock code by POKE-ing it into memory. It then asks you to enter the name of the program you wish to lock, as well as the line number you wish to use as your decoy line. This must be the first line in your program! After that, it allows you to enter a message up to 160 characters in length (the length of the message is fairly arbitrary, but this length was chosen to keep the program simple). Once you get good at this technique, you will want to use other programs to create your message (or perhaps use the monitor like I do) so that you can have fancy banners show up when you try to list the program. It then builds a text file with all the commands necessary to apply AppleLock to your program. This file will then be EXEC-ed so that the AppleLock procedure will be performed automatically. Once the process is complete, your program will be loaded in memory and in a locked state (if you try to LIST it you will only get the message you typed in). At this point, you should SAVE your program to disk to make the process permanent. The program will give you instructions on how to lock/unlock your program so that you, as the author, can list and modify it as you please. Keep in mind that you must unlock your program before you make any changes to it, otherwise you stand the chance of royally screwing your program and possibly crashing your machine. Weird things can happen when you start to mess with AppleSoft program pointers. If this happens, simply reboot your computer and re-load your program, and all will be well again. If you ever want to remove AppleLock from your program, simply unlock it and then save it to your disk (be sure to restore the BASIC start-of-program marker with a POKE 103,1 after you are done saving). When you load your program again, it will be back to normal. The AppleLock program includes an enhanced locking mechanism which will modify the reset vector and also sets the AppleSoft RUN-only flag by POKE-ing a 255 at location 214 before it transfers control to your program. This will prevent users from listing your program should it fail and drop to the command prompt at some point, or the user presses Control-C and you haven't added an ONERR GOTO command to your program. If the reset button is pressed, the locking mechanism will re-lock the program, reset the AppleSoft RUN-only flag, restore the reset vector to its original value and then return to the command prompt. :Disclaimer: This program may be freely modified, distributed, sauteed, fricasseed, lambasted, spindled, mutilated, desecrated, tormented and forced to cry "uncle". It may not, however, be recruited into sado-masochistic rituals unless it has consented to participate in such activities. Niether myself, my immediate family, nor the code (it's just code, it doesn't know any better) can be held responsible for any havoc it wreaks on your AppleSoft programs. This program has been run and tested several times and has been deemed sound by the author. If you do somehow get yourself in a bind, I can be reached via email (dastar(a)siconic.com) and I will try to help you reclaim your lost code. On that note, I leave you with these words to live by: Always Keep a Backup! ------- cut here -------

24 years, 7 months

Software rental, "trusted computing", etc. (was Re: Is this for real -- a new C64/128)

by xds_sigma7＠hotmail.com

Umm well to put it mildly, Ellison is a freaking weirdo... speaking of which, has the PC been replaced yet, Mr. Ellison? Will J ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

24 years, 7 months

Cool AppleSoft BASIC trick I never thought of before

by ethan_dicks＠yahoo.com

--- Vintage Computer GAWD! <foo(a)siconic.com> wrote: > > Stop me if you've heard this one before... STOP! :-) > On the Apple ][, in AppleSoft BASIC, you can set what the start address > of your BASIC program will be in memory by poking it into location 103-104 > ($68-$69 hex). There are similar locations for the same pointers in all versions of M$ BASIC for PETs, etc. > The default is 2049 ($801): 103=1 and 104=8 ($68=1, $69=8). Typical. The PET uses $0401, and the C-64 uses $0801 (because the display memory is at $0400 by default on a C-64) > QUESTION: Does anyone know why the default is $801 instead of $800? I > always wondered why that was. Anyway... I'm not sure of the exact reason, but for PETBASIC, $0400 (or $0800) must contain a null byte. I suspect the same for AppleSoft. > It occured to me tonight as I was writing just such an application--the > Nerd Trivia Challenge management program for the VCF, which loads a > hi-resolution character generator at $1600, which would over-run my BASIC > code, which is therefore relocated to $4001--that two or more BASIC > programs could reside in memory at the same time! One would simply POKE > the beginning address into 103-104 and then LOAD the new program, and > repeat this for as many programs as is possible with the memory available. There was a machine language program for the PET called "QuadraPET" published way back when (I have a copy on a 1541-disk-image file), that moved all the BASIC pointers around in zero page to create four 8K virtual PETs on a 32K PET. The author suggested that in a family setting, each user could have their own space and not clobber other people's work. I'm sure it would be trivial to adapt to AppleSoft, presuming there's around 100 bytes of protected memory to stuff it into - the trick on the PET was to use the second cassette buffer since so few users ever had two cassette drives. It was a great learning experience to have to fit useful programs into 192 bytes. > The only problem here of course is that any variables in either program > will be quashed when the alternate program is run. However, there are > also pointers that point to the beginning of variable memory, and I'm sure > there would be a way to preserve these pointers so that individual > variables for either program stay intact between transitions. Something > worth exploring just for the hack value. cf. QuadraPET; I can send you a copy if you'd like to disassemble it. ISTR it was published in COMPUTE! if you have a collection of them from the 1978- 1981 timeframe. I'm fairly sure that the source is printed in the magazine. OTOH, I am not familiar with this sort of trick being done for AppleSoft, probably because back in those days, people moved to M/L for the Apple very early on because of the demands for speed on graphical programs. -ethan ===== Even though my old e-mail address is no longer going to vanish, please note my new public address: erd(a)iname.com The original webpage address is still going away. The permanent home is: http://penguincentral.com/ See http://ohio.voyager.net/ for details. __________________________________________________ Do You Yahoo!? Send instant messages & get email alerts with Yahoo! Messenger. http://im.yahoo.com/

24 years, 7 months

Cool AppleSoft BASIC trick I never thought of before

by foo＠siconic.com

Stop me if you've heard this one before... On the Apple ][, in AppleSoft BASIC, you can set what the start address of your BASIC program will be in memory by poking it into location 103-104 ($68-$69 hex). The default is 2049 ($801): 103=1 and 104=8 ($68=1, $69=8). QUESTION: Does anyone know why the default is $801 instead of $800? I always wondered why that was. Anyway... For various pratical reasons, usually to avoid over-running the beginning of the first hi-res graphics page which began in memory at 8192 ($2000) with variable data (which was always stored just after the end of the BASIC program in memory), sometimes people would force their programs to load at 16384 ($4000, which is also the beginning of the second hi-res graphics page) or 24576 ($6000), or where ever. It occured to me tonight as I was writing just such an application--the Nerd Trivia Challenge management program for the VCF, which loads a hi-resolution character generator at $1600, which would over-run my BASIC code, which is therefore relocated to $4001--that two or more BASIC programs could reside in memory at the same time! One would simply POKE the beginning address into 103-104 and then LOAD the new program, and repeat this for as many programs as is possible with the memory available. As an experiment, I wrote two simple programs: one at $801 that simply prints "PROGRAM 1!" and then sets the start of the program to $4001 by POKEing a 64 into 104 then issues a RUN command, and another at $4001 that simply prints "PROGRAM 2!" and then sets the start of the program to $801 by POKEing an 8 into 104 and issues a RUN. I run either of the programs and I get an endlessly alternating display of "PROGRAM 1!" and "PROGRAM 2!". In other words, it works! Cool. The only problem here of course is that any variables in either program will be quashed when the alternate program is run. However, there are also pointers that point to the beginning of variable memory, and I'm sure there would be a way to preserve these pointers so that individual variables for either program stay intact between transitions. Something worth exploring just for the hack value. I never actually saw this in practice in all my years of Apple ][ hacking, and believe me I snooped through a lot of code. Has anyone ever seen this, and if so, for what purpose? I just thought of one example, which was a Beagle Brothers product that let you have two programs in each 64K bank of memory on a 128K Apple ][. It seems to me this could be mutated into a sort of practical method of multi-tasking BASIC programs. Comments? Sellam

24 years, 7 months

SDS parts.. info please

by xds_sigma7＠hotmail.com

OK, Yesterday at the scrap yard, I found a whole lot of 60's/70's Burroughs, Honeywell, NCR, and Univac boards... I'm definetly going to get the Honeywell boards since they're from a 316 or 516 (approx. 50+ boards), but I was wondering if anyone had info on what the SDS boards came out of? And no, I'm not asking who SDS was or something like that, I mean if I was to get the boards does anyone have the necessary info to tell what machine they were used in. The boards are copyrighted 1965 and 1966, so I was thinking maybe they were from a 940? They're not very big boards, something like 4 inches by 3 inches, approx of course. Bigger than H316 boards, which isn't saying much, heh. I'm not planning on getting any of the NCR or Burroughs stuff, but I am going to write down all the part numbers, maybe get the remants of the one NCR core stack I found, since its already ruined and then I could have a nice open one to display... dated 1967. Will J ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

24 years, 7 months

Sperry Univac Minicomputer

by xds_sigma7＠hotmail.com

5 feet tall is way too big for a Varian.. the V70 series are early 70's to at least mid 80's machines, only maybe a foot tall (the CPU is what I am speaking of, naturally). I know Univac kept making the V70's until at least 1984; they had to, due to their contract with the company my dad worked for at the time, Auto-trol Technology. They integrated V70's (and 620 series machines before that) into their CAD systems, and in some of the old stock prospectuses(prospecti?) we have at home, it says that Sperry Univac had to give Auto-Trol a minimum of 6 months notice before stopping production of the V70 series. FWIW, was essentially Apollo Computer's first customer, and Apollo's eventually became the basis for Auto-Trol's CAD systems. Will J ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

24 years, 7 months

IBEX info? (fwd)

by vcf＠siconic.com

Can anyone help this dude? ---------- Forwarded message ---------- Date: Tue, 16 May 2000 10:59:23 -0500 From: Beau Reichert <tcr1(a)bga.com> To: vcf(a)vintage.org Subject: IBEX info? Do you know where I could get info on a IBEX computer. Thanks Beau Sellam International Man of Intrigue and Danger ------------------------------------------------------------------------------- Looking for a six in a pile of nines... Coming soon: VCF 4.0! VCF East: Planning in Progress See http://www.vintage.org for details!

24 years, 7 months

← Newer
1
...
24
25
26
27
28
29
30
...
55
Older →

Jump to page:

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 May 2000