The Wasteland 2 computer's technical specs

Topics covering the 6502 emulator in Ranger Citadel: tutorials, specs, source code and share your work!

Moderator: Ranger Team Alpha

Post Reply
User avatar
Joby
Developer
Posts: 129
Joined: February 23rd, 2012, 9:21 am
Location: Ground Zero - inXile
Contact:

The Wasteland 2 computer's technical specs

Post by Joby » September 3rd, 2014, 1:14 pm

You should be well versed on programming for the 6502 processor (from this thread), and have the tools needed to create your own "Diskette" (from this thread).

You won't be able to write a very useful program for the computer in Ranger Citadel until you understand how it's... um... "built".

When you write programs for the 6502 processor, you write them based on the hardware specs and absolute memory locations of how that device was designed and constructed. That's a bit different than modern computers with programming languages that allow you to decouple yourself from the hardware, but deep down, they too need to be compiled to the specific instruction set of the processor. Computers back in the 80's were far simpler machines without operating systems or disk drives. A program was loaded directly into addressable memory and executed. That addressable memory also contained the ROM itself as well as direct mapping of the address space for the monitor and graphics output. To display things onscreen, you'd write values directly to memory locations that represented the monitor's memory for pixels. To make things easier, soft switches were also added. These were memory locations that is accessed by a peek or poke (reading or writing) would trigger some action, like playing a sound or switching graphics modes from hi-res to low-res, etc.

Writing a program for a computer based on a 6502 processor means you are writing a program directly for that hardware. 6502 programs aren't universal. Although the NES, Commodore 64 and Apple ][ were all based on the 6502 processor, they each had very different hardware specs and memory allocations.

