6502 illegal opcodes questions
in [Commodore]
|
Prev: what happened CBM=VGA
Next: 1581 Drive Kits on eBay
From: John Selck on 22 May 2006 08:09 Stephen Harris wrote: > And now you've introduced program bloat, dual code paths, extra potential for > bugs... That's the way you handle low level stuff. All your Windows XP drivers are doing the same, and all the games which support SSE or MMX instructions. Doing it the "one routine works for every condition" way usually means 10 times slower programs.
From: Paul Schlyter on 22 May 2006 08:13 In article <446f7e4c$0$4512$9b4e6d93(a)newsread2.arcor-online.net>, Linards Ticmanis <ticmanis(a)gmx.de> wrote: > Paul Schlyter wrote: > >>> IIRC the S-JiffyDOS patch uses illegal opcodes to speed up GCR decoding. >>> (Jochen, are you reading here and can comment?) >> >> That can also be done without illegal opcodes. The Apple Pascal RWTS >> did it, and was able to read all sectors of a floppy on one revolution >> of the disk -- oncluding GCR decoding on-the-fly. > > But isn't Apple GCR a bit simpler than commodore GCR? Apple's 16-sector > format stores three data bytes per four disk bytes (3:4), Commodore gets > in four data bytes per five disk bytes (4:5) IIRC. Dunny about that. Apple 13-sector format stored 5 data bytes ber 8 disk bytes (5:8), which was less efficient than (3:4) --- still, the denibblizing code was a bit longer in the (5:8) case than the (3:4) case. -- ---------------------------------------------------------------- Paul Schlyter, Grev Turegatan 40, SE-114 38 Stockholm, SWEDEN e-mail: pausch at stockholm dot bostream dot se WWW: http://stjarnhimlen.se/
From: Paul Schlyter on 22 May 2006 08:43 In article <e4s9lm$r0g$1(a)rzsun03.rrz.uni-hamburg.de>, John Selck <selck_j(a)informatik.hgv-hamburg.de> wrote: >Stephen Harris wrote: > >> And now you've introduced program bloat, dual code paths, extra potential for >> bugs... > >That's the way you handle low level stuff. All your Windows XP drivers >are doing the same, and all the games which support SSE or MMX instructions. You can do that today, with GigaBytes of RAM available. But doing it on an Apple II, with 48k (or less) RAM is a waste of memory resources. >Doing it the "one routine works for every condition" way usually means >10 times slower programs. ....of course "10 times slower" doesn't matter much with today's fast processors. That's why Java has succeeded while UCSD Pascal failed, even though they both built upon the same concept: portable binary code which was to be interpreted on the target hardware. -- ---------------------------------------------------------------- Paul Schlyter, Grev Turegatan 40, SE-114 38 Stockholm, SWEDEN e-mail: pausch at stockholm dot bostream dot se WWW: http://stjarnhimlen.se/
From: John Selck on 23 May 2006 08:00 Paul Schlyter wrote: > You can do that today, with GigaBytes of RAM available. But doing it on > an Apple II, with 48k (or less) RAM is a waste of memory resources. Since you know what CPU your code is running on, nobody forces you to keep both routines in memory. > ...of course "10 times slower" doesn't matter much with today's fast > processors. That's why Java has succeeded while UCSD Pascal failed, > even though they both built upon the same concept: portable binary code > which was to be interpreted on the target hardware. It depends on what you do. If you do lot's of graphics and sound stuff, Java is definitely a bad choice.
From: Paul Schlyter on 23 May 2006 10:43
In article <e4utgf$f21$1(a)rzsun03.rrz.uni-hamburg.de>, John Selck <selck_j(a)informatik.hgv-hamburg.de> wrote: >Paul Schlyter wrote: >> You can do that today, with GigaBytes of RAM available. But doing it on >> an Apple II, with 48k (or less) RAM is a waste of memory resources. > >Since you know what CPU your code is running on, nobody forces you to >keep both routines in memory. Swapping pieces of code on/off to floppy disks would be QUITE slow... :-) >> ...of course "10 times slower" doesn't matter much with today's fast >> processors. That's why Java has succeeded while UCSD Pascal failed, >> even though they both built upon the same concept: portable binary code >> which was to be interpreted on the target hardware. > >It depends on what you do. If you do lot's of graphics and sound stuff, >Java is definitely a bad choice. In such a case, UCSD Pascal would be an even worse choice..... -- ---------------------------------------------------------------- Paul Schlyter, Grev Turegatan 40, SE-114 38 Stockholm, SWEDEN e-mail: pausch at stockholm dot bostream dot se WWW: http://stjarnhimlen.se/ |