-
Posts
23 -
Joined
-
Last visited
Recent Profile Visitors
The recent visitors block is disabled and is not being shown to other users.
Kevin McGrath's Achievements
Space Invader (2/9)
15
Reputation
-
Newbie in the house! Questions for the Experts.
Kevin McGrath replied to The Last Templar's topic in Atari 2600
The RCA to F Connector adapter from the Atari Age store should already change the 300 ohm impedance to 75 ohms and provide a way for you to connect your Atari 2600 directly to a TV with that type (cable F connector only) of connector... If your TV has an NTSC tuner and not just an ATSC tuner. The adapter from Atari Age may just be enough to get you going, your TV may be able to decode the old analog signal just fine. But if it doesn't, I'd try the VCR route next since you have that (with the Atari Age adapter), then get something better like an RF demodulator or mod the 2600 for composite video/audio out. -
Newbie in the house! Questions for the Experts.
Kevin McGrath replied to The Last Templar's topic in Atari 2600
The primary problem with these old consoles is that the television standards have all changed. When they came out in the 70’s, they counted on all TV’s having an analog NTSC tuner, which was true at that time and for a few decades before and after. But now-days you would have a tough time finding a new TV with an NTSC tuner, it’ll most likely just have a digital ASTC tuner for HDTV reception. There are very few analog TV broadcasters anymore, and they should all be shut down in the US by July 2021. The ASTC tuners will not work with the NTSC signal that the Atari 2600 generates. The one thing you could count on with a TV in the 70’s is that it had an antenna input, so the Atari engineers stuck with that as their only way to display a picture and get audio to the TV, an extra composite output would’ve added more cost to the system and I would think most TVs wouldn’t have composite inputs in the 70’s anyway. Cable, VCR’s and home computers would change all of that. Anyway, so your Atari 2600 acts like a tiny little NTSC TV broadcaster, converting the games’ video and audio into either a channel 3 or 4 analog NTSC TV signal. But your new HDTV only accepts digital ATSC signals. So you either have to make modifications to the Atari 2600 and add a composite audio/video output, or you have to hook the Atari up to something that is able to receive an old analog NTSC signal like an old VCR. The VCR will then receive the TV signal and convert it into composite output which you can hook up to your HDTV. Or use an old TV. Another thing to consider is matching the antenna impedance. The Atari 2600 antenna signal has an old style 300 ohm that would connect to a switch box which had a forked connector at the end which you attached to your TV, and screw terminals to attach your rabbit ear antenna onto and then you would switch between the game system and live broadcasts from the antenna. When Cable came around, they introduced the 75 ohm F connector, the kind you screw a coax cable onto. If you used Cable, or your TV didn’t have the old style 300 ohm antenna, you had to “match” the 75 ohm impedance from the Atari to the expected 300 ohm impedance of the Cable style F connector. So Atari antenna plugs into the RCA jack of the switchbox and the switchboxes forked leads would screw onto a 75-300 ohm matching impedance transformer which would then plug into the F connector on the device that can pick up NTSC signals (old TV or VCR). The do make little boxes that are just NTSC tuners that convert the signal into composite audio/video for your more modern TVs. They cost around $80-$100. Ideally they would make a simple RF demodulator that had an RCA connector input for 300 ohm (Atari 2600 style), an F connector input for 75 ohm (old VCRs), a switch for either channel 3 or 4 selection and composite video and audio outputs as RCA connectors, but I haven't found anything like that yet (except on eBay for $70, which is crazy expensive). Aside from cost and complication, going through all of this electronics mess will degrade the audio/video signal, so you’ll never get something as nice looking as a modified Atari 2600 that has composite, S-Video or RGB outputs. If you don’t feel comfortable modifying an old Atari 2600 to have composite audio/video yourself, I would highly recommend just buying an already modified system. Don’t spend a lot, make sure the modification has been done using a good quality convertor kit (not a one transistor mod), and don’t bother getting one with HDMI output (you can pick up a composite to HDMI convertor for < $20). I modified my light sixer 2600 using the UAV Ultimate Atari composite mod, but there are a few other very nice mods out there that far surpass the video quality you’ll get from a simple one transistor composite mod. Much more detail can be found here: http://saundby.com/atari7800mod/hookup2.html -
It looks to me like you're missing three things: An antenna adapter cable that plugs into the back of the TV in the "ext.ant" connector (custom, see below), a "game/tv" switch box, and a matching transformer (300 ohm to 75 ohm). That Promo King 5" Portable Black & White TV/Radio should have come with a little bag with an antenna adapter in it. The external antenna connector ("ext.ant") on your TV is not standard, it should look like a coaxial antenna connector where you screw a coaxial cable onto it (called an "F connector"). Instead it appears that the manufacturer used a cheap headphone audio jack, and who knows how that's actually connected inside the TV. It does say it's a 75-ohm external antenna connection, so maybe you could hack something together with a male audio connector that fits. You only need two wires, the ground/shield on the outside of the coaxial cable and the antenna signal wire from the middle of the coaxial cable. But you'll still need to connect the Atari to the matching transformer and then to the hacked together adapter for your TV.
-
Yipes! It looks like I don’t have a working example, though I’m not sure why it’s not working. I’ve attached my 2K ROM test case. If you change the SEG.U for the STRING segment definition into a SEG, you’ll get this error: seg_print.asm (92): error: Origin Reverse-indexed. But leaving it as an undefined segment (SEG.U) appears to allow it to assemble. If you look at the listing file, it looks like the strings are being assigned space and being put into the correct area of the ROM, but a dump of the binary file shows that they are indeed not: 8 f800 00 brk 9 f801 1b DC.B <.storedLen 10 f802 f8 DC.B >.storedLen 11 f803 ENDIF 12 f803 ENDIF 13 Uf81b SEG.U STRINGS String stored at $f81b 14 Uf81b ECHO "String stored at", . 15 Uf81b 03 .storedLen DC.B <[.length] 16 Uf81c 4f 6e 65 .firstChr DC.B "One" 17 Uf81c f8 1f .lastChr EQU . 18 f803 SEG CODE ... 8 f811 00 brk 9 f812 1f DC.B <.storedLen 10 f813 f8 DC.B >.storedLen 11 f814 ENDIF 12 f814 ENDIF 13 Uf81f SEG.U STRINGS String stored at $f81f 14 Uf81f ECHO "String stored at", . 15 Uf81f 03 .storedLen DC.B <[.length] 16 Uf820 54 77 6f .firstChr DC.B "Two" 17 Uf820 f8 23 .lastChr EQU . 18 f814 SEG CODE ... 103 f815 42 65 66 6f* DC.B "Before" 104 f81b Strings_Org: $f81b 105 f81b ECHO "Strings_Org:", . 106 f81b 107 f81b f8 1b Strings_Org EQU . 108 f81b 109 f81b 41 66 74 65* DC.B "After" Above, you can see the DC.B statements within the listing getting assigned space (Uf81b and Ufb1f), but then in the binary file: 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00000000 00 1B F8 78 D8 A2 00 8A A8 CA 9A 48 D0 FB 4C 00 ...x....¨..H..L. 00000010 F8 00 1F F8 40 42 65 66 6F 72 65 41 66 74 65 72 ....@BeforeAfter 00000020 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ 00000030 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ You can see there's nothing between "Before" and "After". Perhaps I should post this as a bug on the Dasm GitHub site? It feels like you should be able to switch segments within a macro, and the listing file sure makes it seem like space is being allocated and assigned to the string bytes, but the final emitted bytes do not contain the strings from the macros. It does go through five passes, which seems like it's trying to figure something out, but not quiet getting there in the end. I'm assembling the attached test file using: dasm.exe seg_print.asm -f3 -v0 -Lseg_print.lst -sseg_print.sym -oseg_print.bin seg_print.asm
-
Not at all. Thanks!
-
Yes, you should be able to switch segments within the macro, and then define the space for your data, and then switch back into your code segment. Here's an example: SEG.U STRINGS ORG Strings_Org ... ; SEG_PRINT "Hello World" ; Store a string, with the first byte containing the string length in bytes MAC SEG_PRINT .length EQU [.lastChr - .firstChr] IF [.length == 0] ECHO "String '", {1}, "' is zero bytes long!" ELSE IF [.length > 255] ECHO "String '", {1}, "' is longer than 255 bytes!" ELSE brk DC.B <.storedLen DC.B >.storedLen ENDIF ENDIF SEG.U STRINGS .storedLen DC.B <[.length] .firstChr DC.B {1} .lastChr EQU . SEG.U CODE ENDM ... SEG CODE ORG $F000 ; Standard Atari 4K cartridge, no bank-switching needed ... SEG_PRINT "Hello World" ... Strings_Org EQU . ;======================================-======================================= ECHO ([$FFFC-.]d), "bytes available for 4KB cartridge" ;======================================-======================================= ; BANK SWITCHING ; Reserve $FFFA - $FFFB (normally the 6502 NMI vector) for bank-switching ;======================================-======================================= ; RESET AND IRQ/BRK VECTORS ORG $FFFC DC.W ColdBoot ; Reset DC.W BRKInst ; IRQ / BRK So in the above example, I've got a primary CODE segment, and at the end of that segment, but still within the CODE segment I've defined the STRINGS segment origin referenced at the top of the assembly code. Notice the macro, which is called from within the CODE segment, switches to the STRINGS segment, defined the data it wants to store there, and then switches back to the CODE segment for the remaining assembly code. As a side note; you can save even more ROM bytes by using the BRK instruction and placing your string's address after the break. If you want to get fancy, you can have a byte after the BRK that defines what thing you want to do, kind of like a system call, so the code would go BRK, function byte, low address byte, high address byte, and get away with a four byte print string call. Or if you just want to use it for string printing, just store your whole string after the BRK instruction like selgus mentions above and save two bytes by not using a JSR. Keep in mind that return address for the BRK on the stack isn't the next instruction immediately after the BRK, but the one after that (so the 6502 sees BRK as a two byte instruction, even though it's only one). Edit: Fixed code formatting
-
No worries, I'm glad to hear you're continuing to improve it. Just FYI, after a little hot rotary tool action, the screws ended up flush to the case and the UnoCart worked flawlessly even after multiple insertions. Hmm, maybe I should mark this reply as NSFW?
-
Just confirming this conclusion and adding a little more. I just finished a UAV/stereo mod on a light sixer and bought the UnoCart-2600 along with the UAV mod kit. Anyway, all of the carts that came with the sixer work just fine, but the UnoCart was just coming up black. I read this post and took the UnoCart out of its printed case and tried it bare on the 2600 and it worked fine! After a few other attempts, it appears the problem in my case are the screws holding the case together. They seem to protrude a bit from outside of the case. The UnoCart works without the screws, and doesn't work with them installed. I'm guessing it's just not able to completely sit within the cartridge slot with those protruding screw heads. I think I'm going to shave down the screw holes a bit and see if I can't make the screws sit completely flush with the cartridge. Thanks everyone in this thread, I was worried I'd have to send the UnoCart back since I also didn't have access to another 2600 to test on.
-
Small correction... In the "SixDigitDisplayKernel" code, it looks like GRP0/1 is set only four times per scanline, so this would only be a four digit (32 pixels) score kernel, not six digits (48 pixels). The two stores after the branch look to be used just to clear the sprite pixels for the next section on the screen. It's a lot of fun looking through this old code and trying to learn from the masters, thanks again!
-
Is there an official Atari Age GitHub portal? It would be pretty rockin' to have a collection of Gists!
-
Very nice! Seems like this would be a pretty early six digit kernel? I wish we had a stickied forum post with a library of "snippets" / tricks learned for the 2600 from your awesome disassemblies and home brewers. Even if it was a sampling of just the different kernels used in the original games, I'd still find that very interesting. And I totally agree with Mr. Davie, the amount of work involved in doing this is very significant. Especially when you're taking care to be able to create both NTSC and PAL ROMs from the source. Excellent work!
-
Oh damnit, you're right of course and I'm an idiot! ? I must've had "LDA (zp),y" stuck in head. Sorry about that!
-
Super minor comment here, but it looks like you have a left over illegal/non-standard opcodes that you're not actually using the benefits of in your kernel (left over code perhaps?): LAX (load the accumulator and the X register), specifically the "lax (P1Ptr),y" and "lax (P1Ptr2),y" instructions. Those both look like they should be LDX instructions, as you're trashing the accumulator right after each LAX instruction anyway and use X for a store later. It won't change your timing or anything, just gets rid of a couple non-standard instructions that aren't being used anyway. I do like your perfect 76 cycle timing though, very nice! ?
-
EPROM for homebrew 4k game cartridge
Kevin McGrath replied to nooly's topic in Atari 2600 Programming
Ah yes, sorry, I did mean a picture with the boards populated with parts that you're attempting to get working. ? If you made five carts, and they are all not working, and you're 100% sure the 2600 you're using to test works with another game, then I would think one (or perhaps both) of the chips was just soldered in the wrong way around. Meaning the notch on the white silk screen on the PCB showing which pin is pin 1 (the actual pin 1 is also a square pad on the PCB). The EPROM you're using specifically states that it's compatible with the Intel 2732A in its datasheet, and the pinout looks identical to my eyes. So I doubt that's the issue. If you have more PCBs, EPROMs and hex inverter chips, I'd get a 24-pin and a 14-pin sockets and solder them in, instead of the chips, so that you can use it to test if the chips work at all. Taking ICs out of a socket is a whole lot easier than desoldering them each time. You can even get a 24-pin ZIF socket (zero insertion force), probably like the same one used for your EPROM burner, to make it very easy to go from burning an EPROM to testing it in a 2600. But, what I would do is: Confirm both ICs are properly installed, with the notch/dot on the ICs matching the notch on the white PCB graphic silk screen. Check for shorts between pins using an ohm meter. Some shorts may be intentional, check the PCB photos to make sure that there's a trace going between those two pins. When the cartridge is in the 2600, confirm that both ICs are getting +5V to Vcc (pin 24 and pin 14, the square pad on the PCB for each chip is pin 1, the pin on the opposite side of the chip is pin 24/14). You will need to attach the ground of the ohm meter to ground on the PCB, I'd pick the wire coming off of the capacitor where the silk screen says "C1" (one side of GND, the side nearest the edge connector, the other side is +5V) to clip the ground of the ohm meter onto. You can look for a broken trace visually too, but if all five carts are not working in the same way then I would guess it's not a random broken trace. All of this is most likely overkill though, AtariAge will sell you a custom Atari 2600 cart with your game and a label for like $25. Certainly a lot cheaper than individual EPROMs, an EPROM burner, PCBs, LS04s, an ohm meter and cases. Hard to beat that price, IMO: https://atariage.com/store/index.php?l=product_detail&p=949 -
EPROM for homebrew 4k game cartridge
Kevin McGrath replied to nooly's topic in Atari 2600 Programming
Also, if you have an ohm meter with conductivity testing, try testing all of the connections between the pins of the two chips, looking for a short. It's very easy to have a bit too much solder and create a bridge between pins. If you use too much heat, you could even bridge nearby pins your not even soldering (or destroy the chip). Photos of the PCB might also help identify bridged pins. Were you able to get the cartridge working?
