Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.sys.apple2.programmer > #3940 > unrolled thread
| Started by | Bill Chatfield <billchatfield1@gmail.com> |
|---|---|
| First post | 2017-10-09 21:47 -0700 |
| Last post | 2017-10-12 21:30 -0700 |
| Articles | 13 on this page of 33 — 10 participants |
Back to article view | Back to comp.sys.apple2.programmer
Delete Key Handler for BASIC.SYSTEM Bill Chatfield <billchatfield1@gmail.com> - 2017-10-09 21:47 -0700
Re: Delete Key Handler for BASIC.SYSTEM James Davis <JPD.Enterprises@outlook.com> - 2017-10-09 22:57 -0700
Re: Delete Key Handler for BASIC.SYSTEM James Davis <JPD.Enterprises@outlook.com> - 2017-10-09 23:47 -0700
Re: Delete Key Handler for BASIC.SYSTEM "Mark D. Overholser" <marko@markoverholser.com> - 2017-10-10 09:57 -0700
Re: Delete Key Handler for BASIC.SYSTEM Steve Nickolas <usotsuki@buric.co> - 2017-10-10 12:59 -0400
Re: Delete Key Handler for BASIC.SYSTEM Brian Patrie <bpatrie@bellsouth.spamisicky.net> - 2017-10-12 00:59 -0500
Re: Delete Key Handler for BASIC.SYSTEM Bill Chatfield <billchatfield1@gmail.com> - 2017-10-10 21:02 -0700
Re: Delete Key Handler for BASIC.SYSTEM James Davis <JPD.Enterprises@outlook.com> - 2017-10-11 00:36 -0700
Re: Delete Key Handler for BASIC.SYSTEM Brian Patrie <bpatrie@bellsouth.spamisicky.net> - 2017-10-12 00:53 -0500
Re: Delete Key Handler for BASIC.SYSTEM James Davis <JPD.Enterprises@outlook.com> - 2017-10-12 00:37 -0700
Re: Delete Key Handler for BASIC.SYSTEM mdj <mdj.mdj@gmail.com> - 2017-11-21 19:05 -0800
Re: Delete Key Handler for BASIC.SYSTEM gids.rs@sasktel.net - 2017-10-09 23:46 -0700
Re: Delete Key Handler for BASIC.SYSTEM "Mark D. Overholser" <marko@markoverholser.com> - 2017-10-10 09:59 -0700
Re: Delete Key Handler for BASIC.SYSTEM gids.rs@sasktel.net - 2017-10-10 21:02 -0700
Re: Delete Key Handler for BASIC.SYSTEM Bill Chatfield <billchatfield1@gmail.com> - 2017-10-10 21:21 -0700
Re: Delete Key Handler for BASIC.SYSTEM gids.rs@sasktel.net - 2017-10-11 07:56 -0700
Re: Delete Key Handler for BASIC.SYSTEM gids.rs@sasktel.net - 2017-10-11 08:02 -0700
Re: Delete Key Handler for BASIC.SYSTEM gids.rs@sasktel.net - 2017-10-11 08:15 -0700
Re: Delete Key Handler for BASIC.SYSTEM James Davis <JPD.Enterprises@outlook.com> - 2017-10-11 17:50 -0700
Re: Delete Key Handler for BASIC.SYSTEM gids.rs@sasktel.net - 2017-10-11 20:42 -0700
Re: Delete Key Handler for BASIC.SYSTEM James Davis <JPD.Enterprises@outlook.com> - 2017-10-12 00:09 -0700
Re: Delete Key Handler for BASIC.SYSTEM gids.rs@sasktel.net - 2017-10-12 07:42 -0700
Re: Delete Key Handler for BASIC.SYSTEM James Davis <JPD.Enterprises@outlook.com> - 2017-10-12 22:42 -0700
Re: Delete Key Handler for BASIC.SYSTEM gids.rs@sasktel.net - 2017-10-13 13:14 -0700
Re: Delete Key Handler for BASIC.SYSTEM Bill Chatfield <billchatfield1@gmail.com> - 2017-10-13 22:16 -0700
Re: Delete Key Handler for BASIC.SYSTEM Michael Pohoreski <michael.pohoreski@gmail.com> - 2017-10-14 09:58 -0700
Re: Delete Key Handler for BASIC.SYSTEM Michael J. Mahon <mjmahon@aol.com> - 2017-10-14 17:17 -0500
Re: Delete Key Handler for BASIC.SYSTEM Michael Pohoreski <michael.pohoreski@gmail.com> - 2017-10-14 22:44 -0700
Re: Delete Key Handler for BASIC.SYSTEM Michael J. Mahon <mjmahon@aol.com> - 2017-10-15 02:04 -0500
Re: Delete Key Handler for BASIC.SYSTEM Anthony Ortiz <anthonypaulo@gmail.com> - 2017-10-15 08:22 -0700
Re: Delete Key Handler for BASIC.SYSTEM Michael Pohoreski <michael.pohoreski@gmail.com> - 2017-10-16 09:43 -0700
Re: Delete Key Handler for BASIC.SYSTEM gids.rs@sasktel.net - 2017-10-16 13:19 -0700
Re: Delete Key Handler for BASIC.SYSTEM gids.rs@sasktel.net - 2017-10-12 21:30 -0700
Page 2 of 2 — ← Prev page 1 [2]
| From | James Davis <JPD.Enterprises@outlook.com> |
|---|---|
| Date | 2017-10-12 00:09 -0700 |
| Message-ID | <898c9fac-a738-4690-89a4-c15a87738bd3@googlegroups.com> |
| In reply to | #3955 |
On Wednesday, October 11, 2017 at 8:42:48 PM UTC-7, gid...@sasktel.net wrote: > > Would it not be better to use CSW and KSW rather than COUT and KEYIN? > > > Basic.system has its own input and output intercepts at $BE30.BE33 in its global page from $BE00.BEFF. And unless you know what BS does with CSW and KSW, it is best to let it be in charge of setting them and handling them while it is in control. > > You can find a good description of Basic.systems global page in the "Prodos 8 Technical Reference Manual". OK, that is in your FOR PRODOS routine, but in your DELETE and DEL2 routines you are using KEYIN and COUT. What if the user is using some other I/O devices rather than the standard Apple II keyboard and monitor? They might just have a motherboard hooked up remotely to their I/O devices. That's why there are User Vectors at KSW and CSW, so the user can usurp and not use the standard I/O if necessary. Wouldn't you want to catch the Delete key code for wherever it came in from?
[toc] | [prev] | [next] | [standalone]
| From | gids.rs@sasktel.net |
|---|---|
| Date | 2017-10-12 07:42 -0700 |
| Message-ID | <63c872ac-e502-4d90-a8ce-8494b42d8d1f@googlegroups.com> |
| In reply to | #3958 |
On Thursday, October 12, 2017 at 1:09:23 AM UTC-6, James Davis wrote: > On Wednesday, October 11, 2017 at 8:42:48 PM UTC-7, gid...@sasktel.net wrote: > > > Would it not be better to use CSW and KSW rather than COUT and KEYIN? > > > > > > Basic.system has its own input and output intercepts at $BE30.BE33 in its global page from $BE00.BEFF. And unless you know what BS does with CSW and KSW, it is best to let it be in charge of setting them and handling them while it is in control. > > > > You can find a good description of Basic.systems global page in the "Prodos 8 Technical Reference Manual". > > OK, that is in your FOR PRODOS routine, but in your DELETE and DEL2 routines you are using KEYIN and COUT. What if the user is using some other I/O devices rather than the standard Apple II keyboard and monitor? They might just have a motherboard hooked up remotely to their I/O devices. That's why there are User Vectors at KSW and CSW, so the user can usurp and not use the standard I/O if necessary. Wouldn't you want to catch the Delete key code for wherever it came in from? You are doing what I call "Fetching". You are looking for complicated scenarios and trying to understand how this program would work in the event you encounter those scenarios. It is best when programming the Apple to use the KISS (Keep It Simple Stupid) method. Then when "That Scenario" arises you can see how to either program for it or around it. The direct answer, though, would be "no", you wouldn't want to catch the Delete key from wherever it came from. This routine is meant to be a part of the keyboard driver for this computer. If you have other input or output devices then you will have drivers for those devices and they will not encounter this routine unless you put it into its driver.
[toc] | [prev] | [next] | [standalone]
| From | James Davis <JPD.Enterprises@outlook.com> |
|---|---|
| Date | 2017-10-12 22:42 -0700 |
| Message-ID | <ee3dbb16-4f6d-4fc9-a079-7713a199e98b@googlegroups.com> |
| In reply to | #3960 |
On Thursday, October 12, 2017 at 7:42:53 AM UTC-7, gid...@sasktel.net wrote: > On Thursday, October 12, 2017 at 1:09:23 AM UTC-6, James Davis wrote: > > On Wednesday, October 11, 2017 at 8:42:48 PM UTC-7, gid...@sasktel.net wrote: > > > > Would it not be better to use CSW and KSW rather than COUT and KEYIN? > > > > > > > > > Basic.system has its own input and output intercepts at $BE30.BE33 in its global page from $BE00.BEFF. And unless you know what BS does with CSW and KSW, it is best to let it be in charge of setting them and handling them while it is in control. > > > > > > You can find a good description of Basic.systems global page in the "Prodos 8 Technical Reference Manual". > > > > OK, that is in your FOR PRODOS routine, but in your DELETE and DEL2 routines you are using KEYIN and COUT. What if the user is using some other I/O devices rather than the standard Apple II keyboard and monitor? They might just have a motherboard hooked up remotely to their I/O devices. That's why there are User Vectors at KSW and CSW, so the user can usurp and not use the standard I/O if necessary. Wouldn't you want to catch the Delete key code for wherever it came in from? > > > You are doing what I call "Fetching". You are looking for complicated scenarios and trying to understand how this program would work in the event you encounter those scenarios. It is best when programming the Apple to use the KISS (Keep It Simple Stupid) method. Then when "That Scenario" arises you can see how to either program for it or around it. > > The direct answer, though, would be "no", you wouldn't want to catch the Delete key from wherever it came from. This routine is meant to be a part of the keyboard driver for this computer. If you have other input or output devices then you will have drivers for those devices and they will not encounter this routine unless you put it into its driver. Yes, that's why I'll never program again. I'm always reading too much into it. I forgot that this is just for ProDOS BASIC.SYSTEM.
[toc] | [prev] | [next] | [standalone]
| From | gids.rs@sasktel.net |
|---|---|
| Date | 2017-10-13 13:14 -0700 |
| Message-ID | <d4fe7636-02ca-4a7a-ac60-c2bacfbca25c@googlegroups.com> |
| In reply to | #3962 |
On Thursday, October 12, 2017 at 11:42:03 PM UTC-6, James Davis wrote: > On Thursday, October 12, 2017 at 7:42:53 AM UTC-7, gid...@sasktel.net wrote: > > On Thursday, October 12, 2017 at 1:09:23 AM UTC-6, James Davis wrote: > > > On Wednesday, October 11, 2017 at 8:42:48 PM UTC-7, gid...@sasktel.net wrote: > > > > > Would it not be better to use CSW and KSW rather than COUT and KEYIN? > > > > > > > > > > > > Basic.system has its own input and output intercepts at $BE30.BE33 in its global page from $BE00.BEFF. And unless you know what BS does with CSW and KSW, it is best to let it be in charge of setting them and handling them while it is in control. > > > > > > > > You can find a good description of Basic.systems global page in the "Prodos 8 Technical Reference Manual". > > > > > > OK, that is in your FOR PRODOS routine, but in your DELETE and DEL2 routines you are using KEYIN and COUT. What if the user is using some other I/O devices rather than the standard Apple II keyboard and monitor? They might just have a motherboard hooked up remotely to their I/O devices. That's why there are User Vectors at KSW and CSW, so the user can usurp and not use the standard I/O if necessary. Wouldn't you want to catch the Delete key code for wherever it came in from? > > > > > > You are doing what I call "Fetching". You are looking for complicated scenarios and trying to understand how this program would work in the event you encounter those scenarios. It is best when programming the Apple to use the KISS (Keep It Simple Stupid) method. Then when "That Scenario" arises you can see how to either program for it or around it. > > > > The direct answer, though, would be "no", you wouldn't want to catch the Delete key from wherever it came from. This routine is meant to be a part of the keyboard driver for this computer. If you have other input or output devices then you will have drivers for those devices and they will not encounter this routine unless you put it into its driver. > > Yes, that's why I'll never program again. I'm always reading too much into it. I forgot that this is just for ProDOS BASIC.SYSTEM. I thought the same way when I first started programming and I was doing it the hard way using the monitor instead of a source assembler. I was trying to imagine every scenario and tried to write program for every scenario. For a little while I grew to hate programming and left it for a few years. I got back into it when I came across the Ninja Force Assembler, and with Sweet16, the two became a dream team. I could copy and paste monitor listings of programs I managed to create into TextEdit on the Mac, edit the text then, copy and paste the source back into NFAssembler. Now I had the tools and routines to do a whole new way of programming, and now I have a library of routines that I can copy and paste into any source and pretty much create any program I want. The nice thing about NFAssembler is that is wasn't a huge learning curve. The source listings are basically the same as monitor listings but without the addresses or bytes. Just the mnemonics and labels. So, never say "Never". You just need to find your momentum.
[toc] | [prev] | [next] | [standalone]
| From | Bill Chatfield <billchatfield1@gmail.com> |
|---|---|
| Date | 2017-10-13 22:16 -0700 |
| Message-ID | <bcf832c9-9f27-4309-8d13-3909992b43a1@googlegroups.com> |
| In reply to | #3962 |
On Friday, October 13, 2017 at 1:42:03 AM UTC-4, James Davis wrote: > On Thursday, October 12, 2017 at 7:42:53 AM UTC-7, gid...@sasktel.net wrote: > > On Thursday, October 12, 2017 at 1:09:23 AM UTC-6, James Davis wrote: > > > On Wednesday, October 11, 2017 at 8:42:48 PM UTC-7, gid...@sasktel.net wrote: > > > > > Would it not be better to use CSW and KSW rather than COUT and KEYIN? > > > > > > > > > > > > Basic.system has its own input and output intercepts at $BE30.BE33 in its global page from $BE00.BEFF. And unless you know what BS does with CSW and KSW, it is best to let it be in charge of setting them and handling them while it is in control. > > > > > > > > You can find a good description of Basic.systems global page in the "Prodos 8 Technical Reference Manual". > > > > > > OK, that is in your FOR PRODOS routine, but in your DELETE and DEL2 routines you are using KEYIN and COUT. What if the user is using some other I/O devices rather than the standard Apple II keyboard and monitor? They might just have a motherboard hooked up remotely to their I/O devices. That's why there are User Vectors at KSW and CSW, so the user can usurp and not use the standard I/O if necessary. Wouldn't you want to catch the Delete key code for wherever it came in from? > > > > > > You are doing what I call "Fetching". You are looking for complicated scenarios and trying to understand how this program would work in the event you encounter those scenarios. It is best when programming the Apple to use the KISS (Keep It Simple Stupid) method. Then when "That Scenario" arises you can see how to either program for it or around it. > > > > The direct answer, though, would be "no", you wouldn't want to catch the Delete key from wherever it came from. This routine is meant to be a part of the keyboard driver for this computer. If you have other input or output devices then you will have drivers for those devices and they will not encounter this routine unless you put it into its driver. > > Yes, that's why I'll never program again. I'm always reading too much into it. I forgot that this is just for ProDOS BASIC.SYSTEM. I try to stick to making it work with a finite set of use cases and K.I.S.S. I strive for perfection but also realize that it's OK to fall short because perfection is really unattainable. Having something that is functional is better than trying for perfection and never getting to the point that it just works for one use case. Make one thing work and then add the next. Don't try to solve every possibility at the same time.
[toc] | [prev] | [next] | [standalone]
| From | Michael Pohoreski <michael.pohoreski@gmail.com> |
|---|---|
| Date | 2017-10-14 09:58 -0700 |
| Message-ID | <f5c4110c-220a-49cc-b9ef-dde18401cac2@googlegroups.com> |
| In reply to | #3967 |
Exactly this. Solve _today's_ problem, NOT some hypothetical tomorrow's problem. You can see this with DOS 3.3's shitty File System design. That isn't to say you don't plan ahead -- but until you _implement_ it you won't _fully_ grok the problem. An "bad" implementation trumps a "perfect" theory every time. As Fred Brooks said over 50 years ago "Plan to throw one away, you will anyways."
[toc] | [prev] | [next] | [standalone]
| From | Michael J. Mahon <mjmahon@aol.com> |
|---|---|
| Date | 2017-10-14 17:17 -0500 |
| Message-ID | <hJ-dnTQ4tp1iEX_EnZ2dnUU7-L9QAAAA@giganews.com> |
| In reply to | #3968 |
Michael Pohoreski <michael.pohoreski@gmail.com> wrote: > Exactly this. > > Solve _today's_ problem, NOT some hypothetical tomorrow's problem. You > can see this with DOS 3.3's shitty File System design. > > That isn't to say you don't plan ahead -- but until you _implement_ it > you won't _fully_ grok the problem. An "bad" implementation trumps a > "perfect" theory every time. As Fred Brooks said over 50 years ago "Plan > to throw one away, you will anyways." > I'm in complete agreement. "Libraries" are a common example of code so over-generalized that one can easily do a much more efficient implementation oneself. "The perfect is the enemy of the good." -- -michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
[toc] | [prev] | [next] | [standalone]
| From | Michael Pohoreski <michael.pohoreski@gmail.com> |
|---|---|
| Date | 2017-10-14 22:44 -0700 |
| Message-ID | <1657c6da-a4aa-4b7c-ac71-4f9ba5f4a813@googlegroups.com> |
| In reply to | #3969 |
Indeed. At work I'm constantly seeing people pull in every library under the sun because they need 1 function here and there -- they end up with "dependency hell", a bloated executable and they wonder why it takes so long to load their app and/or build. For one project we just got rid of jQuery. The few functions we were _actually_ using I rewrote them as native JavaScript because it was trivial to implement. Our app is smaller, faster to load, we don't have to worry about a new version of the lib breaking, etc.
[toc] | [prev] | [next] | [standalone]
| From | Michael J. Mahon <mjmahon@aol.com> |
|---|---|
| Date | 2017-10-15 02:04 -0500 |
| Message-ID | <MISdnSNTJa3olX7EnZ2dnUU7-YfNnZ2d@giganews.com> |
| In reply to | #3970 |
Michael Pohoreski <michael.pohoreski@gmail.com> wrote: > Indeed. At work I'm constantly seeing people pull in every library under > the sun because they need 1 function here and there -- they end up with > "dependency hell", a bloated executable and they wonder why it takes so > long to load their app and/or build. > > For one project we just got rid of jQuery. The few functions we were > _actually_ using I rewrote them as native JavaScript because it was > trivial to implement. Our app is smaller, faster to load, we don't have > to worry about a new version of the lib breaking, etc. ...the dark side of "code reuse". -- -michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
[toc] | [prev] | [next] | [standalone]
| From | Anthony Ortiz <anthonypaulo@gmail.com> |
|---|---|
| Date | 2017-10-15 08:22 -0700 |
| Message-ID | <0bbb9d31-2ecf-4796-8767-f86454043978@googlegroups.com> |
| In reply to | #3970 |
On Sunday, October 15, 2017 at 1:44:34 AM UTC-4, Michael Pohoreski wrote: > Indeed. At work I'm constantly seeing people pull in every library under the sun because they need 1 function here and there -- they end up with "dependency hell", a bloated executable and they wonder why it takes so long to load their app and/or build. > > For one project we just got rid of jQuery. The few functions we were _actually_ using I rewrote them as native JavaScript because it was trivial to implement. Our app is smaller, faster to load, we don't have to worry about a new version of the lib breaking, etc. Not to mention the dependencies that the dependencies themselves have. You think you're using one library when in fact it could be dozens. Modern web development epitomizes this.
[toc] | [prev] | [next] | [standalone]
| From | Michael Pohoreski <michael.pohoreski@gmail.com> |
|---|---|
| Date | 2017-10-16 09:43 -0700 |
| Message-ID | <fd82ffa0-cb20-444a-8825-e907189dfd7e@googlegroups.com> |
| In reply to | #3972 |
On Sunday, October 15, 2017 at 8:22:39 AM UTC-7, Anthony Ortiz wrote: > Not to mention the dependencies that the dependencies themselves have. Yup, AKA "dependency hell" :-/ -- Weinberg's Second Law: If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization. -- collated via Murphy's Computer Laws
[toc] | [prev] | [next] | [standalone]
| From | gids.rs@sasktel.net |
|---|---|
| Date | 2017-10-16 13:19 -0700 |
| Message-ID | <277345ab-db0d-41af-847c-6af1c921bf33@googlegroups.com> |
| In reply to | #3973 |
On Monday, October 16, 2017 at 10:43:52 AM UTC-6, Michael Pohoreski wrote: > On Sunday, October 15, 2017 at 8:22:39 AM UTC-7, Anthony Ortiz wrote: > > Not to mention the dependencies that the dependencies themselves have. > > Yup, AKA "dependency hell" :-/ > > -- > Weinberg's Second Law: If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization. -- collated via Murphy's Computer Laws Rob's Third Law: A computer is only as smart as the programmer that programmed it. And, Too many programmers (libraries) spoil the intended result.
[toc] | [prev] | [next] | [standalone]
| From | gids.rs@sasktel.net |
|---|---|
| Date | 2017-10-12 21:30 -0700 |
| Message-ID | <ce4c924a-776f-4b27-b3ba-9c9a86f11fe5@googlegroups.com> |
| In reply to | #3958 |
On Thursday, October 12, 2017 at 1:09:23 AM UTC-6, James Davis wrote: > On Wednesday, October 11, 2017 at 8:42:48 PM UTC-7, gid...@sasktel.net wrote: > > > Would it not be better to use CSW and KSW rather than COUT and KEYIN? > > > > > > Basic.system has its own input and output intercepts at $BE30.BE33 in its global page from $BE00.BEFF. And unless you know what BS does with CSW and KSW, it is best to let it be in charge of setting them and handling them while it is in control. > > > > You can find a good description of Basic.systems global page in the "Prodos 8 Technical Reference Manual". > > OK, that is in your FOR PRODOS routine, but in your DELETE and DEL2 routines you are using KEYIN and COUT. What if the user is using some other I/O devices rather than the standard Apple II keyboard and monitor? They might just have a motherboard hooked up remotely to their I/O devices. That's why there are User Vectors at KSW and CSW, so the user can usurp and not use the standard I/O if necessary. Wouldn't you want to catch the Delete key code for wherever it came in from? Another reason this won't work is that the byte $FF is recognized as the delete key when the keyboard latch at $C000 is read. But the byte $FF can have a totally different meaning when coming from another input device. The device driver then would handle the byte $FF accordingly.
[toc] | [prev] | [standalone]
Page 2 of 2 — ← Prev page 1 [2]
Back to top | Article view | comp.sys.apple2.programmer
csiph-web