VESRE: 2600 Graphical Editor

[Blackbird]

Small side project of mine. :] Allows you to edit a row of graphics in an interactive GUI, and generates a complete assembly file that you can compile and run. Download it and give it a try.

 

Instructions: Open/Save opens and saves a row file. When you're finished, hit Export Code to generate source. Just play around with the rest, you'll figure it out.

 

VESRE v0.1 (Windows)

8.8 mb; works out of the box

 

VESRE v0.1 (Linux)

14.8 kb; requires "xulrunner" package

 

NEEDS:

- DASM

- an emulator (or a real 2600!)

 

TODO:

- Fix known bug, high X values screw up position of sprites

- Allow editing of multiple rows (if you had that much ROM space!)

- Allow editing of missiles

- Allow setting other things (NUSIZ, CTRLPF, &c.)

- Get values from RAM (game potential!)

Edited June 9, 2009 by Blackbird

[Blackbird]

Some technical notes. (You can skip this if you're just interested in the program!)

 

This program is not meant to generate tight, kernal-friendly code, but instead take full advantage of every register and graphics option the 2600 has (creativity over the technical aspect, so to speak). Instead of generating data, it actually generates 8 lines of code, including all HMOVE, graphics-loading, and color register setting. While this wouldn't be practical for a real game, by now, ROM size has grown exponentially, while the limits of the 2600 have stayed the same; if one could take advantage of ROM space to improve graphics, then it seems a worthwhile tradeoff.

 

The row is 8 pixels high, so you would need 12 of them to make a full screen. You can try--the generated row is about 600, 700 bytes, and there's little room for bankswitching. Optimizations could improve that (there's better ways to waste 50 cycles than 25 NOPs). Generating code in RAM would be even better; maybe once the generation has been standardized.

 

If you're interested in how the code is generated, go to the "chrome\content\rowEditor.js" file and find the exportRow() function.

 

The graphics get messed up at high pixel values cause there is an HMOVE butting in on the RESxxs. Fixable, but difficult.

 

Missiles are another story. Getting an LDA and two STAs in after a WSYNC is painful enough, but can somebody tell me why RESM0 an RESM1 use bit D1, not D0? I could totally take advantage of D0 on the color byte being useless. -.- If somebody finds me an illegal opcode which does ROL, STA in three cycles (or even INC, STA), please tell me. Then again, there's also no time to RESMx the missiles anyway, so it's almost moot.

 

NUSIZ and CTRLPF could be set during the first lines (since no sprites can be displayed there anyway) but it'd be cooler if they could be set on every line (for variable-size sprites). Doesn't seem feasible, though.

 

HMOVE can be set on each line. However, sprites could only move even more left, so it's kinda limited. A future version might do HMOVE on each line, use the HBLANK lines for extra cycle time, and allow per-line sprite movement. If that'd be at all useful.

Edited June 11, 2008 by Blackbird

[Nukey Shay]

Note on missile enable/disable:

 

You can reset the stack pointer (TXS) right at the registers (provided your kernal doesn't use the stack for values or return addresses). A 2-cycle CMP between the sprite location and current scanline count would automatically generate missile or ball display via PHP. There's a number of games that take advantage of this trick. Don't forget to reset the stack pointer by TXSing value $FF later.

 

 

Nice program. Ever thought about creating a windowed program to rival the TIA Painter? That one lacks a modern interface (and also does not provide a means to set pixel height...meaning a full-screen display will always have 192 lines of data instead of allowing you to automatically skip ~n of ~N lines when the data tables are constructed).

Edited June 11, 2008 by Nukey Shay

[Nukey Shay]

BTW if the program is using non-moving missiles or ball as a set part of the display, you could place this data in PF0's lower nybble (which is normally unused). That saves an LDA. Alternately...if there is cycle time available an asymmetrical playfield could use a single table to hold PF0 data for either half of the display...4 ASL's push the data higher for the alternate PF0 store.

[Blackbird]

If only there were enough time for logic. :/ From the middle of a line to the beginning of the next is something like (with VDELP0, VDELBL, and an asymmetrical playfield):

 

; 2nd line tail
lda #(ballbit)
sta ENABL
lda #(p0 data)
sta GRP0
lda #(pf0 data)
sta PF0		; PF0 now invisible
lda #(pf1 data)
sta PF1		; PF1 now invisible
ldx #(bg color)
ldy #(pf color)
lda #(p0 color)
sta HMOVE
sta COLUP0

; 2nd line start
lda #(p1 color)
sta COLUP1
stx COLUBK
sty COLUPF
lda #(p1 data)
sta GRP1		;  16 cycles

 

So cramming in as much as possible in the beginning of a line, that leaves about 6 cycles free (or 9 cycles if I HMOVE each line, but). One possibility is to drop in the ENAM0 and ENAM1 with a register of a known condition (the generator knows COLUP1 will have D1 set, so drop it there), but an extra LDA is required in the off chance that all of them has it set. Alternately, the generator could just lose a bit of luminosity control on their colors, but that's cheating.

 

But all that aside, I think an improved TIA painter is a great idea. Probably a lot more useful than this is, and should be easy to convert over. In fact, if anyone has ideas for 2600 code generation tools, I would be glad to help.

[+batari]

Missiles are another story. Getting an LDA and two STAs in after a WSYNC is painful enough, but can somebody tell me why RESM0 an RESM1 use bit D1, not D0? I could totally take advantage of D0 on the color byte being useless. -.- If somebody finds me an illegal opcode which does ROL, STA in three cycles (or even INC, STA), please tell me. Then again, there's also no time to RESMx the missiles anyway, so it's almost moot.

 

NUSIZ and CTRLPF could be set during the first lines (since no sprites can be displayed there anyway) but it'd be cooler if they could be set on every line (for variable-size sprites). Doesn't seem feasible, though.

 

HMOVE can be set on each line. However, sprites could only move even more left, so it's kinda limited. A future version might do HMOVE on each line, use the HBLANK lines for extra cycle time, and allow per-line sprite movement. If that'd be at all useful.

I think you mean RESMPx, which uses bit 1 to align the missile over the player, as opposed to RESMx which repositions the missile arbitrarily. But that said, you hypothetically could insert a well-timed STA RESMx or RESPx to arbitrarily reposition an object? All instructions are in 5-cycle groups so it should be possible. Then the next line could contain a load and store to HMMx and of course, HMOVE.