A Game Idea.

[KAZ]

Ok, an update on my "progress"...

 

I copied your partial code into a text file...

 

I named it: mycode

 

Then I went:

 

dasm mycode.txt -f3 -mycode.bin

 

It didn't seem to do anything.

 

what is asm? Maybe I have to convert my text file into an asm first?

[Nukey Shay]

I think you have to rename the file to have an .asm extension, or the assembler won't recognise it. As Thomas pointed out, it also won't recognise it if you used any type of formatting (i.e. Wordpad-created text...though Wordpad does have an option to save as plain text).

 

rename mycode.txt mycode.asm

 

Then try Dasm.

[KAZ]

Ok, I will try that...I didn't think it would be that simple...

 

Also I was going to ask if someone could provide me a text file of the playfield....in TXT extension.

 

That way I could have a more complete code to try than that partial one.

 

I will keep you guys up to date on my progress.

[Nukey Shay]

It doesn't have to be a .txt extension to open it. When you double-click, Windows will ask you what program you want to use...just scroll down and pick Notepad (though Windows will probably kick you into Wordpad due to the large file size). Or, you can just flip to Dos and type edit filename.asm

[KAZ]

I was doing the wrong command....I'm following a previous post by you Nukey Shay, and am going to try this:

 

asm mycode.asm -f3 -oname:mycode.bin

 

 

I knew that dasm wouldn't teach me how to code, but I wanted to know this step first before starting on the rest.

 

Like working in kinda a reverse order from bin file....

 

And I realize that learning the machine language WILL take months, but I was begging to understand just this most simple of tasks....about using text files, and dasm, and making bin files...

 

Ok, gonna try this one now cross your fingers!

[KAZ]

asm mycode.asm -f3 -oname:mycode.bin

 

this didn't do anything with my code, it didn't make a bin file

 

dasm mycode.asm -f3 -oname:mycode.bin

 

this also didn't do anything

 

hmm.

 

Maybe my code is wrong, and the dasm doesn't recognize that partial code. I'm looking around the net for a file to try dasm on...like a text file with JUST code in it.

[NE146]

Kaz.. take the WHOLE thing out of

 

http://www.neonghost.com/the-dig/dox/nbtia_1_asm.txt

 

If DASM is like any compiler, it will ignore all the comments. Don't worry about it. But obviously you need the entire thing, not the little teeny snippet I posted above. That was just to give you an idea.

 

Again, you need the whole thing. Don't worry about taking out the comments. In other words, just highlight the whole darn thing and paste it into notepad, and save it. That should do the trick.

 

