Latest version of BeebAsm

[roland]

Hi,

I was looking for the latest version of BeebAsm but all the links I have found to the retrosoft site are still broken. Who has the sources or a Mac binary of BeebAsm?

Greetings,
Roland

[hoglet]

This repo seems quite current:
https://github.com/tom-seddon/beebasm

There is an even more recent branch:
https://github.com/tom-seddon/beebasm/commits/_tom

Dave

[hoglet]

This is the latest release I could find:

BeebASM-V1.08.zip

(515.18 KiB) Downloaded 139 times

Dave

[Prime]

1.08 is the latest as far as I am aware, certainly it's what I'm using.

I believe the source should compile without problems on a Mac, Linux, Windows....

Cheers.

Phill.

[danielj]

Not compiling on my mac at the moment. Barfing with an error. I shall investigate more later as the laptop's been hijacked for minecraft purposes.

d.

[roland]

I tried to compile it on my Mac but it fails:

Code: Select all

In file included from discimage.cpp:25:
./discimage.h:44:18: error: private field 'm_inputFilename' is not used
      [-Werror,-Wunused-private-field]
        const char*                                     m_inputFilename; 
                                                        ^

And when I remove that line there are other complains

Thanks for posting, I'll try to figure out how to compile it for El Capitan.

[danielj]

Yes, that's what I'm getting on El Capitan. I don't understand why that's a fatal error - and m_inputFilename *is* used!

d.

[tricky]

I would guess-Werror is setting warnings as errors, generally agood thing, but try turning it of.

[danielj]

Well, that got things a bit further, but it still died:

Code: Select all

-e Linking ... ../beebasm
ld: warning: option -s is obsolete and being ignored
ld: internal error: atom not found in symbolIndex(__ZNSt3__124__put_character_sequenceIcNS_11char_traitsIcEEEERNS_13basic_ostreamIT_T0_EES7_PKS4_m) for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [../beebasm] Error 1

My UNIX-commandline-C-compilation-fu sort of runs out roughly when they shifted linux from a.out to elf binaries...

d.

[tricky]

ld: internal error: atom not found in symbolIndex(__ZNSt3__124__put_character_sequenceIcNS_11char_traitsIcEEEERNS_13basic_ostreamIT_T0_EES7_PKS4_m) for architecture x86_64

May be being triggered by beebasm, but looks like a slightly dodgy compiler!
You could try the -v option, but my built-foo runs out as soon as it's not visual studio.

[sweh]

So on MacOS 10.10.5 do "make VERBOSE=1 code" and we see

Code: Select all

g++ -O3 -pedantic -Wall -W -Wcast-qual -Werror -Wshadow -Wcast-align -Wold-style-cast -Woverloaded-virtual -c discimage.cpp -o objects/discimage.o
In file included from discimage.cpp:25:
./discimage.h:44:18: error: private field 'm_inputFilename' is not used
      [-Werror,-Wunused-private-field]
        const char*                                     m_inputFilename;
                                                        ^

So the -Wunused-private-field is being set by the OS defaults and not the Makefile. However this can be fixed by setting CXXFLAGS= on the command line

Code: Select all

make code CXXFLAGS=

This then takes us to the next error:

Code: Select all

ld: warning: option -s is obsolete and being ignored
ld: internal error: atom not found in symbolIndex(__Z9WriteByteh) for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [../beebasm] Error 1

This can fixed by setting LDFLAGS=

Code: Select all

$ make clean
Automatically using platform macosx
-e Cleaning target and objects...
$ make code CXXFLAGS= LDFLAGS=
...
-e Compiling ... symboltable.cpp
-e Linking ... ../beebasm
$ ../beebasm
No source file

Let's test...

Code: Select all

$ cd ..
$ ./beebasm -i demo.6502
$ ls -l Code
-rw-r--r--  1 sweh  staff  2208 Oct 24 16:55 Code
$ hexdump -v -e '"%08_ax  "' -e 16'/1 "%02X ""  "" "' -e 16'/1 "%_p""\n"' Code | head   
00000000  78 A2 FF 9A 8E 44 FE 8E 45 FE A9 7F 8D 4E FE 8D   x....D..E....N..
00000010  43 FE A9 C2 8D 4E FE A9 0F 8D 42 FE A9 03 8D 40   C....N....B....@
00000020  FE A9 00 8D 4B FE A9 A6 8D 04 02 A9 12 8D 05 02   ....K...........
00000030  A2 40 A9 00 A8 99 00 40 C8 D0 FA EE 37 11 CA D0   .@.....@....7...
00000040  F4 A2 0D 8E 00 FE BD D7 12 8D 01 FE CA 10 F4 A9   ................
00000050  F4 8D 20 FE A2 0F BD E5 12 8D 21 FE 09 80 8D 21   .. .......!....!
00000060  FE CA 10 F2 A9 00 85 06 85 07 85 05 85 08 A9 01   ................
00000070  85 09 58 A5 05 F0 FC A9 00 85 05 A2 00 86 0A BD   ..X.............
00000080  00 18 85 01 18 BD 00 17 65 07 A8 18 69 40 85 0C   ........e...i@..
00000090  B9 00 14 85 02 38 B9 00 13 85 0B FD 00 19 B0 04   .....8..........
$ 

