cd-w Posted March 13, 2005 Share Posted March 13, 2005 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 Quote Link to comment Share on other sites More sharing options...
Robert M Posted March 13, 2005 Share Posted March 13, 2005 Hello, Welcome to AtariAge. Your demo is very nice, but you need to post the vcs.h and macros.h files you used to compile it or we can not help you to track down the scanline count problem. Cheers! Quote Link to comment Share on other sites More sharing options...
Paul Slocum Posted March 13, 2005 Share Posted March 13, 2005 hi Robert. Since vcs.h and macro.h are standard 2600 "include" files, I think it's preferable not to post them when you post source. the latest versions are always available here: http://www.taswegian.com/TwoHeaded/Atari2600/dasm/ Maze demo looks cool. I'll take a look at the src. I wrote a scroller a few months ago, but it was designed more for coolness than gaming. -paul Quote Link to comment Share on other sites More sharing options...
Paul Slocum Posted March 13, 2005 Share Posted March 13, 2005 It doesn't look like you're using any timer on the Overscan part of the code (if your code takes a variable amount of cycles, you have to use the timer.) And it also appears to be taking too many cycles (you'll have to optimize or split it up). This is often a problem with scrollers since they can take a lot of cycles to process. -paul Quote Link to comment Share on other sites More sharing options...
Cybergoth Posted March 13, 2005 Share Posted March 13, 2005 Hi there! Weird. The scrolling looks better on the horizontal axxis than on the vertical. I'd have thought it should be the other way round... Greetings, Manuel Quote Link to comment Share on other sites More sharing options...
Robert M Posted March 13, 2005 Share Posted March 13, 2005 hi Robert. Since vcs.h and macro.h are standard 2600 "include" files' date=' I think it's preferable not to post them when you post source. the latest versions are always available here: http://www.taswegian.com/TwoHeaded/Atari2600/dasm/ -paul Yes, I would normally agree, but he has a macro in the source called DRAWLINES which is not in the standard macro.h. So it would be good to see both files to make sure we know exactly what he is using. Quote Link to comment Share on other sites More sharing options...
Robert M Posted March 13, 2005 Share Posted March 13, 2005 Whoops! Nevermind, I found the DRAWLINES macro. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted March 13, 2005 Share Posted March 13, 2005 Cool demo. Probably something like Cyclotron from last years Minigame Compo would be pretty doable by using this. It was one of my absolute favourites. Quote Link to comment Share on other sites More sharing options...
cd-w Posted March 13, 2005 Author Share Posted March 13, 2005 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 Quote Link to comment Share on other sites More sharing options...
cd-w Posted March 13, 2005 Author Share Posted March 13, 2005 Hi there! Weird. The scrolling looks better on the horizontal axis than on the vertical. I'd have thought it should be the other way round... Greetings, Manuel The vertical axis scrolls by 9 lines in each step. It should be possible to make it smoother by adding more scroll steps. Chris Quote Link to comment Share on other sites More sharing options...
+batari Posted March 13, 2005 Share Posted March 13, 2005 That's some good work there. Your source is very well organized too. I also used the three scanlines of VSYNC for code, and the emulators and a real 2600 didn't mind this. And yes, there are tricks out there. I used one myself to rotate the playfield which uses all 8 bits in the registers that actually use 8 bits but 4 bits in PF2 since they just use 4 bits. It may save a lot of cycles depending on how you're doing the rotation. Anyway, to rotate PF data in RAM to the right, you can do: LDX #numlines repeat ASL #PF0leftdata-1,X ROR #PF1leftdata-1,X ROL #PF2leftdata-1,X BCC nobit LDA #%00001000 ORA #PF2rightdata-1,X STA #PF2rightdata-1,X CLC nobit ROL #PF2rightdata-1,X ROR #PF1rightdata-1,X ROL #PF0rightdata-1,X DEX BNE repeat OK, so there may be a better way of doing this, but the basic idea is to use the carry bit to your advantage wherever possible. This uses 6 bytes per line. It may be possible to reduce this to 5 bytes by combining both sets of PF2 data into one byte some shifting if you've got the cycles. For rotating left, you can switch things around (ROL's to ROR's, reverse order of PF locations etc) using the same ideas. Of course, in your game you would want to change the ASL to a ROL and add instructions so you can pick up the carry bit from your ROM data. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted March 13, 2005 Share Posted March 13, 2005 Are you shifting the whole maze from scratch each frame? If yes, then you could save a lot of time, by: A: only shift the visible parts B: shift the maze relative to the last frame Quote Link to comment Share on other sites More sharing options...
cd-w Posted March 14, 2005 Author Share Posted March 14, 2005 Are you shifting the whole maze from scratch each frame? If yes, then you could save a lot of time, by: A: only shift the visible parts B: shift the maze relative to the last frame 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. Quote Link to comment Share on other sites More sharing options...
cd-w Posted March 14, 2005 Author Share Posted March 14, 2005 Cool demo. Probably something like Cyclotron from last years Minigame Compo would be pretty doable by using this. It was one of my absolute favourites. 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 Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted March 14, 2005 Share Posted March 14, 2005 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. Yes, the trail will probably be impossible. Maybe you could fill larger blocks or maybe you could develop a completely different gameplay. Quote Link to comment Share on other sites More sharing options...
cd-w Posted March 18, 2005 Author Share Posted March 18, 2005 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 Quote Link to comment Share on other sites More sharing options...
vdub_bobby Posted March 18, 2005 Share Posted March 18, 2005 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! PCAE has a pretty fantastic debugger in it - which does allow you to see the contents of all memory locations (as well as TIA registers and sprite positions). Too bad it isn't a great emulator otherwise (it's rather outdated). Also, you can create trace file in z26. I think you can get PCAE 2.6 (which is the latest version that I'm aware of) here: http://koti.mbnet.fi/thething/atari/emulators.htm Quote Link to comment Share on other sites More sharing options...
Albert Posted March 19, 2005 Share Posted March 19, 2005 I think you can get PCAE 2.6 (which is the latest version that I'm aware of) here:http://koti.mbnet.fi/thething/atari/emulators.htm Has anyone heard from John Dullea in the last few years? It's a shame that development of PCAE stopped, since it had quite a bit of potential. You can also record movies straight from PCAE, and I believe it has some sort of rudimentary networking support, although I don't know if that actually works or not. These features, along with a debugger, would be great to see in z26 and/or Stella. ..Al Quote Link to comment Share on other sites More sharing options...
Tom Posted March 19, 2005 Share Posted March 19, 2005 Did anybody ever get his hands on the *source* for PCAE 2.6 for windows ? Quote Link to comment Share on other sites More sharing options...
Albert Posted March 19, 2005 Share Posted March 19, 2005 Did anybody ever get his hands on the *source* for PCAE 2.6 for windows ? Was the source for PCAE 2.6 ever released? Does anyone know what the original homepage was for when PCAE 2.6 was released? If so, it may be possible to retrieve the source from the Wayback Machine, although I don't know if it caches files of that nature. ..Al Quote Link to comment Share on other sites More sharing options...
Tom Posted March 19, 2005 Share Posted March 19, 2005 Interestingly enough, I have an archive with PCAE 2.6, which contains a copy of the GPL. This is already a good thing, since it would allow for further development - if the source was actually available. Quote Link to comment Share on other sites More sharing options...
Tom Posted March 19, 2005 Share Posted March 19, 2005 A lot of dead links for 2.6 point to http://pcae.vg-network.com Quote Link to comment Share on other sites More sharing options...
+batari Posted March 19, 2005 Share Posted March 19, 2005 The source was released on that page along with the binaries, but PCAE was written in Pascal. I am not making this up. This could very well be the reason that nobody has taken over the project or why nobody seems to have the source. Quote Link to comment Share on other sites More sharing options...
cd-w Posted March 19, 2005 Author Share Posted March 19, 2005 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 Quote Link to comment Share on other sites More sharing options...
Tom Posted March 19, 2005 Share Posted March 19, 2005 That's version 2.5, which is easy to find. Googling for pcaewrsc.zip yields nothing. Adding a debugger to z26 might make more sense anyway. Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.