Kevin McGrath
-
Content Count
23 -
Joined
-
Last visited
Posts posted by Kevin McGrath
-
-
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
-
1
-
-
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.
-
1
-
-
6 hours ago, Andrew Davie said:In preparation for that, I found that it doesn't/won't work.
At least, I'm having trouble with it - the local labels for example, are reused and thus have incorrect values later in the assembly.
I may be misunderstanding it - do you have a working-code example?
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 [email protected] 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
-
5 hours ago, Andrew Davie said:Great answer. This belongs in the new manual.
Would you mind if I included it?
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 / BRKSo 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
-
1
-
-
3 minutes ago, MacRorie said:Sorry about that. We keep trying different screws and different hole designs. We will keep at it.
-M
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?
-
On 7/21/2020 at 2:06 PM, xesf said:I manage to figure out what was wrong.
The 3d printing cartridge was not allowing the PCB to be fully connected to the console.
I had to sand the cartridge a bit to allow the PCB to be connected a bit lower and manage to make it work.
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.
-
On 7/25/2020 at 4:45 AM, DEBRO said:Hi there,
Bob Whitehead has my head spinning. Hopefully this labels correct and makes sense. He got this to fit in 2K of ROM.
The assembler reports out 14 bytes of RAM free but there are actually 16 more RAM bytes available because of how the RAM is used.
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!
-
9 minutes ago, Al_Nafuur said:How about a tool like Github Gist, BitBucket Snippets or snipplr:
https://gist.github.com/https://bitbucket.org/snippets
https://snipplr.com/there might be better ones, the most important feature should be the search function..
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!
-
Just now, splendidnut said:The operation LDX (addr),Y doesn't exist as a standard 6502 instruction: http://www.6502.org/tutorials/6502opcodes.html#LDX
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!
-
On 7/5/2020 at 9:42 AM, Karl G said:Thanks everyone for the advice. Another tip I need to remind myself of is to optimize for your specific need instead of for the general case.
Anyway, my solution uses 0s on each side of the graphics instead of a separate masking step, with two different zones to avoid crossing pages. I was able to draw all 5 objects as well as write to all 3 playfield registers (symmetric playfield), but no color changes. I use the same y register index for all objects, and set the pointers beforehand so that that's valid for each of them.
This will work fine for that idea I have in mind at the moment. Here's the kernel code in case anyone else might find it useful:
ldy #83 lda (PF1Ptr),y sta PF1 lda #0 sta WSYNC ; 3 (0) sta VBLANK ; 3 (3) jmp ____kernel_entry ;3 (6) align $100 KernelLoop lda (PF1Ptr),y ; 5 (69) sta.a PF1 ; 4 (73) lda Temp ; 3 (0) stx GRP1 ; 3 (3) sta ENAM0 ; 3 (6) ____kernel_entry lda (M1Ptr),y ; 5 (11) sta ENAM1 ; 3 (14) lda (PF0Ptr),y ; 5 (19) sta PF0 ; 3 (22) lda (PF2Ptr),y ; 5 (27*) sta PF2 ; 3 (30) lda (BallPtr),y ; 5 (35) sta ENABL ; 3 (38) lda (P0Ptr),y ; 5 (43) sta GRP0 ; 3 (46) lax (P1Ptr),y ; 5 (51) lda (M0Ptr),y ; 5 (56) sta Temp ; 3 (59) dey ; 2 (61) bpl KernelLoop ; 2/3 (63/64) ldy #83 ; 2 (65) KernelLoop2 lda (PF1Ptr2),y ; 5 (70) ____kernel_bottom_entry sta PF1 ; 3 (73) lda Temp ; 3 (0) stx GRP1 ; 3 (3) sta ENAM0 ; 3 (6) lda (M1Ptr2),y ; 5 (11) sta ENAM1 ; 3 (14) lda (PF0Ptr2),y ; 5 (19) sta PF0 ; 3 (22) lda (PF2Ptr2),y ; 5 (27*) sta PF2 ; 3 (30) lda (BallPtr2),y ; 5 (35) sta ENABL ; 3 (38) lda (P0Ptr2),y ; 5 (43) sta GRP0 ; 3 (46) lax (P1Ptr2),y ; 5 (51) lda (M0Ptr2),y ; 5 (56) sta.a Temp ; 4 (60) dey ; 2 (62) bpl KernelLoop2 ; 2/3 (64/65) sta WSYNC lda #0 sta GRP0 sta ENAM0 sta ENAM0 sta ENABL sta GRP1 sta PF0 sta PF1 sta PF2Edit: It seems that the spoiler tage and the code tag don't play nicely together.
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! 😀
-
5 hours ago, nooly said:Kevin, thanks a lot for your answer.
I must admit I'm not expert solder so yes, there could be shorts! I'll check for that. And yes, I did binary compare, it was OK. I haven't found solution yet. I made 5 carts and there's slim possibility that every one of them has a short.I uploaded pic of PCB, is there something that could be wrong with the combination of PCB and EPROM I'm using?
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
-
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?
-
1
-
-
Can you upload pictures of both sides of the PCB? There might be something someone can see visually that's the issue.
Also, you've read the EPROM in the burner and did a binary compare to the data you expect? Do you have a logic probe? Have you made sure that both ICs are getting power to the correct pins? It's super easy to install a chip backwards/flipped, especially on a PCB where you're putting chips on both sides of the board.
-
1
-
-
Love the cat petting bonus! That is supposed to be a bonus, right? Would be funny if the cat followed you after you pet it and scared away the dogs, but that would probably be too much of a bonus. Managed to get 20,147 so far.
Really nice graphics and intuitive game play!
-
13 hours ago, Andrew Davie said:Would seriously love to see what you can come up with regarding a chessboard display.
Forget about actual gameplay - just a board display would be super!
Challenge accepted!
OK, of course there's a lot of interesting issues trying to do chess with this kernel, not the least of which is that I'm a horrible pixel artist (aka not an artist). I can do evil and use the player sprites and missiles for the board colors and place the playfield graphics in front of the board (thank you hardware!), but coming up with recognizable black and white pieces is a bit beyond my skill set.
I mean, there's one color and transparency. How do you "outline" the black pieces when you've only got a 4x5 glyph and one color to work with?
I've attached a screenshot of what I came up with so far, but I've got timing issues somewhere so I'm sure this won't run correctly on hardware yet.
Atari's "Video Chess" was a masterpiece. It's incredible what they made the machine do back then.
-
2
-
-
11 hours ago, Mr SQL said:This is very cool! You've created a programmable character set like the VIC-20 that reads ASCII, looking forward to the adventure game!
The one in Dark mage is similar but does not have the programmable color.
Dark mage got 12 characters across dynamically with a screen buffer by using the SuperCharger for extra RAM - it's a 6K format but you can turn it to RAM.
Lots of potential for cool games with this framework!
Yes! Thank you! I really need to figure out a better way to explain how it works, I did a terrible job in my initial post I think.
The RAM text frame buffer actually contains offsets into the font, instead of ASCII. In the demo source I put a function that converts and "prints" an ASCII string anywhere within the frame buffer. There's just not enough CPU cycles to be able to convert each ASCII character into a font offset, so I diverted that step into the overscan/vblank time and just use font offsets in the kernel.
That also leads to an interesting trick though... You can put any offset from 0 - 255 for each character and the kernel will just blindly display those pixels. So, you could have an scrolling/animated glyph just by adding one to the font offset for that byte in the text frame buffer.
And of course the glyphs aren't required to be latin script characters, they could be tiny monochrome 4x5 pixel graphics like game pieces. I'm thinking about making a truncated font and a 2KB ROM demo. I don't think I could fit chess in 2K with the size of this kernel, but maybe a card game like poker. Educational games would be a breeze.
I'm loving the challenge of this machine. 😂
-
1
-
-
30 minutes ago, splendidnut said:Ah... ok... I misunderstood your original statement:
Made it sound like you didn't see the demo that was done with a "vanilla" cart in 4k.
Sorry, my bad, I don't think I was very clear on what this kernel does. It renders text from a text frame buffer stored in RAM on the fly during visible screen time. By this I mean that every character displayed on the screen is represented as a single byte in RAM.
With that kind of set up you can do anything the next generation of game consoles did, which all had character based RAM buffers (i.e. one byte points to one 8x8 pixel character).
This kernel uses one byte in RAM to point to one of 51 possible 4x5 pixel characters. That "text frame buffer" can be changed on the fly to display any kind of text screen desired.
The text display kernels I researched all seemed to work off of pointing to a binary blob in ROM which gets rasterized out. You might be able to change an entire line of text to another line of text in ROM, but you can't change each individual character where as with my kernel you can.
There's a lot of 2600 games out there though and I haven't seen them all by a long shot, so there could easily be a game that does exactly what I'm currently doing. I'll need to dig deeper.
-
27 minutes ago, splendidnut said:Very cool.
For the record, there was a 32 char, 5 row kernel done in 4k (no extra RAM/ROM/DPC/ARM):
I did look at that forum topic, but it was my understanding (perhaps incorrect) that it's displaying text strings from ROM. Wouldn't a 32x5 character display consume 160 bytes of text buffer in RAM? I don't see how you could do a completely dynamic 32x5 character display and still fit in RAM, which is why I went with just using the playfield for a 10x8 character display (80 bytes). The whole text buffer is in RAM so you can do whatever you want with it between frames.
-
32 minutes ago, s0c7 said:Have a look at Dark Mage to see a 4k example.
I had not checked out Dark Mage! Thanks for the tip, it looks pretty cool and probably does a lot of things I hadn't thought of yet.
-
First I'd like to state that I'm new to programming the Atari 2600, this is my first "kernel" and there's a lot of tricks I still have to learn about the system. While I was trying to figure out how to render a pirate ship for another game idea, I stumbled upon this idea for displaying a full screen of text and wondered if I could use it to make a port of Colossal Cave Adventure for the Atari 2600 from 1977. In other words, can you make a workable text display that is good enough to present the classic text adventure game on the original Atari 2600 hardware in a 4KB cartridge?
OK, in this case, "full screen of text" is eight lines of ten characters, or 80 characters total. That's not a whole lot, is it? But is it enough to make a playable version of the classic ADVENT?
I don't in any way wish to belittle Warren Robinett's incredible achievement with the 1980 Atari game "Adventure". I think the choices Mr. Robinett made back then had been the right ones given the systems limited capabilities. I still don't know if it's even possible to put 30+ room descriptions, items and enemies into a 4KB ROM like he managed to do. As they say, a picture is worth a thousand words, but a thousand words wouldn't fit into 4KB without compression. So even if he could have displayed enough text, utilizing graphics would give you a richer more enjoyable game.
To me, this is more about "can it be done" than "should it be done".
I have read about the 32 character text display demo and the 36 character demo, both are really impressive! However, my understanding is that those demos use pre-generated displays from ROM and DPC/DPC+/ARM features not found on vanilla (earliest) cartridges. I was curious to see if the Atari 2600, without any additional hardware except for a standard 4KB ROM cartridge, could display a large enough dynamic text screen for a playable version of ADVENT.
Kernel Features:
- Designed to work on original 2600 hardware with non-bankswitched 4KB ROM cart (like Adventure)
- Eight lines of text with ten characters per line
- Each text line can have different background and foreground colors (nice for text menus)
- Each missile can be positioned on any text line (0 - 7), with any X (0 - 159)
- Font used can have up to 51 3x5 pixel glyphs, enough for uppercase only English text, digits and some symbols
- 80 byte/character text buffer, unchanged between frames to allow for dynamic text displays
Kernel Limitations:
- Needs ~97 bytes of RAM, brutal given there's only 128 bytes available
- Two copies of the font is required, one normal and one bit reversed, consuming 512 bytes of ROM
- The kernel code is long, currently at 1,285 bytes, making this a challenge for a 2K ROM game
- The font and final display is beyond crude, essentially a 40x48 pixel display
Aside from Colossal Cave Adventure, this kernel may be useful for other games. For example, since the display is 10 characters by 8 lines, you could show a full 8x8 game board and use the 2x8 characters on the side of the display to show previous moves or moves being considered by the AI. Might be good for checkers/draughts or chess, or card games like poker or bridge. Text menus are also really easy with this kernel, of course.
Big "To Do" Tasks:
- Action/verb input: left / right to change available commands then button to select
- Room description text scrolling: up / down should let the player scroll the description
- Inventory: Probably just a bit within a single byte. Risk: commands change depending
- Real-time text decompression: 6-bit ASCII? Arithmetic/Huffman coding? Risk: scrolling!
- Reduced story: How much ROM left over, can we fit a fun playable adventure in 4KB?
- Setup a github repository for the source
- Get real hardware and a cartridge emulator for testing on the real thing
GIF showing how the first room description from Colossal Cave Adventure might look:
Your choice of background and foreground colors per line of text:
Which make joystick selectable text menus really easy:
-
7
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Newbie in the house! Questions for the Experts.
in Atari 2600
Posted
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.