Newsgroups: alt.folklore.computers Subject: Re: CPU speeds References: <6au7ml$qa0@netaxs.com> <34d837b8.0@comnet.co.nz> Organization: Wizvax Communications, Troy, NY. USA From: multics@wizvax.wizvax.net (Richard Shetron) NNTP-Posting-Host: wizvax.wizvax.net Message-ID: <34d9d6a1.0@news.wizvax.net> Date: 5 Feb 98 15:11:29 GMT Lines: 20 Path: ccw.ch!aetna.dolphins.ch!news.planetc.com!news.igateway.net!news.pagesat.net!howland.erols.net!cpk-news-hub1.bbnplanet.com!news.bbnplanet.com!baron.netcom.net.uk!netcom.net.uk!newsfeed.wizvax.net!news.wizvax.net!wizvax.wizvax.net!multics In article <34d837b8.0@comnet.co.nz>, Gaven Miller wrote: >Lisa or Jeff (hancock4@bbs.cpcn.com) wrote in alt.folklore.computers: >> > What were the first computers to break the one kilo/mega/gigahertz CPU >> > speeds? > >> That's not really a proper question, because "speed" can mean very >> substantial different things from one computer to another. > >Fair enough - the question was a bit ambiguous. > >I was thinking of the core CPU speed - one hears so much of 500 MHz >Alphas and 300 MHz Pentiums and PPCs. [snip] From my aged and flakey memory: The Cray one used 2 basic clock cycles, 2ns and 3ns. The Cray one could achieve 350M floating point instructions/second. This was around 1975. I'm not sure what current 'super' computers can do. Of course another question is how do you count multiprocessor systems, such as ILLIAC IV and newer varients ;) ###### From: TonyLima@ms.spacebbs.com (Tony Lima) Newsgroups: alt.folklore.computers Subject: Re: CPU speeds Date: Sat, 07 Feb 1998 04:12:57 GMT Organization: Nope, none Lines: 21 Sender: @207.204.228.201 Message-ID: <34dbdd22.9857444@news.spacebbs.com> References: <6au7ml$qa0@netaxs.com> <34d837b8.0@comnet.co.nz> Reply-To: TonyLima@ms.spacebbs.com NNTP-Posting-Host: 5128@207.204.228.201 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Newsreader: Forte Agent 1.5/16.451 Path: ccw.ch!aetna.dolphins.ch!news.planetc.com!newsfeed.usit.net!news.he.net!Supernews60!supernews.com!Supernews69!not-for-mail On 4 Feb 98 09:41:12 GMT, gmiller@inca.co.nz (Gaven Miller) wrote: >Lisa or Jeff (hancock4@bbs.cpcn.com) wrote in alt.folklore.computers: >> > What were the first computers to break the one kilo/mega/gigahertz CPU >> > speeds? > >> That's not really a proper question, because "speed" can mean very >> substantial different things from one computer to another. > >I was thinking of the core CPU speed - one hears so much of 500 MHz >Alphas and 300 MHz Pentiums and PPCs. > >Have any CPUs breached the GHz (GigaHertz) speed yet? (Probably the >hundreds-of-million-dollars-each supercomputers are close, or broke it a >year or two back. According to news reports today (Feb. 6), IBM has just announced an experimental cpu chip that will do a gigahertz. The way things go in this industry, I want one in the computer I'm buying next summer! - Tony ###### From: hotlynx@SPAMBEGONEwhidbey.net Newsgroups: alt.folklore.computers Subject: Re: CPU speeds Date: Tue, 10 Feb 1998 13:15:05 -0800 Organization: WhidbeyNet News Service Lines: 37 Message-ID: References: <6au7ml$qa0@netaxs.com> <34d837b8.0@comnet.co.nz> NNTP-Posting-Host: asn182.whidbey.net X-Newsreader: Anawave Gravity v2.00 Path: ccw.ch!aetna.dolphins.ch!news.planetc.com!leto.ou.edu!hammer.uoregon.edu!logbridge.uoregon.edu!news-peer.gip.net!news.gsl.net!gip.net!news-peer.sprintlink.net!news-backup-east.sprintlink.net!news-in-east.sprintlink.net!news.sprintlink.net!Sprint!204.94.52.5!news.whidbey.com!not-for-mail In article <34d837b8.0@comnet.co.nz>, gmiller@inca.co.nz says... [ edited for brevity ] > Lisa or Jeff (hancock4@bbs.cpcn.com) wrote in alt.folklore.computers: > > > What were the first computers to break the one kilo/mega/gigahertz CPU > > > speeds? > I was thinking of the core CPU speed - one hears so much of 500 MHz > Alphas and 300 MHz Pentiums and PPCs. > > Have any CPUs breached the GHz (GigaHertz) speed yet? (Probably the > hundreds-of-million-dollars-each supercomputers are close, or broke it a > year or two back. IBM just announced a 1000 Mhz cpu; it's supposed to be ready in 2-3 years > > I am interested in seeing how well they fit the doubling-of-power every > eighteen months that one keeps reading in computer mags. > > And when the one kilhertz and one megahertz speeds were broken. > My C-64 was 1 Mhz, low bandwidth, slow bus, painfully slow disk access (2 1/2 minutes to load a program which could be no more than 39Kb in memory). On the other hand, my 300b modem was state of the art. I had many jealous friends whose modems were 150b. At the time, many businesses were run from C-64s and even VIC-20s. I created a crude double-entry accounting program in Superbase, and used a lot of spreadsheets for estimating for home builders. > > I only got into computers in a small way in 1982-ish, when the "state of > the art" was somewhere around six to eight megahertz (I think) see my previous comment -- L. Nino -- You can blame everything on me this year. ###### From: "Wanderer" Newsgroups: alt.folklore.computers Subject: Re: CPU speeds Date: Tue, 10 Feb 1998 23:30:00 -0700 Organization: AT&T WorldNet Services Lines: 33 Message-ID: <6brghc$qs4@bgtnsc02.worldnet.att.net> References: <6au7ml$qa0@netaxs.com> <34d837b8.0@comnet.co.nz> <34e12c86.188611305@news.xmission.com> NNTP-Posting-Host: 12.64.119.141 X-Newsreader: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Path: ccw.ch!aetna.dolphins.ch!news.planetc.com!leto.ou.edu!hammer.uoregon.edu!logbridge.uoregon.edu!news.maxwell.syr.edu!news-peer.sprintlink.net!news.sprintlink.net!Sprint!worldnet.att.net!newsadm I remember my best friend and I comparing my TRS-80 Model 4 to his C-64. The arguments we used to get into over whose were better. Regardless of the fact that we were just barely into our teens and didn't have a clue anyway. The really cool thing was using Genie for the first time (remember Genie????) Now that was a memory. Who would have thought we would have gotten this far compared to back then. . . -- Jas and Jen http://www.doitnow.com/~jshultz -- Outland Ezine http://www.geocites.com/rainforest/vines/4183 ^^^^---Jen's new panda site------^^^^^ Scott Brown wrote in message <34e12c86.188611305@news.xmission.com>... >On Tue, 10 Feb 1998 13:15:05 -0800, hotlynx@SPAMBEGONEwhidbey.net >wrote: > >>My C-64 was 1 Mhz, low bandwidth, slow bus, painfully slow disk access (2 >>1/2 minutes to load a program which could be no more than 39Kb in >>memory). On the other hand, my 300b modem was state of the art. I had >>many jealous friends whose modems were 150b. > >Those C64 drives were a sick joke. My Color Computer had the same >1MHz clock and 8-bit bus, but it would read a whole disk (180k) in a >minute or so. > >The C64 disk drives were on some kind of serial interface, weren't >they? I wonder what kind of design compromises they made to end up >with that interface. > ###### From: dg@ (David Given) Newsgroups: alt.folklore.computers Subject: Re: CPU speeds Date: Wed, 11 Feb 1998 12:51:18 GMT Organization: I'm organised? Wow! Message-ID: <887201478.12214.0.nnrp-09.9e9878e0@news.demon.co.uk> References: <6au7ml$qa0@netaxs.com> <34d837b8.0@comnet.co.nz> <34e12c86.188611305@news.xmission.com> NNTP-Posting-Host: taos.demon.co.uk X-NNTP-Posting-Host: taos.demon.co.uk [158.152.120.224] Lines: 46 Path: ccw.ch!aetna.dolphins.ch!news.planetc.com!leto.ou.edu!hammer.uoregon.edu!logbridge.uoregon.edu!woodstock.news.demon.net!demon!news.demon.co.uk!demon!taos.demon.co.uk!!dg In article <34e12c86.188611305@news.xmission.com>, Scott Brown wrote: [...] >Those C64 drives were a sick joke. My Color Computer had the same >1MHz clock and 8-bit bus, but it would read a whole disk (180k) in a >minute or so. BBC's had one of the fastest disk interfaces around. IIRC, it was about 10kB/s; at 2.5kB per track (10 sectors, 256 bytes per secotr, 40 or 80 tracks for those who are interested) the tracks fairly chugged past. Used an industry standard 1770 controller, too. The BBC Master had an 8251 and could read PC disks. The BBC's filing system --- DFS, no prizes for guessing what it stood for --- was incredibly simple. 31 files per disk. No fragmentation. Filenames were seven letters, with a single letter for the `directory'. The root directory was called $. The BBC Master had an advanced version, ADFS. This used high-density double-sided disks and could format up to 640kB per disk. The filing system was hierarchical. Filenames were ten letters, much more usable; unfortunately, I don't know about fragmentation. It was much slower, of course; in order to scan a path, it had to scan each component of it and 8-bit machines didn't have disk caches. Much like DOS, really. >The C64 disk drives were on some kind of serial interface, weren't >they? I wonder what kind of design compromises they made to end up >with that interface. The CBM and PET used an IEEE bus and were pathetically slow. The C64 and VIC used a four(?)-wire serial bus and were also pathetically slow. The really *silly* thing was that you could pull data off disk into the on-board memory on the disk drive quite fast... you just couldn't do anything useful with it there. It was the CBM that had two 6502 processors in the disk drive and one in the computer, wasn't it? David Given dg@freeyellow.com ###### From: nickb@primenet.com (Nick S Bensema) Newsgroups: alt.folklore.computers Subject: Re: CPU speeds Date: 11 Feb 1998 12:56:00 -0700 Organization: PrImE NuT (602)864-1005 <--- <--- <--- Lines: 75 Message-ID: <6bsvog$oti@nntp02.primenet.com> References: <6au7ml$qa0@netaxs.com> <34d837b8.0@comnet.co.nz> <34e12c86.188611305@news.xmission.com> X-Posted-By: nickb@206.165.6.203 (nickb) X-Battlestar-Galactica-Date: 2349 croutons, 58 futons, SIX HECTARES! X-Newsreader: trn 4.0-test58 (13 May 97) Path: ccw.ch!aetna.dolphins.ch!news.planetc.com!leto.ou.edu!hammer.uoregon.edu!logbridge.uoregon.edu!su-news-hub1.bbnplanet.com!news.bbnplanet.com!www.nntp.primenet.com!globalcenter1!news.primenet.com!not-for-mail In article <34e12c86.188611305@news.xmission.com>, Scott Brown wrote: >On Tue, 10 Feb 1998 13:15:05 -0800, hotlynx@SPAMBEGONEwhidbey.net >wrote: > >>My C-64 was 1 Mhz, low bandwidth, slow bus, painfully slow disk access (2 >>1/2 minutes to load a program which could be no more than 39Kb in >>memory). On the other hand, my 300b modem was state of the art. I had >>many jealous friends whose modems were 150b. > >Those C64 drives were a sick joke. My Color Computer had the same >1MHz clock and 8-bit bus, but it would read a whole disk (180k) in a >minute or so. > >The C64 disk drives were on some kind of serial interface, weren't >they? I wonder what kind of design compromises they made to end up >with that interface. I do know that the PET had an IEEE interface, which allowed it to use drives that were practically identical to the 1541 drives used by the C64, but faster. One of these was the 4040, which was present on the computer in my kindergarten class.... it was a dual drive system, meaning the same device number could access two disks by specifying filenames like 0:filename and 1:filename. The 1541 actually used the 4040's kernel, but the transition to a single-drive system wasn't entirely smooth.... hence, a bug that crept in and ate one of your files when you used the save-and-replace filename feature. I lost all the code to my first, and last C64 demo in that bug. But the 1541 itself isn't all that brain-dead. The serial bus is...at least in its native form. The problem with the IEEE bus was that it wasn't easy to make cables and stuff like that. So, they switched to a serial cable which used a 6-pin DIN, the kind that you can still get at any electronics store today. This probably made its first appearance in the Vic-20, which allows the use of most C64 devices, including disk drives, printers, cassette drives, and modems. Legend has it that the slowness occurs because of the Commodore 64's design. The video chip had such high demand for memory that it had to sneak away CPU cycles every eight scanlines to read in whatever it was going to draw. Since this interfered with the otherwise smooth operation of the serial port, the disk read routines were written to read data in a way that this wasn't an issue anymore. A much, much slower way. Perhaps it would have been better if they had just done like they did with the cassette player and blanked the screen during loads*. In theory, this might mean that a 1541 could load programs faster on a Vic-20 than on a stock C-64; the Vic-20's primitive video hardware doesn't need to steal CPU time. It also explains how the one-minute full-disk copy works: just have the disk drives send the data to each other, without running them through the computer. Since the 1541's each had their own processor, all you'd have to do is send them each a small program and have them run. Stuff like this is even mentioned in the programmer's reference manual, where it suggests you can print a disk file by sending the disk drive a TALK signal and sending the printer a LISTEN signal. There are innumerable fast-load methods for the Commodore 64, both in software and hardware. Some of them don't even require the screen to blank. The unfortunate side-effects of this are that drives which aren't completely 1541-compatible might not work with some products, and it complicates the emulation of both the Commodore 64 itself and the Commodore 1541 (for file-serving purposes). * Actually there was a program called TurboTape available for both the Vic-20 and the Commodore 64, from Compute's Gazette, which allowed one to copy disk files to tape in a format that loaded slightly faster than a stock 1541 hooked up to a Commodore 64. At least one of the Action Replay cartridges also did this. -- Nick Bensema 98-KUPD Red Card #710563 UIN: 2135445 ~~~~ ~~~~~~~ ~~~~~~~~~~~~~~~~~~~~ ###### From: R!ch Newsgroups: alt.folklore.computers Subject: Re: CPU speeds Date: Wed, 11 Feb 1998 15:14:42 +0000 Lines: 36 Message-ID: References: <6au7ml$qa0@netaxs.com> <34d837b8.0@comnet.co.nz> <34e12c86.188611305@news.xmission.com> <887201478.12214.0.nnrp-09.9e9878e0@news.demon.co.uk> NNTP-Posting-Host: paddington.uk.sun.com Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Sender: richardt@paddington To: dg@freeyellow.com In-Reply-To: <887201478.12214.0.nnrp-09.9e9878e0@news.demon.co.uk> Path: ccw.ch!aetna.dolphins.ch!news.planetc.com!newsfeed.usit.net!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.internetmci.com!194.72.7.126!btnet-peer!btnet-feed2!btnet!carbon.eu.sun.com!uk-usenet.uk.sun.com!paddington!richardt On Wed, 11 Feb 1998, it was written: > BBC's had one of the fastest disk interfaces around. IIRC, it was about > 10kB/s; at 2.5kB per track (10 sectors, 256 bytes per secotr, 40 or 80 > tracks for those who are interested) the tracks fairly chugged past. Used > an industry standard 1770 controller, too. The BBC Master had an 8251 and ~~~~ Not the orginal Beebs; these used Intel's 8271, and were like gold dust until the 1770 became more standard in Beebs. > The BBC's filing system --- DFS, no prizes for guessing what it stood for > --- was incredibly simple. 31 files per disk. No fragmentation. Filenames 31 files per side. Disc (sic) Doctor (from Watford Electronics?) extended this to 62, by allowing you to switch between two 31 file "catalogues". The "other" catalogue was stored in a file called "!.!!!!!!!", IRRC. -- R!ch (Email is flakey at present: use richardt@keaton.uk.sun.com) If it ain't analogue, it ain't music. #include \\|// - ? (o o) /==================================oOOo=(_)=oOOo========\ | Richard Teer richard.teer@uk.sun.com | | | | | | WWW: www.rkdltd.demon.co.uk | | .oooO | | ( ) Oooo. | \===================================\ (==( )==========/ \_) ) / (_/ ###### From: korpela@islay.ssl.berkeley.edu (Eric J. Korpela) Newsgroups: alt.folklore.computers Subject: Re: CPU speeds Date: 11 Feb 1998 16:54:41 GMT Organization: Cal Berkeley-- Space Sciences Lab Lines: 22 Message-ID: <6bsl4h$mm4$1@agate.berkeley.edu> References: <6au7ml$qa0@netaxs.com> <34d837b8.0@comnet.co.nz> NNTP-Posting-Host: islay.ssl.berkeley.edu Path: ccw.ch!aetna.dolphins.ch!news.planetc.com!leto.ou.edu!hammer.uoregon.edu!logbridge.uoregon.edu!agate!islay.ssl.berkeley.edu!korpela In article , wrote: >My C-64 was 1 Mhz, low bandwidth, slow bus, painfully slow disk access (2 >1/2 minutes to load a program which could be no more than 39Kb in >memory). On the other hand, my 300b modem was state of the art. I had >many jealous friends whose modems were 150b. That's because Commodore, in their infinite wisdom (read: to make things cheap) chose a slow serial link for their floppy drives. (I don't really think they thought people would actually by a FDD for a VIC-20 or C-64) The link was about 1200 bps. Later programs doubled or tripled this speed by using the serial port handshaking lines for data transfer. Eric -- Eric Korpela | An object at rest can never be korpela@ssl.berkeley.edu | stopped. Click here for more info. ###### From: atbowler@thinkage.on.ca (Alan Bowler) Newsgroups: alt.folklore.computers Subject: Re: CPU speeds Date: 11 Feb 1998 18:04:57 GMT Organization: Thinkage Ltd. Lines: 11 Message-ID: <6bsp89$o55$1@nntp1.uunet.ca> References: <34d837b8.0@comnet.co.nz> <34e12c86.188611305@news.xmission.com> NNTP-Posting-Host: 192.102.11.4 Path: ccw.ch!aetna.dolphins.ch!news.planetc.com!leto.ou.edu!hammer.uoregon.edu!logbridge.uoregon.edu!newsfeed.direct.ca!news.uunet.ca!atbowler In article <34e12c86.188611305@news.xmission.com> skb@xmission.removethis.com (Scott Brown) writes: >The C64 disk drives were on some kind of serial interface, weren't >they? I wonder what kind of design compromises they made to end up >with that interface. It was a stripped down version of the HP-IB (Hewlett Packard Instrument Bus?) (IEEE-488). This originally designed as something to read/control various devices (sensors, valves (the mechanical kind) etc. Using for disks as Commodore did with the PET was kind of bizarre. When they did the C64, they stopped uing the standard cable, and some of the signal lines. ###### From: daled@cds9172.Cadence.COM (Dale DePriest) Newsgroups: alt.folklore.computers Subject: Re: CPU speeds Date: 11 Feb 1998 19:07:16 GMT Organization: Cadence Design Systems, Inc Lines: 57 Distribution: world Message-ID: <6bsst4$ke7$3@news.cadence.com> References: <6au7ml$qa0@netaxs.com> <34d837b8.0@comnet.co.nz> <34e12c86.188611305@news.xmission.com> <887201478.12214.0.nnrp-09.9e9878e0@news.demon.co.uk> NNTP-Posting-Host: cds9172.cadence.com Path: ccw.ch!aetna.dolphins.ch!news.planetc.com!leto.ou.edu!hammer.uoregon.edu!logbridge.uoregon.edu!ais.net!uunet!in5.uu.net!news.cadence.com!cds9172.Cadence.COM!daled In article <887201478.12214.0.nnrp-09.9e9878e0@news.demon.co.uk>, dg@ (David Given) writes: |> In article <34e12c86.188611305@news.xmission.com>, |> Scott Brown wrote: |> [...] |> >Those C64 drives were a sick joke. My Color Computer had the same |> >1MHz clock and 8-bit bus, but it would read a whole disk (180k) in a |> >minute or so. |> >The C64 disk drives were on some kind of serial interface, weren't |> >they? I wonder what kind of design compromises they made to end up |> >with that interface. |> |> The CBM and PET used an IEEE bus and were pathetically slow. The C64 and Actually the CBM and PET had acceptable performance. The IEEE bus has quite a bit of handshaking but did a fair job of transferring data. You can always be faster if you don't share devices on a bus. The bus idea was nice. It was neat to see an $800 pet controlling thousands of dollars worth of test equipment in a lab. The IEEE bus was all implemented in software in the machine. |> VIC used a four(?)-wire serial bus and were also pathetically slow. The Now this was really slow. I agree with pathetic. The serail bus was a full serial implementation of the IEEE bus. It had all of the bus overhead and only serial data. They did find some mistakes in the design and could have sped up the C-64 a bit but didn't just to maintain compatiblity. Too bad. |> really *silly* thing was that you could pull data off disk into the |> on-board memory on the disk drive quite fast... you just couldn't do |> anything useful with it there. Compatibility is just a two edged sword. There were hardware fixes that were sold by third parties to speed up the interface. They made a considerable difference. |> It was the CBM that had two 6502 processors in the disk drive and one in |> the computer, wasn't it? Yes they had two processors. The peripherals were intelligent. Actually my 4040 disk has two processors in the disk drive controller itself. One to talk to the drive and one to talk to the interface. The design made sense for the time. Note that busmaster scsi controllers in a pc also have a second processor to do i/o. Pretty advanced, really. |> |> David Given |> dg@freeyellow.com |> |> -- _ _ Dale DePriest San Jose, California /`) _ // daled@Cadence.COM voice: (408) 428-5249 o/_/ (_(_X_(` ISO 9000 Program Manager fax: (408) 894-3484 ###### Path: ccw.ch!usenet From: Neil.Franklin.remove.this@ccw.ch Newsgroups: alt.folklore.computers Subject: Re: CPU speeds Date: 11 Feb 1998 21:42:57 +0100 Organization: My own Private Self Lines: 67 Message-ID: <3ehp27qm.fsf@chonsp.franklin.lugs.ch> References: <6au7ml$qa0@netaxs.com> <34d837b8.0@comnet.co.nz> <34e12c86.188611305@news.xmission.com> <887201478.12214.0.nnrp-09.9e9878e0@news.demon.co.uk> X-Newsreader: Gnus v5.3/Emacs 19.34 dg@freeyellow.com (David Given) noted: >The CBM and PET used an IEEE bus and were pathetically slow. The C64 and >VIC used a four(?)-wire serial bus and were also pathetically slow. The PET and the larger CBMs (2xxx, 4xxx, 8xxx) used the IEEE488/IEC625 bus for connecting to disk drives and printers. That was an large/expensive (24/25 wire) affair, 8 data, 3 handshake, 5 control, rest GND. It managed ca 2 kByte/second. The Vic-20 and the C64 used a Commodore-proprietary reduced version of above, they called it Serial IEC Bus. That was an small/cheap (6 wire, DIN plug) affair, 1 data, 1 clock, 3 control, 1 GND. It managed even less, ca 1/2 kByte/second (it was synchronised with the video output, 1 bit per ca 4 scan lines, because the processor stopped running). 1 = Service Request, from peripheral 2 = GND 3 = Attention, from computer 4 = Clock, bidirectional 5 = Data, bidirectional 6 = Reset, bidirectional, directly to/from CPU reset pin, unbuffered (!) Thats what this C64 wiring diagram here ((C) CBM 1983) says. >The really *silly* thing was that you could pull data off disk into the >on-board memory on the disk drive quite fast... you just couldn't do >anything useful with it there. You could do usefull stuff there. The Floppy BIOS/DOS allowed saving of machine code to a file, followed by loading any block on disk into the Floppy memory and executing it. This was used to replace the BIOS/DOS with routines that transfered data up to 10 times faster (they had to switch off the computers video display to do this). It was though awfull to program, because all BIOS/DOS routines ended in fixed jumps to the main loop (not returns, they saved stack space) and the main loop had no hookable vectors (such as the computers BASIC interpreters had). I one heard a rumour (never saw it) of an program that calculated Mandelbrot on the Floppy controller (it didn't get stopped 40% of the time for video DMA, nor interrupted 20% of the time for keyboard scan). >It was the CBM that had two 6502 processors in the disk drive and one in >the computer, wasn't it? The Pet/CBM/Vic/C64 had each 1 6502-1 in them. The 1540/1541/2030 Floppies had their own 6505-1 (or 6502-2?, can't remember) The 4040/8x50 Floppies had both an 6502-x and an 6504-x in them (!) 6502 did the BIOS/DOS, 6504 the actual disk controller The printers had yet annother 6502 (or 6504 ?) in them. Processors were cheap then :-) Cheaper that TTL based controllers (there existed no ASIC "chipsets"). After all that was the reason for inventing microprocessors. Personal/ Home computers were only a side effect. Must be the largest side effect in history :-) -- Neil.Franklin.remove.this@ccw.ch, http://www.ccw.ch/Neil.Franklin/ for Geek Code, Papernet, Voicenet, PGP public key see http: Mac, 95 and NT users are CLUEless (Command Line User Environment) If I go missing, its once again my newsfeed that has craped ###### From: Clark_Geisler@nospamnortel-nsm.com (Clark Geisler) Newsgroups: alt.folklore.computers Subject: Re: CPU speeds Date: Wed, 11 Feb 1998 23:24:31 GMT Organization: Nortel Message-ID: <6btbtl$j4q@bcrkh13.bnr.ca> References: <34d837b8.0@comnet.co.nz> <34e12c86.188611305@news.xmission.com> <6bsp89$o55$1@nntp1.uunet.ca> NNTP-Posting-Host: 47.223.64.209 X-Newsreader: News Xpress 2.01 Lines: 28 Path: ccw.ch!aetna.dolphins.ch!news.planetc.com!leto.ou.edu!news.onenet.net!news.oru.edu!woodstock.news.demon.net!demon!europa.clark.net!209.130.129.134!node2.frontiernet.net!node17.frontiernet.net!xcski.com!freenet-news.carleton.ca!cunews!nott!bcarh189.bnr.ca!bmerhc5e.bnr.ca!bcrkh13.bnr.ca!cgeisler In article <6bsp89$o55$1@nntp1.uunet.ca>, atbowler@thinkage.on.ca (Alan Bowler) wrote: >In article <34e12c86.188611305@news.xmission.com> skb@xmission.removethis.com > (Scott Brown) writes: >>The C64 disk drives were on some kind of serial interface, weren't >>they? I wonder what kind of design compromises they made to end up >>with that interface. > >It was a stripped down version of the HP-IB (Hewlett Packard Instrument >Bus?) (IEEE-488). This originally designed as something to read/control >various devices (sensors, valves (the mechanical kind) etc. Using for >disks as Commodore did with the PET was kind of bizarre. When they did >the C64, they stopped uing the standard cable, and some of the signal >lines. Actually, HP themselves used HP-IB to interface most of the floppy and hard disk boxes they built to work with the computers they built in the 1980's. In fact, you could get a faster-than-standard speed HP-IB controller that was designed specifically for connecting hard disks. You used the same cables (which are actually pretty damn good technically: shielded, with a solid metal connector), but the total length of the bus chain allowed was lower than the standard IEEE-488 allowed. I'm not sure, but I think standard IEEE-488 can go to 1 M byte/s, and the HP suped up version could do 5 M Bytes/s. -- Clark Geisler Test Engineer, Nortel, Lentronics division, Burnaby, BC, Canada * fix my e-mail address as required. ###### From: dg@ (David Given) Newsgroups: alt.folklore.computers Subject: Re: CPU speeds Date: Thu, 12 Feb 1998 12:24:25 GMT Organization: I'm organised? Wow! Message-ID: <887286265.27741.0.nnrp-11.9e9878e0@news.demon.co.uk> References: <6au7ml$qa0@netaxs.com> <34e12c86.188611305@news.xmission.com> <887201478.12214.0.nnrp-09.9e9878e0@news.demon.co.uk> NNTP-Posting-Host: taos.demon.co.uk X-NNTP-Posting-Host: taos.demon.co.uk [158.152.120.224] Lines: 31 Path: ccw.ch!aetna.dolphins.ch!news.planetc.com!leto.ou.edu!hammer.uoregon.edu!vixen.cso.uiuc.edu!howland.erols.net!woodstock.news.demon.net!demon!news.demon.co.uk!demon!taos.demon.co.uk!!dg In article , R!ch wrote: >On Wed, 11 Feb 1998, it was written: >> BBC's had one of the fastest disk interfaces around. IIRC, it was about >> 10kB/s; at 2.5kB per track (10 sectors, 256 bytes per secotr, 40 or 80 >> tracks for those who are interested) the tracks fairly chugged past. Used >> an industry standard 1770 controller, too. The BBC Master had an 8251 and > ~~~~ >Not the orginal Beebs; these used Intel's 8271, and were like gold dust >until the 1770 became more standard in Beebs. You're absolutely right. Not only did my memory swap 1770 and 8271, but it corrupted the 7 in 8271 to boot. Now, where did I put that pin cleaner... >> The BBC's filing system --- DFS, no prizes for guessing what it stood for >> --- was incredibly simple. 31 files per disk. No fragmentation. Filenames > >31 files per side. Disc (sic) Doctor (from Watford Electronics?) >extended this to 62, by allowing you to switch between two 31 file >"catalogues". The "other" catalogue was stored in a file called >"!.!!!!!!!", IRRC. There were a number of Basic programs to do the same. As all the filing system's metadata was stored in the first to sectors of the disk, it was easy... unfortunately, since the directory also served as the allocation map, each catalogue could only access half the disk. David Given dg@freeyellow.com ###### Path: ccw.ch!usenet From: Neil.Franklin.remove.this@ccw.ch Newsgroups: alt.folklore.computers Subject: Re: CPU speeds Date: 13 Feb 1998 00:34:29 +0100 Organization: My own Private Self Lines: 97 Message-ID: <4t24l7ne.fsf@chonsp.franklin.lugs.ch> References: <6au7ml$qa0@netaxs.com> <34d837b8.0@comnet.co.nz> <34e12c86.188611305@news.xmission.com> <6bsvog$oti@nntp02.primenet.com> X-Newsreader: Gnus v5.3/Emacs 19.34 nickb@primenet.com (Nick S Bensema) wrote: > I do know that the PET had an IEEE interface, which allowed it to use > drives that were practically identical to the 1541 drives used by the > C64, but faster. One of these was the 4040, which was present on the > computer in my kindergarten class.... > The 1541 actually used the > 4040's kernel, but the transition to a single-drive system wasn't > entirely smooth... > But the 1541 itself isn't all that brain-dead. The serial bus is...at > least in its native form. The 4040 was, as you noticed, a dual drive, there was a single drive version, the 2031. When the Vic-20 came out they made the 1540 (2031 with the serial bus). The 1541 was an 1540 adapted for the C64 (but still usable on the Vic). > The problem with the IEEE bus was that it wasn't easy to make cables and > stuff like that. So, they switched to a serial cable which used a 6-pin > DIN, the kind that you can still get at any electronics store today. > This probably made its first appearance in the Vic-20, which allows > the use of most C64 devices, including disk drives, printers, cassette > drives, and modems. Same expense as with external SCSI cables today. Anyone for SSA? > Legend has it that the slowness occurs because of the Commodore 64's > design. The video chip had such high demand for memory that it had to > sneak away CPU cycles every eight scanlines to read in whatever it was > going to draw. This is no legend, just inprecise. The video chip on _every_ scan line used the entire bus bandwidth for 40us (when no sprites were in use, add 3us per sprite, max 8 of them). At ca 65us per scan line that means that the CPU nearly stopped while the picture was been drawn, it actually spent 40% of its time blocked for video DMA!!! > Since this interfered with the otherwise smooth operation > of the serial port, the disk read routines were written to read data > in a way that this wasn't an issue anymore. A much, much slower way. One bit per 4 scan lines, IIRC. The real annoyence is that both the Vic-20/C64 and the 1540/1541 had in their 6522/6526 chips unused parallel-serial converters that could have been used to do the transfer in hardware, with software only for signalling the actual bytes. This would have allowed ca 10 times highter speed without any more hardware. > Perhaps it would have been better if they had just done like they did > with the cassette player and blanked the screen during loads*. That was not possible because switching the screen off was an slow operation. IIRC, the off bit only was checked at the end of each frame draw, so that makes an avg. 1/120s (8ms) delay loop). For tape loading that was acceptable, for serial bus transactions (which may be short and many) this would be intolerable. > In theory, this might mean that a 1541 could load programs faster > on a Vic-20 than on a stock C-64; the Vic-20's primitive video > hardware doesn't need to steal CPU time. In theory? The 1541 had an undocumented "fast" (= Vic) mode, that shortened the bit delay loop. > It also explains how the > one-minute full-disk copy works: just have the disk drives send > the data to each other, without running them through the computer. > Since the 1541's each had their own processor, all you'd have to > do is send them each a small program and have them run. Strictly speaking the 1541s were not disk drives, they were file servers. The protocol was not unlike TFTP. If you look at the ".REL" index sequencial files they even were very primitive database servers. > * Actually there was a program called TurboTape available for both the > Vic-20 and the Commodore 64, from Compute's Gazette, which allowed > one to copy disk files to tape in a format that loaded slightly > faster than a stock 1541 hooked up to a Commodore 64. At least one > of the Action Replay cartridges also did this. Slightly faster? About 2/3 time. I once scared a colleague with it. "But floppies must be faster than tapes!" With TurboDisk they were again. -- Neil.Franklin.remove.this@ccw.ch, http://www.ccw.ch/Neil.Franklin/ for Geek Code, Papernet, Voicenet, PGP public key see http: Mac, 95 and NT users are CLUEless (Command Line User Environment) If I go missing, its once again my newsfeed that has craped ###### Message-ID: <34E4C5A6.3ED6@hiwaay.net> Date: Fri, 13 Feb 1998 16:13:58 -0600 From: Bob Crispen Reply-To: crispen@hiwaay.net Organization: http://hiwaay.net/~crispen/ X-Mailer: Mozilla 3.01 (Win95; I) MIME-Version: 1.0 To: Scott Brown Subject: Re: CPU speeds References: <6au7ml$qa0@netaxs.com> <34d837b8.0@comnet.co.nz> <34e12c86.188611305@news.xmission.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Newsgroups: alt.folklore.computers Lines: 24 NNTP-Posting-Host: max18-200.HiWAAY.net [208.147.149.200] Path: ccw.ch!aetna.dolphins.ch!news.planetc.com!newsfeed.usit.net!news.clark.net!europa.clark.net!205.252.116.205!howland.erols.net!logbridge.uoregon.edu!pet.hiwaay.net Scott Brown wrote: > Those C64 drives were a sick joke. My Color Computer had the same > 1MHz clock and 8-bit bus, but it would read a whole disk (180k) in a > minute or so. Ahhhh, the memories. The CoCo's disk controller solved the problem of bus contention (between the CPU and the disk controller) in a very straightforward way: it asserted HALT on the CPU (all the signals were available on the game cartridge plugin port) until it was done. I've still got that CoCo upstairs, though I haven't fired it up in a decade or so. I got a much better disk drive than the standard Radio Shack disks -- and if you want proof of that assertion, just listen to the manly CLANG as the solenoid engaged. They don't make 'em like that any more. -- Rev. Bob "Bubba Spice" Crispen crispen@hiwaay.net New experience-based course -- learn about Internet fraud! Send your credit card number today! ###### From: Clark_Geisler@nospamnortel-nsm.com (Clark Geisler) Newsgroups: alt.folklore.computers Subject: Re: CPU speeds Date: Mon, 16 Feb 1998 21:46:29 GMT Organization: Nortel Lines: 47 Distribution: world Message-ID: <6cac1s$t7m@bcrkh13.bnr.ca> References: <94064-887437472@paralynx.com> NNTP-Posting-Host: 47.223.64.209 X-Newsreader: News Xpress 2.01 Path: ccw.ch!aetna.dolphins.ch!news.planetc.com!leto.ou.edu!hammer.uoregon.edu!logbridge.uoregon.edu!news.maxwell.syr.edu!cpk-news-hub1.bbnplanet.com!denver-news-feed1.bbnplanet.com!news.bbnplanet.com!csn!nntp-xfer-1.csn.net!news.acsu.buffalo.edu!srv1.drenet.dnd.ca!crc-news.doc.ca!nott!bcarh189.bnr.ca!bmerhc5e.bnr.ca!bcrkh13.bnr.ca!cgeisler In article <94064-887437472@paralynx.com>, richard@mindlink.net (Richard Hennick) wrote: >Please pardon my probable display of profound ignorance here, but: > >In article <6btbtl$j4q@bcrkh13.bnr.ca>, Clark_Geisler@nospamnortel-nsm.com >(Clark Geisler) writes: >> >> In article <6bsp89$o55$1@nntp1.uunet.ca>, atbowler@thinkage.on.ca (Alan >> Bowler) wrote: >> >> >It was a stripped down version of the HP-IB (Hewlett Packard Instrument >> >Bus?) (IEEE-488). This originally designed as something to read/control >> >various devices (sensors, valves (the mechanical kind) etc. Using for >> >disks as Commodore did with the PET was kind of bizarre. >> >> Actually, HP themselves used HP-IB to interface most of the floppy and >> hard >> disk boxes they built to work with the computers they built in the >> 1980's. > >I *have* one of those HP computers (a 9835A), and I have the HP-IB >interface unit and cable for it, but nothing to attach it to. If I could >find one of those PET floppy drives, is there a reasonably simple way to >hook it up so the HP could use it for storage? Or were the HP disk drives >completely different in other ways? I haven't used a 9835A, but I have seen a 9825A which I suspect is similar. The hardware interface is more than likely compatible. However, the protocol used to talk to the disk drive over the HP-IB would be different. In fact, HP themselves used several different protocols over the years. On your computer, the protocol would be built into the ROMS on the interface, coupled with commands in the operating system it used (some kind of BASIC, or HPL, a language HP used before BASIC on computers like the 9825). I'm more familiar with the HP9000 series 200 (aka 9826, 9836, 9817) computers. The HP BASIC for these was called Rocky Mountain BASIC, since the HP division that made it was in Colorado. This BASIC supported at least 2 disk protocols over HP-IB that I remember: Amigo and CS80 (Command Set 80). All the disks we ever used were CS80 disks. Your best bet is to find an HP disk drive that was compatible with your computer. But I don't know which models could be used with a 9835A. -- Clark Geisler Test Engineer, Nortel, Lentronics division, Burnaby, BC, Canada * fix my e-mail address as required.