beebasm v1.10

[killpack]

Hello everyone,

Here to announce a new version of beebasm, over four years after v1.09. This one contains a significant number of additions and bug fixes that have been tested by the community for the last month. Thank you to those to worked on improvements or helped test.

The pre-compiled Windows executable is available from the beebasm GitHub releases page https://github.com/stardot/beebasm/releases/tag/v1.10

Changelog for v1.10:

• (Potentially breaking) Random number generator now uses 32-bit ints.
• Documented "$" and "%" as literal prefixes (thanks to cardboardguru76 forpointing this out).
• Fixed silently treating label references starting with "." as 0 (thanks to Charles Reilly for this fix).
• Allowed "-h" and "-help" options to see help.
• Fixed tokenisation of BASIC pseudo-variables in some cases. (Thanks to Richard Russell advice on this.)
• Fixed incorrect line number for errors inside macros with blank lines inside them.
• Fixed incorrect line numbers from PUTBASIC in some cases.
• Fixed crashes in PUTBASIC caused by edge cases in end-of-file handling.
• Added FILELINE$ and CALLSTACK$ (thanks to tricky for this)
• Added -cycle, -dd and -labels options (thanks to tricky for these)
• Added CMake support and man page (thanks to Dave Lambley)
• Added string values and VAL, EVAL, STR$, LEN, CHR$, ASC, MID$,
• LEFT$, RIGHT$, STRING$, LOWER$, UPPER$, ASM. (Charles Reilly with thanks to Steven Flintham.)
• Support underscore separators in numeric literals. C++'s built-in parsing was used previously so beebasm's numeric syntax varied between compilers and platforms; this is fixed.
• Improved literal exponent parsing.
• Error on out of range integer conversions.

[0xC0DE]

Thanks!

[Iggypop]

Thx, will use it

[derek]

HI,

I downloaded the source code and compiled on my Linux Mint 20.3 computer with no errors.

I reassembled the demo.6502 file and loaded and autorun perfectly in B_EM

All seems to work very nicely.

Just need to get VC Code to run in Linux correctly, seems to be a file path to the source code issue, all works in Windows 10 OK...

I wrote some Linux Bash scripts to assemble and run the 652 files.

Or is there a better way to use beeasm?

[julie_m]

Minor point I spotted: The included manpage still says 1.09.

[julie_m]

Macros

Just to be sure I am understanding this right, if I have a bunch of statements basically of the form

Code: Select all

LDX #source - varbase
LDY #dest - varbase
JSR entry_pt

and various entry points all doing assorted things with different values, found at some addresses pointed to by X and Y within a block of memory beginning at varbase, I can do something like

Code: Select all

MACRO COPY_COORDS source, dest
    LDX #source - varbase
    LDY #dest - varbase
    JSR copy_coords
ENDMACRO
\ ... stuff
    COPY_COORDS vptL, plotbuf+4

and it will insert code corresponding to

Code: Select all

LDX #vptL - varbase
LDY #plotbuf+4 - varbase
JSR copy_coords

? Will varbase (which we can be sure is defined in the main source) still be visible inside the macro?

And then can I put macros for each of these functions into one INCLUDEd file?

[tricky]

The macros will see the globals, but I'm not sure about the other way around, try it and see
an include used to be (maybe still is) a type of for loop so maybe in an inner scope.

[Rich Talbot-Watkins]

I don't think that's the case - Includes would be useless if their contents were not visible to the outside!

I think there's something like they have to be in global scope though (so no putting one in a FOR loop!).

[tricky]

You should know
I think I am thinking of variables.

[lovebug]

ive thought about variables in beebasm and a possible way would be to add a new command "var" which just allows you to overwrite the value in a constant without giving the "Symbol already defined." error

; define constant
zpPointer = 0

..

; update constant value
var zpPointer = zpPointer + 1

[Rich Talbot-Watkins]

