Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.apple2.programmer > #2912 > unrolled thread

detecting if ASCII value is a letter

Back to article view | Back to comp.sys.apple2.programmer

Contents

  detecting if ASCII value is a letter Mark Lemmert <mark.lemmert@gmail.com> - 2016-08-11 10:49 -0700
    Re: detecting if ASCII value is a letter Michael Pohoreski <michael.pohoreski@gmail.com> - 2016-08-11 13:04 -0700
    Re: detecting if ASCII value is a letter Michael Pohoreski <michael.pohoreski@gmail.com> - 2016-08-11 13:05 -0700
    Re: detecting if ASCII value is a letter Michael Pohoreski <michael.pohoreski@gmail.com> - 2016-08-11 13:44 -0700
      Re: detecting if ASCII value is a letter Mark Lemmert <mark.lemmert@gmail.com> - 2016-08-11 14:25 -0700
      Re: detecting if ASCII value is a letter Michael J. Mahon <mjmahon@aol.com> - 2016-08-11 23:44 -0500
    Re: detecting if ASCII value is a letter Mark Lemmert <mark.lemmert@gmail.com> - 2016-08-11 16:26 -0700
      Re: detecting if ASCII value is a letter Michael Pohoreski <michael.pohoreski@gmail.com> - 2016-08-11 18:28 -0700
        Re: detecting if ASCII value is a letter Michael J. Mahon <mjmahon@aol.com> - 2016-08-12 02:54 -0500
          Re: detecting if ASCII value is a letter Mark Lemmert <mark.lemmert@gmail.com> - 2016-08-12 07:37 -0700
            Re: detecting if ASCII value is a letter Michael Pohoreski <michael.pohoreski@gmail.com> - 2016-08-12 08:10 -0700
            Re: detecting if ASCII value is a letter mmphosis <mmphosis@macgui.com> - 2016-08-12 15:57 +0000
              Re: detecting if ASCII value is a letter Mark Lemmert <mark.lemmert@gmail.com> - 2016-08-12 11:11 -0700
                Re: detecting if ASCII value is a letter Michael J. Mahon <mjmahon@aol.com> - 2016-08-12 16:15 -0500
                Re: detecting if ASCII value is a letter Michael Pohoreski <michael.pohoreski@gmail.com> - 2016-08-13 09:53 -0700
                  Re: detecting if ASCII value is a letter Michael J. Mahon <mjmahon@aol.com> - 2016-08-13 15:29 -0500
                  Re: detecting if ASCII value is a letter Mark Lemmert <mark.lemmert@gmail.com> - 2016-08-19 19:22 -0700
                Re: detecting if ASCII value is a letter rich.martin@gmail.com - 2016-08-13 20:49 -0700
        Re: detecting if ASCII value is a letter Anthony Lawther <alawther@spammenot.mac.com> - 2016-08-14 16:09 +0900
          Re: detecting if ASCII value is a letter Michael Pohoreski <michael.pohoreski@gmail.com> - 2016-08-15 09:09 -0700
      Re: detecting if ASCII value is a letter John Brooks <jbrooks@blueshiftinc.com> - 2016-08-11 21:49 -0700
        Re: detecting if ASCII value is a letter Michael Pohoreski <michael.pohoreski@gmail.com> - 2016-08-12 06:17 -0700
          Re: detecting if ASCII value is a letter Mark Lemmert <mark.lemmert@gmail.com> - 2016-08-12 07:40 -0700
            Re: detecting if ASCII value is a letter Michael Pohoreski <michael.pohoreski@gmail.com> - 2016-08-12 10:37 -0700
              Re: detecting if ASCII value is a letter Mark Lemmert <mark.lemmert@gmail.com> - 2016-08-12 11:41 -0700
                Re: detecting if ASCII value is a letter Michael J. Mahon <mjmahon@aol.com> - 2016-08-12 16:15 -0500
              Re: detecting if ASCII value is a letter D Finnigan <dog_cow@macgui.com> - 2016-08-12 21:09 +0000
                Re: detecting if ASCII value is a letter Michael Pohoreski <michael.pohoreski@gmail.com> - 2016-08-12 17:35 -0700

Page 1 of 2  [1] 2  Next page →

#2912 — detecting if ASCII value is a letter

Does anyone know if there is a more efficient way than the code below to detect if an ASCII value is a letter (A-Z). It seems like there should be a bit level way of doing it but I haven't been able to figure it out. 

I'm using this in conjunction with AND #$DF to convert the ASCII value to lower case, but unless I'm missing something I need to make the ASCII value is a letter first to avoid corrupting non-letter values. 

Thanks!


	lda value
	cmp #$C1
	bcc .NOT.A.LETTER
	cmp #$FB
	bcs .NOT.A.LETTER2

[toc] | [next] | [standalone]

#2914

On Thursday, August 11, 2016 at 10:49:09 AM UTC-7, Mark Lemmert wrote:

With one of our favorite Beagle Bros ASCII chart:
http://www.lazilong.com/apple_ii/bbros/ascii.jpg

A =$C1
Z = $DA
a = $E1
z = $FA

1. You have a typo:
> 	cmp #$FB

Should be:
cmp #$DB


