So in over all effect, is the SAM relatively faster than the Spectrum in operation? I realise their are more fundamental differences between the two machines and that the SAMs processor is said to run at twice the speed. I considered moving into Z80, since my 8 bit background concentrates on 6502 coding, which is far simpler (For Constant speeds and variety of instructions) but i am rather heavily put off by the speed restrictions noted! Like Driving a sports car all your life through Granny City!!
Respect Twilighte -----Original Message----- From: Andrew Gale <[EMAIL PROTECTED]> To: sam-users@nvg.ntnu.no <sam-users@nvg.ntnu.no> Date: 05 August 1999 21:11 Subject: Re: Music :> Another Question, is this right that portions of the RAM are constrained by :> speed of access? :> : :Yes, all of it is, but exactly how restricted it is depends on when :you try to access it (accessing it when the ASIC is drawing the :border is not as slow as when the ASIC is drawing the main part :of the screen). : :Below is a very useful post that Ian sent a while ago, which should :answer your question. : :-Andy : :---------- : : :Date: Mon, 12 Apr 1999 17:51:24 +0100 :From: Ian Collier <[EMAIL PROTECTED]> :To: sam-users@nvg.ntnu.no :Subject: Re: SimCoupe interrupt timings : :On Sat, Apr 10, 1999 at 02:58:35PM +0100, Si Owen wrote: :> LD r,r' says 8 t-states, but the docs I have say it's 7. JR c,e takes 8 :> t-states if the condition is not met and 12 if it is, but the docs I have :> say it's 7 and 13 respectively. etc. : :> Could someone explain the 4 t-state rounding? (machine cycles?) I could :> understand it being rounded up, but the conditional relative jump is :> slightly shorter. I've always done video effects with official timings, and :> manual tweaks if necessary! : :For the moment, assume that the screen is turned off or it happens to :be displaying the border. At this time, all accesses to main RAM are :restricted by the ASIC to occur only on every fourth cycle. (This does :not apply to external RAM or to ROM). The usual effect of this is to round :instructions up to the next multiple of 4, because each instruction starts :with an opcode fetch and thus has to wait until the next "fourth" cycle. : :So, for example, if INC HL is executed then it takes 6 cycles of its own :plus 2 cycles waiting for the next instruction fetch for a total of 8 cycles. : :Some instructions involve more than one memory access. In these cases :the instruction timing depends on when exactly the Z80 requests the memory :access. In the simplest cases of LD A,n, LD HL,nn and so on the accesses :follow on from each other and so the time taken is just four cycles for each :access. However, for PUSH HL I believe it goes something like this : : opcode is fetched 4 cycles : SP register is decremented 1 cycle : Z80 must wait for the next access 3 cycles : H is stored at (SP) 3 cycles : SP is decremented in parallel with the store so no cycles : Z80 must wait for the next access 1 cycle : L is stored at (SP) 3 cycles : Z80 must wait for the next instruction fetch 1 cycle : :making 16 cycles in total. : :As for the JR instruction, you remember wrongly. Docs state that JR :takes 12 cycles if the jump is taken, and that is still true. For DJNZ :docs state that it takes 13 cycles if the jump is taken, and Sam rounds :that up to 16. The Sam never takes less time than the docs say. : :Now, if the screen is turned on then it is slightly more complicated. The :screen is displayed for 256 of every 384 cycles on each line, for 192 of :the 312 lines (though this is different in mode 1). During that time :memory access is restricted to every eighth cycle, so most instructions :take twice as long. INC HL still only takes 8 cycles, though, since it :doesn't require memory access once the instruction has been fetched. : :On the other hand, if a program is running in ROM then the Z80 doesn't have :to wait for instruction fetches, so it runs faster. It does have to wait :for each instruction which accesses the RAM, however. : :imc :