Try that out and let us know how it goes! (I'm pretty interested too)

[Nukey Shay]

The problem with your snip is that the Start tag is missing...so the assembler doesn't know where the code begins.

[Nukey Shay]

Next commands:

GOSUB X and RETURN

 

GOSUB works kind of like a GOTO does, except when it encounters a RETURN, the program zips back to where it was called from. X specifies the line number, and unlike other Basics, you CAN use a variable to specify the line (although this practice is discouraged).

 

How is this useful? For one thing, you can have one section of the program handle many things. Consider this:

 

0 GRAPHICS 8 : COLOR =1

10 SETCOLOR 2,0,0 : SETCOLOR 1,0,15

20 X=INT(RND(0)*301)+9

30 Y=INT(RND(0)*152)+4

40 PLOT X,Y-4

50 DRAWTO X+8,Y-1

60 DRAWTO X-9,Y-1

70 DRAWTO X-8,Y+4

80 DRAWTO X,Y-4

 

This program draws a five-pointed star on a highres screen at a random location. It only does it at the beginning of the program. If I were to need another star drawn later on in the program, I would have to code all those lines again. But not if I used GOSUB. Add these lines:

 

15 GOTO 100

90 RETURN

100 GOSUB 20

 

Don't worry, Basic will put them in the correct spots. Now, whenever I need a star drawn, I would simply GOSUB 20 from anywhere in the program. Add this to try it...

 

110 GOSUB 20

 

Bingo, now you've got two stars. Now try a whole bunch of them by changing line 100 and adding line 120...

 

100 FOR I=1 TO 30

120 NEXT I

 

* hums

"Starry starry night..." - Don McLean

[KAZ]

That's amazing how the dasm can ignore all those extra comments in that document, this I will HAVE to see for myself.

 

I still don't understand Atari basic, do I just start writing code like:

 

10 (something)

20 (something)

 

putting this code into a text file, and then the dasm knows how to deal with it to make a binary (bin) file?

 

Thanks for being patient with me...

[NE146]

The problem with your snip is that the Start tag is missing...so the assembler doesn't know where the code begins

 

Ok that's been fixed

 

But it doesn't matter! That snippet wasn't supposed to do ANYTHING but just show a small picture of what the unassembled code for a typical 2600 program looks like..as it seems to me that is some of the confusion here.

 

Kaz, ignore that snippet dude. Just go to that source code on that page I linked to. That's it.

 

That's amazing how the dasm can ignore all those extra comments in that document, this I will HAVE to see for myself

 

Kaz, there's nothing to it really. All it does is look for the ";" (the semicolons) then it disregards everything AFTER THAT up until a carriage return. That's all it does really. It's a piece of cake. But again, this is nothing you have to worry about.

 

example:

STA WSYNC ; everything typed here is ignored. I can type "I like Menudo" for all it matters.

 

I still don't understand Atari basic, do I just start writing code like:  

10 (something)  

20 (something)  

putting this code into a text file, and then the dasm knows how to deal with it to make a binary (bin) file?

 

Be careful not to get confused with the ATARI BASIC commands these guys are putting up above as examples to familiarize yourself with programming concepts, and with the assembly source code for the 2600 itself.

 

Now that I think of it, maybe I just confused things more here by joining in... I'll leave it up to the experts here from this point.

 

But again, that page I pointed you to (The Dig) has lots of 2600 source code. You should just be able to just take that stuff, paste it into a .txt file (renaming it as necessary), then compile it. And poop out a playable .bin. At least this is my understanding. Ok I'll butt out now

[Thomas Jentzsch]

That's amazing how the dasm can ignore all those extra comments in that document, this I will HAVE to see for myself.

 

I still don't understand Atari basic, do I just start writing code like:

 

10 (something)

20 (something)

 

putting this code into a text file, and then the dasm knows how to deal with it to make a binary (bin) file?

Don't mix BASIC with Assembler!

 

The line numbers are typical for old BASIC interpreters/compilers. DASM is an Assembler so he needs completely different input. The code looks like the code in the "How to draw a Playfield" example.

• Lines beginning with ";" are comments, also everything behind ";"

[*]Lines that are not indended are lables (marks where the code jumps to), the usually habe a describing name (and optionally end with ":")

[*]Lines that are indended contain either the code (mnemonic follows) or data (".byte" follows).

There a some exceptions to the rule, but that shouldn't bother you now.

 

There are two columns that make the code:

• The first contains the mnemonics (easy to remember 3 letter abrevations, e.g. LDA = LoaD Accumulator; STA = STore Accumulator etc.)

[*]The second column contains the operators (LDA #$81 = load $81 into accumulator, LDA $81 = load the contents of RAM address $81 (into accumulator etc.). Not that all numbes are hexadecimal (base 16) numbers ($81 = 8*16 + 1 = 129).

• Instead of writing LDA $81, you can give the address a name (e.g. "Count") and then use it like a variable in BASIC and write LDA Count. That makes the code much more readable.

 

Thanks for being patient with me...

I do my very best!

But you should definitely start reading some Assembler docs now.

[KAZ]

ok, here's an update:

 

I went to that "how to draw a playfield site", and did a "select all"

I then chose COPY. I went to a totally blank textfile named: mycode.txt

I pasted it all there.

 

I renamed mycode.txt to mycode.asm

 

I copied mycode.asm into the directory containing my dasm program files...

 

I went into ms-dos and did this:

 

C:WINDOWSDesktopdasm>dasm mycode.asm -f3 -oname:mycode.bin

DASM V2.02, ©Copyright 1988 Matthew Dillon, All Rights Reserved

unable to [re]open 'name:mycode.bin'

 

perhaps my command is wrong:

dasm mycode.asm -f3 -oname:mycode.bin

 

 

 

What am I doing wrong? Any suggestions?

 

This playfield code supposedly will scroll a hello when you play it in an emulator.

[Thomas Jentzsch]

perhaps my command is wrong:

dasm mycode.asm -f3 -oname:mycode.bin

The correct command is: dasm mycode.asm -f3 -omycode.bin

(I think you got confused by the ram: prefix in the docs-example, just ignore that).

 

You are very close now.

[KAZ]

Well excellent, it DID something! We have progress!

 

I used the new command you gave Thomas, and this is what happened:

 

C:WINDOWSDesktopdasm>dasm mycode.asm -f3 -omycode.bin

DASM V2.02, ©Copyright 1988 Matthew Dillon, All Rights Reserved

unable to open vcs.h

unable to open vcs.h

unable to open vcs.h

Error: source is not resolvable.

re-run with verbose option 2 or higher to determine problem

 

So it created the BIN file, and I was getting excited to see this awesome HELLO screen on it.....

 

I ran it through my z26 emulator and.....a black screen and some garbled mess on the very top.

 

 

It was virtually the SAME garbled mess that I saw when I messed with the bin file of Freeway, in itself that is pretty goofy.

 

 

So I am getting farther than I was, but maybe the command still isn't quite right, or the code wrong, or the emulator I'm using is wrong.

 

It could be a bunch of things.

 

I am starting to understand about the ; semicolon thing, as far as how the dasm doesn't look at some words at all.

 

So I am still open to more suggestions, as I haven't QUITE gotten this hello program (playfield) to boot up properly.

 

I DO understand this process better, and this is helping me a TON.

 

I actually read through the playfield analysis on that site, and I understood maybe like 3% of what was said.

 

VSYNC this, and wasted clock cycles that...

 

So this game isn't even close to over....once I get this hello program working we're in business. Then I'll study the commands intensely, since I know how to make a bin file from a text file.

 

 

Also, if it isn't too much trouble, can someone explain what dasm IS exactly? What is it doing behind the scenes? And do I really want to know?

Is it making the text file into 1's and 0's? That's what binary means to me right now...maybe I'm not far off.

[KAZ]

Sorry for two posts back to back like this, but I was wondering if it mattered what ORDER a code goes in....

 

Like what if I took that text file, and cut it from the middle down to the bottom, and stuck that on top, and then dasm it?

 

I haven't gotten the first to work yet (till someone suggests a fix for me), but I was curious about this important point.

 

If ORDER doesn't matter, then that does allow alot of "freedom" to put code wherever. And I'd probably next ask what would happen if a code line was copied twice (maybe by accident).

[Nukey Shay]

C:WINDOWSDesktopdasm>dasm mycode.asm -f3 -omycode.bin  

DASM V2.02, ©Copyright 1988 Matthew Dillon, All Rights Reserved  

unable to open vcs.h  

unable to open vcs.h  

unable to open vcs.h  

Error: source is not resolvable.  

re-run with verbose option 2 or higher to determine problem

 

The problem is that the assembler isn't "seeing" the VCS.H file (isn't this included with Dasm??). This file contains all the addresses used for the registers used in VCS binary code. Dasm needs to cross-reference these if the source code calls them by name. You can grab it here:

http://buerger.metropolis.de/estolberg/texts/vcs.h

Put it in the same folder that your source code (mycode.asm) is in.

Without it, the binary program will end up with the wrong addresses in it.

 

Also, if it isn't too much trouble, can someone explain what dasm IS exactly? What is it doing behind the scenes? And do I really want to know?  

Is it making the text file into 1's and 0's? That's what binary means to me right now...maybe I'm not far off.

That is exactly correct. Like somebody interpreting a foreign language for you, the assembler is looking at the opcodes in the source file (like LDA #$FF) and translating it into binary code (in this case, it would be two bytes with values of $A9 and $FF). Your attempt would have worked, except the assembler couldn't figure out what some of the addresses were (since VCS.H is missing).

[Nukey Shay]

Like what if I took that text file, and cut it from the middle down to the bottom, and stuck that on top, and then dasm it?

 

I would be very surprised if something like that was able to compile correctly. In the source code, many things are usually defined up at the beginning of the source code. Since the assembler reads through it twice as it is building the binary file, some things it might be able to figure out on it's own. Other things would still be unknown to it (and therefore left blank). In Basic terms, it might go something like this...

 

A=B+C

B=C+1

C=5

 

...pass 1...

On the first line, it won't be able to figure out A (since it doesn't know what B and C are). So it skips it.

On the second line, it won't be able to figure out B (since it STILL doesn't know what C is)

