WIP ADVENT2600: A text adventure for the vanilla Atari 2600

[Kevin McGrath]

First I'd like to state that I'm new to programming the Atari 2600, this is my first "kernel" and there's a lot of tricks I still have to learn about the system.  While I was trying to figure out how to render a pirate ship for another game idea, I stumbled upon this idea for displaying a full screen of text and wondered if I could use it to make a port of Colossal Cave Adventure for the Atari 2600 from 1977.  In other words, can you make a workable text display that is good enough to present the classic text adventure game on the original Atari 2600 hardware in a 4KB cartridge?

 

OK, in this case, "full screen of text" is eight lines of ten characters, or 80 characters total.  That's not a whole lot, is it?  But is it enough to make a playable version of the classic ADVENT?

 

I don't in any way wish to belittle Warren Robinett's incredible achievement with the 1980 Atari game "Adventure".  I think the choices Mr. Robinett made back then had been the right ones given the systems limited capabilities.  I still don't know if it's even possible to put 30+ room descriptions, items and enemies into a 4KB ROM like he managed to do.  As they say, a picture is worth a thousand words, but a thousand words wouldn't fit into 4KB without compression.  So even if he could have displayed enough text, utilizing graphics would give you a richer more enjoyable game.

 

To me, this is more about "can it be done" than "should it be done".

 

I have read about the 32 character text display demo and the 36 character demo, both are really impressive!  However, my understanding is that those demos use pre-generated displays from ROM and DPC/DPC+/ARM features not found on vanilla (earliest) cartridges.  I was curious to see if the Atari 2600, without any additional hardware except for a standard 4KB ROM cartridge, could display a large enough dynamic text screen for a playable version of ADVENT.

 

Kernel Features:

• Designed to work on original 2600 hardware with non-bankswitched 4KB ROM cart (like Adventure)
• Eight lines of text with ten characters per line
• Each text line can have different background and foreground colors (nice for text menus)
• Each missile can be positioned on any text line (0 - 7), with any X (0 - 159)
• Font used can have up to 51 3x5 pixel glyphs, enough for uppercase only English text, digits and some symbols
• 80 byte/character text buffer, unchanged between frames to allow for dynamic text displays

 

Kernel Limitations:

• Needs ~97 bytes of RAM, brutal given there's only 128 bytes available
• Two copies of the font is required, one normal and one bit reversed, consuming 512 bytes of ROM
• The kernel code is long, currently at 1,285 bytes, making this a challenge for a 2K ROM game
• The font and final display is beyond crude, essentially a 40x48 pixel display

 

Aside from Colossal Cave Adventure, this kernel may be useful for other games.  For example, since the display is 10 characters by 8 lines, you could show a full 8x8 game board and use the 2x8 characters on the side of the display to show previous moves or moves being considered by the AI.  Might be good for checkers/draughts or chess, or card games like poker or bridge.  Text menus are also really easy with this kernel, of course.

 

Big "To Do" Tasks:

• Action/verb input: left / right to change available commands then button to select
• Room description text scrolling: up / down should let the player scroll the description
• Inventory: Probably just a bit within a single byte. Risk: commands change depending
• Real-time text decompression: 6-bit ASCII? Arithmetic/Huffman coding? Risk: scrolling!
• Reduced story: How much ROM left over, can we fit a fun playable adventure in 4KB?
• Setup a github repository for the source
• Get real hardware and a cartridge emulator for testing on the real thing

 

GIF showing how the first room description from Colossal Cave Adventure might look:

 

 

Your choice of background and foreground colors per line of text:

 

 

Which make joystick selectable text menus really easy:

 

 

Demo Video

 

 

 

 

advent2600.bin ADVENT2600_Src.zip

Edited June 27, 2020 by Kevin McGrath
Trying to make a clearer post

[s0c7]

I don't see why not.  You might be required to do a subset, but you should be able to get a fully playable game out of it.

 

Have a look at Dark Mage to see a 4k example.

 

https://atariage.com/software_list.php?SystemID=2600&searchValue=dark+mage&Submit2=Begin+Search&searchCompanyID=ALL&searchRegion=N&searchTvFormat=ALL&searchRarity=ALL&searchLabel=&orderByValue=Ascending&recordsPerPage=100&searchType=NORMAL

 

Edit: Didn't realize the final version was 8k. Here's the 4k beta.

Dark Mage - Beta (1997) (Hozer Video Games, Greg Troutman) (Prototype).bin

Edited June 27, 2020 by s0c7

[+splendidnut]

Very cool.

 

For the record, there was a 32 char, 5 row kernel done in 4k (no extra RAM/ROM/DPC/ARM):

 

 

[+splendidnut]

I do like that yours has lots of color options

[Kevin McGrath]

32 minutes ago, s0c7 said:

Have a look at Dark Mage to see a 4k example.

I had not checked out Dark Mage!  Thanks for the tip, it looks pretty cool and probably does a lot of things I hadn't thought of yet.

[Kevin McGrath]

27 minutes ago, splendidnut said:

Very cool.

 

For the record, there was a 32 char, 5 row kernel done in 4k (no extra RAM/ROM/DPC/ARM):

 

 

I did look at that forum topic, but it was my understanding (perhaps incorrect) that it's displaying text strings from ROM.  Wouldn't a 32x5 character display consume 160 bytes of text buffer in RAM?  I don't see how you could do a completely dynamic 32x5 character display and still fit in RAM, which is why I went with just using the playfield for a 10x8 character display (80 bytes).  The whole text buffer is in RAM so you can do whatever you want with it between frames.

[SoundGammon]

Stellar Track is basically a text game, check it out!

[+splendidnut]

Ah... ok... I misunderstood your original statement:

2 hours ago, Kevin McGrath said:

However, my understanding is that those demos use pre-generated displays from ROM and DPC/DPC+/ARM features not found on vanilla (earliest) cartridges.

Made it sound like you didn't see the demo that was done with a "vanilla" cart in 4k.
 

----

 

Though... There's probably a way to make that 32 char kernel a bit more dynamic...

[Kevin McGrath]

30 minutes ago, splendidnut said:

Ah... ok... I misunderstood your original statement:

Made it sound like you didn't see the demo that was done with a "vanilla" cart in 4k.

Sorry, my bad, I don't think I was very clear on what this kernel does.  It renders text from a text frame buffer stored in RAM on the fly during visible screen time.  By this I mean that every character displayed on the screen is represented as a single byte in RAM.

 

With that kind of set up you can do anything the next generation of game consoles did, which all had character based RAM buffers (i.e. one byte points to one 8x8 pixel character).

 

This kernel uses one byte in RAM to point to one of 51 possible 4x5 pixel characters.  That "text frame buffer" can be changed on the fly to display any kind of text screen desired.

 

The text display kernels I researched all seemed to work off of pointing to a binary blob in ROM which gets rasterized out.  You might be able to change an entire line of text to another line of text in ROM, but you can't change each individual character where as with my kernel you can.

 

There's a lot of 2600 games out there though and I haven't seen them all by a long shot, so there could easily be a game that does exactly what I'm currently doing.  I'll need to dig deeper.
 

[Mr SQL]

3 hours ago, Kevin McGrath said:

Sorry, my bad, I don't think I was very clear on what this kernel does.  It renders text from a text frame buffer stored in RAM on the fly during visible screen time.  By this I mean that every character displayed on the screen is represented as a single byte in RAM.

 

With that kind of set up you can do anything the next generation of game consoles did, which all had character based RAM buffers (i.e. one byte points to one 8x8 pixel character).

 

This kernel uses one byte in RAM to point to one of 51 possible 4x5 pixel characters.  That "text frame buffer" can be changed on the fly to display any kind of text screen desired.

 

The text display kernels I researched all seemed to work off of pointing to a binary blob in ROM which gets rasterized out.  You might be able to change an entire line of text to another line of text in ROM, but you can't change each individual character where as with my kernel you can.

 

There's a lot of 2600 games out there though and I haven't seen them all by a long shot, so there could easily be a game that does exactly what I'm currently doing.  I'll need to dig deeper.
 

This is very cool! You've created a programmable character set like the VIC-20 that reads ASCII, looking forward to the adventure game!  

 

The one in Dark mage is similar but does not have the programmable color.

 

Dark mage got 12 characters across dynamically with a screen buffer by using the SuperCharger for extra RAM - it's a 6K format but you can turn it to RAM. 

 

Lots of potential for cool games with this framework! 

 

6 hours ago, Kevin McGrath said:

 

[+splendidnut]

10 hours ago, Kevin McGrath said:

Sorry, my bad, I don't think I was very clear on what this kernel does.  It renders text from a text frame buffer stored in RAM on the fly during visible screen time.  By this I mean that every character displayed on the screen is represented as a single byte in RAM.

 

  . . . snip . . .

Yup, I understood all that when I read the first post. I found the phrasing of the statement about 32 character kernels requiring DPC/DPC+/ARM to be a bit misleading.  It's my fault for not articulating that better, earlier.  That's what I get for posting when tired.  My apologies for the confusion...

 

That description will be really helpful for others.  This is a nice simple, nifty kernel for displaying a good amount of text.  It's dynamic nature is nice and allows a multitude of 'text-mode' style games.

 

It'll be interesting to see how this develops.

[Kevin McGrath]

11 hours ago, Mr SQL said:

This is very cool! You've created a programmable character set like the VIC-20 that reads ASCII, looking forward to the adventure game!  

 

The one in Dark mage is similar but does not have the programmable color.

 

Dark mage got 12 characters across dynamically with a screen buffer by using the SuperCharger for extra RAM - it's a 6K format but you can turn it to RAM. 

 

Lots of potential for cool games with this framework! 

 

 

Yes!  Thank you!  I really need to figure out a better way to explain how it works, I did a terrible job in my initial post I think.

 

The RAM text frame buffer actually contains offsets into the font, instead of ASCII.  In the demo source I put a function that converts and "prints" an ASCII string anywhere within the frame buffer.  There's just not enough CPU cycles to be able to convert each ASCII character into a font offset, so I diverted that step into the overscan/vblank time and just use font offsets in the kernel.

 

That also leads to an interesting trick though... You can put any offset from 0 - 255 for each character and the kernel will just blindly display those pixels.  So, you could have an scrolling/animated glyph just by adding one to the font offset for that byte in the text frame buffer.

 

And of course the glyphs aren't required to be latin script characters, they could be tiny monochrome 4x5 pixel graphics like game pieces.  I'm thinking about making a truncated font and a 2KB ROM demo.  I don't think I could fit chess in 2K with the size of this kernel, but maybe a card game like poker.  Educational games would be a breeze.

 

I'm loving the challenge of this machine.  ?

[Mr SQL]

4 hours ago, Kevin McGrath said:

Yes!  Thank you!  I really need to figure out a better way to explain how it works, I did a terrible job in my initial post I think.

 

The RAM text frame buffer actually contains offsets into the font, instead of ASCII.  In the demo source I put a function that converts and "prints" an ASCII string anywhere within the frame buffer.  There's just not enough CPU cycles to be able to convert each ASCII character into a font offset, so I diverted that step into the overscan/vblank time and just use font offsets in the kernel.

 

That also leads to an interesting trick though... You can put any offset from 0 - 255 for each character and the kernel will just blindly display those pixels.  So, you could have an scrolling/animated glyph just by adding one to the font offset for that byte in the text frame buffer.

 

And of course the glyphs aren't required to be latin script characters, they could be tiny monochrome 4x5 pixel graphics like game pieces.  I'm thinking about making a truncated font and a 2KB ROM demo.  I don't think I could fit chess in 2K with the size of this kernel, but maybe a card game like poker.  Educational games would be a breeze.

 

I'm loving the challenge of this machine.  ?

X2!

 

I really like the way that function works for an adventure game, because the effect is the text lackadaisically scrolls across the screen at 300 baud just as if you were playing Colossal Cave adventure over a Teletype or terminal emulator 

 

With close to 3K free and dynamic ASCII, you've got room to make a really awesome 4K text adventure game with the colorful text transitions and animated glyphs! 

 

[+Pat Brady]

On 6/26/2020 at 6:35 PM, Kevin McGrath said:

To me, this is more about "can it be done" than "should it be done".

Welcome to AtariAge, Kevin. I think you are going to fit in here.

[+Andrew Davie]

12 hours ago, Kevin McGrath said:

I don't think I could fit chess in 2K with the size of this kernel, but maybe a card game like poker.

 

Would seriously love to see what you can come up with regarding a chessboard display.

Forget about actual gameplay - just a board display would be super!

 

[Kevin McGrath]

13 hours ago, Andrew Davie said:

 

Would seriously love to see what you can come up with regarding a chessboard display.

Forget about actual gameplay - just a board display would be super!

 

Challenge accepted!

 

OK, of course there's a lot of interesting issues trying to do chess with this kernel, not the least of which is that I'm a horrible pixel artist (aka not an artist).  I can do evil and use the player sprites and missiles for the board colors and place the playfield graphics in front of the board (thank you hardware!), but coming up with recognizable black and white pieces is a bit beyond my skill set.

 

I mean, there's one color and transparency.  How do you "outline" the black pieces when you've only got a 4x5 glyph and one color to work with?

 

I've attached a screenshot of what I came up with so far, but I've got timing issues somewhere so I'm sure this won't run correctly on hardware yet.

 

Atari's "Video Chess" was a masterpiece.  It's incredible what they made the machine do back then.

 

 

[+Andrew Davie]

3 hours ago, Kevin McGrath said:

Challenge accepted!

 

Atari's "Video Chess" was a masterpiece.  It's incredible what they made the machine do back then.

 

Good first effort. But what if you have black and white pieces on the same line?

Agreed. At first I wasn't very keen on video chess but as the years have gone by I have realised it is indeed a masterpiece.

[+Karl G]

Perhaps capital letters for the pieces of one one side, and lowercase for the other?  ? 

[+Andrew Davie]

Just now, Karl G said:

Perhaps capital letters for the pieces of one one side, and lowercase for the other?  ? 

That would work. I think maybe that's what the original text-based microchess did. Memory is dim.