Robert M

Hello, Glad to see new people trying their hand at programming thte VCS. Please use Winzip in the future. That big listing of PF data is painful to scroll through on the forum. Here is the main visible display loop from your code above: LDX #192; 192 Scanlines to Display Draw_Picture LDA Screen_PF0-1,X STA PF0 LDA Screen_PF1-1,X STA PF1 LDA Screen_PF2-1,X STA PF2 STA WSYNC DEX BNE Draw_Picture If you want to reduce that size of your PF data tables, then you can employ many methods. The key to many of them is to use one index register to count the total scanlines (X in your code) and the other index register to point at the next byte of PF data. If the PF data should be recycled for say 8 scanlines producing PF pixels 8 scanlines high and cutting your tables by 8, then you simply need to update Y only once every 8 lines. like this: LDX #192; 192 Scanlines to Display LDY #0 ; PF Graphics index. Draw_Picture LDA Screen_PF0-1,Y STA PF0 LDA Screen_PF1-1,Y STA PF1 LDA Screen_PF2-1,Y STA PF2 STA WSYNC DEX BEQ exit TXA ; Copy the line count to A AND #8-1 ; Since 8 is a power of 2 we can test the lower 3 bits of BNE .skip1 ; the line count. If they are all 0's, then the line count is INY ; a mulitple of 8 and we need to increment the PF index in Y .skip1 JMP Draw_Picture You need to learn how to use the timer TIM64T and INTIM to count scanlines, and you will find it easier to write a display loop if you do not try to use all 192 lines. Its hard to make a graceful transition from vertical blanking directly to a loop that draws the screen. If you leave the first visible scanline blank, then you can move the STA WSYNC to the top of your display loop, and then the sequence of code in the loop from top to bottom matches the scanning of the raster on the TV from left to right for one scanline. I think you will find that arrangement easier to manage and solve display problems. As for displaying 6 sprites on the screen, the Venture game that I disassembled to hack into Wolfenstein has an engine that can display 6 sprites and the ball with veritcal placement restrictions and flickering at 30 Hz. The mostly commented source is located here: http://www.qotile.net/minidig/ There is alot of other good info and source code examples at the minidig. Cheers!

Whoops! Nevermind, I found the DRAWLINES macro.

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.

30380, that will be it for me this week.

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!

I forgot to ask. Does it just suddenly go black, or does the picture degrade before it goes off? Colors going bad or an interference pattern?

Turn the unit on. Then gently wiggle the power cord where it enters the unit, the RF cord where it exits the unit, and the power switch (side to side). If it goes off when you jiggle one of those, it may be a broken solder connection, or the power switch is just getting old.

Thanks Jarret for bringing it to market. Dave did a fantastic job on the artwork. Biggest thanks go to Scott for having the original inspiration to hack Venture into Wolfenstein, and for letting me help make it even better. So, ah... Is one of the first 30 for me?

First score: 7190.

That looks like a good tool for learning the 6502. It comes with some library functions to print output, and it appears to have breakpoints and single stepping execution. As a side note, you shouldn't spend a lot of time learning about interrupts on the 6502, because there are no interrupts in the Atari 2600.

Just out of curiosity, Robert: Aren't the Atari 8bit computers 6502-based? And if so, wouldn't it be better to start with them instead of a Commodore or an Apple? At least that way you get a head start on players and missiles, not that they are that hard to understand. Thanks, -bob That is true. Atari computers used the 6502 as well. I was just listing examples from my experience. The key is to have one of these older systems that have enough RAM and a text interface that will allow more interactive development so the learner has time to get comfortable with the 6502 assembly language before tackling the VCS where if the kernel is unstable debugging can be a nightmare for the inexperienced programmer. Since there are emulators for all the old 650x based systems. It might be best to find an old Machine Language for beginners book and then use the emulator for the system that happens to be the focus of the book. The goal is not to learn that other system, but to use its enhanced human interfacing abilities to learn assembly coding/debugging techniques. Regards,

Hello, Here is my recommendations. You need to learn 2 big things. 1. You need to learn how to program the 650x processor. 2. You need to learn how to program the Atari 2600. If you separate those steps, then the process will be easier in my opinion. If you had previous assembly experience I would say that trying to learn both to produce something in a year would be doable, but you need to learn from a Java background so tackle them one at a time. 1. The 650x family of processors is used in lots of computers at that time period. So I recommend that you either pick up a Commodore 64 or an Apple II personal computer or a really good emulator of either. 2. Pick up a used book that teaches Assembly or Machine language programming for the machine you chose. Consume that book and learn the language 3. Join the Stella mailing list. 4. Write some sample code on that machine with your new language skills. 5. Now you are ready to tackle the Atari 2600. Get the Stella programmers guide. (I'll post a link later). 5. Read Andrew's newbie tutorial on this website, and do the exercises. Explore and ask questions. 6. Now you are ready to start a custom 2600 project. Cheers,

That's very good! If I may make one small complaint about a feature inherited from the original. I never liked that it starts you on the extreme left edge of movement permitted to the base. On the later levels if that one alien fires immediately it can be impossible to dodge the shot. Could you consider shifting the starting position of the base off the edge? Thanks!

I claim dibs on porting Jupiter Lander. The kernel is up and running, I just need the free time to wrap the game around it. Cheers!

Slightly Better: 3429

My best so far: 2527

This is a nice hack idea. I am seeing some glitches in your final ROM though. The score at the top of the screen is clipped to a single line, and the game ends after completing a single wave. I don't see those things with the original ROM running on Stella, so I was wondering if those changes were planned by you, or are they bugs? Cheers!

Just another minor correction to Nukey's idea. You need to do a little more then just reuse the movement restrictor for the last intersection until you reach a new one. If you do that, then the player will be able to exit an intersection and turn before reaching the next intersection in a valid direction for the last intersection that outside the intersection is no longer valid. Hence, the player can pass through walls. Instead, you need to build and maintain a movement restrictor for the passageway the player is in. If the player is at an intersection, then use that movement restrictor instead. But, as soon as the player leaves an intersection you must construct and save a movement restrictor for the passageway. To construct the restrictor is easy. It is just the direction the player left the intersection plus the opposite direction. While the player is between intersectionws the passageway restrictor applies.

just one minor correction to Nukey's formula: Y = (V / CELL_HEIGHT)*NUM_COLUMNS + (H / CELL_WIDTH) I made the cell sizes generic rather than fixed values just to show that they can be any integer you wish. For Nukey's example: CELL_HEIGHT = 8 CELL_WIDTH = 16

You have pretty much nailed the technique down. You keep track of the player's position and compare it to data describing the maze in ROM, and restrict the player accordingly. Its not much work really if you set the maze data up correctly.

That book looks awesome. I can not wait to receive my copy. Cheers!

Gett'in the hang of it: 15749 TIP: Stay away from the corners unless at least 2 cars are out of commision.

Learning how to play this beast: 7321.

A little better: 4548

1546