Jump to content

appleo

Members
  • Content Count

    51
  • Joined

  • Last visited

Community Reputation

0 Neutral

About appleo

  • Rank
    Star Raider

Contact / Social Media

Profile Information

  • Interests
    creating & playing classic video games<br />indie & experimental & classic rock<br />philosophy<br />inventing gadgets<br />guitars<br />
  1. Followup... I found a couple of similar items. Zektor lets you use Vectrex as a display device: http://www.zektor.com/zvg/index.html http://www.zektor.com/zvg/zvg_vpix.htm This one lets the Vectrex talk to PC via USB: http://kokosplace.50webs.com/Vec%20Multi/Vectrex_Multifunction_Box.htm http://vectrex.wikia.com/wiki/Vectrex_Multifunction_Adapter The device I am thinking of would be specifically for Vectrex, cheap (you could build it with an Arduino, a repurposed Vectrex cartridge & some components), self-contained unit that plugs into the cartridge port (needs no jumpers or anything modified on the Vectrex itself), plugs into the USB 1.1 or 2 port on PC, and the PC sees as just another USB2 peripheral.
  2. Cool, thanks, I'll check those guys out...
  3. Hi everyone I'm a fan of old video games & do some programming (mostly VB / JavaScript) and would enjoy playing around making programs for the Vectrex. Although I have programmed some simple assembly language routines on the C-64 back in the day, that would probably be a little too much work for me to be fun these days. That said, are there any higher level languages or game development IDEs / construction sets available for the Vectrex? Also does anyone make a flash card adapter (like the Harmony for the Atari 2600) to make it easy to play your game on a physical Vectrex? Finally has anyone tried making a custom "cartridge" for the Vectrex that basically lets the PC use the Vectrex as a vector display monitor (and possibly read input from the Vectrex's controllers / light pen / etc.)? I think it would be kind of neat not only for homebrewed games (including network games) but for MAME as well. With tools like Arduino & PICAXE, it should be possible to do and affordable to construct. The device I am imagining would work like this: Display adapter 1) the part that talks to the PC would acts as a simple video memory buffer that would receive coordinates from the PC for where to plot shapes on the Vectrex screen 2) the part that talks to the Vectrex would just be a simple homebrew program that draws stuff on the screen, based on the coordinates in the buffer Input adapter 1) the part that talks to the Vectrex would poll the joystick(s) or light pen and save any input to an input buffer 2) the part that talks to the PC reads the buffer and via the device driver, shows up as keyboard or mouse input, to control the game or emulator on the PC (since the joysticks are analog, it might map a 2nd "virtual" mouse for 2-joystick games, or include an option to convert the joystick inputs to digital as pc keypresses). If this exists, where can you order one (or find the instructions to make one)... If not, where would you find people to work with or discuss such a project? Thanks!
  4. Can anyone recommend a reputable service or individual that does 2600 console mods, refurbishing, repairs?
  5. This would be a much better product if it had two 9-pin D-shell connectors that worked with the standard Atari 2600 joystick OR paddles OR numeric keypad. That way you can play 2-player games, or 4-player paddle games, stuff like Star Raiders, etc. Not that I'm surprised since it's Steve Jobs we're talking about, but I don't understand why in 2011 with all the advanced technology available to us, it's SO HARD to plug a couple simple joysticks or paddle controllers (1977 technology) into an iPad or iPhone and configure a game to use it. Or rather, why getting a device as advanced as an iPad or iPhone to receive simple input from a standardized hardware interface in a standard way, and be able to configure ANY game app to work with it, instead of having to buy these "magical" products that only work with certain games. Is playing old Atari games and at least wiring in a couple joysticks or paddles easier than this on Droid? Does it work with Stella?
  6. Alright, now I'm getting into lower level operations that are currently over my head, but let me venture an idea. What if we just let the kernel read the one value (0-255), and make it available to the main program code, so we interpret the value outside the kernel? Just leave the kernel to do raw i/o. What I mean is that it is very kernel-intensive to read paddles, since you have to do it during the kernel. The fewer values you have to check for, the more that requirement is eased. For example, if you only need to check against one value, < 128K or > 128K for example, then you only need to read the paddles once during your kernel. That's pretty easy to stick in there somewhere. On the other end of the extreme...if (like for Breakout or something) you need to read one of ~100 values, then you essentially need to read the paddle on every line of your kernel. That really restricts what you can display on screen. The fewer possible values, the easier it will be to program for. The six-joystick idea is very interesting, though! 940535[/snapback]
  7. Good point, but is coding for the speed of one rapid click necessary if the player is standing still? In the case that the player has not moved in x (whatever the cutoff is) seconds or milliseconds we count them as standing still, and move them the minimal distance. With a resolution of 16 pulses per rev, is one click far enough that it will be noticable? Ah yes, but the Atari 2600 has two analog inputs -- so just use one of those! I also agree that it takes two clicks to measure the speed. One click gives you no information that you can use. Okay, who's got the breadboard to wire this sucker up! 940495[/snapback] 940513[/snapback] I don't agree. There are plenty of times where the user doesn't want to move -- they want to stay in one place. So after two clicks have been seen, you stop timing. Then the user may want to make a rapid move so you want to measure the time between two clicks again. If you are constantly timing like you seem to be saying, I don't see how the user can stay in one place for a while, then make a rapid movement. 940537[/snapback]
  8. Well, if you count pressing of the Reset button or powerup, as click #1 (LastClick=0), then you don't need two clicks to measure speed. You just compare CurrentClick to the amount of time elapsed since LastClick. Of course with limited RAM, storing a date/time variable could be expensive. Ah yes, but the Atari 2600 has two analog inputs -- so just use one of those! I also agree that it takes two clicks to measure the speed. One click gives you no information that you can use. Okay, who's got the breadboard to wire this sucker up! 940495[/snapback]
  9. The thing is, you're only reading one value off the pot, a single resistance. Then it's up to the code to interpret the value - ie decipher it into the bits it represents. Or are you saying that the value read from the paddle is not precise enough to be able to translate into bitwise values? What you said is interesting though because theoretically if you can read paddles AND joysticks you could have 6 joysticks. ----- I'm pretty sure that's a hardware limitation. My suggestion: you have 5 on/off pins in each port (UDLR and fire), why not use them? So: 8K = U 16K = D 32K = L 64K = R L = J0 fire, R = J1 fire. Or something. The fewer values you need to read off the pots the easier it is to read in the program. 940500[/snapback]
  10. I think it is possible to connect 4 joysticks to the 2600 using paddles. I had hoped you could do it with the keyboard controllers, which still might work, but we need some specs. Basically, instead of plugging the joystick into the joystick pins, we plug it into the paddle pins. Connect the ground to the +5v for the paddle, and connect each direction and fire button in the joystick to a fixed resistor (resistors should be gold tolerance), all leading to the gnd for the paddle. The resistances, added up, should not be > 1 MOhm (the max resistance of a paddle pot). Each resistance would need to have a base 2 number, like: JOYSTICK, RESISTANCE up, 8k ohm down, 16k left, 32k right, 64k fire, 128k (total), <1 MOhm I am using the larger numbers (8,16,32,64,128 as opposed to 1,2,4,etc) because I think the smaller numbers would be harder to detect. So if the player pressed up, right and fire simultaneously, the value read on the paddle would be 8k + 64k + 128k = 200k ohms, which would coincide with a unique paddle position (or time for the cap to discharge or whatever). Translate this time back into the number 200 and the individual bits, and you can detect that up / right and fire bits = on. Is this doable? Thoughts? A thread on the topic: appleo: 2600 keyboard controller - simultaneous keypresses Is it possible to read >1 key being pressed on the keyboard controller at one time? For instance if the "1" and the "7" keys are pressed simultaneously can this be detected? batari: You can read the keyboard controllers in bB, but there's no built-in functions for them as there are for joysticks. You will need to use the SWCHA and INPT4 registers directly. I've never actually tried to read them in a program, but I have heard that some keys on the controller can't be read simultaneously. I recall a post about this a while back but I can't find it. The poster was asking if it was possible to modify a keyboard controller to simulate two joysticks, and the answer was no because some combinations of button presses couldn't be read at the same time. appleo: Actually, that was my question for the joysticks. A long time ago I had come up with this scheme (http://softintheheadware.com/soft/4_atari_...s_invention.asp) for 4 joysticks on the C=64, and now that I am interested in the 2600, seeing that each keypad has 12 buttons would mean the possibility of 4 joysticks with 2 buttons each. I would like to experiment with some 4 player games - after all there are 4 player paddle games, why not for the joystick? Some specs on the keyboard controllers might help. If they are read using resistances like my c64 scheme uses, then it might be possible. Otherwise, multiple joysticks could still be used on the 2600 using the c64 scheme (resistances attached to the paddle ports in a binary fashion) I found what you were talking about - from "synthcart for the atari 2600": >Note that the Atari is not designed to read multiple keys off the keypads, so although one or two keys can be read accurately, the Atari may sometimes read keys in the wrong row when you are holding down three or more keys at once. (full text) I wonder though if this is a hardware or a software limitation. I need to find some specs on these keypad controllers.
  11. That is if we directly use quadrature output from the driving controller - what about programming a PIC to constantly read the driving controller, and use the quadrature to track a value 0-255, and then use that to manipulate resistance between 1K and 1 M ohm and send that to the 2600? That way the 2600 receives an absolute value for each controller, and thinks it's reading paddles. We could get really fancy and attach a switch or pot to the pic for "tolerance" so that we can tweak how far/fast the paddle value changes depending on how fast the knob is turned. The only EFFICIENT way for the 2600 to read controllers is to do it once every frame (1/60th of a second). This happens to be sufficient for the standard driving controller. Only when you twist the driving controller very quickly does this sample rate lose sync of the quadrature encoding. By using a microcontroller to read a higher resolution encoder more often, you still need to present this to the 2600. There are only 4 digital bits in which to encode direction and speed. So you would need to buffer some kind of multi-nybble information which the 2600 would then pull out each frame with successive reads of the port until it figures out that it's caught up. I'm not saying it can't be done. I'm just saying it's not trivial. 940155[/snapback]
  12. I have a 2600 4-switch console with no sound- is there a chip or part that would be most likely responsible for this?
  13. Some questions: 1) So displaying sprites on alternate frames is called "flicker" ? (I tried searching forums for a definition, but didn't find it) I assume it's called this because they literally flicker - how did they get multiple non-flickering objects then in games like Space Invaders, Galaxian, Combat? 2) I've heard the term "player/missile graphics" for a long time, what is the difference between a sprite and a missile object? I'm used to Commodore 64 where everything is just a sprite. Thanks You'll need to be a little more specific. Can the missile-sprites be dots/lines, or do they need to have more complex shapes? What are the spatial relationships between the sprites? Specifically, do more than two of them need to be on the same scanline at the same time? Finally, you already have this with the current bB kernel if you implement flicker. 939431[/snapback] 939491[/snapback] vdub_bobby's multisprite kernel might work when it's integrated into bB - it has 5 sprites and 3 missile-like objects. One of the sprites could be used as a missile if that's what you need. The only issue with this kernel is it doesn't allow more than two sprites on a particular scanline. Two independently-moving sprites per scanline is a limitation of the 2600's hardware. Games that display more must display the sprites on alternate frames. In the future, I may implement Manuel's algorithm for "intelligent flicker" which will allow flicker to be done automatically instead of doing it explicitly like you must do now. 939621[/snapback]
  14. The missile sprites can be dots or small squares. The sprites/missiles can be one color but each needs their own color. It is possible all 8 objects might be on the same scan line at the same time. I am a complete newbie to 2600 coding - what is flicker? I probably have some reading to do You'll need to be a little more specific. Can the missile-sprites be dots/lines, or do they need to have more complex shapes? What are the spatial relationships between the sprites? Specifically, do more than two of them need to be on the same scanline at the same time? Finally, you already have this with the current bB kernel if you implement flicker. 939431[/snapback]
×
×
  • Create New...