31 replies to this topic

[cd-w]

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

Attached Files

•  maze.zip   14.3K   124 downloads

[Robert M]

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!

[Paul Slocum]

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...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

[Paul Slocum]

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

[Cybergoth]

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

[Robert M]

Quote

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...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.

[Robert M]

Whoops! Nevermind, I found the DRAWLINES macro.

[Thomas Jentzsch]

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.

[cd-w]

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

Attached Files

•  maze02.zip   15.22K   91 downloads

[cd-w]

Cybergoth said:

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

[batari]

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.

[Thomas Jentzsch]

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

[cd-w]

Thomas Jentzsch said:

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.

[cd-w]

Thomas Jentzsch said:

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

[Thomas Jentzsch]

cd-w said:

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.

[cd-w]

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

Attached Files

•  maze03.zip   16.51K   79 downloads

[vdub_bobby]

cd-w said:

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...i/emulators.htm

[Albert]

vdub_bobby said:

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

[Tom]

Did anybody ever get his hands on the *source* for PCAE 2.6 for windows ?

[Albert]

Tom said:

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

[Tom]

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.

[Tom]

A lot of dead links for 2.6 point to http://pcae.vg-network.com

[batari]

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.

[cd-w]

The old website is still on the wayback machine:

http://web.archive.o...vg-network.com/.

The files are not stored, but googling for pcaesrc.zip gives the following website:

http://patpend.net/f...mulators/a2600/

Unfortunately it appears to be written in a combination of Pascal and 386 assembler ...

Chris

[Tom]

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.