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 allisonp＠world.std.com

<register assets, and simply look at what it takes to "do something" e.g. <load a value, do some arithmetic, store a value, etc. the two instruction <sets have considerable overlap. However, the longest instructions for the <6502 take six (?) clock ticks, while the shortest ones for the Z-80 take <four. (feel free to correct me, as I haven't even though about this, let this is correct. Consider the timing as the z80 was using cycles in groups of four (at 4mhz 1979). So a register moe or register to register add was typically 1uS. Likely the 6502 at the time was 1uS as well. Don't count clocks themselves the sysles were too different. Count the total time to execute. <know how long the longest instruction for the Z-80 takes nor do I even kno 21, LDIR (block move) and 23 (large group) of instructions that use indexing through the IX and IY registers most of which have no analog in 6502. for example SET b,(IX+D) (sets a bit at memory location.). The last one takes 5.75uS at 4mhz. What counts now is what would it take to do that using 6502. <what its longest instruction is. I'd imagine it's one in which you load <16-bit register from memory, indexed, or some such. That would have to tak <a fair number of clock ticks. load indexed is about 5uS. Lotas of clocks but they are used differently. <In my comparisons, I've always fudged in favor of the Z-80, because it <didn't make sense to me that a processor so cheap and simple would be as <much faster than a Z-80 as the 6502 appeared. The hardware problems aside the 6502 trades hardware complexity for some amount of speed and coves very close but at about half the number of longer clocks. <processor's instructions unless they are pushed. If you look at a simple <load-the-accumulator then store-the-result, which occurs often in almost an <application, the Z-80 takes about 6 ticks in the opcode fetch/decode (the <instruction is decoded during the refresh cycle), three for each byte of th <source address, then three to fetch the value. It then takes as long to <store the result to memory. That's 6+3+3+3=15, twice is 30 ticks, or 7.5 <microseconds at 4MHz. LDAX D ; load using DE as index STAX B ; stor using BC as index That is 7 clocks each or 14 total. @4mhz (1979) tht would be 3.5uS the 6502 at 2mhz may do that in about the same time. < The 6502 takes one to fetch the load opcode, one to <fetch each byte of the source address, one to execute the load, one to fetc <the store opcode, one for each byte of the destination address, and one to <accomplish the store. That's 5 to load, 5 to store, which is 10, right? I <would appear that the 6502 would get through this pretty quickly at the sam <clock rate, i.e. 2.5 microseconds, but the problem is that external <peripheral devices wouldn't run this fast. What's more, the 4 MHz parts, <though priced a little higher than a 4 MHz Z-80, in 1980, the Z-80 had <peripherals which would work very well together with the CPU at 4 MHz. <Nevertheless, that's a 3:1 performance ratio which, based on the fact that <there were many more register-to-register (quick) operations available to <the Z-80 programmer, it's hard to imagine these would close the gap that <much. They would have a significant impact, though. It does depending on the application. If a lot of 16bit adds and subtracts were part of the "core" then were is the 6502? How about languages that use really deep stacks? what about really deep recusive code? The z80 has a far larger stack limit! Granted 128 calls is a lot but none of that stack can pass parameters either, so you need to use one of the index register for that. Also there is interrupt structure for multiple complex devices. Z80 allows a 7 bit vector (pointer to table, anywhere in ram) for mode 2. Even mode0 (8080) it has 8 vectors in low memory (one is reset). using the Mode 1 you still have two (NMI and INT/). Hardware wise can the 6502 support DMA, the z80 has busreq/ and busack/ to request the bus from the cpu and get acknowledgement that it has. How much ram space does the 6502 have to give up for a typical spread of devices verses seperate IO space (z80). Keep in mind if memory mapped IO is desired the z80 does that too. <I think you can easily build a circuit with a 2 MHz 6502 and one with a 4 <MHz Z-80 and make a comparison yourself. If you honestly try to take <advantage of the instruction set to accomplish a task on both processors, <you'll play HELL getting the Z-80 to keep up. It can be done, though, if Depending on the mix it would favor one or another but when averaged out the z80 wins or at best matched. There are other factors that may be system implementation dependent that may favor one over the other. <the task is chosen properly. A pair of simulators would be really handy, <wouldn't it? there are tons for the z80 but few if any do cycle counts or other timing. They could be done for the 6502 but... their performance would have to be validated against the real parts to insure the simulations arent biased. Allison

25 years, 9 months

What if,... early PCs (was: stepping machanism

by allisonp＠world.std.com

<$399 without the monitor and cassette. I struggled long and hard with <that decision, until one of the RS store managers agreed to be willing to <special order a "replacement" monitor for me for $200 if I were to be <unsuccessful in interfacing one of my CCTV monitors. Fortunately (since I <didn't/don't) have Allison's technical expertise, it turned out to need <nothing more than cabling. Wise move! My system test stand at work had a common monitor incase the problem was the RCA box. <BTW, MOST of us thought that CP/M-86 would push PC-DOS out ("as soon as it <comes out")! CP/M-86 was significantly delayed. By the time that it <showed up, and the higher price for it than PC-DOS, PC-DOS was barely <affected by its presence. Shows how much to believe "experts"! It was available at introduction. What was delayed was the marketing. It didn't ship with the machine it was a $200 option. Allison

25 years, 9 months

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

by allisonp＠world.std.com

<I have to disagree with your comparison of the 2 MHz 6502 with a 4 MHz <Z-80A. My thought here is that the 4MHz Z-80 used in the conventional way <had a memory cycle of 750 nanoseconds (3 clock ticks), while the 6502, at No it did not. The memory active portion of the instruction cycle was far shorter, typically 300ns at 4mhz (shorter for M1 cycle). the rest of the time the cpu cares not if memory is there. Now if your depending on the CPU for refresh it's longer but then again if you used something else it still has to be done and takes some about of time/logic. <had to go in order to utilize the memory bandwidth most effectively. The <The 6502 could be interfaced quite easily by using an asymmetrical clock, <with a short Phase-1 (the period during which addresses and control signal The same can be done with the Z80 (the cmos parts it can be very effective). I've used that trick to get a M1 read/ that has the same length as Mread/. <In any case, what I determined was that the Z-80, in spite of its <complicated hardware requirement, was potentially the faster processor. I always get upset with this term as it's hard to quantitize unless standard programs (sieve, fp-ops...) Allison

25 years, 9 months

GeoWorks -- Commodore/Apple/PC?

by roblwill＠usaor.net

GEOS wasn't multitasking? I have it on my Tandy Zoomer (with AOL), and can switch back and forth between two programs, and they seem to be where they were left before (They can't be minimized, like Windows, but they don't seem to close). -- -Jason Willgruber (roblwill(a)usaor.net) ICQ#: 1730318 <http://members.tripod.com/general_1> -----Original Message----- From: Cameron Kaiser <ckaiser(a)oa.ptloma.edu> To: Discussion re-collecting of classic computers <classiccmp(a)u.washington.edu> Date: Saturday, April 10, 1999 7:58 PM Subject: Re: GeoWorks -- Commodore/Apple/PC? >::I Used to have a Commodore 128 that had GeoWorks on it (I think it was >::actually GEOS, or something like that). I also have a box and font/graphics >::set for the PC version or GeoWorks. I've also heard that there was a >::version of it for the Apple // series. > >PC GeoWorks != Commodore/Apple GEOS. Totally different architectures. The >8-bit GEOS was a single-tasking GUI API; the PC version is actually an entire >true preemptively multitasking OS. AOL, before the Windows client emerged, >in fact was based on a PC-GEOS runtime. > >Apple GEOS was an unmitigated flop, especially because Apple was heavily >pushing Quark Catalyst. A shame, because Berkeley Softworks (now GeoWorks) >was trying to add application cross-compatibility between Commodore and Apple >GEOS where possible. > >Commodore GEOS, on the other hand, was and is a big hit. It's still sold >and manufactured, and now people have issued homegrown patches for it that >allow it to take advantage of RAM expansion up to 16MB, hard drive real >estate and the SuperCPU accelerators, and even do context-switching. Avoid >versions before 1.5, however, and even then C= GEOS didn't come into its own >until v2.0. > >-- >-------------------------- personal page: http://calvin.ptloma.edu/~spectre/ -- >Cameron Kaiser Database Programmer/Administrative Computing >Point Loma Nazarene University Fax: +1 619 849 2581 >ckaiser(a)ptloma.edu Phone: +1 619 849 2539 >-- A straw vote only shows which way the hot air blows. -- O. Henry ----------- >

25 years, 9 months

Restoring an 8/E

by mbg＠world.std.com

Allison and I were over at my place today, unloading some of the haul from the weekend - now I've got an RL01 to put on the 11/34a so that I can have a booting system. We took some time to take a look at the pdp-8/e that I now have (which, conincidentally enough was hers about 8 years ago when she gave it to someone else -- the person from whom I obtained my recent haul). We replaced the missing fuse, then used a piece of wire to jumper the plug in the back so it would power up (we got it from the lab-8/e -- the same connector was apparently missing from that machine, so they kludged it). Anyway, we plugged it in, and turned it on.... fans whirred just fine. Allison toggled in a quick program and demonstrated that it had 8k in it, that the CPU seems to execute some instructions, and some of the lights work... so we're off and running. The front panel had a piece broken out of it below the keyswitch, and the panel was kind of dirty... so we removed it and I've cleaned it up. For the time-being the piece is tacked back in with glue from a hot glue gun, but I'll use something else later on... I've also taken some pictures of the case from various angles and have them up in my jpg area, but I haven't set up links to them... If anyone wants to see them by typing in the path to them, they're at http://world.std.com/~mbg/pdp8e_view_001.jpg (002, 003, 004) Megan Gentry Former RT-11 Developer +--------------------------------+-------------------------------------+ | Megan Gentry, EMT/B, PP-ASEL | Internet (work): gentry!zk3.dec.com | | Unix Support Engineering Group | (home): mbg!world.std.com | | Compaq Computer Corporation | addresses need '@' in place of '!' | | 110 Spitbrook Rd. ZK03-2/T43 | URL: http://world.std.com/~mbg/ | | Nashua, NH 03062 | "pdp-11 programmer - some assembler | | (603) 884 1055 | required." - mbg | +--------------------------------+-------------------------------------+

25 years, 9 months

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

by pete＠dunnington.u-net.com

On Apr 11, 14:37, Allison J Parent wrote: > Yes, the 6502 overlaps the instuction fetch and execute (mini pipeline). > The z80 is more classic multi-state machine. In the end the two parts are > roughly the same speed for their generation. IE: a 4mhz z80 does basic > operations in 1uS and 6502 at 2mhz is about the same. That's about my estimation, Richard's example not withstanding. > the difference is > any is when complex indexing or other tassks are discussed where the z80 > has a better instuction set (though slower...more states) the 6502 uses > more small instructions(fast but many). I'm not sure I'd agree, when it comes to indexing. I think the 6502 indexing is more useful in typical cases, and the instruction set is much "cleaner" in some ways. However... > In the end they do the same task just different. Exactly. I was brought up on the Z80, or at least that's what my earliest assembly language experience was on, but I learned how to use a 6502 pretty well. Just a different design philosophy. > That supports the only logical conclusion... clock speeds dont count. -- Pete Peter Turnbull Dept. of Computer Science University of York

25 years, 9 months

Restoring an 8/E

by mbg＠world.std.com

>You mean you _don't_ have a pile of PDP11 power control cables to raid >suitable plugs from ? I do have cables, but I didn't want to canabalize any in order to just make a loop. The looped wire did the trick anyway... >Nice!. It's worth testing all the panel lamps (just load an address of >all 1's, store data of all 1's to location 0, etc). A blown bulb can make >debugging a program rather hard... I plan on doing that at some point... Yes, a blown bulb can make debugging VERY annoying... >Try to get some 'plastic weld'. It's a solvent for the sort of plastic >used on these panels, and you can weld the broken bit back in place. It's >normally a very strong repair. Thanks... I'll keep that in mind... Megan Gentry Former RT-11 Developer +--------------------------------+-------------------------------------+ | Megan Gentry, EMT/B, PP-ASEL | Internet (work): gentry!zk3.dec.com | | Unix Support Engineering Group | (home): mbg!world.std.com | | Compaq Computer Corporation | addresses need '@' in place of '!' | | 110 Spitbrook Rd. ZK03-2/T43 | URL: http://world.std.com/~mbg/ | | Nashua, NH 03062 | "pdp-11 programmer - some assembler | | (603) 884 1055 | required." - mbg | +--------------------------------+-------------------------------------+

25 years, 9 months

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

by edick＠idcomm.com

Please see embedded 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 7:24 AM Subject: Re: stepping machanism of Apple Disk ][ drive (was Re: Heatkit 51/4 floppies) ><I believe (guessing because I've learned memory doesn't serve as it once ><did) The load is two clock ticks and the indirect, indexed jump is five, s ><that's 3.5 microseconds, give or take a tick. it's less at 4 MHz, which i ><what the 65C02C is rated, though it readily will run at 4.9152 (24.576 ><MHz/5) over a wide temperature and voltage range provided the clock is ><phased correctly. the divice-by five yields a 40/60 h/l which must be ><inverted to give a little longer phase-2 than phase-1. > >The point was apparently missed. Of course I can take a cmos z80 and blow >that out of the water using a 6 or 8 mhz clock. Heck using a 1989 version >of the z80, the Z280 at 12.5mhz I can get the execution time way down. In >the time frame before 1982 (as a marker) there werent any 4mhz 650c02s and >there were 4mhz z80s and pdp-8s were still produced. In that context the >the example represent programming style rather that absolute speed as they >didn't vary that much over all to represent a great diffferece unless you >needed a characteristic that was specific to a given CPU. No, the point wasn't missed. I remember what was going on back then (1979-1984) because it was at a critical juncture in the course of my life. In 1979, my "favorite" CPU was the 6502, the fastest MOS-Technology-comptible version of which was the 4 MHz NMOS part from SYNERTEK. I was VERY involved in making things run faster than most folks thought they could/should at that time and also had occasion to attempt comparison and contrast on the basis of a number of parameters, including performance. In '79, ZILOG and MOSTEK put out the 6-MHz "B"-series of their Z-80, which was enjoying almost universal acceptance as the most widely applicable and easiest-to-use microprocessor available. Most of the popular statements about it were pretty much on the money. Of course, the evolution of the 64K DRAM made its refresh counter more or less useless, but the impact of that wasn't to be felt for a couple of years yet, as commercial production of the 3-voltage 16K DRAMS was just getting into full swing. >I'm not slamming the 6502 or it heirs as it's also a very popular embedded >CPU still. For that fact so are the Z8 and Z80 heirs. Just from that it's >possible to conclude they all had desirable enough characteristics to keep >them in the running. I agree with you there. The Zilog boys had the CP/M crowd to maintain the low-end of their development system market, so nobody could complain it was too expensive to develop. The MOS-Technology folks had merely to point at the Apple to accomplish the same thing. Meanwhile, Motorola was making a BIG mistake, abandoning the amateur and "small" users. >As a CPU the 8051 is ok, I use it. As a controller it's without question >a popular part still. But as a general purpose cpu, it's a really bad >C or Pascal compiler host/target. Since the evolution of the now-popular 'C' and PASCAL compilers for the 8051-core micro's, I believe the popularity of this 25-year-old model has actually increased. The HLL's and the development of high-speed versions of this processor family by DALLAS and Philips, among others have definitely extended the life of this family. The simple migration path to "bigger" parts of more or less the same architecture, e.g. '251, has also made many a '51-core user. I believe that it's as a consequence of that, that there are now compilers for several truly "ugly" architectures, e.g. the PIC/SCENIX class of processors. There are also VHDL and VERILOG cores for several of the older architectures, e.g. 650x, available for those who prefer to "roll-their-own" which are also, though less well, supported with compilers and other tools. Again, Motorola seems to have been left behind at least with their smaller MCU's. I guess that's because of their reputation for spurning applications which consume fewer than 100K parts per week. > >Allison >

25 years, 9 months

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

by edick＠idcomm.com

If you look at the instructions as opposed to getting too hung up on the register assets, and simply look at what it takes to "do something" e.g. load a value, do some arithmetic, store a value, etc. the two instruction sets have considerable overlap. However, the longest instructions for the 6502 take six (?) clock ticks, while the shortest ones for the Z-80 take four. (feel free to correct me, as I haven't even though about this, let alone looked at precise instruction details for over ten years.) I don't know how long the longest instruction for the Z-80 takes nor do I even know what its longest instruction is. I'd imagine it's one in which you load a 16-bit register from memory, indexed, or some such. That would have to take a fair number of clock ticks. In my comparisons, I've always fudged in favor of the Z-80, because it didn't make sense to me that a processor so cheap and simple would be as much faster than a Z-80 as the 6502 appeared. The hardware problems aside, the Z-80 instruction set is full of pretty complex instructions which take a number of clock ticks. The 6502 is full of fairly complex instructions too, but not as many. Fortunately, most programmers don't use ALL of either processor's instructions unless they are pushed. If you look at a simple load-the-accumulator then store-the-result, which occurs often in almost any application, the Z-80 takes about 6 ticks in the opcode fetch/decode (the instruction is decoded during the refresh cycle), three for each byte of the source address, then three to fetch the value. It then takes as long to store the result to memory. That's 6+3+3+3=15, twice is 30 ticks, or 7.5 microseconds at 4MHz. The 6502 takes one to fetch the load opcode, one to fetch each byte of the source address, one to execute the load, one to fetch the store opcode, one for each byte of the destination address, and one to accomplish the store. That's 5 to load, 5 to store, which is 10, right? It would appear that the 6502 would get through this pretty quickly at the same clock rate, i.e. 2.5 microseconds, but the problem is that external peripheral devices wouldn't run this fast. What's more, the 4 MHz parts, though priced a little higher than a 4 MHz Z-80, in 1980, the Z-80 had peripherals which would work very well together with the CPU at 4 MHz. Nevertheless, that's a 3:1 performance ratio which, based on the fact that there were many more register-to-register (quick) operations available to the Z-80 programmer, it's hard to imagine these would close the gap that much. They would have a significant impact, though. I think you can easily build a circuit with a 2 MHz 6502 and one with a 4 MHz Z-80 and make a comparison yourself. If you honestly try to take advantage of the instruction set to accomplish a task on both processors, you'll play HELL getting the Z-80 to keep up. It can be done, though, if the task is chosen properly. A pair of simulators would be really handy, wouldn't it? Dick -----Original Message----- From: Pete Turnbull <pete(a)dunnington.u-net.com> To: Discussion re-collecting of classic computers <classiccmp(a)u.washington.edu> Date: Sunday, April 11, 1999 10:55 AM Subject: Re: stepping machanism of Apple Disk ][ drive (was Re: Heatkit 51/4 floppies) >On Apr 11, 10:20, Richard Erlacher wrote: >> Subject: Re: stepping machanism of Apple Disk ][ drive (was Re: Heatkit >51 >> I have to disagree with your comparison of the 2 MHz 6502 with a 4 MHz >> Z-80A. My thought here is that the 4MHz Z-80 used in the conventional >way, >> had a memory cycle of 750 nanoseconds (3 clock ticks), while the 6502, at >> whatever rate, again, used in the conventional way, had a memory cycle of >> one clock tick. Now, some instructions involve several memory cycles, >but >> that was true of both processor families. What I often cursed, was that >the >> textbook application of the 650x core left memory available (idle) half >the >> time. That was a blessing up to a point (2.5 MHz to be exact) because it >> allowed for DRAM "RAS-precharge." The Apple and others like it proved >that >> at around 1 MHz, the 6502's memory could be used for an entirely separate >> purpose, e.g. video refresh. > >I wasn't talking about precisely 2MHz vs 4MHz, just a ballpark figure (as >opposed to "about the same" or "about ten times" clock speeds). So, given >the rest of your message, I think we're in broad agreement. BTW, BBC >Micros have a 2MHz clock on the 6502, and interleaved video and processor >access quite happily in 1980. The video took care of the refresh >requirement. > >> I believe there are entirely too many subjective, architecture-related, >> factors to allow an absolute comparison/contrast of the two processors. > >Agreed :-) That's why lies, damned lies, and benchmarks are so much fun >:-) > >> In my "gut" I still believe the 4 MHz Z-80 is about >> comparable to a 1.5 MHz 6502. > >Well, that's not very far from what I wrote, is it? I was just pointing >out that although Allison seemed to imply that a 6 or 8MHz Z80 was much >faster than a 4MHz(? I haven't got the original message any more) 6502, I >believe that to be far from the case. > >-- > >Pete Peter Turnbull > Dept. of Computer Science > University of York

25 years, 9 months

What if,... early PCs (was: stepping machanism

by edick＠idcomm.com

I didn't hate the glyptol on the screws nearly so much as I hated the bayonet interlocks, which often broke when you opened a RS box Dick -----Original Message----- From: Fred Cisin (XenoSoft) <cisin(a)xenosoft.com> To: Discussion re-collecting of classic computers <classiccmp(a)u.washington.edu> Date: Sunday, April 11, 1999 12:16 PM Subject: Re: What if,... early PCs (was: stepping machanism >On Sun, 11 Apr 1999, Richard Erlacher wrote to Allison: >> The principal complaint I heard about the M1 was the principal complaint >> about the M3. It was a paper tiger until you opened the box and added a >> bunch of stuff/mods. > >While I agree, I kinda doubt that Allison has EVER plugged in ANYTHING >before she "opened the box and added a bunch of stuff/mods". So, she >might not see that as quite the negative that you do :-) > >> The same, to lesser extent, perhaps, could be said for >> the Apple. The Apple was made easy-to-open. The RS boxes were not. > >While velcro is certainly extraordinarily convenient, particularly to >those bothered by screwdrivers. But, as an occasional professional auto >mechanic, I hardly felt that half a dozen screws made something hard to >open. But it is true that RS had a very bad attitude about it. They >actually had anti-tamper paint on one of the screws! One of the local RS >technicians had an interesting slant on that: Since RS's policies >apparently didn't explicitly mention modifications, only that the tamper >seal must be intact, he would happily do the various warranty mods (there >were SEVERAL for the early EI), IFF you provided him circuit sketches for >all mods, and put a dab of the anti-tamper paint (he would provide it) on >the screw after you made the mods. He said that if the store manager >balked at seeing additional stuff through the slots of the "unopened" >case, just start talking about "building boats in bottles". Apple's >attitude of "go on in!" was much more refreshing. > > >> When I saw my first PC in a commercial environment, it was running CP/M-86 >> because that had the software the business owner was using previously on his >> Z-80. I often wondered what motivated him to switch. I also saw a couple >> of people's Apple-II running CP/M-86, and was awed by the fact they'd run an >> OS that was slower than the previous and better-endowed (with software) >> CP/M-80 in the same basic environment. > >Interesting. What after-market system were they running to do CP/M-86 on >the Apple? > >> IBM really performed only one major service to the microcomputer world: >> They lent it its own trade name, which was its legitimacy. >"PC" was in moderately common usage around here before IBM's entry. >IBM always considered "PC" to be a shortened description, NOT a trade >name! They did NOT trademark "PC". They never even trademarked >"PC-DOS"!! OTOH, "MS-DOS" IS a registered trademark. > >> Having done >> that, the behemoth was overrun by smaller, more adept innovators. > >Like a handful of fleas on an elephant. > >One fellow referred to Compaq's "challenge" of IBM as "a mouse running up >the elephant's leg with intent to rape". > >

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