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

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

PLASMA/Acme oddity

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

Contents

  PLASMA/Acme oddity mike.finger@gmail.com - 2016-04-06 11:28 -0700
    Re: PLASMA/Acme oddity David Schmenk <dschmenk@gmail.com> - 2016-04-07 08:42 -0700
      Re: PLASMA/Acme oddity David Schmenk <dschmenk@gmail.com> - 2016-04-07 08:51 -0700
        Re: PLASMA/Acme oddity Michael Finger <mike.finger@gmail.com> - 2016-04-07 09:29 -0700
          Re: PLASMA/Acme oddity David Schmenk <dschmenk@gmail.com> - 2016-04-07 11:17 -0700
            Re: PLASMA/Acme oddity Michael Finger <mike.finger@gmail.com> - 2016-04-08 11:13 -0700
              Re: PLASMA/Acme oddity Michael Finger <mike.finger@gmail.com> - 2016-04-08 11:14 -0700
              Re: PLASMA/Acme oddity David Schmenk <dschmenk@gmail.com> - 2016-04-08 13:19 -0700
                Re: PLASMA/Acme oddity Michael Finger <mike.finger@gmail.com> - 2016-04-08 21:45 -0700
                  Re: PLASMA/Acme oddity David Schmenk <dschmenk@gmail.com> - 2016-04-09 08:56 -0700
                  Re: PLASMA/Acme oddity David Schmenk <dschmenk@gmail.com> - 2016-04-09 09:14 -0700
                    Re: PLASMA/Acme oddity Michael Finger <mike.finger@gmail.com> - 2016-04-09 11:52 -0700
                      Re: PLASMA/Acme oddity D Finnigan <dog_cow@macgui.com> - 2016-04-09 20:09 +0000
                        Re: PLASMA/Acme oddity Michael Finger <mike.finger@gmail.com> - 2016-04-11 08:42 -0700

#2665 — PLASMA/Acme oddity

I have a question related to PLASMA and, by extension, the ACME assembler. 

The issue I'm running into is that I have some inline assembly in a function in PLASMA that is using labels. 

I trying to put in the No-Slot Clock time routines I borrowed from the ADTPro source.  I converted it to work with ACME, but it seems to be computing absolute label offsets based on the passed in program counter and not by location within the assembly code. 

Here is an example (PLASMA): 
asm _gettime 
L0260   lda #$00 
        sta L02DE 
        lda #$03 
L0267   ora #$C0 
        sta L031F 
L026C   sta L0322 
        sta L0331 
        sta L033F 
        lda #$03 
        sta L02DF 
        one L0292 
... 
L02DE   brk 
L02DF   brk 
L02E0   brk 

When I compile it and load it up in PLASMA, I have the PLASMA code print out the address of _gettime, which spits out $4047 as the address of _gettime 

Looking at the in memory code I see this: 
4047-   A9 00           LDA   #$00 
4049-   8D B2 10        STA   $10B2 
404C-   A9 03           LDA   #$03 
4067-   09 C0           ORA   #$C0 
4069-   8D F3 10        STA   $10F3 
406C-   8D F6 10        STA   $10F6 
406F-   8D 05 11        STA   $1105 
4072-   8D 13 11        STA   $1113 
4075-   A9 03           LDA   #$03 
4077-   8D B3 10        STA   $10B3 
407A-   D0 16           BNE   $4079 


The STA on 4049 should be $40C5 but it's $10B2, same with the other absolute address labels. 407A is correct, but that is a relative address. 

It looks like offset that are too large for a relative offset are based on the current value of the PC. 

I can get the offsets to be right if I run ACME with --setpc 16401 but then the execution crashes even before outputting the address value.  Which I'd expect since I'm sure It messes up the entry point. 

