RevEng
-
Posts
7,607 -
Joined
-
Last visited
-
Days Won
12
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Posts posted by RevEng
-
-
Would the Sega Genesis controller work?
A version of Defender 2 that uses the Sega Genesis controller is in the 2 button hacks thread, along with a bunch of other converted games.
The genesis B button is the regular fire, and the C button is smart bombs until you run out of smart bombs, then inviso until you run out of inviso, and finally hyperspace. The joystick 2 inviso/hyperspace selection still works too.
It's a compromise, but I find it way more playable than trying to use 2 joysticks. I concede that a custom controller would be the best solution.
-
While up-down scrolling is pixel perfect I think Batari BASIC can only do side scrolling a playfield pixel at time.
Yup, though it's a 2600 limitation, rather than a batari Basic one.
Nice demo! It looks like you're hitting 263 scanlines instead of the usual 262, but that should be easily enough fixed up.
-
Well first, what kind of things would potentially need to be modified. As in, why is it that you even need to modify it.
You'll want to modify it when the display kernel doesn't give you what you need for a game.
You may find one day you want to make a game with 2 sprites on the top of the screen and 2 on the bottom, with an asymmetric destructable playfield and no flickering.
Or you may decide you want a 4 color playfield that uses flickerblinds. Or a screen that displays a 5x5 grid of colors with a unique color possible in each spot. Or some weird kernel that nobody has dreamed of.
Or you may find that the standard kernels do exactly what you need.
Give the bB manual a read, look at what people have produced with it, and see if it matches the games in your head.
But either way, its a good framework in which to learn about the 2600 and assembly language.
-
How hard is it to modify the kernel?
It depends on what you want to modify.
To use a car analogy, its like you're asking me how hard is it to work on an engine.
Upgrade the spark plugs or air filter? Easy. Replace the radiator? Not as easy.
-
I believe these games use the stock bB kernels, and they've been released on cart...
Gingerbread man
Cave-In
Evil Magician Returns
Dodge-it
Solar Plexus
There could be more. These are just the ones I know of.
-
If you use bB without any assembly, you need to use one of the provided display kernels.
While the bB kernels are very flexible, certain game designs will either require a custom kernel, or will look better with one.
Many successful bB programmers don't know a lick of assembly, so its definitely not a requirement to getting games made.
-
There are 2 distinct disciplines involved in creating a game for the 2600. One is coding 6507 assembly, and the other is tweaking the 2600's hardware registers to get what you want to happen.
Even if you plan to eventually learn assembly, my recommendation is to take the bB route first; it will allow you to get your feet wet with the hardware registers.
Then when you're comfortable with that (and if you still decide that you're interested in assembly) you can use bB to get your feet wet with assembly, by writing inline asm, minikernels, and alternate kernels.
-
So near, yet so far.
Carry on.
-
Philsan, I had a thought on how you could use "no_blank_lines", use whatever color you want on the meteor, and still achieve a side thrust effect...
If you increase the shading a bit on the upper module, I think you can get away with adding a "blank" line between the upper and lower module. This would be colored red and have no data. Then you just change your sprite data when the thrust is turned on.
"A" represents the easy way to do it with your present 7-pixel wide sprite. If you get a bit more fancy, you can do "B" with an 8-pixel wide sprite. In this case you'd need to mirror the sprite and temporarily re-adjust its position depending on which side the thrust is on.
-
Check out the discussion in the best prince of persia thread.
-
...But I was also working on the aforementioned breakout style game when I created a playfield, tested how it looked, then noticed that the playfield has thin horizontal blank lines. Does anyone know how to eliminate this?
Use the no_blank_lines kernel option. It does come at a cost though, so read that link before you enable it.
-
On the theoretical side...
- We're talking about a 2-cycle difference. Count up if it makes your bB code more understandable, as that's more valuable.
On the practical side...
- A countdown loop to zero in bB isn't optimized. It still uses a "CMP #0" before the branch. So there's actually no savings.
-
1
-
Do you think your titlescreen kernel could be added to this game?
If yes, with which image?
You're presently using 2 banks. Really I'd recommend that you mostly dedicate most of a bank to the titlescreen, so you might need to go to 4 banks... if this isn't a problem, then a titlescreen is doable.
Nothing comes to mind initially for images. I'll mull it over.
The other thing you need to figure out what else you want in the layout - what text do you want displayed, if you want the score displayed, game selection (probably not, based on your code so far), do you want scrolling text, etc.
-
I've always wondered why Nintendo doesn't do a 2D Smash Bros like that for the DS/DSi. Seems like a no-brainer to me.
It's not like the console game actually uses 3 dimensions in any meaningful way.
-
Close enough for a contest to me.
Here are my entries. The source images are also from NASA, and under the usual terms...
If you don't use the text one, I'd still suggest you reproduce that plaque somewhere in your instructions, as it's too cool.
-
I have a feeling the demo might need to be reworked a bit for real hardware. I didn't have a harmony at the time, and I learned about the "starting in any bank" thing after I wrote it.
Also, the demo relied on the games being 4k non-bankswitched. JH is 8k, so you'd still have to rework it's ASM code to do the right thing if the 2600 started up in one of the JH banks.
-
While it's possible, its going to take a fair amount of effort on the ASM side...
You could include the ASM in a bB program, but you'd need to modify JH so it fit in the free banks and bank-switching played nice with bB. The VCS can start in any bank, so you need to modify the Jungle Hunt code to bankswitch to the bB bank.
Also, the titlescreen kernel has overscan and vblank code that matches the bB kernel, which does things in a fairly unique way, to allow for cycles and cyclescore. This code would need to be matched to the jungle hunt kernel's way of doing things, or else you'll get a big screen roll during the transition.
-
Did he draw the 0's and 1's himself or did he convert an image?
In the case of the "RevEng Presents" text I drew the 0's and 1's. One of the design goals of the minikernels was to keep the data in a easy to edit format, and its pretty easy to manually bang out letters in a 3x5 monospaced font once you get used to it.
For more complex stuff like images, I used Gimp and a different (more complicated) export process. But since then, I've exported images through ImgToCode with great success.
I used a thin Gimp font for the scrolling Knight Rider text demo, and it didn't turn out too badly. I started off with the image at the 48x256 resolution I needed, bumped down the font size and played with the hinting settings.
Is there an image or some text you want to display? I can post the steps I'd take, and you can give them a shot, and we'll see where things are going wrong.
-
I missed editing the routine in another bank. Hopefully, this is straightened out. No way for me to check this (because Z26 doesn't support 2 buttons and Stella no longer works under Win98), so I gotta play it by ear.
I hacked in genesis controller support to z26...
...You only need to use the z26_20040523_genesis.exe binary, but I included the source as it was the easiest way to comply with the GPL.
Use the CLI switch "-)GC" for the genesis controller. Left ctrl is the Genesis-B/INPT4 button, and right shift is the Genesis-C/INPT1 button.
-
A quick definition to make the language easier. The two number representations we're talking about are usually referred to as "signed" (for a byte, -128 to 127) or "unsigned" (for a byte, 0 to 255).
The slightly shorter answer to your question...
The 6502 doesn't really know about numbers being signed or unsigned. The numbers are laid out in such a way that the math will work out the same from a binary perspective.
If you're not doing anything in the context of signed numbers, you should consider the numbers as being unsigned. So your loop from 1 to 255 is just a loop from 1 to 255.
If you do something like "if mynum<0 then goto someroutine", then you are treating mynum like a signed number, and you should probably consider stuff like 255 is the same as -1, and that a signed number rolls after 127 instead of 255.
The longer answer to your question...
The 2 number representations, signed and unsigned, are mapped out in such a way that the arithmetic works out the same whether you think of the number as signed or unsigned, with the exception of the limits where the numbers roll-over. (i.e. from 0<->255 or -128->127)
This mapping system is called two's complement.
Here's a quick summary of how unsigned and signed values are mapped out in two's complement...
Signed Unsigned Binary 0 0 00000000 1 1 00000001 ... 127 127 01111111 -128 128 10000000 -127 129 10000001 ... -2 254 11111110 -1 255 11111111The CPU actually doesn't actually know or care if your program is expecting to use a number as signed or unsigned. It just adds up everything in binary, and leaves the signed/unsigned context up to you.
Consider the signed expression "-2 + 1 = -1" and the unsigned version of the same expression "254 + 1 = 255". The binary math works out fine whether you treat the numbers as signed or unsigned.
So for your loop from 1 to 255...
The CPU just counts from 00000001 to 11111111.
From an unsigned context, the loop looks like it goes from 1 to 255.
From a signed context, the loop looks like it goes from 1 to 127, then rolls over, and goes from -128 to -1.
But remember that the actual context comes from the way your code treats the number. It's a bit weird to loop from 1 to 255 and do tests for negativity and other stuff that would imply signed values, so you really wouldn't be thinking in terms of signed values as you coded this loop.
Hopefully this has helped, and we haven't had more worms escaping from the can!
-
The interesting thing about your arrow analogy, is it can be modified to be analogous to the way 6502 byte arithmetic works.
If the universe was only 256 feet long, and you shot your arrow 255 feet, it would wind up 1 foot behind you. (assuming space curves back on itself.) You'd also be wise not to shoot the arrow 257 feet.
Similar to the arrow in our 256 foot universe, when you keep adding one to a byte and it reaches the 255 limit, it starts over again at 0 and continues up.
In this kind of system, you can treat bytes as if they were from 0<->255 *or* from -128<->127, depending on which suits your needs. Mainly this is handy in assembly code - one example is when you want to check if a number has become less than zero.
To answer your question about counting down from 255, the number stops being negative when the you reach 127. (but "stops having the same representation as negative numbers" is probably a more accurate way to describe it.)
-
To access "score" as a variable, you just need to access the 3 component bytes with different variable names...
dim sc0=score dim sc1=score+1 dim sc2=score+2 rem to check score is 1000... if sc0=$00 && sc1=$10 && sc2=$00 then ...
The dollar signs are important, as the score is held as binary coded decimal.
-
That's excellent news! I believe I'll neuter some pads and mark them specifically for the Atari somehow.
I've updated the FAQ in the first post to include the pin 5 info. Thanks nems!
I've also added 2 button versions of Mouse Trap and Sea Hawk to the first post as well.
During hardware-testing I noticed that I accidentally enabled the fire button during the Sea Hawk attract mode. I think I'm just going to rename it the "auto-pilot trainer mode", and call it a day.
-
Find the gun first!
It's up one screen from the start.
-
1
-
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Starting with straight 6502 or BatariBasic?
in Atari 2600 Programming
Posted
Certainly there are fewer instructions, but in Assembly the contexts in which those instructions operate are a lot more complex.
bB coders don't need to know about 6502 related topics like two's compliment, carry bits, overflow flags, BCD, various addressing modes, how the stack works, etc, in order to create games. Similarly, on the 2600 front they can also ignore details about horizontal positioning code, skipdraw, six-digit score, asymmetric playfield timing, bank switching, etc. And that isn't to say they can't later explore these topics within bB if they like.
Take all of this with a grain of salt, because I pray at the altar of the opcode too. But I think there's great value in the fact that one can write their first "move the guy around with the joystick" 2600 program from scratch with a few lines of code.
@Omegamatrix: I've mostly given up on helping people who keep their variables named after the alphabet and use no comments. Its not out of malice or anything; it just takes too much time to follow the spaghetti and understand the context of the variables in their program, and by then I'm bored and on to something else.
It would probably be helpful to have a recommended style guide section in the bB manual. Something with the usual comments on self-documenting code, indentation, etc.