Looks good...

[danielj]

Thanks Stephen - all good now here. Just for my own reference, what was causing the linker error exactly?

d.

[roland]

Thanks Stephen, it also works for me

[sweh]

MacOS uses "clang" rather than "g++" so it's not 100% compatible. The "-s" flag to g++ was breaking on MacOS.

A bit more detail... if you run the make with VERBOSE=1 you see the last line it tries to run is

Code: Select all

g++ -s -o ../beebasm ./objects/BASIC.o ./objects/asmexception.o ./objects/assemble.o ./objects/commands.o ./objects/discimage.o ./objects/expression.o ./objects/globaldata.o ./objects/lineparser.o ./objects/macro.o ./objects/main.o ./objects/objectcode.o ./objects/sourcecode.o ./objects/sourcefile.o ./objects/stringutils.o ./objects/symboltable.o  -lm

to build the final program and that gave the error we'd seen before:

Code: Select all

ld: warning: option -s is obsolete and being ignored
ld: internal error: atom not found in symbolIndex(__Z9WriteByteh) for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
$ 

Removing "-s" works, which we can test from the command line:

Code: Select all

$ g++ -o ../beebasm ./objects/BASIC.o ./objects/asmexception.o ./objects/assemble.o ./objects/commands.o ./objects/discimage.o ./objects/expression.o ./objects/globaldata.o ./objects/lineparser.o ./objects/macro.o ./objects/main.o ./objects/objectcode.o ./objects/sourcecode.o ./objects/sourcefile.o ./objects/stringutils.o ./objects/symboltable.o  -lm   
$

Setting LDFLAGS was the simplest way of fixing it without needing to do any editing of the Makefile.

[Prime]

MacOS uses "clang" rather than "g++" so it's not 100% compatible. The "-s" flag to g++ was breaking on MacOS.

{RANT MODE}
Can't remember if it was MacOS or one of the Linux variants, but something that really irritated me was that when I toild it to install gcc, I got clang! No if I'd wanted clang I would have asked for that!!!!
{/RANT MODE}

Mind I suppose you could get the gcc source and compile that for MacOS, I had to do that on our cluster at work because someone wanted to compile something that required a version of gcc that was newer than the Ubuntu supplied one....

Cheers.

Phill.

[hoglet]

Looks like the current version of BeebASM doesn't support the Rockwell specific extensions, like BBR and BBS, which ADFS uses.

Is anyone still maintaining BeebASM?

If not, I'm happy to have a go at adding support for these myself.

Dave

[sweh]

Is anyone still maintaining BeebASM?

Yeah, over at www.retrosoftware.co.uk/forum/viewforum.php?f=17

[hoglet]

Is anyone still maintaining BeebASM?

Yeah, over at http://www.retrosoftware.co.uk/forum/viewforum.php?f=17

Thanks Stephen.

Actually, it turns out I don't need need BBR and BBS, these were just data in the ADFS disassembly.

Dave

[Rich Talbot-Watkins]

Author of BeebAsm here

I'm not really actively supporting it any more but can try and find the time to add patches if anyone has them. The Master 65C12 didn't have the Rockwell extensions, so I'm assuming the ADFS code you're looking at is something which gets copied over to run on the 2nd processor?

If you don't want to try to add the code to handle this natively, you could always fall back on macros (untested):

Code: Select all

MACRO BBR0 zp, address
   offset = address-P%-3
   IF offset>=-128 AND offset<=127
      EQUB &0F, zp, (offset AND 255)
   ELSE
      ERROR "Branch out of range"
   ENDIF
ENDMACRO

MACRO SMB0 zp
   EQUB &87, zp
ENDMACRO

etc

[hoglet]

Hi Rich,

I'm not really actively supporting it any more but can try and find the time to add patches if anyone has them. The Master 65C12 didn't have the Rockwell extensions, so I'm assuming the ADFS code you're looking at is something which gets copied over to run on the 2nd processor?

It turns out that the BBR and BBS were bogus, they were data rather than instructions.

But thanks for the macro, it may be useful in the future.

Dave

[sydney]

I'd just like to add my thanks to Stephen as I've just compiled this on a G5 imac using Xcode 3.1.4 and the instructions given worked perfectly!
I'd given the imac to my parents about 18 months ago and they got on quite well with it but they've asked for a better pc so I've given them my old windows machine and I'm going to give this mac a go at being my main machine for a while.