Assembling .a, .S files; .bas files; Fixed point; Functions; Questions?

[M12]

Hi all,

 

I'm new to 7800 programming. I'll let you know some of the things I know (and maybe you can correct me). And I also have some questions.

 

.a78 files are the machine language files that run directly in an Atari or an emulator such as Mess. How does one assemble such files? Is there an assembler I can download that can convert a ".S" or a ".a" into the machine code file that I can run on an Atari or emulator?

 

What is the difference between a ".S" file and a ".a" file? I downloaded source code from atarimuseum.com for a game such as Dig Dug, and all of the files are ".S" files, which seem to just be assembly files.

 

I also downloaded a game called INV+ (http://www.dos486.com/atari/index.shtml), which came in the form of a ".a" file, which seems to be an assembly file with some other assignments such as "BombDelay = $C6" at the beginning of the file; are these assignments just defining things so that the code is easier to read? INV+ also had a ".bin" file, which seemed to just be machine code (so a ".bin" file can also be run on an emulator or an Atari?).

 

Now, when it comes to BASIC files, the extension is ".bas". The games that came in the 7800basic download such as simple and adventurer had ".bas" files. The 7800basic is a compiler that takes in a ".bas" file as input and produces a ".a78" machine code file. Whenever I run 7800basic on a file such as "adventurer.bas", it outputs a 7800.asm file (which is an assembly file) and a "a78info.cfg" file. But there is no adventurer.bas.a78. Am I just not waiting long enough for the compiler? How long should it take?

 

Finally, are interpreters useful to use on a BASIC file rather than a compiler?

 

Thanks if you answer any of these questions!

Edited July 12, 2015 by M12

[M12]

Here's another question. I'm going through the source code for BASE78 because it includes the Asteroids code, which I am going to look through further. I had thought that the ".O" files were the machine code files, but when I tried to run the emulator (MESS) on the ".O" files by itself, it didn't work. How do I output the file used by the Atari or emulator from the source code?

[+RevEng]

Lots of questions, some attempts at answers...

 

There's no one standard "assembly" file extension. Homebrew 2600 and 7800 titles tend to use .asm. As you saw, .S and .A are also used too, and I'm sure there are more.

 

The most important thing to consider is that different assemblers will require different syntax, so if you're downloading a file you'll need to know which assembler it was written for. For example, you can't just take a historic assembly like DigDug and assemble it with a modern assembler like DASM, at least not without a lot of modification.

 

.a78 files are binary files for emulators, and not for use on the console itself. They're cart ROM images with an additional header that tells the emulator which hardware it should emulate. e.g. if an in-cart Pokey chip should be emulated.

 

.bin files are binary ROM files that can be burned onto cart eprom chips, or used with certain flash carts.

 

The file extension .o is usually reserved for object files - a sort of relocatable machine code. This is an intermediate step, and not useful in emulators or anything else except the build process.

 

I don't know why your 7800basic adventure.bas didn't compile into a .a78 file. Did you install 7800basic first? What command-line did you use to compile adventure.bas, and what output did it produce?

[ErikM]

Hi. INV+ programmer here, dos486.com is my site.

 

INV+'s source code is just a text file. The ".a" extension doesn't mean anything and isn't any kind of standard, that was just my own choice to mark Atari code separate from PC x86 assembler code (".asm") that I was also doing at the time. DASM and the other assemblers don't care what the file extension is, they will take any file containing text.

 

Yes, .bin files are the machine code to run on an emulator, or on a real Atari with the help of some kind of development cartridge that it can be loaded onto.

 

Yes, BombDelay and all those other lines are just defines, they are defining names for memory locations.

 

I am not promising that INV+'s code is any sort of good material to learn from. There are much better tutorials out there than my 18 year old mess of a game.

[Mord]

Interpreters like normal basic languages would not be useful on a retro console. The resources are highly limited as it is, and all interpreters run slower than having a compiled binary. (So even if you managed to make an interpreter, the resulting games you'll be able to write for it will be much more limited.)

 

Regarding your issue with adventurer.bas, the problem is that you're using the command "7800basic adventurer.bas". Use "7800bas adventurer.bas" instead. It'll compile quickly.

[M12]

Thanks RevEng and ErikM. That cleared up a lot. Mord, your solution worked.

 

I'm not too sure how to deal with functions in 7800 basic.

function multiply

temp1 = temp1 - 1

temp4 = temp2

for temp3 = 1 to temp1 : temp2 = temp2 + temp4

return temp2

end

Whenever I try to compile my code that includes this, it says that 'end' is an "unknown keyword". But this is a keyword according to the 7800basic guide. I also tried making 'end' not have any indentation, but then this resulted in "extraneous end statement found".

I also have a question about fixed point numbers. fp1 = 3.5 is for some reason represented as 0380 when I try to display it using the following:

plotvalue scoredigits_8_wide 0 fp1 4 x y

I am not sure why the decimal part of the number is represented as 80. Whenever I have say the numbers 1.5 and 7.7 (0180 and 07B3), adding them together results in 9.2 (0933). So the representation of the decimal part has some meaning because 80 + B3 = 133 - FF = 34 (not 33 because we carried the 1 over to the integer part). Why are the decimal parts represented like this and how do I convert it to a more familiar representation?

Edited July 11, 2015 by M12

[CPUWIZ]

Looks like hexadecimal numbers to me, maybe that's what is confusing you? I am just guessing, I didn't even know you could work with fixed point numbers in 7800Basic. Pretty cool, easy 8:8 resolution too.

[M12]

Looks like hexadecimal numbers to me, maybe that's what is confusing you? I am just guessing, I didn't even know you could work with fixed point numbers in 7800Basic. Pretty cool, easy 8:8 resolution too.

Well they are hexadecimal numbers, but I am good with normal hex conversions. If you do the conversion, it is not what you'd expect though. Thanks anyways

Edited July 12, 2015 by M12

[+RevEng]

Whenever I try to compile my code that includes this, it says that 'end' is an "unknown keyword". But this is a keyword according to the 7800basic guide. I also tried making 'end' not have any indentation, but then this resulted in "extraneous end statement found".

Seems like it might be a bug. I'll look into it. For now you can just skip the end statement, as it doesn't do anything meaningful anyway.

 

 

I also have a question about fixed point numbers. fp1 = 3.5 is for some reason represented as 0380 when I try to display it using the following:

plotvalue scoredigits_8_wide 0 fp1 4 x y

I am not sure why the decimal part of the number is represented as 80. Whenever I have say the numbers 1.5 and 7.7 (0180 and 07B3), adding them together results in 9.2 (0933). So the representation of the decimal part has some meaning because 80 + B3 = 133 - FF = 34 (not 33 because we carried the 1 over to the integer part). Why are the decimal parts represented like this and how do I convert it to a more familiar representation?

Plotvalue only knows how to work with whole numbers, and only ones coded in BCD or hexidecimal at that. If you're unsure of what BCD is, read about it in the guide.

 

Plotvalue doesn't understand 8.8, and to be honest I don't think it's worth complicating plotvalue to support such a special case. The game can fake it with game logic if its really needed.

 

When you displayed a non-BCD value using plotvalue, you saw the hex values, as Mr CPUWIZ correctly surmised. $80 is 128 decimal, or half of 256. The fractional numbers aren't represented in BCD, because that would throw away a lot of precision.

 

 

[...] I didn't even know you could work with fixed point numbers in 7800Basic. Pretty cool, easy 8:8 resolution too.

Yep, they're very handy and easy to use for subpixel movement. 7800basic inherited them from bB, so Fred can take the credit.

[M12]

Seems like it might be a bug. I'll look into it. For now you can just skip the end statement, as it doesn't do anything meaningful anyway.

 

....

Plotvalue only knows how to work with whole numbers, and only ones coded in BCD or hexidecimal at that. If you're unsure of what BCD is, read about it in the guide.

When you displayed a non-BCD value using plotvalue, you saw the hex values, as Mr CPUWIZ correctly surmised. $80 is 128 decimal, or half of 256. The fractional numbers aren't represented in BCD, because that would throw away a lot of precision.

Cool. I'll just leave 'end' out then. Thanks.

 

And as for the fixed point. The integer part is represented correctly. I understand BCD as well. But yeah, the fractional parts aren't a representation I'm familiar with. A thing I mentioned previously is that when you do take the fractional parts and add them together, it gets what you'd expect anyway. ...

1.5 (0180) + 7.7 (07B3) = 9.2 (0933) ... note that 80 + B3 = 34 and 34 - 1 = 33 (since 1 is carried), which is the arithmetic for the fractional parts.

[+RevEng]

But yeah, the fractional parts aren't a representation I'm familiar with.

Think of it this way... 1 represents 1/256, 2 represents 2/256, 3 represents 3/256, ...

 

To convert to something closer to what you want, it's probably best to use a lookup table. Pre-divide the value by 2 or 4 if you want to trade-off precision for space.

[M12]

Think of it this way... 1 represents 1/256, 2 represents 2/256, 3 represents 3/256, ...

 

To convert to something closer to what you want, it's probably best to use a lookup table. Pre-divide the value by 2 or 4 if you want to trade-off precision for space.

Ahhh, I see now. And now I also see that you explained this in the earlier post, but I didn't realize. Sorry I didn't catch it then. Thanks a bunch!

[M12]

Another thing I just noticed was that even a simple function such as

 

function foo

return 0

 

does not let the game play. It just displays the familiar Atari screen, then it goes to a black screen. I did not even call the function yet. Is there a certain area I should be writing my function declarations?

Edited July 12, 2015 by M12

[+RevEng]

The function itself should be out of the game flow, as it will be executed if the program flows into it.

 

If in doubt, stick it at the end.

[M12]

That was it. It works now.