On the last line, it finally gets a value for C.

---end of pass 1---

 

...pass 2...

On the first line, it knows the value for C...but not B. Skip it.

On the second line, it gets the value for B (since it knows C's value from pass 1).

The third line is already known.

---end of pass 2---

 

There's your two passes. And the value for A is still unknown (so the blank bytes that the assembler used as placeholders are still in the binary file!)

[Nukey Shay]

That's amazing how the dasm can ignore all those extra comments in that document, this I will HAVE to see for myself.

It's not really all that amazing. Is like if you are reading a book, and whenever you see the word "the" you ignore the rest and turn the page. The assembler does the same thing whenever it runs across a semicolon in the source code.

 

; ALL THIS TEXT IS IGNORED

 

Adding remarks is the best way of keeping track of what each part of the program is doing. Although it's not as essential, you can also make remarks in a Basic program by using the REM command...like this:

 

10 REM PROGRAM TO EDIT PLAYER SPRITES

 

The reason it's not as essential in Basic programming is because you don't get lost as easy.

Oops...there's another command for you Basic programmers looking in. REM is just a way to document parts of your program. Anything that follows that command is ignored by the computer. You can also add remarks to lines that contain statements...

 

10 PRINT "THIS IS NOT IGNORED" : REM THIS IS IGNORED

20 REM THIS IS IGNORED : PRINT "OOPS...SO IS THIS BECAUSE IT'S AFTER A REM"

 

Line 20 shows that you need to be careful to put the rem AFTER any commands that you want done...less they be ignored.

[Nukey Shay]

Oh, by now some of your budding Basic programs might be getting large...sometimes too big to enter in one go.

 

SAVING and LOADING programs

Saving your Basic programs can be done on an actual Atari computer by booting up Dos, typing in your program (or part of it), and typing this to write it to the floppy disk:

SAVE"D:filename.ext"

You can use any numbers or letters as part of the filename and extension, and can only be a maximum of 8 characters for the filename, and three for the extension. No spaces or other characters allowed, and the filename MUST begin with an alphabetic letter. To reload the program later on, you would type this:

LOAD"D:filename.ext"

 

If you are using the Atari800Win emulator, those commands still work. However, I suggest writing to your PC's hard drive instead. Use alt-h to pick the hard drive folder you want to work with, and follow the saving/loading instructions above...substituting "D:" with "H:".

SAVE"H:filename.ext"

LOAD"H:filename.ext"

You can also work with multiple drives/folders as well. Simply call them by number.

SAVE"H5:filename.ext" would write the program to the fifth folder selected in the alt-h screen.

 

Speedy tip!!!

You notice all these programs that I've been typing? Here's a way to paste them into Atari800Win using the hard drive folder...

-Highlight the program and copy/paste it into Notepad.

-IMPORTANT...at the end of each line, paste this character ›

-Save the text to the folder, and type this in Atari800Win...

ENTER"H:filename.ext"

That's it! You can save it the normal way from there.

 

Note on that special character above...No, it's not a greater-than sign. It's another character created by CHR$(155)...which is Atari's carriage return character. It will appear as a small box when you paste it into Notepad.

[KAZ]

vcs-h was NOT in the directory...I thought it would be...

 

no matter, I've seen this thing before, and I'll grab it from where you stated it was...

 

I may yet get this right!

[KAZ]

Awesome!! It totally worked this time with the addition of that vcs.h file.

 

Without vcs.h file it created a BIN file that was only 37 bytes

With the vcs.h file it created a BIN file that is 4 KB

 

And I had a feeling even when I saw the size of that file, that it would work.

 

A pleasant scrolling HELLO on two sides in different colors scrolled down the screen!

 

The game has begun!

 

...now the real challenge begins, making sense of all that nonsense code!

 

 

But, hypothetically, I know how to make that bin file, if I just had the right code to write in there. 4-5 months maybe I'll understand a little bit of code!

[Nukey Shay]

It's not really nonsense...computer's are very stupid.

Getting them to understand what you want them to do...that's the hard part.

 

"That's why I use a twenty-pound sledge." -Tim Allen

[Thomas Jentzsch]

Congratulations KAZ!

 

You definitely do not look like a guy that gives up to soon. That's already one major quality needed when programming in Assembler and especially for the 2600.

[KAZ]

Hey thanks for the words of encouragement.

 

Yeah, the whole thing is that I really do want to learn this stuff, I want to make a simple game sometime...

 

Even this dasm stuff was challenging...I had to work in ms-dos, something I don't do often except when playing ms dos emulators. But they have front ends for that kind of stuff.

 

 

It is a mystery to me how Atari basic fits into all this...

is it just a teaching tool that you guys have thought up to help with the whole concept of programming?

I think you said before that the:

10

20

30

stuff can't be put into a text file, and dasm

 

 

Here's the point I see myself at...I use analogies all the time.

 

Let's say I want to compose music for the piano..

At this point I know what the piano looks like, I know how to sit at the bench (dasm stuff and ms dos), I've even played a couple notes on it.

 

And I say that if I just had the right code in my head that I could make a game...that's exactly like saying that if I had the right music in my head, I could write it down on a sheet of paper.

 

I don't want to be a hassle...but maybe you guys could assist me more...like write some code, with some comments, and I'll look at it and dasm it....then you could make progressively harder "lessons" for me to look at. Just an idea.

 

It is too bad that code has to be in order, that's gonna make this really hard, I was hoping it would be like cooking...it doesn't matter when you add the ingredients, it just all gets mixed together by the assembly.

 

If it DOES need to go in order, maybe I should establish a rock solid code base, like the playfield example, and just always start out the first 10 lines of code with the same thing....