Jump to content


New Members
  • Content Count

  • Joined

  • Last visited

Community Reputation

14 Good

About rmzalbar

  • Rank
    Space Invader
  1. The joystick-induced static went away when I replaced my switchbox/coax F terminator combo, with a direct RCA female-to-male F connector adapter. Excellent picture now (well, excellent for RF anyway.)
  2. Replaced. All is working. Fry's actually came through with two NTE159. I hope I never have to go down into the RF shield ever again... Out of curiosity, can anyone explain the overheating mechanism for this circuit? Is it a failure of the transistors themselves, or is there a problem elsewhere causing them to run hot? The circuit looks like it runs on the 16v line direct from the transformer, clamped to a zener value. I imagine if the resistor/zener/ground failed, the clock circuit either wouldn't run at all, or the chips would have failed from the high voltage on their clock pins. Could there be a problem with the switching current on the base not fully driving the transistors completely on and off?
  3. My Intellivision works.. requires a lot of cart wiggling and resets. Did a total cleanup and cap replacement, but looks like I'll need Q1 and Q2 as well. Now I get to try to source 2c parts in a post-Radio Shack world. Fry's is right next door to me, but their circuit section is a complete shame. Never restocked, perpetually out of everything anyone might need.
  4. Hi all, I've pulled my old Atari out of storage, and gave it a refresh job with all new caps from the Console5 kit, trigger input protection, new jack, new 7805, and the TIA resistor color boost. It's a Rev 12 2600A. Well, on firing it up, it works perfectly, but gives a smattering of interference sparkles visible on the screen when any of the following switches are triggered. is this normal? RESET SELECT Joystick 1 or 2, any of the four cardinal directions. Fire button does not do this, nor does any paddle activity. The interference is just an instantaneous blip of a smattering of sparkles, it does not disrupt modulation, it's just visible. This is standard TV RF output to a CRT television. My primary concern is that it is doing something unhealthy and should be filtered out. I understand the 2600's RF output is very weak, and any interference tends to be seen in the display, so that may mean the spikes from the controller/switch input are basically nothing. If it's not a concern, but isn't normal and/or can be fixed, I would be interested in doing that too. I've tried jumping in capacitors across various lines to see if I could change it, including across the capacitors I've replaced just in case I got unlucky and swapped in a bad one. I've also measured my voltage brick (10.5v loaded on the transformer, and 4.998v after the regulator) but no luck so far. Any suggestions? Thank you, It did clean up nice:
  5. I have a question about the power circuit. Looking at the schematic, it looks like: ZD13 zener diode fails short: ~0.7 volts, switched, between the rails. ZD13 zener diode fails open: 9v, unswitched, between the rails Q12 mosfet fails short: 9v unswitched Q12 mosfet fails open: 0v unswitched Is that correct? I'm trying to estimate the chances of fail-deadly. I'm thinking of leaving the whole thing alone, but adding crowbar overvolt protection, if necessary. I looked at doing a 5v regulator mod, but those have a parasitic power loss when the console is off, can still fail deadly, and I intend to stay with 9v batteries.
  6. Thank you for all the feedback! I am about 40 pages into the C programming language book, and last night I was staring at ASM examples and the timers/interrupts in LX.NETs Lynx tutorial. Then I followed that over to the 6502 interrupts tutorial and fell down the rabbit hole. I'll start making changes in another day or so.
  7. I'm reading about how to use the timers on the Lynx, and how to use timers for controlling the flow of real-time games in general. First though, I will learn to use pointers to update my SCBs instead of querying the arrays every update, to see how much that improves performance. Oh yeah, and learn use the timers to measure execution of different functions so I can tell when I'm doing better.
  8. Here it is, now with the game.lnx binary included. cc65.zip
  9. OK, here's my project. I still haven't implemented any timers. I set it up according to the very nice Atari Lynx Programming tutorial here: https://atarilynxdeveloper.wordpress.com/series/atarilynxprogrammingtutorial/ I did not go with Visual Studio though, just a makefile and GNU make. So it uses make (for GNU Make,) external resources for sprite data, SP65 and/or SPRPCK, and the Unix utilities set he recommends for the makefiles. All of the code is in C, with external resources being the sprite data as .o files converted from BMP or PCX-drawn sprites (robot, bullets, playfield.) I tried to format it properly and comment it sufficiently. Understand I'm not only not a C programmer, I'm not even a programmer. This is my first attempt at something since LOGO in junior high school. So if you have any ridicule for me, please let me have it so I may learn Edit: Shot speed to the right is slowed down to make it easier to test number of bullets on screen. One of the buttons changes the robot walk speedfactor. Default 50, but will go up to 100. No slow down button anymore - that is now the fire button. The score shows number of frames, and the second number shows the robot speedfactor. robogame.zip
  10. I still have to implement timers. I did gain enough headroom for an extra bullet simply by replacing INTs with CHARs wherever possible, especially as loop control variables. I'm going to be out for a few days, but I'll clean up and post my code when I get back. Thank you all for the tips!
  11. That's good, because it gives me something to do. The arrays-within-arrays method of updating my SCB chain each blank isn't doing it any favors. 2800 lines of ASM code got generated just for what I've shown so far.
  12. Nice! This will be useful immediately, because right now I am getting slowdown when there are 10 sprites on the screen, and I need to determine if it's code or hardware limitation. All sprites are chained, and redrawn as soon as tgi_done. - Playfield sprite (is also the blanking sprite) - Player robot - up to 10 bullets Any bullets 8 or more causes slowdown when refresh is set to 60. Doesn't matter if page flip or not. Looking as ASM will probably help, and I can read timers or hblank to see how long my things are taking.
  13. Too much of what I'm doing is trial and error. I'm not used to programming for memory efficiency. I get the concept of pointers OK, but not always why to use them, or what exactly is happening in some situations. The arrow operator you've used was unknown to me. I've just received The C Programming Language book, and this will be my bedtime reading for the next few days. Anyway, shooting happens now:
  14. After a few agonizing months where 'life' 'happened' to me, I've gathered myself enough to pick this up again. Finally worked out how to make a struct of typedef'd SCB structs, so now I can track an array of bullets, which was my main obstacle to making them go and do things. I suspect I shouldn't be abusing cc65's struct handling that way, and I should use ASM blocks to set up and reference them as others do, but I wanted to see it through until I understood what I was doing wrong first. The score is showing the bullet index, which I needed for troubleshooting. The second number is a player walk speed factor, adjustable from 1-100. Also, diagonal walk is speed-corrected. Super fun so far. I'm not a C programmer, but I may be close to being one by the time I get a real game out of this
  • Create New...