Jump to content

RevEng

Members
  • Content Count

    6,847
  • Joined

  • Last visited

  • Days Won

    10

Everything posted by RevEng

  1. Why bury your head in the sand? Something can be done about it in most cases. In the case of the 2600, the only parts that can't be easily replaced is the 6507 processor and the TIA. Creating functional replacements using microcontrollers or FPGAs wouldn't be a colossal task. I believe there are already open 6502 FPGA cores available. If it's really a huge worry, see what you can do to jumpstart the Stellacon/Open 2600 project. Also, get yourself a regulated power supply if you want to be kind to those capacitors. The less ripple they see, the longer they'll last. In the case of the a8 computers, get yourself some SIO2SDs or SIO2PCs. IMO an SIO2SD is a reasonable tradeoff that will allow your "drive" to last hundreds of years.
  2. HDMI is definitely more convenient. You'd probably notice a small difference between it and component if you did A-B tests, but its not a big enough difference to be noticable in practice. Bascially the edges of stuff look slightly crisper. Be sure you get the most expensive Monster brand cable you can. The 1's and 0's enjoy their transport over an oxygen-free latinum-core cable better, and will provide happier entertainment on the other side of the TV. Seriously though, feel free to cheap-out on the HDMI as much as you like, though some of the super-cheap ones are a bit flimsy, so watch for that. And if you're thinking of upgrading your speaker wires, try coathangers.
  3. MausGames, not sure what you mean. Wouldn't scrolling every other line in alternate directions just make the lines jiggle? Or do you mean scroll the lines in alternate directions until they're off the screen, like a fancy screen wipe? Michael, that was an excellent suggestion, but I figured I'd write the superchip version and write up a rolled-up version at the same time. parallaxwrap.bas.bin parallaxwrap.bas
  4. White nerd here, late 30s, and I used to DJ all kinds of music back in the stone age, including rap and house. Used to scratch and mix on beat with the best of them. I think this DJ controller might be a major fail . One of the reasons why GH is neat is your hands do a crude approximation of what a guitar player does. This DJ controller thing just fails. Buttons on different parts of the record? WTF?!? And it would have been just as easy to just make the buttons part of a fake cross-fade/level control instead. I'll give it a shot in a store someday, but I'm not expecting great things.
  5. Ah, looks like I misread the bB guide. Dang. Well, easy enough to adapt. Each asm roll needs to change to something like... lda r000 ror ; or rol depending on which pf byte sta w000 Unfortunately I don't have the time right to fix it in time for your halloween demo. If someone doesn't beat me to it I'll post a real SC parallax example in a day or so.
  6. If you constrain yourself to using the parallax in the portion of the playfield that uses normal ram instead of superchip ram, it's fairly easy to do by rolling your own scroll routines. Disclaimer: I'm no great shakes at 6507 assembly... [edited the code out for brevity.] ...this is just a first pass. You could make a short general line scroll instead of unrolling the code like I have here. But hopefully this puts you in the right direction. If you need to use parallax with the superchip ram area it becomes a bit more involved and cycle hungry, because you can't simply roll the memory locations. You need to read in the read-location sc-memory, roll the resgister, then store the result in the write-location sc-memory. parallax.bas parallax.bas.bin
  7. Very nice! You've managed a very difficult feat. You've tweaked the gameplay of a classic and actually made it better. Well done!
  8. Nice technique! That will come in handy!
  9. I think this is quite a good start for a neat puzzle game. A few suggestions... It's a bit frustrating that there's no undo or fix a solution you've worked on without a total restart. This is especially true since you can drop pieces outside of the solution area. Once you've reached the last piece can the fire button go back to the first? Also frustrating, but less so, is the fact that I can't move my new piece past any placed ones. Is this a technical problem, or an intentional game element? That said, I enjoyed it despite these nitpicks, so I think you're on a good track. I know it would be a fair bit harder, but if the puzzles could be randomly generated it would add to the replay value infinitely.
  10. jrok has been plugging away nicely at Circus Galacticus lately. I'm sure he'll come back to this one sooner or later.
  11. On second thought, provided the playing area stays where it is, you can do that without the mask and make it even faster... if var4 < %11111100 then goto notsolved if var8 < %11111100 then goto notsolved if var12 < %11111100 then goto notsolved if var16 < %11111100 then goto notsolved if var20 < %11111100 then goto notsolved if var24 < %11111100 then goto notsolved rem if we're here then the puzzle was solved! goto levelsolved notsolved
  12. Nice concept! The easiest way to do is to check the 6 high bits of the appropriate playfield vars... temp7=var4 & %11111100 if temp7 < %11111100 then goto notsolved temp7=var8 & %11111100 if temp7 < %11111100 then goto notsolved temp7=var12 & %11111100 if temp7 < %11111100 then goto notsolved temp7=var16 & %11111100 if temp7 < %11111100 then goto notsolved temp7=var20 & %11111100 if temp7 < %11111100 then goto notsolved temp7=var24 & %11111100 if temp7 < %11111100 then goto notsolved rem if we're here then the puzzle was solved! goto levelsolved notsolved ...but if you later decide to move the puzzle area you'll need to adjust the code.
  13. Ah, didn't realize that // was used for the remainder. I guess I haven't had a need for it yet! ; and /* */ comments in bB would be perfect. I don't use vbB. I use cygwin and a makefile. My hack of the preprocessor changes everything after the // into a REM on the next line... [ \t^]*"//".* {printf("\n rem %s",yytext);} Ugly, but it works for dim and pretty much everything else, but not within data/sdata statements.
  14. I hacked my own preprocess.lex to allow for C++ style // comments. They can go in after a statement (dim or otherwise) or on their own line. In the assembly source they get thrown into the next line, which I think is a not too bad a compromise. I'd love to see this, and C style /* */ multi-line comments be integrated into the official bB. The later is *way* handy for disabling large blocks of code when you're tracking down a bug.
  15. Looking good! Its probably on your to-do list, but you need to clear the sound registers when the game ends. Sometimes if there's a sound effect in-progress right before the end game it plays throughout the title screen.
  16. [edit] nevermind... I see that it was sdata causing problems, not data [/edit]
  17. I'm sorry to hear that. My family and I will pray for you to lose your phone/Internet/cable next week. Keep the faith!
  18. Some possible methods of case fabrication: rapid prototype aka 3D printing... too expensive ($100s or $1000s per part) and takes very long per part. Injection molding... Initial setup is expensive. May be cost effective depending on your definition of "small run" NC mill... Similar cons to 3D printer. DIY vacuform... Case needs to be simple and designed with this in mind. Check benheck forums for examples.
  19. I had a fuzzy 4-switch 2600, and ordered and installed longhorn engineer's video mod. I am very pleased with the results. Build quality is excellent, and the screen looks great to me even through the composite output. (It has s-video as well) As a bonus, you get stereo sound output too. As for general advice, supposedly cleaning the connectors and/or replacing the RF cable with a heavier one helps. Doing that didn't have much effect on my 4-switcher, but I have a feeling it may have had a problem with the internal RF modulator.
  20. In truth I never thought SD card capability was important, seeing that there's already a 2600 SD cart solution. Curt seemed to express some interest in this thread, so I thought this might go with an updated FB2 core (which Legacy Eng owns AFAIK) and eventually be done with an ASIC. IMO if someone else is going to take a kick at the can with the software emulation route, they might as well take the GP2X approach and emulate multiple platforms (with sd card). No technical reason why it couldn't support 2600/7800/colecovision/etc and even some of the early arcade units.
  21. It depends on what "good enough" is. It plays Stella as well as I've seen it run on any PC. IMO that's not good enough, but it depends on how high your bar is. Its soft-moddable, and there are lots of guides. But my point really wasn't about the xbox per se - it was just one example. The point was, if software emulation is good enough then there's not much point in creating a specific platform. The user can readily find one that suits them... Whether its a used xbox, a castaway pc, a used wii, or whatever.
  22. Maybe Curt could verify this, but I'd guess that fb2 had a lot less dev time and iterations than stella has seen. With the exception of a few fixable issues, its pretty near perfect itself. I owe its success in such a short dev time to the approach chosen. (And to the implementors, of course) If a vcs emulator is good enough, the someone should just create a usb cart interface and leave the rest to the end-user. People can get a used xbox cheaper nowdays cheaper than we can make a console for, microcontroller or not.
  23. Definitely true that emulation is emulation, whether it is in hardware (through an FPGA or ASIC) or software. The gates and such in an FPGA version of a chip are unlikely to have the exact same characteristics as the original. But emulation in hardware happens at a lower level than software - signals, gates, etc. are recreated as faithfully as possible. Emulation in software is necessarily at a higher level because realtime emulation of circuit pathways in software for any complex design just isn't feasible on today's CPUs. Instead you get a higher level state machine which lacks the subtler undocumented characteristics of the original. Regarding video improvements, due to the way the programmer controls much of the 2600 video timing, the only way I see it being fixed for modern TVs is a complete framebuffer approach, where an extra layer of hardware would take the outgoing video as an input and build a frame in memory, and ouput something more accurate to NTSC standards. Doable, but it would be prone to errors too, and I suspect it would add significantly to the cost.
  24. Just an aside point that any patents on 2600 tech ran out long ago. The only reason anyone would need to approach Atari is to actually use the "atari" brand name or to license their games to include with the console.
  25. Looking forward to it RT! It sounds like an original!!!
×
×
  • Create New...