The Wasteland 2 computer, which I lovingly call the Agave ][, was designed with it's own unique structure. It is very simple, but should offer enterprising programmers a playground to create some really wonderful programs/games.

Let's get going!

--- The Agave ][ Computer Hardware ---

The 6502 computers of Wasteland use the amazingly robust 650WL2 64k processor. (See what I did there :roll: ) Hardware memory mapping is as follows:

Page 00:
0x0000 - 0x00FF : Zero page storage.

Page 01:
0x0100 - 0x01FF : Stack location (do not use)

Pages 02-69:
0x0200 - 0x03FF : Monitor memory text buffer page 0
0x0400 - 0x35FF : Monitor memory graphics page 0
0x3600 - 0x37FF : Monitor memory text buffer page 1
0x3800 - 0x69FF : Monitor memory graphics page 1

Pages 70-EF:
0x7000 - 0xEFFF : User program space (32k)

Pages F0-F7:
0xF000 - 0xF7FF : ASCII Font definitions (8 bytes per character = 8 bits per row, 8 rows)

Pages F8-FE:
0xF800 - 0xFEFF : ROM Reserved Space for future use

Page FF:
0xFF00 - 0xFFFF : Soft switches, input and other variables


The following memory locations offer special abilities:

Soft Switches:
0xFF00 - Read/Write to switch to Low-Res graphics mode (default), clears screen
0xFF01 - Read/Write to switch to High-Res graphics mode, clears screen
0xFF02 - Read/Write to switch to Text mode, clears screen
0xFF03 - Read/Write to switch to TextOR mode (text layered on high-res), clears screen

0xFF04 - Read/Write to switch to Low-Res graphics mode, does not clear screen
0xFF05 - Read/Write to switch to High-Res graphics mode, does not clear screen
0xFF06 - Read/Write to switch to Text mode, does not clear screen
0xFF07 - Read/Write to switch to TextOR mode (text layered on high-res), does not clear screen

0xFF08 - Clears low/high-res graphics memory page 0
0xFF09 - Fills low/high-res graphics memory page 0 with value
0xFF0A - Clears low/high-res graphics memory page 1
0xFF0B - Fills low/high-res graphics memory page 1 with value

0xFF0C - Clears text buffer memory page 0
0xFF0D - Fills text buffer memory page 0 with value
0xFF0E - Clears text buffer memory page 1
0xFF0F - Fills text buffer memory page 1 with value

0xFF10 - Set active graphics page to 0
0xFF11 - Set active graphics page to 1
0xFF12 - Set active text page to 0
0xFF13 - Set active text page to 1

Special Quirks:
0x0000 - Although you can set the program counter to any address, setting it to $0000 will pause execution until the next Unity update call. You can leverage this to create a delay by setting $00 to 0xEA (NOP) and $01 to 0x60 (RTS), then calling JSR $0000 within your loop.
0xFFFF - BRK or errors jump here then program counter sits here and does nothing. This is different than the standard 6502 BRK instruction. Note, there are no hardware interrupts.

Input:
0xFFF0 - Last key pressed (0-255 ASCII value)
0xFFFA - A random number (0-255) updated after every operation

--- Graphics ---

Low-Res Mode:
16 colors (4-bit values 0x0-0xF) in a 32x32 resolution. Starting at memory location 0x0400 for Page 0 and 0x3800 for Page 1. 1 pixel per 8-bit address. Bits are as follows: 0b[Darkness,Red,Green,Blue], with 0b0 being black, 0b0111 being white, 0b1000 being dark grey and 0b1111 being light grey. With a 1 Darkness bit, colors are half as bright, so 0x0-0x7 represents 8 bright colors, while 0x8-0xF are their darker versions.

High-Res Mode:
16 colors (4-bit values 0x0-0xF) in a 160x160 resolution. Starting at the same memory locations as low-res mode. 2 pixels per 8-bit address location, 4 bits per pixel.

Text Mode:
Monochrome (white) 20x20 columns/rows of text. Using the graphics locations for rendering font pixels, each character uses an 8x8 pixel grid (64 pixels per character) with 2 pixels defined in each byte. A special text memory buffer is allocated at 0x0200 for Page 0 and 0x3600 for Page 1 which stores 1 byte per 1 character (values 0-255). In text mode, the information in the active text buffer page will be read and painted into the active graphics page based on the font character definitions at 0xF000-0xF7FF.

The letter '0' rendered in high-res graphics memory, 2 pixels per byte:

0x0200:

[x30]... (ASCII hex value for '0')

0x0400:

Code: Select all

[x00][x00][x00][x00]... +76 more bytes...
[x00][x07][x77][x00]... etc
[x00][x70][x00][x70]...
[x00][x70][x07][x70]...
[x00][x70][x70][x70]...
[x00][x77][x00][x70]...
[x00][x70][x00][x70]...
[x00][x07][x77][x00]...
Spacing of the font is a 1 pixel buffer on top and right, two pixel buffer on left, and no buffer on bottom. The first pixel may not get used (or overlayed) in the future (which is why there is a 2 pixel buffer on the left), which would allow for a 22x20 text display. However, at this time, the display is 20x20.

Each row (of the 8 rows) of that character is offset by 0x14 (20) vertically, thus each individual character is offset by 0xA0 (160) vertically within the text buffer page. An individual character is offset in address space by 0x01 (1) horizontally from one character to the next.

0x0200 (Row 0):

[0x30][0x30]... +18 more bytes

0x0214 (Row 1):

[0x30]... etc


Custom Wasteland inspired fonts exist in the lower ASCII values normally control characters, while basic ASCII values are respected for alpha-numeric characters and symbols. The higher values will most likely be graphic shapes in the future, however is currently unused (or can be used for your own custom fonts). However, this data is stored at memory locations 0xF000-0xF7FF, allowing the programmer to create their own fonts and characters as desired.

The character '0', ASCII value 0x30, is offset from 0xF000 by 0x30*8 or by 0x0180, thus starts at 0xF180:

Addresses 0xF180-0xF187:

...[0x00][0x1A][0x22][0x26][0x2A][0x32][0x22][0x1A]...

Represents:

Code: Select all

[........] = [0x00]
[...###..] = [0x1A]
[..#...#.] = [0x22]
[..#..##.] = [0x26]
[..#.#.#.] = [0x2A]
[..##..#.] = [0x32]
[..#...#.] = [0x22]
[...###..] = [0x1A]
Note, Soft Switches of 0xFF03 and 0xFF07 set 'TextOR' mode. This mode uses the High-Res graphics memory and layers the text data ontop (bit-wise OR text and current graphics). This allows you to have both text and graphics pixels rendered optop of each other. 'Regular' text mode does not preserve the graphics data, but overwrites with the text buffer font data.

Soft Switches have been created to set modes, clearing and filling page memory and double buffering management.

PRO TIP: You can display text from text page 0, then soft switch 0xFF07 to be in TextOR mode without clearing buffers, fill page 0 with an unused character (store 0xFF into 0xFF0D), then change the font character 0xFF's 8 bytes to all be 0x1, then loop on a delay and a bit-shift left 1 until the value is 0x80. This will have an effect of displaying a page of text, then the page wipes to solid white in a vertical blinds transition. I used this technique in the Snake game to clear the text when starting the game.

Remember: programs are loaded into address 0x7000 and run from there. When assembling your code, you will need to ensure your assembler sets the program's beginning address location to 0x7000.

I can't wait to see what people create!
- Joby
inXile's ruthless Leader of Scripters

User avatar
Joby
Developer
Posts: 129
Joined: February 23rd, 2012, 9:21 am
Location: Ground Zero - inXile
Contact:

ASCII Font

Post by Joby » September 3rd, 2014, 2:50 pm

Here's the current ASCII font set for the Agave ][ starting with ASCII value 0x00 being empty, then with 31 Wasteland related characters, then the standard lower end ASCII character set up to 0x80.

Image

So, a space is ASCII value 32, or 0x20. Although lower and uppercase letters are accepted as keyboard input stored at 0xFFF0, both will display as an uppercase letter. Both 0x41 and 0x61 are 'A', for example.
- Joby
inXile's ruthless Leader of Scripters

User avatar
vadrick
Acolyte
Posts: 70
Joined: March 6th, 2012, 2:03 pm
Location: Bay Area, CA
Contact:

Re: The Wasteland 2 computer's technical specs

Post by vadrick » September 4th, 2014, 10:03 pm

This is crazy cool. The (pleasant) surprises keep coming.

A couple questions. What is the clock? What is the vsync in clocks?

I'd up my pledge by $5 if you add IRQ for keypress. Too late? Worth trying. ;)

Awesome work, guys.

User avatar
Joby
Developer
Posts: 129
Joined: February 23rd, 2012, 9:21 am
Location: Ground Zero - inXile
Contact:

Re: The Wasteland 2 computer's technical specs

Post by Joby » September 5th, 2014, 11:29 am

vadrick wrote:This is crazy cool. The (pleasant) surprises keep coming.

A couple questions. What is the clock? What is the vsync in clocks?

I'd up my pledge by $5 if you add IRQ for keypress. Too late? Worth trying. ;)

Awesome work, guys.
"Pay no attention to that man behind the curtain..." :mrgreen:

There are a few limitations to this simulated computer within Unity. Mostly because I also had Wasteland 2 to work on. ;)

There are no hardware interrupts and the display of data to the screen is a bit different because of how it's integrated within the game and Unity itself (making the concept of interrupts not really needed). The update methods are called as fast as possible and can vary, however, I'm running a number of operations per second to be consistent over time, about 6500 cycles/second. I did not, however, actually break out each opcode to consume their unique cycle count... all opcodes consume 1 cycle (including whatever the soft switch does, like filling the screen with a character, wiping the sceen, etc). So, it's not quite as bad as a 6.5KHz computer. It is still pretty slow, far slower than the sluggish 1MHz Apple ][+ I had as a kid. In part this was to make programming simpler for people new to the 6502 (burning cycles to create a delay is far easier being so slow) and it can be more an educational tool. Adjusting this clock rate is trivial, though, and I'll probably have a soft switch you can flip to put it in "turbo" mode(s) later on when the community is pushing it to its limits demanding more from it. :geek: :D

Updating the screen occurs on the HUD's own update cycle, so it too is as fast as possible, whatever that ends up being on your system. Unlike the cycles running, I didn't gate this. It reads the current data then adjusts the pixels to their proper colors. There is no real vsync or scan rate. So it'll update constantly as your program is running. This was one reason I setup the double pages and soft switches to manage them, so you could have control over smoother double buffering. However, I have to admit, I find these limitations enjoyable. Purely from a historical and educational role, so many people are unaware of the tricks people would do to push these early computers to do things that seemed impossible. I love the fact this computer is so limited... programming for it is it's own challenge and game within itself. :ugeek:

When it comes to keyboard input, Unity carries the user's input as a string and this data is available on each update. Each update may run 100-200 cycles, but for that time there will just be the one update to $FFF0 for the last key pressed. On Unity's next update the user input string is empty if there wasn't a keypress. I only update $FFF0 when the string exists and use the last character. So, you can loop through looking for keyboard input, checking for a non-zero value at $FFF0, grab it and then set $FFF0 to zero, waiting for it to change again in the future... or keep track of what it used to be and look for a change from that value. Either way, $FFF0 will have the last key pressed until another key is pressed.

Unfortunately, there is/was a slight issue with keyboard input. I used to run the processor cycles off Unity's FixedUpdate method, which is tied into the physics engine and runs at a consistent rate. We used to have the Physics settings running at a rate that made this all sing, but right before the last update the physics update rate was lowered because we only minimally use physics for particle effects. Because the user input data is tied to the Update method and not FixedUpdate, this caused user input to be lost between the different update rates of the two methods. I didn't catch this until after our update, so user input is/was a bit wonky. I've fixed this since then, but if you are having a hard time playing the Snake game, that is why. Part of me hoped no one would notice this easter egg until after the release and patch. Oh well. Day 1 patches are the best thing ever. :D
- Joby
inXile's ruthless Leader of Scripters

User avatar
clearer
Scholar
Posts: 102
Joined: June 26th, 2012, 6:26 pm
Location: Right here!

Re: The Wasteland 2 computer's technical specs

Post by clearer » September 19th, 2014, 3:26 pm

Joby wrote:However, I have to admit, I find these limitations enjoyable. Purely from a historical and educational role, so many people are unaware of the tricks people would do to push these early computers to do things that seemed impossible. I love the fact this computer is so limited... programming for it is it's own challenge and game within itself. :ugeek:
I still have fond memories writing game engines for DOS (quite similar to the original Wasteland in fact -- only 8 years later) and then discovering that all I had to do to make a lot of effects, like fading to some constant value (black for example), was to change the palette.. a lot faster than changing single pixels, even for low resolutions. Boy, did I have a lot of fun after that.

I'm looking forward to writing games for the 6502WL2 64K.

UncleSporky
Scholar
Posts: 144
Joined: April 25th, 2012, 4:21 pm

Re: The Wasteland 2 computer's technical specs

Post by UncleSporky » September 23rd, 2014, 7:45 am

Could someone post a screenshot of all the available colors with corresponding value?

Am I reading this right, we have 256 bytes of RAM, and 32k for program, graphics, everything else? Yeesh, I'm spoiled by 2k RAM on the NES. :)

User avatar
Joby
Developer
Posts: 129
Joined: February 23rd, 2012, 9:21 am
Location: Ground Zero - inXile
Contact:

Re: The Wasteland 2 computer's technical specs

Post by Joby » September 23rd, 2014, 11:18 am

UncleSporky wrote:Could someone post a screenshot of all the available colors with corresponding value?
Image

Top row is values 0x0 - 0x7, bottom row is 0x8 - 0xF. Think of the color as the binary for the four bits: [darkness, red, green, blue]. So, yellow for example, is 0b0110, or 0x6, and dark yellow/sand is 0b1110, or 0xE. Exception is 0x8, or 0b1000, being a dark grey... instead of a "dark black".

Below is source code for displaying the above (computer defaults to low-res mode 32x32, with graphics memory starting at address 0x0400):

Code: Select all

LDA #$0
STA $0400
LDA #$1
STA $0401
LDA #$2
STA $0402
LDA #$3
STA $0403
LDA #$4
STA $0404
LDA #$5
STA $0405
LDA #$6
STA $0406
LDA #$7
STA $0407

LDA #$8
STA $0420
LDA #$9
STA $0421
LDA #$a
STA $0422
LDA #$b
STA $0423
LDA #$c
STA $0424
LDA #$d
STA $0425
LDA #$e
STA $0426
LDA #$f
STA $0427
- Joby
inXile's ruthless Leader of Scripters

UncleSporky
Scholar
Posts: 144
Joined: April 25th, 2012, 4:21 pm

Re: The Wasteland 2 computer's technical specs

Post by UncleSporky » September 23rd, 2014, 12:55 pm

Thanks, it's helpful for planning graphics.

I'm looking into what it would take to be able to convert bitmap graphics to this format, not sure if a 4 bit color bitmap already corresponds directly to these colors and format or if I'm going to need to write a conversion program.

EDIT: Ah, I see. Shouldn't be too tough to convert a bitmap to this format...

Mika
Initiate
Posts: 18
Joined: September 25th, 2014, 11:47 pm

Re: The Wasteland 2 computer's technical specs

Post by Mika » September 28th, 2014, 2:08 pm

very very cool. This easter egg really made my day! :P :P :P

User avatar
Whelp
Acolyte
Posts: 87
Joined: September 22nd, 2014, 7:44 pm

Re: The Wasteland 2 computer's technical specs

Post by Whelp » September 29th, 2014, 12:08 pm

The... silly computer in the citadel is actually an emulated 6502? You gotta be shitting me.

Mind = blown.

User avatar
Whelp
Acolyte
Posts: 87
Joined: September 22nd, 2014, 7:44 pm

Re: The Wasteland 2 computer's technical specs

Post by Whelp » September 29th, 2014, 12:13 pm

Well? Somebody port Elite onto that thing already (I kid.)

UncleSporky
Scholar
Posts: 144
Joined: April 25th, 2012, 4:21 pm

Re: The Wasteland 2 computer's technical specs

Post by UncleSporky » September 29th, 2014, 12:19 pm

I should try to do a wireframe maze runner or something.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest