cd-w

This sounds like it would be a very useful thing to do. From the timing diagram it looks like you would have to finish writing PF2 at exactly cycle 49? However, the testcode below does not work (in Stella and Z26) unless the write finishes on cycle 48? Will this actually work on real 2600 hardware? Chris ; Asymmetrical Reflected Playfield Test PROCESSOR 6502 INCLUDE vcs.h INCLUDE macro.h SEG CODE ORG $F800 Start CLEAN_START lda #%00000011 sta CTRLPF ; Reflected Playfield lda #$76 sta COLUP0 ; LHS Colour lda #$55 sta COLUP1 ; RHS Colour Main VERTICAL_SYNC lda #43 sta TIM64T VBlk lda INTIM bne VBlk sta VBLANK ldy #192 Screen sta WSYNC ; [0] SLEEP 20 ; [0] + 20 lda #%10101010 ; [20] + 2 sta PF1 ; [22] + 3 < 28 lda #%11111111 ; [25] + 2 sta PF2 ; [27] + 3 < 38 lda #%01010101 ; [30] + 2 SLEEP 13 ; [32] + 13 sta PF2 ; [45] + 3 = 48 lda #%11111111 ; [48] + 2 sta PF1 ; [50] + 3 dey bne Screen sta WSYNC lda #2 sta VBLANK ldy #30 OScan sta WSYNC dey bne OScan jmp Main ORG $FFFC .word Start .word Start

Hi Folks, The last posting of my scrolling maze demo had a couple of "off-by-one" errors which prevented diagonal scrolling from working properly. I have now tracked these down, and attached the corrected code to this message. I think the core code is now bug-free, although there are probably plenty of optimisations that could still be done. This should be the last version that I post here for a while as I am now going to concentrate on turning this demo into a proper game. As for debugging, I hadn't realised that Z26 could produce a log file while running. This should be a lot of help, although I think I now need to write a tool to parse the rather large output that it produces! Thanks for the help. Chris maze04.zip

The old website is still on the wayback machine: http://web.archive.org/web/20040202131229/...vg-network.com/. The files are not stored, but googling for pcaesrc.zip gives the following website: http://patpend.net/ftp/emulators/a2600/ Unfortunately it appears to be written in a combination of Pascal and 386 assembler ... Chris

Hi Folks, I have now created a new version of the maze demo, based on the comments posted here. The old version calculated the entire screen on every frame, which was clearly sub-optimal. The new version shifts the existing screen data, and only calculates the new data at the edges. This change required a big rewrite of the core code, but that is life! The result is an amazing improvement in speed, and the scrolling routine now fits comfortably within the vertical blank region, without the need for double-buffering. I am quite pleased with some of the tricks employed in the new code. For example, the screen is represented as a circular-buffer, so we don't have to shift the data when scrolling vertically. However, there is still plenty of room for improvement, and I will welcome any suggestions. The scrolling doesn't quite work in the diagonal direction, but I don't think this is particularly useful in any case. I will probably remove this possibility from the code unless I can find the source of the problem. It is probably just a stray carry, which seems to happen to me all the time! On that note, does anyone have any debugging tips for 2600 code? Since there is no printf, I usually write the data into PF1 to see what is going on, but this gets to be a real pain. Something like a memory monitor would help enormously! Anyway, feel free to copy this code and modify it for your own purposes. Chris maze03.zip

Thanks for the suggestion - it took me a while to get the Oric emulator running, but it seems like a rather addictive game to me. I was originally planning some kind of adventure game (collect the objects, avoid the baddies), but this looks like it would make for a better game. Also, the maze could be generated by a pseudo-random sequence to save on ROM space. The only thing that worries me at present is that it would be necessary to store the "trail" of the player as they move through the maze. In theory, you could loop back and forward several times through the corridors, leaving a rather complex trail. It might be rather a push to fit this in the RAM? Chris

Aha, that makes a lot of sense. At the moment I am redrawing the screen from scratch every time, but it should be possible to reuse the existing data with something like the routine by batari posted above. Of course, this is going to require a fairly major redesign of my scroll engine, but I am rapidly learning that it is necessary to rewrite all my code several times on the 2600! I will keep this group posted on my progress. Many thanks, Chris.

The vertical axis scrolls by 9 lines in each step. It should be possible to make it smoother by adding more scroll steps. Chris

Hi Folks, Thanks for all the positive feedback! I now realise that I need to calculate the length of the overscan properly. For some reason I was assuming that the vertical blank would automatically be triggered at the correct time. Unfortunately, this means that the code uses about twice as many scanlines as it should in the overscan region I have now coded up a modified version which calculates the screen in 2 passes. The calculations are now performed entirely in the Vertical Blank region (37 cycles), which leaves the Overscan region free. The calculations could probably be done in a single pass by using both of these regions, but I hope to make a game out of this demo, so I need to leave some space for the rest of the game. Because I am calculating in 2 passes, the screen is double-buffered, as only half of the screen would be displayed in the first pass otherwise. The scrolling is now half the speed, but I think it is still fast enough for a decent game. I have attached the new version of the code to this message. Note: I didn't include the .h files again as there is a note in these files that states that they shouldn't be redistributed. However, as pointed out above, they are available from the DASM site. Unfortunately there are two problems with modified version, and I would be grateful for any suggestions: 1) The code overflows the vertical blank region when there are too many blocks displayed on the screen. I think the code would be stable with only 2-3 more scanlines. As the screen only uses 189 of the 192 available scanlines, I think this problem could be fixed by extending the vertical blank to 40 cycles, and shrinking the screen to 189 scanlines. Is there any problem with this, or will it fail to work on real Atari hardware? Alternatively, I think some work could be done during the three vertical sync scanlines? However, most of the sample code on the web avoids this region. Is there any reason for this, or is it possible to do work here? 2) The code is now using too much RAM (60 bytes for the screen). I would like to reduce this significantly as it doesn't leave much spare space. Only 4 bits of each byte are actually being used, so theoretically we could fit both screens into 30 bytes by using the unused 4 bits. However, there are not enough spare cycles in the kernel to do the required masking and shifting. Are there any tricks that I can use to make use of these wasted bits? Many thanks, Chris maze02.zip

Hi Folks, The "Retro Gamer" magazine in the UK had a feature on the Atari 2600 last month (issue 12). This feature covered both the gaming side, and the programming side, including a pitch for the Atari Age website. After reading about how difficult it was to program the machine, I got motivated to have a shot myself. My main programming these days is done in Java, so it was a bit of a paradigm shift to start programming the 6502. Actually, this is the first time I have ever touched real assembly language. Anyway, cutting to the chase, I have now read through the various tutorials on the web, including the excellent material on this forum. I decided to get started with playfield graphics, rather than tackling the sprite hardware straight away. To get to grips with asymmetric playfields, I have coded-up a small scrolling maze demo to test my understanding of the principles. The demo and source code should be attached to this message. The code is GPL licenced, so anyone is free to take it and modify it should they wish. My maze demo displays a 6x5 window which can be scrolled around a 32x32 maze using the joystick. The maze wraps at the edges, so you can scroll indefinitely in any direction. It also uses the full screen, except for 3 scanlines. I think this demo will make a good basis for a number of different maze-type games which I hope to write soon. I still have plenty of spare cycles in the vertical bank region, and spare RAM to play with. I would be grateful for any suggestions on how I can improve the code, and any flaws in my programming technique. The scrolling appears to be stable in both Stella and Z26, but the line count in Z26 fluctuates between 270 and 290 scanlines? Any pointers on what I am doing wrong would be most appreciated. Cheers, Chris maze.zip