BeebAsm

[SteveF]

Thanks for taking a look at that, I've built your branch and works fine.

Shall I create an issue for this and link to your branch so this doesn't get forgotten for the next release?

[ctr]

That would be great, thank you.

[SteveF]

Done, thanks again! https://github.com/stardot/beebasm/issues/44

[6502]

Just a quick question, does BeebAsm support string variables?
Such as:

Code: Select all

CONSTANT_NAME = "FOOBAR"

ORG &1900
.start
    EQUS CONSTANT_NAME
.end

[sweh]

I'm willing to be proved wrong, but I don't think so.

However, macros may meet the requirement, depending,

Code: Select all

MACRO CONSTANT_NAME 
  EQUS "FOOBAR"
ENDMACRO

ORG &1900
.start
    CONSTANT_NAME
.end

Off the top of my head, I can't think of a scenario where a string isn't used in an EQUS so the macro may suffice.

[6502]

I'm willing to be proved wrong, but I don't think so.

However, macros may meet the requirement, depending,

Code: Select all

MACRO CONSTANT_NAME 
  EQUS "FOOBAR"
ENDMACRO

ORG &1900
.start
    CONSTANT_NAME
.end

Off the top of my head, I can't think of a scenario where a string isn't used in an EQUS so the macro may suffice.

Yes just tested it and that works. Using a macro is a little clunky, but I guess it does the job.

[ReubenS]

I need a little help getting Beebasm to build Starquake from source...

Starquake is basically one big file that contains 1 large chunk and 3 small chunks, all concatenated together. This big file loads from disc at &1200 and the large chunk is immediately relocated to &E00, while the 3 smaller chunks are relocated to other addresses.

I think I understand the relocdemo sample but I can't see how to go about doing *multiple* relocations. Should I be aiming to do a different SAVE for each chunk? If so, then what loads them all?

[VectorEyes]

I need a little help getting Beebasm to build Starquake from source...

Starquake is basically one big file that contains 1 large chunk and 3 small chunks, all concatenated together. This big file loads from disc at &1200 and the large chunk is immediately relocated to &E00, while the 3 smaller chunks are relocated to other addresses.

I think I understand the relocdemo sample but I can't see how to go about doing *multiple* relocations. Should I be aiming to do a different SAVE for each chunk? If so, then what loads them all?

So it's one big file that gets loaded, then some code is executed that relocates the big chunk and the 3 smaller chunks, and then you jump to the 'main game start' code, something like that?

One approach might be to assemble the chunks at the 'destination' locations, SAVE all four of them out (to the local filesystem, not to the SSD) ... then have a second assembly pass that uses INCBIN to include each of them at the place they're meant to go when they're part of the one big file... then SAVE out the big file (along with the code that does the runtime relocation etc).

There are various other ways to do it but that approach seems simple and easy to implement.

[Rich Talbot-Watkins]

There's also a COPYBLOCK <start>, <end>, <dest> command which you might be able to use to shift blocks of code around after they've been assembled. That might work for you, though you'd need to be careful that you copy them in such an order that you don't overwrite anything you need to preserve. Generally, the trick would be to copy the block with the highest address destination first.

Code: Select all

ORG &400
.block1
\\ stuff
.block1end

ORG &900
.block2
\\ stuff
.block2end

ORG &E00
.block3
\\ stuff
.block3end

load = &1200
block1load = load
block2load = block1load + (block1end - block1)
block3load = block2load + (block2end - block2)
entryload = block3load + (block3end - block3)
COPYBLOCK block3, block3end, block3load
COPYBLOCK block2, block2end, block2load
COPYBLOCK block1, block1end, block1load

ORG entryload
.entry
\\ relocation code here
JMP start
.end

SAVE "Code", load, end, entry

I have no idea if that will actually work, but it looks as though it might.

(Note: this is a different technique to the relocdemo, which assembles to its final location but patches address references in the entry point code which will be loaded at a higher position. This makes use of the fourth parameter in SAVE, to supply a reload address.)

[ReubenS]

Thanks for the pointers, guys.

I was considering hacking at the "SAVE" command so that "SAVE+" (or something like that) appends to the previously saved file...

