David.Plummer@f70.n140.z1.FIDONET.ORG (David Plummer) (12/20/90)
I was wondering about two older Commodore machines that I saw/have promo literature for but never actually saw the machines. The first is the Commodore 128PC LCD Laptop (did this ever make it to market?) The second is a little more obtuse: sometime between the SuperPET era and the Amiga (a wide time slice, to be sure) there were rumours of some "Z machine" that would multitask and a bunch of other stuff. It couldn't have been the amiga though, I think it was too early. I don't think it became the 128 (obviously). Anyone ever heard of it, or have any idea what I'm talking about? While I'm on the nostalgia kick: Correct me if I'm wrong, (I likely am), but wasn't one of Dave Haynie's original projects the 128? If so, (or even if not), would it have been possible to include an 8088 instead of a Z80? Was it a technical problem or purely cost? Or even bad judgement? Imagine the software base! C64 and PC! A toss-up to decide which would be the more powerful mode :-)... -- David Plummer - via FidoNet node 1:140/22 UUCP: ...!herald!weyr!70!David.Plummer Domain: David.Plummer@f70.n140.z1.FIDONET.ORG Standard Disclaimers Apply...
erickson@alee.UUCP (Lee Erickson) (12/22/90)
>In article <1029.2772FECD@weyr.FIDONET.ORG> David.Plummer@f70.n140.z1.FIDONET.ORG >(David Plummer) writes: >I was wondering about two older Commodore machines that I saw/have promo >literature for but never actually saw the machines. The first is the >Commodore 128PC LCD Laptop (did this ever make it to market?) No, it never got to market. >The second is a little more obtuse: sometime between the SuperPET era >and the Amiga (a wide time slice, to be sure) there were rumours of some >"Z machine" that would multitask and a bunch of other stuff. I never heard it called the "Z machine", but Commodore did develop a machine called the "C900". It was based on the Zilog Z8000 processor, with MMU. At least 500 of one design were made (to distribute to software developers). It ran a version of the Coherent OS. 10 of a better design were made, and Zilog's ZEUS implementation of System V was ported to it. Both of these machines were "ready" about the same time the Amiga was "ready". Commodore was reporting big losses, and these worthwile machines lost out. -- Lee Erickson uucp: ...{rutgers|uunet}!cbmvax!alee!erickson Working for but NOT ...!psuvax1!burdvax!gvlv2!lock60!alee!erickson representing internet: erickson%alee@canal.org InnovaSystems, Inc. usmail: 720 Raynham Rd., Collegeville PA 19426
kdarling@hobbes.ncsu.edu (Kevin Darling) (12/23/90)
David.Plummer@f70.n140.z1.FIDONET.ORG (David Plummer) writes: >The second is a little more obtuse: sometime between the SuperPET era >and the Amiga (a wide time slice, to be sure) there were rumours of some >"Z machine" that would multitask and a bunch of other stuff. I know it wasn't this, but people ran (and still run) OS-9 on that early 6809 CBM machine (was that the SuperPET? or another name?). I'm not sure when the port was done tho, but it might actually have been the first CBM multitasking computer available :-). kevin <kdarling@catt.ncsu.edu> (guest account)
vinsci@nic.funet.fi (Leonard Norrgard) (12/28/90)
>I'm not sure when the port was done tho, but it might actually have >been the first CBM multitasking computer available :-). I seem to remember there was an old hack to run multiple basic programs simultaneously on the PET. It wasn't really useful due to the slowness, but still ;-). Anyone have a better moemory of this? >kevin <kdarling@catt.ncsu.edu> (guest account) -- Leonard
xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (12/28/90)
vinsci@nic.funet.fi (Leonard Norrgard) writes: >>kevin <kdarling@catt.ncsu.edu> (guest account) writes: >>I'm not sure when the port was done tho, but it might actually have >>been the first CBM multitasking computer available :-). >I seem to remember there was an old hack to run multiple basic >programs simultaneously on the PET. It wasn't really useful due to the >slowness, but still ;-). Anyone have a better moemory of this? Not too sure it is fair to characterize the Pet as slow; I saw several collecting seven to nine simultaneous reasonably high speed channels of meteorological data each during a big weather project I was part of in 1981 (computer operator and ship jockey). The folks running the show confirmed that they were doing the collecting using BASIC, though I wasn't sophisticated enough about BASIC in those days to ask if they were running an assembly kernel in there somewhere. The Pets had replaced multimillion dollar special hardware used for the same purpose in 1974. On the other hand, dumping text to the screen from BASIC was painfully slow, even for those days. Perhaps that is where the perception of a slow BASIC arose. Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>
kdarling@hobbes.ncsu.edu (Kevin Darling) (12/28/90)
In <1990Dec28.001940.25138@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: >[interesting stuff about PETs] >On the other hand, dumping text to the screen from BASIC was painfully >slow, even for those days. Perhaps that is where the perception of a >slow BASIC arose. This reminded me of a quote in "OEM Integrator" last summer... I figured you might be interested in it, altho it's obviously not always true: * Traditionally, at least according to Jones, PCs have been designed * like terminals, with designers concentrating on improving CPU * performance while ignoring I/O completely. Jones harkened back to * what customers want in the minicomputer marketplace. "If you really * look at what customers buy, it is not MIPS," he said. "What the * world really buys is I/O throughput." The rest of us call this the "instant gratification" theory <grin>. - kev <kdarling@catt.ncsu.edu>
peterk@cbmger.UUCP (Peter Kittel GERMANY) (12/28/90)
In article <1029.2772FECD@weyr.FIDONET.ORG> David.Plummer@f70.n140.z1.FIDONET.ORG (David Plummer) writes: >I was wondering about two older Commodore machines that I saw/have promo >literature for but never actually saw the machines. The first is the >Commodore 128PC LCD Laptop (did this ever make it to market?) I saw this, but I saw no "128" in its name, just LCD. The OS was sort of mixed C64 and Plus/4, not really compatible with any of them. >The second is a little more obtuse: sometime between the SuperPET era >and the Amiga (a wide time slice, to be sure) there were rumours of some >"Z machine" that would multitask and a bunch of other stuff. This could be the CBM 900, a UNIX box with a Z8000 processor. We showed it on several faires in early 1985, but then this project died. One version of it even had a (really >1000) hires monochrome screen WITH a mouse and window manager! -- Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
peterk@cbmger.UUCP (Peter Kittel GERMANY) (12/29/90)
In article <1990Dec28.001940.25138@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: > >Not too sure it is fair to characterize the Pet as slow; Oh, I LOVE my old 8032. Running BASIC, it's not so much slower than a normal Amiga with AmigaBasic. >On the other hand, dumping text to the screen from BASIC was painfully >slow, even for those days. Perhaps that is where the perception of a >slow BASIC arose. Hmm, but there was another issue with screen output on the PETs, which I miss on all the current computers like Amiga or PCs: the cursor control characters that worked blindingly fast when used in a PRINT statement. I had a demo using simple PRINTs with whole text lines shooting in from the left or right, just by issuing proper insert or delete control chars. There the benefit of a memory mapped simpe character screen storage was VERY apparent. Simply stated: I can't do this in a similar way on the Amiga! (But in another way it works: with graphical GET and PUT, but that's another story.) -- Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
David.Plummer@f70.n140.z1.FIDONET.ORG (David Plummer) (12/29/90)
Ok, thanks for the info. For our next question, what the heck is a B series PET, and why does it look like something from Star Trek? -- David Plummer - via FidoNet node 1:140/22 UUCP: ...!herald!weyr!70!David.Plummer Domain: David.Plummer@f70.n140.z1.FIDONET.ORG Standard Disclaimers Apply...
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (12/30/90)
In <673@cbmger.UUCP>, peterk@cbmger.UUCP (Peter Kittel GERMANY) writes: >In article <1990Dec28.001940.25138@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: >> >>Not too sure it is fair to characterize the Pet as slow; > >Oh, I LOVE my old 8032. Running BASIC, it's not so much slower >than a normal Amiga with AmigaBasic. > >>On the other hand, dumping text to the screen from BASIC was painfully >>slow, even for those days. Perhaps that is where the perception of a >>slow BASIC arose. > >Hmm, but there was another issue with screen output on the PETs, >which I miss on all the current computers like Amiga or PCs: the >cursor control characters that worked blindingly fast when used >in a PRINT statement. I had a demo using simple PRINTs with whole >text lines shooting in from the left or right, just by issuing >proper insert or delete control chars. There the benefit of a >memory mapped simpe character screen storage was VERY apparent. > >Simply stated: I can't do this in a similar way on the Amiga! >(But in another way it works: with graphical GET and PUT, but >that's another story.) The console device supports a full set of cursor positioning sequences, and is indeed blindingly fast. In addition to the normal up/down/left/right/home, etc., you have 'erase to EOL/EOS', cursor positioning by row/column, and more. I don't know if these are usable from Basic, but if Basic uses the console.device, it should work fine. -larry -- The best way to accelerate an MsDos machine is at 32 ft/sec/sec. +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
vinsci@nic.funet.fi (Leonard Norrgard) (01/03/91)
In article <1990Dec28.001940.25138@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: vinsci@nic.funet.fi (Leonard Norrgard) writes: >>kevin <kdarling@catt.ncsu.edu> (guest account) writes: >>I'm not sure when the port was done tho, but it might actually have >>been the first CBM multitasking computer available :-). >I seem to remember there was an old hack to run multiple basic >programs simultaneously on the PET. It wasn't really useful due to the >slowness, but still ;-). Anyone have a better moemory of this? Not too sure it is fair to characterize the Pet as slow; I saw several collecting seven to nine simultaneous reasonably high speed channels of meteorological data each during a big weather project I was part of in 1981 (computer operator and ship jockey). IEEE-488 wonders, I guess. Of course, the PET also had what now are the Amiga I/O chips (8520), only a little earlier model (6520). :-) confirmed that they were doing the collecting using BASIC, though I wasn't sophisticated enough about BASIC in those days to ask if they were running an assembly kernel in there somewhere. The Pets had replaced multimillion dollar special hardware used for the same purpose in 1974. On the other hand, dumping text to the screen from BASIC was painfully slow, even for those days. Perhaps that is where the perception of a slow BASIC arose. Well, you could flip a bit and get a sudden speed increase, an order of magnitude or so. Too bad they didn't flip that bit at the factory. If you followed the output vector ($ffe4?) you could notice how it busywaited for the CRT to finnish drawing the current frame before updating screen RAM, just to avoid some very minor flicker near the screen position updated. It was not the only Microsoft mis-feature in those ROMs, I can assure you! I was always wondering why someone at CBM didn't optimize things. Any CBM people from that time still around? Now is your chance to explain yourself! ;-) Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us> -- Leonard
peterk@cbmger.UUCP (Peter Kittel GERMANY) (01/07/91)
In article <VINSCI.91Jan3022911@nic.nic.funet.fi> vinsci@nic.funet.fi (Leonard Norrgard) writes: > >Well, you could flip a bit and get a sudden speed increase, an order >of magnitude or so. Too bad they didn't flip that bit at the factory. >If you followed the output vector ($ffe4?) you could notice how it >busywaited for the CRT to finnish drawing the current frame before >updating screen RAM, just to avoid some very minor flicker near the >screen position updated. Hmm, are we talking PET 2001 or later models? For the 2001, you're sure right. But in the later 8032 (I think it was called Super PET in US), it was not necessary to wait for screen finish because the video RAM access was interleaved between CPU and 6545 CRT controller. (Each one had one half of the Phi2 phase, so it was 1000 ns cycles effective access, compare that to 500 or so ns stated by Dave for the A3000 :-) But I can't swear that they really took advantage of this in the ROM. Hmm, but when I look at that old demo (I can still run it here!), I think they did. Yes, back on the 2001 you only got it to flicker was with POKing to the screen memory, nearly not by PRINT (well, NEARLY: when you made a close loop printing and deleting the character at the home position, it also looked like bad flicker). I should state that I was not a system programmer in those days, just a (satisfied!) user. -- Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
andy@cbmvax.commodore.com (Andy Finkel) (01/10/91)
In article <10.278AB99D@weyr.FIDONET.ORG> David.Plummer@f70.n140.z1.FIDONET.ORG (David Plummer) writes: >LN> Well, you could flip a bit and get a sudden speed increase, an order >LN> of magnitude or so. Too bad they didn't flip that bit at the factory. >LN> If you followed the output vector ($ffe4?) you could notice how it >LN> busywaited for the CRT to finnish drawing the current frame before >LN> updating screen RAM, just to avoid some very minor flicker near the >LN> screen position updated. It was not the only Microsoft mis-feature in >LN> those ROMs, I can assure you! I was always wondering why someone at >LN> CBM didn't optimize things. Any CBM people from that time still >LN> around? Now is your chance to explain yourself! ;-) >LN> >LN> >LN> Kent, the man from xanth. >LN> <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us> >LN> It wasn't minor flickering...it was major flickering. In fact, I did a screen hack on the PET that use it to produce a snow storm in a demo program. I seem to remember that the video controller was later updated to sync updates to screen blank, and the software fix was removed. (my snow storm vanished; and I had to explain to a bunch of people how it was supposed to look) andy -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. "And Amiga has not forgot the retailer." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
David.Plummer@f70.n140.z1.FIDONET.ORG (David Plummer) (01/11/91)
PK> Hmm, are we talking PET 2001 or later models? For the 2001, you're
PK> sure right. But in the later 8032 (I think it was called Super PET
PK> in US), it was not necessary to wait for screen finish because the
[...]
PK> Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opin
PK> Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger
PK>
PK> --- ConfMail V3.31
PK> * Origin: weyr.fidonet.org (1:140/22)
Actually in the US (or at least in Canada) the 8032 and the SuperPET
were two completely different items. The SuperPET was actually the
PET 9000 (or SP9000, I think). It had a 6809 in addition to the 6502,
96K of RAM, and a host of Waterloo languages (interpreted PASCAL!).
-----------------------------------------------------------------------
= plummerd@uregina.ca or plumme@hercules.uregina.ca (BITNET) =
=---------------------------------------------------------------------=
= Amiga__ | Make it possible for programmer's to =
= __ /// IBMUBMWEALLBM4IBM | write code in English and you'll soon =
= \\\/// | discover that programmers cannot =
= \XX/ | write in English. =
-----------------------------------------------------------------------
--
David Plummer - via FidoNet node 1:140/22
UUCP: ...!herald!weyr!70!David.Plummer
Domain: David.Plummer@f70.n140.z1.FIDONET.ORG
Standard Disclaimers Apply...peterk@cbmger.UUCP (Peter Kittel GERMANY) (01/16/91)
In article <19.278EA89B@weyr.FIDONET.ORG> David.Plummer@f70.n140.z1.FIDONET.ORG (David Plummer) writes: > >Actually in the US (or at least in Canada) the 8032 and the SuperPET >were two completely different items. The SuperPET was actually the >PET 9000 (or SP9000, I think). It had a 6809 in addition to the 6502, >96K of RAM, and a host of Waterloo languages (interpreted PASCAL!). Ah, then I know: It was named "MMF 9000" (at least here). And you know what MMF stood for? "Micro MainFrame"!!! (Maybe because of these Waterloo languages, they were all awfully slow, I think with an 6809 you could have managed far better performance, look e.g. at OS9 for this processor!) -- Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk