Staring at this code gave me a headache....

[KAZ]

This is the disassembly of Freeway:

http://www.neonghost.com/the-dig/source/freeway.asm

 

I got it from someone's useful link given in response to AA/IR's post.

 

And how would you fit ALL this stuff into the size of 2k? How do they transfer this data into a cart?

 

The text itself is well over 2k isn't it?

 

Staring at this stuff for 30 seconds, and I'm lucky I still remember what 2+2 is. Ouch, my brain hurts. It is such a "simple" game too.

 

Look at all that binary stuff at the bottom of the page, more pain...I can take looking at the screen for like 20 seconds, and then the pain starts

 

[ 06-06-2002: Message edited by: KAZ ]

[Cybergoth]

quote:

---

Originally posted by KAZ:

And how would you fit ALL this stuff into the size of 2k? How do they transfer this data into a cart?

---

 

Well, you can just trying to count the needed bytes.

 

- Any single instruction like TAX, INX, ROL, etc is one byte.

 

- Any instruction with a byte operand like LDA #$07, DEC $FF is two bytes.

 

- Any instruction with a word operand like STA $F000, INC $F000 is three bytes.

 

Well, there's a few exceptions like the branches (BNE, BEQ, etc) which seem to have word operands, but actually are using byte operands.

 

But all in all, your count should end somewhere ~ 2050 bytes +- 100

 

I think the source for Thrust is some 300K all typed by Thomas. Try printing it, too see how much work is in there

 

Greetings,

Manuel

[KAZ]

Wow, you know your stuff, excellent information. Just looking at this for like a minute, it looks like AA has a long road ahead of him.

 

Unless I get there first.

 

What file format does all this data need to be in to be accepted by an emulator?

Is BIN an actual format?

 

And is that same format the one you'd use if you were to burn it using an eprom burner, or something slightly different.

 

I think if people realized just how difficult it is to program the Atari 2600 or any system for that matter, they would appreciate it 5 times more.

 

My appreciation of Freeway is even strengthened by looking at this code.

[KAZ]

Before I go to bed I'm gonna ask one more question if you don't mind, this will assist me greatly!

 

What is the absolute MINIMUM code necessary for a cartridge to "load" up in a real Atari 2600?

 

How many lines in disassembly, and how many bytes does it take up.

 

And if you wanted the game to just load up, and say the words: Welcome to Atari 2600

How would the code likely look? That would be an awesome beginning exercise for me to see first hand using my emulator. A first "game" if you will.

 

[ 06-06-2002: Message edited by: KAZ ]

[KAZ]

I'll bet I need some sort of text file to BIN converter....

 

Like you'd write the code into a word pad file (doc format) and then convert it to a BIN file, and away you go??

[Thomas Jentzsch]

quote:

---

Originally posted by KAZ:

What file format does all this data need to be in to be accepted by an emulator?

Is BIN an actual format?

---

It's a simple raw format with no additional informations. So e.g. a 4K game like Pitfall! is exactly 4*1024 = 4096 bytes.

 

The assembler (DASM) will create that format for you.

 

quote

And is that same format the one you'd use if you were to burn it using an eprom burner, or something slightly different.

Yes, I think so.

[Thomas Jentzsch]

quote:

---

Originally posted by KAZ:

What is the absolute MINIMUM code necessary for a cartridge to "load" up in a real Atari 2600?

 

How many lines in disassembly, and how many bytes does it take up.

---

That's a bit hard to answer. The smallest games for the 2600 are 2k. But you don't have to use all the space.

 

The best (and very simple) example program to start with is "How to draw a Playfield".

 

quote:

---

And if you wanted the game to just load up, and say the words: Welcome to Atari 2600

How would the code likely look?

---

That's already a tough job for the 2600. This machine has no built in operating system, so everything has to be done by yourself.

 

E.g. you have to:

- define the patterns for the characters

- make them visible on the screen (that routine is called the kernel and is the most tricky thing to program)

- do all the additional framework necessary to get a stable signal to your TV (horizontal and vertical syncronisation etc.)

- ...

 

If you look into the mentioned example program, you will get an idea.

[Cassidy Nolen]

Where is the example "How to draw a playfield" on the web? I would love to do the tutorial.

 

Thanks,

Cassidy

[Cybergoth]

quote:

---

Originally posted by Cassidy:

Where is the example "How to draw a playfield" on the web? I would love to do the tutorial.

---

 

Everything is in The Dig, really. If it's not there, it doesn't exist.

 

BTW: While generally DASM is the tool to compile any 2600 source, I thought it might be better to warn you that AFAIR 'Freeway' is not compiling with DASM without tweaking it a little

 

Greetings,

Manuel

[Nukey Shay]

quote

Look at all that binary stuff at the bottom of the page, more pain...I can take looking at the screen for like 20 seconds, and then the pain starts

 

* opening shot of Quincy...

"Welcome to the wonderful world of assembly."

 

Just to backtrack for a minute--there are two types of code...assembled and disassembled.

 

Assembled code looks like raw data...just 2k (or however big the cart is) of numbers. There was once a time that due to limited system memory, a program had to be constructed...byte-by-byte. Yes, they actually had to do it this way (!!). This is no longer necessary with modern editors, and I don't suggest anyone try it (you WILL go mad).

 

Disassembled code has all those numbers translated into three-letter instructions and their arguments. Each byte has a value of 0 to 255. And each one can be one of three things: An instruction, an argument (the address or value the instruction is testing, loading, or whatever), or data.

By looking at the first one, the disassembler knows which instruction it is referring to, whether it has an argument, and how many bytes are used. It translates the instruction byte into it's three-letter Mnemonic, and tacks the argument at the end. Then skips ahead by the number of bytes used and grabs the next one for translation. Raw data is just a collection of values. A disassembler does not automatically know where these occur, however, and will attempt to translate these values as instructions. It's up to the programmer or person studying the program to keep tabs on where the data tables are.

 

But what about all that text? These lines are called "remarks" and never actually are put in the program at all. They are put into the listing by whoever is writing the program, sort of like reminders of what those lines are attemting to do. This collection of disassembled instructions and remarks is loosely known as "source code"**, and is actually preferred over just a plain assembly because of it's remarks (it's that much easier to read or figure out). The disassembled program/source code is basically just no more than a text file, and you must assemble it into a binary file that can be run.

 

But what about the data tables and things...won't the program try to "execute" these areas as well? Yes, the processor will. It's up to the programmer to make sure that the program skips over these areas, or a computer lock-up would be likely to occur when it tries to run the data as a program.

 

**"Source code" actually refers to the original labelled and remarked disassembly made by the original programmer. Since none of this exists after it is compiled into a binary file, ones of old games at the dig were actually labelled and remarked by other people (just like you and me), to better document the game for potential programmers (just like you and me).

[KAZ]

I'm taking a look at The Dig.

 

I'm still somewhat unclear where I'd put code even if I knew how to. Like a blank BIN file for example? Maybe there's a "blank 2600 template" of some kind on this dig site. I'm still investigating.

 

This "template" would have all the necessary fields in which to construct either a playfield or to move objects around.

 

hmmm, brain working 20% harder, ouch.

[Han]

This topic is giving me a heacache ...

[Thomas Jentzsch]

quote:

---

Originally posted by KAZ:

I'm still somewhat unclear where I'd put code even if I knew how to. Like a blank BIN file for example? Maybe there's a "blank 2600 template" of some kind on this dig site. I'm still investigating.

---

No, the BIN file is generated by the assembler.

 

As a human being you put your code into a text file (like when coding for Basic or C) and tell the compiler (=assembler) to use it.

 

The "How to Draw a Playfield" example is basically the empty template that you are looking for.

It's the "Hello World" program for the 2600. If you would make it even more simplier (remove all code inside ScanLoop except STA WSYNC , DEY and BNE SCANLOOP), all you would get is an empty black screen.

[KAZ]

You are approaching 1000 posts! You should do a HUGE HUGE post somewhere celebrating this!

[Nukey Shay]

That's only 8 posts in binary.

Thomas, you're still a newbie j/k

 

* dodges rocks thrown at him from everyone

 

[ 06-06-2002: Message edited by: Nukey Shay ]

[slapdash]

Kaz: sounds like you have a long way to go...

 

When you see an assembler "command" like TAX, that's only for the convenience of the programmer. To the computer that might be 05, or 3d, or ff (can you tell I'm too lazy to look it up right now?). A byte is a two-digit hexadecimal number, like ff. So, a 4K BIN file has 4096 of these numbers. So where's TAX, etc? The assembler converts them to the numbers that "TAX" etc represent.

 

Mind you, not all of that 4096 bytes are converted commands... Some of it is data, and some of it is addresses (telling the computer where to look for data, or where to jump to). If you see a source code file (text), you can see that it's not all "TAX" etc either, and the assembler knows what to do with it.

 

As to your question about minimum program, that came up on Stellalist a year or so ago. I don't have the URL for the post(s) in the archives (c.f. "laziness"), but I seem to recall that you could at least draw a stable screen with a remarkably small program (39 bytes?? that number sticks out in my head for some reason; I think it was under 100 anyway).

[Nukey Shay]

Right.

It's kind of like shorthand. Like how some people write "4" instead of "for" and "u" instead of "you". To the computer, it doesn't matter that it's language is only comprised of 1-byte instructions...because it can tell the difference. The disassembly just makes things easier to read for us humans.

BTW TAX has a value of $AA...which is 170 decimal (I wish my tax was that low).

 

"I would tax all people who stand in water!" -R.N.Gumby (standing in a creek)

[Nukey Shay]

As a matter of fact...1-letter shorthand words are three letters long in longhand.

8=ate, T=tea, etc.

 

Spooky

 

 

I8p4u -Prince

 

[ 06-08-2002: Message edited by: Nukey Shay ]

[Osbo]

now I know why used to take 1-2 years to program a game like Adventura... Just think about debugging that code... Write the code, try it, find the bugs, debug, try it again... man

 

Just my two cents

 

Osbo

 

[ 06-08-2002: Message edited by: osbo ]