[alastairhm]

I've recently got a new Mac laptop from work with Catalina installed, the version of beebasm I previously downloaded didn't work I assume because it was 32 bit.

So I had to compile my own 64 bit version.

If you need a MacOs 64 bit version as well you can download it from here http://blog.0x32.co.uk/posts/beebasm/

[julie_m]

Would it be possible to add a feature to BeebAsm where PUTTEXT, INCBIN et al can launch a shell with two extra environment variables, one containing all the source code seen so far and the other with -v output so far; run an external command; and use its STDOUT in the disc image?

[garfield]

Another request for the excellent BeebAsm is: multi-line comments

i.e. the equivalent to /* */ in C and C++

It is a minor chore to put a single backslash before each line, so some "opening" and "closing" sequence to denote ignorable comments would be great.

Thanks again Rich and all.

[SteveF]

I've pulled together some of the recent fixes onto the proposed-updates branch (https://github.com/stardot/beebasm/tree ... ed-updates). It would be good to get these labelled up as beebasm 1.10, in particular mungre's fix for the "JMP .label" case where 1.09 just silently assembles 0 (https://github.com/stardot/beebasm/issues/44).

Can people please test this to see if it builds correctly for them and assembles their projects OK?

If I missed anyone's code submissions please let me know. (There have been some good ideas for improvement proposed and I hope someone will implement some of them at some point, but I don't personally have the time to do that right now.)

Here's the relevant bit of the changelog:

Code: Select all

??/??/????  1.10  Documented "$" and "%" as literal prefixes (thanks to
                  cardboardguru76 for pointing this out).
                  Fixed silently treating label references starting with "."
                  as 0 (thanks to mungre for this fix).
                  Allowed "-h" and "-help" options to see help.
                  Fixed tokenisation of BASIC pseudo-variables in some cases.
                  Fixed incorrect line number for errors inside macros with
                  blank lines inside them.
                  Fixed incorrect line numbers from PUTBASIC in some cases.              

[tricky]

Did you get my CALLSTACK$ request/sample implementation?
viewtopic.php?p=280427#p280427

[SteveF]

Did you get my CALLSTACK$ request/sample implementation?
viewtopic.php?p=280427#p280427

I hadn't picked this up but I've now tidied your implementation up slightly and pushed a version of this on the https://github.com/stardot/beebasm/tree ... -callstack branch, which also includes all of the other proposed-updates changes. Please take a look and let me know if you're happy with it, and if it still works correctly - I've only given it a light test.

I'll merge that onto proposed-updates later, in the meantime if people could build and test the tricky-fileline-callstack branch as the possible beebasm 1.10 release candidate I'd appreciate it.

[tricky]

Thanks, I'll give it a try tonight.
Sorry, I don't do git.

[tricky]

Thanks,
Still builds straight out of the box with the supplied VS2010 proj and sol.
CALLSTACK$ seems OK, but as it doesn't support -dd or -labels <labels file> I can't give it a full test.

[SteveF]

Thanks for trying that tricky. If you can give me a pointer to not-too-hacky code implementing -dd and -labels I will see if I can polish those up for inclusion too. (I won't search the forum myself in case there are newer/better implementations I might miss...)

[tricky]

I thought that they were already in, but I'll have a look!

[tricky]

This is my version that came from a proposed updates version that I think was based on 1.09.
It also include -writes 99 to set the number of accesses that the disc shows as having.
It is just the src folder without the VS2010 folder.

[SteveF]

Thanks tricky. I've tweaked that (mainly a bit of variable renaming to avoid errors on g++) and it's on https://github.com/stardot/beebasm/tree ... ricky-misc - this has CALLSTACK$ and FILELINE$ as well and all the other proposed-updates stuff.

I've very lightly tested this and it seems to be working but please try it and let me know how you get on. Edited to add: if it seems to be working, it would be good if you could compare the labels file generated with one from your current local beebasm build to help catch any glitches.

Cheers.

Steve

[tricky]

Thanks, great job and sorry it was so hacky in the first place!

It doesn't build with the supplied project because of the use of C++11 (I think it was 11).

Code: Select all

for (const Label & label : m_labelList)

It doesn't build with 2013

Code: Select all

..\commands.cpp(157): error C2039: 'max' : is not a member of 'std'

VS2019 works with updated WDK and toolset.
I've attached an updated .vcxproj
The solution will still default to 2010, but you can right click and "open with" or update the .sln

labels and disc images are binary identical.

[SteveF]

Thanks for testing that, good to know the output is still the same!

I've pushed changes to https://github.com/stardot/beebasm/tree ... ricky-misc to rewrite that C++11 code in a hopefully C++98-compatible way (it does at least build on g++ with --std=c++98). I hope that's OK but it seemed a shame to break C++98 compatibility just for this.

I haven't yet added your new BeebAsm.vcxproj - should I replace the existing VS2010/BeebAsm.vcxproj with this, or should I create a new VS2019/BeebAsm.vcxproj which is your new version? Do we need to put something in the README telling users what to do? As you can probably tell I'm not too well up on the finer points of VS...

[tricky]

There is no need to have it if it still builds fine with the old one.
If you do want to include it, I have just realised that it probably has source control entries which won't be helpful for anyone else!
I'll remove them and create a new .sln to go with the .vcxproj, they can then be placed in a VS2019 folder (for consistency).

[SteveF]

Thanks tricky, I'll add the VS2019 directory to the repo when you have the contents ready (no rush) and with a bit of luck someone will have an old Visual Studio they can test the existing VS2010 directory with - I think there's a fair chance that will still work now I've tweaked the problems you mentioned earlier (e.g. the C++11-style for loop), I just can't test myself.

[tricky]

That builds fine with 2010.

[SteveF]

Excellent, thanks for testing!

[SteveF]

I've created an experimental implementation of offset assembly for beebasm. You can find the code on the offset-assembly branch in my repo, which includes all the proposed 1.10 updates discussed above including tricky's contributions.

This adds an OPT command as in the BBC BASIC assembler, although only bit 2 (i.e. 4 or 0) is relevant - bits 0 and 1 have no effect. When using OPT 4-7, code is generated at O% but labels are assigned as if it were actually located at P%, and both O% and P% are advanced in step. I believe this implementation works exactly the same as in BBC BASIC; part of the code changes make it possible to assign to P% and O% multiple times during the assembly.

examples/offsetdemo.6502 on the offset-assembly branch shows how to use this; I'll paste it inline here for reference as well.

Code: Select all

\ Copy code into the screen RAM and execute it from there; this is silly, but
\ it shows the relocation happening...

oswrch = &ffee

org &2000

\ This code is assembled at &2000 and is intended to run there.
opt 3
.start
{
    lda #22:jsr oswrch:lda #4:jsr oswrch
    ldx #0
.copy_loop
    lda screen_code_copy_from,x:sta screen_code,x
    inx:bne copy_loop
    jsr screen_code
    jmp finish
}

\ This code is assembled immediately after the "jmp finish" at &20xx
\ but it is intended to run at &5e40.
.screen_code_copy_from
opt 7:O%=P%:P%=&5e40
.screen_code
{
    \ Use absolute jumps to show they use the right addresses.
    lda #0:sta &70
    lda #&70:sta &71
    lda #255:ldy #0
.loop
    sta (&70),y
    inc &70:beq low_byte_zero:jmp loop:.low_byte_zero
    inc &71:ldx &71:bpl high_byte_lt_80:jmp done:.high_byte_lt_80
    jmp loop
.done
    rts
}

\ This code is assembled immediately after the "rts" at &20xx and
\ is intended to run there.
opt 3:P%=O%
.finish
{
    \ Use some absolute jumps to show they use the right addresses.
    lda #'A':jsr oswrch
    jmp finish_b
.finish_c
    lda #'C':jsr oswrch
    rts
.finish_b
    lda #'B':jsr oswrch
    jmp finish_c
}
.end

save "test", start, end

Apart from fixes for the inevitable bugs , the only thing definitely missing from this branch is a change to the README to note this feature exists.

[tricky]

Sound useful.
I only have two references that need to allow for relocating, but sometimes have a thief and inevitably forget to offset it!