Jump to content

doppel

Members
  • Content Count

    67
  • Joined

  • Last visited

Community Reputation

3 Neutral

About doppel

  • Rank
    Star Raider

Recent Profile Visitors

8,721 profile views
  1. Or perhaps a "Mapping the Intellivision". :-)
  2. I have reverse-engineered the Executive ROM and the portion of GROM that has code in it. I would like to post a disassembly of it, but I am unsure about that...In the meantime I can answer questions about it.
  3. The thing is, when you change that byte's lower nybble to a 3, it gets stuck in an infinite loop.
  4. What exactly does this have to do with programming? Or anything, for that matter?
  5. One important detail that keeps getting glossed over is that in order to read the keypad in the right controller port, INPT2, INPT3, and INPT5 are used, not INPT0, INPT1, and INPT4.
  6. Feel free to disagree with me, everybody, but I kinda feel like programming the 2600 in anything but good ol' 6502 assembly is kind of missing the point. Sure, you can argue that batari Basic makes doing so easier, that it takes the labor of writing a completely new graphics engine for every single game out of the hands of the programmer, and many other points. But I feel that it's more of a learning experience to control the 2600 directly, and that tackling those challenges is the whole point. Just thought I'd throw in my 2 cents worth, for what it's worth. :-)
  7. I think it might be more accurate to state that there are sixteen different bit states that the disc pad can invoke. There are five bits connected to the disc, and the positions at which they're connected differs. Whether or not the game actually responds to 16 different directions depends on the game itself, how it was programmed, whether or not the astrological sign of the programmer was in Uranus, etc. You end up with 1 to 3 closed switches (which clears the bit on the I/O port it's connected to) depending on the direction pushed, and there are sixteen unique states. Some of the bits are also connected to the keypad and they also map to other bits, and those other bits are mapped to the buttons on the sides. And that's about as technical as I can get without actually revealing which bits are mapped where and whathaveyou. And the disc doesn't actually rotate, that's just the outside.
  8. This is Joe Z. I have a cartridge design I'm putting into production. I am actively working on making it available to a wide audience so that anyone can self-publish with ease. I don't have the bandwidth to sell these personally as "Left Turn Only", so I'm researching other options. I'll still publish my own games under that banner. As with so many things in this arena, it's a labor of love. I was hoping to be at this point over a year and a half ago, but the economy tanked, work went absolutely nuts, and I had to shelve things. The economy's back now, and there are a bunch of exciting, material developments the last few months. (Not just talk... I've got beaucoup $$$ out there in active production.) Like David mentioned, we're not in a position to announce dates. But, I've moved forward with hardware production, so the rest is just a matter of time. If I can open up the capability to a wider audience, even better. I'm actively pursuing options there so that I'm not the bottleneck. My new design is flash based and in-circuit programmable, which makes it easier to fan out to a large audience. It also supports unimaginably large games (at least in terms of ROM size), so I doubt hardware should be much of a limitation ever again. If it is, I can make a better design. 16K bytes RAM, 240K bytes ROM though should be enough to hold people for a few years.... :-) BTW, I did actually receive a couple entries to my programming contest. Not as many as I hoped, but a couple. Now that I'm moving to hardware production, I can make good on the prizes I wanted to offer. I had wanted to move to production in 2007 originally, slipped to 2008, and then had to totally can things until 2010 due to the economy (all my savings "disappeared") and an oppressive work situation. I'm back now. :-) That's a shot in the arm for those of us like myself who aren't so hardware-inclined. :-)
  9. Since I know little about GPL itself, I can't really say whether or not GPL itself was a mistake. Writing BASIC in GPL instead of assembly *was* a mistake, as was using proprietary GROMs.
  10. The one thing that actually helped me wrap my head around assembly language was figuring out that the only thing assembly language really does is manipulate bits of memory, then figuring out *how* each instruction affected the memory and registers. The only real way to figure that part out is to read, study, and most importantly of all, experiment.
  11. I didn't know there was swearing in Pong. There will be when I'm through with it.
  12. I'd be in for number 2 if I could afford it. Number 1 doesn't seem so attractive to me, because it seems basically just a "High Score Cart" that only works with a few games and contains the same plastic as the actual Expansion Module for extra confusion.
  13. But which one has priority, the playfield or the ball?
  14. I'm not entirely sure what you're trying to do, but it looks like you're trying to scroll an asymmetrical playfield to the left by rotating bits through the playfield memory. One of the problems of doing this is that you have to not only be sure you're rotating in the correct direction, but you also have to jump bits over to/from the PF0 memory used on the right side of the screen. So if you're scrolling to the left, d4 of PF0 on the right side has to end up as d7 of PF2 on the left side, whereas if you're scrolling to the right, it's the other way around. It looks like you've failed to take that into account.
  15. I thought writing to the color registers during on-screen rendering of line RAM was supposed to result in color stretching, whether or not the color reg being written to was actually in use. But I don't see any. Is this behavior not properly emulated on the emulators, or does somebody know something I don't? I was in the middle of writing my own palette demo for the 7800 a few days ago, and I had already calculated the minimum cycle requirements (195 counting worst-case startup and shutdown), and strangely enough we both had the same idea (8 bytes of three-color stripes per object, 5 objects), though mine would have had the colors arranged the other way, and no letters. I stopped midway through when A. I saw no possible way to update 16 color regs on one scanline after DMA, and B. somebody (you) had already beaten me to it about 7 years ago.
×
×
  • Create New...