Re: Does an enhanced //e _ALWAYS_ have 80 col. support?

[mjmahon@aol.com (Michael J. Mahon)]

Don Bruder replied:

>In article <20041123133113.21939.00001199@mb-m06.aol.com>,
> mjmahon@aol.com (Michael J. Mahon) wrote:
>
>> Don Bruder wrote:
>> 
>> >In article <Udzod.178761$df2.88821@edtnps89>,
>> > "Craig Bower \(Bender MX\)" <NOSPAMnitroacd@telusplanet.NAYSPAM.net> 
>> > wrote:
>> 
>> <snip>
>> 
>> >> For Example from assembly:
>> >> 
>> >> LDA #$00                   Load Accum with #$00 (soft swtich bait)
>> >> STA $C00A                Enable main ROM from $C300-$C3FF
>> >> JSR $C300                  PR#3
>> >> LDA #$00                   Reset Accum in case JSR $C300 scrambled it.
>> >> <<STA $C00C>>    << Might be optional -try it with & w/out
>> >> STA $C00F                Turn on Alternate character set.
>> >
>> >ERROR! ERROR! ERROR! ERROR!!!
>> >
>> >When playing with soft-switches, *ALWAYS* *READ* from them, unless 
>> >specifically told that writing to activate them is OK. Some of them 
>> >don't care. Others will toggle twice when written. (A read involves one 
>> >access, a write involves two accesses - one to "locate" the address, the 
>> >second to do the actual write) 
>> 
>> *** ERROR: ERRONEOUS ERROR MESSAGE ABOVE! ***  ;-)
>> 
>> Many of the //e softswitches can be written to.  Some _must_ be
>> written to since they have different functions depending on whether
>> they are read or written.
>
>Right, that's what I was referring to. When in doubt, the "rule" I 
>always knew was "read unless specifically told otherwise". 

And that "rule" is an incorrect generalization.  Only _some_
stores do a double access, and most of the "original" soft
switches don't care whether they are read from or written to.

If a "read"-type operation would disturb flags or a register,
then a store can be more appropriate.

>> $C00F is a switch that should be written to.
>> 
>> The only time a "store" accesses the effective address twice is
>> in the indexed form.  I think this myth got started because of
>> the warnings about POKE vs. PEEK, since POKE uses an
>> indexed store.
>
>Hmmm... That'd be a new one on me. Wasn't aware of it being limited to 
>the indexed forms. I've always been under the impression that all writes 
>did what amounts to "look at the address (counts as one access) store 
>the value (counts as second access)" 

Nothing is actually "looking"--the data is ignored.  The processor just
has to do some kind of a memory cycle, and a read is more benign
than a write.  ;-)

>> Jim Sather has a nice table showing exactly what bus activity
>> results from the execution of each opcode.
>
>Sounds like an interesting item to have... Might just have to go looking 
>for it if Jim doesn't offer to ship it direct. :) 

I was referring to "Understanding the Apple II(e)", and it would be
great if you could actually find him.

When I get to it (this is a busy week ;-), I'll scan the 6502 and 65C02
tables and post them.  They're a little tricky to read, but they are
intelligible to anyone who needs them, and they are a lot more compact
than a complete bus activity dissection.

-michael

Check out parallel computing for 8-bit Apples on my
Home page:  http://members.aol.com/MJMahon/