Article 71069 of comp.sys.cbm: Path: news.acns.nwu.edu!newsfeed.acns.nwu.edu!news.luc.edu!chi-news.cic.net!199.60.229.3!newsfeed.direct.ca!nntp.portal.ca!news.bc.net!rover.ucs.ualberta.ca!news.ucalgary.ca!srv1.freenet.calgary.ab.ca!albrecht From: "Alvin R. Albrecht" Newsgroups: comp.sys.sinclair,comp.sys.cbm,comp.emulators.cbm Subject: Re: Spectrum Emulator for C64 Date: Sun, 6 Jul 1997 22:08:04 -0600 Organization: Calgary Free-Net Lines: 124 Message-ID: <5ppq5k$d3i@ds2.acs.ucalgary.ca> References: <339d8a2a.3224107@news.demon.co.uk> <5nsdcu$kue$6@triglav.iwaynet.net> <5nui21$aja@ds2.acs.ucalgary.ca> <33AEBF04.231@erols.com> <5or5go$bgf@argon.btinternet.com> <5p15us$p8d$1@gerry.cc.keele.ac.uk> Reply-To: "Alvin R. Albrecht" NNTP-Posting-Host: albrecht@srv1.freenet.calgary.ab.ca Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII In-Reply-To: Xref: news.acns.nwu.edu comp.sys.sinclair:40959 comp.sys.cbm:71069 comp.emulators.cbm:22675 On Mon, 30 Jun 1997, Bruce R. McFarling wrote: > On 27 Jun 1997, Spike wrote: > > Ahhhh, but the Z80 doesn't have a memory limit on the size of stack. > > You could quite easily have a stack 20K in size, if you wanted..... > > Why would you want, unless you were using a language with an > inefficient stack frame approach? 8-)# Obviously the 6502 assembly Flood fill, quicksort, lookahead for investigating strategies in games, the process of compiling, stack frames for compiled languages immediately come to mind. > BTW, how well does the stack pointer work at fetching an array in > ravel order when you use a ladder approach and perform transposes or > reverses by modifying the i, j, or k increment and first address location, > instead of by manipulating the array data? I'm still on the trail of the Don't use the stack for that: it's only good for linear arrays or saving variables since it lacks an SP-relative addressing mode (this is the reason for the IX/IY index registers, by the way. If IX=SP then you've got an SP-relative addressing mode, useful when compiling high level languages for a stack frame and, at the same time, the reason why compiled code on the z80 generally isn't that good). Instead, use HL or DE in the same way you'd use the indexed mode on the 6502 (L/E are index registers X/Y and H/D are 256 byte page identifiers). Then the cycle ratios will be <2.8:1. There will be savings in a z80 specific version rather than a translated 6502 version. > throughput advantage that was thought to be the case in the late 70's / > early 80's. Current list of suspects: > - applications relying on scattered memory references involve > register loading / restoring overhead in the Z80, maintained in place on > the zero-page in the 6502. This is an inner-loop / outer-loop problem, > so the question is whether inner loops are / were short or long Hmmm. An example? What kind of problem has randomly scattered memory references? > - Early on there was an incentive to write vanilla CP/M code, > which means within the limitations of the 8080. How much better throughput > does the Z80 have compared to the 8080? Is the roughly 4:1 comparison a There are cases where z80 code is faster than 8080 code, and that may involve the inner/outer loop problem you referred to above. Of the 4-5 examples done here so far, 2 of them made special use of z80 specific features. In my personal experience, I am usually concerned about writing compact code rather than fast code and that usually means 8080 compatible. > 6502 vs 8080 comparison that was applied to the Z80 before it was well > understood how much the Z80 added to the mix? If that was the case, what > divider would you apply to the 4 in the 4:1? I don't know. There's no way to generalize. The cycle ratio will be 1:1 with an 8080 quite often and depending on the problem could drop much lower. However, I do know that the cycle limit is 4.2:1 for emulation of the 6502's indexed addressing & branching. Operations on the accumulator occur at 2:1 ratios. 90% of the time, I do believe that emulating a 6502 can be done at <2.8:1. This does not involve special features of the z80 and also applies to the 8080. > - Z80 code that is relocatable can not be efficiently performed in > the 6502, but will there be a speed savings in the jump-table version? Of > course, there's a 6502 / 65C02 discrepency here, in that you can vector > the jump table in the 65C02 with the JMP (absolute,X) instruction There is a JP (HL) instruction on the z80. The ()'s are misleading as this normally means "contents of memory location" in z80 mnemonics. In this case, JP (HL) actually means JP HL - jump to address in HL. Alternatively, one could push a jump address on the stack and then do a RET: PUSH BC; RET. The 65C02's JMP (absolute,x) implements a jump vector table very cleanly vs. a z80 version which would require a table lookup: enter: HL=vector=x LD DE,absolute ; 10 ADD HL,DE ; 11 LD E,(HL) ; 7 INC L ; 4 LD D,(HL) ; 7 EX DE,HL ; 4 JP (HL) ; 4 > - there's the polish (soft o, not hard o) question: with the > hardware layouts of 6502 based machines more set in place precisely > *because* of the redirection limitations of the 6502, was there more > optimized-to-the-last-cycle assembler code for the 6502? Certainly the > action in the mid-80's seemed to be more in migrating Z80 code to the > 8086, while the action on the 6502 side was in expanding capabilities > within the hardware limitations of the millions of C64's being sold. There are z80 machines that have special hardware (display, sound whatever) designed for them. Half the early arcade machines were z80 based. The Spectrum is a very simple computer and that's the reason it was so cheap. Other z80 machines run the gammit from simple to complex. While the z80 crowd may have moved on to the 8086 fairly early (compared to the 6502 crowd), the user base (professional and otherwise) was just so much larger than the 6502 base. In Europe especially, the z80 lived on into the late 80's as the processor of choice for cheap home computers just as the 6502 lived on in the C64. > I don't know how to write a 16-bit BCD addition for the Z80, and > am not about to learn how to add the cycles (T cycles? M cycles? What's > the diff?). Just write one up: two positive numbers (it's sensible to T states = clock cycles M cycles = machine cycles and refer to various steps in instruction decode/execution. eg: M1 cycles are for opcode fetch and one M1 cycle is composed of 4 T states. Alvin Article 71260 of comp.sys.cbm: Path: news.acns.nwu.edu!newsfeed.acns.nwu.edu!news.luc.edu!chi-news.cic.net!howland.erols.net!newspump.sol.net!sol.net!spool.mu.edu!newsspool.sol.net!munnari.OZ.AU!news.mel.connect.com.au!harbinger.cc.monash.edu.au!news.cs.su.oz.au!metro!metro!seagoon.newcastle.edu.au!cc.newcastle.edu.au!ecbm From: "Bruce R. McFarling" Newsgroups: comp.sys.sinclair,comp.sys.cbm Subject: Re: Spectrum Emulator for C64 Date: Thu, 10 Jul 1997 19:31:20 +1000 Organization: The University of Newcastle Lines: 22 Message-ID: References: <339d8a2a.3224107@news.demon.co.uk> <5nsdcu$kue$6@triglav.iwaynet.net> <5nui21$aja@ds2.acs.ucalgary.ca> <33AEBF04.231@erols.com> <5or5go$bgf@argon.btinternet.com> <33BB3997.9FF@erols.com> <5pmi4v$q32@ds2.acs.ucalgary.ca> <33C497DB.7736@erols.com> NNTP-Posting-Host: cc.newcastle.edu.au Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII In-Reply-To: <33C497DB.7736@erols.com> Xref: news.acns.nwu.edu comp.sys.sinclair:41156 comp.sys.cbm:71260 On Thu, 10 Jul 1997, Greg King wrote: > ALL stacks are "restricted" (no stack can reach beyond a machine's > addressing range) -- I call that a pointless description! The Z80's > stack is limitted to 64k -- it's irrelevant that the program-counter > is limitted to the exact same length. > Size is the ONLY difference between the 6502's stack and the Z80's! And I had hoped that it had been settled for once and for all. I had thought that "restricted" meant, as in the normal sense of the word, restricted for that specific purpose above and beyond any normal restrictions. As in, there is no speed limit on the german Autogahn (except those imposed by the limitations of the car and the laws of phsyics). Under that interpretation, the 6502 stack is restricted, the Z80 is not, and both are relocatable. Virtually, Bruce R. McFarling, Newcastle, NSW ecbm@cc.newcastle.edu.au Article 71179 of comp.sys.cbm: Path: news.acns.nwu.edu!newsfeed.acns.nwu.edu!news.ece.nwu.edu!news.cse.psu.edu!uwm.edu!vixen.cso.uiuc.edu!howland.erols.net!europa.clark.net!dispatch.news.demon.net!demon!thespian.demon.co.uk!thespian.demon.co.uk!starglider From: The Starglider Newsgroups: comp.sys.sinclair,comp.sys.cbm Subject: Re: The C64 was much better than the Spectrum. Date: Wed, 9 Jul 1997 08:58:23 +0100 Organization: Starglider Productions Distribution: world Message-ID: References: <5pu7j2$m5l@lupin.csv.warwick.ac.uk> NNTP-Posting-Host: thespian.demon.co.uk X-NNTP-Posting-Host: thespian.demon.co.uk [194.222.59.42] MIME-Version: 1.0 X-Newsreader: Turnpike Version 3.00 Lines: 36 Xref: news.acns.nwu.edu comp.sys.sinclair:41058 comp.sys.cbm:71179 In article <5pu7j2$m5l@lupin.csv.warwick.ac.uk>, Andrew Clover writes >The C64 was much better than the >Spectrum. >The Spectrum's sprite's were > >shite. >Vector graphics on the Spectrum >were >bollocks. >That keyboard was > >absolute crap. >That one-channel sound was > >cat shit. >The Spectrum's memory was only >48K, >cack. > >C64 RULEZ ! SPECTRUM SUCKZ ! > >BCNU, AjC, > >PS. I only got four flames, as well. Tch. Is it me, or did all Commode users have terrible educations? Maybe that's why they could never spell. -- **************The Starglider**************** * E-Mail:starglider@thespian.demon.co.uk * * Web site:http://www.thespian.demon.co.uk * * NVG UPDATES:nvg@thespian.demon.co.uk * * ICQ Number:1773852 * _WW_ * WWPAGER:http://wwp.mirabilis.com/1773852 * /_ _\ ******************************************** | O O | ___________________________________________________________oOO_\/_OOo___________ Article 71453 of comp.sys.cbm: Path: news.acns.nwu.edu!merle!judd From: judd@merle.acns.nwu.edu (Stephen Judd) Newsgroups: comp.sys.sinclair,comp.sys.cbm Subject: Re: The C64 was much better than the Spectrum. Date: 14 Jul 1997 20:02:56 GMT Organization: Northwestern University, Evanston, IL Lines: 18 Message-ID: <5qe0lg$hoe@news.acns.nwu.edu> References: <5pu7j2$m5l@lupin.csv.warwick.ac.uk> Reply-To: sjudd@nwu.edu (Stephen Judd) NNTP-Posting-Host: merle.acns.nwu.edu Xref: news.acns.nwu.edu comp.sys.sinclair:41388 comp.sys.cbm:71453 In article , The Starglider wrote: >In article <5pu7j2$m5l@lupin.csv.warwick.ac.uk>, Andrew Clover > writes >>The C64 was much better than the >>Spectrum. >>The Spectrum's sprite's were >> >>shite. >Is it me, or did all Commode users have terrible educations? Maybe >that's why they could never spell. Why, quite simply because in high school we were all playing games on the 64 instead of doing homework, studying, etc. More evidence as to the superiority of the C64 and C64 games! -S Article 71701 of comp.sys.cbm: Path: news.acns.nwu.edu!newsfeed.acns.nwu.edu!news.ece.nwu.edu!news.cse.psu.edu!rutgers!cam-news-feed2.bbnplanet.com!news.bbnplanet.com!homer.alpha.net!mvb.saic.com!nntprelay.mathworks.com!europa.clark.net!feed1.news.erols.com!news.ecn.uoknor.edu!munnari.OZ.AU!metro!metro!seagoon.newcastle.edu.au!cc.newcastle.edu.au!ecbm From: "Bruce R. McFarling" Newsgroups: comp.sys.sinclair,comp.sys.cbm Subject: Re: Spectrum Emulator for C64 Date: Fri, 18 Jul 1997 18:05:21 +1000 Organization: The University of Newcastle Lines: 160 Message-ID: References: <339d8a2a.3224107@news.demon.co.uk> <5p15us$p8d$1@gerry.cc.keele.ac.uk> <11386.imc@comlab.ox.ac.uk> Reply-To: "Bruce R. McFarling" NNTP-Posting-Host: cc.newcastle.edu.au Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII In-Reply-To: <11386.imc@comlab.ox.ac.uk> Xref: news.acns.nwu.edu comp.sys.sinclair:41695 comp.sys.cbm:71701 And on the question of recursion (which I highly approve of when there is no danger of it being a stack hog: for instance, B-tree operations can be implemented with recursion with the number of items handled growing exponentially with respect to the depth of the recursion), the following is a non-recursive Towers of Hanoi. Of course, it's in Forth, but there are Forth's available for the C64, and I would assume for the spectrum as well. Virtually, Bruce R. McFarling, Newcastle, NSW ecbm@cc.newcastle.edu.au ************************************************************************ From hello@albany.net Fri Jul 18 18:04:54 1997 Date: Thu, 17 Jul 1997 20:21:48 -0400 From: Mary Murphy and Leo Wong Newsgroups: comp.lang.forth Subject: Non-Recursive Towers of Hanoi \ Non-Recursive Towers of Hanoi + \ Copyright 1997 Leo Wong MARKER Virtue \ aspirant's words : message ( a u -- ) 0 1 AT-XY TYPE ; : Wait ( -- ) KEY DROP ; : Enter ( -- ) S" Please (press) Enter." message ; : Quit? ( -- ) KEY? IF Wait Enter QUIT THEN ; : Number ( -- u ) 0. PAD DUP 10 ACCEPT -TRAILING >NUMBER 2DROP D>S ; 20 CONSTANT Max-Disks \ keep within screen depth Max-Disks 1+ \ ambiguous saying: CONSTANT Empty \ no disk is greater than any disk 0 VALUE Disks \ number of disks to move 0 VALUE Destination \ tower to end up on VARIABLE Moves \ tally \ towers of bramah CREATE Towers Max-Disks 1+ 3 * CHARS ALLOT : tower ( n -- addr ) Max-Disks 1+ * CHARS Towers + ; \ discern the top disk; if the tower is empty, disk = Empty : disk ( tower -- disk ) tower DUP C@ ?DUP IF CHARS + C@ ELSE DROP Empty THEN ; \ put a disk on a tower : push ( disk tower -- ) tower DUP C@ DUP Max-Disks = ABORT" Toppled tower" 1+ 2DUP SWAP C! CHARS + C! ; \ take the top disk from a tower : pop ( tower -- disk ) tower DUP C@ DUP 0= ABORT" Empty tower" 2DUP 1- SWAP C! CHARS + C@ ; \ the top of a tower on screen : taxy ( tower -- ) Disks OVER tower C@ - 2 + >R 5 * 2 + R> AT-XY ; \ appearances and disappearances : appear ( disk tower -- ) taxy 2 U.R ; : vanish ( tower -- ) taxy 2 SPACES ; : Moves? ( -- ) 1 Moves +! Moves @ 38 0 AT-XY U. ; \ move a disk from one tower to another, show move count : move-disk ( from-tower to-tower -- ) >R DUP vanish pop R> 2DUP push appear Moves? \ as if we had time: \ S" Press a key to continue." message Wait ; \ circular motion : East ( disk -- next-disk ) 1+ 3 MOD ; \ on odd moves, move the smallest disk over one 0 VALUE Tiny : Smallest ( -- ) Tiny DUP East DUP TO Tiny move-disk ; \ on even moves, make the only other possible move : Other ( -- ) Tiny East DUP East OVER disk OVER disk U> IF SWAP THEN move-disk ; \ more disks coming? : Incomplete ( -- flag ) Destination C@ Disks U< ; \ hanoi without recurse : Hanoi ( -- ) BEGIN Quit? Smallest Incomplete WHILE Other REPEAT ; \ ask how many disks to move : Request ( -- ) 0 BEGIN DROP CR CR ." Move how many disks from tower A to another tower?" CR ." Max = " Max-Disks . ." - 0 to quit. " Number DUP 0 Max-Disks 1+ WITHIN UNTIL TO Disks ; \ display the three towers : .Start ( -- ) PAGE ." Non-Recursive Towers of Hanoi - Moves=" Moves ? CR Disks 0 DO CR I 1+ 4 U.R LOOP CR ." A B C " S" Press a key to start." message Wait S" Press a key to quit. " message ; \ 1 (B) for an odd number of disks, else 2 (C) : Goal ( -- ) Disks 1 AND IF 1 ELSE 2 THEN tower TO Destination ; \ clear towers, add disks to A, zero moves, display towers : Start ( -- ) 0 0 tower C! 0 1 tower C! 0 2 tower C! Disks 0 DO Disks I - 0 push LOOP 0 TO Tiny Goal 0 Moves ! .Start ; \ non-recursive towers of hanoi : NTH ( -- ) BEGIN PAGE ." Non-Recursive Towers of Hanoi" Request Disks WHILE Start Hanoi S" DONE! Press a key to begin again." message Wait REPEAT ; NTH \ 17 July 1997 + \ Leo Wong \ -- \ hello@albany.net \ http://www.albany.net/~hello/ Article 71713 of comp.sys.cbm: Path: news.acns.nwu.edu!newsfeed.acns.nwu.edu!news.ece.nwu.edu!news.cse.psu.edu!uwm.edu!vixen.cso.uiuc.edu!howland.erols.net!cpk-news-hub1.bbnplanet.com!news.bbnplanet.com!baron.netcom.net.uk!netcom.net.uk!server3.netnews.ja.net!news.ox.ac.uk!news From: imc@ecs.ox.ac.uk (Ian Collier) Newsgroups: comp.sys.sinclair,comp.sys.cbm Subject: Re: Spectrum Emulator for C64 Date: 18 Jul 1997 13:34:06 GMT Organization: Oxford University Computing Laboratory Lines: 8 Message-ID: <11513.imc@comlab.ox.ac.uk> References: <339d8a2a.3224107@news.demon.co.uk> <11386.imc@comlab.ox.ac.uk> NNTP-Posting-Host: gruffle.comlab.ox.ac.uk X-Local-Date: Friday, 18th July 1997 at 2:34pm BST Xref: news.acns.nwu.edu comp.sys.sinclair:41698 comp.sys.cbm:71713 In article , "Bruce R. McFarling" wrote: >the following is a non-recursive Towers of Hanoi. Good heavens, it's rather longer than the one I posted the other day isn't it? :-) -- ---- Ian Collier : imc@comlab.ox.ac.uk : WWW page (including Spectrum section): ------ http://www.comlab.ox.ac.uk/oucl/users/ian.collier/imc.html Article 71910 of comp.sys.cbm: Path: news.acns.nwu.edu!newsfeed.acns.nwu.edu!news.luc.edu!chi-news.cic.net!207.22.81.9!europa.clark.net!cpk-news-hub1.bbnplanet.com!news.bbnplanet.com!baron.netcom.net.uk!netcom.net.uk!server3.netnews.ja.net!news.ox.ac.uk!news From: imc@ecs.ox.ac.uk (Ian Collier) Newsgroups: comp.sys.sinclair,comp.sys.cbm Subject: Re: Spectrum Emulator for C64 Date: 21 Jul 1997 17:11:35 GMT Organization: Oxford University Computing Laboratory, UK Lines: 17 Message-ID: <11533.imc@comlab.ox.ac.uk> References: <339d8a2a.3224107@news.demon.co.uk> <11386.imc@comlab.ox.ac.uk> <5qoq85$g9k@ds2.acs.ucalgary.ca> NNTP-Posting-Host: boothp2.ecs.ox.ac.uk X-Local-Date: Monday, 21st July 1997 at 6:11pm BST Xref: news.acns.nwu.edu comp.sys.sinclair:41860 comp.sys.cbm:71910 In article <5qoq85$g9k@ds2.acs.ucalgary.ca>, "Alvin R. Albrecht" wrote: >And for comparison, here's some pseudo-code for a recursive version of >the Towers of Hanoi problem: >Definitely easier to follow and formulate than the iterative versions >shown here. Also very short. Max recursion depth is N (64) levels. To be fair, almost all that forth code was window-dressing. The algorithm was: for i=1 to 2^n if i is odd then move the smallest disk clockwise else make the only other possible move. end -- ---- Ian Collier : imc@comlab.ox.ac.uk : WWW page (including Spectrum section): ------ http://www.comlab.ox.ac.uk/oucl/users/ian.collier/imc.html Article 72165 of comp.sys.cbm: Path: news.acns.nwu.edu!newsfeed.acns.nwu.edu!news.ece.nwu.edu!news.cse.psu.edu!rutgers!news.cis.ohio-state.edu!news.maxwell.syr.edu!howland.erols.net!infeed2.internetmci.com!newsfeed.internetmci.com!in3.uu.net!207.167.14.9!scanner.worldgate.com!rover.ucs.ualberta.ca!news.ucalgary.ca!srv1.freenet.calgary.ab.ca!albrecht From: "Alvin R. Albrecht" Newsgroups: comp.sys.sinclair,comp.sys.cbm Subject: Re: Spectrum Emulator for C64 Date: Sat, 26 Jul 1997 19:00:07 -0600 Organization: Calgary Free-Net Lines: 71 Message-ID: <5re6ka$6mg@ds2.acs.ucalgary.ca> References: <339d8a2a.3224107@news.demon.co.uk> <11386.imc@comlab.ox.ac.uk> <11513.imc@comlab.ox.ac.uk> NNTP-Posting-Host: albrecht@srv1.freenet.calgary.ab.ca Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII In-Reply-To: Xref: news.acns.nwu.edu comp.sys.sinclair:42189 comp.sys.cbm:72165 On Tue, 22 Jul 1997, Bruce R. McFarling wrote: > headers in the final code. And, of course, is towers of hanoi a good > example? How many words of return stack space does it require? (There is > no problem setting up a 256 word data stack on the 6502 using either the > X or Y register, so data stack space can't be the limiting factor) Probably not. The Towers of Hanoi problem, as posed, sets N=64 in the algorithm below: MOVE(n,a,b,c) ; move n disks from a to b using c if n=0 return MOVE(n-1,a,c,b) move a disk from a to b MOVE(n-1,c,b,a) return Which means there is a maximum call depth of 64 requiring storage of 128 bytes for return addresses. There are 4 variables (n,a,b,c) that need to be stored before each call requiring 4*64=256 bytes of storage. All fit nicely in a 6502, but the 256 byte retrieval has to be done using indexing, one source of cycle savings for a z80. Other algorithms where you don't know the depth of the recursion ahead of time may require you to write for the worst case (>256 byte call depth & >256 bytes for variables). The Towers problem is especially mild as you don't even have to save the registers in a stack before the call since all variables change in a predictable manner. The z80 version might look like: ; B=n, C=a, D=b, E=c MOVE RET Z 5/11 ; Z flag set by DECs before CALLs below ; if n=0 return LD A,D 4 ; MOVE(n-1,a,c,b) LD D,E 4 LD E,A 4 DEC B 4 CALL MOVE 17 ; move a disk from needle in C to needle in E (not shown) ; and note that the registers are still different from ; their entry. LD A,C 4 ; MOVE(n-1,c,b,a) LD C,D 4 LD D,E 4 LD E,A 4 INC B 4 ; make sure Z flag is properly set DEC B 4 CALL MOVE 17 INC B 4 ; restore registers to their LD A,C 4 ; entry values before return LD C,E 4 LD E,A 4 RET 10 Isn't it still less than 2:1 even when using absolute locations on the zp? Alvin