6502.org • View topic - A test program?

View unanswered posts | View active topics

Board index » 6502.org Users Forum » EhBASIC

All times are UTC

A test program?

Page 4 of 4

[ 53 posts ]

Go to page Previous 1, 2, 3, 4

Previous topic | Next topic

Author

Message

dclxvi

Post subject: Re: A test program?

Posted: Fri Jun 29, 2018 12:21 am

Joined: Thu Mar 11, 2004 7:42 am
Posts: 362

The atan2 calculation in line 50 uses X<0, but the sign of TRUE turns out not to matter in that case because the comparison in line 60 is mod pi.

The argument for TRUE = 1 is that it's slightly easier to pack into (and unpack from) a bitfield or an array of bits. The argument for -1 is that it's more useful with bitwise operators (including XOR). I'm more of a fan of -1 myself, but both arguments are reasonable. (Apple I BASIC and Apple "Integer" BASIC also use 1.)

Also, it might be useful to have at least (tested versions of) some of these examples in source code repository and/or possibly a link to this thread. Adding a link to the EhBASIC link in on the homebuilt projects page might also be helpful.

Top

BillO

Post subject: Re: A test program?

Posted: Fri Jun 29, 2018 1:34 am

Joined: Fri Dec 12, 2008 10:40 pm
Posts: 1000
Location: Canada

floobydust wrote:

... but retirement has gotten overly busy, who knew :roll:

My very same lament. :roll:

Not only did I get myself involved in a full time 'career' playing trombone in 5 bands, and increasing my efforts in my digital electronics hobby, but also agreed to help my wife re-build a run-down cottage to use as an income property. We think we can control our type 'A' personalities, but in fact, they are what we are... :!:

_________________
Bill

Top

BigEd

Post subject: Re: A test program?

Posted: Fri Jun 29, 2018 6:33 am

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10793
Location: England

dclxvi wrote:

The argument for TRUE = 1 is that it's slightly easier to pack into (and unpack from) a bitfield or an array of bits. The argument for -1 is that it's more useful with bitwise operators (including XOR).

I always liked the approach taken in BBC Basic. The Boolean value of an expression is the same as testing for non-zero. That is, zero is false and non-zero is true. The builtin FALSE has the value zero, and the builtin TRUE has the value -1. As a consequence of all that, the boolean and bitwise operators are the same things and act in the expected way. It's even the case that NOT TRUE is equal to FALSE and NOT FALSE is equal to TRUE.

Top

Klaus2m5

Post subject: Re: A test program?

Posted: Fri Jun 29, 2018 3:26 pm

Joined: Sat Jul 28, 2012 11:41 am
Posts: 442
Location: Wiesbaden, Germany

BigEd wrote:

I always liked the approach taken in BBC Basic. The Boolean value of an expression is the same as testing for non-zero. That is, zero is false and non-zero is true.

I am not aware of any Basic that does not support this. You can replace

Code:

X = 5 : REM any value other than 0
IF X <> 0 THEN

Code:

X = 5 : REM any value other than 0
IF X THEN

_________________
6502 sources on GitHub: https://github.com/Klaus2m5

Top

GaBuZoMeu

Post subject: Re: A test program?

Posted: Sat Jun 30, 2018 7:13 pm

Joined: Wed Mar 01, 2017 8:54 pm
Posts: 660
Location: North-Germany

Chromatix wrote:

Quote:

3. 1 4 1 5 9 2 6 5 3 5 8 9 7 9 3 2 3 8 4 6 2 6 4 3 3 8 3 2 7 9

You can improve the formatting of this by changing "PRINT Q;" to "PRINT ;Q;".

EhBasic seems to be different on that. "PRINT ;Q;" wouldn't work:

Code:

190 ?;Q;
RUN
 3. 1 4 1 5 9 2 6 5 3 5 8 9 7 9 3 2 3 8 4 6 2 6 4 3 3 8 3 2 7 9
Ready
190 ?CHR$(Q+48);
RUN
3.141592653589793238462643383279
Ready

