| A2SimpleIO? [message #276931] |
Sun, 28 December 2014 07:12  |
Harry Potter
Messages: 1304
Registered: March 2012
Karma: 0
|
Senior Member |
|
|
|
I created a cc65 library for some CBM computers called CBMSimpleIO. It is a quick replacement for puts() and printf(). Basically, it works by directly using the kernal to display data and read user input. Its test binaries are all <1k long. Now, I want to port it to the Apple 2. I need some basic information on using the Apple 2's kernal. Where can I find this?
|
|
|
|
| Re: A2SimpleIO? [message #276955 is a reply to message #276931] |
Sun, 28 December 2014 08:49  |
Bill Buckels
Messages: 1418
Registered: November 2012
Karma: 0
|
Senior Member |
|
|
"Harry Potter" <rose.joseph12@yahoo.com> wrote:
> I created a cc65 library for some CBM computers called CBMSimpleIO. It is
> a quick replacement for puts() and printf(). Basically, it works by
> directly using the kernal to display data and read user input. Its test
> binaries are all <1k long. Now, I want to port it to the Apple 2. I need
> some basic information on using the Apple 2's kernal. Where can I find
> this?
There's really no point. cc65's puts() and printf() don't need a
replacement. The tgi in cc65 works quite well for text-based programs too.
As far as a kernal goes, have a look at the ProDOS MLI. That is the closest
equivalent to the MS-DOS kernal. What you don't find there is in the Apple
II ROM.
Backreading csa2 and using google are both good places to start.
It is very unlikely that anyone here that uses cc65 will use anything that
you write. Most of us are experts and perfectly capable of writing our own
(better) code.
Bill
|
|
|
|
|
|
| Re: A2SimpleIO? [message #277004 is a reply to message #276955] |
Sun, 28 December 2014 11:20 |
Harry Potter
Messages: 1304
Registered: March 2012
Karma: 0
|
Senior Member |
|
|
On Sunday, December 28, 2014 8:49:28 AM UTC-5, Bill Buckels wrote:
> There's really no point. cc65's puts() and printf() don't need a
> replacement. The tgi in cc65 works quite well for text-based programs too.
>
puts() and prints() *are* good, but at the same time, by using the CBM ROMs directly, I can cut the size of small programs by up to 4k than by using the standard and console I/O libraries.
> As far as a kernal goes, have a look at the ProDOS MLI. That is the closest
> equivalent to the MS-DOS kernal. What you don't find there is in the Apple
> II ROM.
>
The ProDOS MLI works on *disks*, not *screen/keyboard.*
> Backreading csa2 and using google are both good places to start.
>
> It is very unlikely that anyone here that uses cc65 will use anything that
> you write. Most of us are experts and perfectly capable of writing our own
> (better) code.
>
> Bill
Oh. :(
|
|
|
|
| Re: A2SimpleIO? [message #277013 is a reply to message #276955] |
Sun, 28 December 2014 11:48 |
Harry Potter
Messages: 1304
Registered: March 2012
Karma: 0
|
Senior Member |
|
|
On Sunday, December 28, 2014 8:49:28 AM UTC-5, Bill Buckels wrote:
> It is very unlikely that anyone here that uses cc65 will use anything that
> you write. Most of us are experts and perfectly capable of writing our own
> (better) code.
>
> Bill
Would anybody have use of a simplified I/O library? CBMSimpleIO works by replacing the heavy screen/keyboard I/O of cc65 with simplified versions that address the CBM kernals directly, saving up to 4k of potentially unnecessary processing.
|
|
|
|
| Re: A2SimpleIO? [message #277099 is a reply to message #277004] |
Sun, 28 December 2014 14:30 |
Bill Buckels
Messages: 1418
Registered: November 2012
Karma: 0
|
Senior Member |
|
|
"Harry Potter" <rose.joseph12@yahoo.com> wrote:
> puts() and prints() *are* good, but at the same time, by using the CBM ROMs
> directly, I can cut the size of small programs by up to 4k than by using
> the standard and console I/O libraries.
We are talking about the Apple II and not some other computer.
The Apple II cc65 routines already call the ROM routines... further, printf
is for formatted output just like sprintf, so additional overhead is
incurred. puts is simpler. both also have file variants. Any non-trivial
program in cc65 will probably call one or both printf and puts or write or
whatever anyway, so by adding additional code for your own routines you will
make programs larger and not smaller. Cutting program size on a demo program
is meaningless if a real program is bigger.
You might want to read the cc65 Apple II library code before speculating
further about what you say you want to do or how this can benefit an Apple
II cc65 program.
You should start by looking at how cc65 uses memory on the Apple II.
Then learn the MLI a little.
You'll need it.
Bill
|
|
|
|
| Re: A2SimpleIO? [message #277112 is a reply to message #277099] |
Sun, 28 December 2014 15:18 |
Harry Potter
Messages: 1304
Registered: March 2012
Karma: 0
|
Senior Member |
|
|
On Sunday, December 28, 2014 2:30:48 PM UTC-5, Bill Buckels wrote:
> We are talking about the Apple II and not some other computer.
>
I already know that. I'm only making a comparison to tell you what I want to do.
> The Apple II cc65 routines already call the ROM routines... further, printf
> is for formatted output just like sprintf, so additional overhead is
> incurred. puts is simpler. both also have file variants. Any non-trivial
> program in cc65 will probably call one or both printf and puts or write or
> whatever anyway, so by adding additional code for your own routines you will
> make programs larger and not smaller. Cutting program size on a demo program
> is meaningless if a real program is bigger.
>
printf() uses extra work to handle formatting such as the inclusion of strings and numbers, and puts() does extra work to handle file I/O as necessary.. In CBMSimpleIO, as I plan to do for the Apple2, for example, a dedicated prints() function just writes a string directly through the kernal. printu() would convert an integer to ASCII and write it through prints(). On the CBM, these helped me to optimize more than just a test program. It also helped with DirMenu (a CBM menu/loader program) and MadLib64/128.
> You might want to read the cc65 Apple II library code before speculating
> further about what you say you want to do or how this can benefit an Apple
> II cc65 program.
>
Okay.
> You should start by looking at how cc65 uses memory on the Apple II.
>
> Then learn the MLI a little.
>
> You'll need it.
>
> Bill
You're right.
|
|
|
|
| Re: A2SimpleIO? [message #277142 is a reply to message #277112] |
Sun, 28 December 2014 16:45 |
Harry Potter
Messages: 1304
Registered: March 2012
Karma: 0
|
Senior Member |
|
|
On Sunday, December 28, 2014 3:18:28 PM UTC-5, Harry Potter wrote:
I need a map of the Apple2/2e ROMs. Where can I get it?
|
|
|
|
|
|
|
|
| Re: A2SimpleIO? [message #277287 is a reply to message #277013] |
Sun, 28 December 2014 21:55 |
Bill Buckels
Messages: 1418
Registered: November 2012
Karma: 0
|
Senior Member |
|
|
"Harry Potter" <rose.joseph12@yahoo.com> wrote:
> Would anybody have use of a simplified I/O library?
Probably not. It's easy enough to put a character on the Apple II screen or
to read the keyboard buffer. Have a look at the Peeks, Pokes, and Pointers:
http://beagle.applearchives.com/the_posters/poster_3.html
> CBMSimpleIO works by replacing the heavy screen/keyboard I/O of cc65 with
> simplified versions that address the CBM kernals directly, saving up to 4k
> of potentially unnecessary processing.
CBSimpleIO is for the Commodore 64. I notice that you posted an announcement
for CBMSimpleIO in comp.sys.cbm on Dec 5, 2014 and nobody replied. Spend
your time here by learning about the Apple II instead of asking C
programmers if they need some help. We don't. We've already got enough of
our own ideas to keep ourselves busy, and you have enough links from me to
keep yourself busy.
Bill
|
|
|
|
| Re: A2SimpleIO? [message #277357 is a reply to message #276955] |
Mon, 29 December 2014 02:02 |
mdj
Messages: 301
Registered: December 2012
Karma: 0
|
Senior Member |
|
|
On Sunday, 28 December 2014 23:49:28 UTC+10, Bill Buckels wrote:
> There's really no point. cc65's puts() and printf() don't need a
> replacement. The tgi in cc65 works quite well for text-based programs too..
I dunno, he seems to have figured out that using full C libraries on a 6502 results in bloatware ;-) That said, these 'simple' programs that need 'simple' IO will probably leave enough RAM around that the bloat is irrelevant.
In any case, these threads would be shorter if people actually answered the question.
Character IO on the Apple II (Assuming you've decided not to replace it with something more efficient) is handled principally via 2 routines in the BIOS (or monitor, or even monitor ROM as it's most often called in Apple II speak).
Character OUTPUT is handled by a routine at $FDED called COUT. However all COUT does is jump to the routine pointed to by the vector at zero page locations 36 and 37. This vector is called CSW. On an Apple II with no OS loaded, this vector will contain $FDF0, which is the address of routine COUT1, which will 'print' the value currently in the accumulator to the standard 40 column text screen.
Note that the vector at $36 will contain different things if you have:
1) Loaded DOS or ProDOS
2) Enabled 80 column mode
3) Both
This is how operating systems patch into the IO path to provide disk support to BASIC. You could theoretically write an efficient puts() in assembly language for cc65 that used the COUT entry point at FDF0.
As for INPUT, I leave this up to you to figure out. All of this and more is very succinctly documented (amongst other places) in the book "Apple II Monitors Peeled", but the Apple II reference manual would contain more than enough detail for the purposes you outlined.
Matt
|
|
|
|
| Re: A2SimpleIO? [message #277395 is a reply to message #277357] |
Mon, 29 December 2014 07:01 |
Harry Potter
Messages: 1304
Registered: March 2012
Karma: 0
|
Senior Member |
|
|
On Monday, December 29, 2014 2:02:01 AM UTC-5, mdj wrote:
> I dunno, he seems to have figured out that using full C libraries on a 6502 results in bloatware ;-) That said, these 'simple' programs that need 'simple' IO will probably leave enough RAM around that the bloat is irrelevant.
>
> In any case, these threads would be shorter if people actually answered the question.
>
Support! Thank you! :D
> Character IO on the Apple II (Assuming you've decided not to replace it with something more efficient) is handled principally via 2 routines in the BIOS (or monitor, or even monitor ROM as it's most often called in Apple II speak).
>
> Character OUTPUT is handled by a routine at $FDED called COUT. However all COUT does is jump to the routine pointed to by the vector at zero page locations 36 and 37. This vector is called CSW. On an Apple II with no OS loaded, this vector will contain $FDF0, which is the address of routine COUT1, which will 'print' the value currently in the accumulator to the standard 40 column text screen.
>
So the following would print a character on the screen:
_printc:
JMP ($36)
Thank you!
> As for INPUT, I leave this up to you to figure out. All of this and more is very succinctly documented (amongst other places) in the book "Apple II Monitors Peeled", but the Apple II reference manual would contain more than enough detail for the purposes you outlined.
>
> Matt
Okay.
|
|
|
|
|
|
| Re: A2SimpleIO? [message #277417 is a reply to message #277395] |
Mon, 29 December 2014 09:43 |
mdj
Messages: 301
Registered: December 2012
Karma: 0
|
Senior Member |
|
|
On Monday, 29 December 2014 22:02:55 UTC+10, Harry Potter wrote:
> Support! Thank you! :D
There's an old saying that says you only truly understand something when you can teach it to others. This seems to reflect the way you learn, and whilst its incredibly inefficient one can't help but respect your tenacity if nothing else.
But seriously, kid, you need to learn how to *read* reference material.
> So the following would print a character on the screen:
>
> _printc:
> JMP ($36)
>
> Thank you!
Yes, but it will crash shortly thereafter as the routine you just JMP'd to will do an RTS you didn't have a JSR for.
So you'd need:
_printc:
JSR $FDED
|
|
|
|
| Re: A2SimpleIO? [message #277427 is a reply to message #277407] |
Mon, 29 December 2014 09:56 |
mdj
Messages: 301
Registered: December 2012
Karma: 0
|
Senior Member |
|
|
On Tuesday, 30 December 2014 00:37:38 UTC+10, Bill Buckels wrote:
> You can bet that this is the last time I post any links in here other than
> my own. That is a promise.
I didn't mean to get under your skin, Bill, just offering a different perspective.
> You and Mutt can have the ng to yourselves.
:-S I thought you were done looking for fights
|
|
|
|
|
|
| Re: A2SimpleIO? [message #277614 is a reply to message #277013] |
Mon, 29 December 2014 18:41 |
Michael AppleWin Debu
Messages: 1262
Registered: March 2013
Karma: 0
|
Senior Member |
|
|
On Sunday, December 28, 2014 8:48:29 AM UTC-8, Harry Potter wrote:
> Would anybody have use of a simplified I/O library? CBMSimpleIO works by replacing the heavy screen/keyboard I/O of cc65 with simplified versions that address the CBM kernals directly, saving up to 4k of potentially unnecessary processing.
No;
1. I'll probably directly poke text into $400 .. $7FF for 40-column text
2. If I need Pro/DOS or 80-col support, I'll just JSR COUT, or call DOS directly.
3. We usually don't waste memory using an ASCIIZ string that wastes an extra byte of NULL for string terminator; The Apple idiom is to set the high bit on the last character so it is negative. i.e. See the AppleSoft ROM disassembly
http://www.txbobsc.com/scsc/scdocumentor/D000.html
As Bill said, most of us here don't need yet-another-bloated-unproven-3rd party library. I'm willing to bet we've been writing Apple programs before you were born. You library just wastes memory for us while providing nothing of benefit that:
a) we can't write ourselves
b) isn't already provided
I love C more then the next guy but I also recognize programming anything other then to the metal with the Apple is just bloatware.
|
|
|
|
| Re: A2SimpleIO? [message #277616 is a reply to message #277614] |
Mon, 29 December 2014 19:13 |
Steve Nickolas
Messages: 2036
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Mon, 29 Dec 2014, Michael 'AppleWin Debugger Dev' wrote:
> 3. We usually don't waste memory using an ASCIIZ string that wastes an
> extra byte of NULL for string terminator; The Apple idiom is to set the
> high bit on the last character so it is negative. i.e. See the AppleSoft
> ROM disassembly
I must be the exception... All my code uses ASCIIZ.
-uso.
|
|
|
|
| Re: A2SimpleIO? [message #277619 is a reply to message #277614] |
Mon, 29 December 2014 19:24 |
Harry Potter
Messages: 1304
Registered: March 2012
Karma: 0
|
Senior Member |
|
|
On Monday, December 29, 2014 6:41:34 PM UTC-5, Michael 'AppleWin Debugger Dev' wrote:
> No;
>
> 1. I'll probably directly poke text into $400 .. $7FF for 40-column text
>
Good idea.
> 2. If I need Pro/DOS or 80-col support, I'll just JSR COUT, or call DOS directly.
>
My prints() routine would look like this:
--------------------------
_prints:
sta ptr1
stx ptr1+1
ldy #0
@lp:
lda (ptr1),y
beq @exit
jsr cout
iny
bne @lp
@exit:
rts
------------------------
Is this bloat-ware? :/
> 3. We usually don't waste memory using an ASCIIZ string that wastes an extra byte of NULL for string terminator; The Apple idiom is to set the high bit on the last character so it is negative. i.e. See the AppleSoft ROM disassembly
>
> http://www.txbobsc.com/scsc/scdocumentor/D000.html
>
Your method cuts down the number of character possibilities to 128 but is sufficient for normal ASCII strings. C uses ASCIIZ, though, and this WIP is to interface with C.
> As Bill said, most of us here don't need yet-another-bloated-unproven-3rd party library. I'm willing to bet we've been writing Apple programs before you were born. You library just wastes memory for us while providing nothing of benefit that:
>
> a) we can't write ourselves
> b) isn't already provided
>
Was the same already written for cc65? If so, I'd like to see it.
> I love C more then the next guy but I also recognize programming anything other then to the metal with the Apple is just bloatware.
Again, is my example really bloat-ware?
|
|
|
|
| Re: A2SimpleIO? [message #277622 is a reply to message #277619] |
Mon, 29 December 2014 19:34 |
wsxyz
Messages: 157
Registered: February 2013
Karma: 0
|
Senior Member |
|
|
Am Montag, 29. Dezember 2014 19:24:10 UTC-5 schrieb Harry Potter:
> On Monday, December 29, 2014 6:41:34 PM UTC-5, Michael 'AppleWin Debugger Dev' wrote:
>> 2. If I need Pro/DOS or 80-col support, I'll just JSR COUT, or call DOS directly.
>>
> My prints() routine would look like this:
> --------------------------
> _prints:
> sta ptr1
> stx ptr1+1
> ldy #0
> @lp:
> lda (ptr1),y
> beq @exit
> jsr cout
> iny
> bne @lp
> @exit:
> rts
> ------------------------
> Is this bloat-ware? :/
It's fine, except that it can't handle long strings. It's also trivial and no one really needs you to provide a library for this sort of thing. If
you don't intend for your code to run in ROM, you might want to consider
using an self-modified absolute,indexed instruction to access the
characters. That way to don't need zero page and you can increment the high
byte to support strings longer than 255 bytes.
> Your method cuts down the number of character possibilities to 128 but is sufficient for normal ASCII strings.
The Apple II doesn't really have much in the way of extended ASCII.
> Was the same already written for cc65? If so, I'd like to see it.
cc65 has a puts(), if that's what you are asking.
|
|
|
|
| Re: A2SimpleIO? [message #277623 is a reply to message #277619] |
Mon, 29 December 2014 19:39 |
wsxyz
Messages: 157
Registered: February 2013
Karma: 0
|
Senior Member |
|
|
Am Montag, 29. Dezember 2014 19:24:10 UTC-5 schrieb Harry Potter:
My recommendation for you, Harry Potter, is to write finished software instead of libraries. Yeah sure, write the libraries for your own usage, but instead of trying to make a product of your libraries, use them to write finished software.
Use the newsgroup to get help if you need it, and come back in six months with a new Apple II game or utility and you will find a lot more appreciation for your efforts.
|
|
|
|
| Re: A2SimpleIO? [message #277629 is a reply to message #277616] |
Mon, 29 December 2014 20:01 |
Michael AppleWin Debu
Messages: 1262
Registered: March 2013
Karma: 0
|
Senior Member |
|
|
On Monday, December 29, 2014 4:12:25 PM UTC-8, Steve Nickolas wrote:
> I must be the exception... All my code uses ASCIIZ.
You have one of those new fangled Apples rumored to have 128K don't ya? :-)
*grin*
|
|
|
|
|
|
| Re: A2SimpleIO? [message #277631 is a reply to message #277623] |
Mon, 29 December 2014 20:07 |
mdj
Messages: 301
Registered: December 2012
Karma: 0
|
Senior Member |
|
|
On Tuesday, 30 December 2014 10:39:14 UTC+10, wss...@gmail.com wrote:
> Am Montag, 29. Dezember 2014 19:24:10 UTC-5 schrieb Harry Potter:
>
> My recommendation for you, Harry Potter, is to write finished software instead of libraries. Yeah sure, write the libraries for your own usage, but instead of trying to make a product of your libraries, use them to write finished software.
Good advice. Good libraries are born of a need; indeed a direct need that materialised as a result of building something else. Such libraries tend to be quite lean and contain mostly routines you will use.
Contrast this with the plethora of design-by-committee or design-by-perceived-need APIs/libraries floating around the place. Littered with routines people *think* you will need.
The software I work on presently carries something in the order of 70% of its code footprint as dependencies on dependencies on libraries that were used in small part to achieve one small thing. In this era, this adds up to tens of gigabytes of memory - required at runtime to start, then inevitably swapped out.
Not that anybody cares ;-)
|
|
|
|
| Re: A2SimpleIO? [message #277632 is a reply to message #277629] |
Mon, 29 December 2014 20:23 |
Steve Nickolas
Messages: 2036
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Mon, 29 Dec 2014, Michael 'AppleWin Debugger Dev' wrote:
> On Monday, December 29, 2014 4:12:25 PM UTC-8, Steve Nickolas wrote:
>> I must be the exception... All my code uses ASCIIZ.
>
> You have one of those new fangled Apples rumored to have 128K don't ya? :-)
>
> *grin*
>
Well, yes, but I prefer to code for a 64K machine (48, if not using
ProDOS).
-uso.
|
|
|
|
| Re: A2SimpleIO? [message #277634 is a reply to message #277622] |
Mon, 29 December 2014 20:25 |
mdj
Messages: 301
Registered: December 2012
Karma: 0
|
Senior Member |
|
|
On Tuesday, 30 December 2014 10:34:16 UTC+10, wss...@gmail.com wrote:
> cc65 has a puts(), if that's what you are asking.
cc65's puts(), like it's other standard C routines calls the internal function
cputc(), which you can see defined for the Apple at:
https://github.com/cc65/cc65/blob/master/libsrc/apple2/cputc .s
It's pretty inefficient compared with just calling COUT, and since it ostensibly implements "COUT1" directly for IIe+ hardware it precludes the use of third-party 80 column adapters.
Matt
|
|
|
|
| Re: A2SimpleIO? [message #277636 is a reply to message #277631] |
Mon, 29 December 2014 20:31 |
Michael AppleWin Debu
Messages: 1262
Registered: March 2013
Karma: 0
|
Senior Member |
|
|
On Monday, December 29, 2014 5:07:50 PM UTC-8, mdj wrote:
> The software I work on presently carries something in the order of 70% of its code footprint as dependencies on dependencies on libraries that were used in small part to achieve one small thing. In this era, this adds up to tens of gigabytes of memory - required at runtime to start, then inevitably swapped out.
>
> Not that anybody cares ;-)
Management probably doesn't, but other good coders definitely do!
We cringe at the modern status quo of "just throw more hardware at the problem" simply because someone is including 10+ libraries, totally 2+ GB of RAM usage forcing unnecessary paging / thrashing all because they need one function from each of the libraries.
I'm all for fast iteration time, but it seems like (almost) no one gives a damn about small, fast, non-bloated code anymore. :-/
|
|
|
|
| Re: A2SimpleIO? [message #277637 is a reply to message #277636] |
Mon, 29 December 2014 20:54 |
mdj
Messages: 301
Registered: December 2012
Karma: 0
|
Senior Member |
|
|
On Tuesday, 30 December 2014 11:31:08 UTC+10, Michael 'AppleWin Debugger Dev' wrote:
> I'm all for fast iteration time, but it seems like (almost) no one gives a damn about small, fast, non-bloated code anymore. :-/
Well, we can store a bit of memory in the parasitic body capacitance of a single SOI transistor now. RAM gets cheaper and humans get more expensive. The only trend is people caring even less, but that's economics for you :-)
|
|
|
|
| Re: A2SimpleIO? [message #277640 is a reply to message #277616] |
Mon, 29 December 2014 22:15 |
Bill Buckels
Messages: 1418
Registered: November 2012
Karma: 0
|
Senior Member |
|
|
"Steve Nickolas" <usotsuki@buric.co> wrote:
> I must be the exception... All my code uses ASCIIZ.
Most of us have used ACSIIZ since C'ing clearly... you are not alone in
being the exception to this bit of nonsense.
Two trolls who don't know that strings are terminated with a NULL character
comparing shoe sizes don't make much difference.
Bill
|
|
|
|
| Re: A2SimpleIO? [message #277641 is a reply to message #277631] |
Mon, 29 December 2014 22:22 |
Bill Buckels
Messages: 1418
Registered: November 2012
Karma: 0
|
Senior Member |
|
|
"mdj" <mdj.mdj@gmail.com> wrote:
> Not that anybody cares ;-)
I do sort of. It's hard to take advantage of faster computers if the API
sits on an API sitting on an API so a monkey can drag and drop shlock code
into a webapp. Where's the fun in that?
Bill
|
|
|
|
| Re: A2SimpleIO? [message #277642 is a reply to message #277640] |
Mon, 29 December 2014 23:55 |
mdj
Messages: 301
Registered: December 2012
Karma: 0
|
Senior Member |
|
|
On Tuesday, 30 December 2014 13:16:00 UTC+10, Bill Buckels wrote:
> "Steve Nickolas" wrote:
>> I must be the exception... All my code uses ASCIIZ.
>
> Most of us have used ACSIIZ since C'ing clearly... you are not alone in
> being the exception to this bit of nonsense.
For storing ASCII strings, the Dextral Character Inverted method is more efficient in space to store and also the size and speed of the code required to scan it.
I've personally always preferred the Pascal style, with a prepended length value. It's more time efficient for certain operations and most importantly far less error prone. The reserved character approach taken by C strings is if nothing else, a security disaster.
Matt
|
|
|
|
| Re: A2SimpleIO? [message #277643 is a reply to message #277616] |
Tue, 30 December 2014 00:22 |
Michael J. Mahon
Messages: 1767
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
Steve Nickolas <usotsuki@buric.co> wrote:
> On Mon, 29 Dec 2014, Michael 'AppleWin Debugger Dev' wrote:
>
>> 3. We usually don't waste memory using an ASCIIZ string that wastes an >
>> extra byte of NULL for string terminator; The Apple idiom is to set the
>>> high bit on the last character so it is negative. i.e. See the
>>> AppleSoft > ROM disassembly
>
> I must be the exception... All my code uses ASCIIZ.
The vast majority of buffer overrun bugs can be attributed to
null-terminated strings instead of count-controlled strings...
--
-michael - NadaNet 3.1 and AppleCrate II: http://home.comcast.net/~mjmahon
|
|
|
|
| Re: A2SimpleIO? [message #277644 is a reply to message #277642] |
Tue, 30 December 2014 00:33 |
Michael J. Mahon
Messages: 1767
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
mdj <mdj.mdj@gmail.com> wrote:
> On Tuesday, 30 December 2014 13:16:00 UTC+10, Bill Buckels wrote:
>> "Steve Nickolas" wrote:
>>> I must be the exception... All my code uses ASCIIZ.
>>
>> Most of us have used ACSIIZ since C'ing clearly... you are not alone in
>> being the exception to this bit of nonsense.
>
> For storing ASCII strings, the Dextral Character Inverted method is more
> efficient in space to store and also the size and speed of the code required to scan it.
>
> I've personally always preferred the Pascal style, with a prepended
> length value. It's more time efficient for certain operations and most
> importantly far less error prone. The reserved character approach taken
> by C strings is if nothing else, a security disaster.
>
> Matt
Bingo.
We've spent too much of the last decade cleaning up buffer overrun security
bugs.
--
-michael - NadaNet 3.1 and AppleCrate II: http://home.comcast.net/~mjmahon
|
|
|
|
| Re: A2SimpleIO? [message #277645 is a reply to message #277619] |
Tue, 30 December 2014 02:37 |
Michael AppleWin Debu
Messages: 1262
Registered: March 2013
Karma: 0
|
Senior Member |
|
|
On Monday, December 29, 2014 4:24:10 PM UTC-8, Harry Potter wrote:
> Your method cuts down the number of character possibilities to 128 but is sufficient for normal ASCII strings. C uses ASCIIZ, though, and this WIP is to interface with C.
1. Uh, you DO realize ASCII is only 7-bit right?
http://en.wikipedia.org/wiki/ASCII
8-bit ASCII is non-standard, and considered extended ASCII; almost every platform uses their own code page for the upper 128 characters anyways.
2. This is not an issue in normal use. You're getting "hung up" on some theoretical "problem" when it is a non-issue. Making mountains out of mole holes doesn't change that. Show me _one_ Apple ][ //e game or app that actually uses more then 128 characters.
3. I don't know anyone who uses UTF-8 or Unicode 16 on an Apple anyways.
|
|
|
|
| Re: A2SimpleIO? [message #277646 is a reply to message #277642] |
Tue, 30 December 2014 02:53 |
Michael AppleWin Debu
Messages: 1262
Registered: March 2013
Karma: 0
|
Senior Member |
|
|
On Monday, December 29, 2014 8:55:27 PM UTC-8, mdj wrote:
> For storing ASCII strings, the Dextral Character Inverted method is more efficient in space to store and also the size and speed of the code required to scan it.
Ah, so that is what DCI means! TIL:DCI :-)
I like how the Merlin assembler gave the user the choice of how to store strings:
ASC "STRING" [negative ASCII string]
ASC 'STRING' [positive ASCII string]
ASC "Bye,Bye",8D [negative with added hex bytes]
DCI "STRING" [negative ASCII except for the G]
http://www.textfiles.com/apple/DOCUMENTATION/merlin.docs1
You raise a very good point Matt. You can tell Harry is a complete noob because he is thinking of prints in a vacuum; us experienced developers see the sea of operations for C strings: strlen(), strcpy(), strcat(). This dovetails nicely with your next point.
> I've personally always preferred the Pascal style, with a prepended length value. It's more time efficient for certain operations and most importantly far less error prone. The reserved character approach taken by C strings is if nothing else, a security disaster.
Indeed that is quite nice so you don't have to waste time (and cluttering code) doing a stupid and redundant strlen(). :-)
It is too bad C didn't officially / natively support a string8, string16, string32, with a 8-bit, 16-bit, or 32-bit string length prefix, respectively.. :-/
|
|
|
|
| Re: A2SimpleIO? [message #277647 is a reply to message #277632] |
Tue, 30 December 2014 03:02 |
Michael AppleWin Debu
Messages: 1262
Registered: March 2013
Karma: 0
|
Senior Member |
|
|
On Monday, December 29, 2014 5:21:51 PM UTC-8, Steve Nickolas wrote:
> Well, yes, but I prefer to code for a 64K machine (48, if not using
> ProDOS).
You kids with your fancy schmancy 16K language card. :-)
Back in my day we loved how games assumed only 48K so we could use the ol' copy ROM to LC RAM and "fix" Reset ;-)
|
|
|
|
| Re: A2SimpleIO? [message #277648 is a reply to message #277640] |
Tue, 30 December 2014 03:04 |
Michael AppleWin Debu
Messages: 1262
Registered: March 2013
Karma: 0
|
Senior Member |
|
|
On Monday, December 29, 2014 7:16:00 PM UTC-8, Bill Buckels wrote:
> Two trolls who don't know that strings are terminated with a NULL character
> comparing shoe sizes don't make much difference.
Why are you counting Harry twice?
/me ducks :-)
|
|
|
|
| Re: A2SimpleIO? [message #277649 is a reply to message #277646] |
Tue, 30 December 2014 03:04 |
mdj
Messages: 301
Registered: December 2012
Karma: 0
|
Senior Member |
|
|
On Tuesday, 30 December 2014 17:53:24 UTC+10, Michael 'AppleWin Debugger Dev' wrote:
> Indeed that is quite nice so you don't have to waste time (and cluttering code) doing a stupid and redundant strlen(). :-)
And you can load the length into an index register and do many operations 'backwards' yielding faster code.
> It is too bad C didn't officially / natively support a string8, string16, string32, with a 8-bit, 16-bit, or 32-bit string length prefix, respectively. :-/
C doesn't have a string type (except for the ability to define a string literal) just a bunch of functions that assume a pointer points to a null-terminated stream of bytes. There's plenty of 'better' string handling libraries around if you need them though.
Matt
|
|
|
|
| Re: A2SimpleIO? [message #277650 is a reply to message #277649] |
Tue, 30 December 2014 03:33 |
Michael AppleWin Debu
Messages: 1262
Registered: March 2013
Karma: 0
|
Senior Member |
|
|
On Tuesday, December 30, 2014 12:04:37 AM UTC-8, mdj wrote:
> On Tuesday, 30 December 2014 17:53:24 UTC+10, Michael 'AppleWin Debugger Dev' wrote:
>> Indeed that is quite nice so you don't have to waste time (and cluttering code) doing a stupid and redundant strlen(). :-)
> And you can load the length into an index register and do many operations 'backwards' yielding faster code.
Assuming you aren't thrashing the D$, yes lots of nice optimization possibilities open up.
>> It is too bad C didn't officially / natively support a string8, string16, string32, with a 8-bit, 16-bit, or 32-bit string length prefix, respectively. :-/
> C doesn't have a string type (except for the ability to define a string literal) just a bunch of functions that assume a pointer points to a null-terminated stream of bytes. There's plenty of 'better' string handling libraries around if you need them though.
The problem with string libraries is that everyone does things their own way -- meaning each API is different. :-/
C's internal view of memory pointer = array is both a blessing and a curse.
It enables stupid crap like this:
char hexDigit = "0123456789ABCDEF"[i]; // good
char hexDigit = i["0123456789ABCDEF"]; // legal, but horrible style
I really wish C++ would separate the whole pointer = array idiom, and provide an array_cast<#> from pointers for strong types. For example, due to inheriting C's bad design, you can't provide a separate pointer and array function overload because the compiler treats them as the same underlying type:
int count( int*p )
{
printf( "*p\n" );
}
int count( int a[1] ) // error, already defined!
{
printf( "[]\n" );
}
|
|
|
|
Members
Search
Help
Register
Login
Home
