home *** CD-ROM | disk | FTP | other *** search
/ 8bitfiles.net/archives / archives.tar / archives / genie-commodore-file-library / Information / NEWS&VIEWS.ARC / 02NEWS&VIEWS < prev    next >
Encoding:
Text File  |  2019-04-13  |  36.1 KB  |  791 lines

  1.  ************
  2. Topic 20        Fri Nov 25, 1994
  3. H.HERMAN1                    (Forwarded) 
  4. Sub: Pentium woes...                        
  5.  
  6. No doubt that by now you have all heard of the infamous bug to be found in 
  7. each and every Intel Pentium chip ( *Intel Inside* ), and by implication, 
  8.  *all computers* bearing the Pentium label.
  9. 74 message(s) total.
  10.  ************
  11.  ------------
  12. Category 2,  Topic 20
  13. Message 1         Fri Nov 25, 1994
  14. H.HERMAN1                    (Forwarded) 
  15.  
  16.  No doubt that by now you have all heard of the infamous bug to be found in 
  17.  each and every Intel Pentium chip ( *Intel Inside* ), and by implication, 
  18.   *all computers* bearing the Pentium label.
  19.  
  20.  Intel claims the "bug" can be expected to appear, for the "average" user, 
  21.  only once in every 27 years.  Therefore, they claim it is not serious, and 
  22.  will replace the errant CPU only for those who can "prove" they are running 
  23.  mathematically critical applications.
  24.  
  25.  Talk about unabashed stonewalling......
  26.  
  27.  or...
  28.  
  29.  Hey!  This does not sound all that serious then, right?
  30.  
  31.  Well, yes and no.....
  32.  
  33.  What if you just happen to be the patient undergoing a heart bypass?  Would 
  34.  you feel comfortable knowing that YOUR surgeon will be relying on imaging 
  35.  based on the Pentium?  ha!
  36.  
  37.  So?  How obscure is this bug which will appear only once in every 27 years?
  38.  
  39.  OK!  Take out your Pentium folks!
  40.  
  41.  What?  You don't have one?
  42.  
  43.  Then rush down to your local Pentium retailer/dealer, and put a computer to 
  44.  the test!
  45.  
  46.  A test?
  47.  
  48.  Yup!  One manifestation of the BUG will ALWAYS appear if you calculate:
  49.  
  50.  x=4195835
  51.  y=3145727
  52.  z=x-(x/y)*y
  53.  
  54.  As any C64 and C128 owner will tell you, Z=0.  Basic7 returns a zero.  Most 
  55.  applications will also return a zero.  In the case of roundoff errors, a 
  56.  number no larger than 9.3e-10 is returned.
  57.  
  58.  In fact, most all computers return a ZERO.
  59.  
  60.  So, what about a computer adorned with a Pentium CPU?
  61.  
  62.  It says Z=256.     omigawd..........
  63.  
  64.  ----------
  65.  Hey folks!  
  66.  
  67.  Hang onto your C64's  and C128's!!
  68.  
  69.  They are more accurate than the Pentium.
  70.  
  71.  Howie
  72.  ------------
  73. Category 2,  Topic 20
  74. Message 2         Fri Nov 25, 1994
  75. THE.OUTLAW                   (Forwarded) 
  76.  
  77. I'll bet you had a good time at the computer store, Howie! hehehe
  78.  ------------
  79. Category 2,  Topic 20
  80. Message 3         Fri Nov 25, 1994
  81. H.STEVENS5 [HaroldOH]        (Forwarded) 
  82.  
  83. You realize Howie that you have finally found a way to allow a commie user to
  84. become smug toward a Pentium owner. I can't wait to use this and tell them
  85. that my C-64 is smarter than their Pentium. :)
  86.  
  87. --Harold
  88.  ------------
  89. Category 2,  Topic 20
  90. Message 4         Fri Nov 25, 1994
  91. SAUVIN [Ben]                 (Forwarded) 
  92.  
  93. The 6502 (actually, the 6510) that drove my original C64 had a flaw, probably
  94. well-known in this RT, where the ML instructions
  95.  
  96.         lda whereat,x
  97.  
  98. would load the accumulator with a garbage byte. Fortunately, that bug was well
  99. known enough that we didn't (and don't) get stung by it with commercial
  100. software, and it was (is) absent in the C128's 8502.
  101.  
  102. When I was trying to develop a routine for graphing (plotting) complex
  103. functions on a C128's screen, it blew up because of a bug in the graphics
  104. commands that I didn't know about - the program was eventually completed by
  105. using combinations of the less "advanced" commands, making it much slower than
  106. should have been the case. I do NOT recall what the commands were, except that
  107. negative vectors were a problem.
  108.  
  109. Does anybody even REMEMBER the return rates for early Commodore machines? My
  110. first VIC-20 was also my LAST one, for which I am thankful. However, I went
  111. through three or four C64's before finally having one that could stay alive
  112. for more than a few hours. The 128 on the desk is my second, and the 1581 next
  113. to it is the third I've exchanged for, and it STILL doesn't work reliably.
  114.  
  115. Telling a Pentium owner his machine is inferior because of some bug that might
  116. pop up once every 27 years is sorta like throwing stones from our glass house
  117. living rooms.
  118.  
  119. (Meanwhile, the keyboard on the C128 is dead, or I'd still be using it. When I
  120. have $$ again, I'll have a another - NO machine has ever proven a more benign
  121. place to experiment with interrupt-driven programming, you simply CANNOT kill
  122. a 128 with bad code)
  123.  ------------
  124. Category 2,  Topic 20
  125. Message 5         Sun Nov 27, 1994
  126. S.GOLDSMITH2 [Iron.Man]      (Forwarded) 
  127.  
  128.  >The 6502 (actually, the 6510) that drove my original C64 had a flaw,
  129.  >probably well-known in this RT, where the ML instructions
  130.  
  131.  >       lda whereat,x
  132.  
  133.  >would load the accumulator with a garbage byte. Fortunately, that bug was
  134.  >well known enough that we didn't (and don't) get stung by it with
  135.  >commercial software, and it was (is) absent in the C128's 8502.
  136.  
  137. I thought it was LDA ($FE),Y if $FE $FF pointed to $02FE and Y caused it
  138.  to go past a 256 byte page boundry.  It's been a while since I've written
  139. 6502, but it was something like that...
  140.  
  141. SG :)
  142.  
  143.  ------------
  144. Category 2,  Topic 20
  145. Message 6         Sun Nov 27, 1994
  146. BEN.GELAMP [Ben]             (Forwarded) 
  147.  
  148. Iron.Man:
  149.  
  150.   I don't clearly remember the details of the bug you name, but I remember it
  151. now. There WAS something about a page boundary wraparound problem that never
  152. DID get fixed, that I know of. If memory serves, the construction
  153.  
  154.         lda ($fb),y
  155.  
  156. where $fb is $00, $fc is $6e and .Y is $ff, the CPU would load the LSB of a
  157. pointer from $6eff and the MSB from $6e00, which is hardly what would have
  158. been expected. Or am I confusing this operation with another? All I DO
  159. remember is that the .Y register would not cross a page boundary in this
  160. construction. The reason I don't really remember it is because I do remember
  161. reading about this bug before really trying to use the instruction, so I was
  162. able to take precautions against it.
  163.  
  164.   The LDA WHEREAT,X problem where .X is 0 really ticked me off to NO end until
  165. I learned that it WAS a bug (I thought the assembler I paid good money for was
  166. junk) - I even taught the cat new ways to abuse the English language.
  167.  ------------
  168. Category 2,  Topic 20
  169. Message 7         Sun Nov 27, 1994
  170. E.GBELL [e.g.bell]           (Forwarded) 
  171.  
  172.   BG> The LDA WHEREAT,X problem where .X is 0
  173.  
  174.  I am familiar with the zp bug you mention regarding page boundaries.
  175.  I'm not sure it was a load, though.... but I have never heard of (or
  176.  experienced) an problem with indexing an absolute address with the .x
  177.  register, regardless of the value of .x.  What assembler are  you now 
  178.  sure the problem was not with, and where did you learn that this *was*
  179.  a bug?  Do you have an example we can duplicate.  
  180.  
  181.  ------------
  182. Category 2,  Topic 20
  183. Message 8         Sun Nov 27, 1994
  184. BEN.GELAMP [Ben]             (Forwarded) 
  185.  
  186. E.G.Bell..
  187.  
  188.   You won't be able to duplicate the bug if you have a C128, since that
  189. particular bug didn't survive the trip from the C64's 6510 to the C128's 8502.
  190.  
  191.   There was no "zp" (I assume that to mean zero page) involved here,
  192. particularly. On a 6502 and a 6510, the construction
  193.  
  194.         lda whereat,x
  195.  
  196. loads the accumulator with a garbage byte (unpredictable value) when .X is
  197. zero.
  198.  
  199.   The bug can be repeated with any assembler; I've gotten stung by it on both
  200. the Commodore Macroassembler (what a kludge!) and the Power Assembler
  201. (Spinnaker, formerly the Buddy Assembler, well recommended!) as well as
  202. Micromon and Supermon.
  203.  
  204.   Furthermore, both bugs mentioned in this topic, among others, are documented
  205. in Raeto Colin West's Programming the C64 (*very* highly recommended).
  206.  ------------
  207. Category 2,  Topic 20
  208. Message 9         Mon Nov 28, 1994
  209. E.GBELL [e.g.bell]           (Forwarded) 
  210.  
  211.  I also have a 64 Ben.... and learned my ML on it as a matter of fact.
  212.  I'm not trying to dispute what you say.... just that I've never seen
  213.  mention of the absolute,x thing you mention.  I remember the other one,
  214.  whether it was one of the indirect zp ones or an indirect JMP... even
  215.  gotten bitten by it.
  216.  
  217.  Can you direct me to the section describing this bug in RCWest's book?
  218.  I have it and have long considered it one of the most valuable in my
  219.  library.  I've never had problems with that particular instruction,
  220.  regardless of the value of .x.  I will take some time tonight and try
  221.  to find mention of the one w/the .x register.  I honestly don't remember
  222.  where I saw the zp one, tho I've seen it frequently over the years.
  223.  Do you have a sample of the code that doesn't work?  Of course, I guess
  224.  that :
  225.  
  226.  ldx #0
  227.  lda absolute,x
  228.  
  229.  is all it would take, huh?  BTW, it is not mentioned under the LDA
  230.  discussion on page 312.  On the other hand, I was correct about the
  231.  indirect JMP being the culprit in the other case.  On page 310 of Mr.
  232.  West's book he describes it:
  233.  
  234.  'Note that this instruction has a bug; JMP ($02ff) takes its new address
  235.  from $02ff and $0200,not $0300.  That is kind of what I remembered about
  236.  the other thing you were talkng about.
  237.  
  238.  On page 303 of the book, there is an example using the kind of code you
  239.  say is flawed....
  240.  
  241.          ldx #0
  242.  loop    lda $0278,x
  243.          sta $0277,x
  244.          inx
  245.           cpx #$c6
  246.          bne loop
  247.  
  248.  Substitute 'whereat' for $0278.... are you sure this is a known bug?  The
  249.  book I have by Mr. West is the one for the 64... matter of fact, the 
  250.  example under the LDA instruction uses the same kind of code:
  251.  
  252.  ldx #$00
  253.  lda $7000,x
  254.  sta $8000,x
  255.  dex
  256.  bne -9
  257.  
  258.  Of course, if the bug requires that the instruction use a label, then
  259.  perhaps the bug is common across the assemblers you used?
  260.  ------------
  261. Category 2,  Topic 20
  262. Message 10        Mon Nov 28, 1994
  263. BEN.GELAMP [Ben]             (Forwarded) 
  264.  
  265. Wow.. perhaps it's my MEMORY that's flawed.
  266.  
  267. If I can find that book again, I'll fish it out.
  268.  
  269.  ------------
  270. Category 2,  Topic 20
  271. Message 11        Tue Nov 29, 1994
  272. SAUVIN [Ben]                 (Forwarded) 
  273.  
  274.   It looks like I was totally into left field about the
  275.  
  276.         lda whereat,x
  277.  
  278. mode of addressing, and I think I found out why. DARN, this is irritating! - I
  279. started avoiding that addressing mode very early in the learning process
  280. because of something I must have MISREAD on pages 219-220 of Programming the
  281. C64.
  282.  
  283.   What could also have confused me is the nature of
  284.  
  285.         lda zp_loc,x
  286.         lda zp_loc,y
  287.  
  288. where the operation never loads the accumulator with a garbage byte PER SE,
  289. but CAN load it with an unexpected value if (for example) zp_loc is $fe and x
  290. (or y) is 2 - the value won't be taken from $0100, but from $0000.
  291.  
  292.   I can find no reference to any bug concerning load or store operations,
  293. either in RCW's Programming, the Commodore PRG or Mapping the C128 except the
  294. problem with
  295.  
  296.         jmp ($567f)
  297.  
  298. bug, which reads an LSB from $56ff, but an MSB from $5600 - and yes, this one
  299. has stung me, too.
  300.  
  301.   It's also possible the problem I read about was indeed with an assembler,
  302. although I doubt it. I remember *something* about it being repeatable no
  303. matter what translator I used.
  304.  
  305.   :sigh:
  306.  
  307.   There WAS somewhere, somehow, something that was a bug in the 6502 that
  308. wasn't in the 8502 - I clearly remember reading SOMETHING about it - but I
  309. suddenly find myself believing I know a LOT less about those chips than I used
  310. to THINK I knew. It's just been too long since I've seriously done anything
  311. with those machines.
  312.  
  313.   This whole thread actually started by mentioning the Pentium's less than
  314. ideal handling of floating point math (I believe but don't KNOW that the
  315. problem is with the FDIV instruction, floating point divide) - somebody tried
  316. to suggest that Pentium machines were relatively brain-dead because of that
  317. fact.
  318.  
  319.   It's irrational that I'd feel personally stung by such a comment, since I
  320. don't even have ACCESS to a Pentium, or plans to buy one. I was no less
  321. antagonised when people laughed at my Commodore 128. I don't imagine it's
  322. necessary to tell anybody here it's more than just a game machine, perfectly
  323. capable of handling all the major types of software, and that's precisely what
  324. it DID do for me, for the better part of a decade when people were trying to
  325. tell me to spend several thousand dollars on IBM hardware that (at the time)
  326. had only the advantages of speed and size.
  327.  
  328.   I'm hardly innocent of that kind of antagonism, myself. It wasn't terribly
  329. long ago that one of my favourite cosysops and I had a major row about my
  330. putting down the Macintosh line of computers - I'd say "Your Mac can't handle
  331. THIS" or "That kind of software isn't available for your Mac", and so on, and
  332. so forth, until one day the turnabout exploded in my face with "WILL YOU QUIT
  333. CUTTING DOWN MY MACINTOSH, YOU SMUG CONDESCENDING !@$#^!!"
  334.  
  335.   It'd never occurred to me that some people take their machines (or even
  336. IDENTIFY with them) every bit as much as I.. or even MORE.
  337.  
  338.   In the time since, I've learned that Macintosh does indeed have some of the
  339. same kinds of internal problems with their operating systems as do the current
  340. crop of IBM machines, legacy code and data structures limitations, for
  341. example, and have had to consider (yet once again) that each machine has its
  342. strengths, weaknesses and appropriate applications. What other kinds of
  343. machines may have this general kind of problem, I cannot say, but on the basis
  344. of the machines I've dealt with so far, it'd surprise me greatly to learn of
  345. ANY machine/OS/platform that hasn't had growing pains.
  346.  
  347.   We could go on and on and on about bashing other people's computers on the
  348. basis of perceived faults. For what gain (I ask as I remember that angry
  349. cosysop's "voice")? Much of it is history, and most of the remainder is
  350. actually academic. It is true that Commodore people tend to be extremely loyal
  351. to their machines.. but ST people tend to like THEIR machines (calling PC's
  352. kludgy, not without reason), as do also Amiga people, as do users of most
  353. other brands of current or classic hardware.
  354.  
  355.   That loyalty, to a degree, is a Good Thing. We can't feel good about our
  356. computering experience(s) unless we feel good about the machines we're working
  357. with, but our zealotry crosses the line when it blinds us to the advantages
  358. other machines might offer.
  359.  ------------
  360. Category 2,  Topic 20
  361. Message 12        Tue Nov 29, 1994
  362. GEOS-TIM                     (Forwarded) 
  363.  
  364. I know an interesting fellow that has just about every kind of computer tht
  365. you could think of: Macs, C64, C128, Pentium,etc.  I think he even has a Old
  366. Tandy.  He told me that he uses all of them from time to time,  because they
  367. all do some special things for him, and since he has the  luxury of having
  368. plenty of room for them, he is indulged.
  369.    Bottom line on any computer, or software:  It has a job to do. What ever
  370. computer you have you have a sizable learning curve that has been mastered,
  371. and you start knowing all the intricate things that your computer and software
  372. can do and not do.  I use GEOS most of the time, and I still learn things from
  373. and about it.  I think that is part of the charm of using them.
  374.    I have a copy of geoShell on my disk shelf.  I have booted it up  several
  375. times, and I recognize that it has tons of power in it, but I don't have the
  376. time to invest in it right now, to learn it thoroughly, so I sort of get it
  377. out from time to time.  Eventually, I'll be using it a lot, but  it has to fit
  378. around my many projects.
  379.    We all have time invested, and we have computer projects sitting there. The
  380. more we know our computer and software, the better we can get that job done. 
  381. So you're right , Ben.  Everyone gets attached to their computer in some way,
  382. cuz after all, it is sort of like a non human fellow worker. But I can't think
  383. of any computer "personality" nicer to work with than my Commodore.           
  384. :) -Tim
  385.  ------------
  386. Category 2,  Topic 20
  387. Message 13        Wed Nov 30, 1994
  388. H.HERMAN1                    (Forwarded) 
  389.  
  390. Ben,
  391.  
  392. I, for one, can easilly identify with most all of what you said.
  393.  
  394. It is interesting to observe also how owners of new Pentium computers do too.
  395.  
  396. While the Pentium is relatively new, the impression I get is that their owners
  397. are livid with outrage at the way Intel is handling this problem.
  398.  
  399. I recall when the C128 first arrived, it had the now famous Cap's Q bug, and
  400. other problems.  As I recall it was clear from the outset, thanks to widely
  401. distributed postings of Fred Bowen, that Commodore would fix this.  True to
  402. its word updated C128 ROM's were made available for a nominal charge.
  403. Something like $15, if I remember correctly.
  404.  
  405. This contrasts sharply with how Intel is attempting to stonewall their
  406. problem, and require "proof" from its customer that he/she requires a properly
  407. working MPU, before giving  a replacement will even be considered.
  408.  
  409. We all seem to get attached to our electronic toys very quickly.  Finding out
  410. that it is flawed can indeed prove upsetting.
  411.  
  412. Tim has hit the provebial nail on its head by observing that the factor of
  413. time and a learning curve for any computer plays an important part in the
  414. formula.
  415.  
  416. Howie
  417.  ------------
  418. Category 2,  Topic 20
  419. Message 14        Wed Nov 30, 1994
  420. M.RANDALL2 [Maurice]         (Forwarded) 
  421.  
  422.   I just thought that I might throw in my own thoughts and opinions on the
  423. JMP(indirect) subject. I won't comment on how this subject got started with
  424. the deal on the Pentium, but I thought it to be quite funny that the Pentium
  425. truly does have a nasty bug as such. Plus, I like the fact that I can lay my
  426. finger on a powered up 6502 without getting burned.
  427.  
  428.   Anyway, the 6502 has been around for a long, long time. Even long before
  429. Commodore built the first PET computer. And the early 6502's no doubt did have
  430. some bugs. It was quite an advancement in microprocessors just as the new
  431. processors of today are. The JMP to an indirect address was designed for
  432. program designers to place a set of addresses into a table within memory.
  433. These addresses would then make reference to the desired location where the
  434. programmer intends to jump to. This table would be in a 'known' location so
  435. that software could easily alter any of the values within the table and
  436. therefore cause a program to jump to a different location as desired. Any one
  437. of these addresses could be referenced as many times as needed anywhere within
  438. the program. So, to cause several different routines to jump to a specific
  439. location only requires two bytes to be altered, rather than altering several
  440. sets of bytes scattered throughout the program.
  441.   The CBM operating system makes use of this feature. There are indirect
  442. vectors located in memory that point to various routines such as the interrupt
  443. routines and the loading and saving routines, etc. When the 6502 was first
  444. designed, it was given three fixed vectors of which the location of them
  445. cannot be changed. These are the NMI, RES, and IRQ vectors. They were placed
  446. at the highest locations addressable by the 6502, at $FFFA-$FFFF. This puts
  447. them out of the way and leaves the rest of the memory map available for
  448. programming and other uses. The 6502's stack is always addressed at page one
  449. of memory from $0100- $01FF. This location can be changed through hardware as
  450. is proven with the 128. But otherwise it is always in the first page. Page
  451. zero was thought to be an excellent location for indirect vectors. It would be
  452. easy to remember where they are located and easy to alter. This more than
  453. likely was the original idea for where to have the JMP(indirect) vectors
  454. located. They would be contained entirely within one page of memory. The first
  455. one would be at $00,$01 and the second at $02,$03 and so on (Of course,
  456. $00,$01 got put to use for other purposes). There was room for 128 vectors
  457. within this page of memory. If all of them were used, then the 128th would be
  458. at $FE,$FF. The next page would be the stack. No more room for vectors.
  459.   Now, with a little thinking, and thank goodness for that, the designers of
  460. the 6502 probably thought that there just might be a need for more than 128
  461. vectors in some programs. Maybe this feature shouldn't be limited to page
  462. zero. Let's allow it to be located on any given page in memory. And so it was.
  463.   One little thing was overlooked in the design however. If a table of
  464. indirect vectors began on an odd address and there were enough in use to cause
  465. the table to cross over into the next page, a minor problem would occur. The
  466. zero page thought still existed. The next page of memory was not allowed to be
  467. accessed in order to fetch the high byte of the destination address. Instead
  468. the high byte is fetched from the first location of the current page. This
  469. occurs when the vector begins on the last byte of a page, such as $08FF for
  470. example. Your program has the second byte (the high byte) of the vector
  471. sitting at $0900. The 6502 will use the byte at $0800 instead.
  472.   So, is this really a bug? I don't think so. If you understand how the
  473. operation works, it will never affect your programming. The answer here is to
  474. always place your indirect vector table either at the start of a page, or
  475. start it on an even byte. If it begins on an odd byte, you are asking for
  476. trouble unless you know for sure that it will not extend past the end of a
  477. page of memory. As long as it begins on an even byte, then you can make the
  478. table just as large as you need within the confines of memory.
  479.   Internally, within the 6502 itself, what is happening is this: The 6502
  480. begins by fetching the operation code to begin it's next instruction. It finds
  481. a $6C there. This is the opcode for the JMP(indirect) operation. Now it knows
  482. what it needs to do, and this whole operation is going to take up a total of 5
  483. clock cycles. We have about a million clock cycles to work with every second.
  484. The 6502 has already used up one cycle. On the next two cycles it gets the
  485. value contained in the next two locations. It now knows where the vector is
  486. that contains the address it should jump to. With this info, the 6502 then
  487. goes and gets the first byte of the vector during the fourth cycle. It then
  488. adds a 1 to the address where it found the first byte. This now points to the
  489. second byte of the vector, which it will fetch on the 5th and final cycle of
  490. this operation. BUT... within the 6502, when it added a 1 to the address of
  491. the vector, it did not take into account it's own internal carry. It should
  492. have added the value of the carry to the high byte of the location of the
  493. vector. Since it did not, it will still look within the same page of memory
  494. for the second byte of the vector. The carry never gets added internally when
  495. fetching the indirect vector as it increments it's address pointer to the
  496. second byte of the vector. This is not the carry flag as we know it, but the
  497. carry that is within the 6502's own little arithmetic logic unit (ALU).
  498.   Again, I don't see this as a bug, but more like something that a programmer
  499. should just remember about when writing his software. There are other
  500. processors with worse problems. Some of the 16 and 32 bit processors require
  501. that an actual instruction begin on an even byte. This forces you to place
  502. unused bytes here and there so that the instructions don't begin on an odd
  503. location. Not too handy. The only time we need to do this with a 6502 would be
  504. just prior to an indirect vector table. A zero byte or a NOP instruction could
  505. be placed there if the last instruction would cause the table to begin on an
  506. odd byte. Sure it's a wasted byte, but it beats spending a week trying to
  507. debug a program that doesn't work.
  508.   Just as a side note, here's an imaginary scenario on an early 6502 potential
  509. problem: Imagine it's 1977 and you just bought one of the very first PET
  510. computers. Shortly afterwards, it develops a problem and you have to take it
  511. in for repairs. While trying to figure it out, the repair technician replaces
  512. the 6502 and does some other stuff. It starts working and you are back in
  513. business. Probably it was the 'other stuff' that fixed it. Well, the 6502 that
  514. just went into your new computer was one that just happened to be 'lying'
  515. around the repair facility. Hmmm... Ready? Prior to June of 1976, the 6502's
  516. did not have a ROR instruction in them. Whoops. Some software just doesn't
  517. seem to work like it should.
  518.   Isn't this fun.
  519.  
  520.   - Maurice Randall
  521.  
  522.  
  523. (P.S.  Sorry for the length of this message for those that had to scroll
  524. through it and are not interested in this sort of stuff.)
  525.  
  526.  
  527.  
  528.  ------------
  529. Category 2,  Topic 20
  530. Message 15        Wed Nov 30, 1994
  531. GEOS-TIM                     (Forwarded) 
  532.  
  533. Maurice "Guru of the Programming Mountain"
  534.   It is always a pleasure to read your positive feedback, even if I don't 
  535. understand it all, it still makes sense.  May your overlooking of percieved
  536. 6502 limitations continue unabated.    :) -Tim Or should I say, Sweeping away
  537. perceived 6502 limitations?   :)-Tim
  538.  ------------
  539. Category 2,  Topic 20
  540. Message 16        Wed Nov 30, 1994
  541. BEN.GELAMP [Ben]             (Forwarded) 
  542.  
  543. LOL!
  544.  
  545.   Maurice, anybody who can worry about an "internal carry bit in an ALU" is a
  546. far, far better computer nerd than I :)
  547.  
  548.   I enjoyed every word of what you wrote - do it again sometime!
  549.  
  550.   Two of the pleasantest discoveries about the Commodore machine were the
  551. existence of the formal services that you can call with a simple JSR (for
  552. example, CHROUT ($ffd2) with the character in .A, and the other was the
  553. existence of the vector table in Page 3 that use the jmp (wherethru)
  554. construction. It made interrupt-level programming possible, and OOooOOoo, was
  555. THAT ever fun! I used it to redirect the keyboard handler to something that
  556. did FUNKY things to my roommate's typing on his 128 :>
  557.  
  558.   I knew the 6502 had been around for a while when that first VIC-20 appeared
  559. under the Christmas tree, but since 1976!??! Gee.. no WONDER they were so
  560. sound!
  561.  
  562.   You might be pleasantly surprised to learn (if you didn't already know) that
  563. the PowerPC instruction set is supposed to be far simpler than the 8086's -
  564. it's supposed to be as simple (or possibly even simpler) than that of the
  565. 6502, with the exception that floating point operations will not only be built
  566. in (no more having to deal with FACC's and stuff). When I see the instruction
  567. sets, I'll be sure to let you know, but it looks like the heyday of the
  568. Monster Instruction Set (MIS) is soon to expire.
  569.  
  570.   As much as I've enjoyed toying with IBM machines, I think I'll enjoy those
  571. computers almost as much as I enjoyed the 128 and the Amiga.
  572.  ------------
  573. Category 2,  Topic 20
  574. Message 17        Fri Dec 02, 1994
  575. D.TUOMI [Doctor]             (Forwarded) 
  576.  
  577. I wonder if a 6502 would qualify as a RISC processor?  There is some dispute
  578. as to exactly what a RISC processor is.  For example, the Alpha supposedly has
  579. more instructions than a 80x86 chip, but yet its still considered a RISC chip.
  580. The 6502 doesn't have a lot of instructions, and its fairly efficient about
  581. the way it processes.  So, perhaps one could think of a 6502 based Commodore
  582. machine as a prototype RISC computer.
  583.  
  584. Doc.
  585.  ------------
  586. Category 2,  Topic 20
  587. Message 18        Fri Dec 02, 1994
  588. BEN.GELAMP [Ben]             (Forwarded) 
  589.  
  590. I've often thought the same thing myself.
  591.  
  592. Nebbermind what I might have forgotten or misremembered (or misread :sigh:),
  593. I'll still claim that learning machine language on the C128 was (is) easier
  594. than on any other machine I know of, partly because its instruction set is so
  595. small, partly because it was (is) unkillable and because the Commodore
  596. operating system was easy to deal with.
  597.  
  598. Could the 6502 have been a doable CPU in "real" computers? Maybe. Several
  599. changes would have to be made, including (but not limited to)
  600.  
  601.         * faster processing!
  602.         * 32 or 64 bit absolute and relative addressing
  603.                 (makes relocatable code possible)
  604.         * more internal registers
  605.         * relocatable stacks
  606.  
  607. Fact is, the 6502 really did (does) have a very limited instruction set, to
  608. the point of true minimalism: how many of us have said "I'd kill for a TXY
  609. instruction, or a .Z register, or .."?
  610.  
  611. One of the things *included* in the RISC chips, is floating point math. They
  612. also have "instruction pipes" - for example, it is literally common practice
  613. for those chips to execute a floating point operation, an integer operation
  614. and a branching operation simultaneously (please don't ask me for more detail,
  615. this is all stuff my RISC-based boss told me).
  616.  
  617. Do RISC chips have more instructions than CISC? I honestly don't know yet.
  618. It's certain they won't have the problems an IBM has of dealing with 16-or 32-
  619. bit "segment" and "offset" registers or selectors (somewhat like bank# and
  620. address components on a C128), they'll be flat 32 or 64 bit model programming.
  621. The 68000 has "modes", where any given instruction has many different
  622. meanings, each selected by putting the processor in the appropriate mode -
  623. that is also gone in the RISC chip (and I can't think of a 6502 equivalent at
  624. the moment).
  625.  
  626. I believe the idea behind a RISC isn't so much to reduce the numbers of
  627. instructions as their inherently byzantine nature on the current crop of
  628. industrial-strength desktop numbercrunchers.
  629.  ------------
  630. Category 2,  Topic 20
  631. Message 19        Fri Dec 02, 1994
  632. C128.JBEE                    (Forwarded) 
  633.  
  634.  I believe the idea behind RISC chips was to reduce the number of instructions
  635.  the chip has to search through to execute an instruction that has been
  636.  submitted to the chip.
  637.  ------------
  638. Category 2,  Topic 20
  639. Message 20        Sat Dec 03, 1994
  640. CMD-DOUG                     (Forwarded) 
  641.  
  642. All of these things:
  643.  
  644.         * faster processing!
  645.         * 32 or 64 bit absolute and relative addressing
  646.                 (makes relocatable code possible)
  647.         * more internal registers
  648.         * relocatable stacks
  649.  
  650. are available in 65xx family processors. The 65816 and 65832 processers offer
  651. 16 and 32 bit power with a 6502 compatible instruction set. They come in
  652. speeds up to 20MHz. They have additional registers and relocatable stacks.
  653. They offer wider addressing to larger amounts of memory, and even have the
  654. ability to support co-processors and virtual memory. The 65816 even has a 6502
  655. emulation mode, which blocks off the extra features when attempting to
  656. maintain compatibility with older software. And these new processors were all
  657. designed by hand by one of the original designers of the 6502 - Bill Mench of
  658. Western Design Center (formerly with MOS Technology). Even the standard 65C02
  659. has been updated and enhanced with time by Bill's firm, with current versions
  660. offering important new instructions (such as BRA - BRanch Always) and high
  661. speeds (20MHz using .8 micron processes). 
  662.  ------------
  663. Category 2,  Topic 20
  664. Message 21        Sat Dec 03, 1994
  665. D.TUOMI [Doctor]             (Forwarded) 
  666.  
  667. So, the argument still stands.  Could the 6502 be called a RISC processor.  It
  668. certainly has a "reduced" instruction set, even compared with some of its
  669. contemporaries like the 8080 and Z80.  Its more powerful decendents meet the
  670. qualifications for 32bit and 16bit computing.  As to "real" computing.  I'm
  671. not sure what lies in your philosophy, but the 128 appears to be a consistant
  672. object within this reality, there-fore its likely to be as real as anything
  673. else within this reality.
  674.  
  675. Doc.
  676.  ------------
  677. Category 2,  Topic 20
  678. Message 22        Sat Dec 03, 1994
  679. BEN.GELAMP [Ben]             (Forwarded) 
  680.  
  681.     Hmm.. I knew of the advanced versions of the 6502; one of them powers the
  682. Apple GS, if I remember correctly.
  683.  
  684.     Would speeds beyond 20 MHz be possible? By todays's standards, a 33 MHz
  685. 386 is at the LOW end of acceptable speed - if you've never run AutoCAD or
  686. Windows, you'll know why.
  687.  
  688.  ------------
  689. Category 2,  Topic 20
  690. Message 23        Sun Dec 04, 1994
  691. D.TUOMI [Doctor]             (Forwarded) 
  692.  
  693. MHZ isn't a speed rating, its the number of pulses that the system clock
  694. cycles per second.  Since different processors process different op-codes
  695. under a different number of cycles, it makes comparing processors by MHZ
  696. rating unreliable.  This is partially the reason for the increase in speed on
  697. RISC chips is that since they have fewer op-codes they can do tasks in fewer
  698. cycles, and thus be faster.  I've heard the 6502 series running at 1mhz to be
  699. comparable to a 8088 running at 4mhz, and a 6502 running at 2mhz to be
  700. comparable to a 8088 running at 8mhz.  This is probably very debatable, and
  701. probably depends on the instructions beging executed, but if that analogy
  702. holds true then a 20mhz 6502 would be comparable to a 40mhz 8088.  And if you
  703. were talking about a 16 or 32bit version, then it would be more like the 80x86
  704. series, but still requiring fewer processor cycles to do the same tasks.
  705.  
  706. Doc.
  707.  ------------
  708. Category 2,  Topic 20
  709. Message 24        Sun Dec 04, 1994
  710. BEN.GELAMP [Ben]             (Forwarded) 
  711.  
  712.   Makes good sense to me; few of the commonly used indicators of speed give
  713. any *absolute* idea of actual throughput in any event, and are therefore just
  714. that: indicators (BTW, say what you will, the 4 MHz Z80 in the C128 seemed
  715. faster than the 286-12, at times!)
  716.  
  717.   A 486DX2-66 is a 486 clock-doubled 33 MHz CPU accessing memory and many
  718. other external components on a 32-bit bus, and so it will *execute* the
  719. instructions twice as fast as a 486DX-33 that's otherwise similarly equipped,
  720. and the 486DX-33 will operate considerably faster than a 386DX-33, for similar
  721. reasons (the 486 CPU is much faster). And, a 386DX-33 will run a darn sight
  722. faster overall than a 386SX-33 because the 386SX only has a 16- bit bus,
  723. meaning that fewer data can make it from memory to CPU and back in a given
  724. amount of time.
  725.  
  726.   None of which is worth a tinkerer's diddly if the system depends on a 120ms
  727. hard drive (today's standards are closer to 10ms) for programs and data file
  728. access - any such machine running Windows or compiling a massive project in C
  729. is going to run like four-banger Chevette with a tank full of molasses and
  730. three missing spark plugs.
  731.  
  732.   In general, no system ever performs any better than the least of its
  733. components.
  734.  
  735.   Using MHz as an indicator of speed might not be reliable, but it does
  736. furnish an important clue as to what kind of performance to expect. At this
  737. point in time, I would suspect that even if the 8088 itself were brought up to
  738. 66 MHz, its performance would be such that only the most uninitiated computer
  739. user (or economically burdened) would purchase such a machine; its actual
  740. processor throughput simply would not compare.
  741.  
  742.   The many other details of CPU construction, ones whose contributions simply
  743. cannot be compared with "indicators of speed" are also crucial to overall
  744. performance. Some of these include "instruction pipes" and "pre- fetch",
  745. others include the bus size and speed, speed of the video and disk subsystems,
  746. and no doubt other innovations will appear that I've not begun to imagine yet.
  747.  
  748.   Given these kinds of considerations, I ask again: could the 65* series of
  749. microprocessors be brought up to levels to handle today's demands?
  750.  
  751.   (Please say YES, and back it up! I'd LOVE to get back into 6502 assembly!)
  752.  ------------
  753. Category 2,  Topic 20
  754. Message 25        Sun Dec 04, 1994
  755. CMD-DOUG                     (Forwarded) 
  756.  
  757. YES, and get back to working with the 6502. ;)
  758.  
  759. Western Design Centers, who makes the 65816 and 65C02, rates the the 20 MHz
  760. 65816 as equal to a 33 MHz 386. They didn't state if this was a DX or SX, or
  761. at least I don't recall it. However, this is a rating of raw processing power,
  762. and I think it's important to note that the kind of software commonly used on
  763. 386-based MS-DOS machines these days is extremely inefficient. With most users
  764. of those machines running compiled software under Windows, which in turn is
  765. running on top of MS-DOS... well, I think you get the picture.
  766.  
  767. By the way, there IS a new supported method of rating different processor
  768. types against each other now, due to the comparisons going on between Pentium
  769. and PowerPC proponents. The new specifation is called SPEC. I don't have any
  770. details, though, but I've seen it talked about a little in a few recent
  771. articles, and have seen some of the comparison figures it yielded for the
  772. Pentium and PPC. But I doubt we'll see any comparisons with 6502's.
  773.  
  774. Is the 6502 a RISC processor? Technically, no. It's a pipelined processor. But
  775. the instruction set is so small and the pipelining is so efficient that I
  776. doubt if RISC implementation of a similarly powered processor would yield any
  777. relevent increase in throughput.
  778.  
  779. Is a 33 MHz version of the 6502 possible? Sure, if someone is willing to
  780. design a lower power, smaller channel version. The ability to increase the
  781. speed to 20 MHz has come through the latter, since WDC now uses a .8 micron
  782. process. Lowering the operating voltage makes going to a smaller process more
  783. feasable. New Pentiums and PPC processors are now being manufactured with a .6
  784. micron process, and at least new PPC's are due soon in a .4 micron version.
  785. The really high-speed pentiums are running at 3VDC now, I believe, instead of
  786. 5VDC. Not sure about the PPC voltages. Anyway, if WDC had the equipment and
  787. the desire, they've certainly got the know-how to create much faster versions
  788. of the 6502 and their other cousins. 
  789.  ------------
  790.  
  791. 2 |