And if someone references zpPointer in code before its initial definition, what value should it have? The lack of any satisfyingly correct answer to that was why I elected to treat symbols as constants right from the start.

If mutable variables were required (and they're a perennially popular request!), my thought was that they should be a different kind of "thing" altogether (maybe with a special prefix or suffix) which were not allowed to be forward-referenced.

I'm interested in the kind of use-cases people have for mutable variables, and wonder if there are other ways to solve these problems.

[tricky]

I think the only time I wasted then I ended up using P% as a variable and saving and restoring it.
Having to assign a mutable variable to a traditional variable to give it a specific point/time/value seems like a great idea.

[lovebug]

real variables would be nice, how about using an @ as a prefix ?

[lovebug]

i was looking through the documentation for beebasm and I couldnt find if it is able to make an adfs disk image which im going to need

maybe I missed something ?

[6502]

Beebasm is a fantastic development tool, but just run into an unexpected issue.

Code: Select all

.self_modifying_load
	LDA &1300, X
.self_modifying_store
	STA &0000, X

	INC self_modifying_load + 2
	INC self_modifying_store + 2

I'm setting up two self modifying addresses for shifting down code into zero page. Have removed the loop and branches for clarity.
After the memory INC's, the load should be &1400 and store &0100.

However, Beebasm is making the addressing mode of the STA to a "Zero Page,X" one instead of a STA "Absolute,X" which is what I wanted. Is there anyway of forcing an override to the addressing mode of the STA?

I could just type EQUB &9d, &00, &00, but that's an ugly sort of workaround.

[0xC0DE]

Is there anyway of forcing an override to the addressing mode of the STA?

I don't think there is. It is why I added that feature to my assembler (max65): STA! (with exclamation mark) forces absolute addressing mode.

You could also use code like STA &FF00,X and then set the high byte to zero before starting your copying loop.

[cmorley]

You could create a macro along the lines of:

Code: Select all

MACRO staabsx addr
equb &9d
equw addr
ENDMACRO

[TobyLobster]

I don't think there is. It is why I added that feature to my assembler (max65): STA! (with exclamation mark) forces absolute addressing mode.

And acme uses e.g. "STA+2 &0000,X" (the plus two meaning 'instruction+2 bytes'). It's a shame beebasm lacks this ability.

[Rich Talbot-Watkins]

Part of the reason for this is the way that BeebAsm was initially modelled on the BBC BASIC assembler for the greatest possible compatibility. In BBC BASIC, I don't think there's any way to do this either!

If you can, you could index with Y, which doesn't have a ZP mode. That was my approach to working around this limitation in the past, and before I realised I could do that, I was assembling it by hand with EQUB, as you suggested.

One possible way to handle this is to change the way BeebAsm assembles. Currently it generates an error for out of range 0...&FFFF addresses - what if it were to truncate instead, but not before checking whether the value were in ZP range?

i.e. replace this code in assemble.cpp:

Code: Select all

		if ( value < 0 || value > 0xFFFF )
		{
			throw AsmException_SyntaxError_BadAddress( m_line, oldColumn );
		}

		if ( value < 0x100 && HasAddressingMode( instruction, ZP ) )
		{
			Assemble2( instruction, ZP, value );
			return;
		}
		else if ( HasAddressingMode( instruction, ABS ) )
		{
			Assemble3( instruction, ABS, value );
			return;
		}

with this:

Code: Select all

		if ( value < 0x100 && HasAddressingMode( instruction, ZP ) )
		{
			Assemble2( instruction, ZP, value );
			return;
		}
		else if ( HasAddressingMode( instruction, ABS ) )
		{
			Assemble3( instruction, ABS, value & 0xFFFF );
			return;
		}

Then you could define a constant called ADDR16 = &10000

and assemble with STA ADDR16+value,X

or a new unary function ADDR16(x) which returns the same thing.

This was the implementation approach I took on my WIP BeebAsm 2.0. It made sense there because I made a point of truncating all values, so that e.g. you could write things like LDA #-1.

[BigEd]

It's a workaround, but if you write the loop with DEC instead of INC then perhaps the initial address will be a two-byte value? (Or maybe shuffle the INC to the top of the loop and start at &FF00.)

[Rich Talbot-Watkins]

DEC wouldn't work though if the source block overlaps with the destination block (I don't know how big the block is that's being copied). Honestly the very simplest workaround if possible is to index with Y, and use X as a counter for the memory pages you copy.

[lovebug]

in ladybug I remember having this issue somewhere in the code so i have a constant called dummy16 which is defined as &ff00 and use that as the address and just before it I store the correct high byte before the loop

[6502]

If you can, you could index with Y, which doesn't have a ZP mode. That was my approach to working around this limitation in the past, and before I realised I could do that, I was assembling it by hand with EQUB, as you suggested.

Oh yeah that's works. Didn't know the CPU didn't support STA zero page,Y

Thanks.

[lovebug]

sorry to be a pain
I just downloaded the source but i've forgotten the command to build it in linux mint, been using windows 7 and ide's for too long

-------------- edit ------------------

make all seems to be doing something

[archie456]

Hi,

I have an issue with the speed that BeebASM assembles code to an SSD file over a network.

My code consists of one ASM file which INCLUDEs another 25 or so ASM files to assemble into 3 files on an SSD, the code is not very large, the ASM files total 180KB and the assembled code on the SDD file is about 12KB.

I use VS Code, when the ASM files are stored on my Desktop the code assembles in under two seconds, but when its stored on my network drive (which is an solid state disk on a NAS), it takes about 75 seconds to assemble.

I know its not the network speed as when I copy the ASM files from the network it takes about 3 to 4 seconds.

Any ideas on why it takes so long to assemble files stored on a network location? Is there something I can do to speed things up?

Thanks.

[VectorEyes]

Hi,

I have an issue with the speed that BeebASM assembles code to an SSD file over a network.

My code consists of one ASM file which INCLUDEs another 25 or so ASM files to assemble into 3 files on an SSD, the code is not very large, the ASM files total 180KB and the assembled code on the SDD file is about 12KB.

I use VS Code, when the ASM files are stored on my Desktop the code assembles in under two seconds, but when its stored on my network drive (which is an solid state disk on a NAS), it takes about 75 seconds to assemble.

I know its not the network speed as when I copy the ASM files from the network it takes about 3 to 4 seconds.

Any ideas on why it takes so long to assemble files stored on a network location? Is there something I can do to speed things up?

Thanks.

To cut to the chase: assembling / compiling code from a network share is generally just a really bad idea. You'd probably do a lot better by storing the files locally. If you really, really want to assemble them from the network, then consider changing your build process so that there's a 'first step' that copies them from the share (either using rsync, or basic file copy) and then a second step to assemble from the local copies, and then a third step to copy them back.

As for why: Essentially when you access files across the network there is a lot of negotiation going on behind the scenes regarding how much of the files to copy across at any one time, whether to pre-cache bits of them, and so on. I had a look at the BeebAsm source and it's calling into std::ifstream::readline, which reads single characters at a time until it reaches an end-of-line character. So the code is reading single bytes at a time. Now there are all kinds of levels of caching ... the C++ libraries might pre-emptively read more than they need to, the OS file-reading implementation probably splits files into pages and pre-emptively caches one or more pages whenever it reads ... then whichever protocols are being using for networked file access (probably some form of SMB?) also do caching... you really don't have a vast amount of control over it all.

This is all very different to what's happening when you simply copy a file, where it's basically a fast, efficient stream of data being sent sequentially from the source to the destination.

Now BeebAsm could probably be altered such that it read the whole file into memory at the start, and then 'read' the file line by line from the in-memory copy. Which would speed things up, for sure. But I can't help feeling that just putting your files on a local drive is going to be the easiest solution!

[archie456]

OK, thanks for the advice. I'll set up some sort of copy local process.

Cheers.