Beebasm feature request

[sydney]

I've recently restarted 6502 coding and I have a question about beebasm and .inf files. Is it possible to have beebasm automatically create an .inf file when assembling to the PC hard disk? If not would it be difficult to add this capability?
I ask this as I'd like to use the ROMless serial file system by gfoot to easily run and test programs as I develop them.
Thanks,
Sydney.

[tricky]

I can't help with the feature, but I write my own from beebasm by assembling the text and writing the. Inf file with a second save.

[sweh]

Or you could save to SSD image and then use a tool (like my MMB Utils) to extract the files, complete with inf

[sydney]

Or you could save to SSD image and then use a tool (like my MMB Utils) to extract the files, complete with inf

That was my initial idea but then thought beebasm must have all the information available so why not just use that.


\

I can't help with the feature, but I write my own from beebasm by assembling the text and writing the. Inf file with a second save.

I thought a second SAVE statement would be the way to go. Something like this:

Code: Select all

.inf
	EQUS "name "
	EQUS STR$~(start)
	EQUS STR$~(start)
	EQUS STR$~((end-start))
.endinf

SAVE "name.inf",inf,endinf

It doesn't work but I think I'm close.

[tricky]

Somewhere I posted my HEX macro for generating text strings of numbers.

MACRO HEX1 v
d = v AND &F
IF d<10
EQUB '0'+d
ELSE
EQUB 'A'+d-10
ENDIF
ENDMACRO
MACRO HEX2 v
HEX1 v DIV &10
HEX1 v
ENDMACRO
MACRO HEX4 v
HEX2 v DIV &100
HEX2 v
ENDMACRO

ORG &C000
EQUS "B%=&" : HEX4 MAIN : EQUS 13
EQUS "CH.", 34, "MOON", 34, 13
save "!BOOT", &C000, P%, 0, 0

[sydney]

Thanks for that Ticky it seems to have done the job!
For those wanting to do this here is the code I used along with Tricky's macros:

Code: Select all

.inf
	EQUS "river "
	EQUS "FFFF" : HEX4 start 		; load address
	EQUS " " : HEX4 start			; execute address
	EQUS " " : HEX4 (end-start)		; length
.infend
save "river.inf", inf, infend

Which produces the following river.inf file:

Code: Select all

river FFFF2000 2000 013A

I've not yet tried it out in anger but as long as my understanding of .inf files is right it should work.

[jgharston]

Thanks for that Ticky it seems to have done the job!
For those wanting to do this here is the code I used along with Tricky's macros:

Code: Select all

.inf
	EQUS "river "
	EQUS "FFFF" : HEX4 start 		; load address
	EQUS " " : HEX4 start			; execute address
	EQUS " " : HEX4 (end-start)		; length
.infend
save "river.inf", inf, infend

Which produces the following river.inf file:

Code: Select all

river FFFF2000 2000 013A

I've not yet tried it out in anger but as long as my understanding of .inf files is right it should work.

Using that INF file will cause the error Won't! (or similar) (or just crash the machine) as you're loading to the I/O processor and attempting to execute in the language processor. You want:

Code: Select all

.inf
	EQUS "river"
	EQUS " FFFF" : HEX4 start 		; load address
	EQUS " FFFF" : HEX4 start		; execute address
	EQUS " " : HEX4 (end-start)		; length
.infend
save "river.inf", inf, infend

Which produces the following river.inf file:

Code: Select all

river FFFF2000 FFFF2000 013A

[julie_m]

Is there a way to force BeebAsm to use a long address in an instruction (e.g. AD 70 00), even if there exists a form with a short address (e.g. A5 70) ?

[TobyLobster]

acme has this feature by adding "+2" on the mnemonic e.g. "LDA+2 $70" but I've not found it in BeebAsm.

EDIT: acme even lets you declare a symbol as 16 bit e.g.

Code: Select all

symbol+2 = $70               ; using this forces 16 bit operand.

I'm not sure I like the "+2" syntax, but defining symbols with leading zeros in acme will force 16 bit too:

Code: Select all

symbol = $0070

which seems cleaner.

[picosonic]

I’d like to see PUTBASIC be able to save out to a specified file on the PC, it only seems to save the tokenised version into SSD files

Currently I need to extract the tokenised BASIC file from the SSD in a separate step

[tricky]

In beebasm, if you are outputting to a disc images -do, all output files go there of not, they go to the pc file system, but I haven't tried this explicitly.

[picosonic]

In beebasm, if you are outputting to a disc images -do, all output files go there of not, they go to the pc file system, but I haven't tried this explicitly.

Thanks for the suggestion, however it doesn't seem to work.

When I create a test.asm file with just the following

Code: Select all

PUTBASIC "test.bas", "tokenised"

I get the error ..

Code: Select all

Processed file 'test.asm' ok
warning: no SAVE command in source file.

And no tokenised output is created

Looking at the source on GitHub for void LineParser::HandlePutBasic() it has a test for GlobalData::Instance().UsesDiscImage() before ImportBASIC() is called and ultimately is saved to the disc image with GlobalData::Instance().GetDiscImage()->AddFile()

Basically what I want to do is tokenise some BASIC, append it with 0D FF then append some machine code which I can call from the BASIC with a CALL command.

I can do it manually, but would be nice if beebasm could write the tokenised output to a PC file which would make all this much easier.

[jgharston]

Would be acceptable to do it as a seperate command, eg:

Code: Select all

rem build my program
BeebAsm blah blah blah
BasConv -t textsourcefile -b basicoutputfile
copy /b basicoutputfile+extracodefile finaloutfile

[picosonic]

Would be acceptable to do it as a separate command, eg:

Code: Select all

rem build my program
BeebAsm blah blah blah
BasConv -t textsourcefile -b basicoutputfile
copy /b basicoutputfile+extracodefile finaloutfile

That's almost exactly how I'm doing it.

It would still be nice if beebasm was able to output tokenised basic to somewhere other than a disk image file

[tricky]

Sorry

I would say you probably need a big fix then

[jgharston]

I think on the principle of Keep It Simple Software, if you want something to output tokenised BASIC, you should use a tool specifially written to output tokenised BASIC, and use BeebAsm to specifically translate assembler source code into binary output.
Otherwise, you'll be asking for an email extension next.

[julie_m]

A feature I would like to see is the ability to invoke a shell and run an external command; pass all the symbols defined in the source file to it somehow (either through environment variables, or via STDIN like an Asterisk AGI script); and either save its STDOUT to the output disc image, or treat it as an included source file (the script would have to withstand being run twice in this case).

[TobyLobster]

I think on the principle of Keep It Simple Software, if you want something to output tokenised BASIC, you should use a tool specifially written to output tokenised BASIC, and use BeebAsm to specifically translate assembler source code into binary output.
Otherwise, you'll be asking for an email extension next.

This principle only works so far I think. By the same logic, would you propose removing BeebAsm's ability to create SSDs? Once a file is assembled to binary, creating the SSD is a separate step that can be done by another tool. But I would say that people seem to find this facility very useful as a built in feature, and removing it would be a detriment.

Tokenising BASIC in some ways a close fit to the scope of the tool. It is at least vaguely similar to assembling source, in that it translates a text file (in this case the 'source' untokenised BASIC) into a binary (tokenised BASIC) for use on the BBC.

The reverse translation would be a less a good fit for the tool.

[julie_m]

I built a detokeniser into DFSBuster, which I could always hack out into a stand-alone program .....

[picosonic]

I think on the principle of Keep It Simple Software, if you want something to output tokenised BASIC, you should use a tool specifially written to output tokenised BASIC, and use BeebAsm to specifically translate assembler source code into binary output.
Otherwise, you'll be asking for an email extension next.

This principle only works so far I think. By the same logic, would you propose removing BeebAsm's ability to create SSDs? Once a file is assembled to binary, creating the SSD is a separate step that can be done by another tool. But I would say that people seem to find this facility very useful as a built in feature, and removing it would be a detriment.

Tokenising BASIC in some ways a close fit to the scope of the tool. It is at least vaguely similar to assembling source, in that it translates a text file (in this case the 'source' untokenised BASIC) into a binary (tokenised BASIC) for use on the BBC.

The reverse translation would be a less a good fit for the tool.

I kind of agree with you both to some extent.

I already run a build script which calls beebasm several times to create multiple machine code executables and data files, some of which are then merged together or added to a single disc image as part of the final step.

The reason I have separate steps is to generate the data files which comprise multiple parts and then create an index to those parts. These generate files on the host build system, which can then be incorporated into the final image. I also convert PNGs to Beeb format and get compressed but only if the source files have changed on the dev environment.

My limited use case seems on the face of it quite trivial to implement. I'd be happy to do it, but don't want to fork a separate branch of the code. After all, it does already tokenise the imported BASIC.

But I also understand it's a change which is unlikely to get a lot of use when there are already tools out there for generating tokenised BASIC. I don't see it as a bug or omission.

Thanks

[SteveF]

I kind of agree with you both to some extent.

Me too, FWIW.

My limited use case seems on the face of it quite trivial to implement. I'd be happy to do it, but don't want to fork a separate branch of the code. After all, it does already tokenise the imported BASIC.

