Can the 2600 Output any data?

[Pioneer4x4]

I have an idea for a 2600 program but it would need to be able to output a signal. The program wouldn't be all that advanced, and I might be able to do it with the batari basic. I have NO CLUE about programming a 2600, but I have programmed in Basic from TRS80 up to Visual Basic.

[Wickeycolumbus]

Yes, the controller ports are bidirectional.

[Pioneer4x4]

Yes, the controller ports are bidirectional.

Good news! Now once I get my Harmony cart, and learn something, I might have something to contribute! Is there any specs/data anywhere on that info?

[+GroovyBee]

Is there any specs/data anywhere on that info?

 

You can get the RIOT datasheet (joystick ports are connected to Port A on it) from here :-

 

http://en.wikipedia.org/wiki/MOS_Technology_6532

 

The 2600 schematic is in the 2600's archive on here.

[Wickeycolumbus]

Here is some info more specific to the 2600 (from the Stella Programmer's manual):

 

5.0 Port A - Hand Controllers

   Port A is under full software control to be configured as an input or an output port. It can then be used to read or control various hand-head controllers with the data bits defined differently depending on the type of controller used.

   5.1 Setting for input or output

       Port A has an 8 bit wide Data Direction Register (DDR) that is written to at SWACNT (HEX 281) to set each individual pin of Port A to either input or output. The Port A pins are labeled PA0 thru PA7, and writing a "0" to a pins' DDR bit sets that pin as input, and a "1" sets it as an output. For example, writing all 0's to SWACNT (the DDR for Port A) sets PA0 thru PA7 (all 8 pins of Port A) as inputs. If F0 (11110000) were written to SWACNT then PA7, PA6, PA5 & PA4 would be outputs, and PA3, PA2, PA1 & PA0 would be inputs. 

   5.2 Inputting and Outputting

       Once the DDR has set the pins of Port A for input or output they may be read or written to by addressing SWCHA (HEX 280). 

   5.3 Joystick Controllers

       Two joysticks can be read by configuring the entire port as input and reading the data at SWCHA according to the following table:

           Data Bit	Direction	Player
           D7	right	P0
           D6	left	P0
           D5	down	P0
           D4	up	P0
           D3	right	P1
           D2	left	P1
           D1	down	P1
           D0	up	P1
           (P0 = left player, P1 = right player)

       A "0" in a data bit indicates the joystick has been moved to close that switch. All "1's" in a player's nibble indicates that joystick is not moving. 

[Pioneer4x4]

Thank you very much. Now I need to learn more. I read through the Batari Basic introductory pages, and will hopefully be able to start there. If I fail miserably, I will submit my idea to the masses, and let someone with more knowledge of Ataris to implement. What I want to do I was able to with a TRS-80 back in the day via interpreted basic, but different IO method.

 

Thanks again!

[Pioneer4x4]

Man, I suck. I did some putzing with Batari Basic today. WOW I am lost. Like I have said, I am very familiar with basic, but the 2600 intricacies are incredible. And as for my idea with output, I saw some similar posts. Basically I want to have a multiplayer/multi console game with 2 2600s linked. I know that it is a horrible first project, but if it is possible, it should actually be a simple one. I did it on a TRS-80 back in 1982 over cassette port so I have a vague idea what I want to do.

It will not be a "Arcade" game but more of a board game, so speed should not be an issue.

 

Also, what is the practial resolution of the playfield? Everything seems so limited, but then when you see a game like Starpath's The Official Frogger as an example it seems that there is so much more you can do.

[+batari]

Man, I suck. I did some putzing with Batari Basic today. WOW I am lost. Like I have said, I am very familiar with basic, but the 2600 intricacies are incredible. And as for my idea with output, I saw some similar posts. Basically I want to have a multiplayer/multi console game with 2 2600s linked. I know that it is a horrible first project, but if it is possible, it should actually be a simple one. I did it on a TRS-80 back in 1982 over cassette port so I have a vague idea what I want to do.

It will not be a "Arcade" game but more of a board game, so speed should not be an issue.

 

Also, what is the practial resolution of the playfield? Everything seems so limited, but then when you see a game like Starpath's The Official Frogger as an example it seems that there is so much more you can do.

http://www.atariage.com/forums/blog/134/entry-5561-2600-lan/

[Pioneer4x4]

http://www.atariage.com/forums/blog/134/entry-5561-2600-lan/

That is way more ambitios than what I was planning! I will need to try it out though.

[yuppicide]

My idea was to find a low powered device that when something happened in the game the thing did something.. for example, an adult game could have a vibrating sex toy. You could have something with motion such as a USB powered humping dog, or just a special light that lights up.

[tetrode kink]

Wow, batari, after reading your blog entry I have only one question: How did you keep the two machines synced to each other? The VCS timing (thus the RIOT) is crystal-controlled. Since no two crystals are absolutely identical, they would eventually drift and lose comm sync. I would think you'd need an asynchronous communication method for it to be reliable.

 

Once the kinks are worked out, how about expansion: Someone design a USB interface for the ersatz VCS "modem." Now connect it to a computer. An internet-connected computer...

 

I'm going to go now, I just blew my mind.

 

-tet

[Pioneer4x4]

YAQ (Yet another question) Can batari basic be used to send data to port? I originally asked if the hardware could, but I guess I need to know if it is possible in batari basic. Otherwise, I'll give up and offer my idea to the masses.

[+GroovyBee]

YAQ (Yet another question) Can batari basic be used to send data to port? I originally asked if the hardware could, but I guess I need to know if it is possible in batari basic. Otherwise, I'll give up and offer my idea to the masses.

 

I suspect not. However, I'm sure that if you put out a call for help somebody will write what is needed in assembler such that a batari Basic program can use it.

[+batari]

Wow, batari, after reading your blog entry I have only one question: How did you keep the two machines synced to each other? The VCS timing (thus the RIOT) is crystal-controlled. Since no two crystals are absolutely identical, they would eventually drift and lose comm sync. I would think you'd need an asynchronous communication method for it to be reliable.

 

Once the kinks are worked out, how about expansion: Someone design a USB interface for the ersatz VCS "modem." Now connect it to a computer. An internet-connected computer...

 

I'm going to go now, I just blew my mind.

 

-tet

It's been a while and I don't remember all of the details, but I think the synchronization code is right at the end of the display kernel. Anyway, the master console will then send a connection request, and waits for an ACK. The other console waits in a tight loop for the connection request and sends the ACK once it arrives. The second console waits a number of cycles before trying to read the port while the first console starts sending data after a shorter delay (the idea is to try to stagger the timing so data won't change while one console is reading.)

 

The consoles exchange data, 2 bits at a time, about once every 50 cycles or so. IIRC, the master sends 2 bytes of game data and the slave responds with one byte of data (controller data and something else I can't remember.)

 

It isn't perfect. I originally tried to just exchange controller info and collision registers but that proved to be too difficult (this is possible I think, but needs significant recoding, and would be easier for a new game instead of a hack of an existing game.)

 

Since I wanted to show something at NWCGE, I changed it such that the master simply sends nearly the entire contents of RAM to the slave over the course of 50-60 frames or so. Of course this means the slave can have incorrect data for nearly a full second at a time and it doesn't sound like it would play well, but in practice it works reasonably well.

 

However, I can't see it working over the internet or even a direct-dial modem connnection except for maybe turn-based games due to the latency, which is 2-3 orders of magnitude too slow for real-time gameplay. The 2600s don't need a particularly fast data rate (I believe my demo sends data at around 40 kbps, half-duplex) but they do need a very low latency connection. I don't know what the latency of the cable is, but if it's more than a few hundred microseconds, it's probably too slow.

YAQ (Yet another question) Can batari basic be used to send data to port? I originally asked if the hardware could, but I guess I need to know if it is possible in batari basic. Otherwise, I'll give up and offer my idea to the masses.

Sure, it could work in bB. It would be a matter of setting SWACNT appropriately and placing the code in vblank and doing reads and writes of SWCHA. Since the timing in bB couldn't be controlled by cycle counting as well, I'd use WSYNCs to keep the consoles synchronized. I could look into demo code someday - I would guess that you could exchange one byte each way if it were done carefully.

[Pioneer4x4]

Sure, it could work in bB. It would be a matter of setting SWACNT appropriately and placing the code in vblank and doing reads and writes of SWCHA. Since the timing in bB couldn't be controlled by cycle counting as well, I'd use WSYNCs to keep the consoles synchronized. I could look into demo code someday - I would guess that you could exchange one byte each way if it were done carefully.

OK I PM you about my idea?

[tetrode kink]

OK thanks batari, if I'm reading it right, what you described is asynchronous, with all the sends and waits for ACK, etc. I thought it sounded like synchronous in your blog, but I'm no expert on comms (not even amateur, for that matter...).

 

But wow, that it worked at all is really exciting! OK, so it might not work over the internet for real-time play, so turn-based it is. That still leaves room for a game of Battleship!

 

Now, how about a nice game of chess (why does that sound familiar...)? Ooh, modify Atari's "Chess" to use VCSComm (I just coined that; you're welcome!) for two-player "action!" How about that; many ways of playing chess on the internet but I want a way to do it on the VCS...

 

@Pioneer4x4, I would think that due to the critical timing, you'd have to do the comms in ASM, which is fine since batariBasic lets you bust out the ASM at your whim. You seem to want to keep your idea under wraps for now, but I am curious as to what it is. Whatever, I wish you luck on your project!

 

-tet

[+batari]

OK thanks batari, if I'm reading it right, what you described is asynchronous, with all the sends and waits for ACK, etc. I thought it sounded like synchronous in your blog, but I'm no expert on comms (not even amateur, for that matter...).

Yes, it's asynchronous, but now that you mention it, it might be better and faster as a semi-synchronous protocol. That is, we still do the connection request and ACK, but after the request, we one of the lines becomes the clock. So once comms are established, the slave simply waits for the clock to go high and reads the data after a short delay to eliminate possible glitches.

 

Maybe this could allow for a 3-bit channel which could send a byte (with parity) in 3 cycles of the clock and send enough data per frame to do something more meaningful.

[+selgus]

Wow, batari, after reading your blog entry I have only one question: How did you keep the two machines synced to each other? The VCS timing (thus the RIOT) is crystal-controlled. Since no two crystals are absolutely identical, they would eventually drift and lose comm sync. I would think you'd need an asynchronous communication method for it to be reliable.

At Catapult, when we did the XBAND modem, we needed to keep two free-running Genesis consoles in sync. The approach we took was to sync the VBLANKs. We would exchange small amounts of sync information every 1/60th of a second. Now, because no two consoles are exactly alike, the consoles would drift out of sync. We used the fact that you could switch the Genesis in and out of interlaced mode, thereby changing the time spent in the VBLANK. We would use this fact to have a sliding window that kept the two consoles in sync, by adjusting when we would switch in and out of interlace.

 

So the algorithm keeps the consoles in sync from the standpoint of the data they exchange, but the consoles are never exactly cycle in sync.

 

--Selgus

[A.J. Franzman]

Now, how about a nice game of chess (why does that sound familiar...)? Ooh, modify Atari's "Chess" to use VCSComm (I just coined that; you're welcome!) for two-player "action!" How about that; many ways of playing chess on the internet but I want a way to do it on the VCS...

If you start from an existing game, it should be the prototype Computer Chess, not the released Video Chess. As I understand it, Atari refused to spring for 8K carts for the game, so the game was stripped down by removing features (like the onscreen alphanumeric notation) to make it fit in 4K.

[Wickeycolumbus]

Now, how about a nice game of chess (why does that sound familiar...)? Ooh, modify Atari's "Chess" to use VCSComm (I just coined that; you're welcome!) for two-player "action!" How about that; many ways of playing chess on the internet but I want a way to do it on the VCS...

If you start from an existing game, it should be the prototype Computer Chess, not the released Video Chess. As I understand it, Atari refused to spring for 8K carts for the game, so the game was stripped down by removing features (like the onscreen alphanumeric notation) to make it fit in 4K.

 

Actually, both versions are 4K

[A.J. Franzman]

Actually, both versions are 4K

OK, so what's this "6K" version that Tempest mentions on Atariprotos.com?

 

After much research it has been concluded that Computer Chess is an early version of the program that eventually become Video Chess. Computer Chess was the first 2600 game to break the 4K barrier, weighing in at a hefty 6K! Rather than go through the expense of releasing Computer Chess as a bankwitched cart, Atari decided to strip it down (removing some of the graphical extras) so it could fit into a regular 4K cart. Still, the production end label found on the prototype cart makes me wonder just how close Computer Chess was to being released in its 6K form.

Does this mean that the version of Computer Chess that we have, is not the same one that's on the cart with the production end label? I didn't see any mention on Atariprotos that the two known protos are different from one another.

 

Or is the problem perhaps that the version in Rom Hunter's collection is an underdump? Or is it that the board-only version actually didn't need to be on a bankswitching board? Tempest?

Edited March 2, 2010 by A.J. Franzman

[Wickeycolumbus]

Actually, both versions are 4K

OK, so what's this "6K" version that Tempest mentions on Atariprotos.com?

 

After much research it has been concluded that Computer Chess is an early version of the program that eventually become Video Chess. Computer Chess was the first 2600 game to break the 4K barrier, weighing in at a hefty 6K! Rather than go through the expense of releasing Computer Chess as a bankwitched cart, Atari decided to strip it down (removing some of the graphical extras) so it could fit into a regular 4K cart. Still, the production end label found on the prototype cart makes me wonder just how close Computer Chess was to being released in its 6K form.

Does this mean that the version of Computer Chess that we have, is not the same one that's on the cart with the production end label? I didn't see any mention on Atariprotos that the two known protos are different from one another.

 

Or is the problem perhaps that the version in Rom Hunter's collection is an underdump? Or is it that the board-only version actually didn't need to be on a bankswitching board? Tempest?

 

The PCB only prototype pictured on Atariprotos is in fact 4k (two 2716 EPROMs). If I recall correctly, the ROM floating around is from the PCB only proto, not the one in the computer chess shell. While it's certainly possible that the other one is 6K, I doubt it is. According to CPUWIZ, '6K' was a typo:

 

http://www.atariage.com/forums/topic/142284-computer-chess/