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

Groups > comp.sys.apple2.programmer > #2679

Re: PLASMA/Acme oddity

Show all headers | View raw

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

Back to comp.sys.apple2.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web