roland p

I think that's the whole point. mnemonics do things that are just too low level to give long names to it. even macro's do things that are low level/generic and are just called 'ADD_16_BIT' or 'CMP_16_BIT'. Only at the level when you start creating routines that really do something more complex you can give names to it like 'draw_screen', 'player_jumps' or 'check_joy_up' Even in a high-level language like Java the following code doesn't make sense: public int addTwoNumbers(int numberOne, int numberTwo) { return numberOne + numberTwo; } I think not all mnemonics make sense. The mnemonic for bitwise AND with accumulator is called 'AND'. But the mnemonic for bitwise OR isn't called 'OR' but 'ORA'. I found that really stupid because AND isn't called ANDA too. But of course keeping all mnemonics 3 letters made assemblers back in those days a lot faster because they did not have to check for the length of a mnemonic.

Wow that's just great! I hope I can keep up to the expectations

Now we get to the root of it. That was what I thought it would lead to. So instead of being nice to the early learners, maintain all difficulties because that was what you went through? Rather selfrighteous huh? Don't give help since well seasoned programers didn't get any except what was deemed acceptable by the general consensus? Sounds like the way the US government runs the country. Keep the little ones in the dark so they don't know what REALLY goes on behind closed doors. And you know its true. Doesn't change things to deny it. Really cracks open a can of worms doesn't it. Many endorse the internet, wanting knowledge to be free to all. However, there is a catch. You have to learn that knowledge OUR WAY or not at all. Makes you wonder if anything is really free in life. There are lot's of resources that explain what is going on inside the 6502/7, so nothing is kept secret. And if you do not understand something, just ask here and it will be answered. I don't see the problem except that assembly is just hard to learn and you can only learn it by trying to write programs. I used a 6502 simulator to find out what the heck was going on with those flags etc. I think that if you have a feeling for it and you try very hard you can get a long way.

Changing all those mnemonics into readable text would throw away the nurdy status of those whom understand them

They look indeed very different from the sides.. I've attached a picture with those colors used in the middle...

Yeah, that one really hurt When the scanlines scroll to left/right, the instruction that fills the GRP0 register moves too... It now works ok, I still have to make it dynamic, which adds 1 cycle (Change LDA immediate into LDA zero page), but that should not be too hard. I now make updates every other line. The drones are symmetric, so maybe I could use GRP1 in reflected mode, and fill it with the same data. The scanlines are then offset one line, but that could be corrected with VDELP1? I've tried turning on VDELP0, but that resulted in an invisible sprite... Thanks, but are you sure?, I've tried those colors, but the bordercolor $14 results in light brown, and the dark/bright colors result in a blueish tint.

Kernel with one sprite... phew... ballblazer.bin

That would result in 480p @ 29.97Hz instead of 59.94Hz. is that an accepted standard?

When I've added some collision detection which bounces the player back into the playfield, the issue should be fixed.

I think those effects come form vertical and horizontal movement overlapping. Since vertical movement is much smoother than horizontal, it can happend that e.g. the last visible edge of a tile is scrolled out only to be scrolled in a frame later by the other scrolling direction. There isn't much you can do against this, except for synced scrolling. But then you would loose vertical scrolling resolution. I think that could be improved by using small sprites to increase the resolution

I've tweaked the engine a bit to make the tiles look better in relation to the on screen raster. a tile in the distance will now grow exactly 1 pixel each time when it comes closer. It has less interference with the raster. ballblazer.bin

I'm not sure what you mean. You can try to move at the slowest speed, the you can see more precisely what is going on. The resolution is very low so that can make thing a bit weird, especially in the distance. I want to add (real, non flickering) antialiassing to smooth things out a bit, just like the real ballblazer. The kernel allows this. This should make it look less wonky.

It's quality work -- well done, you should be very proud of this. Don't slack off -- now's the time to push for some sprites and see what you can do! Or perhaps a second screen down below? And one request -- I'd like to have the speed attetuated by friction ASAP! Cheers A The sprites are a sort of last requirement. If those are in it, we could say that ballblazer should be technically possible. I've already been working on friction and brakes, but it's not the way I want yet, it was commented out for the last version. For friction and braking I'll try a two stage design where friction is high at high speed and low at low speed. nothing fancy. Maybe add more stages if it looks crappy.

Well, the thing looks best in motion

Thanks everyone! This feedback really keeps me going I could try to tweak it. One line should be able to scroll 1 full tile, so what you see at the and is the tile that comes at the next line. It's scrolled by eating one cycle. It is now one kernel, wich rotates the lines 45 degrees. Maybe if I split it in two (or just parts of it), where one kernel is a 22,5 degrees rotated version of the first one, I have more time. The tile board is now a repeating 'texture' of two lines heigh and 32 bytes wide. You could create a texture of 256 bytes (256 unique colors), and every line on screen is a pointer within that 256 bytes. I now want to add antialiasing (non-flickering) to enhanche the tiles in the distance. grtz, Roland.

