EricBall
-
Content Count
2,362 -
Joined
-
Last visited
Posts posted by EricBall
-
-
Maybe, but the 2600 won't give you many indications about what you do wrong on it either.z26.log - yes it's huge but it give lots & lots of info. (A helper application is also being developed to make it easier to work with). I believe that PCAE alos has some tracing capabilities, along with an add-on to Stella in development.
The problem, IMHO, with programming other computers & consoles is you spend most of your time figuring out what BIOS calls to make instead of coding actual 6502 routines. That BIOS knowledge can't be re-used on other platforms.
-
sometimes a grey line shows up, it's diagonal.... what is this?This is probably more to do with your TV. Since the 2600 CPU is trying to execute code which doesn't exist it isn't causing the TIA to generate VSYNC or a valid frame.
-
The problem is most 6502 based consoles and computers are very different from an I/O perspective. So although you can re-learn 6502 using a C64, 90% of what you will need to learn will be C64 specific.
And I have to disagree with Thomas, the 2600 isn't a bad console to use to learn the 6502. Although it can be difficult to program the 2600 to do many things, it is reasonably easy to get it to do something. You don't need to write very much code to persuade the TIA to start kicking out graphics. (Whereas you need a lot of code to set up the DLL used by the 7800 for example.)
-
I haven't done any Lynx programming, but I've done lots of C and ASM (6502 and others).
A big benefit of ASM programming is it gives the programmer almost absolute control. There is no translation layer (compiler) making decisions on your behalf.
C is also built around function calls and typically uses stack-based local variables. Both are not that efficient for the 6502 (JSR/RTS=12 cycles). And unless the Lynx C compiler has been optimized for the Lynx/6502 there may be other inefficiencies (starting with the size of int).
-
The 7800 has 6 different graphics modes selected by three bits: bits 0 & 1 of the CTRL register (read mode) and bit 7 of the second byte in a five byte graphics header (write mode).
WM RM1 RM0 mode details 0 0 0 160A 4 color, 2 bits/pixel 1 0 0 160B 0 1 1 320A 2 color, 1 bit/pixel 1 1 0 320B 4 color, 2 bits/pixel 1 1 1 320C 0 1 0 320D
Modes 160A, 320A and 320B are straightforward - the palette is given in the display list and the bits in the graphics data select one of the colors. Modes 160B, 320C and 320D are more difficult to understand (and use) because they mix the graphics and palette bits. See the 7800 Software Guide for a description of these modes.
Because the Write Mode bit is contained in a graphics header, it could (theoretically) be changed "on the fly" to allow some graphics (e.g. backgrounds) to be more colorful than the rest. It would be interesting to know whether this was ever done in practice. However, this does mean that you will need to stick a 5 byte header into one of the display lists to set the Write Mode bit. (It doesn't have to be on the visible screen, so it could be part of one of the hardcoded null display lists.)
160A is a standard 7800 graphics mode used by many games. The graphics header selects one of the 8 palettes and each pair of bits (76,54,32,10) selects a color, with 00 being transparent. 320A is also simple to understand - again, the palette is given in the graphics header and each bit determines whether a pixel is on (color #2) or off (background or background). 320B is the same as 160 except it has double the resolution and the bits are in a different order (73,62,51,40).
It should be noted that all of the 320 modes have some limitations. First, the 320 modes are more like doubleres 160 modes. Although the color resolution is 320 pixels per line, the sprites are still positioned the same (effectively 160 pixel resolution).
The 320 modes are have a quirk when it comes to transparency. Both halves of the singleres pixel have to be 0 for transparency to work. If only one half is 0, then that half will be the background color instead. With a little care, this can almost be used as an additional color. (Setting bit 1 of the CTRL register (kangaroo mode) causes color 0 to be background instead of transparent in all cases.)
Finally, the 320 modes can cause color artifacts because the pixel frequency is the same as the color modulation frequency. The 7800 game Tower Toppler uses this intentionally and with great effect. An alternative is to set bit 7 of the CTRL register (colorkill) which suppresses the colorburst causing the graphics to be black & white.
-
See Session 13: Playfield Basics for my comments about the VBLANK control bits and some other comments about VBLANK usage.
-
A homebrew is so little of the original games code left, or enough different in code, or playability to declair it it's own game.I'd say that homebrews are started from scratch, possibly using routines and ideas from other works. While hacks and hackbrews are modified versions of existing games (to a lesser or greater degree). It's kinda like music: are you sampling a riff, or re-interpretting the whole song.
Take Eric Ball's Skelleton as an example. There is one other game on Atari 2600, that's first person, but it looks very different different, and plays very different.Just to clarify: Skeleton was programmed from scratch. I wasn't even aware of the two or three first person maze games for the 2600 when I started. Any similarities between Skeleton(+) and other 2600 games is co-incidental.
There are other games (like Space Instigators, I believe) where the gameplay is similar to another, but where the code is unique. (Question: do Jammed and Crazy Valet share any code?)
For me the difference between a hack and a hackbrew would be whether the creator made changes which required disassembly & re-assembly.
-
As far hacks needing a mod'd 7800, the a78sign program works just fine for hacks as well as new games.
But from what I've heard, the 7800 graphics are stored in a format that's harder to hack. Any 7800 programmers care to comment?See A 7800 hack request over in the Hacks forum for some possible starting tools.
For pure graphics hacks, the first challenge is figuring out which mode(s) the game is using. That will give you the bit to pixel/color mapping. Just like a 2600 hack, the color (or palette on the 7800) will require some disassembly to change. (And disassembling is non-trivial.)
But I'd really prefer to see other people take up the challenge of programming the 7800 rather than make a "Kill Dr. Phill".
-
Made a bunch of tweaks and a fix to the thrust & velocity tables. (Thanks to Rob Mitchell for pointing out that shots down didn't go straight down.)
Changes (based on your feedback):
- decreased gravity
- increased thrust
- decreased top speed
- increased speed of rotation
- decreased shot speed and range
I've also played a bit with the PDP-1 SpaceWar! under MESS, and I found the thrust very low, even lower than my previous version. I simply found it very difficult to fight gravity. Although my version may be more "arcade like", I think that makes it more fun.
Some other notes:
- Due to how the 7800 works, I will not be able to duplicate the Expensive Planetarium in the 4K version (not saying there will be a >4K version thuogh). I will however resist temptation to make the background something other than black.
- Just like the original, touching the singularity will destroy the ship. (Although my version will have a larger collision area than the absolute center.)
- The current version only allows two shots total onscreen at once, with a third shot replacing the first. This is a temporary side effect. I haven't decided how to handle shots yet. (I'm also not inclined to limit shots or fuel, though I have a wicked idea for hyperspace if that gets implemented.)
Oh, found a different PDP-1 Spacewar (via Google Groups)- a punchtape image! Uncompress the attached file into the mess/software/pdp1 subdirectory. Select PDP-1 then the spacewar.rim file in the MESSGUI and press Ctrl-Enter to load (this takes a while).
-
Eric - do you think you might do another project after this? A game that makes use of 128K or more would be nice. :-)128K? I'd get agoraphobia
But if I ever get back to Leprechaun, I'll try to put in as many levels (2K each) as possible. -
MESS supports PDP emulation and the 1960's Spacewar game. (unfortunately the keyboard functions for left / right turn are backwards).If someone can point me to the "ROM" for the PDP-1 Spacewar (other than through FilePlanet) I would appreciate it.
I just tried it too! The Sun looks truely PDP like!
See my PM about concerns about the shot angle, distance and speed.
The gravity feels just right ..
I think that alot more thrust should go into motion .. to avoid crashing into the Sun and each other. (ie slow down the action and increase the strategy.)
I think the ships could be 1/3 smaller which with other changes will increase the gameplay arena.
The player can deliver alot of shots .. fill the screen with shots .. which takes away from the strategy aspect of the game. Maybe the shots should go slower and shorter?
As it is right now .. I think the gameplay is too much like 2600 Space War (which has less gravity) and Vectrex Space Wars (too fast, no real gravity element) and not enough like PDP Spacewar gameplay.
These two ships should either utilize or fight the sun's gravity gradient to establish an orbit to reach the enemy or wraparound to get the enemy. Not shoot off a barrage of lucky shots and knock off the enemy all the way across the screen.
The shots should be much smaller and their velocity should be much slower. I wish the shots momentum would be relative to the velocity of the spacecraft which fired. On PDP emulation the shots fired as the ship orbits close around the sun make for some pretty cool shot patterns.
Gosh .. it is hard to imagine that this game was programmed 41 years ago (1962, the year I was born!) and it is so much fun! I look forward to your final game program!
One more thing: Are you gonna reset the ships to their starting positions (or some random spots) after every successful kill?
Rob Mitchell, Atlanta, GA
It's interesting that you are okay with gravity & want more thrust, while Mitch wants less gravity and lower top speed. Smaller ships is something I've considered and may try. Would one active shot per player address your concerns about strategy?
The shots are supposed to be some kind of light-based weapon, so they are unaffected by the ship's velocity. (Yes, that's also easier to code.)
I haven't decided yet how I'm going to handle kills etc.
-
cut & paste from a PM
First I want to say Thank you for the awesome work you have done so far on this great classic. Not only that but your also starting what I hope is a very nice and long trend of into some 7800 homebrewing.I do have a few things that came to my mind about Space War as I was playing this latest build.
First eveything looks great! You have somehow managed to capture a very vector like effect better than I have seen from any other raster based system!
However, Lighten that singularities gravity a bit ehh? At full thrust is can be nearly impossible to escape the thing and the only way to do it currently is to slingshot your self around it.
Increase the turning speed of the ships a bit more...they move like a couple of Kenworth trucks!
Shot life is way too long. The shots should only go one about a full screen across max. Right now they appear to cover the screen twice?
Thanks for the compliments & feedback. Yeah, I've been thinking myself that gravity is a little strong. I'll play with it a little and see if I can come up with something better. Although, with the gravity at its current level you have to pay attention to it... Turning speed is also something I will tweak slightly, though I don't think I want to make the ships turn on a dime - too easy. I'll also decrease the shot life.
Okay that is all for the physics aspect of the game and gameplay.Now for a small idea. I know the original didn't have color. But would it be possible to alternate a yellow and white or orange and white effect on the singularity? What about making the ships a different color?
What if you could make the ships be a certain color, and then have one side of them get lit up in respect to the sun or singularity? hehe...
Just some thoughts. The color bit could even be selectable so that die hard fans of the original wouldn't have to play that mode if they didn't want.
What are you going to do for sound?
Okay..enough questions from me. You wanted some feedback...and there you go. Again, great work! Perhaps I too can learn this 6502 code someday?
I don't think I'm going to do too much with color, though I might do some stuff with different shades of grey. Sound - don't you know there's no sound in space? Seriously though, once I get the physics nailed down the next challenge will be collision detection, especially since it looks like I'm going to have to attempt to code for bit/pixel accuracy instead of simple X/Y bounding boxes.
-
I have added the fire code to Spacewar! No collision detection though so you will have to judge whether you hit yourself. The gravity well (singularity / star) is also displayed (and looks quite nice).
I am asking for anyone and everyone to give this version a try and give me some feedback. Some items I'm interested in:
- bug reports (I've only played via MESS)
- shot speed, thrust, gravity & rotation speed: too fast or too slow
- ship & shot size
PS The 8K bin for CC2 owners is now signed. Thanks Chad for pointing out a78sign will work without the a78 header.
-
I've been reading through RCorcoran's PDF (up to chapter 7 so far), it's very nice. However the commentary bits need some work (though I'm pleased to see that many of my comments have been included). Sometimes it needs a some additional context, or probably should be moved to another chapter (e.g. the discussion about mul/div in chapter 6 should be in chapter 4 and have the context of the 6502 ASM book.)
-
This puts a serious crimp on the kinds of effects you can do from frame to frame because you can't really hold pages of bitmaps in RAM.MARIA is a sprite based engine, so the concept of a bitmap display doesn't exist. I guess you could do something bizarre with tiles (indirect graphics), but it wouldn't be a traditional frame-buffer bitmap. Plus, there really isn't enough time for the 6502 to be redrawing the bitmap on the fly.
I think this is one of the reasons why the 320 mode wasn't used as much, because RAM was scarce. That and because you can't get as many colors per line at 320 mode.Nope, 320B has the same 2 bits per pixel from 1 of 8 palettes that the traditional 160B mode, though with out-of-order bits.
-
2) Sound - I've seen this topic covered before on the 7800. Yeah Im gonna search and read about it, but in a word, BLAH! A lot of the games sound like 2600 games. The sound on this system is definetly a letdown.Of course the reason for that is the sound (except for the couple of carts with onboard POKEYs) is generated by the TIA, the same chip used in the 2600.
-
You might want to have a look at the source code from Skeleton+ I posted to Stellalist, and the mini project diaries on my website.
-
I've just added the gravity and thrust code so the ships now move. Download now! (CC2 8K bin included.)
-
if its an homage, you'll have to make it open source ;pIt is open source, or didn't you see that I have included commented source?
Also .. would you compile it to a BIN file (8k) so that those of us now beta testing the CC2 can try it out on real hardware?Chad's CC2 firmware doesn't handle 4K A78 files? Sounds like something which should be easy to add/fix. Otherwise add an ORG $E000 before the A78 header section and re-assemble.
-
Some more notes:
As Albert pointed out on the front page, SPACEWAR! was originally done for the PDP-1 (although a version most likely exists for the PDP-11). I am not doing a port of any specific version, just using the basic ideas & title. Call it a homage if you will.
My desire is to have thrust, gravity (with a killer signularity) and shots (not affected by gravity, just like the original). Two player only, unfortunately. I will try to put in the hyperspace manuver too.
Thrust should be accurate. Gravity is approximated somewhat. Once I get the movement code done (in progress) we'll see how well it works.
-
If you want to get rid of the artifacts, just turn off the color. I did that on the 7800/2600 Monitor cartridge so the text was readable. This also gives you "true" black and white on color televisions.I have done that; I suspected it might help. Thanks for the confirmation.
-
Most of the answers to these questions can be found in the project diary, but I'll answer them rather than force you to read my rambles.
How complete is the game so far? Any idea of how long until you're finished?Right now I've got the basic display kernal working and the players rotating. Player movement (thrust and gravity) is next. I'm working on it when I can, though now that I can see something I have more incentive.
Please make PAL version compability too
The code is designed to be converted to PAL without too much trouble.
Things I want to see: several game options (asteroid, gravity strength, black hole, inertia), expensive planetarium, variable ship damage, like the arcade version, computer AI maybe? and of course, proper amounts of fuel and ammunition (as well as range of your bullets).I was thinking maybe even making something like a galactic map where you can or need to warp to where you can goto a different solar system with a different type of sun/gravity pull, etc.Unfortunately, I doubt I will be able to put in your suggestions as I only have currently 667 bytes left in the 4K cart. (Why 4K? So it can be put on a standard 2600 4K PCB; and compete in next year's 4K compo.
)Heheh. Been a few years since I've seen someone "discover" artifacting.
I've been working with component instead of composite for too long. I'm still puzzled why the 7800 has so many 320 modes when they can't avoid artifacts. At least you read my ramblings. -
In some of my previous posts I've hinted that I have been working on a 7800 homebrew. Well, I'm now ready to reveal that I am working on bringing the PDP-1 classic Spacewar to the 7800. Although it is nowhere close to finished, you can download the current source code (with comments!) and binary.
There is also a lengthy project diary over at www.videobrewery.com, for those interested in the my ramblings.
7800 Spacewar uses the 7800 320x1 mode (320A), so MESS 0.74 or better is recommended.
-
Even if you did manage to get a bunch of DPC's and etched boards that supported them, you'd never be able to change any of the graphic colors or sprites. They're all encoded in the DPC. Essentially, you'd need to be a hardware wizard and create your own DPC clone out of a PIC or some sort of hardware. Lots of effort here.Isn't Pitfall 2 just one chip with the graphics and code ROMs included with the DPC logic? (At least that's what the patent seemed to suggest.) If so, then it would be impossible to hack Pitfall 2 without creating a DPC clone.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
What's the best platform for playing with assembly language?
in Programming
Posted
Nope, although there are a lot of similarities, there are some major (and minor) differences - starting with 16 bit X, Y & S registers.
Of course, what make a computer/console isn't the CPU but the other chips.