DavidEth

SpiceWare, I don't understand what's going on here: SetChopper0: lda #ChopperGraphicHeight clc adc Chopper0Y cmp #ChopperGraphicHeight bcs NoYadjustC0 lda #$FF .byte #$2c NoYadjustC0 lda #$0 sta NegativeYadjust sec lda TempPtr sbc Chopper0Y sta DF0LOW lda TempPtr+1 sbc NegativeYadjust sta DF0HI Seems like it's comparing Y+8 to 8 and using the result of that test to store 0 or -1 into an adjust value. Seems like it could just be comparing Y to zero directly? -Dave

Yeah, that would work too. I'm not sure how useful adding zero would be anyway, since you can achieve the same end (assuming 0.8 fixed point) by using 1/256th, which will not overflow for another 255 scanlines either. Main problem with always adding 1 is that it throws off all the rest of the fractions (although 0x100 - FRAC is even worse in this regard). -Dave

In the big scheme of things none of this matters, but since this is all just firmware anyway, there are three possible "fixes" to this nonexistent problem: 1. Treat 0 as a special case meaning 256, either implicitly, or by having the "hardware" add 0x0100 - FRAC. 2. Make the fractional value 1.7 or 2.6 instead of 0.8; this would also let you zoom out a playfield vertically, for whatever that is worth. 3. Whenever the address is rewritten (which presumably zeroes out the fractional LSB's), just set the LSB's to %0000 0001 instead of pure zero. -Dave

So is the priming read just because you're using 1.8 fixed point with only 8 fractional bits? In other words, without the priming read, you're going to return the first data twice, because if the counter starts at zero and the most you can add is 255, you'd get: 0x0000 - return line 0 0x00FF - return line 0 0x01FE - return line 1 0x02FD - return line 2 0x03FC - return line 3 It wouldn't repeat a line again for another 255 or so scanlines, typically more than you're ever going to render on a 2600. -Dave

I wanted a fully programmable playfield and two full color sprites and quickly realized that DPC+ with fastfetch would let me focus on writing a game instead of a bunch of custom kernels. I cut and paste a bunch of the sample code and got my own app working. Nothing special about my code otherwise, but it might be easier to start with. (Note that my code doesn't bother to do the special "priming read" that SpiceWare's code has in it, been meaning to ask him about that) -Dave Note: Example sprite from this thread -- http://www.atariage.com/forums/topic/169238-free-sprites-for-the-taking/ -- courtesy of PAC-MAN-RED. hack2600.zip

I probably don't understand your question, but here are the standard 2600 headers. http://www.atari2600.org/DASM/Atari2600_1_10.zip -Dave

Looking at the game, you might be able to do it with both missiles and the ball combining to allow up to three "drops" per scanline. Every such tuple would share a single Y coordinate but would have unique X coordinates. Assuming you got creative and made the row implicit, you'd need probably four bytes to hold three positions and three X velocities, which would give you maybe 60 bullets on the screen at once. Another option would be to table a bunch of spread patterns in ROM, and just remember which pattern is active (so a single spread pattern may be 50-60 bullets, you just remember which pattern is active, and perhaps apply a slight random offset to each frame) -Dave

Minor update to above, finally got REPEAT / RENEND working in nested case. BOUNDARY macro in climber5.asm is still screwed up, although I think the ALIGN operation does the same thing. Climber5 also has some duplicate symbols because of the way it implements overlays. -Dave my2600src.zip

/* ChangeLog 28 Sep 2010 - More refactoring of assembler and debugger - Implemented BRK and RTI (BRK was necessary for cave1k) - Cleaned up insn decoder, added expected insn counts for clarity, assert they match at runtime - REPEAT / REPEND work better now (well, they don't quite nest yet, see dkong.asm) - Can write assembler output to a file now. - SEG.U turns off initialization, SEG turns it back on - ORG and RORG can now be used to generate at least 8k roms (bzone.asm, montezuma.asm). */ -Dave my2600src.zip

Started keeping a proper changelog. Got massively sidetracked improving the assembler so I could hack on more of the example code out there quickly and easily. Not convinced REPEAT/REPEND handling is quite correct yet. - VDELBL was broken, Pitfall vine works again - Assembler improvements: - * and . equate to program counter - File inclusion works - IFCONST, IFNCONST work - Preserves case on everything except opcodes - Opcode parsing improved - Don't need -a flag any longer, just pass in .asm file - No longer has built-in version of VCS.H, but can re-enable with -V flag. - .z opcode suffix forces zero page (like .w) - MAC / ENDM / SET / EQU now understood. SET and = can reassign values, EQU cannot. - REPEAT / REPEND now understood. - local labels work (inherits context from macro invokation line and/or SUBROUTINE) - Runtime trace displays effective address and contents of memory when appropriate - SDL usage can be completed compiled out - Added DCP opcode - Messed around with VBLANK/VSYNC handling a bit my2600src.zip

I think FE bankswitching just works by switching on any access to $FE The main program is stored in one bank and all subroutines in the other. The stack pointer is set to $FF at startup and any jsr will push values to $FF and $FE the rts will then pull values from $FE and $FF. But I thought that the cartridge is never going to see any access to $FE. In other words, bit 12 of the address line of the 6507 is wired to the "cartridge select" line? -Dave

Interesting -- that must be how FE-style bankswitching works on Robot Tank then? Hardware on the cart itself sees if an opcode being fetched is a JSR or RTS and behaves accordingly. How do you tell fetching a JSR opcode (or in your case, LDA #imm) apart from just a normal data read? (Is the source code to the Harmony BIOS available? The 1.05 download I tried only had a bunch of .arm binary files) -Dave

Okay, Conquest of Mars had the same lockup on startup problem Berzerk had. It was setting the interval to 64 and doing a series of STA WSYNC / LDA INTIM / BNE TOP checks, and it would skip hitting exactly zero. I hacked around it by nerfing the RIOT behavior of resetting the decrement interval to 1 once INTIM reaches zero, but I suspsect something else must be going wrong here? Conquest of Mars also didn't produce a display because my emulator only resets the raster back to the top when it sees VBLANK D2 go from one to zero, which has worked well on other cartridges. When VSYNC D2 goes from 1->0, I flip the screen buffer and process events. When VBLANK D2 goes from 1->0, I was resetting the emulated raster to the top, but it seems like Conquest only ever writes 0 to VBLANK, is there some special reason for that? (I also have to track down what opcode 0xC7 is, I'm guessing it's DCP) -Dave

Seems like it could work -- the mountains in Chopper Command might be doing it. Assume I have a grid of squares, and I want each square to have an arbitrary color based on terrain type. (Using SCORE mode works great for games like Medieval Mayhem, not sure it applies here) Assuming I had a subroutine for each of several combinations of terrain, can I hit COLUBK multiple times per scanline and expect it to work on real hardware? Seems like the fastest I could do it is every 9 color clocks (a bunch of STA/STX/STY COLUBK's to pick between three colors), but that doesn't line up with the playfield and I would be unable to update the playfield registers either. Every color clock being 3 cpu cycles makes it a bit of a pain in the ass to line up though. Does the write from the CPU happen on the last cycle of the instruction? ST{AXY} COLUP0 ; 3 cycles, 9 color clocks; 17 tiles across, only 3 colors. ST{AXY}.w COLUP0 ; 4 cycles, 12 color clocks. 13 tiles across. Playing field would line up at least. LDA #NN STA COLUP0 ; 5 cycles, 15 color clocks. 10 tiles across. Arbitrary colors. LDA #NN STA.w COLUP0 ; 6 cycles, 18 color clocks. 8 tiles across. Arbitrary colors. LDA #NN NOP STA COLUUP0 ; 7 cycles, 21 color clocks, not very useful. LDA #NN STA zp_dummy STA COLUP0; 8 cycles, 24 color clocks. 6 tiles across. Playing field would line up. I guess the only practical one gives me a whopping 6 tiles across while still having enough time to update playfield registers too. If I wanted a bigger map I guess it could scroll? -Dave

I read the discussion here: http://www.atariage.com/forums/topic/162520-fine-positioning-not-working/page__view__findpost__p__2006722 and it clears up a lot of things for me, thanks. It sounds like people generally hit HMOVE on either: - Cycle 0 (right after a WSYNC) or cycle 75, giving you an eight-pixel black bar. - Or cycle 73 or 74, which eliminates the black bar but only lets you move the sprite left. -Dave