| POKE and STA for speaker access [message #262433] |
Sat, 26 July 2014 13:20  |
sicklittlemonkey
Messages: 570
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
There have been a few threads on this topic, but I just discovered a couple of things worth "backing up" on the internet ...
The classic meme is usually about STA $C030 generating no sound or quieter sound because it accessed the speaker twice. This is demonstrably false, and the meme presumably originated from the warnings I quote at the end of this post. Though never stated clearly, the warnings should apply to the Integer or Applesoft BASIC POKE command and the assembly language instruction it uses STA (zp),Y - and similar instructions, but not STA abs.
Find 1
The original "Red Book" Apple II Reference Manual (January 1978) gives no such warning, and even gives an example of POKE -16336,0 for toggling the speaker.
POKE should not be used for the reason given above, so it seems that the 1979 manual introduced the first poorly worded warning, and thus the meme.
Find 2
James Sather's books "Understanding the Apple II" and "Understanding the Apple IIe" detail the address bus activity of the CPU in each cycle of all instruction types, and he documents instructions that generate 1 to 4 accesses to a given address, and implications for RAM and disk I/O soft switches.
In the IIe book he details the differences between the NMOS 6502 and the 65C02, including some changes in the number of accesses for several types of instructions.
But he missed a significant implication: POKE is "safe" for speaker access when using a 65C02 since the STA (zp),Y instruction only generates one access, not two. He also failed to flag that his suggested use of STA (zp),Y for disk soft switch access will fail on the 65C02.
Anyway, trivia, minutia - and yet strange given his overall meticulous care and research in these books.
Cheers,
Nick.
Some of the warnings ...
The "Apple II Reference Manual" (copyright 1979, with green chapter pages) has:
Note that a "write" operation on the Apple's 6502 microprocessor actually performs a "read" before the "write", so that if you use a "write" operation to flip any soft switch, you will actually throw that switch twice.
The "Apple II Reference Manual For //e only" (copyright 1982) and "Apple IIe Technical Reference Manual" (copyright 1985) are a bit better:
If you write using an indexed store operation, the Apple IIe's [6502] microprocessor activates the address bus twice during successive clock cycles, causing a device that toggles each time it is addressed to end up back in its original state. For this reason, you should read, rather than write, to such devices.
The "Apple IIc Reference Manual" (Volume 1, copyright 1984) is worse again:
.... if you write to the speaker location, the microprocessor activates the address bus twice during successive clock cycles, causing the speaker toggle to end up in its original state before the speaker cone can move. Therefore, you should read, rather than write, to use this device.
The "Apple IIgs Hardware Reference" (Second Edition) is like the IIe manuals:
If you access this soft switch by using an assembly-language indexed-mode command, it switches twice in rapid succession.
|
|
|
|
|
|
| Re: POKE and STA for speaker access [message #262460 is a reply to message #262433] |
Sat, 26 July 2014 20:44  |
Michael J. Mahon
Messages: 1767
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
sicklittlemonkey <nick.westgate@gmail.com> wrote:
> There have been a few threads on this topic, but I just discovered a
> couple of things worth "backing up" on the internet ...
>
> The classic meme is usually about STA $C030 generating no sound or
> quieter sound because it accessed the speaker twice. This is demonstrably
> false, and the meme presumably originated from the warnings I quote at
> the end of this post. Though never stated clearly, the warnings should
> apply to the Integer or Applesoft BASIC POKE command and the assembly
> language instruction it uses STA (zp),Y - and similar instructions, but not STA abs.
>
> Find 1
> The original "Red Book" Apple II Reference Manual (January 1978) gives no
> such warning, and even gives an example of POKE -16336,0 for toggling the speaker.
>
> POKE should not be used for the reason given above, so it seems that the
> 1979 manual introduced the first poorly worded warning, and thus the meme.
>
> Find 2
> James Sather's books "Understanding the Apple II" and "Understanding the
> Apple IIe" detail the address bus activity of the CPU in each cycle of
> all instruction types, and he documents instructions that generate 1 to 4
> accesses to a given address, and implications for RAM and disk I/O soft switches.
>
> In the IIe book he details the differences between the NMOS 6502 and the
> 65C02, including some changes in the number of accesses for several types of instructions.
>
> But he missed a significant implication: POKE is "safe" for speaker
> access when using a 65C02 since the STA (zp),Y instruction only generates
> one access, not two. He also failed to flag that his suggested use of STA
> (zp),Y for disk soft switch access will fail on the 65C02.
>
> Anyway, trivia, minutia - and yet strange given his overall meticulous
> care and research in these books.
>
> Cheers,
> Nick.
>
> Some of the warnings ...
>
> The "Apple II Reference Manual" (copyright 1979, with green chapter pages) has:
> Note that a "write" operation on the Apple's 6502 microprocessor actually
> performs a "read" before the "write", so that if you use a "write"
> operation to flip any soft switch, you will actually throw that switch twice.
>
> The "Apple II Reference Manual For //e only" (copyright 1982) and "Apple
> IIe Technical Reference Manual" (copyright 1985) are a bit better:
> If you write using an indexed store operation, the Apple IIe's [6502]
> microprocessor activates the address bus twice during successive clock
> cycles, causing a device that toggles each time it is addressed to end up
> back in its original state. For this reason, you should read, rather than
> write, to such devices.
>
> The "Apple IIc Reference Manual" (Volume 1, copyright 1984) is worse again:
> ... if you write to the speaker location, the microprocessor activates
> the address bus twice during successive clock cycles, causing the speaker
> toggle to end up in its original state before the speaker cone can move.
> Therefore, you should read, rather than write, to use this device.
>
> The "Apple IIgs Hardware Reference" (Second Edition) is like the IIe manuals:
> If you access this soft switch by using an assembly-language indexed-mode
> command, it switches twice in rapid succession.
You're right--this is the meme that won't die. ;-)
In my sound synthesis programs I always use STA $C030 to toggle the speaker
(or cassette output), since it leaves the A register undisturbed.
--
-michael - NadaNet 3.1 and AppleCrate II: http://home.comcast.net/~mjmahon
|
|
|
|
| Re: POKE and STA for speaker access [message #262462 is a reply to message #262460] |
Sat, 26 July 2014 21:25 |
sicklittlemonkey
Messages: 570
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Sunday, 27 July 2014 12:44:46 UTC+12, Michael J. Mahon wrote:
> In my sound synthesis programs I always use STA $C030 to toggle the speaker
> (or cassette output), since it leaves the A register undisturbed.
Yes, but what I hadn't realized - since I read (past tense) Sather like a textbook - is that POKE is now single access (write) on a 65C02. The Apple IIc warning is now especially misleading!
I am collating a bit more to post ... later.
Cheers,
Nick.
|
|
|
|
| Re: POKE and STA for speaker access [message #262463 is a reply to message #262434] |
Sat, 26 July 2014 21:27 |
sicklittlemonkey
Messages: 570
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Sunday, 27 July 2014 05:42:44 UTC+12, D Finnigan wrote:
> I even put the warning into The New Apple II User's Guide.
>
> We must respect tradition.
Heh, I'm still waiting for the corrected 2nd edition to purchase!
Besides - things move quickly in the cutting edge Apple II world. Can you keep up with all this new software and hardware!?
Er, please let me proof-read it before I purchase it. ; - )
Cheers,
Nick.
|
|
|
|
|
|
| Re: POKE and STA for speaker access [message #262468 is a reply to message #262464] |
Sat, 26 July 2014 23:17 |
sicklittlemonkey
Messages: 570
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Sunday, 27 July 2014 14:03:34 UTC+12, Steve Nickolas wrote:
> Not BIT?
STA has the advantage on not modifying any registers - including the status register.
I love ARM assembly because you must explicitly set an instruction flag for it to affect the status register ... and every instruction can be optionally conditional anyway.
That's two powerful ways to tackle the same problem.
Cheers,
Nick.
|
|
|
|
|
|
| Re: POKE and STA for speaker access [message #262476 is a reply to message #262474] |
Sun, 27 July 2014 02:09 |
Steve Nickolas
Messages: 2036
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Sun, 27 Jul 2014, Michael J. Mahon wrote:
> Steve Nickolas <usotsuki@buric.co> wrote:
>> On Sat, 26 Jul 2014, Michael J. Mahon wrote:
>>
>>> In my sound synthesis programs I always use STA $C030 to toggle the speaker
>>> (or cassette output), since it leaves the A register undisturbed.
>>
>> Not BIT?
>>
>> -uso.
>
> BIT disturbs the status bits. STA is simple and straightforward.
>
True. But it leaves A untouched. :P
-uso.
|
|
|
|
| Re: POKE and STA for speaker access [message #262483 is a reply to message #262433] |
Sun, 27 July 2014 04:31 |
|
|
Originally posted by: Vladimir Ivanov
On Sat, 26 Jul 2014, sicklittlemonkey wrote:
> There have been a few threads on this topic, but I just discovered a
> couple of things worth "backing up" on the internet ...
Internet is just full of .. things. :-)
> The classic meme is usually about STA $C030 generating no sound or
> quieter sound because it accessed the speaker twice.
Opcode $8D is exactly 4 cycles - three cycles fetching the instruction,
one final cycle doing the write access.
> [Sather] But he missed a significant implication: POKE is "safe" for
> speaker access when using a 65C02 since the STA (zp),Y instruction only
> generates one access, not two.
Opcode $91 on the 65SC02 is 6 cycles - two cycles instruction fetch, two
cycles zero page pointer fetch, one cycle dummy zero page read, one final
cycle doing the write access.
65SC02, compared to NMOS 6502, generally tries to replace dummy I/O with
something safe. One notable exception is keeping RWTS happy (STA abs,X),
but there are also few surprises here and there.
|
|
|
|
| Re: POKE and STA for speaker access [message #262484 is a reply to message #262468] |
Sun, 27 July 2014 04:52 |
|
|
Originally posted by: Vladimir Ivanov
On Sat, 26 Jul 2014, sicklittlemonkey wrote:
> I love ARM assembly because you must explicitly set an instruction flag
> for it to affect the status register ... and every instruction can be
> optionally conditional anyway.
While that was a nifty thing once when the core was bunch of gates and
people wrote hand-crafted assembler routines, it became obstacle for the
newer speculative out-of-order implementations, among other things like PC
being GPR and LDM/STM instructions. Check what they (finally) removed in
their 64-bit architecture.
|
|
|
|
| Re: POKE and STA for speaker access [message #262507 is a reply to message #262463] |
Sun, 27 July 2014 11:51 |
D Finnigan
Messages: 1154
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
sicklittlemonkey wrote:
> On Sunday, 27 July 2014 05:42:44 UTC+12, D Finnigan wrote:
>> I even put the warning into The New Apple II User's Guide.
>>
>> We must respect tradition.
>
> Heh, I'm still waiting for the corrected 2nd edition to purchase!
>
> Besides - things move quickly in the cutting edge Apple II world. Can you
> keep up with all this new software and hardware!?
>
> Er, please let me proof-read it before I purchase it. ; - )
If I do another book on Apple II, I think it will be focused on assembly
language or some other more technical subject. Not just another book
teaching assembly (we have enough of these), but rather interesting projects
and programming for peripherals in assembly language.
--
]DF$
Apple II Book: http://macgui.com/newa2guide/
Usenet: http://macgui.com/usenet/ <-- get posts by email!
Apple II Web & Blog hosting: http://a2hq.com/
|
|
|
|
| Re: POKE and STA for speaker access [message #262557 is a reply to message #262483] |
Sun, 27 July 2014 20:01 |
sicklittlemonkey
Messages: 570
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Sunday, 27 July 2014 20:31:21 UTC+12, Vladimir Ivanov wrote:
> Internet is just full of .. things. :-)
So is my HDD, but these things are much easier to find when on the internet.. ; - )
>> [Sather] But he missed a significant implication: POKE is "safe" for
>> speaker access when using a 65C02 since the STA (zp),Y instruction only
>> generates one access, not two.
>
> 65SC02, compared to NMOS 6502, generally tries to replace dummy I/O with
> something safe. One notable exception is keeping RWTS happy (STA abs,X),
Yes, this is the crucial point - I have been compiling a table of only the _changes_ to make them easier to see than in Sather's otherwise useful tables.
STA abs,X has been fixed for the PX (page-crossing) case by adding a dummy read of the program counter, so the change was rW -> W. In the non-PX case it still reads the destination address, so there is no change: RW -> RW.
STA (zp),Y has been fixed for both cases by adding a dummy read of the program counter, so the change was rW -> W and RW -> W.
That is potentially a breaking change on a memory mapped computer like the Apple II. It would have been safer to keep the extra write in the non-PX case, but I suppose preserving the behaviour of POKE wasn't a good enough reason! It made POKE safe for toggling soft switches, but nobody seems to know about it.
** The decision by the 65C02 designers to keep the STA abs,X non-PX behaviour must have been because of the disk controller soft switches in the Apple II. No other explanation makes sense. **
And yet Sather didn't spot this, or at least didn't properly update the CPU section of his book for the 65C02. He still suggests STA (zp),Y as an alternative for writing to disk - but that won't work on a 65C02.
> but there are also few surprises here and there.
Oh, anything else you'd care to share? I notice Sather doesn't mention that non-PX INC and DEC don't get the same cycle "discount" as other read-modify-write instructions. (He treats them all the same in row 23 of his tables.)
Cheers,
Nick.
|
|
|
|
|
|
| Re: POKE and STA for speaker access [message #262659 is a reply to message #262627] |
Mon, 28 July 2014 17:09 |
Bill Buckels
Messages: 1418
Registered: November 2012
Karma: 0
|
Senior Member |
|
|
"Scott Alfter" <scott@alfter.diespammersdie.us> wrote:
> BIT $C030 leaves the accumulator alone as well, and without risk of a
> double access.
Hi Scott,
I was wondering if someone would mention this. I can't help but agree:)
As far a Nick's old magazine articles and stuff, "when someone gave grandma
a lemming she made lemming pie"...
Here's the reason that I agree (I will likely need to do some timing
adjustments for cc65 and maybe even do an NSC version that makes a little
more sense to someone who doesn't CD clearly):
Code follows,
Regards,
Bill
/* ------------------------------------------------------------ ------------
System: Manx Aztec C65 Version 3.2b
MS-DOS cross-development environment
Platform : Apple IIe 128K PRODOS 8
Program: sound.c
Description: G2 Library Routine
Written by : Bill Buckels
Revision Date: July 6, 1991
Licence: You may use this code for whatever you wish as long
as you agree that Bill Buckels has no warranty or
liability obligations whatsoever from said use.
------------------------------------------------------------ ------------ */
/* create a proper musical scale for the apple */
/* this is the algorithm that will be used */
/* june 1991 */
/* tired of flat notes... select a piano scale */
/* Apple Pitch Values */
int __pitch[5][12]={
/* C C# D D# E F F# G G# A A# B */
/* 0 1 2 3 4 5 6 7 8 9 10 11 */
285, 270, 257, 243, 229, 215, 200, 188, 179, 171, 167, 160,
150, 142, 132, 126, 117, 111, 106, 99, 93, 88, 83, 79,
74, 70, 65, 61, 58, 55, 51, 48, 45, 43, 40, 38,
36, 34, 32, 30, 28, 26, 24, 23, 21, 20, 19, 18,
17, 34, 32, 30, 28, 26, 24, 23, 21, 20, 19, 18};
sound(octave,note,duration)
char octave,note,duration;
{
int j,pit,temp;
switch(octave)
{
case 0:
case 1: pit= __pitch[0][note];break;
case 2: pit= __pitch[1][note];break;
case 3: pit= __pitch[2][note];break;
case 4: pit= __pitch[3][note];break;
case 5:
case 6: pit= __pitch[4][note];break;
/* silence... try to match the sound loop */
case 7: pit= 128;
temp=(1024*duration)/pit;
NOPER:; /* loop the required note length */
j=pit;
COUNTING:;
if(j--)goto COUNTING;
if(temp--)goto NOPER;
return 0;
}
temp=(1024*duration)/pit;
TOPPER:; /* loop the required note length */
#asm
BIT $C030
#endasm
j=pit;
COUNTER:;
if(j--)goto COUNTER;
if(temp--)goto TOPPER;
/* wait for the duration specified by pitch */
/* then click it again */
}
|
|
|
|
| Re: POKE and STA for speaker access [message #262681 is a reply to message #262659] |
Mon, 28 July 2014 18:42 |
sicklittlemonkey
Messages: 570
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Tuesday, 29 July 2014 09:09:50 UTC+12, Bill Buckels wrote:
> "Scott Alfter" wrote:
>> BIT $C030 leaves the accumulator alone as well, and without risk of a
>> double access.
There is no risk of a double access. Why propagate the "myth"?
> #asm
> BIT $C030
> #endasm
Your code is not optimal. ; - )
I presume CC65 has a an optimizer on the resulting assembly language? By doing a BIT you change 3 processor status flags. It probably doesn't matter in this case, but somewhere else it might.
Cheers,
Nick.
|
|
|
|
| Re: POKE and STA for speaker access [message #262685 is a reply to message #262681] |
Mon, 28 July 2014 21:27 |
Bill Buckels
Messages: 1418
Registered: November 2012
Karma: 0
|
Senior Member |
|
|
"sicklittlemonkey" <nick.westgate@gmail.com> wrote:
>Your code is not optimal. ; - )
It rarely is. But I was younger then too. So my code seemed faster. This is
old Aztec C code from 1991...
> I presume CC65 has a an optimizer on the resulting assembly language?
No. In fact cc65's optimizer might remove inline assembly if it isn't
disabled for the function.
cc65's optimizer is for C code only. In cc65 you either disable the
optimizer for any functions that use inline assembly, or you write in
assembly and link to your C code. It amounts to almost the same thing since
assembly code is not optimized in either case, but if you do use inline
assembly it's best not to do much else in the same function because loops
and stuff won't benefit.
Aztec C did not optimize anyway so no worry about code ever being optimal:)
> By doing a BIT you change 3 processor status flags. It probably doesn't
> matter in this case, but somewhere else it might.
I'll use STA $C030 then. No point in not listening further.
Bill
|
|
|
|
| Re: POKE and STA for speaker access [message #262686 is a reply to message #262681] |
Mon, 28 July 2014 21:30 |
Michael J. Mahon
Messages: 1767
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
sicklittlemonkey <nick.westgate@gmail.com> wrote:
> On Tuesday, 29 July 2014 09:09:50 UTC+12, Bill Buckels wrote:
>> "Scott Alfter" wrote:
>>> BIT $C030 leaves the accumulator alone as well, and without risk of a
>>> double access.
>
> There is no risk of a double access. Why propagate the "myth"?
>
>> #asm
>> BIT $C030
>> #endasm
>
> Your code is not optimal. ; - )
>
> I presume CC65 has a an optimizer on the resulting assembly language? By
> doing a BIT you change 3 processor status flags. It probably doesn't
> matter in this case, but somewhere else it might.
>
> Cheers,
> Nick.
In my sound programs, other tasks are interspersed with the speaker
toggles, so it's very important to use an instruction that does *nothing*
but toggle the speaker.
--
-michael - NadaNet 3.1 and AppleCrate II: http://home.comcast.net/~mjmahon
|
|
|
|
|
|
| Re: POKE and STA for speaker access [message #262697 is a reply to message #262681] |
Tue, 29 July 2014 00:42 |
scott
Messages: 4237
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
In article <0bfeca41-8ddb-44d8-928d-6f06de0aacd8@googlegroups.com>,
sicklittlemonkey <nick.westgate@gmail.com> wrote:
> On Tuesday, 29 July 2014 09:09:50 UTC+12, Bill Buckels wrote:
>> "Scott Alfter" wrote:
>>> BIT $C030 leaves the accumulator alone as well, and without risk of a
>>> double access.
>
> There is no risk of a double access. Why propagate the "myth"?
"Myth?" From page 37 of the Apple IIe Technical Reference Manual:
> The Speaker
> ===========
>
> The Apple IIe has a small speaker mounted toward the front of the bottom
> plate. The speaker is connected to a soft switch that toggles; it has two
> states, off and on, and it changes from one to the other each time it is
> accessed. (At low frequencies, less than 400 Hz or so, the speaker clicks
> only on every other access.)
>
> If you switch the speaker once, it emits a click; to make longer sounds, you
> access the speaker repeatedly. You should always use a read operation to
> toggle the speaker. If you write to this soft switch, it switches twice in
> rapid succession. The resulting pulse is so short that the speaker doesn't
> have time to respond; it doesn't make a sound.
ISTR observing this behavior long ago, which led to always using LDx or BIT
operations to toggle the speaker. Perhaps processors newer than the 6502
behave differently and this no longer applies; for widest compatibility,
though, you wouldn't want to rely on that.
_/_
/ v \ Scott Alfter (remove the obvious to send mail)
(IIGS( http://alfter.us/ Top-posting!
\_^_/ >What's the most annoying thing on Usenet?
|
|
|
|
| Re: POKE and STA for speaker access [message #262699 is a reply to message #262697] |
Tue, 29 July 2014 01:08 |
sicklittlemonkey
Messages: 570
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Tuesday, 29 July 2014 16:42:41 UTC+12, Scott Alfter wrote:
> "Myth?" From page 37 of the Apple IIe Technical Reference Manual:
Sigh ...
> What's the most annoying thing on Usenet?
People posting in a thread without reading earlier posts? ; - )
Please read the first post in this thread. Download a copy of Understanding the Apple II by Jim Sather if you need further "proof".
Cheers,
Nick.
|
|
|
|
| Re: POKE and STA for speaker access [message #262701 is a reply to message #262557] |
Tue, 29 July 2014 02:02 |
sicklittlemonkey
Messages: 570
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Monday, 28 July 2014 12:01:44 UTC+12, sicklittlemonkey wrote:
> ** The decision by the 65C02 designers to keep the STA abs,X non-PX behaviour must have been because of the disk controller soft switches in the Apple II. No other explanation makes sense. **
Replying to myself here, but I found a bit of relevant info.
This article on the old website (archived, luckily) of Jorge Chamorro Bieling - who used to post to this group regularly:
http://web.archive.org/web/20100331075737/http://homepage.ma c.com/jorgechamorro/a2things/PDFs/65xxx.txt
It was supposedly taken from "// Technical" which I've never heard of. Anyway, the part relevant to this thread:
"The 65c816's design was not without it's problems. Bill Mensch
"improved" the bus interface on the 65c816 (over that used by the
6502). Unfortunately, the Apple's disk drive controller relied on some
of the old kludges in the 6502 chip. With those problems removed, the
65c802 and 65c816 chips worked fine on an Apple computer, but the
disk drives didn't work. Of course Apple immediately began laminting
about the stupidity of the designers at WDC and WDC's designers
immediately began complaining about the stupidity of Apple's design. In
the long run, money won out. If WDC wanted Apple to use the '816, WDC
would have to redesign the chip. They did. This exchanged, combined
with the fact that the 65c816 was two years late coming to market, was
the beginning (if not the cause) of an adversarial relationship between
Apple and WDC. There are those at Apple who feel that the schedule of
the 65c816 was one of the major reasons Apple cancelled the ill-fated
Apple //x project.
Eventually, the 65c816 functioned properly and Apple incorporated
it into the Apple //GS."
Also, an interview with Bill Mensch.
http://www.commodore.ca/commodore-history/bill-mench-the-bra ins-behind-the-brains/
By googling around and I know now a lot more about his significant accomplishments: basically the design of the entire 6502 line of CPUs. Some other links:
http://research.swtch.com/6502
http://silicongenesis.stanford.edu/transcripts/mensch.htm
Anyway, again the relevant part of the first interview:
"In the case of an Apple computer, as an example, the way that [Apple co-founder Steve] Wozniak did his disk controller, we had to make modifications because of the way that the disk controller works."
The article talks about the 6502, 65C02 and 65C816. The last quote is again about the development of the 65C816.
This really surprises me. It doesn't make sense that most 65C02 instructions were optimized except for the one case which would break Apple II RWTS. (STA abs,x where no PX occurs - remember the PX case was optimized.)
Did they only try to optimize that away in the 65C816?
Still looking for an answer.
Cheers,
Nick.
|
|
|
|
|
|
| Re: POKE and STA for speaker access [message #262823 is a reply to message #262557] |
Wed, 30 July 2014 07:29 |
|
|
Originally posted by: Vladimir Ivanov
On Sun, 27 Jul 2014, sicklittlemonkey wrote:
> STA abs,X has been fixed for the PX (page-crossing) case by adding a
> dummy read of the program counter, so the change was rW -> W. In the
> non-PX case it still reads the destination address, so there is no
> change: RW -> RW.
True, the page boundary crossing case does a dummy read of PC.
> STA (zp),Y has been fixed for both cases by adding a dummy read of the
> program counter, so the change was rW -> W and RW -> W.
Just a small correction - as I wrote previously, it does dummy read of
zero page. :-)
> ** The decision by the 65C02 designers to keep the STA abs,X non-PX
> behaviour must have been because of the disk controller soft switches in
> the Apple II. No other explanation makes sense. **
Indeed, so the RWTS and alikes could write.
> Oh, anything else you'd care to share? I notice Sather doesn't mention
> that non-PX INC and DEC don't get the same cycle "discount" as other
> read-modify-write instructions. (He treats them all the same in row 23
> of his tables.)
Yes, $DE/$FE don't save a cycle on no page boundary crossing, but there is
still a twist - the dummy read is different depending on whether or not
page boundary is crossed. I guess another Apple II compatibility patch,
maybe.
|
|
|
|
| Re: POKE and STA for speaker access [message #262961 is a reply to message #262823] |
Thu, 31 July 2014 01:27 |
sicklittlemonkey
Messages: 570
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Wednesday, 30 July 2014 23:29:56 UTC+12, Vladimir Ivanov wrote:
> On Sun, 27 Jul 2014, sicklittlemonkey wrote:
> True, the page boundary crossing case does a dummy read of PC.
Yes - I don't understand why most other "unexpected" reads were cleaned up, but this one still happens. From the Bill Mensch interview it looks like they didn't know about the RWTS/disk controller problem until they tried to develop the 65C816.
>> STA (zp),Y has been fixed for both cases by adding a dummy read of the
>> program counter, so the change was rW -> W and RW -> W.
>
> Just a small correction - as I wrote previously, it does dummy read of
> zero page. :-)
Yes, but that is an extra read of an operand (zp + 1), which can be considered "expected". The operand is read. We don't care how many times. ; - )It doesn't access anywhere "unexpected" like it did in the NMOS 6502. The extra access used to be to the destination (or dest -$100) where we do care how many times.
>> ** The decision by the 65C02 designers to keep the STA abs,X non-PX
>> behaviour must have been because of the disk controller soft switches in
>> the Apple II. No other explanation makes sense. **
>
> Indeed, so the RWTS and alikes could write.
I've changed my mind about this. I think it must have been a lucky accident, because the Bill Mensch interview doesn't mention this problem for the 65C02 development. Only for the 65C816 development.
> Yes, $DE/$FE don't save a cycle on no page boundary crossing, but there is
> still a twist - the dummy read is different depending on whether or not
> page boundary is crossed. I guess another Apple II compatibility patch,
> maybe.
Interesting. Do you have a link for this? The 6502.org site mentions it, but there's no detailed cycle timing. I would be surprised if INC/DEC abs,X did an "unexpected" read - I mean to dest - $100.
And again, it sounds (from the interview) like there was no discussion with Apple about compatibility until the 65C816. The 65C02 working for RWTS seems to be a happy accident.
Cheers,
Nick.
|
|
|
|
| Re: POKE and STA for speaker access [message #263045 is a reply to message #262961] |
Thu, 31 July 2014 15:05 |
|
|
Originally posted by: Vladimir Ivanov
On Wed, 30 Jul 2014, sicklittlemonkey wrote:
> From the Bill Mensch interview it looks like they didn't know about the
> RWTS/disk controller problem until they tried to develop the 65C816.
I somehow doubt this is pure luck, but not losing much sleep over it,
either. :-)
>>> STA (zp),Y has been fixed for both cases by adding a dummy read of the
>>> program counter, so the change was rW -> W and RW -> W.
>>
>> Just a small correction - as I wrote previously, it does dummy read of
>> zero page. :-)
>
> Yes, but that is an extra read of an operand (zp + 1), which can be
> considered "expected". The operand is read. We don't care how many
> times. ; - )It doesn't access anywhere "unexpected" like it did in the
> NMOS 6502. The extra access used to be to the destination (or dest
> -$100) where we do care how many times.
That feature of the NMOS 6502 was a neat trick for C64 people. Otherwise
plenty dangerous near I/O areas in various embedded 6502 setups, so Mr.
Mensch did the right thing and got rid of it.
>> Yes, $DE/$FE don't save a cycle on no page boundary crossing, but there is
>> still a twist - the dummy read is different depending on whether or not
>> page boundary is crossed. I guess another Apple II compatibility patch,
>> maybe.
>
> Interesting. Do you have a link for this?
My own inspection of G65SC02P.
> The 6502.org site mentions it, but there's no detailed cycle timing. I
> would be surprised if INC/DEC abs,X did an "unexpected" read - I mean to
> dest - $100.
No, 65SC02 does not do dangerous "semi" indexed reads at all, that's the
beauty of it.
The no page boundary crossing case of $DE/$FE does quadruple access to the
target address (RRRW), while the page boundary case does only triple
access (RRW).
|
|
|
|
| Re: POKE and STA for speaker access [message #263089 is a reply to message #263045] |
Thu, 31 July 2014 18:30 |
sicklittlemonkey
Messages: 570
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Friday, 1 August 2014 07:05:14 UTC+12, Vladimir Ivanov wrote:
> On Wed, 30 Jul 2014, sicklittlemonkey wrote:
>> From the Bill Mensch interview it looks like they didn't know about the
>> RWTS/disk controller problem until they tried to develop the 65C816.
>
> I somehow doubt this is pure luck, but not losing much sleep over it, either. :-)
Pure luck is hard to believe, I agree! As you noted (in your email) in the interview Bill said "I had an associate company do some of the logic design on the 65C02". I wonder if they decided to play it safe and preserve more of the abs,X timing.
BTW, here is another link about how early 6502s had problems fixed in later designs. ROR didn't work:
http://www.pagetable.com/?p=406
> My own inspection of G65SC02P.
>
> No, 65SC02 does not do dangerous "semi" indexed reads at all, that's the
> beauty of it.
>
> The no page boundary crossing case of $DE/$FE does quadruple access to the
> target address (RRRW), while the page boundary case does only triple
> access (RRW).
It's almost unbelievable that Sather could have missed this ... unless different 65C02 parts have different quirks.
You probably already know about it, but I found this article that links to details about 65C02 NOPs doing memory accesses! Not good!
http://6502org.wikidot.com/errata-other-65c02opcodes
Cheers,
Nick.
|
|
|
|
| Re: POKE and STA for speaker access [message #263127 is a reply to message #263089] |
Fri, 01 August 2014 02:16 |
|
|
Originally posted by: Vladimir Ivanov
On Thu, 31 Jul 2014, sicklittlemonkey wrote:
> BTW, here is another link about how early 6502s had problems fixed in
> later designs. ROR didn't work:
> http://www.pagetable.com/?p=406
Yes, that's a well known one.
> You probably already know about it, but I found this article that links
> to details about 65C02 NOPs doing memory accesses! Not good!
> http://6502org.wikidot.com/errata-other-65c02opcodes
This entry is correct, except about $5C.
Some of these opcodes aren't really NOPs, they are simply unused (or
whatever they do inside is not registered) and they belong to certain
addressing mode classes. Think of them as extension placeholders. I
wouldn't even call this "Errata".
From the webpage: "However, opcode $5C does not access memory, though it
does take 8 cycles."
$5C actually does a kind of memory addressing, but mostly fixed and quite
useless. Or it has very secret application. :-)
|
|
|
|
| Re: POKE and STA for speaker access [message #394389 is a reply to message #262701] |
Sat, 09 May 2020 00:28 |
sicklittlemonkey
Messages: 570
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Tuesday, 29 July 2014 16:02:18 UTC+10, Nick Westgate wrote:
> Did they only try to optimize that away in the 65C816?
>
> Still looking for an answer.
As a coda to this old thread, some more facts have recently come to light.
Oliver Schmidt started a discussion over on comp.sys.apple2.programmer:
"Phantom reads on 6502, 65C02 and 65816"
https://groups.google.com/d/topic/comp.sys.apple2.programmer /qk7MZPRgVXI/discussion
It turns out that Antoine had the answers all along, as usual. ; - )
http://www.brutaldeluxe.fr/documentation/cortland/v7.zip
(I do wonder why Apple France had this info and not the rest of us.)
Anyway, I'll note a couple of items, tests, and fun facts.
For some reason I had always pictured the 65816 emulating the 65C02.
But in the following it more closely emulates the NMOS 6502.
The instructions of interest:
1. STA abs,X - page crossing - fixed invalid (read) access on 65C02.
2. STA abs,X - no page crossing - double access (read then write).
3. STA (zp),Y - no page crossing - single access on 65C02. (Fixes POKE.)
How do these behave on the 65816?
1. STA abs,X - page crossing - fixed invalid (read) access on 65C02.
Widely known and documented by Sather in Understanding the Apple //e.
But: It ain't what you don't know that gets you into trouble.
It's what you know for sure that just ain't so. (Mark Twain supposedly.)
So we can test it with this code:
300: A2 51 BD FF C0 4C DA FD
LDX #51
LDA C0FF,X
JMP FDDA
On my ROM 3 IIgs this turns on graphics mode, so C050 was touched.
And it prints 22, which is the value of C150.
And it didn't matter if:
e=0 or 1
x=0 or 1
m=0 or 1
We use LDY and LDA abs,Y.
So in this case the 65C816 behaves like an NMOS 6502.
The CPU I tested was a CMD (micro symbol) G65SC816P-4 from 1989.
I also tested an enhanced //e with an NCR 65C02A.
Graphics stayed off, so there was no invalid access.
2. STA abs,X - no page crossing - double access (read then write).
This behaves the same on all 3 chips because of the disk controller.
It's mentioned as a bone of contention in the Mensch interview.
A fun new (old) fact is that the IWM doesn't need the double access!
http://www.brutaldeluxe.fr/documentation/iwm/iwm_discussion_ 19820531.pdf
We'll test this with the next instruction...
3. STA (zp),Y NX now does a single accesses on 65C02. (This fixes POKE.)
On anything pre-IIgs we need to make sure we have an F8 ROM in RAM, eg:
C081 C081 N F800<F800.FFFFM
Now consider the following code we'll put at 300:
LDA #$C0
STA $01
LDA #$81
STA $00
LDA #$00
TAX
TAY
BIT $C080
BIT $C081
BIT $C081 ;READ 2
STA $D000
BIT $C080
RTS
This will set D000 to 0 in LC RAM Bank 2.
The second read (BIT $C081) is necessary to enable LC RAM write.
If we change BIT to STA with 312:8D, the code fails to change D000.
On the //e with 65C02:
We can test STA abs,X with 312:9D. This works, so there is a read.
Now STA (zp),Y with 312:91 00 EA. This fails; there is no read.
One the IIgs:
STA abs,X with 312:9D. This works, so there is a read.
STA (zp),Y with 312:91 00 EA. This works; there is still a read.
So again the 65816 acts like an NMOS 6502 and POKE is not good for C030!
Cheers,
Nick.
|
|
|
|
Members
Search
Help
Register
Login
Home