I can't speak for anyone else, but if you're willing to implement this I can't see why it couldn't be merged into the master beebasm code in the stardot repo without needing a permanent fork. As you say, it's probably not too hard to implement and I don't think it need be too intrusive to add an option to beebasm to support it, so anyone who prefers not to use it can just ignore the new feature.

Edit: at the risk of stating the obvious, if you use beebasm as-is to generate a disc image containing nothing but a BASIC program, you can (I think; I haven't tried this just now) get the tokenised BASIC out of the disc image just by chopping off the first 512 bytes. (On Unix, "tail -c +512 foo.ssd > foo.tok" would do it.)

[sweh]

FWIW, I think this diff would mean that if the destination file is called "*" then PUTBASIC will inline the code

So, for example:

Code: Select all

        ORG &2000
.start
        PUTBASIC "myprog","*"
.end
        SAVE "foo",start,end

and

Code: Select all

% cat myprog 
10 PRINT "HELLO"

Then the output is

Code: Select all

% ls -l foo
-rw-r--r-- 1 sweh sweh 16 Oct 29 17:14 foo

% hdump foo
00000000  0D 00 0A 0E 20 F1 20 22 48 45 4C 4C 4F 22 0D FF   .... . "HELLO"..

% beeb list foo
   10 PRINT "HELLO"

~~~~~

Code: Select all

--- a/src/commands.cpp
+++ b/src/commands.cpp
@@ -1622,8 +1622,10 @@ void LineParser::HandlePutBasic()
 		throw AsmException_SyntaxError_InvalidCharacter( m_line, m_column );
 	}
 
-	if ( GlobalData::Instance().IsSecondPass() &&
-		 GlobalData::Instance().UsesDiscImage() )
+	// If filename is '*' (we're inlining the code) we need to do this
+	// on both passes for consistent sizes
+	if ( (GlobalData::Instance().IsSecondPass() &&
+		 GlobalData::Instance().UsesDiscImage() ) || (beebFilename.compare("*") == 0 ) )
 	{
 		Uint8* buffer = new Uint8[ 0x10000 ];
 		int fileSize;
@@ -1645,12 +1647,19 @@ void LineParser::HandlePutBasic()
 			}
 		}
 
+		if (beebFilename.compare("*") != 0) {
+
 			// disc image version of the save
 			GlobalData::Instance().GetDiscImage()->AddFile( beebFilename.c_str(),
 										reinterpret_cast< unsigned char* >( buffer ),
 										0xFFFF1900,
 										0xFFFF8023,
 										fileSize );
+		} else {
+			for (int i=0;i<fileSize; i++) {
+				ObjectCode::Instance().PutByte( buffer[i] );
+			}
+		}
 
 		delete [] buffer;
 	}

[picosonic]

FWIW, I think this diff would mean that if the destination file is called "*" then PUTBASIC will inline the code

So, for example:

Code: Select all

        ORG &2000
.start
        PUTBASIC "myprog","*"
.end
        SAVE "foo",start,end

and

Code: Select all

% cat myprog 
10 PRINT "HELLO"

That’s a great idea to inline it, that way I can add machine code or data afterwards easily on the same beebasm command and not need to worry about the file size of the BASIC changing as I edit it and messing up all the offsets

[picosonic]

Edit: at the risk of stating the obvious, if you use beebasm as-is to generate a disc image containing nothing but a BASIC program, you can (I think; I haven't tried this just now) get the tokenised BASIC out of the disc image just by chopping off the first 512 bytes. (On Unix, "tail -c +512 foo.ssd > foo.tok" would do it.)

Yes I could use something like

Code: Select all

dd if=foo.ssd of=foo.tok bs=1 skip=512 count=???

But I’d need to work out what the value of count was.

[SteveF]

Yes I could use something like

Code: Select all

dd if=foo.ssd of=foo.tok bs=1 skip=512 count=???

But I’d need to work out what the value of count was.

If the BASIC program is the only thing on the .ssd, I think you can just set count=1000000 ("infinity") - the worst that will happen is you'll get up to 255 bytes of padding at the end of the tokenised program, which BASIC will just ignore. But yes, if there's something else on the disc too you would.

[picosonic]

If the BASIC program is the only thing on the .ssd, I think you can just set count=1000000 ("infinity") - the worst that will happen is you'll get up to 255 bytes of padding at the end of the tokenised program, which BASIC will just ignore. But yes, if there's something else on the disc too you would.

I can omit count= to get the rest of the file, but I want to append machine code and data to the tokenised BASIC and then be able to CALL it from the BASIC code. So I do need to know how big the output is.