Jump to content

Photo

I'm officially looking to become a programmer.


30 replies to this topic

#26 pojr OFFLINE  

pojr

    Space Invader

  • Topic Starter
  • 23 posts

Posted Sun May 22, 2011 6:34 PM

Alright, here's a good question, will Batari Basic help me learn Assembly in the end? Because whether or not I learn Batari Basic, I think I will eventually try out Assembly.

#27 potatohead OFFLINE  

potatohead

    River Patroller

  • 4,397 posts
  • Location:Portland, Oregon

Posted Sun May 22, 2011 7:14 PM

Yes.

With that goal in mind, it's not a bad idea to either write something basic, or compile the same, and get the assembly language output. Use the simple 4K mode, no bankswitch, etc...

Once you have that assembly listing, you can go through and examine it in detail. Last I looked, some parts of it were auto-commented. Either way, you have something very valuable. A high level, simplified representation, and a lower level assembly language one.

Long ago, on the Apple computers first, then Atari computers, I did a similar thing, on the advice of a mentor at the time. To get going on assembly, you can start commenting the assembly language listing, line by line.

Work in layers, identifying the code vs data blocks first. Then use a different color highlighter or pen, then go back and find the control structures, matching them up to the higher level program. Finally get into the detail.

That process will do you a lot of good. Score some assembly references, and just decode the thing. It will take a while, but it pays off.

If you want to mix it up a bit, you can get to a point where you make changes to the assembly, see the behavior change, and then do the same at the higher level, or reverse that to see how things might get done.

Should you get to the making changes part, you are well on your way then. Time to just start looking at all sorts of assembly code, and it's game on from there.

You can also start "swapping in" assembly to replace things you find in the BASIC program, using the inline assembly capability. Simple things like a multiply, or bit shift, variable swap, etc... all are great targets.

IMHO, this is one of the better learning scenarios available. The VCS itself is difficult, but the environment and how you can mix it up high level and low level is damn sweet. There are similar things for the 8 bit computers too. Others can advise there.

Edited by potatohead, Sun May 22, 2011 7:17 PM.


#28 SeaGtGruff OFFLINE  

SeaGtGruff

    Quadrunner

  • 5,558 posts
  • Location:Georgia, USA

Posted Sun May 22, 2011 8:22 PM

Once you have that assembly listing, you can go through and examine it in detail. Last I looked, some parts of it were auto-commented. Either way, you have something very valuable. A high level, simplified representation, and a lower level assembly language one.

Not "auto-commented" exactly, but the compiled assembly listing does show the original batari Basic instructions as comments, followed by the assembly code that was generated for/from those batari Basic instructions. The assembly code itself doesn't contain comments, though, except any comments that Fred (batari) may have added into the code while he was writing it, and those would probably be more along the lines of "notes to self." :) But being able to see the original batari Basic instructions with the assembly code they generated is invaluable if you're just learning assembly.

In fact, this presents a good reason for putting individual batari Basic instructions on their own program lines as much as possible, rather than using colons to cram dozens of batari Basic instructions into each program line. If you put four instructions on one line, the assembly listing will show all four instructions as a single comment, followed by the assembly language for all four of those instructions, which would make it harder to see which assembly code corresponds to which individual instruction.

Of course, sometimes you *have* to put multiple instructions on a single line, separated by colons, such as in the "then" or "else" portions of an "if-then-else" construct. And you can save bytes of ROM by putting similar assignment instructions together on a single line (e.g., A=1:B=1:C=1:D=1). But as for an "if-then-else," you can usually redesign it to use "goto" so you can break the "then" and "else" portions up into one-instruction-per-line code if you want to see how each instruction gets converted to assembly code. And as for putting similar assignment statements together on a line, that's actually a good thing, because in the assembly code you can see how the value was loaded into the accumulator just once and then stored into several memory locations, rather than having to reload the (same) value into the accumulator each time.

I don't know if someone else already explained this, but you had asked why there were so many files. The reason for all the files is because each one is a step along the way.

You begin by coding your program, either in assembly language or batari Basic.

Your program can "include" other files in it. These "include" files contain bits of code or other instructions (such as label assignments) that don't change from program to program, so it's more convenient to put them in reusable "include" files, rather than having to code them all over again from scratch each time you want to make a new program. If you're using batari Basic, the necessary "include" files will usually be added to your program automatically, although you can include additional files if you want, or even tell batari Basic to use a different set of "include" files than the ones it would have used by default. If you're programming in assembly, you need to specify the "include" files you want to use. Either way, you generally save your program code as a single file; the various "include" files are separate files, but you don't need to save them (unless you're writing new "include" files of your own), because they're already saved.

If you're programming in batari Basic, you'll need to compile your program using the batari Basic compiler. It consists of multiple files-- the compile batch file, the various executables used in the compile process, and the various "include" files-- but all you need to worry about is the command that compiles your program. If you're using an IDE (a special text editor used by programmers), you can set up the compile command so you can compile your program with just a mouse click. Visual bB is an IDE that's created just for batari Basic, and it includes various tools to help you create your program more easily. But you can also use a generic IDE, and set it up to compile, assemble, and run your programs.

Anyway, the compile process creates one or more intermediate files that contain the assembly language equivalent of your batari Basic code.

If you're programming in assembly, you don't need to compile your program, but you will need to assemble it using an assembler, such as DASM. The assembler takes the assembly code for your program and converts it into machine code that the Atari can understand. It also puts the machine code into the proper ROM format that the Atari uses. If you're programming in batari Basic, the compile batch will automatically assemble your program as the second phase of the overall compile process.

The result will be a single file that contains the ROM image for your program, which can then be played in an emulator, or transferred to a cart and played on an actual Atari.

Michael

#29 purduecrum OFFLINE  

purduecrum

    Moonsweeper

  • 498 posts
  • Location:Lafayette, IN

Posted Sun Aug 7, 2011 10:41 AM

<bump>

I just downloaded VisualbB 1.0 Build 554 and batari_basic 1.1 beta. I have yet to unpack or install either. Do I need both? What else do I need?

I'm using Windows Vista. I think at some point I would go the assembly route, I do have DASM and have experimented with it. I think my best way to continue my introduction is to shift to something like batari basic until I get a better feel for all of the timing/cycle issues.

I have read most of Scanlon's 6502 Software Design book and you could say I have some experience programming (especially in C and in a variety of UNIX scripting languages).

Edited by purduecrum, Sun Aug 7, 2011 10:45 AM.


#30 Random Terrain OFFLINE  

Random Terrain

    Visual batari Basic User

  • 28,180 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Sun Aug 7, 2011 1:13 PM

I just downloaded VisualbB 1.0 Build 554 and batari_basic 1.1 beta. I have yet to unpack or install either. Do I need both? What else do I need?

You should probably check out this post:

http://www.atariage....62#entry2336862


And this might help too:

http://www.randomter...tml#install_vbb

Just ignore the parts about downloading the older version of batari Basic (bBWin7_64bit.zip) and the older version of VbB.

You need Visual batari Basic if you want all kinds of useful tools and features that make the whole game making process easier and more fun.

Edited by Random Terrain, Sun Aug 7, 2011 1:17 PM.


#31 pacpix OFFLINE  

pacpix

    Space Invader

  • 46 posts
  • Location:USA

Posted Tue Aug 9, 2011 11:51 AM

When you figure out how to program you need to make this!
http://www.atariage....page__hl__railz




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users