-
Content Count
1,884 -
Joined
-
Last visited
-
Days Won
1
Content Type
Profiles
Member Map
Forums
Blogs
Gallery
Calendar
Store
Everything posted by Propane13
-
Whoa, wait a sec-- that is an interesting idea for a trick. So, are you suggesting that when you start drawing the "blank lines" of the screen (i.e. overscan), you can do the following: - disable MARIA output - adjust the stack, since you ain't coming back from this DLI - start your calculations And then, when you're complete, wait for vblank, and then re-enable MARIA? That's a slick idea. But, would it work? I wonder if anyone's tried it. -John
-
Hello! So, I was working on a project, and then a situation hit me that I think could be a real tripping hazard for 7800 programmers. If I remember right, if you have more cycles of calculations than the space between VBlank starting and MARIA's next screen drawing routine, then on real hardware, you'll have some issues. I think (correct me if I'm wrong) that MARIA will go ahead and start drawing the next frame, interrupting whatever calculation you're on, but when she returns, you may have some register corruption. I think I remember running into something like this a few years ago. Since this seems to be a valid situation that emulation does not trap (maybe it indicates that an issue is present with some subtle graphics glitches), I was wondering: 1) How many cycles are there between when VBLank starts (let's assume a worst-case scenario, when MARIA's last DLL is full of data), and when MARIA starts drawing the next frame? Is that an easy number to derive or estimate? 2) Is there any way in emulation or with a tool to see how many cycles some code is using in order to make sure you end up under that threshold? What would be perfect is if I could press a button in prosystem and have it give a count of the cycles between MSTAT reads/writes/BIT commands. If it was over the cycle threshold in 1, put the color in red, if under, put it in green. I know the 7800 community is limited, but I wonder how other programmers deal with this issue. Optimization is the solution, sure, but how do you know when you've surpassed the threshold, or how close you are? I guess the other possibility is to disable MARIA drawing when calculations take longer than expected, but I'm thinking that's more of a workaround than a correct solution. Thoughts? -John
-
I have a random recommendation for future backing up of your stuff, if you felt like learning a new skill set. I'm not sure how familiar you are with version control, but you can install a program like subversion or git. Then, if you learn some of those commands/concepts, you can back up your stuff for free on a site like projectlocker.com I currently have any code I've written in the last 3 years backed up via a git repository at that site. It's private, free, and a great backup solution that doesn't require making full copies of source to other hard drives. What makes it even nicer is that I can just run a single command to "back up" my new changes in history, and it takes about 2 seconds to do. I know a lot of people aren't into version control stuff, but once you know it, it's very powerful stuff. -John P.S. A two-player mode sounds interesting-- it'll be cool to see what you come up with.
-
Yes, the Ninja Golf hidden Joystick test does what I think you're looking for: http://www.digitpress.com/eastereggs/78ninjagolf.htm -John
-
Atari 7800 questions to people who know the system well...
Propane13 replied to Robert Carrion's topic in Atari 7800
I actually could use the answer to this myself. But, I'm not a hardware guy-- I'm a software guy. Has anyone ever replaced the cartridge port on a 7800, or found a way to make it have "better contact" with some games? -
Atari 7800 questions to people who know the system well...
Propane13 replied to Robert Carrion's topic in Atari 7800
Yeah, I'm guessing it's the contacts in your system that are temperamental. If the "pull it in a direction and hold it" method works, that means that the power is fine, the game is fine, but the connection between the two of them isn't what it used to be. A new system may be a solution, but I thought of another possible workaround. If you bought the high-score-cart or a soon-to-be-released XM module, and that had a good connection to the system (since they're relatively new peripherals), you would likely have the 2600 games work through that middle-man. Just a thought. -John -
Atari 7800 questions to people who know the system well...
Propane13 replied to Robert Carrion's topic in Atari 7800
I've sometimes had it where for some games to work, I have to "push them forward" a little bit, to make the circuit board contact a little bit better. I'm curious-- are the 2600 games in question Activision games, mostly? -
Yeah, I hope for the H2 as well, or maybe for another run of CC2's (which I am guessing is impossible). I should have gotten a CC2 back in the day as a development tool. I think I was just too in love with my EPROM programmer.
-
I just want to throw in my 2 cents here. I think that you both are talented, but in different ways. GroovyBee has always been interested in pushing the envelope-- he got a C compiler working on the 7800, made a graphics engine, and is very interested in making the 7800 an easy-to-develop platform. He is very interested in getting games out there with more than the standard 25-color-limit. And, he has lots of projects that involve hardware that are very interesting. My respect for Bob comes from another angle-- all games from what I can tell are written in pure assembly, and his ports are spot-on. When he runs out of RAM, he finds more. This guy is a bit-packing genius, who can take the constraints of "what was", and really, really push them. Is one programmer the best? Well, no. Both have their strengths. And, let's not forget Schmutzpuppe and kenfused-- their contributions are noted. And, there may be others I have missed. Any programmer of the 7800 deserves a stocking full of happiness this Christmas, in my opinion. They're keeping the hobby alive. I think I've figured out what the apprehension is. With the XM release and a potential release of a C-code development system, this is doing a really good thing for the 7800-- opening it uo for more development. I'm getting a feeling that this is very similar to the batari basic of the 7800 world. Some 2600 developers have a love/hate relationship with that tool; it had its benefits in bringing in new fresh blood that was too afraid to try programming on such an old, complicated system. Some of them went on and programmed some good games. But, it also opened up a crap-ton of "I released this overnight; buy, buy, buy" type games. In the end, for a guy like me, it all comes down to gameplay. If the game sucks, I try not to buy it, regardless of how flashy it is. Granted, people can program whatever they want-- it's not a lucrative hobby; it's just a hobby. Being honest, I am really excited about anything that comes out for the 7800-- GroovyBee's graphics from what I've seen are awesome. Wiring in new support for new hardware is also cool-- the demos are really interesting. Bob's bit-packing arcade ports are also awesome. I think that both approaches can live in harmony. But, both sides need to give a little, otherwise this could get divisive. The XM's potential benefits as a programming platform are vast, but it does have two issues that I have to learn to get over. The first issue is that if I show off my 7800 collection to my programmer friends, and they get really excited about Midnight Mutants pushing the envelope, I can then I say "oh yeah? Check this out!" and then plug in my XM and an XM game. It will make them go "no way!", but then I'll also have some explaining to do. I'm sure my programmer friends will will think it's some sort of overclocker or cheating device that doesn't really match what could be put on a 7800 cart-- they may not understand that it expands what could simply have been put on a cartridge. But, at the end of the day, it's not a big deal, but it is a realistic issue, even if it's small. My other issue is that I also really like having the option for XM games without an XM, just so I can have a standalone cart to brag about. Even if it became more expensive to do so-- that option seems like it won't be available anymore. I'll have to learn to deal with that as well, but that is another con that I see. Maybe it's just personal preference, but for some reason, I picture the XM as a way to save money on extra hardware that you "could have in a cart", but some part of me may want to spend the extra money to have a fully-loaded cart. I also was worried about XM becoming "standard", because there was a comment made awhile back that was very glad that there would be no more TIA sound. We also need to recognize that there may be non-XM games coming out too that could be just as exciting. They may not be as graphically intensive, but they could be fun, and playable. It's up to the programmer to decide what to use, but at the end of the day, XM and non-XM can create fun games, all the same. Now, I can't just talk about that side again saying how exciting the XM really can be. Pushing the envelope of what could have been is really cool-- we can put character maps completely in RAM so that we can have awesome "morphing graphics". We can have very large worlds defined. We can have amazing arcade-like sound. We could have a keyboard-based came, or a series of them. Such things are wonderful for attracting new developers, and this system has like 5 programmers on it-- it could use some more. The 2600 had a boom of programming when batari basic came out, and as I said, I feel that this is a similar push. Bob is right-- a lot of time and money has been spent on this project. People should try to be respectful. Even if you won't purchase the XM, you've got to admit that it's still a cool project-- and, anything to bring in fresh blood to a dead system can't be bad. If we get even just one new programmer, the impact to the community will be substantial. I really like the look and feel of the project, and can see how much detail and though was put into it-- it's a stellar project. For me personally, I'm not yet on the XM pre-order list, but I can explain why-- I'm a gameplay-oriented guy. All it takes for me to make a purchase is for someone to say "this game is a lot of fun", and then I'll jump on that wagon. Yes, I know-- I may not be the most supportive of guys by waiting for a release, but I am still planning to purchase once I see something in the mix that I really want. The demos are cool, but I wish at least just one of the games was a little less secretive. I know that the main reason for this is the "wow factor" on release day, but I've always found that community support makes for better gameplay; I learned that with some of my 2600 projects. And, that's the one thing that's missing for me that would make me buy the XM right out. For now, it sounds like I have to wait until release day, and then see what people say about the games. That's not an issue, but I am hoping that with everything invested, these will be the best playable games possible. If even just one of them is remotely fun to play, I have my money standing by. -John
-
I thought about how to respond to this post for awhile. Though I'm really glad to hear that there are a lot of "what could have been in a few years" type projects (and I have a high interest in purchasing them and offering my support in the community), it's also important to realize that anything that has special hardware may not be something that some programmers would want to use. I'll explain why. There seems to be a deviation growing between the "what could have been" for the 7800 and the "what was". It's great to offer opportunities to developers to use these tools, but it is worth noting that if the 7800 community gets new programming blood, there might be some people that just want to try to program for the challenge of "what was"-- TIA sound, limited memory, no special hardware. Why? Because it's hard. Very hard. The TIA sucks. The limited RAM is tough to budget. Adding more hardware into the mix changes the game (no pun intended). This is why I like programming 2600 games with 128 bytes of RAM on occasion. It's a heck of a challenge. Some people may feel that programming for the 7800's base features and limitations may also be fun. I don't want to sound unsupportive here, and I have a feeling that my comments may be taken that way. I DON'T want people to think I'm detracting from this thread's enthusiasm. I think this is a great idea, and a cool project, and I am excited about it myself. But, I can't really keep quiet on this weird vibe I'm feeling on these forums as of recently that if you don't support all of these new add-ons, your game could be considered garbage or insufficient because it's not taking advantage of all of these new things. HSC support seems to be becoming a standard instead of a "nice-to-have". I don't want the community to discriminate against those that are coding for the challenge of "what was", even if it's a game with less bells and whistles. The XM is cool, an extra-hardware demo is cool, but games that don't use those features are also cool. Providing the extra hardware support may attract more coders, and it may not. But, I definitely don't want this to become a mandatory standard in the community. Programmers should be free to use whatever they choose. Again, I don't want anyone thinking that I am not supporting these projects-- and regardless of how I express myself, I've noticed hyper-sensitivity on some subjects in these forums, and I could frustrate some people with my comments, and I'm trying really hard not to convey that. I'm just expressing a thought, that I think needs to be said. These are "tools of what could have been", and they're cool. It should be up to an individual developer whether or not they want to use them. If we get more people because of this, then great. But, if we get people that don't use the hardware-- also great. At the end of the day, more games, regardless of what category they are in means that everybody wins. I hope everyone's kind of on the same page about this. -John
-
Mine just arrived too. Many thanks, Bob. I can't wait to try this out this weekend. -John
-
They are at the same address. If the XM BIOS detects a HSC pass through cart plugged into the top slot it displays an error message. If it detects a multi-cart it disables its own built in HSC because it doesn't know what you'll choose to play. If you are mad enough to plug an XM into an XM it detects that too. XM POKEY does not conflict with CC2, Ballblazer or Commando POKEY addresses. It is compatible with the XBOARD games BeefDrop and Froggie. Ok, this is good to hear. So, in theory, there is no software change needed for say, newly-written software to be "XM compatible" with respect to the POKEY and the HSC, right? In short, I'm trying to confirm that developers only need to make the software "one way". So, if I wrote a game that used HSC, I'd have the option to use my old HSC, or to use the XM without code changes. And, if I had a game that used POKEY, I wouldn't have to compile 2 different versions, one for XM, and one for "hardware that supported POKEY", correct? That was something rattling around in my brain today; thought I'd ask the experts. -John
-
2 questions-- 1) is the HSC at a different software address compared with the old HSC I already have? 2) Same question, but about POKEY software address for "special hardware" carts vs. XM. -John
-
"The circle is now complete". Great job, man. You have real talent.
-
Do any 7800 emulators offer debugging info (like the ability to monitor a specific location in RAM)? -John
-
I get the sense that 250 won't be enough...
-
Awesome!
-
I would also like to request to be on a potential standby list.
-
The one trick for special moves is to make them happen with a combo of buttons. In doing so, it makes it more difficult to pull off-- i.e., it'll take a few seconds to press "up, up, left, left", which could cost you dearly and allow the other creature to attack. So, I'd recommend that over just a single button. Combos for Mortal Kombat on Genesis included: - A, "towards", A (so A, left, A if the opponent's on your left, A, right, A if the opponent's on your right) - left, right, up, down The combos also made for "finishing moves". So, if you knocked someone down to zero energy, they would stand there limply. You could just knock them over with any move to win, or you could type in some ridiculous code (toward, toward, away, away, start), to have a special ending to the fight. I'm not suggesting that you go with both of these options, but what I am conveying is that the combo button moves always make a game fell more like an arcade beat-em-up. You may want to consider that over a right-shoulder-button single press. Just a thought.
-
Sometimes it's good to power through, and sometimes it's good to take a break. What are you working on for it specifically?
-
Honestly, I wouldn't worry about HSC too much. It's a "nice-to-have", not a mandatory-to-have. I had no idea that it was such a RAM hog. That makes me reconsider what I'd need to do for Arkanoid. My thought is-- if you're able to make a great game without it, then so-be-it. Back in the day, the HSC support was abandoned, and no games supported high-scores. Heck, even my Nintendo doesn't save high-scores. I wouldn't sweat it if a great game got out without it. I don't know if my voice is a solitary one, but I wouldn't give up functionality or add extra RAM just to support a high-score add-on. I think it sounds brilliant as it is. -John
-
Does the step require a missile? It seems one frame overhangs the rightmost lower-dot. -John
-
Not sure why this is posted in the 7800 forum....
-
From the stella-list post, I have this written: "I can't remember which pin it transfers on, but I made a cable which connected 2 9-pin connectors via pins 1 to 3, 3 to 1, 4 to 2, and 2 to 4, but I made the demo rs232 compliant, so only 2 of those wires should really be useful. To test on itself, take a 9-pin connector and wire pin 1 to 3 and pin 2 to 4." So, that's what you need to do. The ROM is 4K, so can fit with other ROMS on certain media. I believe I tested it back in the day with one burned cart and one via SuperCharger. So, if you have a SuperCharger and a Harmony cart, you have all you need. -John
-
New release. - PAL colors supported - red pill now works (gives you shooting powers) arkanoid_2011_09_11.a78 arkanoid_2011_09_11.bin For the PAL colors, I tried my best to use "trial and error", so I would be interested in real feedback as to if anything looks ok or terrible. I know that PAL timing is a little bit off in the emulator, but that's an exercise for another day. Anyway, have fun! Regards, -John
