Jump to content

Kevin McGrath

New Members
  • Content Count

    15
  • Joined

  • Last visited

Community Reputation

12 Good

About Kevin McGrath

  • Rank
    Space Invader

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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!
  2. Is there an official Atari Age GitHub portal? It would be pretty rockin' to have a collection of Gists!
  3. 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!
  4. 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!
  5. 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! 😀
  6. 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
  7. 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?
  8. 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.
  9. 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!
  10. 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.
  11. 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. 😂
  12. 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.
  13. 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.
  14. 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.
  15. 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: Demo Video advent2600.bin ADVENT2600_Src.zip
×
×
  • Create New...