From imc@ecs.ox.ac.uk Sun Jun 22 10:09:00 CDT 1997 Article: 70050 of comp.sys.cbm Path: news.acns.nwu.edu!newsfeed.acns.nwu.edu!news.luc.edu!chi-news.cic.net!news.maxwell.syr.edu!dispatch.news.demon.net!demon!delos.dra.hmg.gb!server2.netnews.ja.net!server3.netnews.ja.net!server1.netnews.ja.net!warwick!bham!bhamcs!news.ox.ac.uk!news From: imc@ecs.ox.ac.uk (Ian Collier) Newsgroups: comp.sys.sinclair,comp.sys.cbm,comp.emulators.cbm Subject: Re: Spectrum Emulator for C64 Date: 20 Jun 1997 17:11:46 GMT Organization: Oxford University Computing Laboratory Message-ID: <11322.imc@comlab.ox.ac.uk> References: <33845f94.1768387@commodore64.com> <5nhubi$13l0@ds2.acs.ucalgary.ca> <5o1c2n$12lc@ds2.acs.ucalgary.ca> NNTP-Posting-Host: gruffle.comlab.ox.ac.uk X-Local-Date: Friday, 20th June 1997 at 6:11pm BST Lines: 9 Xref: news.acns.nwu.edu comp.sys.sinclair:40292 comp.sys.cbm:70050 comp.emulators.cbm:22009 In article <5o1c2n$12lc@ds2.acs.ucalgary.ca>, "Alvin R. Albrecht" wrote: >I agree but that doesn't mean the z80 isn't microcoded. The biggest >suggestion otherwise is the presence of undocumented instructions. The biggest suggestion otherwise is the sentence in Tanenbaum's book on computer architecture saying "The Z80 is not microcoded." :-) -- ---- Ian Collier : imc@comlab.ox.ac.uk : WWW page (including Spectrum section): ------ http://www.comlab.ox.ac.uk/oucl/users/ian.collier/imc.html From imc@ecs.ox.ac.uk Sun Jun 22 10:13:43 CDT 1997 Article: 70046 of comp.sys.cbm Path: news.acns.nwu.edu!newsfeed.acns.nwu.edu!news.luc.edu!chi-news.cic.net!news.maxwell.syr.edu!news-xfer.cybernet.dk!rill.news.pipex.net!pipex!server1.netnews.ja.net!warwick!bham!bhamcs!news.ox.ac.uk!news From: imc@ecs.ox.ac.uk (Ian Collier) Newsgroups: comp.sys.cbm,comp.sys.sinclair,comp.emulators.cbm Subject: Re: That Z80 line routine Date: 20 Jun 1997 17:27:25 GMT Organization: Oxford University Computing Laboratory Lines: 25 Message-ID: <11326.imc@comlab.ox.ac.uk> References: <5o00p9$gi9@news.acns.nwu.edu> <11304.imc@comlab.ox.ac.uk> <5o9uu7$d8f@news.acns.nwu.edu> NNTP-Posting-Host: gruffle.comlab.ox.ac.uk X-Local-Date: Friday, 20th June 1997 at 6:27pm BST Xref: news.acns.nwu.edu comp.sys.cbm:70046 comp.sys.sinclair:40287 comp.emulators.cbm:22006 In article , "Bruce R. McFarling" wrote: >On 19 Jun 1997, Stephen Judd wrote: >> The 6510 signals subtraction underflow by clearing the carry flag, and >> I assume the Z80 does something similar, > Is this right? It's been a decade, but I would have sworn that the >Z80 used a straight carry for borrow flag, rather than the 6502's inverted >carry. You are correct, as a described a few posts ago. But Stephen didn't claim that the Z80 was _exactly_ the same as the 6502. > So to subtract in 2's complement, you >can just invert all of the appropriate signals, use the add with carry >circuit, and invert the carry for a borrow. Hence, inverted carry as >borrow for subtract. > But, AFAIR, the Z80 doesn't do this: it does it the long way >around (hence the high gate count) Really? And what is the long way round? (If I were implementing it I would do it the way you said.) -- ---- Ian Collier : imc@comlab.ox.ac.uk : WWW page (including Spectrum section): ------ http://www.comlab.ox.ac.uk/oucl/users/ian.collier/imc.html From ecbm@cc.newcastle.edu.au Sun Jun 22 20:11:39 CDT 1997 Article: 70101 of comp.sys.cbm Path: news.acns.nwu.edu!newsfeed.acns.nwu.edu!math.ohio-state.edu!usc!howland.erols.net!news.maxwell.syr.edu!pumpkin.pangea.ca!news.mira.net.au!news.netspace.net.au!news.mel.connect.com.au!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,comp.emulators.cbm Subject: Re: Spectrum Emulator for C64 Date: Sun, 22 Jun 1997 17:28:07 +1000 Organization: The University of Newcastle Lines: 27 Message-ID: References: <33845f94.1768387@commodore64.com> <5nhubi$13l0@ds2.acs.ucalgary.ca> <5o1c2n$12lc@ds2.acs.ucalgary.ca> <5o4k56$aht@news.acns.nwu.edu> <5o75oi$14hc@ds2.acs.ucalgary.ca> <5od1oj$bgg@ds2.acs.ucalgary.ca> NNTP-Posting-Host: cc.newcastle.edu.au Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII In-Reply-To: <5od1oj$bgg@ds2.acs.ucalgary.ca> Xref: news.acns.nwu.edu comp.sys.sinclair:40343 comp.sys.cbm:70101 comp.emulators.cbm:22056 On Thu, 19 Jun 1997, Alvin R. Albrecht wrote: > On Thu, 19 Jun 1997, Bruce R. McFarling wrote: >... > > OTOH, the reason that it is still being used today is because of > > its efficiency. <4,000 gates leaves a hell of a lot of real estate on a > > chip mask: plenty for ample ROM, a good chunk of RAM for some zero page > > and stack page locations, a couple three special support circuits on the > > level of a VIA. > Efficiency? Low gate count you mean. The z80 is around because it is the > favoured discrete choice for controllers. An efficiency is an output divided by an input. As a core cell for an ASIC, a chip that can do what the 65C02 can do in <4,000 is efficient -- space efficiency, energy efficient, time efficient (the smaller the processor core, the easier to work around it) etc. As far as the Z180, if you start making next gen comparisons, you have to compare with the 65816 family. Which is a 'whole other discussion. Virtually, Bruce R. McFarling, Newcastle, NSW ecbm@cc.newcastle.edu.au From u5a77@teach.cs.keele.ac.uk Sun Jun 22 20:11:53 CDT 1997 Article: 70077 of comp.sys.cbm Path: news.acns.nwu.edu!newsfeed.acns.nwu.edu!news.luc.edu!uchinews!uwvax!uwm.edu!vixen.cso.uiuc.edu!ais.net!newsfeed.direct.ca!dispatch.news.demon.net!demon!delos.dra.hmg.gb!server2.netnews.ja.net!server6.netnews.ja.net!server1.netnews.ja.net!server5.netnews.ja.net!daresbury!keele!not-for-mail From: u5a77@teach.cs.keele.ac.uk (Spike) Newsgroups: comp.sys.sinclair,comp.sys.cbm,comp.emulators.cbm Subject: Re: Spectrum Emulator for C64 [additonal translation] Followup-To: comp.sys.sinclair,comp.sys.cbm,comp.emulators.cbm Date: 11 Jun 1997 12:47:07 GMT Distribution: world Message-ID: <5nm6ob$bjr$7@gerry.cc.keele.ac.uk> References: <337C5E94.388@actcom.co.il> <01bc6c89$ae5d4a00$04b8de8b@w9622136> <338EE6D2.23A6@tbaytel.net> <01bc6d0c$b90244a0$04b8de8b@w9622136> <5mmvp4$b7r@news.acns.nwu.edu> <5mvqq7$7qk$6@gerry.cc.keele.ac.uk> <9706102102.AA00g6t@cosine.demon.co.uk> NNTP-Posting-Host: bilbo.teach.cs.keele.ac.uk X-Newsreader: TIN [UNIX 1.3 950515BETA PL0] Lines: 24 Xref: news.acns.nwu.edu comp.sys.sinclair:40322 comp.sys.cbm:70077 comp.emulators.cbm:22035 Jason (tmr@cosine.demon.co.uk) wrote: : We can assign a whole 2K (256 character) font to that purpose and, if need : be, we can use multiple fonts. There are 27 possible charsets available... We can redesign every printable character as well, apart from special tokens, like keywords. (In other words, big deal, we don't get the full 256, but we could quite easily set up multiple font tables and have the computer access all of them when needed, and as each font only takes up about 800 bytes, we'd have a LOT of space for a large font bank.....) (It's just a matter of POKEing a couple of system variables that point to the font) -- | |What to do if you find yourself stuck in a crack| |u5a77@teach.cs.keele.ac.uk|in the ground beneath a giant boulder, which you| | |can't move, with no hope of rescue. | |Andrew Halliwell |Consider how lucky you are that life has been | |Principal Subjects in:- |good to you so far... | |Comp Sci & Electronics | -The BOOK, Hitch-hiker's guide to the galaxy.| ----------------------------------------------------------------------------- |GCv3.1 GCS/EL>$ d---(dpu) s+/- a- C++ U N++ o+ K- w-- M+/++ PS+++ PE- Y t+ | |5++ X+/++ R+ tv+ b+ D G e>PhD h/h+ !r! !y-|I can't say F**K either now! :( | From tmr@cosine.demon.co.uk Sun Jun 22 20:12:38 CDT 1997 Article: 70075 of comp.sys.cbm Path: news.acns.nwu.edu!newsfeed.acns.nwu.edu!news.luc.edu!chi-news.cic.net!feeder.chicago.cic.net!europa.clark.net!dispatch.news.demon.net!demon!mail2news.demon.co.uk!not-for-mail From: Jason Newsgroups: comp.sys.sinclair,comp.sys.cbm,comp.emulators.cbm Subject: Re: Spectrum Emulator for C64 [additonal translation] Followup-To: comp.sys.sinclair,comp.sys.cbm,comp.emulators.cbm Date: Sun, 22 Jun 97 15:57:36 GMT Organization: Cosine Systems Distribution: world Message-ID: <9706221557.AA00glr@cosine.demon.co.uk> References: <337C5E94.388@actcom.co.il> <5nn1cj$17j4@ds2.acs.ucalgary.ca> X-Mail2News-User: tmr@cosine.demon.co.uk X-Mail2News-Path: relay-1.mail.demon.net!gate.demon.co.uk!cosine.demon.co.uk X-Newsreader: TIN [AMIGA 1.3 950726BETA PL0] Lines: 22 Xref: news.acns.nwu.edu comp.sys.sinclair:40321 comp.sys.cbm:70075 comp.emulators.cbm:22034 The Starglider: > You obviously haven't seen uridium on the spectrum then (SMOOOOOTH!). Marc Walters: > Hmmm, You obviously haven't seen Uridium on the C64 then (SMOOOOTHER!). The Starglider: > Erm, I have, and nope, it didn't look any different to me. Have you considered an eye test? If you really think there's no difference between 17FPS and 50FPS I'll happily put together a little routine to put both on the screen at once and show you... =-) -- Jason =-) _______________________________________________________________________ TMR / / / / / / / /\ / /__/ / / /__/ / / / /__/ Email: tmr@cosine.demon.co.uk / / / /\_/ / /__ / / / / __// Cosine Homepage: / / / /__/ / / / / / / / / / http://www.cosine.demon.co.uk / / /_____/_____/_____/__/__/__/_____/_____________________________________/ / \_____\_____\_____\__\__\__\_____\_____________________________________\/ From imc@ecs.ox.ac.uk Mon Jun 23 01:03:44 CDT 1997 Article: 70051 of comp.sys.cbm Path: news.acns.nwu.edu!newsfeed.acns.nwu.edu!news.luc.edu!chi-news.cic.net!news.maxwell.syr.edu!news-peer.gsl.net!news-paris.gsl.net!news.gsl.net!newsfeed.cableol.net!server4.netnews.ja.net!server2.netnews.ja.net!server3.netnews.ja.net!server1.netnews.ja.net!warwick!bham!bhamcs!news.ox.ac.uk!news From: imc@ecs.ox.ac.uk (Ian Collier) Newsgroups: comp.sys.cbm,comp.sys.sinclair,comp.emulators.cbm Subject: Re: ...and a Z80 question Date: 20 Jun 1997 17:21:45 GMT Organization: Oxford University Computing Laboratory Lines: 27 Message-ID: <11324.imc@comlab.ox.ac.uk> References: <5o00p9$gi9@news.acns.nwu.edu> <5o3gmi$9er@yama.mcc.ac.uk> <11284.imc@comlab.ox.ac.uk> <5o904h$1k7@news.acns.nwu.edu> NNTP-Posting-Host: gruffle.comlab.ox.ac.uk X-Modified-on: Friday, 20th June 1997 at 6:21pm BST X-Local-Date: Friday, 20th June 1997 at 6:21pm BST Xref: news.acns.nwu.edu comp.sys.cbm:70051 comp.sys.sinclair:40295 comp.emulators.cbm:22013 In article <5o904h$1k7@news.acns.nwu.edu>, sjudd@nwu.edu (Stephen Judd) wrote: >Ahhh, I see now. Somehow I didn't realize that the Z80 graphics memory >was part of the normal RAM (I thought it might be ported or something). To be fair, you should say "Spectrum graphics". Who knows what someone somewhere might have attached to a Z80? :-) >Well, for what it's worth, a C64 version generally looks like: > LDY #00 > TYA >:LOOP STA BASE,Y ;BASE=$8000 say for bitmap at $8000 > STA BASE+256,Y > STA BASE+512,Y > ... [32 times] > INY > BNE :LOOP >...a little bit over 4 cycles/byte (which I still find oppressive since it >takes a total of like 2 frames). The Z80 stack-based version took a little over 5.5 cycles per byte, which is a clear winner at last. :-) At that rate it would take just over half a frame on a Spectrum. -- ---- Ian Collier : imc@comlab.ox.ac.uk : WWW page (including Spectrum section): ------ http://www.comlab.ox.ac.uk/oucl/users/ian.collier/imc.html From ecbm@cc.newcastle.edu.au Mon Jun 23 01:04:03 CDT 1997 Article: 70104 of comp.sys.cbm Path: news.acns.nwu.edu!newsfeed.acns.nwu.edu!math.ohio-state.edu!howland.erols.net!news.maxwell.syr.edu!pumpkin.pangea.ca!news.mira.net.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!metro!metro!seagoon.newcastle.edu.au!CC.newcastle.edu.au!ecbm From: "Bruce R. McFarling" Newsgroups: comp.sys.cbm,comp.sys.sinclair,comp.emulators.cbm Subject: Re: That Z80 line routine Date: Sun, 22 Jun 1997 17:35:14 +1000 Organization: The University of Newcastle Lines: 15 Message-ID: References: <5o00p9$gi9@news.acns.nwu.edu> <11304.imc@comlab.ox.ac.uk> <5o9uu7$d8f@news.acns.nwu.edu> <11326.imc@comlab.ox.ac.uk> NNTP-Posting-Host: cc.newcastle.edu.au Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII In-Reply-To: <11326.imc@comlab.ox.ac.uk> Xref: news.acns.nwu.edu comp.sys.cbm:70104 comp.sys.sinclair:40344 comp.emulators.cbm:22057 On 20 Jun 1997, Ian Collier wrote: > Really? And what is the long way round? (If I were implementing it I > would do it the way you said.) "Long way around" is probably a misleading way to say it. Inverting the carry flag internally, instead of simply specifying that the borrow flag is an inverted carry, prolly doesn't take more time, just extra gates. Virtually, Bruce R. McFarling, Newcastle, NSW ecbm@cc.newcastle.edu.au From sjudd@nwu.edu Mon Jun 23 01:04:08 CDT 1997 Article: 70119 of comp.sys.cbm Path: news.acns.nwu.edu!merle!judd From: judd@merle.acns.nwu.edu (Stephen Judd) Newsgroups: comp.sys.cbm,comp.sys.sinclair,comp.emulators.cbm Subject: Letter from Clive Date: 23 Jun 1997 05:21:22 GMT Organization: Northwestern University, Evanston, IL Lines: 7 Message-ID: <5ol14i$ihr@news.acns.nwu.edu> References: <5o00p9$gi9@news.acns.nwu.edu> <11326.imc@comlab.ox.ac.uk> Reply-To: sjudd@nwu.edu (Stephen Judd) NNTP-Posting-Host: merle.acns.nwu.edu Xref: news.acns.nwu.edu comp.sys.cbm:70119 comp.sys.sinclair:40346 comp.emulators.cbm:22063 There is a letter from Clive Sinclair in the latest (June 21) issue of The Economist. Just thought some of you Speccy guys might be interested... -S From sjudd@nwu.edu Mon Jun 23 01:05:19 CDT 1997 Article: 70120 of comp.sys.cbm Path: news.acns.nwu.edu!merle!judd From: judd@merle.acns.nwu.edu (Stephen Judd) Newsgroups: comp.sys.cbm,comp.sys.sinclair,comp.emulators.cbm Subject: Re: ...and a Z80 question Date: 23 Jun 1997 06:03:41 GMT Organization: Northwestern University, Evanston, IL Lines: 37 Message-ID: <5ol3jt$ioa@news.acns.nwu.edu> References: <5o00p9$gi9@news.acns.nwu.edu> <11284.imc@comlab.ox.ac.uk> <5o904h$1k7@news.acns.nwu.edu> <11324.imc@comlab.ox.ac.uk> Reply-To: sjudd@nwu.edu (Stephen Judd) NNTP-Posting-Host: merle.acns.nwu.edu Xref: news.acns.nwu.edu comp.sys.cbm:70120 comp.sys.sinclair:40347 comp.emulators.cbm:22064 In article <11324.imc@comlab.ox.ac.uk>, Ian Collier wrote: >In article <5o904h$1k7@news.acns.nwu.edu>, sjudd@nwu.edu (Stephen Judd) wrote: >>Ahhh, I see now. Somehow I didn't realize that the Z80 graphics memory >>was part of the normal RAM (I thought it might be ported or something). > >To be fair, you should say "Spectrum graphics". Hah, that's error #3 for me :). Time to start paying attention I guess :). >Who knows what someone >somewhere might have attached to a Z80? :-) I once knew a guy who put an 8-cylinder engine into his Z80, and... oops, wait, that was a 280Z. Yes indeed, there are some things just not worth speculating about. Who knows what sorts of things these degenerate Spectrum fiends might be trying out, late at night... fiddling with their 3.5" floppies... peeking, poking random locations, and otherwise practicing unsafe hex... What? Why are you all looking at me like that? >>...a little bit over 4 cycles/byte (which I still find oppressive since it >>takes a total of like 2 frames). > >The Z80 stack-based version took a little over 5.5 cycles per byte, which is >a clear winner at last. :-) At that rate it would take just over half a >frame on a Spectrum. Yep, no doat aboat it, Speccy clobbers the 64 on that one. evetS- >---- Ian Collier : imc@comlab.ox.ac.uk : WWW page (including Spectrum section): >------ http://www.comlab.ox.ac.uk/oucl/users/ian.collier/imc.html From ecbm@cc.newcastle.edu.au Mon Jun 23 19:48:40 CDT 1997 Article: 70159 of comp.sys.cbm Path: news.acns.nwu.edu!newsfeed.acns.nwu.edu!news.luc.edu!uchinews!cbgw2.lucent.com!uunet!in3.uu.net!206.154.70.8!news.webspan.net!feed1.news.erols.com!newsfeed.internetmci.com!news.maxwell.syr.edu!pumpkin.pangea.ca!news.mira.net.au!news.netspace.net.au!news.mel.connect.com.au!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,comp.emulators.cbm Subject: Re: Spectrum Emulator for C64 Date: Sun, 22 Jun 1997 17:32:54 +1000 Organization: The University of Newcastle Lines: 18 Message-ID: References: <33845f94.1768387@commodore64.com> <5nhubi$13l0@ds2.acs.ucalgary.ca> <5o1c2n$12lc@ds2.acs.ucalgary.ca> <11322.imc@comlab.ox.ac.uk> NNTP-Posting-Host: cc.newcastle.edu.au Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII In-Reply-To: <11322.imc@comlab.ox.ac.uk> Xref: news.acns.nwu.edu comp.sys.sinclair:40384 comp.sys.cbm:70159 comp.emulators.cbm:22089 On 20 Jun 1997, Ian Collier wrote: > In article <5o1c2n$12lc@ds2.acs.ucalgary.ca>, "Alvin R. Albrecht" wrote: > >I agree but that doesn't mean the z80 isn't microcoded. The biggest > >suggestion otherwise is the presence of undocumented instructions. > > The biggest suggestion otherwise is the sentence in Tanenbaum's book on > computer architecture saying "The Z80 is not microcoded." :-) No, the Z80 is not microcoded. Don't confuse the multi-phase interface to the memory bus with a "decode opcode, execute microcode' cycle. Virtually, Bruce R. McFarling, Newcastle, NSW ecbm@cc.newcastle.edu.au From junkmail@the.bin Mon Jun 23 23:13:11 CDT 1997 Article: 70147 of comp.sys.cbm Path: news.acns.nwu.edu!newsfeed.acns.nwu.edu!math.ohio-state.edu!cs.utexas.edu!news.maxwell.syr.edu!dispatch.news.demon.net!demon!mail2news.demon.co.uk!the.bin!dharkhig From: dharkhig@the.bin (Garry Lancaster) Newsgroups: comp.sys.sinclair,comp.sys.cbm,comp.emulators.cbm Subject: Re: Spectrum Emulator for C64 [additonal translation] Date: Sat, 21 Jun 97 01:39:23 GMT Message-ID: <866857163snz@the.bin> References: <01bc7d89$c9ed60a0$090000c0@pc-david> Reply-To: junkmail@the.bin X-Mail2News-User: dharkhig@the.bin X-Mail2News-Path: menaxus.demon.co.uk X-Newsreader: Demon Internet Simple News v1.30 Lines: 11 Xref: news.acns.nwu.edu comp.sys.sinclair:40377 comp.sys.cbm:70147 comp.emulators.cbm:22084 > I bet I can say which one runs at 50 fps and which one runs at 25 fps. > For things more complex I sure will not be able. > I bet you can't - PAL TV runs interlaced, so although it goes at 50Hz a full frame is only shown every 2 cycles, thus 25fps *not* 50fps. -- Garry Lancaster Z88 Forever! Homepage: http://www.netforward.com/deathsdoor/?dharkhig Email: dharkhig at deathsdoor.com (replace " at " with "@") From tmr@cosine.demon.co.uk Mon Jun 23 23:14:13 CDT 1997 Article: 70164 of comp.sys.cbm Path: news.acns.nwu.edu!newsfeed.acns.nwu.edu!news.ece.nwu.edu!news.cse.psu.edu!rutgers!usenet.logical.net!news.radio.cz!nntprelay.mathworks.com!howland.erols.net!europa.clark.net!dispatch.news.demon.net!demon!mail2news.demon.co.uk!not-for-mail From: Jason Newsgroups: comp.sys.sinclair,comp.sys.cbm,comp.emulators.cbm Subject: Re: Spectrum Emulator for C64 [additonal translation] Date: Mon, 23 Jun 97 20:00:06 GMT Organization: Cosine Systems Distribution: world Message-ID: <9706232000.AA00gnu@cosine.demon.co.uk> References: <337C5E94.388@actcom.co.il> <01bc6c89$ae5d4a00$04b8de8b@w9622136> <338EE6D2.23A6@tbaytel.net> <01bc6d0c$b90244a0$04b8de8b@w9622136> <5mmvp4$b7r@news.acns.nwu.edu> <5mvqq7$7qk$6@gerry.cc.keele.ac.uk> <9706102102.AA00g6t@cosine.demon.co.uk> <5 X-Mail2News-User: tmr@cosine.demon.co.uk X-Mail2News-Path: relay-1.mail.demon.net!gate.demon.co.uk!cosine.demon.co.uk X-Newsreader: TIN [AMIGA 1.3 950726BETA PL0] Lines: 25 Xref: news.acns.nwu.edu comp.sys.sinclair:40390 comp.sys.cbm:70164 comp.emulators.cbm:22090 Spike: > (In other words, big deal, we don't get the full 256, but we could quite > easily set up multiple font tables and have the computer access all of them > when needed, and as each font only takes up about 800 bytes, we'd have a LOT > of space for a large font bank.....) So do we if we're only using 100 characters. > (It's just a matter of POKEing a couple of system variables that point to > the font) Yeah, but if I do one POKE every single character on the screen can change to the new font at the point that the command finishes executing. We're not just pointing to a new font, we're refreshing *all* of the stuff displayed in the old font as well. -- Jason =-) _______________________________________________________________________ TMR / / / / / / / /\ / /__/ / / /__/ / / / /__/ Email: tmr@cosine.demon.co.uk / / / /\_/ / /__ / / / / __// Cosine Homepage: / / / /__/ / / / / / / / / / http://www.cosine.demon.co.uk / / /_____/_____/_____/__/__/__/_____/_____________________________________/ / \_____\_____\_____\__\__\__\_____\_____________________________________\/ From tmr@cosine.demon.co.uk Mon Jun 23 23:15:05 CDT 1997 Article: 70165 of comp.sys.cbm Path: news.acns.nwu.edu!newsfeed.acns.nwu.edu!news.ece.nwu.edu!news.cse.psu.edu!rutgers!usenet.logical.net!news.radio.cz!europa.clark.net!dispatch.news.demon.net!demon!mail2news.demon.co.uk!not-for-mail From: Jason Newsgroups: comp.sys.sinclair,comp.sys.cbm,comp.emulators.cbm Subject: Re: Spectrum Emulator for C64 [additonal translation] Followup-To: comp.sys.sinclair,comp.sys.cbm,comp.emulators.cbm Date: Mon, 23 Jun 97 20:11:03 GMT Organization: Cosine Systems Distribution: world Message-ID: <9706232011.AA00gnz@cosine.demon.co.uk> References: <337C5E94.388@actcom.co.il> <5nn1cj$17j4@ds2.acs.ucalgary.ca> X-Mail2News-User: tmr@cosine.demon.co.uk X-Mail2News-Path: relay-1.mail.demon.net!gate.demon.co.uk!cosine.demon.co.uk X-Newsreader: TIN [AMIGA 1.3 950726BETA PL0] Lines: 42 Xref: news.acns.nwu.edu comp.sys.sinclair:40391 comp.sys.cbm:70165 comp.emulators.cbm:22091 Jason =-) > Have you considered an eye test? If you really think there's no difference > between 17FPS and 50FPS I'll happily put together a little routine to > put both on the screen at once and show you... =-) The Starglider: > I VERY much doubt that the C64 Uridium runs at 50 fps. I mean, with the > VIC chip doing the sprites and the processor dealing with the rest, > there is not enough processor power in a C64 to do all that at 50fps. Now before I start to *really* take the piss are you sure you don't want to take that back? Okay, I can state now, with no doubts in my mind whatsoever that the C64 version of Uridium runs at a steady 50FPS. Since Uridium is quite simple compared to, say, Armalyte or IO (both of which better it for the number of hardware and software sprites onscreen and still maintain full framerate) it's a simple matter to get that kind of job going at 50FPS. Any half decent scroll routine can shuffle 1,000 bytes of data to the screen a frame and that's enough to move the scrolling area Urid uses and a bit more besides. There are only eight hardware sprites in use (Manta, shadow, five nasties and uridimine), the ship's bullets are chars, a little bit of background definition is copied in and they're mapped over it and the stars are just chars again. Most C64 coders would be *laughed at* if their code dropped below full framerate, it's something that (short of 3D stuff, which obviously takes a little longer) is *expected* of us. Despite your claims, the human eye *is* perfectly capable of noting the difference between 17FPS, 25FPS and 50FPS and if you like I can happily put a little routine together that scrolls the top twelve lines of the screen at 50FPS and the bottom at 25FPS to prove the point. -- Jason =-) _______________________________________________________________________ TMR / / / / / / / /\ / /__/ / / /__/ / / / /__/ Email: tmr@cosine.demon.co.uk / / / /\_/ / /__ / / / / __// Cosine Homepage: / / / /__/ / / / / / / / / / http://www.cosine.demon.co.uk / / /_____/_____/_____/__/__/__/_____/_____________________________________/ / \_____\_____\_____\__\__\__\_____\_____________________________________\/ From sjudd@nwu.edu Tue Jun 24 09:24:30 CDT 1997 Article: 70171 of comp.sys.cbm Path: news.acns.nwu.edu!merle!judd From: judd@merle.acns.nwu.edu (Stephen Judd) Newsgroups: comp.sys.cbm,comp.sys.sinclair,comp.emulators.cbm Subject: Re: Letter from Clive Date: 24 Jun 1997 04:52:11 GMT Organization: Northwestern University, Evanston, IL Lines: 29 Message-ID: <5onjpr$j8r@news.acns.nwu.edu> References: <5o00p9$gi9@news.acns.nwu.edu> <5ol14i$ihr@news.acns.nwu.edu> <5om128$ejg@argon.btinternet.com> Reply-To: sjudd@nwu.edu (Stephen Judd) NNTP-Posting-Host: merle.acns.nwu.edu Xref: news.acns.nwu.edu comp.sys.cbm:70171 comp.sys.sinclair:40393 comp.emulators.cbm:22095 In article <5om128$ejg@argon.btinternet.com>, Geoff wrote: > Stephen Judd wrote in article <5ol14i$ihr@news.acns.nwu.edu>... >> >>There is a letter from Clive Sinclair in the latest (June 21) issue >>of The Economist. >> >>Just thought some of you Speccy guys might be interested... > >Scan it in!!!!!! Well, to be honest, it's a very short letter and not of any profound importance, just one of those points of interest speckling the 8-bit landscape. Besides, posting it would undermine my subversive attempt to get more people to read The Economist :). One of the few news magazines worth more than the paper it is printed on. ...to take part in "a severe contest between intelligence, which presses forward, and an unworthy, timid ignorance obstructing our progress." e v e t S - >Geoff From gngking@erols.com Tue Jun 24 09:24:49 CDT 1997 Article: 70200 of comp.sys.cbm Path: news.acns.nwu.edu!newsfeed.acns.nwu.edu!news.ece.nwu.edu!news.cse.psu.edu!uwm.edu!chi-news.cic.net!newsfeed.internetmci.com!europa.clark.net!feed1.news.erols.com!news From: Greg King Newsgroups: comp.sys.cbm,comp.sys.sinclair,comp.emulators.cbm Subject: Re: That Z80 line routine Date: Tue, 24 Jun 1997 03:31:25 -0700 Organization: . Lines: 18 Message-ID: <33AFA1FD.4A9A@erols.com> References: <5o00p9$gi9@news.acns.nwu.edu> <11304.imc@comlab.ox.ac.uk> <5o9uu7$d8f@news.acns.nwu.edu> <5oh7bt$6kn@news.acns.nwu.edu> NNTP-Posting-Host: spg-as50s54.erols.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Received-On: 24 Jun 1997 04:46:10 GMT X-Mailer: Mozilla 2.02 (Win16; I) Xref: news.acns.nwu.edu comp.sys.cbm:70200 comp.sys.sinclair:40405 comp.emulators.cbm:22111 Stephen Judd wrote: > In article , > Bruce R. McFarling wrote: > >On 19 Jun 1997, Stephen Judd wrote: > >> The 6510 signals subtraction underflow by clearing the carry flag, and > >> I assume the Z80 does something similar, so the CP H gets taken care of > >> automatically by the subtraction. And since you're subtracting, you never > >> have problems with overflow, so the JR C,Diag isn't necessary either. > > > > Is this right? > > Since it was a question based on my deep and profound general ignorance > on most matters, it is probably not, indeed is not, right. :) "They" use Carry for both add and subtract. "We" use Carry for add, and Borrow for subtract. (The mnemonic really should be SBB.) From sjudd@nwu.edu Tue Jun 24 09:33:19 CDT 1997 Article: 70170 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,comp.emulators.cbm Subject: Re: Spectrum Emulator for C64 Date: 24 Jun 1997 04:37:09 GMT Organization: Northwestern University, Evanston, IL Lines: 26 Message-ID: <5onitl$irl@news.acns.nwu.edu> References: <33845f94.1768387@commodore64.com> <5od1oj$bgg@ds2.acs.ucalgary.ca> <5oh74b$6k5@news.acns.nwu.edu> Reply-To: sjudd@nwu.edu (Stephen Judd) NNTP-Posting-Host: merle.acns.nwu.edu Xref: news.acns.nwu.edu comp.sys.sinclair:40392 comp.sys.cbm:70170 comp.emulators.cbm:22094 In article <5oh74b$6k5@news.acns.nwu.edu>, Stephen Judd wrote: >In article <5od1oj$bgg@ds2.acs.ucalgary.ca>, >Alvin R. Albrecht wrote: >>There is >>a point of diminishing returns. In my experience, for > >Ah, an interesting point: what does your experience in these matters >consist of? That is, what kinds of programs have you written, and >how large/involved were they? Z80 assembly programs of course. >>This >>is your 4:1 number popping up if the z80 acts like a 6502. > >You just don't seem to get it: Bruce is saying, "Based on the Ugggghhhh... Well, for what it's worth, I actually don't give a flying rat's butt about any experience, etc. and I think from now on I will try to just stick to the technical side of things, and otherwise await your code in textual silence. Sigh... it's time for me to retreat from the verbal battlefront, I'm too wound up in it. -S From albert@isosotka.uucp Tue Jun 24 17:15:59 CDT 1997 Article: 70242 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!newsfeed.sovam.com!sovam!Gamma.RU!srcc!Radio-MSU.net!news.RUNNet.ru!news.funet.fi!news.cs.tut.fi!isosotka!albert From: albert@isosotka.uucp (Ojala Pasi 'Albert') Newsgroups: comp.sys.sinclair,comp.sys.cbm,comp.emulators.cbm Subject: Re: Spectrum Emulator for C64 [additonal translation] Date: 24 Jun 1997 13:22:34 GMT Organization: Tampere University of Technology Lines: 17 Distribution: inet Message-ID: <5oohmq$rq3@peippo.cs.tut.fi> References: <01bc7d89$c9ed60a0$090000c0@pc-david> <866857163snz@the.bin> NNTP-Posting-Host: isosotka.cs.tut.fi NNTP-Posting-User: albert Xref: news.acns.nwu.edu comp.sys.sinclair:40433 comp.sys.cbm:70242 comp.emulators.cbm:22130 In article <866857163snz@the.bin>, Garry Lancaster wrote: >I bet you can't - PAL TV runs interlaced, so although it goes at 50Hz >a full frame is only shown every 2 cycles, thus 25fps *not* 50fps. C64 outputs non-interlaced video signal (composite or chroma-luma), thus it is 50Hz progressive, *not* 25Hz interlaced. In this case field==frame, because there is no interlacing, and you get 'very' large black lines between active lines on the monitor/tv. Well, actually *more* than twice as wide than on interlaced display. -Pasi -- "So, how did you find about all of this?" "I'm .. a telepath. .. Work it out." -- Sheridan and Bester in Babylon 5:"Ship of Tears" From albrecht@freenet.calgary.ab.ca Tue Jun 24 17:29:49 CDT 1997 Article: 70223 of comp.sys.cbm Path: news.acns.nwu.edu!newsfeed.acns.nwu.edu!news.ece.nwu.edu!news.cse.psu.edu!rutgers!usenet.logical.net!news.radio.cz!nntp.uio.no!news.maxwell.syr.edu!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 [additonal translation] Date: Mon, 23 Jun 1997 17:39:48 -0600 Organization: Calgary Free-Net Lines: 57 Message-ID: <5on1ik$s4e@ds2.acs.ucalgary.ca> References: <337C5E94.388@actcom.co.il> <5nn1cj$17j4@ds2.acs.ucalgary.ca> <9706221557.AA00glr@cosine.demon.co.uk> <33AE970F.621A@arkanixlabs.com> NNTP-Posting-Host: albrecht@srv1.freenet.calgary.ab.ca Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII In-Reply-To: <33AE970F.621A@arkanixlabs.com> Xref: news.acns.nwu.edu comp.sys.sinclair:40424 comp.sys.cbm:70223 comp.emulators.cbm:22120 On Mon, 23 Jun 1997, Robin Harbron wrote: > I don't understand why you say "with the VIC chip doing the sprites" > as if it slows down the machine... that is precisely why our machine > can do games faster than your "faster" spectrum. Sounds like for > these sorts of games in particular, our machine is at least 3 times > faster than your machine. And 17 fps is a great achievement? 4 or > 5 times faster then... It kind of feels like words are being put in our mouths or else we have been misunderstood. The hardware gives the C64 a 50fps rate (and it must do this to avoid flickering which would occur otherwise if a sprite were drawn and then absent on alternating frames, for example) and it is done independently of the processor, so of course it's "done for free" (though not really as the VIC steals 50% of the 6502's cycles - the reason why the C64 is clocked at an effective 1MHz rather than 2). The frame rate is a flexible number on a Spectrum. What your are going to achieve depends on how many sprites you have, how big they will be and whatever else is going on: it all depends on processor speed. At 3.54MHz with a 10fps target, you have 354000 cycles to play with. Now, to get 8 sprites of 21x24 size moving around is easy in 354000 cycles. To get 8 sprites + animated background is a little harder. To get 21x48 sprites (on C64, start doubling # sprites using scan line interrupts) + animated background takes more cycles, etc. etc. Eventually you can't do more and maintain the 10fps target. At a 50fps target, you have 70800 cycles. You can still do things at a 50fps rate, but what can be done will be much reduced. No one has ever claimed that the software sprites are done faster on a Spectrum than they are done in hardware on the C64. What has been the claim is that the hardware was a substitute for processor speed on the C64 and the suggestion was the "faster" Spectrum could overcome the hardware deficiency (ah I see the confusion: we are not claiming a 50fps rate here). There seems to be some contention here whether a 3.54MHz z80 is in fact faster than a 1MHz 6502, but we have offered evidence of this in the case of some types of software: games where the graphics are not necessarily amenable to the use of the C64 hardware and therefore must be done in the same way as on the Spectrum, in software, plotting onto a bitmap. These were games like the 3d isometrics (Head over Heels, the author of which has already posted here that it wasn't easy getting a C64 to do it), the filled polygon 1st person perspective ones which are slower on the C64 or are not done in 3d at all (Carrier Command was 2d on the C64: someone in the C64 camp did say that it was 3d on the C64, but I have seen it in 2d running on a 64: load it up and try it: if you say it's 3d, I'll believe it) and the vector graphics ones (Starglider) - Stephen has an interest in this last one and wants to see the z80 versions of fast multiply and fast draw to validate this claim. Alvin From albert@isosotka.uucp Tue Jun 24 23:23:01 CDT 1997 Article: 70264 of comp.sys.cbm Path: news.acns.nwu.edu!newsfeed.acns.nwu.edu!news.luc.edu!chi-news.cic.net!howland.erols.net!news-peer.sprintlink.net!news.sprintlink.net!Sprint!news.maxwell.syr.edu!news-xfer.cybernet.dk!news.kolumbus.fi!news.funet.fi!news.cs.tut.fi!isosotka!albert From: albert@isosotka.uucp (Ojala Pasi 'Albert') Newsgroups: comp.sys.sinclair,comp.sys.cbm,comp.emulators.cbm Subject: Re: Spectrum Emulator for C64 [additonal translation] Date: 24 Jun 1997 20:00:04 GMT Organization: Tampere University of Technology Lines: 34 Distribution: inet Message-ID: <5op904$t87@peippo.cs.tut.fi> References: <337C5E94.388@actcom.co.il> <33AE970F.621A@arkanixlabs.com> <5on1ik$s4e@ds2.acs.ucalgary.ca> NNTP-Posting-Host: isosotka.cs.tut.fi NNTP-Posting-User: albert Xref: news.acns.nwu.edu comp.sys.sinclair:40454 comp.sys.cbm:70264 comp.emulators.cbm:22147 In article <5on1ik$s4e@ds2.acs.ucalgary.ca>, Alvin R. Albrecht wrote: >independently of the processor, so of course it's "done for free" (though >not really as the VIC steals 50% of the 6502's cycles - the reason why >the C64 is clocked at an effective 1MHz rather than 2). Not exactly true. The 6510 on the C64 IS clocked at 1MHz, but it only accesses memory on the latter cycle-half, thus VIC can access the memory on the other cycle-half. I.e. the memory has 500ns access time so that both VIC and 6510 can access it at 1MHz. So, 6510 effective clock rate is the same as it's actual clock rate, 1MHz. However, VIC does steal cycles from the 6510 on occasions where it needs more memory bandwidth than that. 40 cycles for each character row (25 per frame) to fetch the character codes (and colors) and 2 cycles for each sprite where it is displayed to fetch the other two bytes of sprite data (data pointer and 1 byte of sprite data are fetched on VIC's cycle-half). There are very good documents about C64 on the net, so please check before you write as a seemingly fact something you think you heard 10 years ago. Unfortunately this is a problem with a lot of the discussion here and there.. And please, write shorter paragraphs. It makes it much easier to read your posts. -Pasi -- "Nothing. I saw .. nothing." -- Londo in Babylon 5:"The Fall of Night" From yurik@erupt.com Tue Jun 24 23:23:27 CDT 1997 Article: 70262 of comp.sys.cbm Path: news.acns.nwu.edu!newsfeed.acns.nwu.edu!news.luc.edu!uchinews!cbgw2.lucent.com!uunet!in3.uu.net!204.27.65.11!news-out.communique.net!communique!demos!news.maxwell.syr.edu!ix.netcom.com!tor-nn1.netcom.ca!news From: Repose/Style Newsgroups: comp.sys.sinclair,comp.sys.cbm,comp.emulators.cbm Subject: Re: Spectrum Emulator for C64 [additonal translation] Date: Mon, 23 Jun 1997 14:02:30 -0300 Organization: Netcom Canada Lines: 59 Message-ID: <33AEAC26.6E6C@erupt.com> References: <337C5E94.388@actcom.co.il> <5nn1cj$17j4@ds2.acs.ucalgary.ca> <5npjud$2rv@news.acns.nwu.edu> <5nunbg$t3e@ds2.acs.ucalgary.ca> <5o4iuv$a5s@news.acns.nwu.edu> <5o73r9$mrs@ds2.acs.ucalgary.ca> <01bc7cab$49a47de0$090000c0@pc-david> <5ochi1$fme@ds2.acs.ucalgary.ca> <01bc7d89$c9ed60a0$090000c0@pc-david> NNTP-Posting-Host: hal-ns1-44.netcom.ca Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-NETCOM-Date: Mon Jun 23 1:02:37 PM EDT 1997 X-Mailer: Mozilla 3.01 (Win95; I) Xref: news.acns.nwu.edu comp.sys.sinclair:40451 comp.sys.cbm:70262 comp.emulators.cbm:22145 > What's the point? The human eye cannot only works at about 18-20 fps (if > you can call it that) anyway, so there will be no advantage in doing > anything faster. > -- > **************The Starglider**************** I must protest about all this misinformation on the human visual system :) There seems to be a popular myth that the eye can only see 30fps. Well that is just false, but like all myths, it does have a basis somewhere. In textbooks you might read that your eye has a *persistence of vision* of about 1/30th of a second. So many people take this to mean you can only see 30fps, but that is not what it means. POV means that when light hits your eye, the chemicals in it take some time to react to the stimulus. It means that an image flashed on your eye will remain visible after it is gone, as an aftereffect of the chemicals reacting. The image will remain for about 1/30th of a second while it fades away and the chemicals react to the new scene (darkness, or the next image.. whatever). But there's a lot more to it than "meets the eye" :)). You have two types of sensors in your eye, rods and cones. Rods are designed to be sensitive to motion and contrast, and only see in grey. They also see better in low light conditions. They are quicker at responding to light. Cones come in several types which can see colors. They are less quick to sense. And there is more to it than that. Further up, in various phases of vision processing, different elements are extracted at different speeds. For example, you can recognize the difference between a solid circle and a doughnut or hollow circle if it's very bright when it's flashed on your eye for only 1/1000th of a second! On the slow side, you can recognize a letter or scene that is rotated proportional to the amount that it is rotated, which can take up to several 10ths of a second. And about motion blur: it's created naturally by the lag of the chemicals in your eye responding to light. Say one frame is displayed, sometime later, the image is registered in terms of chemical reactions and electrical impulses. Then the next frame comes; it is additive and blends on top of the previous reactions, which causes a blurring effect. One final proof that the myth is false. How could a baseball player or tennis player hit balls coming at 90mph when your eye could only seea frame rate of 30fps?? The answer is the speed of motion detection in the rods. In short, when considering computer animation, whatever looks good is the answer. It's generally accepted that 15fps looks ok to most people, but of course it's a continuous scale and not fixed at all. When I watch films, which have 24fps I can see chopiness when the camera is panning. Btw, films also flicker at 72fps, that is, they open and close the shutter 3 times for each frame. I can see NTSC TV flicker as well, and the flicker you would notice is 30fps, caused by sharp contract between an even and odd line. Finally, I can see a flourescent lamp flicker at 60fps. Even the white on my computer screen now if flickering at 60fps. An easy way to tell what your threshold animation rate is, is flashing a light at a controlled speed, and panning your eye across the light. If you see the trail of dots then it's going too slow. As your eye moves from left to right, the light flashes on different spots on your eyeball, and you will see a trail of different lights. Also try looking at your favorite IFLI graphic. If you look at it with your eyes steady, it doesn't flicker too much, but move your eyes around, and it flickers much worse. From simonc@jumper.mcc.ac.uk Tue Jun 24 23:23:30 CDT 1997 Article: 70263 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!howland.erols.net!news.maxwell.syr.edu!nildram!Aladdin!aladdin.net!ns2.aladdin.net!RMplc!rmplc.co.uk!yama.mcc.ac.uk!simonc From: simonc@jumper.mcc.ac.uk (Cookie) Newsgroups: comp.sys.sinclair,comp.sys.cbm,comp.emulators.cbm Subject: Re: Spectrum Emulator for C64 [additonal translation] Followup-To: comp.sys.sinclair,comp.sys.cbm,comp.emulators.cbm Date: 24 Jun 1997 21:46:13 GMT Organization: Sirius Cybernetics Corporation Lines: 15 Distribution: world Message-ID: <5opf75$mic@yama.mcc.ac.uk> References: <337C5E94.388@actcom.co.il> <5nn1cj$17j4@ds2.acs.ucalgary.ca> NNTP-Posting-Host: jumper.mcc.ac.uk X-Newsreader: TIN [version 1.2 PL2] Xref: news.acns.nwu.edu comp.sys.sinclair:40453 comp.sys.cbm:70263 comp.emulators.cbm:22146 The Starglider (starglider@thespian.demon.co.uk) wrote: : What's the point? The human eye cannot only works at about 18-20 fps (if : you can call it that) anyway, so there will be no advantage in doing : anything faster. Not completely true... look at a monitor or a TV out of the corner of your eye -- you'll see flicker. Rods are more sensitive to motion than cones, and appear to react faster... ...but of course, it's true enough for the purposes explained here. BTW: For some reason, 50fps LOOKS smoother than 25fps. That is, on systems which don't interlace the picture. Go figure. Simon From sjudd@nwu.edu Tue Jun 24 23:23:54 CDT 1997 Article: 70243 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,comp.emulators.cbm Subject: Re: Spectrum Emulator for C64 [additonal translation] Date: 24 Jun 1997 22:29:41 GMT Organization: Northwestern University, Evanston, IL Lines: 43 Message-ID: <5ophol$arr@news.acns.nwu.edu> References: <337C5E94.388@actcom.co.il> <33AE970F.621A@arkanixlabs.com> <5on1ik$s4e@ds2.acs.ucalgary.ca> Reply-To: sjudd@nwu.edu (Stephen Judd) NNTP-Posting-Host: merle.acns.nwu.edu Xref: news.acns.nwu.edu comp.sys.sinclair:40436 comp.sys.cbm:70243 comp.emulators.cbm:22131 In article <5on1ik$s4e@ds2.acs.ucalgary.ca>, Alvin R. Albrecht wrote: >On Mon, 23 Jun 1997, Robin Harbron wrote: > >> I don't understand why you say "with the VIC chip doing the sprites" >> as if it slows down the machine... that is precisely why our machine >> can do games faster than your "faster" spectrum. Sounds like for >> these sorts of games in particular, our machine is at least 3 times >> faster than your machine. And 17 fps is a great achievement? 4 or >> 5 times faster then... > >It kind of feels like words are being put in our mouths or else we have >been misunderstood. The hardware gives the C64 a 50fps rate (and it must ... >independently of the processor, so of course it's "done for free" (though >not really as the VIC steals 50% of the 6502's cycles - the reason why >the C64 is clocked at an effective 1MHz rather than 2). VIC does not steal half of the 6510's cycles. This was explained some time ago. It is your choice whether to believe this or not. ... >The frame rate is a flexible number on a Spectrum. What your are going to >achieve depends on how many sprites you have, how big they will be and ... >Now, to get 8 sprites of 21x24 size moving around is easy in 354000 cycles ... >No one has ever claimed that the software sprites are done faster on a >Spectrum than they are done in hardware on the C64. What has been the ... >claim is that the hardware was a substitute for processor speed on the C64 >and the suggestion was the "faster" Spectrum could overcome the hardware ... >deficiency (ah I see the confusion: we are not claiming a 50fps rate >here). There seems to be some contention here whether a 3.54MHz z80 is in >fact faster than a 1MHz 6502, but we have offered evidence of this in the >case of some types of software: games where the graphics are not ... Less talk! More code! -S From damien@jetman.d.c.u Wed Jun 25 09:21:59 CDT 1997 Article: 70270 of comp.sys.cbm Path: news.acns.nwu.edu!newsfeed.acns.nwu.edu!news.ece.nwu.edu!news.cse.psu.edu!rutgers!usenet.logical.net!news.IAEhv.nl!news.oru.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!dispatch.news.demon.net!demon!jetman.demon.co.uk!not-for-mail From: damien@jetman.d.c.u (Damien Burke) Newsgroups: comp.sys.sinclair,comp.sys.cbm,comp.emulators.cbm Subject: Re: Spectrum Emulator for C64 [additonal translation] Date: Tue, 24 Jun 1997 19:19:54 GMT Organization: Ha! None! Message-ID: <33b1070e.956555@news.demon.co.uk> References: <337C5E94.388@actcom.co.il> <01bc6c89$ae5d4a00$04b8de8b@w9622136> <338EE6D2.23A6@tbaytel.net> <01bc6d0c$b90244a0$04b8de8b@w9622136> <5mmvp4$b7r@news.acns.nwu.edu> <5mvqq7$7qk$6@gerry.cc.keele.ac.uk> <9706102102.AA00g6t@cosine.demon.co.uk> <5 <9706232000.AA00gnu@cosine.demon.co.uk> Reply-To: damien@jetman.d.c.u NNTP-Posting-Host: jetman.demon.co.uk X-NNTP-Posting-Host: jetman.demon.co.uk [194.222.120.157] X-Newsreader: Forte Agent 1.0/32.390 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 15 Xref: news.acns.nwu.edu comp.sys.sinclair:40457 comp.sys.cbm:70270 comp.emulators.cbm:22150 On Mon, 23 Jun 97 20:00:06 GMT, Jason wrote: >Yeah, but if I do one POKE every single character on the screen can change >to the new font at the point that the command finishes executing. We're >not just pointing to a new font, we're refreshing *all* of the stuff >displayed in the old font as well. What??! You mean you can only have one font onscreen? How awful! :) -- //// Damien Burke (replace d.c.u in address with demon.co.uk if replying) //// Spectrum pages: http://www.jetman.demon.co.uk/speccy/ //// New to this group? Read this: http://www.jetman.demon.co.uk/speccy/faq/ From sentilius@skynet.be Wed Jun 25 09:52:58 CDT 1997 Article: 70279 of comp.sys.cbm Path: news.acns.nwu.edu!newsfeed.acns.nwu.edu!news.ece.nwu.edu!news.cse.psu.edu!rutgers!usenet.logical.net!news.mathworks.com!howland.erols.net!surfnet.nl!news.belnet.be!skynet.be!not-for-mail From: sentilius Newsgroups: comp.sys.cbm,comp.sys.sinclair Subject: spectrum faster in 3D Date: Fri, 20 Jun 1997 03:29:43 +0200 Organization: SKYNET SA/NV Lines: 12 Message-ID: <33A9DD07.153E@skynet.be> Reply-To: sentilius@skynet.be NNTP-Posting-Host: dialup43.antwerpen.skynet.be Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.01Gold (Win95; I) Xref: news.acns.nwu.edu comp.sys.cbm:70279 comp.sys.sinclair:40461 Why was the 16bit game 'CARRIER COMMAND' converted to the C64 in 2D. And why was the spectrum version in full 3D. Answer: Because the 6502 was slower than a Z80 when it came to real maths. Speccy forever... From sjudd@nwu.edu Wed Jun 25 09:53:02 CDT 1997 Article: 70299 of comp.sys.cbm Path: news.acns.nwu.edu!merle!judd From: judd@merle.acns.nwu.edu (Stephen Judd) Newsgroups: comp.sys.cbm,comp.sys.sinclair Subject: Re: spectrum faster in 3D Date: 25 Jun 1997 14:42:31 GMT Organization: Northwestern University, Evanston, IL Lines: 26 Message-ID: <5oraon$sre@news.acns.nwu.edu> References: <33A9DD07.153E@skynet.be> Reply-To: sjudd@nwu.edu (Stephen Judd) NNTP-Posting-Host: merle.acns.nwu.edu Xref: news.acns.nwu.edu comp.sys.cbm:70299 comp.sys.sinclair:40476 In article <33A9DD07.153E@skynet.be>, sentilius wrote: >Why was the 16bit game 'CARRIER COMMAND' converted to the > >C64 in 2D. > >And why was the spectrum version in full 3D. > >Answer: Because the 6502 was slower than a Z80 when it came to real > >maths. That's a strong claim, and one that has been made many times. In my experience to date it is made by people who do not understand any of the issues involved in 3D graphics, let alone the underlying mathematics, and how they are implemented computationally, so maybe you can help me out: If you would like to test the merits of the claim, feel free to contribute some code to the coding challenges. Specifically, a fast multiply routine needs to be demonstrated, and a fast line routine would help the Spectrum cause out quite a bit. evetS- >Speccy forever... From albrecht@freenet.calgary.ab.ca Wed Jun 25 09:53:18 CDT 1997 Article: 70296 of comp.sys.cbm Path: news.acns.nwu.edu!newsfeed.acns.nwu.edu!news.ece.nwu.edu!news.cse.psu.edu!uwm.edu!newsfeeds.sol.net!newspump.sol.net!howland.erols.net!newsfeed.internetmci.com!in1.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,comp.emulators.cbm Subject: Re: Spectrum Emulator for C64 Date: Mon, 23 Jun 1997 19:37:50 -0600 Organization: Calgary Free-Net Lines: 116 Message-ID: <5on8fu$h8e@ds2.acs.ucalgary.ca> References: <33845f94.1768387@commodore64.com> <5o75oi$14hc@ds2.acs.ucalgary.ca> <5od1oj$bgg@ds2.acs.ucalgary.ca> <5oh74b$6k5@news.acns.nwu.edu> 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: <5oh74b$6k5@news.acns.nwu.edu> Xref: news.acns.nwu.edu comp.sys.sinclair:40473 comp.sys.cbm:70296 comp.emulators.cbm:22162 On 21 Jun 1997, Stephen Judd wrote: > >But how many subroutines that you write need all 256 registers? > Sigh... I think you miss the point. Reflect on how useful it would be to have more than one accumulator or even a couple of fast page 0 locations on chip. How many of your algorithms would save significant time by not having to operate on slower memory so frequently? If that doesn't convince you, reflect on how many modern day processors use a page 0 like architecture and wonder why they are so rare. > >There is > >a point of diminishing returns. In my experience, for > Ah, an interesting point: what does your experience in these matters > consist of? That is, what kinds of programs have you written, and > how large/involved were they? Z80 assembly programs of course. All for z80 controllers. They have included: simple operating systems (streams, multitasking), simple interpretters, bitmap display drivers and of course mundane hardware associated stuff (read keypads, output a couple of bits to turn on relays, interrupt handlers, etc.) All easily fit in 8k ROM. > >This > >is your 4:1 number popping up if the z80 acts like a 6502. > You just don't seem to get it: Bruce is saying, "Based on the Actually, I think you've missed the point entirely. Bruce made the claim that tasks take anywhere from a 2:1 ratio in cycle times to 6:1. What I did was make the z80 behave like a 6502 to find out exactly what the worst case could possibly be and it turned out to be ~4.2:1. So you could *never* get any cycle ratios greater than that. His statement that the average is 4:1 is having trouble proving itself. If that is truly the average, then it should be easy to come up with examples. He gave an excellent example: the simultaneous 4 string compare, which is what he likely believed would demonstrate some huge cycle ratios, but it turned out to be ~2.6:1. He could easily extend that to 8 strings, 10 strings or whatever, but I then suggested that it would be profitable to switch to a deterministic automaton to compare the strings. Then you'd see a return to ~2:1 ratios. If you didn't want to switch to an automaton just for a thought exercise, then you'd probably see something approach 3:1 when I'd start using the stack to save pointers. > general experience from a wide variety of people who spent a lot > of time programming both architechtures, the general rule was 4:1". I'm not one for celebrity endorsements (sorry Bruce :). Even the biggest geniuses on the planet make mistakes. It is entirely possible that Bruce was surrounded by a lot of talented 6502 programmers and less talented z80 programmers. He has already made one mistake by suggesting cycle ratios go up to 6:1. One other thing: this is not a prevalent attitude among all engineers. > This is very different from your "Based on a few glaces at a spec > sheet and these simple examples and thought problems which exactly > prove my point, it's clear that the Z80 ought to be <2:1". > (How very Aristotelian of you!) :-) A little more effective than "Oh dear; sigh; Let's reprint this and reflect on the wisdom" - all indications that either you can't come up with an argument against or are too closed-minded to attempt to expand your understanding through considering another's arguments. This may not describe you personally, but that's what it makes you look like when you use these ineffective psychological tools. Actually, my arguments are based on: - the most time consuming algorithms use few variables (be they memory pointers or not) that can normally be held in the z80's registers (when this is done, slightly <2:1). - most data structures can be organized to be accessed sequentially in memory. In this case, I can use either the stack (~1:1 ratio when compared to 6502 lda/sta to zero page) or HL as a pointer (lda d,x; inx <-> ld a,(hl); inc l = ~1.6:1) - in large data structures such as arrays, the z80 also carries an advantage as it can calculate 16 bit addresses of random array elements much quicker than a 6502. - when a small table is needed (<256 bytes), in random access, the ratio is <2:1. - when a large table is needed (>256 bytes), the ratios dip further below 2:1 (I assume you need some self-modifying code here or maybe a double table lookup) - the z80 has a clear advantage in recursive algorithms. These things probably don't mean much to you, but the following may: - All the inherent 6502 instructions have z80 counterparts and they occur in 2:1 ratios. - The 6502's page 0 can be emulated on a z80 at a maximum ~4.2:1 ratio and most of the time in the range 2.2:1 to 2.8:1. - Z80 programmers don't write programs that way because it's quicker to formulate algorithms in other ways. - the opinion that cycle ratios occur on average at 4:1 is not the general opinion of all engineers. > It is also, of course, different from my "Based on a few glances > at a spec sheet and my experience in writing substantial programs > and algorithms, I expect between 3:1 and 4:1, so lets write some > code to see what's what". It's fine to write some code and compare, but there are millions of problems out there and if you can't generalize some problems, you'll never reach a conclusion. Alvin From sjudd@nwu.edu Wed Jun 25 09:53:39 CDT 1997 Article: 70300 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,comp.emulators.cbm Subject: Re: Spectrum Emulator for C64 Date: 25 Jun 1997 14:51:21 GMT Organization: Northwestern University, Evanston, IL Lines: 19 Message-ID: <5orb99$t2s@news.acns.nwu.edu> References: <33845f94.1768387@commodore64.com> <5od1oj$bgg@ds2.acs.ucalgary.ca> <5oh74b$6k5@news.acns.nwu.edu> <5on8fu$h8e@ds2.acs.ucalgary.ca> Reply-To: sjudd@nwu.edu (Stephen Judd) NNTP-Posting-Host: merle.acns.nwu.edu Xref: news.acns.nwu.edu comp.sys.sinclair:40477 comp.sys.cbm:70300 comp.emulators.cbm:22165 In article <5on8fu$h8e@ds2.acs.ucalgary.ca>, Alvin R. Albrecht wrote: 133 lines of blahtext. Less talk, more code. -S >describe you personally, but that's what it makes you look like when you >use these ineffective psychological tools. Could be, could be... >It's fine to write some code and compare, but there are millions of >problems out there and if you can't generalize some problems, you'll never >reach a conclusion. Right on, brother. From albrecht@freenet.calgary.ab.ca Wed Jun 25 09:53:52 CDT 1997 Article: 70298 of comp.sys.cbm Path: news.acns.nwu.edu!newsfeed.acns.nwu.edu!news.ece.nwu.edu!news.cse.psu.edu!uwm.edu!chi-news.cic.net!howland.erols.net!newsfeed.internetmci.com!in1.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,comp.emulators.cbm Subject: Re: Spectrum Emulator for C64 Date: Mon, 23 Jun 1997 18:10:17 -0600 Organization: Calgary Free-Net Lines: 34 Message-ID: <5on3bp$7ri@ds2.acs.ucalgary.ca> References: <33845f94.1768387@commodore64.com> <5nhubi$13l0@ds2.acs.ucalgary.ca> <5o1c2n$12lc@ds2.acs.ucalgary.ca> <5o4k56$aht@news.acns.nwu.edu> <5o75oi$14hc@ds2.acs.ucalgary.ca> <5od1oj$bgg@ds2.acs.ucalgary.ca> 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:40475 comp.sys.cbm:70298 comp.emulators.cbm:22164 On Sun, 22 Jun 1997, Bruce R. McFarling wrote: > An efficiency is an output divided by an input. As a core cell > for an ASIC, a chip that can do what the 65C02 can do in <4,000 is > efficient -- space efficiency, energy efficient, time efficient (the > smaller the processor core, the easier to work around it) etc. No argument there. This isn't in dispute: I'd end up using a 6502 on an ASIC as well if I ever needed an 8bit uP. > As far as the Z180, if you start making next gen comparisons, you > have to compare with the 65816 family. Which is a 'whole other > discussion. Yes, 'tis. I just wanted to offer a reason for the missing 40MHz z80: there's no point. A 20MHz 6502 is great, especially as part of an ASIC. A 40MHz z80 really isn't necessary because as a controller you don't need that speed. In more complex applications you really should be using a z180 or z380 instead - which are built for speed and offer a lot of other useful features. If you want to convince me that the max clock ratios are not 2:1 using the same device geometries, you have to explain this history: z80 : 2MHz, 4MHz, 6MHz, 8MHz 6502: 1MHz, 2MHz, 3MHz, 4MHz Alvin From ecbm@cc.newcastle.edu.au Thu Jun 26 08:36:18 CDT 1997 Article: 70377 of comp.sys.cbm Path: news.acns.nwu.edu!newsfeed.acns.nwu.edu!news.luc.edu!chi-news.cic.net!feeder.chicago.cic.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,comp.emulators.cbm Subject: Re: Spectrum Emulator for C64 Date: Thu, 26 Jun 1997 15:18:36 +1000 Organization: The University of Newcastle Lines: 25 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> NNTP-Posting-Host: cc.newcastle.edu.au Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII In-Reply-To: <5or5go$bgf@argon.btinternet.com> Xref: news.acns.nwu.edu comp.sys.sinclair:40532 comp.sys.cbm:70377 comp.emulators.cbm:22216 On Wed, 25 Jun 1997, Geoff wrote: > Greg King wrote in article <33AEBF04.231@erols.com>... > >"Relocatable" means that the stack's DOMAIN can be moved. > [snip > ] > >The Z80, on the other hand, runs its stack from 0000h all the way to > >0FFFFh, so it doesn't need to be relocatable! > > The z80 stack pointer can be moved at any time by any program - which > means that you can have more than one stack domain: if you know (for > example) that an interrupt routine is going to use 32 bytes of stack you > can put it in a particular piece of memory to avoid overwriting other > people's use of the stack, then put it back when you return. Thus > effectively changing the stack domain. So can the 6502 stack. Since a Forth program doesn't need anywhere near 256 bytes of return stack, you can use that to support 4 or more multi-tasking Forth processes. Virtually, Bruce R. McFarling, Newcastle, NSW ecbm@cc.newcastle.edu.au From ecbm@cc.newcastle.edu.au Thu Jun 26 08:43:32 CDT 1997 Article: 70373 of comp.sys.cbm Path: news.acns.nwu.edu!newsfeed.acns.nwu.edu!news.ece.nwu.edu!news.cse.psu.edu!rutgers!news.columbia.edu!panix!howland.erols.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,comp.emulators.cbm Subject: Re: Spectrum Emulator for C64 Date: Thu, 26 Jun 1997 14:39:39 +1000 Organization: The University of Newcastle Lines: 75 Message-ID: References: <33845f94.1768387@commodore64.com> <5nhubi$13l0@ds2.acs.ucalgary.ca> <5o1c2n$12lc@ds2.acs.ucalgary.ca> <5o4k56$aht@news.acns.nwu.edu> <5o75oi$14hc@ds2.acs.ucalgary.ca> <5od1oj$bgg@ds2.acs.ucalgary.ca> <5on3bp$7ri@ds2.acs.ucalgary.ca> NNTP-Posting-Host: cc.newcastle.edu.au Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII In-Reply-To: <5on3bp$7ri@ds2.acs.ucalgary.ca> Xref: news.acns.nwu.edu comp.sys.sinclair:40527 comp.sys.cbm:70373 comp.emulators.cbm:22215 On Mon, 23 Jun 1997, Alvin R. Albrecht wrote: [quoth I] > > As far as the Z180, if you start making next gen comparisons, you > > have to compare with the 65816 family. Which is a 'whole other > > discussion. > Yes, 'tis. I just wanted to offer a reason for the missing 40MHz z80: > there's no point. A 20MHz 6502 is great, especially as part of an ASIC. > A 40MHz z80 really isn't necessary because as a controller you don't need > that speed. In more complex applications you really should be using a > z180 or z380 instead - which are built for speed and offer a lot of other > useful features. Also for the 6502 instruction set, you gain a lot with a little fast memory (data and shadow ROM), even if devices are accessed at a slower rate. Access to a memory mapped I/O device address will typically be interspersed fairly evenly with instruction and data memory accesses, so a small, fast SRAM and a 6502 can get a lot out of a lower speed I/O chip with clock stretching. Isn't the Z80 approach more to add wait states to let the processor take advantage of opporuntities on offer to outrun the memory/device bus cycle (when doing all that internal register operations that give the Z80 its advantages)? > If you want to convince me that the max clock ratios are not 2:1 using the > same device geometries, you have to explain this history: > z80 : 2MHz, 4MHz, 6MHz, 8MHz > 6502: 1MHz, 2MHz, 3MHz, 4MHz When max clock rations where constrained by DRAM access speed, the 2:1 processor clock is informative: that's an upshot of the different memory bus designs of the processor. The 6502 is direct clocked to the memory bus. That's why there aren't any such things as 'wait states' for a 6502 -- and why the fully static design of the 65C02 is such a big deal: you bus the 65C02 to different speed of access memories (or I/O chips) by running it at the speed of the fastest, and stretching the low of the processor clock when it is necessary to avoid outrunning the slow clock. This is something that is done by an external (or 'seperate' for an ASIC, I guess) chip(s). The 4:1 ration was directed at something else. It was a rule of thumb that if you built a 6502 system with 1/4 the processor clock rate, you'd get the same general throughput. Remembering that the Apple I was a kit computer and so were the early S-100 bus computers, a lot of this is low level stuff: assemblers, text editors, Basic interpreters, software cassette I/O control, etc. The current question was, I took it, whether this still holds for the type of throughput that these processor would be asked to provide today in a hobbyist setting. Historically, the 6502 got into the Apple II, which got a spreadsheet and from then on turned into a software driven market, and the competing computer / game machines that were programmed with an awful lot of expectation that one would be the same as the next. When the Apple III got in trouble, and Commodore winning the computer / game machine wars with a price and mass market strategy[*] the Z80 machines caught up in troughput due to being more open systems. That meant better development environment, more code (hence solution) sharing, ability to accomodate processor speed improvements as soon as they became available, etc. The C128 would have contributed to that, if they had run it off the dot clock at 8MHz, but getting the interaction with the 2MHz parts on the motherboard (and are some of them 1MHz parts?) was complicated, so the C128 was crippled on its CP/M side to begin with. It would have been better if they introduced a cartridge that ran off the dot clock at 8MHz with its own memory (and could plug into either the C64 or the 128 -- that would have been the ticket) with DMA memory transfers and the C128 handling I/O jobs. Virtually, Bruce R. McFarling, Newcastle, NSW ecbm@cc.newcastle.edu.au [*] Sorry if my economics profession slips through here somewhere. From imc@ecs.ox.ac.uk Thu Jun 26 08:44:12 CDT 1997 Article: 70387 of comp.sys.cbm Path: news.acns.nwu.edu!newsfeed.acns.nwu.edu!news.luc.edu!chi-news.cic.net!howland.erols.net!news.mathworks.com!rill.news.pipex.net!pipex!server1.netnews.ja.net!warwick!bham!bhamcs!news.ox.ac.uk!news From: imc@ecs.ox.ac.uk (Ian Collier) Newsgroups: comp.sys.sinclair,comp.sys.cbm,comp.emulators.cbm Subject: Re: Spectrum Emulator for C64 [additonal translation] Date: 25 Jun 1997 13:12:44 GMT Organization: Oxford University Computing Laboratory Lines: 17 Message-ID: <11357.imc@comlab.ox.ac.uk> References: <01bc7d89$c9ed60a0$090000c0@pc-david> <866857163snz@the.bin> NNTP-Posting-Host: gruffle.comlab.ox.ac.uk X-Local-Date: Wednesday, 25th June 1997 at 2:12pm BST Xref: news.acns.nwu.edu comp.sys.sinclair:40548 comp.sys.cbm:70387 comp.emulators.cbm:22231 In article <866857163snz@the.bin>, junkmail@the.bin wrote: >I bet you can't - PAL TV runs interlaced, so although it goes at 50Hz >a full frame is only shown every 2 cycles, thus 25fps *not* 50fps. PAL TV in general runs interlaced, with 25 frames per second, or 50 fields per second (two fields make a frame). However, if the programme you are watching was shot on video rather than on film (and hasn't had any silly tricks done to it) then motion will usually occur between the fields, thus giving the impression of 50 pictures per second. The Spectrum does not output interlaced fields. It outputs 50 identical frames each second, each containing 312 lines (311 on the +3). The TV does not interlace them. Hence we really are talking about 50fps for Spectrum output. -- ---- Ian Collier : imc@comlab.ox.ac.uk : WWW page (including Spectrum section): ------ http://www.comlab.ox.ac.uk/oucl/users/ian.collier/imc.html From imc@ecs.ox.ac.uk Thu Jun 26 08:44:35 CDT 1997 Article: 70388 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!news.maxwell.syr.edu!rill.news.pipex.net!pipex!server1.netnews.ja.net!warwick!bham!bhamcs!news.ox.ac.uk!news From: imc@ecs.ox.ac.uk (Ian Collier) Newsgroups: comp.sys.sinclair,comp.sys.cbm,comp.emulators.cbm Subject: Re: Spectrum Emulator for C64 [additonal translation] Date: 25 Jun 1997 13:16:36 GMT Organization: Oxford University Computing Laboratory Lines: 9 Message-ID: <11358.imc@comlab.ox.ac.uk> References: <337C5E94.388@actcom.co.il> <01bc7fe3$e5ec3ea0$090000c0@pc-david> <1997Jun24.183336@cantva> NNTP-Posting-Host: gruffle.comlab.ox.ac.uk X-Local-Date: Wednesday, 25th June 1997 at 2:16pm BST Xref: news.acns.nwu.edu comp.sys.sinclair:40550 comp.sys.cbm:70388 comp.emulators.cbm:22232 In article <1997Jun24.183336@cantva>, nrw20@csc.canterbury.ac.nz wrote: >Who's this person who claims the human eye only works at about 18-20 fps !?! >That's just plain wrong. You need a frame-rate of close to 60 fps for the >human eye to perceive the motion as continuous. Funny, it looked OK last time I watched a film at 25 fps... -- ---- Ian Collier : imc@comlab.ox.ac.uk : WWW page (including Spectrum section): ------ http://www.comlab.ox.ac.uk/oucl/users/ian.collier/imc.html From robinh@arkanixlabs.com Thu Jun 26 08:46:49 CDT 1997 Article: 70354 of comp.sys.cbm Path: news.acns.nwu.edu!newsfeed.acns.nwu.edu!news.luc.edu!uchinews!news.spss.com!newsrelay.netins.net!mr.net!netnews.com!howland.erols.net!newsfeed.internetmci.com!news1.bellglobal.com!bellglobal.com!not-for-mail From: Robin Harbron Newsgroups: comp.sys.sinclair,comp.sys.cbm,comp.emulators.cbm Subject: Re: Spectrum Emulator for C64 [additonal translation] Date: Tue, 24 Jun 1997 16:24:11 -0400 Organization: Arkanix Labs Lines: 69 Message-ID: <33B02CEB.4B7F@arkanixlabs.com> References: <337C5E94.388@actcom.co.il> <5nn1cj$17j4@ds2.acs.ucalgary.ca> <9706221557.AA00glr@cosine.demon.co.uk> <33AE970F.621A@arkanixlabs.com> <5on1ik$s4e@ds2.acs.ucalgary.ca> Reply-To: robinh@arkanixlabs.com NNTP-Posting-Host: 206.47.150.132 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.01Gold (Win95; I) Xref: news.acns.nwu.edu comp.sys.sinclair:40526 comp.sys.cbm:70354 comp.emulators.cbm:22207 Alvin R. Albrecht wrote: > It kind of feels like words are being put in our mouths or else we have > been misunderstood. The hardware gives the C64 a 50fps rate (and it must > do this to avoid flickering which would occur otherwise if a sprite were > drawn and then absent on alternating frames, for example) and it is done > independently of the processor, so of course it's "done for free" (though > not really as the VIC steals 50% of the 6502's cycles - the reason why > the C64 is clocked at an effective 1MHz rather than 2). You're not as easily misunderstood as some of your cohorts :) This business about the C64 running at 2Mhz is utterly false tho... but the end result is similar to what you describe. There are two phases to each clock tick... the VIC takes the first, the 6510 takes the second. A small percentage of the time, the VIC steals some extra phases from the 6510, to read some extra graphics data. > The frame rate is a flexible number on a Spectrum. What your are going to > achieve depends on how many sprites you have, how big they will be and > whatever else is going on: it all depends on processor speed. At 3.54MHz > with a 10fps target, you have 354000 cycles to play with. The frame rate is also flexible on a 64... if doing some work that is too much to fit in a single frame, we would double buffer the display. ie. draw one complete frame, display that while the next is being drawn, then swap frames, then draw the next frame in the "hidden" screen, then display that one... > No one has ever claimed that the software sprites are done faster on a > Spectrum than they are done in hardware on the C64. What has been the > claim is that the hardware was a substitute for processor speed on the C64 > and the suggestion was the "faster" Spectrum could overcome the hardware > deficiency (ah I see the confusion: we are not claiming a 50fps rate > here). There seems to be some contention here whether a 3.54MHz z80 is in > fact faster than a 1MHz 6502, but we have offered evidence of this in the There have been very few solid examples of things truly running faster on the Z80 than the 6510... the only one I recall seeing is that one using the stack to clear out a large area of memory. It seems the 3 or 4 to 1 cycle ratio is fairly accurate... in which case the throughput of both processors is very close. But then you add the bag of tricks that the VIC adds to the 64, and you end up with a more powerful machine... I'm willing to be convinced another way, if some proof would show. 'cmon! more example like the screen clear routine ;) > case of some types of software: games where the graphics are not > necessarily amenable to the use of the C64 hardware and therefore must be > done in the same way as on the Spectrum, in software, plotting onto a > bitmap. These were games like the 3d isometrics (Head over Heels, the > author of which has already posted here that it wasn't easy getting a C64 Well, it sure turned out nice... was it ever easy doing it on a Speccy? ;) > to do it), the filled polygon 1st person perspective ones which are > slower on the C64 or are not done in 3d at all (Carrier Command was 2d on > the C64: someone in the C64 camp did say that it was 3d on the C64, but I > have seen it in 2d running on a 64: load it up and try it: if you say it's > 3d, I'll believe it) and the vector graphics ones (Starglider) - Stephen > has an interest in this last one and wants to see the z80 versions of fast > multiply and fast draw to validate this claim. I haven't seen either of these programs - but I have seen Stephen's various programs, and they sure run nice and fast... have you checked them out yet? Robin Harbron (Macbeth/PSW) macbeth@tbaytel.net From u5a77@teach.cs.keele.ac.uk Thu Jun 26 08:50:05 CDT 1997 Article: 70383 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!ais.net!newsfeed.direct.ca!dispatch.news.demon.net!demon!delos.dra.hmg.gb!server2.netnews.ja.net!server6.netnews.ja.net!server1.netnews.ja.net!warwick!keele!not-for-mail From: u5a77@teach.cs.keele.ac.uk (Spike) Newsgroups: comp.sys.cbm,comp.sys.sinclair,comp.emulators.cbm Subject: Re: Two more coding challenges -- Shootout part deux Followup-To: comp.sys.cbm,comp.sys.sinclair,comp.emulators.cbm Date: 16 Jun 1997 18:40:35 GMT Distribution: world Message-ID: <5o41b3$ncg$11@gerry.cc.keele.ac.uk> References: <5o00p9$gi9@news.acns.nwu.edu> <11285.imc@comlab.ox.ac.uk> NNTP-Posting-Host: bilbo.teach.cs.keele.ac.uk X-Newsreader: TIN [UNIX 1.3 950515BETA PL0] Lines: 20 Xref: news.acns.nwu.edu comp.sys.cbm:70383 comp.sys.sinclair:40544 comp.emulators.cbm:22227 Ian Collier (imc@ecs.ox.ac.uk) wrote: : LD DE,msg : XOR A : JP $0C0A : : msg:DEFB $80,"Hello Worl","d"+$80 : : Slow as hell but quite short. I thought it was RST16 to access the ROM print routine..... -- ______________________________________________________________________________ |u5a77@teach.cs.keele.ac.uk| "Are you pondering what I'm pondering Pinky?" | |Andrew Halliwell | | |Principal subjects in:- | "I think so brain, but this time, you control | |Comp Sci & Electronics | the Encounter suit, and I'll do the voice..." | ------------------------------------------------------------------------------ |GCv3.1 GCS/EL>$ d---(dpu) s+/- a- C++ U N++ o+ K- w-- M+/++ PS+++ PE- Y t+ | |5++ X+/++ R+ tv+ b+ D G e>PhD h/h+ !r! !y-|I can't say F**K either now! :( | ------------------------------------------------------------------------------ From imc@ecs.ox.ac.uk Thu Jun 26 08:50:12 CDT 1997 Article: 70385 of comp.sys.cbm Path: news.acns.nwu.edu!newsfeed.acns.nwu.edu!news.luc.edu!chi-news.cic.net!howland.erols.net!cpk-news-hub1.bbnplanet.com!news.bbnplanet.com!dispatch.news.demon.net!demon!delos.dra.hmg.gb!server1.netnews.ja.net!warwick!bham!bhamcs!news.ox.ac.uk!news From: imc@ecs.ox.ac.uk (Ian Collier) Newsgroups: comp.sys.cbm,comp.sys.sinclair,comp.emulators.cbm Subject: Re: Two more coding challenges -- Shootout part deux Date: 25 Jun 1997 13:05:42 GMT Organization: Oxford University Computing Laboratory Message-ID: <11356.imc@comlab.ox.ac.uk> References: <5o00p9$gi9@news.acns.nwu.edu> <11285.imc@comlab.ox.ac.uk> <5o41b3$ncg$11@gerry.cc.keele.ac.uk> NNTP-Posting-Host: gruffle.comlab.ox.ac.uk X-Local-Date: Wednesday, 25th June 1997 at 2:05pm BST Lines: 19 Xref: news.acns.nwu.edu comp.sys.cbm:70385 comp.sys.sinclair:40546 comp.emulators.cbm:22229 In article <5o41b3$ncg$11@gerry.cc.keele.ac.uk>, u5a77@teach.cs.keele.ac.uk (Spike) wrote: >Ian Collier (imc@ecs.ox.ac.uk) wrote: >: LD DE,msg >: XOR A >: JP $0C0A >: msg:DEFB $80,"Hello Worl","d"+$80 >I thought it was RST16 to access the ROM print routine..... You can print a character with RST 16, yes. But to print a whole message you can find other routines. One such is at 0C0A (it's used for printing the error reports and also for expanding tokens). Another is at 203C, which is part of the PRINT routine - it prints BC characters starting from (DE) (it is this which messes up when you press a mode key at the "scroll?" prompt because listing the current line corrupts the DE register). -- ---- Ian Collier : imc@comlab.ox.ac.uk : WWW page (including Spectrum section): ------ http://www.comlab.ox.ac.uk/oucl/users/ian.collier/imc.html From imc@ecs.ox.ac.uk Thu Jun 26 08:50:19 CDT 1997 Article: 70045 of comp.sys.cbm Path: news.acns.nwu.edu!newsfeed.acns.nwu.edu!news.luc.edu!chi-news.cic.net!howland.erols.net!newsfeed.nacamar.de!rill.news.pipex.net!pipex!server1.netnews.ja.net!warwick!bham!bhamcs!news.ox.ac.uk!news From: imc@ecs.ox.ac.uk (Ian Collier) Newsgroups: comp.sys.cbm,comp.sys.sinclair,comp.emulators.cbm Subject: Re: That Z80 line routine Date: 20 Jun 1997 17:23:28 GMT Organization: Oxford University Computing Laboratory Lines: 17 Message-ID: <11325.imc@comlab.ox.ac.uk> References: <5o00p9$gi9@news.acns.nwu.edu> <5o2e3j$f5p@news.acns.nwu.edu> <11304.imc@comlab.ox.ac.uk> <5o9uu7$d8f@news.acns.nwu.edu> NNTP-Posting-Host: gruffle.comlab.ox.ac.uk X-Local-Date: Friday, 20th June 1997 at 6:23pm BST Xref: news.acns.nwu.edu comp.sys.cbm:70045 comp.sys.sinclair:40286 comp.emulators.cbm:22005 In article <5o9uu7$d8f@news.acns.nwu.edu>, sjudd@nwu.edu (Stephen Judd) wrote: >Well, you are basically doing > > A = H/2 >loop A = A + dx > if A>dy then A=A-dy : y=y+1 > >which is exactly the same as doing > > A = H/2 >loop A = A - dx > if A<0 then A=A+dy : y=y+1 OK, cool. I wonder why the programmers of the ROM never noticed. :-) -- ---- Ian Collier : imc@comlab.ox.ac.uk : WWW page (including Spectrum section): ------ http://www.comlab.ox.ac.uk/oucl/users/ian.collier/imc.html From nrw20@csc.canterbury.ac.nz Fri Jun 27 11:22:26 CDT 1997 Article: 70438 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!news.maxwell.syr.edu!pumpkin.pangea.ca!news.mira.net.au!news.netspace.net.au!news.mel.connect.com.au!munnari.OZ.AU!comp.vuw.ac.nz!canterbury.ac.nz!cantva!nrw20 From: nrw20@csc.canterbury.ac.nz Newsgroups: comp.sys.sinclair,comp.sys.cbm,comp.emulators.cbm Subject: Re: Spectrum Emulator for C64 [additonal translation] Date: 27 Jun 97 15:10:03 +1200 Organization: University of Canterbury, Christchurch, New Zealand Lines: 30 Message-ID: <1997Jun27.151003@cantva> References: <337C5E94.388@actcom.co.il> <01bc7fe3$e5ec3ea0$090000c0@pc-david> <1997Jun24.183336@cantva> <11358.imc@comlab.ox.ac.uk> NNTP-Posting-Host: cantva.canterbury.ac.nz Xref: news.acns.nwu.edu comp.sys.sinclair:40592 comp.sys.cbm:70438 comp.emulators.cbm:22271 In article <11358.imc@comlab.ox.ac.uk>, imc@ecs.ox.ac.uk (Ian Collier) writes: > In article <1997Jun24.183336@cantva>, nrw20@csc.canterbury.ac.nz wrote: >>Who's this person who claims the human eye only works at about 18-20 fps !?! >>That's just plain wrong. You need a frame-rate of close to 60 fps for the >>human eye to perceive the motion as continuous. > Funny, it looked OK last time I watched a film at 25 fps... Well, I've seen the difference between something animating at 25fps (in this case, it was a flight-simulator, running on an PAL-interlace (620x512) screen) and the same thing animating at 50fps, (the same flight-sim. running on a Double-PAL (640x512) screen.) The difference was bloody amazing... and actually something I hadn't expected. (Incidently, the difference is still noticable when I try it on NTSC-interlace (30fps) then DoubleNTSC (60fps) screenmodes too.) If you got the chance to see a film at 25fps, and the same film at 50fps, (assuming you are correct in its frame-rate), I bet you'd be surprised too. As a side-note, if you had the chance to see one of you average modern hollywood-movies on the big screen. And were then able to see one such as, for example "Laurence of Arabia" on the same big screen, you'd be able to better appreciate the low resolution of film they use these days too. Nathan. (nrw20@csc.canterbury.ac.nz) From tmr@cosine.demon.co.uk Sun Jun 29 11:34:29 CDT 1997 Article: 70345 of comp.sys.cbm Path: news.acns.nwu.edu!newsfeed.acns.nwu.edu!news.ece.nwu.edu!news.cse.psu.edu!rutgers!usenet.logical.net!news.mathworks.com!howland.erols.net!europa.clark.net!dispatch.news.demon.net!demon!mail2news.demon.co.uk!not-for-mail From: Jason Newsgroups: comp.sys.sinclair,comp.sys.cbm,comp.emulators.cbm Subject: Re: Spectrum Emulator for C64 [additonal translation] Followup-To: comp.sys.sinclair,comp.sys.cbm,comp.emulators.cbm Date: Wed, 25 Jun 97 20:23:49 GMT Organization: Cosine Systems Message-ID: <9706252023.AA00gqr@cosine.demon.co.uk> References: <337C5E94.388@actcom.co.il> <5nn1cj$17j4@ds2.acs.ucalgary.ca> <9706221557.AA00glr@cosine.demon.co.uk> <33AE970F.621A@arkanixlabs.com> <5on1ik$s4e@ds2.acs.ucalgary.ca> X-Mail2News-User: tmr@cosine.demon.co.uk X-Mail2News-Path: relay-1.mail.demon.net!gate.demon.co.uk!cosine.demon.co.uk X-Newsreader: TIN [AMIGA 1.3 950726BETA PL0] Lines: 54 Xref: news.acns.nwu.edu comp.sys.sinclair:40519 comp.sys.cbm:70345 comp.emulators.cbm:22198 Alvin R. Albrecht: > Now, to get 8 sprites of 21x24 size moving around is easy in 354000 > cycles. To get 8 sprites + animated background is a little harder. To > get 21x48 sprites (on C64, start doubling # sprites using scan line > interrupts) + animated background takes more cycles, etc. etc. Eventually > you can't do more and maintain the 10fps target. I can scroll the screen in 48 rasterlines and process a thirty two sprite multiplex in half a frame (three quarters if I don't use a presorter) and *still* have time to play music, process game logic and so forth. At 50FPS. Armalyte (Thalamus) does 32 sprites, 40 soft sprites, full screen scrolling and some of the most complex attack patterns I've ever seen. > At a 50fps target, you have 70800 cycles. You can still do things at a > 50fps rate, but what can be done will be much reduced. Only for the Speccy (see above). > No one has ever claimed that the software sprites are done faster on a > Spectrum than they are done in hardware on the C64. What has been the > claim is that the hardware was a substitute for processor speed on the C64 > and the suggestion was the "faster" Spectrum could overcome the hardware > deficiency (ah I see the confusion: we are not claiming a 50fps rate > here). Maybe *you're* not, but... The Starglider [pulled from mail backlog, dated June 9th]: > Fair enough. But the sprites doesn't enter into it, because (as you > know) the spectrum can do those as well, and just as well. *He* seems to think so. When C64 users talk about scrolling, moving sprites, bob routines, in fact everything barring 3D linedrawing (and even then only sometimes) we are talking 50FPS. *Once again* I will repeat my challenge. 32 sprites, over a picture, standard Speccy resolution, no colour clash and, since you feel that the point should be made, *50FPS*. The code took about an hour (if memory serves, it was written three weeks ago). For 3D stuff you have the advantage (well, on the games side of things, there are some incredibly fast 3D routines in demos, Reflex's chessboard zoomer (Radio Napalm) for example, Byterapers' plasma zoom (FTS3) or Graham of Oxyron's texture mapping (Dawnfall) but after that... -- Jason =-) _______________________________________________________________________ TMR / / / / / / / /\ / /__/ / / /__/ / / / /__/ Email: tmr@cosine.demon.co.uk / / / /\_/ / /__ / / / / __// Cosine Homepage: / / / /__/ / / / / / / / / / http://www.cosine.demon.co.uk / / /_____/_____/_____/__/__/__/_____/_____________________________________/ / \_____\_____\_____\__\__\__\_____\_____________________________________\/ From ecbm@cc.newcastle.edu.au Sun Jun 29 11:34:37 CDT 1997 Article: 70378 of comp.sys.cbm Path: news.acns.nwu.edu!newsfeed.acns.nwu.edu!news.luc.edu!chi-news.cic.net!howland.erols.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,comp.emulators.cbm Subject: Re: Spectrum Emulator for C64 Date: Thu, 26 Jun 1997 15:15:23 +1000 Organization: The University of Newcastle Lines: 129 Message-ID: References: <33845f94.1768387@commodore64.com> <5o75oi$14hc@ds2.acs.ucalgary.ca> <5od1oj$bgg@ds2.acs.ucalgary.ca> <5oh74b$6k5@news.acns.nwu.edu> <5on8fu$h8e@ds2.acs.ucalgary.ca> NNTP-Posting-Host: cc.newcastle.edu.au Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII In-Reply-To: <5on8fu$h8e@ds2.acs.ucalgary.ca> Xref: news.acns.nwu.edu comp.sys.sinclair:40533 comp.sys.cbm:70378 comp.emulators.cbm:22217 On Mon, 23 Jun 1997, Alvin R. Albrecht wrote: > On 21 Jun 1997, Stephen Judd wrote: > > > >But how many subroutines that you write need all 256 registers? > > > Sigh... > > I think you miss the point. Reflect on how useful it would be to have > more than one accumulator or even a couple of fast page 0 locations on > chip. How many of your algorithms would save significant time by not > having to operate on slower memory so frequently? > If that doesn't convince you, reflect on how many modern day processors > use a page 0 like architecture and wonder why they are so rare. A lot of modern day architectures use a page 0 like instruction set. They're called RISC chips. Of course, the equivalent of page 0 is the register bank on a RISC, but you forget that the 6502 design is clocked directly to the memory bus if you think that costs as much as all that. When the 6502 instruction set lets you specify exactly what you intend to do, it's not a major slowdown LDA zp External 0 page Internal 0 page fetch op fetch op fetch zp, parse op fetch zp, parse op load A from (zp) load A from (zp) and fetch next op 3:2 LDA zp,X External 0 page Internal 0 page fetch op fetch op fetch zp, parse op fetch zp, parse op index zp+X index zp+X load A from (zp) load A from (zp) and fetch next op 4:3 LDA (zp,X) External 0 page Internal 0 page fetch op fetch op fetch zp, parse op fetch zp, parse op index zp+X index zp+X fetch addlo from zp+X fetch addlo from zp,x fetch addhi from zp+x+1 fetch addlo from zp+x+1 load A from addlo,addhi load A from addlo,addhi and fetch next op 6:5 It's a fairly constant 1 cycle overhead, which must be balanced against opportunities to retain data on the zero page and work with them directly there, rather than accessing them with the 4+ cycles required to load them to a register with the 3 byte "lda addrlo addrhi" type instruction, and the RISC-like facility of using the zp locations as an X-indexed stack. > Actually, I think you've missed the point entirely. Bruce made the claim > that tasks take anywhere from a 2:1 ratio in cycle times to 6:1. What I > did was make the z80 behave like a 6502 to find out exactly what the worst > case could possibly be and it turned out to be ~4.2:1. So you could > *never* get any cycle ratios greater than that. His statement that the > average is 4:1 is having trouble proving itself. If that is truly the > average, then it should be easy to come up with examples. He gave an > excellent example: the simultaneous 4 string compare, which is what he > likely believed would demonstrate some huge cycle ratios, but it turned > out to be ~2.6:1. He could easily extend that to 8 strings, 10 strings or > whatever, but I then suggested that it would be profitable to switch to a > deterministic automaton to compare the strings. Then you'd see a return > to ~2:1 ratios. If you didn't want to switch to an automaton just for a > thought exercise, then you'd probably see something approach 3:1 when > I'd start using the stack to save pointers. The point here is that this ~2.6:1 is not the savings, because I didn't present an example, I just presented an inner loop. If they are strings averaging 90 bytes in length, the data manipulation overhead starts to vanish. If they are strings that are three bytes in length, the extra data manipulation overhead from not working with the information in place raises its head again. If, as in ACE, you have 126 bytes of zero page available for the application, you can set up 12 bytes of pointers to significant strings and leave them there. In the Z80, you have to go and get them and work with them, pushing down the throughput. And the same goes when you work with them and have to restore the values to memory later so that the registers can be used for another purpose. > > general experience from a wide variety of people who spent a lot > > of time programming both architechtures, the general rule was 4:1". > I'm not one for celebrity endorsements (sorry Bruce :). Even the biggest > geniuses on the planet make mistakes. It is entirely possible that Bruce > was surrounded by a lot of talented 6502 programmers and less talented z80 > programmers. He has already made one mistake by suggesting cycle ratios > go up to 6:1. My impression is that cycle ratios do go up to 6:1. I assume that is for BCD math (the 6502 *was* originally designed under the cover of being a calculator chip, after all!). So why don't the 6502 and Z80 assembly language programmers program: A 16 digit accuracy Addition A 16 digit accuracy Subtraction A 32 digit accuracy unsigned 16-digit by 16-digit multiply. Add up the clocks and see where the ratios lie. I seem to be less committed to the 4:1 ratio than some other protagonists in the debate seem to be (!). It may well be that an experienced Z80 programmer and an experienced 6502 programmer will arrive at different ratios than were commonly experienced in the late 70's, simply because we know more about programming these little buggers in the late 70's. And it may well be that the mix of processing tasks has changed. I could go on at this point to point out what I hink *are* the weakness of the 65C02 instruction set as an 8-bit chip (that is, leaving out the next-generation 65816 type approach), but I've written too much already. Virtually, Bruce R. McFarling, Newcastle, NSW ecbm@cc.newcastle.edu.au From simonc@jumper.mcc.ac.uk Sun Jun 29 11:34:40 CDT 1997 Article: 70503 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!delos.dra.hmg.gb!server1.netnews.ja.net!warwick!keele!yama.mcc.ac.uk!simonc From: simonc@jumper.mcc.ac.uk (Cookie) Newsgroups: comp.sys.sinclair,comp.sys.cbm,comp.emulators.cbm Subject: Re: Spectrum Emulator for C64 Followup-To: comp.sys.sinclair,comp.sys.cbm,comp.emulators.cbm Date: 27 Jun 1997 14:54:22 GMT Organization: Sirius Cybernetics Corporation Message-ID: <5p0k6u$ejr@yama.mcc.ac.uk> References: <33845f94.1768387@commodore64.com> <5o75oi$14hc@ds2.acs.ucalgary.ca> <5od1oj$bgg@ds2.acs.ucalgary.ca> <5oh74b$6k5@news.acns.nwu.edu> <5on8fu$h8e@ds2.acs.ucalgary.ca> NNTP-Posting-Host: jumper.mcc.ac.uk X-Newsreader: TIN [version 1.2 PL2] Lines: 7 Xref: news.acns.nwu.edu comp.sys.sinclair:40644 comp.sys.cbm:70503 comp.emulators.cbm:22319 Alvin R. Albrecht (albrecht@freenet.calgary.ab.ca) wrote: : If that doesn't convince you, reflect on how many modern day processors : use a page 0 like architecture and wonder why they are so rare. Perhaps because there's not much use for it on register-rich processors? Simon From ecbm@cc.newcastle.edu.au Mon Jun 30 22:54:46 CDT 1997 Article: 70627 of comp.sys.cbm Path: news.acns.nwu.edu!newsfeed.acns.nwu.edu!news.ece.nwu.edu!news.cse.psu.edu!uwm.edu!chi-news.cic.net!newsxfer.itd.umich.edu!newsxfer3.itd.umich.edu!howland.erols.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,comp.emulators.cbm Subject: Re: Spectrum Emulator for C64 Date: Mon, 30 Jun 1997 13:23:45 +1000 Organization: The University of Newcastle Lines: 61 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> <5p15us$p8d$1@gerry.cc.keele.ac.uk> NNTP-Posting-Host: cc.newcastle.edu.au Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII In-Reply-To: <5p15us$p8d$1@gerry.cc.keele.ac.uk> Xref: news.acns.nwu.edu comp.sys.sinclair:40736 comp.sys.cbm:70627 comp.emulators.cbm:22432 On 27 Jun 1997, Spike wrote: > Bruce R. McFarling (ecbm@cc.newcastle.edu.au) wrote: > : So can the 6502 stack. Since a Forth program doesn't need > : anywhere near 256 bytes of return stack, you can use that to support 4 or > : more multi-tasking Forth processes. > > 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 language programmer does not use the stack pointer for all the different things that the Z80 used the stack pointer for, but restricts it for mostly hardware stack usage, and uses the zero page to hold vectors for larger stack frames. 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 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 - 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 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? - 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'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. 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 assume that the calling routine will know where the sign information is and determine whether to find the sum or the difference and handle the sign of the result): one at a fixed, 8-byte location in memory (either order), the other at an 8-byte location referred to in register (specifiable), the result returned in the fixed location. Fair game to send the length of the operand and retain the length of the result somewhere. How does it look and how many cycles does it take? Virtually, Bruce R. McFarling, Newcastle, NSW ecbm@cc.newcastle.edu.au From ecbm@cc.newcastle.edu.au Mon Jun 30 22:54:52 CDT 1997 Article: 70624 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!agate!ihnp4.ucsd.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,comp.emulators.cbm Subject: Re: Spectrum Emulator for C64 Date: Mon, 30 Jun 1997 12:47:57 +1000 Organization: The University of Newcastle Lines: 22 Message-ID: References: <33845f94.1768387@commodore64.com> <5o75oi$14hc@ds2.acs.ucalgary.ca> <5od1oj$bgg@ds2.acs.ucalgary.ca> <5oh74b$6k5@news.acns.nwu.edu> <5on8fu$h8e@ds2.acs.ucalgary.ca> <5p0k6u$ejr@yama.mcc.ac.uk> NNTP-Posting-Host: cc.newcastle.edu.au Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII In-Reply-To: <5p0k6u$ejr@yama.mcc.ac.uk> Xref: news.acns.nwu.edu comp.sys.sinclair:40735 comp.sys.cbm:70624 comp.emulators.cbm:22431 On 27 Jun 1997, Cookie wrote: > Alvin R. Albrecht (albrecht@freenet.calgary.ab.ca) wrote: > : If that doesn't convince you, reflect on how many modern day processors > : use a page 0 like architecture and wonder why they are so rare. > > Perhaps because there's not much use for it on register-rich processors? Because the problem that it is a solution to is fitting an instruction set into the 256 available values in an 8-bit code (AFAIR, the Z80 uses more, based on special prefixing opcodes that extend the instruction set). For the problem that this is a solution to -- fitting inexpensive processing power to an inexpensive memory bus -- the 65816 family fills the bill nicely. If you want to crank up the mips, you have to go for more parallism, either by multiplying the processors or widening the bus / instruction width, and you pay for what you get. Virtually, Bruce R. McFarling, Newcastle, NSW ecbm@cc.newcastle.edu.au From u5a77@teach.cs.keele.ac.uk Tue Jul 1 10:02:07 CDT 1997 Article: 70653 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!news.maxwell.syr.edu!peer.news.nildram.co.uk!betanews.compulink.co.uk!news.cix.co.uk!Aladdin!aladdin.net!ns2.aladdin.net!RMplc!rmplc.co.uk!yama.mcc.ac.uk!keele!not-for-mail From: u5a77@teach.cs.keele.ac.uk (Spike) Newsgroups: comp.sys.cbm,comp.sys.sinclair,comp.emulators.cbm Subject: Re: ...and a Z80 question Followup-To: comp.sys.cbm,comp.sys.sinclair,comp.emulators.cbm Date: 23 Jun 1997 17:41:04 GMT Lines: 23 Distribution: world Message-ID: <5omcfg$6rf$3@gerry.cc.keele.ac.uk> References: <5o00p9$gi9@news.acns.nwu.edu> <11284.imc@comlab.ox.ac.uk> <5o904h$1k7@news.acns.nwu.edu> <11324.imc@comlab.ox.ac.uk> <5ol3jt$ioa@news.acns.nwu.edu> NNTP-Posting-Host: sierra.teach.cs.keele.ac.uk X-Newsreader: TIN [UNIX 1.3 950515BETA PL0] Xref: news.acns.nwu.edu comp.sys.cbm:70653 comp.sys.sinclair:40758 comp.emulators.cbm:22446 Stephen Judd (judd@merle.acns.nwu.edu) wrote: : Yes indeed, there are some things just not worth speculating about. Who : knows what sorts of things these degenerate Spectrum fiends might be trying : out, late at night... fiddling with their 3.5" floppies... peeking, : poking random locations, and otherwise practicing unsafe hex... LOL! Errrr. Guys... I think this ones getting a little too close to the truth... Should we send "Da boyz" out to get 'im? -- ______________________________________________________________________________ |u5a77@teach.cs.keele.ac.uk| | |Andrew Halliwell | "ARSE! GERLS!! DRINK! DRINK! DRINK!!!" | |Principal subjects in:- | "THAT WOULD BE AN ECUMENICAL MATTER!...FECK!!!! | |Comp Sci & Electronics | - Father Jack in "Father Ted" | ------------------------------------------------------------------------------ |GCv3.1 GCS/EL>$ d---(dpu) s+/- a- C++ U N++ o+ K- w-- M+/++ PS+++ PE- Y t+ | |5++ X+/++ R+ tv+ b+ D G e>PhD h/h+ !r! !y-|I can't say F**K either now! :( | ------------------------------------------------------------------------------ From d.spence@zetnet.co.uk Tue Jul 1 21:36:34 CDT 1997 Article: 70607 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!zetnet.co.uk!not-for-mail From: David Spence Newsgroups: comp.sys.sinclair,comp.sys.cbm,comp.emulators.cbm Subject: Re: Spectrum Emulator for C64 Date: Sun, 29 Jun 1997 23:24:13 +0100 Message-ID: <1997062923241380734@zetnet.co.uk> References: <33845f94.1768387@commodore64.com> <5nhubi$13l0@ds2.acs.ucalgary.ca> <5o1c2n$12lc@ds2.acs.ucalgary.ca> <5o4k56$aht@news.acns.nwu.edu> <01bc7af4$077be420$090000c0@pc-david> <5o6juj$fmh$4@gerry.cc.keele.ac.uk> NNTP-Posting-Host: mumps.zetnet.co.uk X-Mailer: ZIMACS Version 1.10b 10005911 Lines: 9 Xref: news.acns.nwu.edu comp.sys.sinclair:40731 comp.sys.cbm:70607 comp.emulators.cbm:22417 I'm new to this stuff, but how could anyone try to emulate a Speccy on a C64? , and WHY???? All the C64 game/software designers of the eightys tried and failed. If you can't beat it, try to copy it. (Commodore Users Motto) DBS From albrecht@freenet.calgary.ab.ca Mon Jul 7 22:27:11 CDT 1997 Article: 70984 of comp.sys.cbm Path: news.acns.nwu.edu!newsfeed.acns.nwu.edu!math.ohio-state.edu!howland.erols.net!news.mathworks.com!enews.sgi.com!decwrl!tribune.usask.ca!rover.ucs.ualberta.ca!news.ucalgary.ca!srv1.freenet.calgary.ab.ca!albrecht From: "Alvin R. Albrecht" Newsgroups: comp.sys.cbm,comp.sys.sinclair Subject: Re: Elite line routine (was Re: spectrum faster in 3D) Date: Sat, 5 Jul 1997 17:38:43 -0600 Organization: Calgary Free-Net Lines: 194 Message-ID: <5pmm0e$1cm2@ds2.acs.ucalgary.ca> References: <33A9DD07.153E@skynet.be> <5os3r6$fju@yama.mcc.ac.uk> <01bc8260$9a9d4280$29e2869f@dragon> <33B577AF.7351@skynet.be> <5p66j0$471@news.acns.nwu.edu> <33ba2ee9.321664@NEWS.DEMON.CO.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: <33ba2ee9.321664@NEWS.DEMON.CO.UK> Xref: news.acns.nwu.edu comp.sys.cbm:70984 comp.sys.sinclair:40930 On Tue, 1 Jul 1997, rjfm2 wrote: > judd@merle.acns.nwu.edu (Stephen Judd) wrote: > >Well, again, the test of any theory is experiment, so feel free to post > >your Z80 code for doing fast multiplies ('ol Alvin is taking a 'mite > >long time to get his done :) and fast lines. I would be happy to send > >you the fast multiply algorithm if you missed it, and you can see it on > >my web page too. Otherwise, these kinds of declarative comments are just > >so much more balloon juice. > Well it takes time..still waiting for Stonkers to be debugged.. :-) Sorry, it's been a busy couple of weeks. I'll start by seeing what I can do in the next hour or so: 1. Fast Draw To answer Stephen's question: how would one quickly calculate the next y address in the display file, given its wacky layout? Answer: pop it off the stack. The draw routines below are a DRAW dx,dy variety where a line is drawn >from the current pixel position (x0,y0) to (x0+dx,y0+dy). Neither of them plot the initial point which is assumed to have been either drawn by the last draw or plotted by an initial PLOT command. Example: to draw a square of 50 pixels starting at (0,0): PLOT 0,0 ; move to initial pixel position DRAW 50,0 DRAW 0,50 DRAW -50,0 DRAW 0,-50 OK, first a straightforward implementation of Bresenham's algorithm: BRESENHAM --------- Restrictions: dy>=0, dx>0, dy/dx<=1, dy<128, |dy-dx|<128, line lies in screen If necessary, break the line into two parts which can be drawn without repeat of the overhead and without a slope discontinuity. enter: B=dx, C=dy HL=current screen address B'=current pixel position within screen byte (eg: 00100000) SP=sitting in table of y screen addresses (see PLOT) DRAW1 LD A,C 4 ; A=dy SUB B 4 ; A=dy-dx SLA A 8 ; A=2*(dy-dx) LD D,A 4 ; D="incrNE" LD A,C 4 ; A=dy SLA A 8 ; A=2*dy LD E,A 4 ; E="incrE" SUB B 4 ; A=2*dy-dx="d" ; now: E=incrE, D=incrNE, A=d forlp JP M,east 10/10 ; if d<0 goto east neast ADD A,D 4 ; d=d+incrNE EX AF,AF' 4 ; save d and sign LD A,L 4 ; current x coordinate in bits 0-5 of L AND #1F 6 ; save bits 0-5 POP HL 10 ; get address of next y coordinate, x=0 OR L 4 ; or in x coordinate LD L,A 4 JP cont 10 east ADD A,E 4 ; d=d+incrE EX AF,AF' 4 ; save d and sign cont EXX 4 ; get at alternate set RRC B 8 ; rotate pixel position JP NC,noincx 10/10 ; if passed through carry, need to INC L INC L 4 noincx LD A,B 4 ; A=pixel EXX 4 ; get back to set holding screen address OR (HL) 7 ; or in screen contents LD (HL),A 7 ; write pixel EX AF,AF' 4 ; A=d, with sign flag recovered DJNZ forlp 13/8 ; keep going until dx=0 There is a 40 cycle overhead and it takes 117 cycles to plot a NE pixel and 79 cycles to plot an east pixel. It occurred to me that a different version may be quicker: DDA Version ----------- This one calculates the fraction part of dy/dx and adds it to a running variable as the x coordinate is increased by one. If a carry is set, it's time to move to the next y coordinate. Max error is 2^(-9)*256=0.5 pixel when line is drawn across the entire screen. Restrictions: dy>=0, dy/dx<1, line lies on screen enter: B=dx, C=dy/dx (8 bits of fraction part) E=current pixel position in byte (eg 01000000) HL=current screen memory address SP=sitting in table of y screen addresses **** The overhead in calculating the fraction part of dy/dx (a special case division) is not shown here - I'll figure this out and post it tomorrow. XOR A (part of overhead) forlp ADD A,C 4 ; A=A+dy/dx LD D,A 4 ; save A in D JP NC,noincy 10/10 ; if carry, have moved to next y coord LD A,L 4 ; bits 0-5 of L hold current x coord AND #1F 6 ; get x coord POP HL 10 ; pop address of next y coord, x=0 OR L 4 ; or in x coord LD L,A 4 noincy RRC E 8 ; rotate pixel position JP NC,noincx 10/10 ; if through carry, need next x byte coord INC L 4 noincx LD A,E 4 ; A=pixel OR (HL) 7 ; or in screen LD (HL),A 7 ; write pixel to screen LD A,D 4 ; recover A DJNZ forlp 13/8 ; do until dx=0 This one takes 71 cycles to plot if y coordinate not changed and 99 cycles per pixel otherwise. Either way, tough for you to beat I think. 2. The PLOT The plot needs to initialize SP so that it lies in a table of screen addresses for each y coordinate (x=0), pops first screen address into HL, finds first pixel position in byte. The following is very quickly written, so may not be the fastest way. It should also be tweaked for each line draw routine above so that the correct registers end up with the correct variables. enter: HL=y coordinate C=x coordinate exit: A=pixel position in byte (eg 10000000) HL=screen address SP=points to next y screen address PLOT ADD HL,HL 11 ; HL=2*y LD SP,addrtbl 10 ; bottom of screen address table ADD HL,SP 11 ; calculate index LD SP,HL 6 ; SP points to current screen address POP HL 10 ; get current screen address, x=0 LD A,#07 7 ; get bits 0..2 of x coord AND C 4 ; they identify pixel position in byte LD B,A 4 ; B=pixel position in byte (0-7) LD A,C 4 ; get bits 3..7 into bits 0..5 RRCA 4 ; they identify 8 bit pixel group RRCA 4 RRCA 4 AND #1F 7 ; keep bits 0..5 (column) OR L 4 ; OR into screen address LD L,A 4 INC B 4 ; B=pixel position=1..8 LD A,#01 7 ; rotate pixel bit into correct position loop RLA 4 DJNZ loop 13/8 *** POP causes SP to move upward in memory so when next y coord is popped off stack, assuming dy>0, requires top of table to correspond to screen addresses at top of screen. So y=0 refers to bottom of screen. addrtbl DEFW bottom screen address, x=0 DEFW next to bottom, x=0 DEFW .... for each y coord Time's up! Alvin From damien@jetman.d.c.u Tue Jul 8 23:24:53 CDT 1997 Article: 71100 of comp.sys.cbm Path: news.acns.nwu.edu!newsfeed.acns.nwu.edu!news.ece.nwu.edu!news.cse.psu.edu!rutgers!news.columbia.edu!panix!news.eecs.umich.edu!nntprelay.mathworks.com!howland.erols.net!europa.clark.net!dispatch.news.demon.net!demon!jetman.demon.co.uk!not-for-mail From: damien@jetman.d.c.u (Damien Burke) Newsgroups: comp.sys.cbm,comp.emulators.cbm,comp.sys.sinclair Subject: Re: Just how difficult is C-64 Emulation? Read on... Date: Mon, 07 Jul 1997 17:54:20 GMT Organization: Ha! None! Message-ID: <33bfe383.2422317@news.demon.co.uk> References: <5mq1hv$hdn@eyrie.org> <5otej7$gqb@yama.mcc.ac.uk> <33b3a2b6.4410523@news.demon.co.uk> <5pmes9$117@yama.mcc.ac.uk> Reply-To: damien@jetman.d.c.u NNTP-Posting-Host: jetman.demon.co.uk X-NNTP-Posting-Host: jetman.demon.co.uk [194.222.120.157] X-Newsreader: Forte Agent 1.0/32.390 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 12 Xref: news.acns.nwu.edu comp.sys.cbm:71100 comp.emulators.cbm:22707 comp.sys.sinclair:40992 On 5 Jul 1997 21:38:17 GMT, simonc@jumper.mcc.ac.uk (Cookie) wrote: >Well paint me pink and call me a hippy, but personally I find the loss of >vast swathes of human life for such stupid reasons decidedly distasteful. Undoubtedly but when someone else starts it, what do you do? Roll over and play dead or stop them before they run the world? -- //// Damien Burke (replace d.c.u in address with demon.co.uk if replying) //// Spectrum pages: http://www.jetman.demon.co.uk/speccy/ //// New to this group? Read this: http://www.jetman.demon.co.uk/speccy/faq/ From sjudd@nwu.edu Tue Jul 8 23:25:52 CDT 1997 Article: 71174 of comp.sys.cbm Path: news.acns.nwu.edu!merle!judd From: judd@merle.acns.nwu.edu (Stephen Judd) Newsgroups: comp.sys.cbm,comp.emulators.cbm,comp.sys.sinclair Subject: Re: Just how difficult is C-64 Emulation? Read on... Date: 9 Jul 1997 04:24:47 GMT Organization: Northwestern University, Evanston, IL Lines: 22 Message-ID: <5pv3qf$nrf@news.acns.nwu.edu> References: <5mq1hv$hdn@eyrie.org> <33b3a2b6.4410523@news.demon.co.uk> <5pmes9$117@yama.mcc.ac.uk> <33bfe383.2422317@news.demon.co.uk> Reply-To: sjudd@nwu.edu (Stephen Judd) NNTP-Posting-Host: merle.acns.nwu.edu Xref: news.acns.nwu.edu comp.sys.cbm:71174 comp.emulators.cbm:22757 comp.sys.sinclair:41055 In article <33bfe383.2422317@news.demon.co.uk>, Damien Burke wrote: >On 5 Jul 1997 21:38:17 GMT, simonc@jumper.mcc.ac.uk (Cookie) >wrote: > >>Well paint me pink and call me a hippy, but personally I find the loss of >>vast swathes of human life for such stupid reasons decidedly distasteful. > >Undoubtedly but when someone else starts it, what do you do? >Roll over and play dead or stop them before they run the world? And so, with a tacit admission, the Spectrum crowd inadvertantly reveals their grand strategem, giving new impetuts to the heroic efforts of the C64 resistance movement! Truly have these become Flames of Freedom! :) -S > //// Damien Burke (replace d.c.u in address with demon.co.uk if replying) From geoff@farmline.com Fri Jul 11 00:56:52 CDT 1997 Article: 70887 of comp.sys.cbm Path: news.acns.nwu.edu!newsfeed.acns.nwu.edu!math.ohio-state.edu!uwm.edu!vixen.cso.uiuc.edu!howland.erols.net!cpk-news-hub1.bbnplanet.com!news.bbnplanet.com!dispatch.news.demon.net!demon!zetnet.co.uk!btnet-feed1!BTInternet!usenet From: "Geoff" Newsgroups: comp.sys.sinclair,comp.sys.cbm,comp.emulators.cbm Subject: Re: Spectrum Emulator for C64 Date: Fri, 4 Jul 1997 17:19:30 +0100 Organization: Farming On-Line Message-ID: <5pj7j1$rti@argon.btinternet.com> References: <339d8a2a.3224107@news.demon.co.uk> <33AEBF04.231@erols.com> <5or5go$bgf@argon.btinternet.com> <11385.imc@comlab.ox.ac.uk> NNTP-Posting-Host: folstaff.farmline.com Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Newsreader: Microsoft Outlook Express 4.71.0544.0 X-MimeOLE: Produced By Microsoft MimeOLE Engine V4.71.0544.0 Lines: 14 Xref: news.acns.nwu.edu comp.sys.sinclair:40864 comp.sys.cbm:70887 comp.emulators.cbm:22568 Ian Collier wrote in article <11385.imc@comlab.ox.ac.uk>... >Unless you happen to have written a recursive program. They can be quite >useful sometimes, you know. Rarely. Haven't yet seen a recursive program that couldn't be written iteratively. Funnily enough, there's no such thing :) Personally I always found iteration easier to understand, too... and it tends to use up less memory aswell. Geoff From imc@ecs.ox.ac.uk Fri Jul 11 00:56:55 CDT 1997 Article: 71088 of comp.sys.cbm Path: news.acns.nwu.edu!newsfeed.acns.nwu.edu!news.ece.nwu.edu!news.cse.psu.edu!news3.cac.psu.edu!howland.erols.net!europa.clark.net!dispatch.news.demon.net!demon!delos.dra.hmg.gb!server1.netnews.ja.net!lyra.csx.cam.ac.uk!news.ox.ac.uk!news From: imc@ecs.ox.ac.uk (Ian Collier) Newsgroups: comp.sys.sinclair,comp.sys.cbm,comp.emulators.cbm Subject: Re: Spectrum Emulator for C64 Date: 7 Jul 1997 13:35:46 GMT Organization: Oxford University Computing Laboratory, UK Message-ID: <11409.imc@comlab.ox.ac.uk> References: <339d8a2a.3224107@news.demon.co.uk> <11385.imc@comlab.ox.ac.uk> <5pj7j1$rti@argon.btinternet.com> <5pmhqi$gbc@ds2.acs.ucalgary.ca> NNTP-Posting-Host: boothp2.ecs.ox.ac.uk X-Local-Date: Monday, 7th July 1997 at 2:35pm BST Lines: 19 Xref: news.acns.nwu.edu comp.sys.sinclair:40975 comp.sys.cbm:71088 comp.emulators.cbm:22695 In article <5pmhqi$gbc@ds2.acs.ucalgary.ca>, "Alvin R. Albrecht" wrote: >Try solving the Towers of Hanoi problem without recursion directly and >without resorting to writing an iterative version of the easily formulated >recursive version. An interesting problem. The following algorithm might make a good IOCCC entry... for i = 1 to 2^N-1 for j = N-1 to 0 step -1: if (i AND 2^j) = ((i-1) AND 2^j) then next j print "Move disk ";j+1; if ((j XOR N) AND 1) = 1 then print " left" else print " right" next i (where disk 1 is the smallest, "right" means A->B->C->A and "left" means C->B->A->C). -- ---- Ian Collier : imc@comlab.ox.ac.uk : WWW page (including Spectrum section): ------ http://www.comlab.ox.ac.uk/oucl/users/ian.collier/imc.html From sjudd@nwu.edu Fri Jul 11 00:56:58 CDT 1997 Article: 71173 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,comp.emulators.cbm Subject: Re: Spectrum Emulator for C64 Date: 9 Jul 1997 04:16:32 GMT Organization: Northwestern University, Evanston, IL Lines: 25 Message-ID: <5pv3b0$nkc@news.acns.nwu.edu> References: <339d8a2a.3224107@news.demon.co.uk> <5ppnb4$1036@ds2.acs.ucalgary.ca> Reply-To: sjudd@nwu.edu (Stephen Judd) NNTP-Posting-Host: merle.acns.nwu.edu Xref: news.acns.nwu.edu comp.sys.sinclair:41054 comp.sys.cbm:71173 comp.emulators.cbm:22756 In article , Bruce R. McFarling wrote: >On Sun, 6 Jul 1997, Alvin R. Albrecht wrote: > >> ... >> This kind of problem where: >> - There are few variables (index, one var for add) >> - There are a lot of memory references to a table >> - There are a lot of branches (not in this example) >> is where the 6502 will do well against a z80. >> >> Needless to say, this doesn't include the lion's share of problems by far. > > Rather 'many' than 'few' variables. Having few enough variables >that they can be maintained in the Z80 register set without shuffling is >an *advantage* for the 6502. dis or Z80 :) -S