murphyjo@dekalb.UUCP (john) (03/10/89)
>Hello out there, > > My boss just purchased a C-128D for his home and has had a C-128 at the >office for some time to do a general ledger and keep up a data base of costumer >and print shipping lables for packages. I wanted to know if any one could >answer some questions we have had: > > > 1. What besides the disk drive is different on the new system(I have >read a while back in a product reveiw that the newer machine had 64K 80-col >video RAM, instead of the 16K on the older models). > > 2. What is Quantom Link and is it worth joinning??? I have read >some not so nice comments about Q-link and wanted to know 'The Rest of The >story'. > > 3. In reguards to #1(above) how can this video RAM be accesed on the >newer model. I have an assembly routine taken from Computes book on said >older model, but I want to know if the same will work on the newer model??? Hello Again, This is re-posting of my preivious acrticle, I have not seen any respopnese on the net and have not received any mail on this! I know my re- posting may upset some people, but I do need the requested info! Please tell me if this the wrong news group to submit to and I will post to the proper news group! In my original article I did fail to state that I would perfere that all respones be mailed to me, and I mail back to confirm that I recieved it and will post a summary of the responeses back here(or a better place if any- one would provide me a more proper place to post these sorts of questions)!!! Signed (actually typed) Joseph Murphy (aka murphyjo@dekalb) *------------------------------------------------------------------------------* |Joseph(Joe) B. Murphy | JOIN: | |EMAIL: murphyjo@dekalb | Math | |USMAIL: 39911 Cardinal ct. | Majors | | Tucker, GA 30084 | Against | |-----------------------------------| Deriving | | | Drunk | *------------------------------------------------------------------------------*
hermit@ssyx.ucsc.edu (William R. Ward) (03/13/89)
In article <270@dekalb.UUCP> you write: >Hello out there, > > My boss just purchased a C-128D for his home and has had a C-128 at the >office for some time to do a general ledger and keep up a data base of costumer >and print shipping lables for packages. I wanted to know if any one could >answer some questions we have had: > > 1. What besides the disk drive is different on the new system(I have >read a while back in a product reveiw that the newer machine had 64K 80-col >video RAM, instead of the 16K on the older models). The big differences are the built-in drive, detatched keyboard, and extra video RAM. It also has the "current" versions of the ROM chips, which may differ from the office C-128 slightly, but problems due to this seldom occur, and when they do, it would be because really bizarre programs need a specific version of ROM. I've never seen any problems due to this, but it is theoretically possible. > 2. What is Quantom Link and is it worth joinning??? I have read >some not so nice comments about Q-link and wanted to know 'The Rest of The >story'. QLink is, above all, a source for public domain software. It has "chat" and E-mail, but its most valuable feature is the huge public domain library available for downloading. The software is pathetic, requiring a specific disc to run on your computer, and doesn't allow many things as basic as listing the directory of your disc! But for getting that utility, SIDPlayer file, graphics demo, etc. it is a valuable resource, nonetheless. And for around $10 a month (plus extra 8c an hour for certain services) it's a good deal all in all. > 3. In reguards to #1(above) how can this video RAM be accesed on the >newer model. I have an assembly routine taken from Computes book on said >older model, but I want to know if the same will work on the newer model??? The difference between the 16K and 64K is that the 64K lets you do more. For example, there are programs (such as BASIC 8) which let you use the 64K to produce up to 960x400 or some Ghod-awful resolution in monochrome for graphics. The main advantage is 640x200 color graphics, though, and there are quite a few programs which take advantage of that. Any programs designed for the old 16K 128's will work on a 128D as far as I know. The vanilla 128 can be upgraded easily to 64K video RAM for around $50 I think. *-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-*-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-* | William R. Ward | "Delays created while you wait" | *-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-*-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-* | Internet: hermit@ssyx.ucsc.edu | UUCP: ...ucbvax!ucscc!ssyx!hermit | | Voice: (408) 688-6547 | QuantumLink: TheHermit1 | *-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-*-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-*
fred@cbmvax.UUCP (Fred Bowen) (03/13/89)
From: murphyjo@dekalb.UUCP (john): >From: izot@f171.n221.z1.FIDONET.ORG (Geoffrey Welsh): > 1. What besides the disk drive is different on the new system(I have >read a while back in a product reveiw that the newer machine had 64K 80-col >video RAM, instead of the 16K on the older models). > >> I think that's it. I have no idea why Commodore didn't put 64K video RAM >>in the first place but, then again, I have plenty of "why didn't you do that >>in the first place" questions for the designers of the C128... Yup, that's about it. There are some chip differences (32K ROMs, different DOS controller, etc.) but no new features other than more video RAM. I have plenty of "why didn't we do that" answers, BTW... > 2. What is Quantom Link and is it worth joinning??? QuantumLink (aka QLink, or just Q) is an online service that is billed as the "official" Commodore service. Whether that is still true I am unsure. Some folks like it, some do not. I don't use it for anything personal- I just answer questions there as I do here. It requires a C64 (or C64 mode of C128) and special software. > 3. In reguards to #1(above) how can this video RAM be accesed [...] ? > >> The extra video RAM can be used for more character sets, more "screens" >>(you can now page flip through video RAM in the same way some C64 "animators" >>page flip the VIC sreen through normal RAM). You can also try to play with >>high resolution screens (the expanded memory will remove the limitation that >>640 * 200 cannot be used with block colouring, etc.) although I am told that >>there is a bug in the VDC that prevents interlace and hi-res modes from being >>used at the same time (more's the pity, because that would allow 640 * 400 and >>perhaps slightly higher resolutions). >> >> I am told that a package called BASIC 8 will take advantage of the extra >>VDC RAM (I believe it supports hires graphics for the 80-column screen). Geoffrey's discription (deleted) was good, but the info above is incorrect. Interlaced screen resolutions up to 640x600 (that's six full Doodle screens complete with color) are possible. BASIC-8 is probably the most popular software available in the US for accessing the graphic modes of the 8563 (RGBI video chip)- BASIC-8 is, as its name suggests, an extension to the built-in C128 graphical BASIC commands. It's available from Briwall (800-638-5757). Examples of C128D interlaced and overscan screens have been published in TC128, and are available on QLink, GEnie, and probably elsewhere. -- -- Fred Bowen uucp: {uunet|rutgers|pyramid}!cbmvax!fred arpa: cbmvax!fred@uunet.uu.net tele: 215 431-9100 Commodore Electronics, Ltd., 1200 Wilson Drive, West Chester, PA, 19380
izot@f171.n221.z1.FIDONET.ORG (Geoffrey Welsh) (03/14/89)
> From: fred@cbmvax.UUCP (Fred Bowen) > Message-ID: <6222@cbmvax.UUCP> >>I have plenty of "why didn't you do that >>in the first place" questions for the designers of the C128... > >I have plenty of "why didn't we do that" answers, BTW... Gee, this could be interesting. (1) Why didn't the C128 include 64K video RAM from the beginning? Considering that the VDC was designed to handle 2 4416s or 8 4164s (but has also proved workable with 2 4464s), it seemed the logical thing to do... (2) Given that the 128's MMU could handle FOUR 64K banks of memory, why was that capability not used? 41256s were a commodity chip at the time and I find it difficult to believe that Commodore was afraid that the C64 wouldn't clear out its inventories of 4164s... (3) I find it incredibly amusing that the Z80 runs at an effective 2 MHz even though the VIC-II is enabled because it runs 4 MHz, 2 cycles on and 2 off. Would producing a 4 MHz 8502 have ben so expensive that a similar scheme could not have been used to allow 128 mode to support 2 MHz, even in 40-column mode? Better yet, why does there not seem to be a way to shut doen the VIC-II chip in CP/M mode and run the Z80 flat out at 4 MHz (Jeez, it would have been nice to do that in C128 mode as well)... > Geoffrey's discription (deleted) was good, but the info above is > incorrect. Interlaced screen resolutions up to 640x600 (that's six > full Doodle screens complete with color) are possible. That's what I thought from reading the VDC specs, but I wasn't able to achieve it. Since I am not a video specialist (that is probably the area where I lack experience most), I figured at first that it was me. However, I have been told by several people (including a fellow named Jeff Solomon, who claims to be a "Commodore rep") that there is a bug in the VDC that prevents bitmap and interlace modes from being enabled at the same time. > Examples of > C128D interlaced and overscan screens have been published in TC128, > and are available on QLink, GEnie, and probably elsewhere. Well, it's been years since I realized that QLink and GEnie, while good fun, simply cost way too damned much (same for Compu$erve). I never subscribed to TC128 (more's the pity... I really enjoyed the Transactor). Thanks for the info, Fred. ============================================================================ Usenet: watmath!isishq!izot | 66 Mooregate Crescent Internet: Geoffrey.Welsh@f171.n221.z1.fidonet.org | Suite 602 FidoNet: Geoffrey Welsh on 1:221/171 | Kitchener, Ontario PunterNet: 7/GEOFFREY WELSH | N2M 5E6 CANADA BBS: (519) 742-8939 24h/7d 9600 USRobotics HST | (519) 741-9553 ============================================================================ | "I don't need a disclaimer. No one pays any attention to what I say." | ============================================================================ -- Geoffrey Welsh - via FidoNet node 1:221/162 UUCP: ...!watmath!isishq!171!izot Internet: izot@f171.n221.z1.FIDONET.ORG
leblanc@eecg.toronto.edu (Marcel LeBlanc) (03/21/89)
In article <1856.2423BC06@isishq.FIDONET.ORG> izot@f171.n221.z1.FIDONET.ORG (Geoffrey Welsh) writes: > > > From: fred@cbmvax.UUCP (Fred Bowen) > > Message-ID: <6222@cbmvax.UUCP> > > >>I have plenty of "why didn't you do that > >>in the first place" questions for the designers of the C128... > > > >I have plenty of "why didn't we do that" answers, BTW... ... >(3) I find it incredibly amusing that the Z80 runs at an effective 2 MHz even >though the VIC-II is enabled because it runs 4 MHz, 2 cycles on and 2 off. >Would producing a 4 MHz 8502 have ben so expensive that a similar scheme could >not have been used to allow 128 mode to support 2 MHz, even in 40-column mode? >Better yet, why does there not seem to be a way to shut doen the VIC-II chip >in CP/M mode and run the Z80 flat out at 4 MHz (Jeez, it would have been nice >to do that in C128 mode as well)... I'm not sure of exactly what it is you're trying to say, but it looks like you're equating MHz on 8502 with MHz on Z80, which is completely false. A 2Mhz 6502 is (almost) 4 times faster than a 2Mhz Z80. This is because memory (or IO) accesses on a Z80 take 3-4 cycles, whereas the same operation on a 6502 takes only one cycle (yes, the 6502 was an early RISC :-) ). So even if you could get the Z80 to run flat out at 4MHz, it would still be only a little more than half the speed of the 8502 at 2MHz. But then, I guess CP/M can use all the speed it can get... Marcel A. LeBlanc | University of Toronto -- Toronto, Canada leblanc@eecg.toronto.edu | also: LMS Technologies Ltd, Fredericton, NB, Canada ------------------------------------------------------------------------------- UUCP: uunet!utai!eecg!leblanc BITNET: leblanc@eecg.utoronto (may work) ARPA: leblanc%eecg.toronto.edu@relay.cs.net CDNNET: <...>.toronto.cdn
fred@cbmvax.UUCP (Fred Bowen) (03/22/89)
Hindsight is 20-20, of course... but 4 years ago we had a very tight schedule (less than a year for a new system, OS, several new custom chips, new peripherals (REUs, 1571), etc.) and a very strict cost target. Some folks call it amusing, some call it a nightmare, and some call it the best 8-bit system built. From my perspective, no machine is ever "finished." Unfortunately, whatever system is at hand when the window of opportunity opens is what you get- just a slice of its evolution. In article <1856.2423BC06@isishq.FIDONET.ORG> (Geoffrey Welsh) writes: >(1) Why didn't the C128 include 64K video RAM from the beginning? Considering >that the VDC was designed to handle 2 4416s or 8 4164s (but has also proved >workable with 2 4464s), it seemed the logical thing to do... When production was first ramping up, indeed the 8563 had problems with bitmap screens- hell, it could not even do text screens right. The system ROMs were release before I had bug-free silicon (hence some "workaround" code still exists in the Kernel). In fact, the product specification called for 80-column text only, using a 6845 (which was always our fallback if the 8563 was not working in time. Incidentally, the 8563 was to be used for text on both the C128 and the C900). By the time the C128 was released to production, the bugs had been worked out of the 8563 but nothing was done to test the functionality of the bit map modes since they were not part of the product spec. Coupled with the lack of graphic support in the OS, 16K was more than enough video RAM for text support and kept the cost closer to target. Why 80-column text at all? The C128 was a sort of "joining" of the C64 and PET/8032/B-series lines. >(2) Given that the 128's MMU could handle FOUR 64K banks of memory, why was >that capability not used? 41256s were a commodity chip at the time and I find >it difficult to believe that Commodore was afraid that the C64 wouldn't clear >out its inventories of 4164s... A 256K machine was part of the original plan, as evidenced by the MMU documentation and provisions in the operating system, but the system was already beyond the target cost. Hence the shift to expandability via the REUs. In my opinion this is better in most repects anyway; the performance of the DMA device gives the system a real kick. One of the chief problems of the C128 is the banking via the MMU- it's slow and awkward. The current MMU does not support 256K- a revision to the chip would be necessary, although a prototype C256 was built (I have it :-). >(3) I find it incredibly amusing that the Z80 runs at an effective 2 MHz even >though the VIC-II is enabled because it runs 4 MHz, 2 cycles on and 2 off. >Would producing a 4 MHz 8502 have ben so expensive that a similar scheme could >not have been used to allow 128 mode to support 2 MHz, even in 40-column mode? >Better yet, why does there not seem to be a way to shut doen the VIC-II chip >in CP/M mode and run the Z80 flat out at 4 MHz (Jeez, it would have been nice >to do that in C128 mode as well)... You don't understand the bus interface at all. The "shared bus" is the very heart of the VIC video processor. Furthermore, a Z80 bus cycle is much different from a 65xx family bus cycle, especially its interface to the data bus (the Z80 actually does run during the VIC cycle (AEC low) but the data bus interfaces with it only during AEC high). In 2MHz mode, the VIC is removed from the system, and can devote the full clock cycle to the processor. So your idea is not without merit- and in fact a prototype with a 4MHz Z80 was built (I have that one, too :-). > >Interlaced screen resolutions up to 640x600 (that's six full Doodle screens > > complete with color) are possible. > That's what I thought from reading the VDC specs, but I wasn't able to >achieve it. Since I am not a video specialist (that is probably the area where >I lack experience most), I figured at first that it was me. However, I have >been told by several people (including a fellow named Jeff Solomon, who claims >to be a "Commodore rep") that there is a bug in the VDC that prevents bitmap >and interlace modes from being enabled at the same time. The "bug" was in the 8563's designer's docs, not in the chip. As soon as I had the chance to add more video memory (the US version of the C128D), I did. Still could not add the extra banks of memory, faster processors, ACIA, etc. though. Even lost the damn fan (but I kept the vents & mounting holes for ya). I even extended BASIC 7.0 graphic commands to support the 8563 bit map mode, but could not get the okay to release them (yes, I have that system too, which also happens to have a built-in ACIA :-). > Thanks for the info, Fred. You're welcome. -- -- Fred Bowen uucp: {uunet|rutgers|pyramid}!cbmvax!fred arpa: cbmvax!fred@uunet.uu.net tele: 215 431-9100 Commodore Electronics, Ltd., 1200 Wilson Drive, West Chester, PA, 19380
elg@killer.Dallas.TX.US (Eric Green) (03/22/89)
in article <1856.2423BC06@isishq.FIDONET.ORG>, izot@f171.n221.z1.FIDONET.ORG (Geoffrey Welsh) says: > (1) Why didn't the C128 include 64K video RAM from the beginning? Considering > that the VDC was designed to handle 2 4416s or 8 4164s (but has also proved > workable with 2 4464s), it seemed the logical thing to do... 4416s were around $6 apiece on the consumer market at the time. 4464s were about $40 at the time (remember, this was when 256k DRAMs were new). > (2) Given that the 128's MMU could handle FOUR 64K banks of memory, why was > that capability not used? 41256s were a commodity chip at the time See above. Plus, the continuing shortage of 41256's is yet another disincentive. However, I have another pet peeve: Even if you put 256K of RAM into your Commodore 128, the system software, and BASIC in particular, is set up only to access 128Kb of RAM. > achieve it. Since I am not a video specialist (that is probably the area where > I lack experience most), I figured at first that it was me. However, I have > been told by several people (including a fellow named Jeff Solomon, who claims > to be a "Commodore rep") that there is a bug in the VDC that prevents bitmap > and interlace modes from being enabled at the same time. I have a program and several pics that use the 640x600 display. I suspect it'd look great on a multisync monitor. Alas, all I had available was an old CGA monitor borrowed from my brother's office.... Call it an existence proof, in any event, that it IS possible. BTW, I upgraded my C128 to 64K of video RAM simply by popping the darmned things in there. Seems to work, although perhaps in normal operation the computer thinks it only has 16K of video RAM. However, if so, programs which take advantage of the added RAM seem to detect it and re-init into 64K mode, so that wasn't a problem. > FidoNet: Geoffrey Welsh on 1:221/171 | Kitchener, Ontario -- | // Eric Lee Green P.O. Box 92191, Lafayette, LA 70509 | | // ..!{ames,decwrl,mit-eddie,osu-cis}!killer!elg (318)989-9849 | | \X/ Amiga. The homestation for the blessed of us. |
elg@killer.Dallas.TX.US (Eric Green) (03/22/89)
in article <89Mar20.194245est.2737@godzilla.eecg.toronto.edu>, leblanc@eecg.toronto.edu (Marcel LeBlanc) says: > > 2Mhz 6502 is (almost) 4 times faster than a 2Mhz Z80. This is because > memory (or IO) accesses on a Z80 take 3-4 cycles, whereas the same operation > on a 6502 takes only one cycle (yes, the 6502 was an early RISC :-) ). So > even if you could get the Z80 to run flat out at 4MHz, it would still be > only a little more than half the speed of the 8502 at 2MHz. But then, I > guess CP/M can use all the speed it can get... Actually, it's not that simple. Yes, memory access takes 4 cycles on the Z-80, making actual data fetch of a 4mhz Z-80 about the same as a 1mhz 6502. But the Z-80 has 16-bit registers, and has a LOT of registers (at least, when compared to having a whole 3 8-bit registers!) This means that you don't have to go to memory as often, and can more easily do 16-bit arithmetic and do 16-bit indirect addressing. This is one reason you'll find better, e.g., Pascal compilers on a CP/M machine, than on a C-64. I've used Turbo Pascal on a CP/M machine, and it makes any Pascal on the 64 look sad, insofar as code size & speed is concerned. Same with BDS "C" vs. Power C. I don't have a Z-80 manual lying around (I'm not ancient enough ;-), but I also suspect that a 4mhz Z-80 takes less time for internal processing than a 1mhz 6502. e.g. moving B to A may require less time than moving .X to .A on 6502. I explored the 128's CP/M mode some time ago, right after getting my 1750 (it wasn't worth it with a 1571 and a 1541 as the only two of my drives that it'd access). There are text editors under CP/M that make anything under 128 or 64 mode look pitiful. Not to mention that you can probably still get pirate copies of DBASE and WORDSTAR ;-). Unfortunately, screen update is MUCH too slow for it to be useful. There seems to have been a design decision, somewhere in the software cycle, to switch into 6502 mode and use the Kernal for all I/O. I suspect this is responsible for the drastic slow-down... if the Z-80 was handling all its own screen and modem i/o, that'd solve the two biggest problems of the 128's CP/M mode. (and, BTW, there is a program available to turn off the 40 column screen -- it does speed up compute-bound programs, but does little to speed up slow I/O operations). I solved the screen i/o problem by buying an Amiga ;-). But if anybody out there has any CP/M experience, I'd be quite interested in seeing the results of a hacked CP/M that did its own screen i/o instead of punting to the 6502.... -- | // Eric Lee Green P.O. Box 92191, Lafayette, LA 70509 | | // ..!{ames,decwrl,mit-eddie,osu-cis}!killer!elg (318)989-9849 | | \X/ Amiga. The homestation for the blessed of us. |
izot@f171.n221.z1.FIDONET.ORG (Geoffrey Welsh) (03/22/89)
> From: leblanc@eecg.toronto.edu (Marcel LeBlanc) > Message-ID: <89Mar20.194245est.2737@godzilla.eecg.toronto.edu> > I'm not sure of exactly what it is you're trying to say, but it looks like > you're equating MHz on 8502 with MHz on Z80, which is completely false. A > 2Mhz 6502 is (almost) 4 times faster than a 2Mhz Z80. This is because > memory (or IO) accesses on a Z80 take 3-4 cycles, whereas the same > operation > on a 6502 takes only one cycle (yes, the 6502 was an early RISC :-) ). So > even if you could get the Z80 to run flat out at 4MHz, it would still be > only a little more than half the speed of the 8502 at 2MHz. Marcel, you miss the points that (a) the circuitry in the machine existed to allow the 8502 to run 2 MHz in 40-column as well as 80-column mode, without blanking the screen; (b) failing that, the circuitry existed in the machine to make the Z80 run 4 MHz at all times (in stead of 2 cycles on, 2 off) when the 40-column screen was disabled. Geoff ( watmath!isishq!izot ) -- Geoffrey Welsh - via FidoNet node 1:221/162 UUCP: ...!watmath!isishq!171!izot Internet: izot@f171.n221.z1.FIDONET.ORG
dwl10@uts.amdahl.com (Dave Lowrey) (03/22/89)
In article <7605@killer.Dallas.TX.US> elg@killer.Dallas.TX.US (Eric Green) writes: > >BTW, I upgraded my C128 to 64K of video RAM simply by popping the >darmned things in there. Seems to work, although perhaps in normal >operation the computer thinks it only has 16K of video RAM. However, >if so, programs which take advantage of the added RAM seem to detect >it and re-init into 64K mode, so that wasn't a problem. > Which programs use expanded video memory? -- ------------------------------------------------------------------- "This isn't Heaven, this is Cleveland!!!!" Dave Lowrey Amdahl Corp. Houston, Texas (713)-850-8828 ...!{ames,sun,decwrl,uunet,....}!amdahl!dwl10 [ The opinions expressed <may> be those of the author and not necessarily those of his most eminent employer. ]
izot@f171.n221.z1.FIDONET.ORG (Geoffrey Welsh) (03/23/89)
> From: fred@cbmvax.UUCP (Fred Bowen) > Message-ID: <6358@cbmvax.UUCP> > You don't understand the bus interface at all. Marcel at least threw a "perhaps" in his version of that statement to be polite (Bv>). Actually, I AM familiar with Intel vs. 6800-type buses and it had slipped my mind that the Z80 would need partially set up bus cycles to be preserved for its next cycle (which cannot happen if the VIC is using the same circuitry). > (yes, I have that system too, It seems you have a lot of prototype systems. I've really seen only one non-production machine (i.e. one-off/prototype), and that is Keith Hope's HyperPET (a 4 MHz 4032 with 40K RAM)... Keith would love to do an 8 MHz version, too, but he's unwilling to pay for it and I'm not that much of a sucker. (I'd love the conversation piece but its cost far outstrips its usefulness). A couple prototype-looking REUs (circuit board with modifications, no cases) passed through my hands, mostly while I was alpha testing/suggesting PaperClip II for Steve Douglas and BI. One, lent to Steve Punter, was wire-wrapped and in a sealed pastic case! > which also happens to have a built-in ACIA :-). Yeah, I guess that's be nice (though hardly necessary with the advancing state of the art in software RS-232 drivers (Bv>) Speaking of which, shall we send you a copy of DesTerm, our 80-column, 50-line, 9600-bps, ANSI/VT-100, windowed terminal program? <plug> <plug> Geoff ============================================================================ Usenet: watmath!isishq!izot | 66 Mooregate Crescent Internet: Geoffrey.Welsh@f171.n221.z1.fidonet.org | Suite 602 FidoNet: Geoffrey Welsh on 1:221/171 | Kitchener, Ontario PunterNet: 7/GEOFFREY WELSH | N2M 5E6 CANADA BBS: (519) 742-8939 24h/7d 9600 USRobotics HST | (519) 741-9553 ============================================================================ | "I don't need a disclaimer. No one pays any attention to what I say." | ============================================================================ -- Geoffrey Welsh - via FidoNet node 1:221/162 UUCP: ...!watmath!isishq!171!izot Internet: izot@f171.n221.z1.FIDONET.ORG
brendan@jolnet.ORPK.IL.US (Brendan Kehoe) (03/23/89)
So, Fred..how receptive are you to pleas for LIVING in your house? It sounds like you've got every hobbyist's dream hooked up in there. Can we talk U-Haul? -- Brendan Kehoe brendan@cup.portal.com | GEnie: B.KEHOE | Oh no! I forgot to say goodbye brendan@chinet.chi.il.us | CI$: 71750,2501 | to my mind! brendan@jolnet.orpk.il.us | Galaxy: Brendan | - Abby Normal
bjskelly@pbhye.PacBell.COM (Bruce J. Skelly) (03/23/89)
In article <89Mar20.194245est.2737@godzilla.eecg.toronto.edu>, leblanc@eecg.toronto.edu (Marcel LeBlanc) says: > > 2Mhz 6502 is (almost) 4 times faster than a 2Mhz Z80. This is because > memory (or IO) accesses on a Z80 take 3-4 cycles, whereas the same operation > on a 6502 takes only one cycle (yes, the 6502 was an early RISC :-) ). So > even if you could get the Z80 to run flat out at 4MHz, it would still be > only a little more than half the speed of the 8502 at 2MHz. But then, I > guess CP/M can use all the speed it can get... > I don't want to start a 'my cpu is better than your cpu' war here, after all those of us with C128 have them both, but I have this benchmark report on the Z80 cpu vs. the 6502 cpu published by Zilog in July of 1981. They performed 10 tests: Computed GOTO Implementation 8 X 8 Multiply Routine 16 X 16 Multiply Routine Block Move Linear Search Insert into Linked List Bubble Sort Interrupt Handling Character String Translation Dynamic Memory Access They included their program listings. Results were expressed as a ratio. 6502/Z80 Number of Bytes of Code 2.63/1 Number of Lines of Source 3.05/1 Execution time of slowest 1.65/1* Execution time of equal 1.32/1** * Slowest means lowest speed version, which for the 6502 is 1.0 MHz with a memory access time of 650ns., and 2.5 MHz and 575ns for the Z80. ** Equal means equivalent memory access time. For the 6502B at 3.0 MHz that was 170ns., while for the Z80B at 6.0Mhz it was 190ns. Is there a trick involved here? Could be. More importantly, does anyone care? I'm sure that those who love their 6502's will continue to love them, and those that love there Z80's will go to bed with warm smiles on their faces. For those who distrust me it was publication #751-1955-0002 dated 6/12/81 Bruce
izot@f171.n221.z1.FIDONET.ORG (Geoffrey Welsh) (03/23/89)
> From: elg@killer.Dallas.TX.US (Eric Green) > Message-ID: <7606@killer.Dallas.TX.US> > I don't have a Z-80 manual lying around (I'm not ancient enough ;-), > but I also suspect that a 4mhz Z-80 takes less time for internal > processing than a 1mhz 6502. e.g. moving B to A may require less time > than moving .X to .A on 6502. Argh. My Z80 manual is in Toronto and I'm in Kitchener. However, I do have a comparison chart handy that gives execution times for an 8-bit immediate add to accumulator: Processor Op Code Cycles Speed Time ---------- ----------- ------- ------- ----- 6502 ADC # 2 2 MHz 1 us 6800 ADCA # 2 2 MHz 1 us 8085a ACI # 7 5 MHz 1.4 us Z80A ADC A,# 7 4 MHz 1.75 us From this table, I can conclude that you're probably better off using the 128's 2 MHz 6502 than its Z80. I should also mention the 6809 here. It offers 16-bit registers (accumulator, two index registers, user & system stack pointers), a direct page register (to move zero page around, as is possible with the 128's MMU), and an 8 bit by 8 bit unsigned multiply that takes 11 clock cycles! I've heard that OS/9 is a Unix-style operating system for the 6809... if so, I'm not surprised, considering that the 6809 deserves the title "16-bit" almost as much as the 8088 does, and its design is much more efficient. > There seems to have been a design decision, somewhere in the software > cycle, to switch into 6502 mode and use the Kernal for all I/O. Makes the BIOS ROM shorter and saves time re-inventing the wheel. > if the Z-80 > was handling all its own screen and modem i/o, that'd solve the two > biggest problems of the 128's CP/M mode. Miklos Garamzeghy has published a C128 CP/M disk I/O toolkit. Admittedly, RS-232 would be faster if it didn't have to "spawn" a processor switch at every interrupt. Fred: would VDC DMA work with the Z80 controlling the bus? > (and, BTW, there is a > program available to turn off the 40 column screen -- it does speed up > compute-bound programs, but does little to speed up slow I/O > operations). THAT sounds interesting! > I solved the screen i/o problem by buying an Amiga ;-). Problem NOT solved. Have you ever tried scrolling a 16-colour screen at 9600 bps? EVen an 8-colour? The time lag between the scrolling of bitplanes smears the characters badly (they're often unreadable) and, even with Agnus doing the hard work, I have yet to see an Amiga terminal that won't eventually lose characters when scrolling at 9600 bps (our C128 terminal program doesn't... does that indicate that a 2 MHz 6502 with DMA video memory makes a faster terminal than an 8 MHz 68000 with custom graphics coprocessor?) ============================================================================ Usenet: watmath!isishq!izot | 66 Mooregate Crescent Internet: Geoffrey.Welsh@f171.n221.z1.fidonet.org | Suite 602 FidoNet: Geoffrey Welsh on 1:221/171 | Kitchener, Ontario PunterNet: 7/GEOFFREY WELSH | N2M 5E6 CANADA BBS: (519) 742-8939 24h/7d 9600 USRobotics HST | (519) 741-9553 ============================================================================ | "I don't need a disclaimer. No one pays any attention to what I say." | ============================================================================ -- Geoffrey Welsh - via FidoNet node 1:221/162 UUCP: ...!watmath!isishq!171!izot Internet: izot@f171.n221.z1.FIDONET.ORG
elg@killer.Dallas.TX.US (Eric Green) (03/27/89)
in article <1896.24298458@isishq.FIDONET.ORG>, izot@f171.n221.z1.FIDONET.ORG (Geoffrey Welsh) says: > From this table, I can conclude that you're probably better off using the > 128's 2 MHz 6502 than its Z80. For disk i/o, yes, I can see that. One processor-switch for 128 bytes is not excessive overhead. Besides, the Commodore disk routines work via voodoo and glue, and have been so hacked over the years that I doubt you could implement them on another processor without special hardware (e.g. a 6526's serial register to clock data in & out). For modem and screen i/o, though, the overhead of the processor-switch is way too slow. Especially for modem i/o. > I should also mention the 6809 here. It offers 16-bit registers > (accumulator, two index registers, user & system stack pointers), a direct > page register (to move zero page around, as is possible with the 128's MMU), I love the 6809. Ever since I bought a surplus 6809 book from a defunct SuperPet dealer, I've wanted to put together something that used one. The 6809, Forth, and real-time operation go together like macaroni & cheese or cereal & milk. However, it simply cannot compare with the 68000 as a systems-oriented device, due to the 16-bit addresses. (but it's such a pleasant-to-program device that I intend to use it for any imbedded applications I find, even if there ARE more space-efficient solutions). > Miklos Garamzeghy has published a C128 CP/M disk I/O toolkit. Admittedly, > RS-232 would be faster if it didn't have to "spawn" a processor switch at > every interrupt. Fred: would VDC DMA work with the Z80 controlling the bus? The VDC doesn't have DMA in the first place, except internally on its own isolated bus -- which could care less whether the 6502 or Z-80 is controlling. > > I solved the screen i/o problem by buying an Amiga ;-). > > Problem NOT solved. Have you ever tried scrolling a 16-colour screen at > 9600 bps? EVen an 8-colour? The time lag between the scrolling of A 16-color screen uses a large chunk of the Amiga's video DMA time, leaving little for the blitter to operate in. If you're doing interlace as well as 16 colors, video DMA even cuts into CPU time, slowing things down even more. With a 4-color screen there is no hardware reason for slow scrolling, though. Two 16-K blits should occur almost instantaneously. The main reason for slow scrolling in commercial terminal programs is that I have never seen a commercial terminal program worth a bucket of warm spit -- whether for Amiga, C-64, C-128, or whathaveyou. Most Amiga term programs use the console.device for their terminal output, which does NOT seem to be particularly speedy. I might note that the VDC in the C-128 only has to block-move a whole 2K of RAM to scroll the screen. I suspect the VDC would have no trouble keeping up with 19,200 baud or even 32kbaud -- although the rest of the computer probably would get pretty stressed out at 32kbaud (my brother says 19.2kbaud with a real ACIA sucks up about half the CPU power of a stock C-64, so I guess 32kbaud would do the same for the 128). If I was going to build a terminal... the VDC is such a natural for such an application, it's a shame that Commodore will never release it onto the consumer marketplace. > Geoffrey Welsh - via FidoNet node 1:221/162 > UUCP: ...!watmath!isishq!171!izot
izot@f171.n221.z1.FIDONET.ORG (Geoffrey Welsh) (03/28/89)
> From: elg@killer.Dallas.TX.US (Eric Green) > Message-ID: <7664@killer.Dallas.TX.US> > is not excessive overhead. Besides, the Commodore disk routines work > via voodoo and glue, and have been so hacked over the years that I > doubt you could implement them on another processor without special > hardware (e.g. a 6526's serial register to clock data in & out). Let's not forget that the Z80 does have full access to the I/O chips. > For modem and screen i/o, though, the overhead of the processor-switch > is way too slow. Especially for modem i/o. I have to agree with you there. While writing my fast RS-232 drivers, one of the key matters was interrupt reaction time. Processor switching would add too much to that. > I love the 6809. Ever since I bought a surplus 6809 book from a > defunct SuperPet dealer, I've wanted to put together something that > used one. I'd actually like to throw a very fast 6809-based system myself. Nothing designed to topple the current 386 or workstation market, mind you, just something to impress on people the power of 8-bit systems. I'd want to include a DMA processor and an ST-412 interface for hard drive(s), perhaps half a meg of RAM (bank-switched), OS/9 operating system? > With a 4-color screen there is no hardware reason for slow scrolling, > though. Two 16-K blits should occur almost instantaneously. There is "should", and there is "does". > The main > reason for slow scrolling in commercial terminal programs is that I > have never seen a commercial terminal program worth a bucket of warm > spit -- whether for Amiga, C-64, C-128, or whathaveyou. Most Amiga > term programs use the console.device for their terminal output, which > does NOT seem to be particularly speedy. That's more or less what we told Commodore Canada when we showed them DesTerm 128 and said we wanted developer status because we were thinking of doing something similar for the Amiga. They accepted our application quickly (I guess we weren't just a couple of clowns, we were a couple of clowns with some impressive software). I'll bet that, if you saw DesTerm running 16-colour ANSI at 9600 bps, you would at least reconsider the "... worth a bucket of warm spit" phrase. > I might note that the VDC in the C-128 only has to block-move a whole > 2K of RAM to scroll the screen. Because all of Matt's screen stuff is done through generic windowing routines, lines are moved one at a time. > I suspect the VDC would have no > trouble keeping up with 19,200 baud or even 32kbaud -- although the > rest of the computer probably would get pretty stressed out at 32kbaud > (my brother says 19.2kbaud with a real ACIA sucks up about half the > CPU power of a stock C-64, so I guess 32kbaud would do the same for > the 128). If I was going to build a terminal... the VDC is such a > natural for such an application, it's a shame that Commodore will > never release it onto the consumer marketplace. I did some experiments with software RS-232 drivers at high speeds. While 19,200 is definitely attainable without a UART, the code generated occasional errors at 38,400 and that leads me to conclude that a C128 will not soon be running 38,400 without additional hardware. However, my opinion that 19,200 bps is practical in software on a C128 suggests that 9600 should be fairly easy on a C64 without a UART or ACIA. Based on that, I can't help but wonder why 19,200 (twice the speed) would cause problems on a C64 with an ACIA (which reduces overhead by as much as a factor of ten)... -- Geoffrey Welsh - via FidoNet node 1:221/162 UUCP: ...!watmath!isishq!171!izot Internet: izot@f171.n221.z1.FIDONET.ORG
elg@killer.Dallas.TX.US (Eric Green) (04/02/89)
in article <1935.2432C063@isishq.FIDONET.ORG>, izot@f171.n221.z1.FIDONET.ORG (Geoffrey Welsh) says: > > I suspect the VDC would have no > > trouble keeping up with 19,200 baud or even 32kbaud -- although the > > rest of the computer probably would get pretty stressed out at 32kbaud > >. If I was going to build a terminal... the VDC is such a > > natural for such an application, it's a shame that Commodore will > > never release it onto the consumer marketplace. > > Based on that, I can't help but wonder why 19,200 (twice the speed) would > cause problems on a C64 with an ACIA (which reduces overhead by as much as a > factor of ten)... 19,200 is only 1920 interrupts per second. That's not the problem, especially since the NMI's for the ACIA are only about 80-100 cycles. I don't know why my brother said it used so much, except that I assume he was talking about the Kernal and screen display overhead. Also note that his driver software had to do lots of compatiblity sniffing to see if the baud rate had been changed under his nose -- he patched all the RS232 routines in the Kernal, and jumpered over all the modem control lines from the user port, but most software still insists upon poking its RS232 baud rate into low RAM (and elsewhere -- but the elsewhere doesn't much matter). The VDC helps one problem (slow scrolling) by having its own hardware block move command. I'd give the card a twirl, except that he already tore down his prototype. He's not such a great wire-wrapper. So of course when it started glitching he recruited me to re-wrap it (and clean up the drivers, and ... ;-). (maybe I'll get to it before summer, but I doubt it... my priorities are clear -- classwork comes first). -- | // Eric Lee Green P.O. Box 92191, Lafayette, LA 70509 | | // ..!{ames,decwrl,mit-eddie,osu-cis}!killer!elg (318)989-9849 | | \X/ Amiga. The homestation for the blessed of us. |