We now have a checkerboard! ballblazer.bin

Could you explain what your code does? For the sprites you would only need to use horizontal motion registers right? for eating 1 cycle I used the following code, probably not what you are looking for: LDA lineScroll ;(3) AND #%00000001 ;(2) BNE Skip0 ;(2/3) Skip0 etc. My experience is that every other (other then a big dumb kernel) method I tried, the overhead of extra cycles rendered the method unusable for the upper part of the checkerboard. And you have to deal with the following problems: - Getting tiles with the right color. Like: brown at the sides, green in the middle - Getting tiles with the right size. - Scroll 1 full tile. to the right/left issues for certain areas of the checkerboard: upper tiles: Quick change of colors, solved with using ram, scrolling is easy because they don't scroll that far middle tiles: More difficult to scroll, not enough ram to get data for tiles, so indexed table from rom is used but costs extra cycles. lower tiles: changing colors is easy because they are big, scrolling is hard because the have to scroll a lot.

The sprites look nice. I wonder what the playfield would look like. I don't get the ascii representation, ascii is not one of the the Atari 2600 strenghts Are you going to write the game or are you looking for someone to write it? (I'm not volunteering as I'm completely dedicated to Ballblazer )

I know the MSX 2 version does not scroll: , so that's no problem. Although it would be very cool if it did scroll, so why not try it? The playfield of the MSX version just looks like a 16x11 tile grid. the atari 2600 version will probably be something like 20x... if you create an kernel that could draw those tiles, then scrolling would be only moving 1/2 tile. EDIT: The scrolling will probebly look strange when Simon walks up the stairs. The movement of Simon is in a perfect diagonal line, while the scrolling is in big steps

Nothing has been easy so far I checked Ballblazer for the 5200 again. It looks like: - Ship's acceleration is lesser at higher speed, until accelleration reaches 0 - Ship's de-acceleration (Brakes) is very high. - The friction is lower at low speeds. Ship keeps moving slowly after deacceleration

Yes, checkerboard would be nice now. I still have to find a way how to calculate the tiles in the distance.

Back on track. Changes so far: - left/right Accelaration is now possible! Be careful, no collision detects yet. - Increased internal horizontal resolution to 256 pixels per tile. This makes the calculations (acceleration, positions of players etc.) a lot easier. Hint: Try to move slow, it looks very cool. - Vectors for moving the checkerboard are now calculated on the fly, in the overscan, as it would consume now 1K of rom if precalculated. - Vectors are pretty accurate now, only a glitch when you cross a tile. I've the feeling that the checkerboard which runs at 60fps is much faster than the 5200 version, which looks like it runs at 30fps. ballblazer.bin

You have to write the PF registers twice each row. So you also have to store and update 6 PF variables. Which won't work within you 76 cycles. That's right. At least it does things in realtime The idea behind it is that I make 1 buffer for the line and then make minor updates to it every scanline. if you study the checkerboard, It only changes a few pix every scanline. Otherwise, the technique could be used to create a nice racing game, only one tile needed. As long as it fits into 4KB, I'm happy.

Hi Thomas, this was my last playfield experiment. It could generate a vector on the fly. Maybe it could be used to generate the playfield. Or calculate sprite positions. Temp = $80 playfield01 = $D3 playfield11 = $D4 playfield21 = $D5 lda #%00011111 ; START WITH ONE DOT (BIT 4) IN PF0. sta playfield01 ; playfield01 .. 21 are buffers for the playfield. lda #0 sta playfield11 sta playfield21 lda #10 sta Temp ;CALCULATE A VECTOR FROM 0,0 to 44,10 ldy #44 ;NR OF SCANLINES lda #50 ;MAX WIDTH KERNEL_LOOP SBC Temp ;(2) BPL NOMOVE ;2 ;if plus, do nothing. if minus, it's time to move one pixel to the right SEC ;2 ;set bit in carry ROL playfield01 ;5 ;move playfield 1 pixel to the right. ROR playfield11 ;5 ROL playfield21 ;5 ADC #50 ;(2) add 50 to make A positive again. NOMOVE TAX ;2 ;draw the screen... usual stuff. LDA playfield01 ;3 STA PF0 ;3 LDA playfield11 ;3 STA PF1 ;3 LDA playfield21 ;3 STA PF2 ;3 TXA ;2 sta WSYNC dey bne KERNEL_LOOP LDA #0 ;clean up pf's STA PF2 STA PF1 STA PF0

No problem! I don't remember having the exclusive rights on homebrewing Ballblazer Well, this isn't actually my thread too. But seperating the two will keep things easier to follow I guess.