2. Other then that, yup, looks good!  Unfortunately ASCII has the upper case and lower case non-contiguous (I'm assuming to simply the logic TO_UPPER and TO_LOWER) so we have to do two tests. :-/

Here is a mini test driver:

ESC = quit, else it prints
* original char
* char converted to upper case
* Y if is letter, else [N] if not.

CALL-151
!
300: LDA $C000
 BPL $300
 STA $C010
 CMP #$9B
 PHP
 JSR $FDED ; COUT
  JSR $321 ; TOUPPER
 JSR $FDED
 TYA
 JSR $FDED
 JSR $FD8E ; CROUT
 PLP
 BNE $300
 LDY #$4E ; inverse N
 RTS
 AND #$DF ; TOUPPER
 CMP #$C1
 BCC $31E
 CMP #$DB
 BCS $31E
 LDY #$'Y
 RTS

300G

Michael

[toc] | [prev] | [next] | [standalone]

#2915

On Thursday, August 11, 2016 at 10:49:09 AM UTC-7, Mark Lemmert wrote:
> I'm using this in conjunction with AND #$DF to convert the ASCII value to lower case,

Methinks you meant UPEPR case. :-)

[toc] | [prev] | [next] | [standalone]

#2916

On Thursday, August 11, 2016 at 10:49:09 AM UTC-7, Mark Lemmert wrote:

Inspecting the "ASCII" (sic.) chars in binary ...

A = $C1 = 1100_0001
Z = $DA = 1101_1010

.. then by logic/reason we can "see" that there is no other optimal code then the two comparisons:

 CMP #min
 BCC not.upper
 CMP #max+1q
 BCS not.upper

OK, Technically you could use *two* instruction if you had a 128-byte lookup table:

   TAY
   LDA IsUpperCase,Y

But since I'm assuming you're optimizing for space and not speed that is not a practical solution. :-)

[toc] | [prev] | [next] | [standalone]

#2917

Hi Michael,

Thanks for the information.

 In this case I have speed to spare and am optimizing for memory, so it sounds like doing the two comparisons is the way to go. I did mean uppercase in the OP. So I'll use $E1 and $FB as the comparison values to detect if the ASCII value is lower case, if so do AND #$DF and if not leave the ASCII value as is. 

Thanks again!

Mark


On Thursday, August 11, 2016 at 3:44:52 PM UTC-5, Michael Pohoreski wrote:
> On Thursday, August 11, 2016 at 10:49:09 AM UTC-7, Mark Lemmert wrote:
> 
> Inspecting the "ASCII" (sic.) chars in binary ...
> 
> A = $C1 = 1100_0001
> Z = $DA = 1101_1010
> 
> .. then by logic/reason we can "see" that there is no other optimal code then the two comparisons:
> 
>  CMP #min
>  BCC not.upper
>  CMP #max+1q
>  BCS not.upper
> 
> OK, Technically you could use *two* instruction if you had a 128-byte lookup table:
> 
>    TAY
>    LDA IsUpperCase,Y
> 
> But since I'm assuming you're optimizing for space and not speed that is not a practical solution. :-)

[toc] | [prev] | [next] | [standalone]

#2920

Michael Pohoreski <michael.pohoreski@gmail.com> wrote:
> On Thursday, August 11, 2016 at 10:49:09 AM UTC-7, Mark Lemmert wrote:
> 
> Inspecting the "ASCII" (sic.) chars in binary ...
> 
> A = $C1 = 1100_0001
> Z = $DA = 1101_1010
> 
> .. then by logic/reason we can "see" that there is no other optimal code
> then the two comparisons:
> 
>  CMP #min
>  BCC not.upper
>  CMP #max+1q
>  BCS not.upper
> 
> OK, Technically you could use *two* instruction if you had a 128-byte lookup table:
> 
>    TAY
>    LDA IsUpperCase,Y
> 
> But since I'm assuming you're optimizing for space and not speed that is
> not a practical solution. :-)
> 

But note that you can have eight separate character "classes" with the
table approach. This is likely quite useful in a more general lexical
analyzer. 

I've found this approach very versatile as well as very fast.  It's very
easy, for example, to include underscore as an alphabetic character with no
code changes. 
-- 
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

[toc] | [prev] | [next] | [standalone]

#2918

On another ASCII related subject, do you know if there is a way to detect the press of the shift key, beyond just shift 0-9? 

I'd especially like to be able to detect a keypress combo of shift+tab, but the only keys I've found with modified ASCII values when pressed with shift are 0-9.

Thanks.


Mark
 

[toc] | [prev] | [next] | [standalone]

#2919

On Thursday, August 11, 2016 at 4:26:56 PM UTC-7, Mark Lemmert wrote:
> On another ASCII related subject, do you know if there is a way to detect the press of the shift key, beyond just shift 0-9? 

Sadly this is not possible due to the *screwed up* design of ASCII -- it mixes up keys and scan codes!

/rant on

Instead of assigning EVERY key an unique code, go figure, ASCII instead hijacks *some* of the special keys and re-assigns them! i.e. The TAB key _generate_ Ctrl-I. e.g. It is impossible tell if the user _actually_pressed TAB or CTRL-I.

This means it is IMPOSSIBLE to detect these keypresses by themselves:

CAPS -- impossible to detect at all
CTRL -- impossible to detect at all
SHIFT -- only possible with 0 .. 9

You'll notice that CAPS is not in the ASCII table which is fraking stupid.
And Control key IS detectable BUT ONLY with another char. 
*facepalm*

And these 2 keys are _exactly_ equivalent to these CTRL keys:

ESC - remapped to Ctrl-[
TAB - remapped to Ctrl-I

/rant off

Here is a short program to prove this:

!
300: LDA $C000
 BPL $302
 STA $C010
 JMP $FDDA ; PRBYTE

If you press CAPS, SHIFT, CTRL, nothing happens.
If you press ESC and Ctrl-[ you'll get the same scan code: $9B
If you press TAB, and Ctrl-I you'll get the exact same scan code: $89

Woz only made 3 mistakes with the Apple ][.  This was one of them -- but I suspect he didn't want to fix the stupidity of the ASCII sequence.

The 2nd mistake was using High Bit for key press.  ASCII is only 7-bit.  Reading $C000 should have return a POSITIVE number (< $80) when a key was pressed, and returned MINUS when there was no key (>= $80).  Sadly, he reversed the logic but as this is only a minor sin it is forgivable.


> I'd especially like to be able to detect a keypress combo of shift+tab, but the only keys I've found with modified ASCII values when pressed with shift are 0-9.

Can't do that on the Apple. :-(

The only reason Shift-0 .. Shift-9 even work in the first place is because there are OTHER chars assigned to them.

Also, if run on an Apple ][ you will notice the shifted 0-9 keys are NOT in the standard locations!

http://www.hp9845.net/9845/history/comparison/images/closeups/apple2-top-view.jpg
vs
http://mirrors.apple2.org.za/Apple%20II%20Documentation%20Project/Computers/Apple%20II/Apple%20IIe/Photos/Apple%20IIe%20-%20Keyboard.jpg

Key ][ //e
1 ! ! no change
2 " @
3 # # no change
4 $ $ no change
5 % % no change
6 & ^
7 ' &
8 ( *
9 ) (
0 n/a )


Also the last 2 keys got switched around:
Apple ][
: *
- =

Apple //e
- _
= +

I don't know who switched these around to the modern layout.  Does anyone know about the "etymology" of the keyboard?

Michael

[toc] | [prev] | [next] | [standalone]

#2922

Michael Pohoreski <michael.pohoreski@gmail.com> wrote:
> On Thursday, August 11, 2016 at 4:26:56 PM UTC-7, Mark Lemmert wrote:
>> On another ASCII related subject, do you know if there is a way to
>> detect the press of the shift key, beyond just shift 0-9? 
> 
> Sadly this is not possible due to the *screwed up* design of ASCII -- it
> mixes up keys and scan codes!
> 
> /rant on
> 
> Instead of assigning EVERY key an unique code, go figure, ASCII instead
> hijacks *some* of the special keys and re-assigns them! i.e. The TAB key
> _generate_ Ctrl-I. e.g. It is impossible tell if the user _actually_pressed TAB or CTRL-I.
> 
> This means it is IMPOSSIBLE to detect these keypresses by themselves:
> 
> CAPS -- impossible to detect at all
> CTRL -- impossible to detect at all
> SHIFT -- only possible with 0 .. 9
> 
> You'll notice that CAPS is not in the ASCII table which is fraking stupid.
> And Control key IS detectable BUT ONLY with another char. 
> *facepalm*
> 
> And these 2 keys are _exactly_ equivalent to these CTRL keys:
> 
> ESC - remapped to Ctrl-[
> TAB - remapped to Ctrl-I
> 
> /rant off
> 
> Here is a short program to prove this:
> 
> !
> 300: LDA $C000
>  BPL $302
>  STA $C010
>  JMP $FDDA ; PRBYTE
> 
> If you press CAPS, SHIFT, CTRL, nothing happens.
> If you press ESC and Ctrl-[ you'll get the same scan code: $9B
> If you press TAB, and Ctrl-I you'll get the exact same scan code: $89
> 
> Woz only made 3 mistakes with the Apple ][.  This was one of them -- but
> I suspect he didn't want to fix the stupidity of the ASCII sequence.
> 
> The 2nd mistake was using High Bit for key press.  ASCII is only 7-bit. 
> Reading $C000 should have return a POSITIVE number (< $80) when a key was
> pressed, and returned MINUS when there was no key (>= $80).  Sadly, he
> reversed the logic but as this is only a minor sin it is forgivable.
> 
> 
>> I'd especially like to be able to detect a keypress combo of shift+tab,
>> but the only keys I've found with modified ASCII values when pressed with shift are 0-9.
> 
> Can't do that on the Apple. :-(
> 
> The only reason Shift-0 .. Shift-9 even work in the first place is
> because there are OTHER chars assigned to them.
> 
> Also, if run on an Apple ][ you will notice the shifted 0-9 keys are NOT
> in the standard locations!
> 
> http://www.hp9845.net/9845/history/comparison/images/closeups/apple2-top-view.jpg
> vs
> http://mirrors.apple2.org.za/Apple%20II%20Documentation%20Project/Computers/Apple%20II/Apple%20IIe/Photos/Apple%20IIe%20-%20Keyboard.jpg
> 
> Key ][ //e
> 1 ! ! no change
> 2 " @
> 3 # # no change
> 4 $ $ no change
> 5 % % no change
> 6 & ^
> 7 ' &
> 8 ( *
> 9 ) (
> 0 n/a )
> 
> 
> Also the last 2 keys got switched around:
> Apple ][
>> *
> - 
> Apple //e
> - _
> = +
> 
> I don't know who switched these around to the modern layout.  Does anyone
> know about the "etymology" of the keyboard?
> 
> Michael
> 
> 

Well, for one thing, the Apple ]['s ASCII keyboard was first implemented by
a third party using a (then) conventional keyboard encoder. 

The encoder had inputs specifically for the shift key and the control key,
because then (as most do now) those keys were regarded as "modifier"
keys--keys which shift the mapping of other keys if held down during other
key presses. 

The had no meaning individually, only as modifiers to "real"
character-producing keys. 

You may regard this as a design error, but it was the standard method of
implementing an ASCII keyboard until the introductory of "scan code"
keyboards, which leave the encoding job to software. Ironically, in almost
all cases, scan code keyboards plus software encoders behave almost exactly
as hardware-encoded keyboards!

Doing the encoding in hardware, with modifier keys, is a completely
consistent method of implementing a keyboard--at the level of character
inputs, not switch matrix closings. (Of course, the modifier keys are wired
directly, not as part of a matrix.)

The //e introduced two more modifier keys, also wired as directly-sensed
keys, which an Apple //e (or later) application must decode/interpret with
software. 

I'd suggest using these, Open Apple and Closed Apple, as modifiers that you
can sense directly in software. 

Many Apples had the "shift key mod" installed--it's as easy as soldering a
jumper on an early //e board, and it's installed by default on Platinum
//e's. This modification makes the shift key state observable as the state
of Pushbutton 3. 

If you really need it, and don't mind programming for a "nonstandard"
Apple, you can do something very similar with the control key, most likely
by making it a synonym for one of the Apple keys. 
-- 
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

[toc] | [prev] | [next] | [standalone]

#2924

On Friday, August 12, 2016 at 2:55:05 AM UTC-5, mjm...@aol.com wrote:
> I'd suggest using these, Open Apple and Closed Apple, as modifiers that you
> can sense directly in software. 

Thanks for the information you posted. How do I detected the open/closed Apple keys? I don't see them in the ASCII table I have (Beagle Brothers).


Thanks!


Mark

[toc] | [prev] | [next] | [standalone]

#2926

On Friday, August 12, 2016 at 7:37:16 AM UTC-7, Mark Lemmert wrote:
> Thanks for the information you posted. 

No prob.


> How do I detected the open/closed Apple keys? I don't see them in the ASCII table I have (Beagle Brothers).

You need to look on the "other side" of the poster, in the "Keyboard, etc." section. :-)
http://beagle.applearchives.com/Posters/Poster%202.jpg

Counter-intuitively they are mapped to the joystick buttons !

!
300: LDA $C061 ; open apple
 JSR $FDDA
 JSR $FD8E
 JMP $300

< $80 not pressed
>= $80 pressed

You'll want to bookmark / save / print this reference:
http://www.kreativekorp.com/miscpages/a2info/iomemory.shtml

C061 49249 RDBTN0        ECG  R7  Switch Input 0 / Open Apple
C062 49250 BUTN1         E G  R7  Switch Input 1 / Solid Apple

[toc] | [prev] | [next] | [standalone]

#2927

They are not read as keys, but as push buttons...

OPNAPPLE = $C061 ;open apple (command) key data (read)

CLSAPPLE = $C062 ;closed apple (option) key data (read)

These are actually the first two game Pushbutton inputs (PB0
and PB1) which are borrowed by the Open Apple and Closed Apple
keys. Bit 7 is set (=1) in these locations if the game switch or
corresponding key is pressed.

PB2 =      $C063 ;game Pushbutton 2 (read)
This input has an option to be connected to the shift key on
the keyboard. (See info on the 'shift key mod'.)

TAPEIN =   $C060 ;bit 7 = data from cassette on Apple II,
or PB3           ;II+, IIe. On IIgs bit 7 reflects the
                 ;status of Game Port Pushbutton 3--
                 ;closed= 1. (read)

http://web.archive.org/web/20101216114131/http://home.swbell.net/rubywand/csa2pfaq.html#004

[toc] | [prev] | [next] | [standalone]

#2931

Thanks for the tip on using $C063 to detect the shift key!

I read up on the 'shif key mod' an Apple II history site says it refers to an optional wire connected to the shift key on early Apple computers as a means of producing upper/lower case, and that it became installed standard as of the IIe. 

I did some experimenting by pressing keys and checking $C061-$C063 on different platforms and found some interesting results. All emulator test were done in unenhanced IIe mode. 

PC Results (AppleWIN)
                                         $C061           $C062          $C063
SHIFT ON/OFF                 $20/$20       $20/$20       $20/$20
ALT LEFT ON/OFF           $A0/$20       $20/$20       $20/$20
ALT RIGHT ON/OFF         $20/$20       $20/$A0       $20/$20

Mac (Virtual ][)
                                               $C061           $C062          $C063
SHIFT ON/OFF                       $00/$00       $00/$00       $00/$00
ALT-OPT LEFT ON/OFF         $00/$00       $80/$00       $00/$00
ALT-OPT RIGHT ON/OFF       $00/$00       $80/$00       $00/$00


Mac (AppleWIN via RDP to PC session)
                                         $C061           $C062          $C063
SHIFT ON/OFF                 $20/$20       $20/$20       $20/$20
ALT LEFT ON/OFF           $A0/$20       $20/$20       $20/$20
ALT RIGHT ON/OFF         $A0/$20       $20/$20       $20/$20


Real Apple IIe
                                         $C061           $C062          $C063
SHIFT ON/OFF                 $20/$20       $20/$20       $20/$A0

The open apple key results were all over the board.

When pressing open apple + D here are a few of the values I got in $C061-$C063

$B0 / $42 / $BD
$B0 / $20 / $A0
$BC / $2D / $A0
$FF / $7F / $A0
$A0 / $20 / $A0

This is the code I was using to test:

.KEYIN
	LDA KB_BUFFER
       BPL .KEYIN				
       STA KB_BUFFER_ACK      
	
	LDA $C061
	LDX $C062
	LDY $C063
	BRK


My conclusions:

The shift key detect works great on the real Apple IIe but not in the emulators. 

If the open apple key values were consistent on the real IIe, there might be an angle to attach a user interface function to open apple + tab, alt + tab (PC), and alt-opt + tab (MAC). But, alt + tab is already used on the PC to switch between windows so this probably isn't practical. 


I think I'm at a dead end on this, unless anyone has any other ideas?

Thanks much to everyone for all the posts and information!
 

Mark










To clarify my goal, it is to find a key I can detect in conjunction with tab (so some key + tab), that will work on real IIe's and above, PC emulators and make emulators. This is for purposes of a user interface. 




On Friday, August 12, 2016 at 10:57:40 AM UTC-5, mmphosis wrote:
> PB2 =      $C063 ;game Pushbutton 2 (read)
> This input has an option to be connected to the shift key on
> the keyboard. (See info on the 'shift key mod'.)
> 
> 
> http://web.archive.org/web/20101216114131/http://home.swbell.net/rubywand/csa2pfaq.html#004

[toc] | [prev] | [next] | [standalone]

#2935

Mark Lemmert <mark.lemmert@gmail.com> wrote:
> Thanks for the tip on using $C063 to detect the shift key!
> 
> I read up on the 'shif key mod' an Apple II history site says it refers
> to an optional wire connected to the shift key on early Apple computers
> as a means of producing upper/lower case, and that it became installed
> standard as of the IIe. 
> 
> I did some experimenting by pressing keys and checking $C061-$C063 on
> different platforms and found some interesting results. All emulator test
> were done in unenhanced IIe mode. 
> 
> PC Results (AppleWIN)
>                                          $C061           $C062          $C063
> SHIFT ON/OFF                 $20/$20       $20/$20       $20/$20
> ALT LEFT ON/OFF           $A0/$20       $20/$20       $20/$20
> ALT RIGHT ON/OFF         $20/$20       $20/$A0       $20/$20
> 
> Mac (Virtual ][)
>                                                $C061           $C062          $C063
> SHIFT ON/OFF                       $00/$00       $00/$00       $00/$00
> ALT-OPT LEFT ON/OFF         $00/$00       $80/$00       $00/$00
> ALT-OPT RIGHT ON/OFF       $00/$00       $80/$00       $00/$00
> 
> 
> Mac (AppleWIN via RDP to PC session)
>                                          $C061           $C062          $C063
> SHIFT ON/OFF                 $20/$20       $20/$20       $20/$20
> ALT LEFT ON/OFF           $A0/$20       $20/$20       $20/$20
> ALT RIGHT ON/OFF         $A0/$20       $20/$20       $20/$20
> 
> 
> Real Apple IIe
>                                          $C061           $C062          $C063
> SHIFT ON/OFF                 $20/$20       $20/$20       $20/$A0
> 
> The open apple key results were all over the board.
> 
> When pressing open apple + D here are a few of the values I got in $C061-$C063
> 
> $B0 / $42 / $BD
> $B0 / $20 / $A0
> $BC / $2D / $A0
> $FF / $7F / $A0
> $A0 / $20 / $A0
> 
> This is the code I was using to test:
> 
> .KEYIN
> 	LDA KB_BUFFER
>        BPL .KEYIN				
>        STA KB_BUFFER_ACK      
> 	
> 	LDA $C061
> 	LDX $C062
> 	LDY $C063
> 	BRK
> 
> 
> My conclusions:
> 
> The shift key detect works great on the real Apple IIe but not in the emulators. 
> 
> If the open apple key values were consistent on the real IIe, there might
> be an angle to attach a user interface function to open apple + tab, alt
> + tab (PC), and alt-opt + tab (MAC). But, alt + tab is already used on
> the PC to switch between windows so this probably isn't practical. 
> 
> 
> I think I'm at a dead end on this, unless anyone has any other ideas?
> 
> Thanks much to everyone for all the posts and information!
>  
> 
> Mark
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> To clarify my goal, it is to find a key I can detect in conjunction with
> tab (so some key + tab), that will work on real IIe's and above, PC
> emulators and make emulators. This is for purposes of a user interface. 
> 
> 
> 
> 
> On Friday, August 12, 2016 at 10:57:40 AM UTC-5, mmphosis wrote:
>> PB2 =      $C063 ;game Pushbutton 2 (read)
>> This input has an option to be connected to the shift key on
>> the keyboard. (See info on the 'shift key mod'.)
>> 
>> 
>> http://web.archive.org/web/20101216114131/http://home.swbell.net/rubywand/csa2pfaq.html#004
> 

Note that only the high bit of the pushbutton input "ports" is relevant.
The rest of the bits are just "vapor" left on the bus by the immediately
preceding video memory access. Test them with BPL or BMI. 
-- 
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

[toc] | [prev] | [next] | [standalone]

#2937

On Friday, August 12, 2016 at 11:12:01 AM UTC-7, Mark Lemmert wrote:
> PC Results (AppleWIN)
>                                          $C061           $C062          $C063
> SHIFT ON/OFF                 $20/$20       $20/$20       $20/$20
> ALT LEFT ON/OFF           $A0/$20       $20/$20       $20/$20
> ALT RIGHT ON/OFF         $20/$20       $20/$A0       $20/$20

Hmm, I don't recall AppleWin ever having support the shift-key mod at $C063.
Guess I've never used it since I see it is mentioned in Joystick.cpp

https://github.com/AppleWin/AppleWin/blob/c7981575701cd2dd3ac36ed0171e66ad319564be/source/Joystick.cpp#L525-L531

NOTE: The shift-key mod is ONLY emulated in the Apple ][ (or ][+) AND if there is no joystick active. It does not function in the //e or //c mode due to this logic:

    if (IS_APPLE2 && (joyinfo[joytype[1]] == DEVICE_NONE))

The IS_APPLE2 macro is defined here:
https://github.com/AppleWin/AppleWin/blob/c7981575701cd2dd3ac36ed0171e66ad319564be/source/Common.h#L163



> Real Apple IIe
>                                          $C061           $C062          $C063
> SHIFT ON/OFF                 $20/$20       $20/$20       $20/$A0

Both on my //e (unenhanced) and //e (enhanced) I tried reading $C063 and it reads MINUS (>$ 80) regardless if shift is pressed or not -- because the shift key mod is not installed.


> The open apple key results were all over the board.
> 
> When pressing open apple + D here are a few of the values I got in $C061-$C063
> 
> $B0 / $42 / $BD
> $B0 / $20 / $A0
> $BC / $2D / $A0
> $FF / $7F / $A0
> $A0 / $20 / $A0

Only the high-bit is valid. The remaining bits are "garbage values" coming from whatever is left on the data bus.

 
> This is the code I was using to test:
> 
> .KEYIN
> 	LDA KB_BUFFER
>        BPL .KEYIN				
>        STA KB_BUFFER_ACK      
> 	
> 	LDA $C061
> 	LDX $C062
> 	LDY $C063
> 	BRK

The push buttons $C061 and $C062 are _independent_ of the keyboard state -- something to keep in mind.

Michael

[toc] | [prev] | [next] | [standalone]

#2938

Michael Pohoreski <michael.pohoreski@gmail.com> wrote:
> On Friday, August 12, 2016 at 11:12:01 AM UTC-7, Mark Lemmert wrote:
>> PC Results (AppleWIN)
>> $C061           $C062          $C063
>> SHIFT ON/OFF                 $20/$20       $20/$20       $20/$20
>> ALT LEFT ON/OFF           $A0/$20       $20/$20       $20/$20
>> ALT RIGHT ON/OFF         $20/$20       $20/$A0       $20/$20
> 
> Hmm, I don't recall AppleWin ever having support the shift-key mod at $C063.
> Guess I've never used it since I see it is mentioned in Joystick.cpp
> 
> https://github.com/AppleWin/AppleWin/blob/c7981575701cd2dd3ac36ed0171e66ad319564be/source/Joystick.cpp#L525-L531
> 
> NOTE: The shift-key mod is ONLY emulated in the Apple ][ (or ][+) AND if
> there is no joystick active. It does not function in the //e or //c mode due to this logic:
> 
>     if (IS_APPLE2 && (joyinfo[joytype[1]] == DEVICE_NONE))
> 
> The IS_APPLE2 macro is defined here:
> https://github.com/AppleWin/AppleWin/blob/c7981575701cd2dd3ac36ed0171e66ad319564be/source/Common.h#L163
> 
> 
> 
>> Real Apple IIe
>> $C061           $C062          $C063
>> SHIFT ON/OFF                 $20/$20       $20/$20       $20/$A0
> 
> Both on my //e (unenhanced) and //e (enhanced) I tried reading $C063 and
> it reads MINUS (>$ 80) regardless if shift is pressed or not -- because
> the shift key mod is not installed.

There is a "double D" spot on the main board that can easily be bridged
with solder to enable the shift key mod. On later //e's and all Platinums
the mod is installed by default, and a "bow tie" on the board can be cut to
disable it. 

>> The open apple key results were all over the board.
>> 
>> When pressing open apple + D here are a few of the values I got in $C061-$C063
>> 
>> $B0 / $42 / $BD
>> $B0 / $20 / $A0
>> $BC / $2D / $A0
>> $FF / $7F / $A0
>> $A0 / $20 / $A0
> 
> Only the high-bit is valid. The remaining bits are "garbage values"
> coming from whatever is left on the data bus.
> 
>  
>> This is the code I was using to test:
>> 
>> .KEYIN
>> LDA KB_BUFFER
>> BPL .KEYIN				
>> STA KB_BUFFER_ACK      
>> 
>> LDA $C061
>> LDX $C062
>> LDY $C063
>> BRK
> 
> The push buttons $C061 and $C062 are _independent_ of the keyboard state
> -- something to keep in mind.
> 
> Michael
> 
> 
> 



-- 
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

[toc] | [prev] | [next] | [standalone]

#2981

Michael,

Thanks for checking this out in AppleWIN. I was wondering if I was doing something wrong!


Mark


On Saturday, August 13, 2016 at 11:53:36 AM UTC-5, Michael Pohoreski wrote:
> On Friday, August 12, 2016 at 11:12:01 AM UTC-7, Mark Lemmert wrote:
> > PC Results (AppleWIN)
> >                                          $C061           $C062          $C063
> > SHIFT ON/OFF                 $20/$20       $20/$20       $20/$20
> > ALT LEFT ON/OFF           $A0/$20       $20/$20       $20/$20
> > ALT RIGHT ON/OFF         $20/$20       $20/$A0       $20/$20
> 
> Hmm, I don't recall AppleWin ever having support the shift-key mod at $C063.
> Guess I've never used it since I see it is mentioned in Joystick.cpp
> 
> https://github.com/AppleWin/AppleWin/blob/c7981575701cd2dd3ac36ed0171e66ad319564be/source/Joystick.cpp#L525-L531
> 
> NOTE: The shift-key mod is ONLY emulated in the Apple ][ (or ][+) AND if there is no joystick active. It does not function in the //e or //c mode due to this logic:
> 
>     if (IS_APPLE2 && (joyinfo[joytype[1]] == DEVICE_NONE))
> 
> The IS_APPLE2 macro is defined here:
> https://github.com/AppleWin/AppleWin/blob/c7981575701cd2dd3ac36ed0171e66ad319564be/source/Common.h#L163

[toc] | [prev] | [next] | [standalone]

#2939

I've been writing a little program recently that uses multiple keypresses and I use the open-apple and closed-apple keys as modifiers, so this is timely. Here's something quick and dirty to show one way you can test for an open-apple modifier along with the Tab key.

			jsr $fc58	; clear text screen
LOOP:		lda $c000	; get keypress
			bpl LOOP
			sta $c010
			cmp #$89	; Tab key
			beq TAB
			jmp LOOP

TAB:		bit $CO61	; read open-apple
			bmi OA_DOWN		
			lda #$D5	; open-apple is UP
			sta $400
			jmp LOOP
OA_DOWN:	lda #$c4	; open-apple is DOWN
			sta $400
			jmp LOOP

On Friday, August 12, 2016 at 2:12:01 PM UTC-4, Mark Lemmert wrote:
> Thanks for the tip on using $C063 to detect the shift key!
> 
> I read up on the 'shif key mod' an Apple II history site says it refers to an optional wire connected to the shift key on early Apple computers as a means of producing upper/lower case, and that it became installed standard as of the IIe. 
> 
> I did some experimenting by pressing keys and checking $C061-$C063 on different platforms and found some interesting results. All emulator test were done in unenhanced IIe mode. 
> 
> PC Results (AppleWIN)
>                                          $C061           $C062          $C063
> SHIFT ON/OFF                 $20/$20       $20/$20       $20/$20
> ALT LEFT ON/OFF           $A0/$20       $20/$20       $20/$20
> ALT RIGHT ON/OFF         $20/$20       $20/$A0       $20/$20
> 
> Mac (Virtual ][)
>                                                $C061           $C062          $C063
> SHIFT ON/OFF                       $00/$00       $00/$00       $00/$00
> ALT-OPT LEFT ON/OFF         $00/$00       $80/$00       $00/$00
> ALT-OPT RIGHT ON/OFF       $00/$00       $80/$00       $00/$00
> 
> 
> Mac (AppleWIN via RDP to PC session)
>                                          $C061           $C062          $C063
> SHIFT ON/OFF                 $20/$20       $20/$20       $20/$20
> ALT LEFT ON/OFF           $A0/$20       $20/$20       $20/$20
> ALT RIGHT ON/OFF         $A0/$20       $20/$20       $20/$20
> 
> 
> Real Apple IIe
>                                          $C061           $C062          $C063
> SHIFT ON/OFF                 $20/$20       $20/$20       $20/$A0
> 
> The open apple key results were all over the board.
> 
> When pressing open apple + D here are a few of the values I got in $C061-$C063
> 
> $B0 / $42 / $BD
> $B0 / $20 / $A0
> $BC / $2D / $A0
> $FF / $7F / $A0
> $A0 / $20 / $A0
> 
> This is the code I was using to test:
> 
> .KEYIN
> 	LDA KB_BUFFER
>        BPL .KEYIN				
>        STA KB_BUFFER_ACK      
> 	
> 	LDA $C061
> 	LDX $C062
> 	LDY $C063
> 	BRK
> 
> 
> My conclusions:
> 
> The shift key detect works great on the real Apple IIe but not in the emulators. 
> 
> If the open apple key values were consistent on the real IIe, there might be an angle to attach a user interface function to open apple + tab, alt + tab (PC), and alt-opt + tab (MAC). But, alt + tab is already used on the PC to switch between windows so this probably isn't practical. 
> 
> 
> I think I'm at a dead end on this, unless anyone has any other ideas?
> 
> Thanks much to everyone for all the posts and information!
>  
> 
> Mark
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> To clarify my goal, it is to find a key I can detect in conjunction with tab (so some key + tab), that will work on real IIe's and above, PC emulators and make emulators. This is for purposes of a user interface. 
> 
> 
> 
> 
> On Friday, August 12, 2016 at 10:57:40 AM UTC-5, mmphosis wrote:
> > PB2 =      $C063 ;game Pushbutton 2 (read)
> > This input has an option to be connected to the shift key on
> > the keyboard. (See info on the 'shift key mod'.)
> > 
> > 
> > http://web.archive.org/web/20101216114131/http://home.swbell.net/rubywand/csa2pfaq.html#004

[toc] | [prev] | [next] | [standalone]

#2941

Michael Pohoreski <michael.pohoreski@gmail.com> wrote:
> On Thursday, August 11, 2016 at 4:26:56 PM UTC-7, Mark Lemmert wrote:
>> On another ASCII related subject, do you know if there is a way to
>> detect the press of the shift key, beyond just shift 0-9? 
> 
> Sadly this is not possible due to the *screwed up* design of ASCII -- it
> mixes up keys and scan codes!
> 
> /rant on
> 
> Instead of assigning EVERY key an unique code, go figure, ASCII instead
> hijacks *some* of the special keys and re-assigns them! i.e. The TAB key
> _generate_ Ctrl-I. e.g. It is impossible tell if the user _actually_pressed TAB or CTRL-I.
> 
> This means it is IMPOSSIBLE to detect these keypresses by themselves:
> 
> CAPS -- impossible to detect at all
> CTRL -- impossible to detect at all
> SHIFT -- only possible with 0 .. 9
> 
> You'll notice that CAPS is not in the ASCII table which is fraking stupid.
> And Control key IS detectable BUT ONLY with another char. 
> *facepalm*
> 
> And these 2 keys are _exactly_ equivalent to these CTRL keys:
> 
> ESC - remapped to Ctrl-[
> TAB - remapped to Ctrl-I
> 
> /rant off
> 
> Here is a short program to prove this:
> 
> !
> 300: LDA $C000
>  BPL $302
>  STA $C010
>  JMP $FDDA ; PRBYTE
> 
> If you press CAPS, SHIFT, CTRL, nothing happens.
> If you press ESC and Ctrl-[ you'll get the same scan code: $9B
> If you press TAB, and Ctrl-I you'll get the exact same scan code: $89
> 
> Woz only made 3 mistakes with the Apple ][.  This was one of them -- but
> I suspect he didn't want to fix the stupidity of the ASCII sequence.
> 
> The 2nd mistake was using High Bit for key press.  ASCII is only 7-bit. 
> Reading $C000 should have return a POSITIVE number (< $80) when a key was
> pressed, and returned MINUS when there was no key (>= $80).  Sadly, he
> reversed the logic but as this is only a minor sin it is forgivable.
> 
> 
>> I'd especially like to be able to detect a keypress combo of shift+tab,
>> but the only keys I've found with modified ASCII values when pressed with shift are 0-9.
> 
> Can't do that on the Apple. :-(
> 
> The only reason Shift-0 .. Shift-9 even work in the first place is
> because there are OTHER chars assigned to them.
> 
> Also, if run on an Apple ][ you will notice the shifted 0-9 keys are NOT
> in the standard locations!
> 
> http://www.hp9845.net/9845/history/comparison/images/closeups/apple2-top-view.jpg
> vs
> http://mirrors.apple2.org.za/Apple%20II%20Documentation%20Project/Computers/Apple%20II/Apple%20IIe/Photos/Apple%20IIe%20-%20Keyboard.jpg
> 
> Key ][ //e
> 1 ! ! no change
> 2 " @
> 3 # # no change
> 4 $ $ no change
> 5 % % no change
> 6 & ^
> 7 ' &
> 8 ( *
> 9 ) (
> 0 n/a )
> 
> 
> Also the last 2 keys got switched around:
> Apple ][
>> *
> - 
> Apple //e
> - _
> = +
> 
> I don't know who switched these around to the modern layout.  Does anyone
> know about the "etymology" of the keyboard?
> 
> Michael
> 
> 
Posting before researching is a sin also. 

5 minutes (at most) with Google:
https://en.m.wikipedia.org/wiki/Bit-paired_keyboard

The Apple ][ keyboard layout is of the teletype class while the Apple //e
keyboard layout  is of the electric typewriter class. 

Please be aware that ASCII was NOT developed as a keyboard encoding code
set but as a data transmission code set derived from telegraph codes. Have
a look at the Teletype 33 keyboard layout. 

You might as well blame Apple for the limitations of NTSC video....

Regards,
Anthony. 

[toc] | [prev] | [next] | [standalone]

#2943

On Sunday, August 14, 2016 at 12:09:25 AM UTC-7, Anthony Lawther wrote:
> Posting before researching is a sin also. 

Can't search if you don't what to look for !

> 5 minutes (at most) with Google:
> https://en.m.wikipedia.org/wiki/Bit-paired_keyboard

Ah! I was not aware of this name ...

> The Apple ][ keyboard layout is of the teletype class while the Apple //e
> keyboard layout  is of the electric typewriter class. 

... nor the _2_ types of keyboard !

Computers adapting ASCII was a kludge or hack. 

On a physical typewriter you can't physically press multiple keys.  Computers don't have those limitations.  The problem is no one ever stopped to *think* if the electric typewriter using ASCII was "the right solution".

> Please be aware that ASCII was NOT developed as a keyboard encoding code
> set but as a data transmission code set derived from telegraph codes. Have
> a look at the Teletype 33 keyboard layout. 

I had completely forgot about teletype.  It has been *decades* since I've seen one and didn't even stop to consider that their layout might be different.  That explains the differences.  Thanks!

> You might as well blame Apple for the limitations of NTSC video....

Apple was just following (bad) standards such as ASCII. :-)

> Regards,
> Anthony.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.sys.apple2.programmer

csiph-web