rmzalbar

Got my order in this morning. Very glad and appreciative that you've made these available for us!

Reasonable! Looking forward to it!

Very excited! Mine are about dead, and I need enough for the next 100 years at least

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.)

meeeeee too! 6 to 8 of them.

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?

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.

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:

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.

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.

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.

Here it is, now with the game.lnx binary included. cc65.zip

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

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!

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.

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.

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:

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

Thi This worked! What do you mean by different types of sprites?

I'm having an issue getting sprite chaining to work with cc65. The _suzy header appears to want a pointer reference (char *next) for next sprite. However, when I use a pointer to an SCB struct name, I get an incompatible pointer types error. I can draw these two sprites individually so long as *next is set to 0, but trying to reference any SCB from any other for chaining is producing this compile error. So far as I understand pointers, I think I'm doing it correctly - but I'm not an expert in C. Here are two SCB structs. backgrndsprite wants to chain to robotsprite, at line 34. The error is: game.c(34): Error: Incompatible pointer types at 'robotsprite.' Using cc65 V 2.17. Thank you, SCB_REHVST_PAL robotsprite = { BPP_4 | TYPE_NORMAL, PACKED | REHVST, 0x01, 0, &robota, 10, 20, 0x0100, 0x0100, 0x0000, 0x0000, { 0x01, 0x23, 0x45, 0x67, 0x89, 0xab, 0xcd, 0xef } }; SCB_REHV_PAL backgrndsprite = { BPP_4 | TYPE_NORMAL, PACKED | REHV, 0x01, &robotsprite, &backgrnd, 0, 0, 0x0200, 0x0200, { 0x01, 0x23, 0x45, 0x67, 0x89, 0xab, 0xcd, 0xef } };

Well. I had many issues with corrupt sprites or failed conversion for both .PCX and .BMP with all utilities. The issue, in case anyone else follows me, turned out to be the "Remove unused colors from colormap" option in GIMP2 when changing image->mode to indexed. By default it was checked. UNCHECK IT. Now, no further problems with any sprite conversion tools either .pcx or .bmp, and they save as 4-bpp instead of 8 when exported.

Got it working with 8-bpp PCX (4-bpp didn't work) by following the syntax in Karri's post. The cc65 documentation and -h text didn't provide a clear syntax. Thank you, Edit: not really working with 8-bpp images, they still need to be 4-bpp. See following post for the real solution.

Would the current cc65 snapshot (2.17 xxxx) be recommended for cc65 Lynx development? With regards to thread recommendations to use a particular older version.

This is quite cool. Thank you!

I've been using sprpck 1.98, and that worked well enough with BMP files. I just wanted to try making transparent (shaped) sprites, a feature of sp65. I'm still looking for a way to export a PCX with a 4-bit index before that can happen.