Jump to content

Bruce Tomlin

Members
  • Content Count

    3,690
  • Joined

  • Last visited

Posts posted by Bruce Tomlin


  1. from your website:

    no battery needed, powered by the console  

    makes me wonder, what's the maximum load the 6532 can drive ?

    The joystick ports have a +5 volts power supply pin. The 6532 doesn't need to provide power.

     

    The 6532 outputs can definitely drive one TTL input, and I wouldn't be surprised if they can drive four or five of them. (Standard TTL and LS TTL can have a 10:1 fan-out to the same type of TTL input.) I have in the past used the joystick ports and a MAX232 chip to do 2400 baud serial output.


  2. I will say one thing about programming the 7800, after having written some code over the past month. I really wish there was some sort of "jump instruction" in the display list handling. If you have a mix of fixed and moving objects on the same scan line, it looks like you have one of two options:

     

    1) build the display lists from scratch, using the wonderfully expensive STA (ptr),Y addressing mode - this can easily take more than 1/60 of a second. Because of this, I understand why they made Maria II.

     

    2) pre-build the display lists with "holes" at the end of each scan line large enough for every possible object in that zone (remembering that objects appear in two zones if they're not all vertically zone-aligned). Then just fill in the holes.

     

    I initially started with method 1, for a pair of 8x10 sets of 16x16 pixel blocks, each as a separate object, generated from an array of block type indices. Not too efficient.

     

    Then I changed it to use character mode. This meant every block had to share the same colors as its neighbors, but I wasn't too worried about this. The code to generate the character table from the blocks array actually took more than 1/60 of a second. So I changed things around to update both arrays at the same time. A little harder to read the code, but it was fast enough to be useful.

     

    My next plan, once I get an important game mechanics algorithm working, is to try method 2 so I'll have enough CPU time to run that new algorithm. I only have two moving sprites, so this won't be much of a RAM waster, but it will be a big CPU saver.

     

    It sure would be nice to see how Robotron was programmed to handle a lot of sprites on the same line.


  3. I gotta agree about covering over those EPROM windows. Foil tape would be the best thing. You need something which blocks the UV rays.

     

    It's not important when it's just a test burn of something, but when it's a soldered down game for which you don't have the ability to reprogram it, stickers on the EPROM windows can mean the difference between 10 years vs 15 or 20 years of life for the data. "Bit rot" is a real problem for games on EPROM.

     

    In an extreme case (chip in the sunlight daily), it can only take months. This happened once at a previous job when I found an erased boot ROM in an unused controller unit that had been left in the sunlight with its top off for what couldn't have been more than a year.


  4. Programming info for the 7800 can be found with Google. All the 7800 programming info documents have been scanned (and available as a PDF of scans), and also as plain text. I'd search for register names (P0C1 P1C1 P2C1 OFFSET DPPH DPPL) as the most efficient way to find something.


  5. No way that label could have been for even a planned or canceled 2600 game. It's a standard Colecovision label, with the wrap-around and everything. Most 2600 carts had separate main and end labels. Are there any 2600 cart shells that the label will fit on? If there are, would they likely have been used?

     

    Someone just goofed up. This was the days of Kroy lettering and X-acto knives. Maybe they pasted down the wrong text as a placeholder. Maybe someone didn't know what he was doing and just slapped it down to get the artwork out the door, after the original guy got laid off or moved to some other project. Do you actually believe that the label art grunts back in 1983 would know the difference between a 2600 label and a Colecovision label?


  6. I never bought an SP. I knew there would be a revision after it to replace my regular GBA. I already had a regular GB (bought used at a thrift store), and a GBC (bought to play Pokemon back in the days before the franchise had been run into the ground and then a grave cemented over the hole, so I could link cable it with my regular GB), so there was no way I was going to get an SP. I mean, I hardly played the GBA enough to justify needing a backlight anyhow.

     

    The spiffiness of the DS is my reward for ignoring the SP. I never liked the way the SP looked anyhow. I mean, that's really all it is, just a different look. And a backlight. Which they should have had to begin with. The SP won't run any games that the GBA won't run, so I'm not losing out by ignoring it.


  7. Well I'm very happy and suprised to find out that people aren't so polarized about systems! I'm sure we will always have our favorates, but it never means we have to hate the other. I guess I just love all the systems and hope to collect them all someday. Except for X-Box! I'm such a hypocrite.

    Amen to that, brother! I have no interest in getting one of those fragile bricks, even less so since the X-2 will probably not even be backwards compatible! It's the only system that I intentionally don't have. The few others that I don't have (3DO, TG-CD, Neo Geo, etc.) are due to rarity and/or lack of interest.


  8. Your best bet might be a video digitizer card. They're usually multi-standard on their video inputs. The problem is that most classic games used RF, and I wouldn't expect an All-In-Wonder type card to support multi-standard RF.

     

    And PAL uses multiple RF standards anyhow, depending on which country you're in.


  9. OK, that's it then. The Australian 7800 carts will be PAL and won't work on an NTSC 7800.

    Even if you replace the BIOS so that it doesn't check for the authentication key many PAL 7800 games will still not work properly. It would be best to see if you can borrow those NTSC 7800 games from your friend to test with.

    They wouldn't work properly, but at least they'd do something. I haven't tried running a PAL cartridge yet, but I would expect nothing worse than the bottom of the screen would be cut off because the PAL display list would be longer, and the game might run a little fast. (With the reverse, NTSC on a PAL unit, the bottom of the screen would probably just be flashing garbage from running off the end of the display lists.)

     

    Then again, I just realized that my particular one-byte edit only bypasses the encryption check. It doesn't bypass the region check. So they probably still wouldn't work, even with my mod, if PAL 7800 carts set the region byte at FFF8 to anything other than FF.


  10. But if you noticed, Ray Kassar had a hand in it too, by getting in trouble with the SEC, and eventually having to resign from Atari, thus paving the way for Jack Tramiel to screw things up in his own way. GCC was tight with Warner management and could have helped lead Atari out of its own arrogance, if things hadn't completely fallen apart with the Warner sell-off and the Tramiel lay-offs.


  11. Actually, the code should be using BCC and BCS. BPL and BMI merely check the sign bit of the result. If there's an overflow, this will NOT be correct for a greater than/less than comparison. BPL and BMI are half of a signed comparison along with BVC/BVS, while BCC and BCS are for an unsigned comparison.

     

    CMP #value

    BCC label ; if A < value

     

    CMP #value

    BCS label ; if A >= value


  12. Somewhere I've got a complete copy of this, but I don't know where in my stuff it's physically located right now. I've still got a lot of cleaning up to do before I find it.

     

    Unfortunately, it seems its manual is NOT in the AtariAge files.

×
×
  • Create New...