The loaded code runs correct (well, doesn't crash) if I do it from the monitor after it crashes: 

*4047g 
* 

Has anyone run into this?  Am I doing something wrong? 

FWIW, I did originally load code found in here for NSC time byte for byte (via memcpy) to $260 and it runs fine, except PLASMA uses the zero page for things so we end up walking on each other.   

Thanks for any help!

[toc] | [next] | [standalone]

#2673

On Wednesday, 6 April 2016 11:28:02 UTC-7, Michael Finger  wrote:
> I have a question related to PLASMA and, by extension, the ACME assembler. 
> 
> The issue I'm running into is that I have some inline assembly in a function in PLASMA that is using labels. 
> 
> I trying to put in the No-Slot Clock time routines I borrowed from the ADTPro source.  I converted it to work with ACME, but it seems to be computing absolute label offsets based on the passed in program counter and not by location within the assembly code. 
> 
> Here is an example (PLASMA): 
> asm _gettime 
> L0260   lda #$00 
>         sta L02DE 
>         lda #$03 
> L0267   ora #$C0 
>         sta L031F 
> L026C   sta L0322 
>         sta L0331 
>         sta L033F 
>         lda #$03 
>         sta L02DF 
>         one L0292 
> ... 
> L02DE   brk 
> L02DF   brk 
> L02E0   brk 
> 
> When I compile it and load it up in PLASMA, I have the PLASMA code print out the address of _gettime, which spits out $4047 as the address of _gettime 
> 
> Looking at the in memory code I see this: 
> 4047-   A9 00           LDA   #$00 
> 4049-   8D B2 10        STA   $10B2 
> 404C-   A9 03           LDA   #$03 
> 4067-   09 C0           ORA   #$C0 
> 4069-   8D F3 10        STA   $10F3 
> 406C-   8D F6 10        STA   $10F6 
> 406F-   8D 05 11        STA   $1105 
> 4072-   8D 13 11        STA   $1113 
> 4075-   A9 03           LDA   #$03 
> 4077-   8D B3 10        STA   $10B3 
> 407A-   D0 16           BNE   $4079 
> 
> 
> The STA on 4049 should be $40C5 but it's $10B2, same with the other absolute address labels. 407A is correct, but that is a relative address. 
> 
> It looks like offset that are too large for a relative offset are based on the current value of the PC. 
> 
> I can get the offsets to be right if I run ACME with --setpc 16401 but then the execution crashes even before outputting the address value.  Which I'd expect since I'm sure It messes up the entry point. 
> 
> The loaded code runs correct (well, doesn't crash) if I do it from the monitor after it crashes: 
> 
> *4047g 
> * 
> 
> Has anyone run into this?  Am I doing something wrong? 
> 
> FWIW, I did originally load code found in here for NSC time byte for byte (via memcpy) to $260 and it runs fine, except PLASMA uses the zero page for things so we end up walking on each other.   
> 
> Thanks for any help!

Hi Michael-

So you discovered the issue with embedded assembly in PLASMA: the module is built as a RELative object module (that funny relocatable format from the EDASM assembler). What happens is the PLASMA compiler doesn't parse the assembly, so it isn't able to record the fixups for any absolute address labels. You have a few options, but the easiest would be to place your data in a fixed location ($0300 would be a good choice). Another would be to rewrite the code all in PLASMA. Hope that gives you some options.

Dave...

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

#2674

On Thursday, 7 April 2016 08:42:44 UTC-7, David Schmenk  wrote:
> On Wednesday, 6 April 2016 11:28:02 UTC-7, Michael Finger  wrote:
> > I have a question related to PLASMA and, by extension, the ACME assembler. 
> > 
> > The issue I'm running into is that I have some inline assembly in a function in PLASMA that is using labels. 
> > 
> > I trying to put in the No-Slot Clock time routines I borrowed from the ADTPro source.  I converted it to work with ACME, but it seems to be computing absolute label offsets based on the passed in program counter and not by location within the assembly code. 
> > 
> > Here is an example (PLASMA): 
> > asm _gettime 
> > L0260   lda #$00 
> >         sta L02DE 
> >         lda #$03 
> > L0267   ora #$C0 
> >         sta L031F 
> > L026C   sta L0322 
> >         sta L0331 
> >         sta L033F 
> >         lda #$03 
> >         sta L02DF 
> >         one L0292 
> > ... 
> > L02DE   brk 
> > L02DF   brk 
> > L02E0   brk 
> > 
> > When I compile it and load it up in PLASMA, I have the PLASMA code print out the address of _gettime, which spits out $4047 as the address of _gettime 
> > 
> > Looking at the in memory code I see this: 
> > 4047-   A9 00           LDA   #$00 
> > 4049-   8D B2 10        STA   $10B2 
> > 404C-   A9 03           LDA   #$03 
> > 4067-   09 C0           ORA   #$C0 
> > 4069-   8D F3 10        STA   $10F3 
> > 406C-   8D F6 10        STA   $10F6 
> > 406F-   8D 05 11        STA   $1105 
> > 4072-   8D 13 11        STA   $1113 
> > 4075-   A9 03           LDA   #$03 
> > 4077-   8D B3 10        STA   $10B3 
> > 407A-   D0 16           BNE   $4079 
> > 
> > 
> > The STA on 4049 should be $40C5 but it's $10B2, same with the other absolute address labels. 407A is correct, but that is a relative address. 
> > 
> > It looks like offset that are too large for a relative offset are based on the current value of the PC. 
> > 
> > I can get the offsets to be right if I run ACME with --setpc 16401 but then the execution crashes even before outputting the address value.  Which I'd expect since I'm sure It messes up the entry point. 
> > 
> > The loaded code runs correct (well, doesn't crash) if I do it from the monitor after it crashes: 
> > 
> > *4047g 
> > * 
> > 
> > Has anyone run into this?  Am I doing something wrong? 
> > 
> > FWIW, I did originally load code found in here for NSC time byte for byte (via memcpy) to $260 and it runs fine, except PLASMA uses the zero page for things so we end up walking on each other.   
> > 
> > Thanks for any help!
> 
> Hi Michael-
> 
> So you discovered the issue with embedded assembly in PLASMA: the module is built as a RELative object module (that funny relocatable format from the EDASM assembler). What happens is the PLASMA compiler doesn't parse the assembly, so it isn't able to record the fixups for any absolute address labels. You have a few options, but the easiest would be to place your data in a fixed location ($0300 would be a good choice). Another would be to rewrite the code all in PLASMA. Hope that gives you some options.
> 
> Dave...

I forgot to mention, if you were successful using $260 for the code using memcpy, then you may just need to change the zero page locations. PLASMA uses $C0-$FF.

Dave...

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

#2675

On Thursday, April 7, 2016 at 10:51:31 AM UTC-5, David Schmenk wrote:
> On Thursday, 7 April 2016 08:42:44 UTC-7, David Schmenk  wrote:
> > On Wednesday, 6 April 2016 11:28:02 UTC-7, Michael Finger  wrote:
> > > I have a question related to PLASMA and, by extension, the ACME assembler. 
> > > 
> > > The issue I'm running into is that I have some inline assembly in a function in PLASMA that is using labels. 
> > > 
> > > I trying to put in the No-Slot Clock time routines I borrowed from the ADTPro source.  I converted it to work with ACME, but it seems to be computing absolute label offsets based on the passed in program counter and not by location within the assembly code. 
> > > 
> > > Here is an example (PLASMA): 
> > > asm _gettime 
> > > L0260   lda #$00 
> > >         sta L02DE 
> > >         lda #$03 
> > > L0267   ora #$C0 
> > >         sta L031F 
> > > L026C   sta L0322 
> > >         sta L0331 
> > >         sta L033F 
> > >         lda #$03 
> > >         sta L02DF 
> > >         one L0292 
> > > ... 
> > > L02DE   brk 
> > > L02DF   brk 
> > > L02E0   brk 
> > > 
> > > When I compile it and load it up in PLASMA, I have the PLASMA code print out the address of _gettime, which spits out $4047 as the address of _gettime 
> > > 
> > > Looking at the in memory code I see this: 
> > > 4047-   A9 00           LDA   #$00 
> > > 4049-   8D B2 10        STA   $10B2 
> > > 404C-   A9 03           LDA   #$03 
> > > 4067-   09 C0           ORA   #$C0 
> > > 4069-   8D F3 10        STA   $10F3 
> > > 406C-   8D F6 10        STA   $10F6 
> > > 406F-   8D 05 11        STA   $1105 
> > > 4072-   8D 13 11        STA   $1113 
> > > 4075-   A9 03           LDA   #$03 
> > > 4077-   8D B3 10        STA   $10B3 
> > > 407A-   D0 16           BNE   $4079 
> > > 
> > > 
> > > The STA on 4049 should be $40C5 but it's $10B2, same with the other absolute address labels. 407A is correct, but that is a relative address. 
> > > 
> > > It looks like offset that are too large for a relative offset are based on the current value of the PC. 
> > > 
> > > I can get the offsets to be right if I run ACME with --setpc 16401 but then the execution crashes even before outputting the address value.  Which I'd expect since I'm sure It messes up the entry point. 
> > > 
> > > The loaded code runs correct (well, doesn't crash) if I do it from the monitor after it crashes: 
> > > 
> > > *4047g 
> > > * 
> > > 
> > > Has anyone run into this?  Am I doing something wrong? 
> > > 
> > > FWIW, I did originally load code found in here for NSC time byte for byte (via memcpy) to $260 and it runs fine, except PLASMA uses the zero page for things so we end up walking on each other.   
> > > 
> > > Thanks for any help!
> > 
> > Hi Michael-
> > 
> > So you discovered the issue with embedded assembly in PLASMA: the module is built as a RELative object module (that funny relocatable format from the EDASM assembler). What happens is the PLASMA compiler doesn't parse the assembly, so it isn't able to record the fixups for any absolute address labels. You have a few options, but the easiest would be to place your data in a fixed location ($0300 would be a good choice). Another would be to rewrite the code all in PLASMA. Hope that gives you some options.
> > 
> > Dave...
> 
> I forgot to mention, if you were successful using $260 for the code using memcpy, then you may just need to change the zero page locations. PLASMA uses $C0-$FF.
> 
> Dave...

Dave,
  Thanks for the reply.  I just RTFM'd again and I found what you mentioning here probably at the same time you were righting it:
"Lastly, PLASMA modules are re-locatable, but labels inside assembly functions don't get flagged for fix-ups. The assembly code must use all relative branches and only accessing data/code at a fixed address."

Doh!  Sorry I missed that part and wasted the time.

I was successful using the memcpy for the timer routing, but it seemed to interfere with some of my variables when using them.

I'll post an example, but I had a loop running that was calling my _gettime function.  It was like:
for count = 1 to 10
   _gettime
next

I noticed it ran way more than 10 times.  When I had it print out count, the value was way out from 1-10.  I assumed that is because I was walking on stack space in the 0 page.  Is that correct?

Thanks for the response!
Mike

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

#2677

On Thursday, 7 April 2016 09:29:27 UTC-7, Michael Finger  wrote:
> On Thursday, April 7, 2016 at 10:51:31 AM UTC-5, David Schmenk wrote:
> > On Thursday, 7 April 2016 08:42:44 UTC-7, David Schmenk  wrote:
> > > On Wednesday, 6 April 2016 11:28:02 UTC-7, Michael Finger  wrote:
> > > > I have a question related to PLASMA and, by extension, the ACME assembler. 
> > > > 
> > > > The issue I'm running into is that I have some inline assembly in a function in PLASMA that is using labels. 
> > > > 
> > > > I trying to put in the No-Slot Clock time routines I borrowed from the ADTPro source.  I converted it to work with ACME, but it seems to be computing absolute label offsets based on the passed in program counter and not by location within the assembly code. 
> > > > 
> > > > Here is an example (PLASMA): 
> > > > asm _gettime 
> > > > L0260   lda #$00 
> > > >         sta L02DE 
> > > >         lda #$03 
> > > > L0267   ora #$C0 
> > > >         sta L031F 
> > > > L026C   sta L0322 
> > > >         sta L0331 
> > > >         sta L033F 
> > > >         lda #$03 
> > > >         sta L02DF 
> > > >         one L0292 
> > > > ... 
> > > > L02DE   brk 
> > > > L02DF   brk 
> > > > L02E0   brk 
> > > > 
> > > > When I compile it and load it up in PLASMA, I have the PLASMA code print out the address of _gettime, which spits out $4047 as the address of _gettime 
> > > > 
> > > > Looking at the in memory code I see this: 
> > > > 4047-   A9 00           LDA   #$00 
> > > > 4049-   8D B2 10        STA   $10B2 
> > > > 404C-   A9 03           LDA   #$03 
> > > > 4067-   09 C0           ORA   #$C0 
> > > > 4069-   8D F3 10        STA   $10F3 
> > > > 406C-   8D F6 10        STA   $10F6 
> > > > 406F-   8D 05 11        STA   $1105 
> > > > 4072-   8D 13 11        STA   $1113 
> > > > 4075-   A9 03           LDA   #$03 
> > > > 4077-   8D B3 10        STA   $10B3 
> > > > 407A-   D0 16           BNE   $4079 
> > > > 
> > > > 
> > > > The STA on 4049 should be $40C5 but it's $10B2, same with the other absolute address labels. 407A is correct, but that is a relative address. 
> > > > 
> > > > It looks like offset that are too large for a relative offset are based on the current value of the PC. 
> > > > 
> > > > I can get the offsets to be right if I run ACME with --setpc 16401 but then the execution crashes even before outputting the address value.  Which I'd expect since I'm sure It messes up the entry point. 
> > > > 
> > > > The loaded code runs correct (well, doesn't crash) if I do it from the monitor after it crashes: 
> > > > 
> > > > *4047g 
> > > > * 
> > > > 
> > > > Has anyone run into this?  Am I doing something wrong? 
> > > > 
> > > > FWIW, I did originally load code found in here for NSC time byte for byte (via memcpy) to $260 and it runs fine, except PLASMA uses the zero page for things so we end up walking on each other.   
> > > > 
> > > > Thanks for any help!
> > > 
> > > Hi Michael-
> > > 
> > > So you discovered the issue with embedded assembly in PLASMA: the module is built as a RELative object module (that funny relocatable format from the EDASM assembler). What happens is the PLASMA compiler doesn't parse the assembly, so it isn't able to record the fixups for any absolute address labels. You have a few options, but the easiest would be to place your data in a fixed location ($0300 would be a good choice). Another would be to rewrite the code all in PLASMA. Hope that gives you some options.
> > > 
> > > Dave...
> > 
> > I forgot to mention, if you were successful using $260 for the code using memcpy, then you may just need to change the zero page locations. PLASMA uses $C0-$FF.
> > 
> > Dave...
> 
> Dave,
>   Thanks for the reply.  I just RTFM'd again and I found what you mentioning here probably at the same time you were righting it:
> "Lastly, PLASMA modules are re-locatable, but labels inside assembly functions don't get flagged for fix-ups. The assembly code must use all relative branches and only accessing data/code at a fixed address."
> 
> Doh!  Sorry I missed that part and wasted the time.
> 
> I was successful using the memcpy for the timer routing, but it seemed to interfere with some of my variables when using them.
> 
> I'll post an example, but I had a loop running that was calling my _gettime function.  It was like:
> for count = 1 to 10
>    _gettime
> next
> 
> I noticed it ran way more than 10 times.  When I had it print out count, the value was way out from 1-10.  I assumed that is because I was walking on stack space in the 0 page.  Is that correct?
> 
> Thanks for the response!
> Mike

Hi Mike-

Most likely, the X register is getting trashed. PLASMA assumes a return value on the zero page evaluation/parameter stack, indexed by the X register.  The simple fix would be to save the X register at the beginning of _gettime , then restore it and issue a DEX right before the RTS. As long as you don't touch zero page $C0-$FF, everything should be good.

Dave...

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

#2679

On Thursday, April 7, 2016 at 1:17:12 PM UTC-5, David Schmenk wrote:
> On Thursday, 7 April 2016 09:29:27 UTC-7, Michael Finger  wrote:
> > On Thursday, April 7, 2016 at 10:51:31 AM UTC-5, David Schmenk wrote:
> > > On Thursday, 7 April 2016 08:42:44 UTC-7, David Schmenk  wrote:
> > > > On Wednesday, 6 April 2016 11:28:02 UTC-7, Michael Finger  wrote:
> > > > > I have a question related to PLASMA and, by extension, the ACME assembler. 
> > > > > 
> > > > > The issue I'm running into is that I have some inline assembly in a function in PLASMA that is using labels. 
> > > > > 
> > > > > I trying to put in the No-Slot Clock time routines I borrowed from the ADTPro source.  I converted it to work with ACME, but it seems to be computing absolute label offsets based on the passed in program counter and not by location within the assembly code. 
> > > > > 
> > > > > Here is an example (PLASMA): 
> > > > > asm _gettime 
> > > > > L0260   lda #$00 
> > > > >         sta L02DE 
> > > > >         lda #$03 
> > > > > L0267   ora #$C0 
> > > > >         sta L031F 
> > > > > L026C   sta L0322 
> > > > >         sta L0331 
> > > > >         sta L033F 
> > > > >         lda #$03 
> > > > >         sta L02DF 
> > > > >         one L0292 
> > > > > ... 
> > > > > L02DE   brk 
> > > > > L02DF   brk 
> > > > > L02E0   brk 
> > > > > 
> > > > > When I compile it and load it up in PLASMA, I have the PLASMA code print out the address of _gettime, which spits out $4047 as the address of _gettime 
> > > > > 
> > > > > Looking at the in memory code I see this: 
> > > > > 4047-   A9 00           LDA   #$00 
> > > > > 4049-   8D B2 10        STA   $10B2 
> > > > > 404C-   A9 03           LDA   #$03 
> > > > > 4067-   09 C0           ORA   #$C0 
> > > > > 4069-   8D F3 10        STA   $10F3 
> > > > > 406C-   8D F6 10        STA   $10F6 
> > > > > 406F-   8D 05 11        STA   $1105 
> > > > > 4072-   8D 13 11        STA   $1113 
> > > > > 4075-   A9 03           LDA   #$03 
> > > > > 4077-   8D B3 10        STA   $10B3 
> > > > > 407A-   D0 16           BNE   $4079 
> > > > > 
> > > > > 
> > > > > The STA on 4049 should be $40C5 but it's $10B2, same with the other absolute address labels. 407A is correct, but that is a relative address. 
> > > > > 
> > > > > It looks like offset that are too large for a relative offset are based on the current value of the PC. 
> > > > > 
> > > > > I can get the offsets to be right if I run ACME with --setpc 16401 but then the execution crashes even before outputting the address value.  Which I'd expect since I'm sure It messes up the entry point. 
> > > > > 
> > > > > The loaded code runs correct (well, doesn't crash) if I do it from the monitor after it crashes: 
> > > > > 
> > > > > *4047g 
> > > > > * 
> > > > > 
> > > > > Has anyone run into this?  Am I doing something wrong? 
> > > > > 
> > > > > FWIW, I did originally load code found in here for NSC time byte for byte (via memcpy) to $260 and it runs fine, except PLASMA uses the zero page for things so we end up walking on each other.   
> > > > > 
> > > > > Thanks for any help!
> > > > 
> > > > Hi Michael-
> > > > 
> > > > So you discovered the issue with embedded assembly in PLASMA: the module is built as a RELative object module (that funny relocatable format from the EDASM assembler). What happens is the PLASMA compiler doesn't parse the assembly, so it isn't able to record the fixups for any absolute address labels. You have a few options, but the easiest would be to place your data in a fixed location ($0300 would be a good choice). Another would be to rewrite the code all in PLASMA. Hope that gives you some options.
> > > > 
> > > > Dave...
> > > 
> > > I forgot to mention, if you were successful using $260 for the code using memcpy, then you may just need to change the zero page locations. PLASMA uses $C0-$FF.
> > > 
> > > Dave...
> > 
> > Dave,
> >   Thanks for the reply.  I just RTFM'd again and I found what you mentioning here probably at the same time you were righting it:
> > "Lastly, PLASMA modules are re-locatable, but labels inside assembly functions don't get flagged for fix-ups. The assembly code must use all relative branches and only accessing data/code at a fixed address."
> > 
> > Doh!  Sorry I missed that part and wasted the time.
> > 
> > I was successful using the memcpy for the timer routing, but it seemed to interfere with some of my variables when using them.
> > 
> > I'll post an example, but I had a loop running that was calling my _gettime function.  It was like:
> > for count = 1 to 10
> >    _gettime
> > next
> > 
> > I noticed it ran way more than 10 times.  When I had it print out count, the value was way out from 1-10.  I assumed that is because I was walking on stack space in the 0 page.  Is that correct?
> > 
> > Thanks for the response!
> > Mike
> 
> Hi Mike-
> 
> Most likely, the X register is getting trashed. PLASMA assumes a return value on the zero page evaluation/parameter stack, indexed by the X register.  The simple fix would be to save the X register at the beginning of _gettime , then restore it and issue a DEX right before the RTS. As long as you don't touch zero page $C0-$FF, everything should be good.
> 
> Dave...

Dave,
  Thanks for the help.  It's working fine now.  I tried to convert it to non-assembly (C or PLASMA) but apparently my ASM skills are not up to par.

But this worked fine and my looping issue is resolved
asm _readnsc
        txa
        pha
        jsr $030B
        pla
        tax
        dex
        its
end

Thanks again!

Mike

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

#2680

On Friday, April 8, 2016 at 1:13:07 PM UTC-5, Michael Finger wrote:
> On Thursday, April 7, 2016 at 1:17:12 PM UTC-5, David Schmenk wrote:
> > On Thursday, 7 April 2016 09:29:27 UTC-7, Michael Finger  wrote:
> > > On Thursday, April 7, 2016 at 10:51:31 AM UTC-5, David Schmenk wrote:
> > > > On Thursday, 7 April 2016 08:42:44 UTC-7, David Schmenk  wrote:
> > > > > On Wednesday, 6 April 2016 11:28:02 UTC-7, Michael Finger  wrote:
> > > > > > I have a question related to PLASMA and, by extension, the ACME assembler. 
> > > > > > 
> > > > > > The issue I'm running into is that I have some inline assembly in a function in PLASMA that is using labels. 
> > > > > > 
> > > > > > I trying to put in the No-Slot Clock time routines I borrowed from the ADTPro source.  I converted it to work with ACME, but it seems to be computing absolute label offsets based on the passed in program counter and not by location within the assembly code. 
> > > > > > 
> > > > > > Here is an example (PLASMA): 
> > > > > > asm _gettime 
> > > > > > L0260   lda #$00 
> > > > > >         sta L02DE 
> > > > > >         lda #$03 
> > > > > > L0267   ora #$C0 
> > > > > >         sta L031F 
> > > > > > L026C   sta L0322 
> > > > > >         sta L0331 
> > > > > >         sta L033F 
> > > > > >         lda #$03 
> > > > > >         sta L02DF 
> > > > > >         one L0292 
> > > > > > ... 
> > > > > > L02DE   brk 
> > > > > > L02DF   brk 
> > > > > > L02E0   brk 
> > > > > > 
> > > > > > When I compile it and load it up in PLASMA, I have the PLASMA code print out the address of _gettime, which spits out $4047 as the address of _gettime 
> > > > > > 
> > > > > > Looking at the in memory code I see this: 
> > > > > > 4047-   A9 00           LDA   #$00 
> > > > > > 4049-   8D B2 10        STA   $10B2 
> > > > > > 404C-   A9 03           LDA   #$03 
> > > > > > 4067-   09 C0           ORA   #$C0 
> > > > > > 4069-   8D F3 10        STA   $10F3 
> > > > > > 406C-   8D F6 10        STA   $10F6 
> > > > > > 406F-   8D 05 11        STA   $1105 
> > > > > > 4072-   8D 13 11        STA   $1113 
> > > > > > 4075-   A9 03           LDA   #$03 
> > > > > > 4077-   8D B3 10        STA   $10B3 
> > > > > > 407A-   D0 16           BNE   $4079 
> > > > > > 
> > > > > > 
> > > > > > The STA on 4049 should be $40C5 but it's $10B2, same with the other absolute address labels. 407A is correct, but that is a relative address. 
> > > > > > 
> > > > > > It looks like offset that are too large for a relative offset are based on the current value of the PC. 
> > > > > > 
> > > > > > I can get the offsets to be right if I run ACME with --setpc 16401 but then the execution crashes even before outputting the address value.  Which I'd expect since I'm sure It messes up the entry point. 
> > > > > > 
> > > > > > The loaded code runs correct (well, doesn't crash) if I do it from the monitor after it crashes: 
> > > > > > 
> > > > > > *4047g 
> > > > > > * 
> > > > > > 
> > > > > > Has anyone run into this?  Am I doing something wrong? 
> > > > > > 
> > > > > > FWIW, I did originally load code found in here for NSC time byte for byte (via memcpy) to $260 and it runs fine, except PLASMA uses the zero page for things so we end up walking on each other.   
> > > > > > 
> > > > > > Thanks for any help!
> > > > > 
> > > > > Hi Michael-
> > > > > 
> > > > > So you discovered the issue with embedded assembly in PLASMA: the module is built as a RELative object module (that funny relocatable format from the EDASM assembler). What happens is the PLASMA compiler doesn't parse the assembly, so it isn't able to record the fixups for any absolute address labels. You have a few options, but the easiest would be to place your data in a fixed location ($0300 would be a good choice). Another would be to rewrite the code all in PLASMA. Hope that gives you some options.
> > > > > 
> > > > > Dave...
> > > > 
> > > > I forgot to mention, if you were successful using $260 for the code using memcpy, then you may just need to change the zero page locations. PLASMA uses $C0-$FF.
> > > > 
> > > > Dave...
> > > 
> > > Dave,
> > >   Thanks for the reply.  I just RTFM'd again and I found what you mentioning here probably at the same time you were righting it:
> > > "Lastly, PLASMA modules are re-locatable, but labels inside assembly functions don't get flagged for fix-ups. The assembly code must use all relative branches and only accessing data/code at a fixed address."
> > > 
> > > Doh!  Sorry I missed that part and wasted the time.
> > > 
> > > I was successful using the memcpy for the timer routing, but it seemed to interfere with some of my variables when using them.
> > > 
> > > I'll post an example, but I had a loop running that was calling my _gettime function.  It was like:
> > > for count = 1 to 10
> > >    _gettime
> > > next
> > > 
> > > I noticed it ran way more than 10 times.  When I had it print out count, the value was way out from 1-10.  I assumed that is because I was walking on stack space in the 0 page.  Is that correct?
> > > 
> > > Thanks for the response!
> > > Mike
> > 
> > Hi Mike-
> > 
> > Most likely, the X register is getting trashed. PLASMA assumes a return value on the zero page evaluation/parameter stack, indexed by the X register.  The simple fix would be to save the X register at the beginning of _gettime , then restore it and issue a DEX right before the RTS. As long as you don't touch zero page $C0-$FF, everything should be good.
> > 
> > Dave...
> 
> Dave,
>   Thanks for the help.  It's working fine now.  I tried to convert it to non-assembly (C or PLASMA) but apparently my ASM skills are not up to par.
> 
> But this worked fine and my looping issue is resolved
> asm _readnsc
>         txa
>         pha
>         jsr $030B
>         pla
>         tax
>         dex
>         its
> end
> 
> Thanks again!
> 
> Mike

Whoops, rts autocorrected to its.

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

#2681

On Friday, 8 April 2016 11:13:07 UTC-7, Michael Finger  wrote:
>   Thanks for the help.  It's working fine now.  I tried to convert it to non-assembly (C or PLASMA) but apparently my ASM skills are not up to par.
> 
> But this worked fine and my looping issue is resolved
> asm _readnsc
>         txa
>         pha
>         jsr $030B
>         pla
>         tax
>         dex
>         its
> end
> 

Mike-
Glad you got it working. Interfacing assembly to PLASMA is one of its strengths, but I haven't done a great job of documenting it. Someday...

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

#2682

On Friday, April 8, 2016 at 3:19:25 PM UTC-5, David Schmenk wrote:
> On Friday, 8 April 2016 11:13:07 UTC-7, Michael Finger  wrote:
> >   Thanks for the help.  It's working fine now.  I tried to convert it to non-assembly (C or PLASMA) but apparently my ASM skills are not up to par.
> > 
> > But this worked fine and my looping issue is resolved
> > asm _readnsc
> >         txa
> >         pha
> >         jsr $030B
> >         pla
> >         tax
> >         dex
> >         its
> > end
> > 
> 
> Mike-
> Glad you got it working. Interfacing assembly to PLASMA is one of its strengths, but I haven't done a great job of documenting it. Someday...

I think it's an impressive piece of tech.  I'm just exploring options for getting back into retro-programming.  I'm grew up as a C guys, so cc65 was my natural choice but wanted to kick the tires of PLASMA, too.

I've written some blog posts about the (limited) amount of exploration of PLASMA I've done so far.  I plan on adding a post on what you helped me with here as well, so that I have it in a good place and can share it with whoever else is interested.

You can find the first post in the series here: http://retro2neo.org/2016/04/02/working-with-plasma/

Thanks again for all your help.

Mike

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

#2683

On Friday, 8 April 2016 21:45:03 UTC-7, Michael Finger  wrote:
> On Friday, April 8, 2016 at 3:19:25 PM UTC-5, David Schmenk wrote:
> > On Friday, 8 April 2016 11:13:07 UTC-7, Michael Finger  wrote:
> > >   Thanks for the help.  It's working fine now.  I tried to convert it to non-assembly (C or PLASMA) but apparently my ASM skills are not up to par.
> > > 
> > > But this worked fine and my looping issue is resolved
> > > asm _readnsc
> > >         txa
> > >         pha
> > >         jsr $030B
> > >         pla
> > >         tax
> > >         dex
> > >         its
> > > end
> > > 
> > 
> > Mike-
> > Glad you got it working. Interfacing assembly to PLASMA is one of its strengths, but I haven't done a great job of documenting it. Someday...
> 
> I think it's an impressive piece of tech.  I'm just exploring options for getting back into retro-programming.  I'm grew up as a C guys, so cc65 was my natural choice but wanted to kick the tires of PLASMA, too.
> 
> I've written some blog posts about the (limited) amount of exploration of PLASMA I've done so far.  I plan on adding a post on what you helped me with here as well, so that I have it in a good place and can share it with whoever else is interested.
> 
> You can find the first post in the series here: http://retro2neo.org/2016/04/02/working-with-plasma/
> 
> Thanks again for all your help.
> 
> Mike

Mike-

That is awesome! Can I add a link to your posts from the PLASMA site? Can I add you to the dev list ;-)

Dave...

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

#2684

On Friday, 8 April 2016 21:45:03 UTC-7, Michael Finger  wrote:
> On Friday, April 8, 2016 at 3:19:25 PM UTC-5, David Schmenk wrote:
> > On Friday, 8 April 2016 11:13:07 UTC-7, Michael Finger  wrote:
> > >   Thanks for the help.  It's working fine now.  I tried to convert it to non-assembly (C or PLASMA) but apparently my ASM skills are not up to par.
> > > 
> > > But this worked fine and my looping issue is resolved
> > > asm _readnsc
> > >         txa
> > >         pha
> > >         jsr $030B
> > >         pla
> > >         tax
> > >         dex
> > >         its
> > > end
> > > 
> > 
> > Mike-
> > Glad you got it working. Interfacing assembly to PLASMA is one of its strengths, but I haven't done a great job of documenting it. Someday...
> 
> I think it's an impressive piece of tech.  I'm just exploring options for getting back into retro-programming.  I'm grew up as a C guys, so cc65 was my natural choice but wanted to kick the tires of PLASMA, too.
> 
> I've written some blog posts about the (limited) amount of exploration of PLASMA I've done so far.  I plan on adding a post on what you helped me with here as well, so that I have it in a good place and can share it with whoever else is interested.
> 
> You can find the first post in the series here: http://retro2neo.org/2016/04/02/working-with-plasma/
> 
> Thanks again for all your help.
> 
> Mike

Mike-

One more thing. The videos are great showing the speed difference between C and PLASMA. I'm actually surprised PLASMA did as well as it did! Previous incarnations of PLASMA actually had the option to compile to native 6502 code. It ran almost 10 times faster than the byte code. Unfortunately, it was also 10 times larger. So I settled on the byte code and tried to make it as fast as possible, with the option of writing some routines in assembly for speed. It isn't completely apples to apples, but can you also look at the resultant object code size differences between C and PLASMA? The C object files and the PLASMA REL files both contain relocation information, albeit in different formats, but should at least give a feel for the size differences in the code generation. Again, thanks so much for your in depth review,

Dave...

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

#2685

On Saturday, April 9, 2016 at 11:14:03 AM UTC-5, David Schmenk wrote:
> On Friday, 8 April 2016 21:45:03 UTC-7, Michael Finger  wrote:
> > On Friday, April 8, 2016 at 3:19:25 PM UTC-5, David Schmenk wrote:
> > > On Friday, 8 April 2016 11:13:07 UTC-7, Michael Finger  wrote:
> > > >   Thanks for the help.  It's working fine now.  I tried to convert it to non-assembly (C or PLASMA) but apparently my ASM skills are not up to par.
> > > > 
> > > > But this worked fine and my looping issue is resolved
> > > > asm _readnsc
> > > >         txa
> > > >         pha
> > > >         jsr $030B
> > > >         pla
> > > >         tax
> > > >         dex
> > > >         its
> > > > end
> > > > 
> > > 
> > > Mike-
> > > Glad you got it working. Interfacing assembly to PLASMA is one of its strengths, but I haven't done a great job of documenting it. Someday...
> > 
> > I think it's an impressive piece of tech.  I'm just exploring options for getting back into retro-programming.  I'm grew up as a C guys, so cc65 was my natural choice but wanted to kick the tires of PLASMA, too.
> > 
> > I've written some blog posts about the (limited) amount of exploration of PLASMA I've done so far.  I plan on adding a post on what you helped me with here as well, so that I have it in a good place and can share it with whoever else is interested.
> > 
> > You can find the first post in the series here: http://retro2neo.org/2016/04/02/working-with-plasma/
> > 
> > Thanks again for all your help.
> > 
> > Mike
> 
> Mike-
> 
> One more thing. The videos are great showing the speed difference between C and PLASMA. I'm actually surprised PLASMA did as well as it did! Previous incarnations of PLASMA actually had the option to compile to native 6502 code. It ran almost 10 times faster than the byte code. Unfortunately, it was also 10 times larger. So I settled on the byte code and tried to make it as fast as possible, with the option of writing some routines in assembly for speed. It isn't completely apples to apples, but can you also look at the resultant object code size differences between C and PLASMA? The C object files and the PLASMA REL files both contain relocation information, albeit in different formats, but should at least give a feel for the size differences in the code generation. Again, thanks so much for your in depth review,
> 
> Dave...

Dave,
  Thanks for the kind words an the help.

Sure, feel free to link to the posts and the dev list.  I'm trying to share "journey" (I know, sounds corny) back into retro-programming in hopes that it will help others do the same.  I feel it's the "I can see further for I stand on the shoulders of giants", I not be able to do on my Apple ][ what I can now without those "giants" and if what I write can help someone else springboard into it, even better!  I'll where I can and hopefully more in the future as I learn more.

It's been a lot of fun and helped me focus on actually doing some retro stuff.

Comparing sizes is a great idea, I'll look into that as well.   I want to look at doing whatever comparisons I can either speed, size or easy of use and also other languages.  PLASMA is a great thing and has a lot of things going for it.  As with anything, it's about tradeoffs and the right tool for the job and having the data to make those decisions will hopefully help someone.

Thanks again for the feedback and the help with the code I was working with,
Mike

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

#2686

Michael Finger wrote:
> 
> Sure, feel free to link to the posts and the dev list.  I'm trying to
> share
> "journey" (I know, sounds corny) back into retro-programming in hopes that
> it will help others do the same.  I feel it's the "I can see further for I
> stand on the shoulders of giants", I not be able to do on my Apple ][ what
> I can now without those "giants" and if what I write can help someone else
> springboard into it, even better!  I'll where I can and hopefully more in
> the future as I learn more.
> 

Your blog is great. I look forward to reading your future articles.

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

#2687

On Saturday, April 9, 2016 at 3:12:55 PM UTC-5, D Finnigan wrote:
> Michael Finger wrote:
> > 
> > Sure, feel free to link to the posts and the dev list.  I'm trying to
> > share
> > "journey" (I know, sounds corny) back into retro-programming in hopes that
> > it will help others do the same.  I feel it's the "I can see further for I
> > stand on the shoulders of giants", I not be able to do on my Apple ][ what
> > I can now without those "giants" and if what I write can help someone else
> > springboard into it, even better!  I'll where I can and hopefully more in
> > the future as I learn more.
> > 
> 
> Your blog is great. I look forward to reading your future articles.

Thanks for the feedback!

[toc] | [prev] | [standalone]

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

csiph-web