test-drb April 1999

test-drb@ccmp.vtda.org

170 participants
1190 discussions

stepping machanism of Apple Disk ][ drive (was Re: Heatkit 51/4 floppies)

by edick＠idcomm.com

You're certain right . . . it is a dead horse . . . killed by the insistence that 750 ns < 250 ns. Dick -----Original Message----- From: allisonp(a)world.std.com <allisonp(a)world.std.com> To: Discussion re-collecting of classic computers <classiccmp(a)u.washington.edu> Date: Monday, April 12, 1999 7:59 AM Subject: Re: stepping machanism of Apple Disk ][ drive (was Re: Heatkit 51/4 floppies) >> I didn't want to descend into the gate-level details of the CPU, but merely >> to count clocks for comparison's sake. > >Since the clocks are applied in such a different fashion the comparison is >meaningless. > >> clock ticks to access memory while a 6502 took only one. As I've said in >> previous posts, the comparison at the memory bandwidth level came out in > >Meaningless unless that is a particular requirement of an application >HARDWARE. > >> the fastest commercially available Z-80 with the fastest commercially >> available 6502, the 6502 will win by a wide margin EVERY time. Compare the >> Z80H (1983 or so) with the Synertek SYC6502C (1979) and you'll see that >> 8 MHz Z-80 can't be counted on to win the race. If you like, you can > >Your dreaming again. Seriously weve beat the dead horse and it's time to >quit. The 6502 is a good cpu but the comparisons are getting silly. > >If you really want to compare archectecture I'll take the T-11 (PDP-11 on >a 40 pin dip) @7.5mHZ and blow the both out of the water. here a part >from The same era that has all the addressing modes of the 68k and then >some and can use memory like the 6502 or z80 with its registers. Things >like position independent code, relative addressing and two address >structure are all there. the problem is the arguement is specious as I >can also use the CMOS PDP-8 part to put up as good a battle of who wins. >And getting a PDP-8 into a FPGA has been done as well. > >> compare the 8 MHz Z-80H with the Rockwell 65C102, which takes a 4x clock. >> Now it takes 4 clock ticks at 16 MHz to execute a bus cycle of any type. >> Feed it an 8 MHz clock, it will still outdistance the Z-80H. > >YEs and the z180S part takes a 33mhz clock, whats the point? CLOCKS and >counting them is meaningless unless they mean something comparable. > >> I remember what it was like trying to get delivery on 2147's back in >'81. I > >There were peole sellign 4kx1 22pinparts at near firesale prices compared >to 2147 and were near 65ns. They were of the pseudo static three voltage >generation but the y were cheap. > >> machines of the early '80's. That might be worth a look. What I want is a > >Smallc had limited optimization. I've used it for other cpus and it's fat. >I would ahve guessed that was ported to near everything but it's not a >production compiler though I guess it could be used as one. > >> I recently bought a couple of single board dedicated boards, and found that >> they had the 4 MHz Rockwell CMOS parts on them. I didn't think I'd ever see >> something like that in the scrap box. Oh well, once I've figured out the >> memory map, they'll be useful for 1-of's. > >I have 4 or 5 board from telvideo 905/955 terminals and they have 65C02s >from rockwell on them. I also have a trackstar 128 (APPLE II for PC) that >has two 65C02s. > > >Allison > > > >> >> >Allison >> > >> >

25 years, 9 months

Old Nicolet boxes...

by jfoust＠threedee.com

In penance to Sam for opening the floodgates to the previously secret VCF travel fund, I reveal a link to someone at Nicolet who seems willing to talk about their line of computers. - John >From: Mike Lennon <lennon(a)nicolet.com> >To: "'John Foust'" <jfoust(a)threedee.com> >Date: Mon, 12 Apr 1999 08:34:19 -0500 >Subject: RE: Old Nicolet boxes... > >I did a fair amount of engineering on the 1280 and it's operating >system. Feel free to contact me with any questions you may have. > >Mike Lennon

25 years, 9 months

More Pick info (was Prime 2250)

by jlwest＠tseinc.com

Prime Infomation was certainly a pick variant - I spent a lot of time (about 7 years) on Prime's and Prime Information at AB. When pick first came out, is was what we called "vanilla" which meant that the machine booted pick - there was no other operating system. Later other manufacturers (licensees of pick systems) decided to strip out the monitor and missionary/native code architecture, and gut everything that was OSlike rather than RDBMSlike. They then put the remnants on top of some other operating system (layered rather than vanilla). Unix was common, as was DOS, Windows, PRIMOS, etc. To answer someone elses question, BASIC was the programming language (you had no choice). There was also PROC which was not that much more than batch files in DOS. Then there was the assembler. The assembler verb definition was removed from many later versions but you could define a pointer into the ABS area to call it up. BASIC was compiled into DCD or Pcode, and the result was run interpretively. The DCD/Pcode was rather elegant - it implemented a stack architecture to speed code generation and execution in RPN. At the end of each BASIC statements resulting code the state machine was completely back to its initial value. In a certain sense, each basic statement resulted in a separate DCD/Pcode subroutine that was reentrant as the symbol table and variable allocations were made out of the users workspace. All the Pick variations handle file I/O the same - I've never seen any programming language even close to pick basic in the elegance of the file/record interface. The assembler was virtual, in that the instruction set really didn't exist on any machine. So - assembly was a 3 pass process. First, the Pick assembler turned your assembler file into "virtual machine code". Then a BASIC program turned the virtual machine code into an assembler program in the native assembly language of the cpu it was running on. Finally the native assembler was run to generate executable object code. Somewhere I still have some listings where you can see the same program turn into 68000 assembler and then compile on a different machine and see each instruction turn into 8080 assembler. Nifty AND educational :) I forget if prime information was created by ex Vmark engineers, or if Universe was created by ex Prime engineers - one way or the other ;) I have to admit, next to freeBSD, Primos is a really nice OS IMHO. ISTR that the baud rates for the AMLC lines (serial cards) were controlled via the AMLC.COMI file, located on the system volume ( <SYSTEM>AMLC.COMI or <MFD 0>AMLC.COMI). This was a command input file which set the line characteristics. Can't recall if the console speed was set there, but the other serial lines were. I have a complete Primos and Prime Information manual set at the office. I'll check how to set the console speed for you. If you have no docs and are playing with the primos machine, just remember, it's "A " rather than "cd ", and "ED" rather than "vi" <grin> oh - emacs was VERY common on primos, so that might be there as well for you to use. One final note - I do NOT want to represent that I wrote the Pick operating system, or that I was on the original development team. Dick Pick and Chandru Murthi would just scream if I said I was. Pick was developed in the late 60's by those two under a government project for maintaining the data on a helicopter project. The original name (according to the US Government) for the Pick OS was G.I.R.L.S. (Generalized Information Retrieval Language). No Kidding. So - I didn't invent it, I was merely a freelance consultant who worked on modifications and enhancements to the virtual code and monitor code in the Pick OS for some of the pick licensees. Cheers! Jay West -----Original Message----- From: John Lawson <jpl15(a)netcom.com> To: Discussion re-collecting of classic computers <classiccmp(a)u.washington.edu> Date: Sunday, April 11, 1999 7:43 PM Subject: PR1ME 2550 Up and Running > > > Well... it didn't hurt as much as I thought it was going to.. > >I have just run "SHUTDN ALL" after two hours of playing with PRIMOS >(on a DEC LA120 running at 300 baud... s-l-o-w...). > > I rescued this system about two months ago, and finally got tired >of it taking up space. It took about an hour to figure out where all >the cables used to go, and the Control Data SMD drive [used as a >paging and swapping drive] needed a little prodding to wake it up, >but the system boots and remembers what it was doing last time it was >on... about six years ago. > > Now to try and make the console port run at a decent speed. > > And, apropos of the Pick discussions, this machine has INFORMATION >loaded and running... haven't messed with it yet, tho.. > > > Cheers > >John > >

25 years, 9 months

stepping machanism of Apple Disk ][ drive (was Re: Heatkit 51/4 floppies)

by edick＠idcomm.com

please have a look at my emmbedded comments below. Dick -----Original Message----- From: Allison J Parent <allisonp(a)world.std.com> To: Discussion re-collecting of classic computers <classiccmp(a)u.washington.edu> Date: Sunday, April 11, 1999 9:22 PM Subject: Re: stepping machanism of Apple Disk ][ drive (was Re: Heatkit 51/4 floppies) ><Well, Allison, you're going to force me to venture into the archives and ><fetch the data sheet. > >Since I use z80s and kin often the data sheets for the z80 (all dozen or so) >starting with the 1977 ones are at hand. It helps that in my history is >applications engineering time at NEC microcomputers (they sold the uPD780 >a z80). > ><4mhz (shorter for M1 cycle)" is ABSOLUTELY correct. However, it took thre ><clock ticks in order to generate that cycle. IIRC, the entire M1 (opcode ><fetch + refresh) cycle took 4 or 5 (?) clock ticks, which made it the ><longest cycle. Memory cycles other than opcode fetches took 3 ticks and I ><believe I/O cycles took 4. So I remembered these correctly? After all those years? Amazing . . . >Don't ignore the fact that there are such thing as propagation delays >internal to the chip in the 50-80nS range or that some edges chaged on >the rising edge and some on the falling ones. I didn't want to descend into the gate-level details of the CPU, but merely to count clocks for comparison's sake. ><The theory was that one execute a bunch of memory cycles to load up the ><internal registers of the Z-80, of which there are plenty, and then execut ><scads of register-register instructions which are faster, in order to ><accomplish a given computational task. It didn't easily work out that way ><a notion which wasn't lost on the designers of the 6502. > >There are many schools of thought. the PDP-8 is and the 6502 have the >sparse hardware idea in common. the z80 is really a CISC machine and >reflects the more complex instruction set and the 8080 history. > >< ><The MOS-Technology people who first implemented the 6502 architecture, ><recognized that although the Z-80 had plenty of registers, it still wasn't ><enough, so they shortened the memory access cycles. In fact, they used a > >I don't feel that is a right way to say it. I'd go with... The mos >technology people with a limited silicone real estate (silicon costs alot >then) fewer register and a instruction set biased to use memory more. >That heritage comes from the 6800 which is a more similar part. > ><done, and they opted for an 8-bit stack pointer, which gave them the ability ><to execute stack-oriented operations faster than the Z-80 and its kin could > >they werent! Not significantly. in most cases the time to actually execute >isn't that much different. Well . . . I'd say it is significant, in view of the fact a Z-80 took three clock ticks to access memory while a 6502 took only one. As I've said in previous posts, the comparison at the memory bandwidth level came out in favor of the Z-80 because it had a BETTER BASIC interpreter. If you compare the fastest commercially available Z-80 with the fastest commercially available 6502, the 6502 will win by a wide margin EVERY time. Compare the Z80H (1983 or so) with the Synertek SYC6502C (1979) and you'll see that the 8 MHz Z-80 can't be counted on to win the race. If you like, you can compare the 8 MHz Z-80H with the Rockwell 65C102, which takes a 4x clock. Now it takes 4 clock ticks at 16 MHz to execute a bus cycle of any type. Feed it an 8 MHz clock, it will still outdistance the Z-80H. ><do so. It could look at its zero-page as extra-fast memory, or slow ><register space. In any case, a stack operation took one clock tick + one ><clock tick per byte. A zero page operation, depending on the operation in ><question, took one clock tick less time than that same instruction operatin ><on any of the rest of memory. A load or store took two cycles, and an ><indexed load or store took three. > >The idea of zero page was straight from PDP-8 too. The zero page was a way >to solve the problem of too few registers. The TI9900 took an entirely >different path to solve that problem. > >Which problem? Silicon real estate. registers are memory and that memory >eats silicon. back in that time frame you had some hard choices a with >regard to that. The Z80 was somewhat remarkable as there were 208 bits of >storage inside the processor for just user programable registers and bits. > ><Today, we're equipped with cheap VERY fast large, SRAMs which would make i ><much easire to make a solid and objective test of the two processors. ><Unfortunately, there's little reason to do so, since neither is of any ><commercial interest. > >In 1979 I had several tubes of 85nS 4kx1 rams that made a dandy memory. >They were static. I still have some of them. then in 1980 I got some slow >static 16kx1s that were only 70nS (2167) and built a z80 system that pushed >a 6mhz part to 7mhz. fast rams were available. I remember what it was like trying to get delivery on 2147's back in '81. I did manage to get the 55 ns parts for my 6502 based system. The bottom 16K allowed the processor to run a 4 MHz, while the rest caused it to slow to 1 MHz. Since the assembler lived in the bottom 8K, and the editor we used right above it, the combination was pretty fast. I eventually filled the whole lower 48K with the fast SRAMS, as we had a card designed for the TMS4044, which was a slow 2147. >My NSbox had 2116s that were 300ns and only 32 filled the memory space >on one board. that was 1981. > ><Have YOU seen a 'C' compiler for any of the 6502 types? > >Never. There could have been one but I'd wonder about code efficientcy. >Then again I've never seen one for 9900 bit that as CISC a machine if >there ever was one. Someone posted a small-c compiler for the 6502 as implemented in popular machines of the early '80's. That might be worth a look. What I want is a cross-compiler with a version for the PC as the target and one for the 6502. That way I can debug on the PC and transfer my code to the 6502. (Mitsubishi microcontrollers, actually) I recently bought a couple of single board dedicated boards, and found that they had the 4 MHz Rockwell CMOS parts on them. I didn't think I'd ever see something like that in the scrap box. Oh well, once I've figured out the memory map, they'll be useful for 1-of's. >Allison >

25 years, 9 months

Several things

by Philip.Belben＠pgen.com

It has taken me a whole week to catch up with Classiccmp. So this is on oldish threads, I'm afraid... Tim Shoppa wrote (starting with a quotation from I don't know whom): >>C= PET VisiCalc EPROM >>--------------------- >>The Commodore PET version of the VisiCalc spreadsheet came with a chip that >>plugged into a socket on the main board. This was probably an EPROM, used for >>copy-protection. I have an original VisiCalc package, minus this EPROM. Does >>anyone know where I can download an image of the EPROM from? > > I'd be interested to know exactly what this chip did. It was never > perfectly clear to me that it was used for copy-protection. I was always under the impression that the ROM that came with Visicalc contained most of the code. I never used VZCalc on a PET (I had an old ROM PET, not compatible and no expansion sockets, and in those days no knowledge to change matters), but could the ROM have contained the code common to all modules? The argument on microcode and that which it spawned on ABS are a bit old, but since the subject line says "Several things" I may as well put in my bit. MICROCODE, Compilers, Assemblers. ================================= Microcode compilation is a good example of differences between humans and computers. Humans have (one hopes, if they are working at it at all) a BETTER UNDERSTANDING of the job (in one sense, computers have no understanding at all). Computers are FASTER and LESS PRONE TO MISTAKES [1]. In something like microcode compilation/optimisation, it is often a requirement to get the best possible result. If your processor knocks one clock cycle off an addition, because you spotted a shortcut in the microcode that your competitors' compiler/assembler didn't, you will have a faster processor. Probably significantly faster. But you can't claim that humans will always exhibit better PRODUCTIVITY (sorry William B, otherwise I agree with you) because doing it by hand is usually _far_ slower. The distinction between a compiler and an assembler is irrelevant here. As usual, there is a continuous spectrum of techniques and things like Hex monitors, assemblers, macro assemblers, compilers are names given to parts of the spectrum. No matter how you define them there will always be examples that are hard to place in one category or another. I think the point is: the more the computer does for you, the easier and faster it is to get a good result, but the more hassle it is to get the best result... Spc said "There's no such thing as compiled code - everything is interpreted" Definitely everything is interpreted. But unless the code fed to the interpreter, be it software, microcode or hardware, is what was written, it's compiled as well. Tony said, on processor design, you can either have one flip-flop to each machine state (like a P850) or microcode. Again there are intermediate points. I claim you can do quite well by numbering the machine states in a suitably chosen binary code and having one flip-flop to each bit. Logic for changing flip-flops is often _easier_ than when you have one flip-flop per state. (I have done both designs for the same circuit BTW). If you put this logic into a ROM, this becomes in a sense a microcode ROM, but you can do it combinatorially as well... [1] In principle anyway, computers will do what they've been told, rather than forget things. Microsoft have managed to write a suite of programs that do make random silly mistakes just like humans, but even Microsoft software is more predictable in its mistakes than humans are. ABS. ==== To try and keep this on topic, how did Ferguson do ABS in the early 1970s? I don't believe they would have used a microprocessor. I'd guess at an analogue computer, probably not even electronic. Would this be less frightening to Tony? Theory of ABS. -------------- The consensus (and I agree) seems to be that a sliding tyre has less good grip than a rolling one. If when braking, you start to skid, take the foot off and re-apply. This will shorten your stoping distance. I once saw (via television) a demo carried out at a skid pan. Car 1 jammed on brakes and skidded a long way. Car 2, same speed, pumped the brakes quite slowly (less than 1 Hz) and stopped in 1/2 the distance. ABS, by pumping brakes, will stop you in a shorter distance than straight skidding. Now ABS pumps the brakes very fast. A further improvement can be achieved by slow pumping. Why? The car will bounce up and down like anything. If you pump at the resonant frequency of the suspension, you can arrange always to brake when it is down. This gives you extra pressure and extra grip, so you can stop sooner. This is what I understand by the phrase "cadence braking". But as several people have pointed out, the BIG advantage of ABS is extra control. Practice of ABS. ---------------- I will admit that I used to think as Tony does - ABS is undesirable because it fails in a nasty way. However, having driven cars with and without ABS, my opinion has changed. Please note that this is only an opinion. You are welcome to think differently. If you have skid training (I don't, but would like to one day), you perhaps ought to think differently. I don't know. 1. Emergency stop doesn't require pumping as a matter of course. In my 1972 Marcos it is very seldom that I skid and have to reapply brakes. 2. Therefore the technique in most situations is the same whether you have ABS or not: If you start skidding, pump. But not until. 3. As I said in the argument on earth leakage protection, a safety device is to get you out of trouble not into it. ABS is no excuse for driving too fast or too close. 4. There are situations in which ABS if it works can save you when no amount of braking technique from the driver without it can. Emergency stop on a corner springs to mind (see below). It is amazing how far a car goes between applications of the brake pedal. At 60mph, in one second you travel 88 feet. Pumping brakes quite fast, your skids will be 20 feet long. Pumping at a more humanly achievable rate, probably nearer 40 feet. This is quite far enough to leave the road and hit a tree. (Last month emergency stop on a corner sprang rather forcibly to more than just my mind. Car: dead. Diver: minor whiplash and bruising to joints of right leg. Without ABS I am still confident that, had I been able to go in a straight line, I would have stopped safely. With it, I wouldn't have hit the tree. With failed ABS I would be no worse off than I am now.) 5. I now believe that on balance, ABS does more good than harm. To me, that is. 6. But I refuse to have an airbag in my car! I don't like to carry explosives at the best of times, and an accident is hardly the best of times. (Seriously, airbags are generally inflated by an explosive that generates a lot of gas. Sometimes it goes off when you are not crashing. If the airbag has a pinhole leak, escaping gas can cause serious injuries (fortunately I wear glasses when driving)). Seat belts and crumple zones are quite sufficient when used properly. Well, I've got it off my chest too. But boy, has the traffic on the list been high this last week! Philip.

25 years, 9 months

PICK OS - I know it well...

by steverob＠hotoffice.com

> I had no idea there was pick interest here. If someone wants a small writeup > of the OS architecture and progression through history, I'd be happy to > resurrect those brain cells :) > This is a lot more on topic than many recent posts. Please enlighten us! Steve Robertson - <steverob(a)hotoffice.com>

25 years, 9 months

PR1ME 2550 Up and Running

by steverob＠hotoffice.com

> > Well... it didn't hurt as much as I thought it was going to.. > > I have just run "SHUTDN ALL" after two hours of playing with PRIMOS > (on a DEC LA120 running at 300 baud... s-l-o-w...). > > I rescued this system about two months ago, and finally got tired > of it taking up space. It took about an hour to figure out where all > the cables used to go, and the Control Data SMD drive [used as a > paging and swapping drive] needed a little prodding to wake it up, > but the system boots and remembers what it was doing last time it was > on... about six years ago. > > Now to try and make the console port run at a decent speed. > > And, apropos of the Pick discussions, this machine has INFORMATION > loaded and running... haven't messed with it yet, tho.. > > > Cheers > > John John, The 2550 is a neat little minicomputer. I have one but, it has a bad processor card so, I've never actually got it to boot. Sooner or later, I'll find a replacement card for it. IIRC, I was able to connect a dumb terminal to the console port at 2400 baud. I was able to talk to the diagnostics processor and run the startup sequence at this speed. There's probably a configuration setting for this but, I don't know what it is. I have a fairly complete set of DOCs for the machine (as a matter of fact, most of them are still in the shrink wrap). I'll be happy to share them if you are missing any volumes. If you have any specific questions, I'll try to look them up for you. The "2550 Operators Manual" will probably be the most useful at this point. It has the basic system operation and getting started guide. Do you have this DOC? Steve Robertson - <steverob(a)hotoffice.com>

25 years, 9 months

PCMCIA

by edick＠idcomm.com

There are a couple of newsgroups dedicated to PCMCIA which might be of some help. Take a look! Ask! Dick -----Original Message----- From: John Ruschmeyer <jruschme(a)exit109.com> To: Discussion re-collecting of classic computers <classiccmp(a)u.washington.edu> Date: Saturday, April 10, 1999 6:52 PM Subject: PCMCIA >Hi! > >This is possibly too new for this list, so please excuse me if I offend >anyone... > >I was wondering if any of you might have a copy of PCMICA drivers, such as >might have been shipped with a modem or other card? > >I'm in the process of resurrecting my NCR Safari, but the only drivers >that came with it are a simple memory card driver/formatter. > >Thanks... ><<<John>>>

25 years, 9 months

Victor 80286 (Lap-Top)

by vischer＠access.ch

I saw that one; anyone knows anything about it? Victor 80286 (Lap-Top) please mail me privately Thanks! Simon

25 years, 9 months

Fwd: H8 Enthusiasts

by cfandt＠netsync.net

Okay folks, I know a few of you have been looking for these items (Hans F.! Are you reading this now?) so have at it! :-) Seems to be just an H-10 manual, not the unit itself though :( Write Jeff directly of course, don't reply to me. -- Chris >Date: Sun, 11 Apr 1999 12:06:32 -0400 >Reply-To: Jeff Headlee <jeffhdle(a)HOME.COM> >Sender: Heathkit Owners and Collectors List <HEATH(a)LISTSERV.TEMPE.GOV> >From: Jeff Headlee <jeffhdle(a)HOME.COM> >Organization: @Home Network >Subject: H8 Enthusiasts >To: HEATH(a)LISTSERV.TEMPE.GOV > >Greetings, > >I have an H8 computer and a bunch of manuals I must clear out >to tidy up the basement. The H8 has an 8k memeory card in it >but the computer doesn't work. The power supply appears OK, >but the speaker screams a lot and the post is not successful. >Otherwise the unit is in good shape. The manuals are for the many >peripherals available for the H8: > > (2) H8 complete > H9 video terminal (assembly and operation) > H8-2 parallel I/O interface (assembly) > H8-5 serial I/O cassette card (assembly) > H10 paper tape reader/punch (assembly and operation) > 8k static memory card schematics > >Free to loving home if you pay postage or you can pick it up if you >live in the Baltimore MD area. > >Jeff > >--- --- --- --- --- --- --- --- --- --- --- --- --- -- >To subscribe: listserv(a)listserv.tempe.gov >and in body: subscribe HEATH yourfirstname yourlastname >To unsubscribe: listserv(a)listserv.tempe.gov >and in body: signoff HEATH >Archives for HEATH: http://www.tempe.gov/archives >--- --- --- --- --- --- --- --- --- --- --- --- --- -- Christian Fandt, Electronic/Electrical Historian Jamestown, NY USA cfandt(a)netsync.net Member of Antique Wireless Association URL: http://www.ggw.org/awa

25 years, 9 months

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 April 1999