-
Content Count
1,030 -
Joined
-
Last visited
Posts posted by tjb
-
-
Here's a quick video with artifacting turned off. I used hyperspace once on this one. I'll probably allow you to choose either hyperspace or flip and maybe shield. For some reason the video occasionally jerks on my machine, I'm not sure why.
-tjb
-
Here's yet another video of the latest. The explosions are improved in appearance and no longer slow the game down. Additonally the alien spaceship has been added. You'll notice that I ended up with quite a few reserve ships. This is because I have it temporarily set up so that you are rewarded an extra ship every 500 points for testing purposes. Even at 500 points for an extra ship it still rewards them far too often (bug). I'm hoping to have a screen that allows many of the games variables to be set. I'm also working on a high score display (top 10). I may also add a few minor twists like every fifth level being composed of a wave of attacking alien saucers. Of course you would be able to turn this off it you wanted to play a more traditonal game.
-tjb
-
I don't know if this has been mentioned but how about a built-in profiler for assembly programmers. It would be great to know where an app is spending the majority of its time. Also how many times an addr is JSR'd to, average and maximum number of cycles executed by each subroutine, etc. Something like that would be great for evaluating different algorithms to see which ones are the fastest. For example, in my project I have been evaulating different blitting routines. Sure, you can count cycles on paper but it can get tedious.
my 2 cents worth...
-tjb
-
-
I always thought JV Software has some really interesting titles. One of my favorites is Journey to the Planets. I spent many an hour on that one.
-tjb
-
Has anyone ever seen this cart before (on Ebay):
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewI...AMEWA%3AIT&rd=1
The seller claims the cart contains a number of utilities. I've seen/own flash carts (from AtariMax) so I know it's certainly possible but I guess the screenshot makes me wonder. It looks like an early Windows 3.0/3.1 screenshot. Anybody?
-tjb
-
MC_060906.zipHey Guys!
I really been out of touch for awhile
Since, I really don't have time to fix/finish what I started, any volunteers? Or release the source code?- Paul
I just recently ran across your enhanced Missile Command. It's a great effort. I'm just now really starting to get into 6502 Assembly programming on the Atari and I was wondering what tool(s) you used to reverse engineer the original?
Also, releasing even a portion of the source code for your enhanced version would be great. It would be a great learning tool for people such as myself. Heck, I might even be able to contribute.
-tjb
I used dis6502 since it seemed to do a decent job. Next, I used atasm to compile the disassembled code. And after making all the necessary changes got it to compile exactly like the 8bit dump. Then, started making all the hacks!
Since I really don't have alot of time to make further changes (fix the 5200 version!), I'm gonna attach the current source code. My hope is that group/individual will continue this hack! (Just give me alittle credit
) Enjoy!- Paul
Wow, thanks a million
The code will be a great learning tool. I especially like the fact that it can be built for either the 5200 or the Atari 8-bits. This will be most useful in learning the differences between the two. -tjb
-
Wow, that is nice! Do you know if he is still considering releasing the source?
-tjb
-
Very cool. Thanks for sharing.
-tjb
-
looks good so far but remember in an arcade game you should not have different game speeds depending on the action on screen... so i would go for the slowest speed... i personally found it annoying when you hit asteroids that the game slows down and after explosion speeds up...As I said, there is still much work to do. Right now I'm focusing on getting all of the play mechanics in place. Once it's feature complete I'll address the timing issues.
-tjb
-
The game looks great. Is it using the "strip sprites" method discussed earlier?Also, can you post a video either from real hardware via vidcap, or emulator without that annoying artifact simulation?
Finally, can you add timing bars so we can see the CPU utilization (ie - change background colour at start/end of sprite draw and erase)
Thanks. I'll try to put together another video of it running on real hardware. I'm still experimenting with the sprite routine but at present it doesn't use the "strip sprites" method. The main reason is because my sprite data runs from left to right rather than top to bottom. I have a Java sprite drawing program that calculates the data and I haven't gotten around to modifying it. The routine does employ some self modifying code in order to squeeze out a few more cycles.
I'll also look into adding some timing bars.
-tjb
-
Here's a new video of the latest version. Still much work to do but it's playable
I'm thinking I'd like to have a 5200 version as well. Anybody have any porting tips they'd like to share?-tjb
-
I think that unwound loop ZR method Heaven posted would be the way to go.Probably split the big asteroids into 5 "strips"
ie - 1 strip for left/right columns and the 2nd column
2 strips for the 3rd column - looks like there are a lot of zeros in there. Although, circumstances change depending on the XPOS value I suppose.
Maybe reduce the size of the asteroids from 32 to 28 pixels wide? That way, you only do 4 columns instead of 5 of them 50% of the time.
Probably do some cycle counting exercises on the rendering of the smaller asteroids - might be quicker to render them a different way?
Investigate using page flip (double-buffer) - then you can just ORA the data, and store in zeros instead of the second call with EOR. Big extra memory cost, but a saving in cycles, plus any flickering issues will go away.
How will you be doing collision detection (ie shots to rocks)? Apparently, the arcade version uses "collision hexagons" where somehow objects are mapped into hexagon shapes.
Thanks for all the ideas. I'll have to look into them. The only collision at present is checking to see if a bullet hits an asteroid. It uses the simple bounding-rectangle method. I'm open for suggestions.
-tjb
-
can you post or send me the sprites of the 3 rocks? thanks! i would like to make a test...
I'm actually at work at the moment. I can send them later today. What format? Can I send you .bmp files?
-tjb
-
I really like the in-depth discussion on sprite engine techniques. If I would have known posting would have led to this I would have posted much sooner
Please, continue...
-tjb
-
Looks good. Are you implementing more ship angles than the original?That was one of the big weaknesses of the original conversion.
I assume you're using a table lookup in the sprite routine to get the screen address based on the sprite's YPOS?
You can gain extra speed by creative table lookups.
I also would assume you are using pre-shifted sprite definitions?
A really nice feature would be tumbling/turning rocks but it might be rather expensive on memory - maybe do a 128K version?
>>Looks good. Are you implementing more ship angles than the original?
Thanks. Currently the player's ship has 24 different positions. I believe Atari's has 16?
>>I assume you're using a table lookup in the sprite routine to get the screen address based on the sprite's YPOS?
>>You can gain extra speed by creative table lookups.
>>I also would assume you are using pre-shifted sprite definitions?
You're right on the money. I am using both a table lookup to find the screen address of the beginning of the row based on the sprite's Y position and pre-shifted sprite definitions.
>A really nice feature would be tumbling/turning rocks but it might be rather expensive on memory - maybe do a 128K version?
I had rotating rocks initially. It got pretty expensive as you mentioned in terms of memory - especially when you have several frames to make the animation smooth. I'd like to try adding them back at some point. Maybe there will be another version as you suggested - "Rasteroids Deluxe"
-tjb
-
looks good so farquestions:
1) why artifacting turned on?
2) Antic F used? with 40 Byte scanlines?
3) sprite routines are based on EOR right?
4) how many objects will it possible to display?
5) double buffering?
i am just asking as i have played around years ago with a quick softsprite routine based on zoneranger by Activision.
I'd love to hear about these routines as well as the ones in ZoneRanger.
In regards to your questions:
1) why artifacting turned on?
I assume you are referring to having artifacting turned on in Atari800Win plus? I have it turned on to better approximate what the game will look like on real hardware. I've run it on a real Atari and the artifacting is actually not as bad.
2) Antic F used? with 40 Byte scanlines?
Yes, it uses Antic F.
3) sprite routines are based on EOR right?
Yes.
4) how many objects will it possible to display?
It really depends on the size of the objects. This is one area I realize I need to proceed with caution. Currently, the size of the largest asteroid is 32 x 32 pixels! Depending on how things work out I may have to shink it down somewhat.
5) double buffering?
At present I am not using double buffering but that is an interesting possibility. Are you referring to the use of page flipping?
I know you have alot of experience in sprite routines. Any suggestions/hints would be most appreciated.
-tjb
-
I'm currently working on an Asteroids clone entitled Rasteroids. My goal is to make a clone that is closer to the arcade game that the versions I've seen (Asteroids, Meteorites, etc.) available on the 8-bit. There is much work to be done but basic asteroid and ship movement, firing, and some collision detection has been implemented. I'm curious to see if there is any interest in the community for such a game.
I've attached a couple of screenshots and a short AVI of the game running under Atari800Win Plus. Please bear in mind that the game is very much a work in progress at this point (i.e. Ship graphics need lots of work, Asteroids do not explode when hit, the player's ship cannot be destroyed, etc.).
-tjb
-
CC65 does file based linking; ie., you get all the symbols in a object file. One thing you can do to help things is to segment all of your c code into individual (or few) functions per file and have an include file that you custom tailor to only build the sources you need...that's kind of a pain of course, and it only helps you with non-library code. One thing in particular to avoid is any use of the printf()/scanf() family...if you leave all that completely out and use conio or your own routines ou will get a much smaller executable.Interesting. I'm sure I'll continue to use the CC65/CA65 combination for many things. It's nice to test out assembly routines from the confort of C. My initial thought was to code the speed critical parts in assembly and do the rest in C. Since the entire app will essentially be executing as a VBI routine my strategy has changed accordingly. I guess there's no reason why I couldn't simply use a C function as the VBI routine (assuming I could get everything done in the limited amount of cycles available).
-
You have to load them to specific blocks (1, 2, 3 or 5) before you can execute them, just like how the old carts would do it.(the blocks representing memory locations $20, $40, $60 and $A0)
I suggest a visit to Denial ( http://sleepingelephant.com/denial ) to ask as there's lots of Vic20 experts there

Wow, thanks! It seems there's a whole community of VIC-20 enthusiasts I never knew existed!
-
I've not long ago converted to ATAsm.It's close to Mac/65 in syntax.
I've also tried XAsm but a fair amount of conversion to source is needed for it to work, it insists on things like ORG instead of *= and EQU instead of =.
I'm using it with EditPlus - created a short batch file to do the assemblies.
Thanks for the info. I just finished converting my current project to ATAsm. Previously I had a small C program to set the graphics mode and then call an assembly subroutine to set up a VBI routine. The C program would then simply loop. Now with it's all in assembly the code size shrank considerably. Apparently CC65's library functions get linked in as a whole. I sort of thought it would only link in code you actually used but this doesn't seem to be the case. In any case I got the end result I was looking for, thanks. Most of the changes were due to my using the parameter passing scheme of CC65.
tjb
-
There are a number of .prg files (cart dumps I believe) floating around for the VIC-20. Can you simply create a .D64 disk image with these files in order to be able to play them on a real VIC (using a XE1541 cable)? I managed to use the D64 editor program to add some .prg files to a .D64 file. Using an emulator I tried to load them using "LOAD "pgmname",8,1". I then tried using SYS 40960 ($A000) among other things but had no success. Is there something special I need to do? Any help would be most appreciated as I am clueless.Thanks,
tjb
An unexpanded VIC doesn't have enough RAM to play dumped carts. IIRC (from 20+ years ago) although the carts are only 8k, you need the 32k expansion in order to run the cart dumps.
Thanks for the info. I didn't even consider the amount of RAM (or lack thereof). I have a cardboard expansion inteface (by CardCo) that allows you to use RAM expansion modules but alas, I currently only have an 8K one. For some reason I was thinking I had two 16K expansion modules, oh well.
I tried loading the images from the .D64 file inside the WinVICE emulator and while they loaded, I could not get them to run.
tjb
-
There are a number of .prg files (cart dumps I believe) floating around for the VIC-20. Can you simply create a .D64 disk image with these files in order to be able to play them on a real VIC (using a XE1541 cable)? I managed to use the D64 editor program to add some .prg files to a .D64 file. Using an emulator I tried to load them using "LOAD "pgmname",8,1". I then tried using SYS 40960 ($A000) among other things but had no success. Is there something special I need to do? Any help would be most appreciated as I am clueless.
Thanks,
tjb
-
I'm familar and confortable with writing assembly routines using ca65 that interface with cc65 programs. What I'd like to do is use ca65 to write complete assembly apps. It seems the key is the .cfg file used by the linker. Does anyone have any experience doing this? Can you point me in the right direction?
I know this topic has come up many times but, what assembler do you prefer to use for stand-alone work? I like ca65 quite a bit but I wonder how often it's used in a stand-alone fashion.
Thanks,
tjb

In Development: Asteroids clone
in Atari 5200 / 8-bit Programming
Posted
I neglected to answer you earlier question regarding sound. As yet, sounds effects have yet to be written.
-tjb