PLASMA/Acme oddity

[mike....@gmail.com]

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!

[David Schmenk]

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...

[David Schmenk]

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...

[Michael Finger]

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

[David Schmenk]

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...

[Michael Finger]

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

[Michael Finger]

Whoops, rts autocorrected to its.

[David Schmenk]

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...

[Michael Finger]

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

[David Schmenk]

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...

[David Schmenk]

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...

[Michael Finger]

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

[D Finnigan]

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.

[Michael Finger]

Thanks for the feedback!