The hard way does

Top

Klaus2m5

Post subject: Re: A test program?

Posted: Sun Jul 01, 2018 12:33 pm

Joined: Sat Jul 28, 2012 11:41 am
Posts: 442
Location: Wiesbaden, Germany

The string compare is at LAB_1CAE. At LAB_1CE6 the strings are actually compared if they have the same length. FAC1_1 and FAC2_2 is used to hold the indirect pointer to the strings being compared. FAC2_2 was pointing to an invalid location in direct mode. Earlier in the code the string descriptor is pulled

Code:

      LDA   FAC2_2            ; get descriptor pointer low byte
      LDY   FAC2_3            ; get descriptor pointer high byte
      JSR   LAB_22BA          ; pop (YA) descriptor off stack or from top of string space
                              ; returns with A = length, X=pointer low byte,
                              ; Y=pointer high byte
      STX   FAC2_2            ; save string pointer low byte
      STY   FAC2_3            ; save string pointer high byte

In memory the pointer to the string descriptor is off by +$100. So I went back to LAB_EVEX to see where FAC2_2 is loaded. After some more single stepping I found it is pushed onto the stack from FAC1 and then restored to FAC2. When it is pushed to the stack via LAB_1B5B FAC1 is rounded which causes the high address to be incremented by 1 if FAC1_r is > $7f. FAC1_r is not cleared when FAC1 actually contains a memory pointer. Actually it is never cleared and so I am not so sure wether it could also go wrong in run mode.

Code:

; push sign, round FAC1 and put on stack

LAB_1B5B
      PLA                     ; get return addr low byte
      STA   ut1_pl            ; save it
      INC   ut1_pl            ; increment it (was ret-1 pushed? yes!)
                              ; note! no check is made on the high byte! if the calling
                              ; routine assembles to a page edge then this all goes
                              ; horribly wrong !!!
      PLA                     ; get return addr high byte
      STA   ut1_ph            ; save it
      LDA   FAC1_s            ; get FAC1 sign (b7)
      PHA                     ; push sign

; round FAC1 and put on stack

LAB_1B66
      JSR   LAB_27BA          ; round FAC1
      LDA   FAC1_3            ; get FAC1 mantissa3
      PHA                     ; push on stack
      LDA   FAC1_2            ; get FAC1 mantissa2
      PHA                     ; push on stack
      LDA   FAC1_1            ; get FAC1 mantissa1
      PHA                     ; push on stack
      LDA   FAC1_e            ; get FAC1 exponent
      PHA                     ; push on stack
      JMP   (ut1_pl)          ; return, sort of

Either FAC1_r must be cleared when FAC1 is used as a memory pointer or LAB_27BA should check wether the data type is string or number (without breaking something else of course).

edit: Sorry, I have posted this in the wrong thread. I will repost to the correct one.

_________________
6502 sources on GitHub: https://github.com/Klaus2m5

Last edited by Klaus2m5 on Sun Jul 01, 2018 4:47 pm, edited 1 time in total.

Top

JenniferDigital

Post subject: Re: A test program?

Posted: Sun Jul 01, 2018 4:18 pm

Joined: Mon May 25, 2015 1:12 pm
Posts: 92

I wasn't expecting the FAC1 (which I thought to be a floating point accumulator) to be used as a pointer.

Top

barrym95838

Post subject: Re: A test program?

Posted: Sun Jul 01, 2018 5:33 pm

Joined: Sun Jun 30, 2013 10:26 pm
Posts: 1926
Location: Sacramento, CA, USA

DigitalDunc wrote:

I wasn't expecting the FAC1 (which I thought to be a floating point accumulator) to be used as a pointer.

Agreed. If there's a point to that apparent level of complexity, it whizzed past my head.

Mike B.

Top

Page 4 of 4

[ 53 posts ]

Go to page Previous 1, 2, 3, 4

Board index » 6502.org Users Forum » EhBASIC

All times are UTC

Who is online

Users browsing this forum: No registered users and 3 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum