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 2 of 2 — ← Prev page 1 [2]

#2921

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? 
> 
> 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

You can check if the program is running on a GS. If so, $C025 has keyboard status bits for shift, control, caps-lock, whether the key is on the main keyboard or the numeric keypad, and whether the key is repeating.

So it would be easy to detect shift+tab on the GS.

-JB

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

#2923

On Thursday, August 11, 2016 at 9:49:00 PM UTC-7, John Brooks wrote:
> You can check if the program is running on a GS. If so, $C025 has keyboard status bits for shift, control, caps-lock, whether the key is on the main keyboard or the numeric keypad, and whether the key is repeating.

Oooh, that's awesome to hear the GS fixed the earlier Apple's (keyboard) shortcoming.

Guess it depends on the OP's needs and if a GS-only title is an option or requirement.

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

#2925

On Friday, August 12, 2016 at 8:17:09 AM UTC-5, Michael Pohoreski wrote:
> On Thursday, August 11, 2016 at 9:49:00 PM UTC-7, John Brooks wrote:
> > You can check if the program is running on a GS. If so, $C025 has keyboard status bits for shift, control, caps-lock, whether the key is on the main keyboard or the numeric keypad, and whether the key is repeating.
> 
> Oooh, that's awesome to hear the GS fixed the earlier Apple's (keyboard) shortcoming.
> 
> Guess it depends on the OP's needs and if a GS-only title is an option or requirement.


Michael,

Thanks for the information you posted. The application is IIe unenhanced and above, both real hardware and emulators. I realize that's probably going to be tough from a compatibility standpoint when getting into special keys, but I figured I'd ask before assuming it isn't possible! 



Mark

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

#2930

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

Glad to help.


> The application is IIe unenhanced and above, both real hardware and emulators. 

I would strongly suggest, that if possible, to embrace the idiosyncrasies of the Apple, unless you _really_ need "special support". 

This cuts both ways.  I'll explain:

i.e. Does you app NEED the ability to detect 'A' vs Shift-A vs 'a' ? If no, then it will make your life easier.
i.e. Do you NEED > 64 KB RAM?
i.e. Do you NEED 65C02 code?

Take-away: Don't make your life more complicated then it needs to be. :-)

> I realize that's probably going to be tough from a compatibility standpoint when getting into special keys, but I figured I'd ask before assuming it isn't possible! 
 
Actually, you've made your job a little easier. :-)  Supporting "fixed hardware", such as an //e+ and up, is quite reasonable -- lots of the "newer" old software "shafted" the Apple ][ and ][+ -- and for justifiable reason(s): 

a) You're never going to see DHGR on it so why bother supporting an ][ with "normal" HGR sprites,

b) Likewise if your app needed 128KB, it would be more of a developer headache to support an older Apple ][ with > 64KB using one of the popular ram cards then just to use the native built-in AUX mem of the //e, etc.

c) Lastly, you mentioned an unenhanced //e -- am I correct in assuming you are supporting plain 6502 and not requiring 65C02 ?  Requiring a 65C02 is also quite reasonable as witnessed by the lots of late software that required it.  Are there still any ][+ (only) users left that haven't migrated to the //e+ ? :-)

In this day and age, I think we're all just grateful to see _any_ new programs for the Apple 2. :-)

Also, until recently (this past month) I wouldn't have even bothered with IIgs only programs, however I could  see someone targeting IIgs-only programs because of some technical reason.  It would be a shame that it didn't work on the //e+ as well, but at least understandable.

Only you know your program requirements.

Thankfully, it is fairly easy to see the "Hardware supported Features matrix" across the entire Apple 2 line.

For new apps, I would prioritize it as:

a) IIgs only
b) //e+, //c, etc (65C02)
c) //e and newer (6502)
d) ][+ and newer (6502)

The "lower" you go,  the more compatibility you have. Probably no one really cares anymore at this point, but it is always appreciated by some of us.

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

#2932

On Friday, August 12, 2016 at 12:37:09 PM UTC-5, Michael Pohoreski wrote:
> On Friday, August 12, 2016 at 7:40:43 AM UTC-7, Mark Lemmert wrote:

> Actually, you've made your job a little easier. :-)  Supporting "fixed hardware", such as an //e+ and up, is quite reasonable -- lots of the "newer" old software "shafted" the Apple ][ and ][+ -- and for justifiable reason(s): 
> 
> a) You're never going to see DHGR on it so why bother supporting an ][ with "normal" HGR sprites,
> 
> b) Likewise if your app needed 128KB, it would be more of a developer headache to support an older Apple ][ with > 64KB using one of the popular ram cards then just to use the native built-in AUX mem of the //e, etc.
> 
> c) Lastly, you mentioned an unenhanced //e -- am I correct in assuming you are supporting plain 6502 and not requiring 65C02 ?  Requiring a 65C02 is also quite reasonable as witnessed by the lots of late software that required it.  Are there still any ][+ (only) users left that haven't migrated to the //e+ ? :-)


Correct, I'm supporting plain 6502. If I could go back to the beginning of my project and start over I probably would opt for 65C02.

I started out using 6502 because the book I picked last year to learn assembly (Using 6502 by Randy Hyde) happened to be for the 6502, and by the time I got up to speed on 65C02 I already had a tone of code written. I wish I had done more research first. I was just in one of those situations where I didn't know what I didn't know.  

