Viso
-
Content Count
121 -
Joined
-
Last visited
Posts posted by Viso
-
-
I'm looking forward to the completion of this game!
I did come up with an idea for a memory module to save games for the 2600, but haven't developed it yet (I've got many things I'd like to develop). If it were used, there would be no need to enter some code to recreate the game, and there would be no battery. I think it could be made inexpensively, too.
The notes I wrote on the idea are here:
http://home.hiwaay.net/~jeffj1/Atari2600ga...eSaverIdea.html
-
I got a mid 1984 unit second hand. The power supply I got with it is a black box with a partly slanted side. I guess you could call that wedge like, but it isn't much of a wedge. One of the sides has a shape like this:
/--|
/ |
|___|
Sorry about the less than wonderful formatting -- it's a limitation of this board. Just take out the extra empty lines and it looks fine.
-
I'm trying to get a similar S-Video out mod working in my 7800. I'm having a few odd problems (see http://www.atariage.com/forums/viewtopic.php?t=24830) and I'm thinking of redoing part of the circut I have so that it is the CD4050 mod sans 4050 (it is already close).
What I can't figure out is what circut is needed for the chroma signal on the 7800. Right now, I've got the chroma circut pictured at the start of this thread, but without the 6.8K ohm resistor at the input end. Instead, I've got a 1.2K ohm resistor on the 2600 chroma input and a 200 ohm resistor on the 7800 input. After those two resistors, the signals are tied together and given to the transistor. To get any color, I had to remove the 75 ohm resistor between the transistor and the chroma output (I put a wire in parallel). I have the same problem with the luma output.
The resulting color includes regularly spaced darkened columns, perfectly vertical and stationary, on any part of the image that isn't black, white, or somewhere inbetween. Seems to be worse on 7800 games, and worse with green.
Any ideas on how to correct the circut?
-
I have tried to add S-Video output to my 7800, but there are some problems that required me to make odd changes to the circut to get any usable output.
The problems I'm having are darkened vertical lines and a different brightness when the output is given to a different device. The vertical lines don't really look like lines because of the space between each horizontal line, but there are regularly spaced columns where the image is darker. So along a horizontal line that should be the same brightness, it alternates between brigher and darker. The effect is not present when the color is white (or any grey). It can be seen very promenately in Ballblazer - in fact, it is so bad with Ballblazer that I haven't decided if RF looks worse or better yet.
When I connect the output to my VCR (I've got an S-VHS one, so it takes the S-Video input), I get an image that, save for the above problem, is wonderful. When I connect it to my receiver's front panel video input, the result looks darker and the colors more muted. If I adjust the brighness output, I can get the video through the receiver to look almost bright enough to be right, but then the VCR shows it to be too bright and washed out.
The circut I used is very similar to the CD4050 A/V mod sans CD4050 that has been mentioned on Atari age. You can find a 2600 schematic here: http://www.atariage.com/forums/viewtopic.php?t=17748
The exact circut I used started out several months ago as another mod listed here: http://www.geocities.com/atari7800mod/7800...nstruction.html
I modified the circut to include the transistor and two 75ohm resistors on the chroma output as present in the CD4050 mod.
When I connected the circut as described, I did not get an image. I found that until I connected the output to my VCR (or receiver), there where chroma and luma signals at the output end of the circut. With the S-Video cable connected to the VCR (or receiver), the signals at the output end of the circut where grounded. I checked this with an osciliscope.
To get an image, I stuck a couple wirse onto the emitter ends of the two transistors, and connected the other end of each wire to either a chroma or luma line on the S-Video out. This eliminates the 75ohm resistor between the transistors and the circut's output.
What have I done wrong with the circut and how do I fix it?
-
Those bastards! What are they thinking?!?I buy Atari(systems and games) from The EB near my house. Takes a lil bit to get systems but knowning the MGR does have perks :wink:
:wink:EB Games? The EB Games by me doesn't even carry SNES anymore.

In any case, there is an EB Games in Cary, NC, near Raleigh, in the Crossroads huge blob of stores, east of the US1/64 & Walnut intersection, that has quite a few lose NES cartridges. For some reason, I didn't closely inspect their collection to see what other NES stuff was there or if any Atari stuff had escaped my notice.
-
As for RPGs.. Apart from Zelda-esqe games, I can't see playing RPGs with a Joystick.. At least not the Ultima Style games..But you'd want to be able to save your game!!!
Can you do save games?? (I'm not a fan of codes for levels, and it wouldn't work well for RPGs)
desiv
See my post above for saving games. Just an idea.
As for joystick control, you could add a keypad controller, too. Might be a tad awkward, though. Or how about a controller with 5 buttons and an analog joystick? That should be possible, but probably not worth the trouble.
-
I have thought of a solution to that problem, but I haven't made a prototype as I'd need to get code running on a 7800, and I don't know how to program those things.If I remember correctly you would need some sort of battery backup on the cartridge to save a game. Needless to say it would probably very expensive to produce.In any case, what I thought up is a memory module that sits between the console and a joystick or paddle controller. The module should be fairly cheap because its only made up of a microcontroller (a cheap one that I can program), a serial EEPROM, a couple connectors, a PCB, a case, and some resistors and capacitors. The parts, minus the case, PCB, and firmware, cost under $10.
-
How thick do the wires connecting the console and a video mod need to be? Will 30awg wire work, or does something thicker like 24awg need to be used to get a good picture?
-
I'm not so much interested in how long the capacitors take to charge as I am in how long games excpect them to take to charge. I'm looking for how long that would be with a paddle controller connected and turned for maximum resistance. It would help to know the same time figure for minimum resistance. I'm doing some planning for a gizmo that hopefully will emulate paddle controller input, and 5200 joystick input.
-
Here is a good technical question for those programming these Atari consoles.
For 2600 games, what is the maximum time between when the game quits grounding the paddle input line until the game quits waiting for the paddle input to change back to a logic one? Also, what is the inverval for the same events when using the 5200's POKEY?
If anyone happens to know, what is the voltage at which the TIA and POKEY chips decide the input has changed from a zero to a one?
Thanks for the help!
-
Thanks Dan! Great answers.
Out of curiosity, is "TYP-8" a common thing to find on schematics?
-
I've been working on a gizmo to indirectly connect one or two unmodified Playstation controllers to an Atari 2600 and 7800. I'm having to redesign some of it, so I figured I'd try to support the 5200, too. But I need more information before I can get very far.
First: Joysticks
The schematics on the Atari Age site seem to be rather vauge on how the 5200 joystick inputs are handled. It looks like there is a 1.8K ohm resistor on each of the 8 input lines. As I understand it, a capacitor needs to be charged and the time it takes is used to determine the joystick position. The schematics show only two capacitors on the 8 input lines. That is two total, not per line. One is between the resistor and the POKEY, which makes sense, and the other is between the resistor and the controller. Both have different values.
What does the input circut really look like? The schematics show a circut that shouldn't work unless a voltage is used to determine the joystick position rather than a current. I'd really like to know the values of the resistors and capacitors involved, including the potentiometer in the joystick controller.
By contrast, the 2600 and 7800 schematics make sense. Except for the 2600A, they have 1.8K ohm resistors on the paddle inputs, and they all have 0.068uF capacitors between the resistor and the TIA. If I'm not mistaken, a 1M ohm potentiometer is used in each paddle. I thought the 5200 joysticks worked in much the same way as the 2600 paddles. Am I wrong?
Second: keypads
As the 5200 scans the rows of one controller, is it possible to tell which rows are being scanned on another controller without using the other controller's connection? My gizmo will only have enough input to see the row scanning for one keypad, and it would be nice to support two. So, are the same rows scanned on every controller simultaneously? Is it something like row N on one controller and row N+1 on the next controller to the right? Or is there no way to tell?
-
I, too, think serial with a console based UI and support for the 2600 and those large 7800 games would be great.
I don't know how others would feel, but I would like RS-422/485 style serial with a RJ-45 connector for use with ethernet cables. I know it wouldn't be ethernet (that would be even better but would increase hardware cost by more than $50) but it would allow the Atari console and computer to be a good distance away from each other. A 50 meter cable would work fine, and an adapter to convert between RS-422/485 and RS-232 next to the computer is a fairly simple gizmo. I suppose a connector for both types of serial could be on the cartridge. I'm willing to pay extra for that.
If it does have a console based UI, it would be great if it could be a native 7800 thing just for the higher resolution. I think that flag which controls if the Maria or Stella chip is used can be locked, and I don't know what technical limitations that might impose on the device.
Will the cartridge inclued updatable code?
-
That's wonderful! Would you mind sharing any of the details? I'm just starting to learn about electronics and would love to see how far you have progressed.Thanks!
- VD
I don't mind sharing the details. The core of the adapter is a PIC16F877 microcontroller that presently runs at 4MHz (under 1 MIPS). Most functionallity is implemented in software, which makes it flexible, but has resulted in some complex code -- I'll probably spend a few days figuring out what exactly I did before making more progress. Also, I plan to make the code availible under the GPL and already have several libraries on my web site. See: http://home.hiwaay.net/~jeffj1/projects/index.html
I'm planning on these features:
Playstation digital, Dual Shock, and Dual Shock 2 controller support (works)
Custom controller configurations (1st attempt at interpreter nearly done; UI has not been started)
20x4 alpha numeric LCD for menus (LCD library works; LCD menuing library works)
Emulation for 2600 joystick, 7800 joystick, booster grip, paddles, keypad (right port only), and NES pad (for NES only)
Outputs for Atari console mounted controls, like select & reset
Support for providing input for both controller ports through a single Playstation controller.
Bootloader to easily update the software on the PIC16F877 (works)
-
I've been working on an adapter to allow Playstation controllers to be used with Atari 2600 & 7800 systems. It looks like if I can get it working, it could sit between the X-Arcade and an Atari system. Unfortunately, I haven't had much of a chance to work on the adapter for almost 4 months. I'm not sure I'll get much of a chance before the summer to do much with it. But when I get it working, I'll make a post or two.
-
Actually, there are double sided DVD-R's. They aren't as common, but Pioneer, among others, makes the media. All single layer, of course. But the higher cost of a double sided disk can make two single sided ones cheaper.
Getting two hours onto one side of a DVD-R isn't a problem with a small reduction in quality compared to a single hour. I've been putting 1.5 hour long MST3K episodes on DVD and they look great. There are various things that can be done, like using less than the maximum resolution, to help pack longer (>2hr) video in -- I've done close to four hours without really trying. But then the video isn't any sharper than VHS.
I don't mean to discourage using a professional DVD mastering service, but I figure options are good and more might increase the chance for the video to make its way to DVD. No doubt someone will want to research the origins of video games 50 years from now. DVD will help it last that long. So I hope it happens.
-
I never knew about these videos before. I would like to have a copy, especially on DVD, but right now I couldn't afford it. But I have been making DVD's, just not professionally.
Cupcakus, blank DVD-R's that can be played in DVD players cost under $2 each, minus a case. Not horribly pricey.
-
Instead of connecting a hard drive to a 2600, connect the 2600 to a computer. The computer could supply the information to the 2600 so that the 2600 would never have to deal with interfacing to a hard drive or a file system. Plus, adding and updating games should prove much simpler than if the drive was attached to the 2600. The communication could be done over a serial line (RS-422 or 485 to facilitate long cable lengths) or over ethernet with the help of something like Dallas Semi's TINI.
-
I made an S-video output board for my 7800 only to find that my soldering skills woefully lacking when I attempted to make connections to the 7800's PCB. How are you planning on making the connections? I'd like to learn about a better way.
As for interest in the kit, the only Atari system I have is an Atari 7800.
-
Someone has been working on a port of Doom for the Intellivision. Unless I'm mistaken, The Intellivision has the same CPU as the 7800 and worse graphics, so it may well be possible to get it running on the 7800.
http://spatula-city.org/~im14u2c/intv/doom/
3D graphics algorithms have advanced quite a bit since the 7800 was laid to rest. I'm sure the developers for the games had a hard enough time simulating a 3D enviornment without actually rendering 3D.
I haven't looked at the code, so I might be wrong, but it looked to me like Ballblazer wasn't rendering the craft by sprite. It seemed to be a vector style image to me. I'll have to go look again. I figured it did pseudo 3D and limited things to right angles and a single plane. That makes the math a lot easier. The math issue makes me impressed that Doom is even possible running on a 6502 without 3D graphics hardware (which would be wierd to have).
-
Gee, I thought the PIC's instruction set was pretty simple and easy to deal with. Still, it isn't something I'd want to write all my code in, so I do most of my coding in C to make the complex logic easier to maintain, sprinkle in assembly code where needed, and write the whole ISR in assembly. The only formal introduction to assembly I had was a course on 8086 assembly; I didn't care for it. I think the PIC is easier.
Hehe, yeah it's brutal if you don't like RISC.Ugh.. we programmed the 16F877 last year in one of my classes, and it sucked hard. Branching was especially brutal.Of course, this is coming from someone who likes the way the 6502 and 6800 work...

--Zero
About the LQ instruction, it does make sense to at least have 128-bit load and store instructions on a CPU that gets most of its processing power from dealing with 128-bit operands. That could give a nice performance boost, even if it can't work directly with 128-bit integers, save for loading and storing. I imagine it would help keep the size of the program binaries down, too. Does the Athlon or Pentium 4 have 64-bit load and store instructions?
-
Heh, oops. I wonder if Ze_ro took you too seriously as well?You think so huh ? I program the PS2 for a living. What does this instruction do:lq t0,(a0)
Do you know ?
The 4 bit thing was a joke dude ! LOL

I'm not actually familiar with MIPS instructions, and certainly not the Emotion Engine (R5900i?). There doesn't even seem to be a listing of the instruction set online, at lest without registering with MIPS.
I was just trying to make the point that calling the PS2's Emotion Engine a 128-bit processor and x86 a 32-bit is inconsistant. It counts SIMD for the PS2 and not the x86. I suppose I am also assuming the Emotion Engine's core is MIPS III/IV and doesn't do anything 128-bit wise save for integer SIMD. Since the latest MIPS cores are all 64-bit without counting SIMD, it then seems to follow that the Emotion Engine is also 64-bit, minus SIMD.
Now that I'm past that, what have you worked on for the PS2? Enjoy the work? Sounds like an interesting challenge.
Ah, ICD. I suppose I could use that, but I have this bad habbit of finding a use for every I/O pin. My favorite PIC is the one that gets the job done with the fewest headaches and unused resourcesOh and by the way, I program PIC's as well, in fact I just got my ICD after 4 years of programming the PIC cuz I didn't need it. :wink: Which PIC is your favorite ?
I don't program them professionally, I just hack away. I've done Java programming professionally, so PIC programming was an interesting change for me. I read the docs from Microchip and changed my programming style to fit the enviornment.
My latest PIC project is an adapter that takes Playstation controller input and provides apropriate output for an Atari 2600, 7800 or an NES. I'm trying to make it very configurable, so it looks like I'll be using a lot of what the PIC16F877 has to offer, minus the analog stuff.
-
If you want to count the PS2 as a 128-bit processor because of that, then the latest x86 processors are 64-bit processors for the same resaon. Otherwise, the latest x86 processors are 32-bit, and the PS2 is 64-bit (uses MIPS integer core; 64-bit operations with 128-bit SIMD).Yes, I know it is operating on 4 32bit components, it is still operating on 128bits though. That's why it's called "Single Instruction Multiple Data" instruction set.About the thought of a 4-bit processor being difficult at best because of being limited to 16 instructions, that is a misunderstanding. The instruction word can be longer than the amount of data that can be processed in an instruction. For instance, the series of PIC microcontrollers are all 8-bit processors with 12, 14, or 16-bit instruction word sizes depending on the model. The instructions are not so large because there are thousands (at least from how it looks in assembly language), but because a good amount of constant data can be stored within the instruction. Like an 8-bit value to add to the W register, or which 8-bit address to load into the W register. Such constants within instructions are pretty common.
-
Besides being just plain difficult to do short of asking people to write actual code, I'm not doing that because the microcontroller I'm using, a PIC16F877, can only have its Flash ROM rewritten about a thousand times. Writting to it for updating controller configs, especially if only a few can be stored, could soon make the microcontroller useless. I do want to support uploading and downloading configs to and from a computer, but I'm planning on making that data and storing it in much longer lived EEPROM.Well... I don't really know how you two designed your stuff. But if it's anything similar to what I'm learning. Why write open ended code to handle the configurations? Or more accurately, why not do the entire programming on the PC side? I have a custom application (that I wrote in part) that interfaces to a custom 68xx robotics board. Rather than try and write a piece of code that will handle anything, how about building a template that can be modified on the PC, compiled and linked, then, "flash," the new code into the box?
I'm trying to keep the cost of my adapter down, so there isn't anything exotic or increadible in it. It's got 368 bytes of RAM, enough ROM for 8192 instructions, it runs less than 1MIPS, and it will need only 7 to 9 support ICs that are all cheaper than the PIC16F877. It's going to be a tight fit, but I think it will work, and I do have the option of increasing the speed to under 4 MIPS (probably less than 3.5).Of course, my little board is a radical design difference to your boards. I don't know what constraints you guys are working on but I'm hard pressed to even hit an 1/8 of what the board I have can do. (Now if only I can remember what I did with it
) So I'm sure your boards are even smaller with much much tighter constraints.

Current from 2600/7800 controller port
in Hardware
Posted
I'm working on a new peripheral for the Atari 2600 & 7800 that connects to the controller port. I would like it to get its power from the controller port, which I have gotten it to do (at least for a short test), but I'm not sure how much current is too much. The device cannot be powered by the serial port of a PC, which I know can't manage much current, but I don't know how little it is. I'm doing some guess work without an ammeter. When I add together what the components claim to use, I get 3mA continous and 8mA peak.
I don't want to make the game systems' 7805 overheat. As it is, my 7800's gets pretty hot.
Thanks for the help!