Jump to content
Atari_Force

BAS file with machine language

Recommended Posts

Hello.
I have this bas file (PROG.BAS). It's a copier (disk->tape).

COPY.atr

 

I want to insert here: 70 70 70 70 70

 

ins.thumb.PNG.44a6efd3d56144f424f64840f0a54e43.PNG

 

 

Obviously, if I insert: p p p p p  here, the program does not work:

ins1.thumb.PNG.ad543e6a9385207b5ee7ecb47a4ccd2d.PNG

 

What I can do?

Share this post


Link to post
Share on other sites

You would have to update the rest of the BASIC code and possibly machine code to tolerate/process the data you have inserted. That doesn't seem to be an easy task.

Share this post


Link to post
Share on other sites

There's methods to embed short routines but generally you want it to be something relocatable or to be copied to it's intended run address.

 

For a routine that's just called once you can embed it within a USR function, like:

 

1000 R=USR(ADR("hSJHWRUY*&")

(note, meaningless "assembly" routine there)

A potential problem with ML embedded in strings is if you have values 34 or 155 which are quote and RETURN.

A string within a DATA statement can contain quote marks but not the RETURN character.  The added downside to reading from DATA is you then have 2 copies of the same thing in memory which is wasteful.

 

Another alternate could be to just read the routine from a seperate file but that's only practical for disk based programs.

Share this post


Link to post
Share on other sites

You can still concatenate a string using chr$(155) though.  I wrote a utility called convert.bas which will take a binary file and convert to strings or data statements, and generate a .lst  file with the needed code.

Share this post


Link to post
Share on other sites

I always wondered how this worked on the C64. If you loaded a game there, you could (sometimes) list it as a basic program, though the only statement was a SYS instruction starting the game. Though I wonder how the machine language was actually loaded, how it comes that the basic interpreter does not puke on the machine language file, and how it comes that you can SYS to an absolute address.

Share this post


Link to post
Share on other sites
On 7/23/2019 at 6:19 AM, thorfdbg said:

I always wondered how this worked on the C64. If you loaded a game there, you could (sometimes) list it as a basic program, though the only statement was a SYS instruction starting the game. Though I wonder how the machine language was actually loaded, how it comes that the basic interpreter does not puke on the machine language file, and how it comes that you can SYS to an absolute address.

 

I was never much of a "Commie" so I mayy be all washed up on this but... for some reason I'm thinking that on the C64 the "DOS" and "BASIC" were part of the same over-all program.  I think CBM called it the "kernal" (yes with an A L).

Share this post


Link to post
Share on other sites
On 7/24/2019 at 10:57 PM, fujidude said:

 

I was never much of a "Commie" so I mayy be all washed up on this but... for some reason I'm thinking that on the C64 the "DOS" and "BASIC" were part of the same over-all program.  I think CBM called it the "kernal" (yes with an A L).

Having spent the past month or so immersing myself into C64 hardware from scratch in order to troubleshoot and repair my "Deadbin" model, I can tell you this: the C64 OS - such as it is - is pretty dreadfully primitive. There are actually 3 system ROMs, the BASIC ROM, the Kernal ROM, and the Character ROM. The Kernal ROM is essentially the "DOS" part of the system. That's a hell of a lot of board space and custom silicon for such primitive functionality in terms of user-friendliness. 

 

IMG_1697.thumb.png.393d1af8026322c20d40a6de361b571e.png

  • Like 1

Share this post


Link to post
Share on other sites

The C64 BASIC tokenized format may lend itself to embedding machine language files.  Other BASICs, not so much.  MS PC, for one, will go through the program after loading it and look for the line number separations while it rebuilds the linked list of lines.  When it encounters what would be considered a line number of zero, it declares that to be the end of the program and marks that as the start of the scalar variable heap.  I believe it also sanity-checks the line numbers to make sure they're in strictly ascending order.  If you wanted to embed machine language, you'd likely have to make most of the code friendly to the line number counting on load, and have a bunch of data statements with patch data to make the code runnable as soon as you first run the program.

Edited by ChildOfCv

Share this post


Link to post
Share on other sites

Hi!

On 7/23/2019 at 7:19 AM, thorfdbg said:

 

I always wondered how this worked on the C64. If you loaded a game there, you could (sometimes) list it as a basic program, though the only statement was a SYS instruction starting the game. Though I wonder how the machine language was actually loaded, how it comes that the basic interpreter does not puke on the machine language file, and how it comes that you can SYS to an absolute address.

 

This is also possible in Atari BASIC, see my example here: 

 

The reason that most C64 games use a BASIC stub is that the OS is not capable of loading binary files, so this is the only option to load data. Even the disk directory is loaded as a BASIC listing.

 

On the other hand, the Atari OS has support for booting from directly from disk and cassette, so it was not necessary to rely on BASIC loading.

 

Have Fun!

 

Share this post


Link to post
Share on other sites
On 7/23/2019 at 1:19 PM, thorfdbg said:

I always wondered how this worked on the C64. If you loaded a game there, you could (sometimes) list it as a basic program, though the only statement was a SYS instruction starting the game. Though I wonder how the machine language was actually loaded, how it comes that the basic interpreter does not puke on the machine language file, and how it comes that you can SYS to an absolute address.

 

My CBM-fu is rusty, but I think it worked like this:

 

A PRG file contains the load address in its first two bytes. DOS knows the length of the file from the file system. So  'LOAD"PROG",8' loads the complete contents of the file to the load adress. The first part of the file contains a small BASIC program which just calls SYS. The rest of the file is the machine language program. The parameter to SYS is the entry point into the machine language program loaded beyond the BASIC stub.

Share this post


Link to post
Share on other sites
3 hours ago, sanny said:

 

My CBM-fu is rusty, but I think it worked like this:

 

A PRG file contains the load address in its first two bytes. DOS knows the length of the file from the file system. So  'LOAD"PROG",8' loads the complete contents of the file to the load adress. The first part of the file contains a small BASIC program which just calls SYS. The rest of the file is the machine language program. The parameter to SYS is the entry point into the machine language program loaded beyond the BASIC stub.

Hmm. Two questions: Why is there an absolute address in basic programs? Wouldn't that mean if some part of the lower memory is used for other purposes that loading would fail? Or put differently, why would one ever want to load a basic program to some other place if the low memory start is always at the same place?

 

Second, why doesn't the basic interpreter puke on the "binary junk" behind the main program?

Share this post


Link to post
Share on other sites

Old BASIC implementations always loaded programs into the same address, so it was possible to use absolute addresses.

 

Even if you want to make the code relocatable, you'll still have to start with an absolute address that you trust for looking up pointers to whatever.

 

Why the interpreter doesn't puke is because it doesn't try to interpret it.  There is probably an end of program marker in the BASIC portion.  On PC, a line begins with two bytes that will be filled in with the location of the next line, followed by 2 bytes that contain the line number, followed by the tokenized data for that line, ending with a 0 byte and then followed by the next line.  The last line is simply two zeroes.

 

But BASIC doesn't know where those two zeroes are.  It knows the file size.  So it loads file size data bytes.  If you immediately run the program upon loading it, you should be okay.  But if you define variables first, it will probably crash since immediately following those two zeroes it sets the location of the variable space, which will begin overwriting the machine code.  But in neither circumstance does BASIC have to even consider the data the following the end of the BASIC tokenized program data.  So of course it doesn't choke.

Share this post


Link to post
Share on other sites
On 7/30/2019 at 10:55 PM, thorfdbg said:

Hmm. Two questions: Why is there an absolute address in basic programs? Wouldn't that mean if some part of the lower memory is used for other purposes that loading would fail? Or put differently, why would one ever want to load a basic program to some other place if the low memory start is always at the same place?

Ok. In CBM world at least (I just have some C64 knowledge, not much of the other machines).

 

On C64, the load address of a BASIC program is always $0801. In this regard it wouldn't make much sense to store the load address also in the PRG file.

 

But, one can also load files at arbitrary locations (as specified in their PRG header). 'LOAD"file",8' will (on the C64) always load the file to $0801. But 'LOAD"file",8,1' will load the file to the address specified in the PRG header. On the C64 the area $C000..$CFFF is free, beyond the BASIC ROM and not used by BASIC. So you typically loaded utilities (like machine language monitors or such) to this address and started them with SYS49152. My fingers still remember to type this address... 😊

  • Like 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...