An argument could probably be made that I could just start using 65C02 opcodes now, and not worry about what's written unless I have to go back and optimize.

The reason I don't do that (in addition to being a little stubborn, I'll admit), is that: 

a) I think my real IIe for testing is unenhanced, I still need to confirm that via the techniques people suggeted in the other thread recently. Or of course open the case and check the serial #. 

b) I've got a really nasty bug where after a BRK I sometimes see a screen or garbage, instead of the monitor prompt, when I have AppleWIN in 65C02 mode. I never happens in 6502 mode. It also sometimes happens on my physical IIe (which of course doesn't fit with my theory that the IIe is unenhanced). On the physical IIe control+reset brings me to the ] prompt and I can get into the monitor with call -151

In any event, these are some issues that I'd need to untangle before switching the project to 65C02. They are all solvable I have no doubt, but I work on them when I'm blocked on everything else, if that makes sense. 

Thanks for your advice though; for future considerations I'm glad to know that a 65C02 //e+ and up app would be well received! I'd love to INC the accumulator and init variables to zero with one opcode :-)


Mark

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

#2934

Mark Lemmert <mark.lemmert@gmail.com> wrote:
> On Friday, August 12, 2016 at 12:37:09 PM UTC-5, Michael Pohoreski wrote:
>> On Friday, August 12, 2016 at 7:40:43 AM UTC-7, Mark Lemmert wrote:
> 
>> Actually, you've made your job a little easier. :-)  Supporting "fixed
>> hardware", such as an //e+ and up, is quite reasonable -- lots of the
>> "newer" old software "shafted" the Apple ][ and ][+ -- and for justifiable reason(s): 
>> 
>> a) You're never going to see DHGR on it so why bother supporting an ][
>> with "normal" HGR sprites,
>> 
>> b) Likewise if your app needed 128KB, it would be more of a developer
>> headache to support an older Apple ][ with > 64KB using one of the
>> popular ram cards then just to use the native built-in AUX mem of the //e, etc.
>> 
>> c) Lastly, you mentioned an unenhanced //e -- am I correct in assuming
>> you are supporting plain 6502 and not requiring 65C02 ?  Requiring a
>> 65C02 is also quite reasonable as witnessed by the lots of late software
>> that required it.  Are there still any ][+ (only) users left that
>> haven't migrated to the //e+ ? :-)
> 
> 
> Correct, I'm supporting plain 6502. If I could go back to the beginning
> of my project and start over I probably would opt for 65C02.
> 
> I started out using 6502 because the book I picked last year to learn
> assembly (Using 6502 by Randy Hyde) happened to be for the 6502, and by
> the time I got up to speed on 65C02 I already had a tone of code written.
> I wish I had done more research first. I was just in one of those
> situations where I didn't know what I didn't know.  
> 
> An argument could probably be made that I could just start using 65C02
> opcodes now, and not worry about what's written unless I have to go back and optimize.
> 
> The reason I don't do that (in addition to being a little stubborn, I'll admit), is that: 
> 
> a) I think my real IIe for testing is unenhanced, I still need to confirm
> that via the techniques people suggeted in the other thread recently. Or
> of course open the case and check the serial #. 
> 
> b) I've got a really nasty bug where after a BRK I sometimes see a screen
> or garbage, instead of the monitor prompt, when I have AppleWIN in 65C02
> mode. I never happens in 6502 mode. It also sometimes happens on my
> physical IIe (which of course doesn't fit with my theory that the IIe is
> unenhanced). On the physical IIe control+reset brings me to the ] prompt
> and I can get into the monitor with call -151
> 
> In any event, these are some issues that I'd need to untangle before
> switching the project to 65C02. They are all solvable I have no doubt,
> but I work on them when I'm blocked on everything else, if that makes sense. 
> 
> Thanks for your advice though; for future considerations I'm glad to know
> that a 65C02 //e+ and up app would be well received! I'd love to INC the
> accumulator and init variables to zero with one opcode :-)

Of course, once you've loaded (or otherwise obtained) a zero into a
register, you can zero all the variables you want with a single Store.  ;-)

With a little planning, most of the advantages of the 65C02 are rendered
moot, since 6502 code is almost as small/fast--and you retain greater
compatibility across the line. 
-- 
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

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

#2933

Michael Pohoreski wrote:
> 
> The "lower" you go,  the more compatibility you have. Probably no one
> really cares anymore at this point, but it is always appreciated by some
> of
> us.
>

The more I use the integer Apple II and the II Plus, both with Language
Card, the more I'm surprised at the wide range of sofware that will run on
these early machines. And I'm glad that not everyone had this same "no one
really cares" opinion as you do. :-P

-- 
]DF$
The Marina IP stack for Apple II--
http://marina.a2hq.com/

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

#2936

On Friday, August 12, 2016 at 2:09:58 PM UTC-7, D Finnigan wrote:
> The more I use the integer Apple II and the II Plus, both with Language
> Card, the more I'm surprised at the wide range of sofware that will run on
> these early machines. And I'm glad that not everyone had this same "no one
> really cares" opinion as you do. :-P

Preaching to the choir. :-)

~30+ years ago I only had an Apple ][+ at home, and had to use the school's Apple //e, so I always appreciated when someone took the time to make sure their code ran on a plain 6502.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web