Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

154 Excellent

1 Follower

About billkendrick

  • Rank
    Chopper Commander
  • Birthday 05/04/1975

Contact / Social Media

Profile Information

  • Gender
  • Location
    Olympia, WA
  • Interests
    BASIC, Action!, games, demoscene, history

Recent Profile Visitors

8,373 profile views
  1. I tried it out briefly, and I noticed one thing happen that might be a minor bug. I was at the top right corner of the map, where there are four skeletons. As I ran back down the map to get away from them, a couple of the skeletons seemed to get forced into the wall of the hallway (where I assume they would not normally be able to walk). This happened while the screen was scrolling. I'm also wondering how the map graphics are being managed. Not sure if this idea would be suitable for 8-bit Unity, or even this game in particular, but a few years back I toyed around with an idea that took advantage of some of ANTIC's capabilities. So imagine you were making a tiled graphics game using ANTIC mode 4 (like it appears Dungeon here is doing). With tiles made of 2x2 characters, you get tiles that are 8x16 pixels in size. But since each tile takes 4 characters, and your font only has 128 available, you can only have 32 distinct tile shapes. My idea is to chop the screen in half (12 rows of 40 columns, instead of 24 rows), and then double the character set (font) graphics. Then, use a Display List LMS instruction every other row to redraw the same row on the following line. So now you have 24 rows rendering those 12 rows. Then, use a Display List Interrupt to simply flip between the character sets every other row. One font is for the 'top half' of your tiles, the other is for the 'bottom' half. You once again have 8x16 pixel tiles, but have doubled how many tile shapes are possibly (64 shapes). Here's a photo from an experiment from (ugh!) 3 years ago that I did in Action! Twitter thread: Using 4 character sets, and flickering every other frame (my so-called "Super IRG mode" from Gem Drop, and what 8-bit Unity appears to do sometimes, too (woot!)), you get more colors, too! Anyway, just tossing that out there.
  2. Unfortunately it's a bit trickier than simply converting a ROM to run on the Atari 8-bit. The graphics capabilities of the two are a bit too dissimilar. (e.g., on the 2600 you can replicate a player 2 or 3 times -- think of the bi-planes on Combat, or the cows in Stampede). That said, it HAS been done for a few games. Avery 'Phaeron' Lee (creator of the Altirra emulator) reworked a few 2600 games to run on the 8-bits. Offhand I'm not sure if they can run on 400/800, or if they need XL/XE. You can find them over on Atari Mania, for example: http://www.atarimania.com/list_games_atari-400-800-xl-xe-lee-avery_team_9933_8_G.html That lists Adventure, Midnight Magic (a favorite!), Raiders of the Lost Ark, Seaquest, and Stampede. See also Norbert Kehrer's straight up emulators that he's made for the Atari 8-bits: https://norbertkehrer.github.io/... including Atari arcade games Asteroids and Sprint 1, a Commodore PET clone of NAMCO's "Galaga" arcade game, and a Commodore 64 clone of NAMCO's "Rally-X" called "Radar Rat Race"... and even emulators of a PDP-8 emulator and HP calculators! Enjoy!
  3. And here's a quick vid of the app loading a parrot sample image over #FujiNet. (I'm actually running the XEX of my program off of an Ultimate Cart, since I don't have a local TNFS server set up yet, and I hate dealing with microSD )
  4. Awww yeaaahhhh! Thanks again! Here's a screenshot of the "gate" from Alternate Reality: The City, that I swiped from a Google image search and plopped in as a test image. First, in 320x192 black & white: And also in 80x192 4,096 colors!
  5. This is exactly what my web app does (it's very dumb PHP that fetches the image from the APOD website and uses ImageMagick and some other stuff to convert the images to something the Atari can read 'directly'). WRT APAC modes (both flickery 80x192 and non-flickery 80x96), that certainly could be done as well. The main issue is mapping the hues from the source image to the 16 hues the Atari provides (and no doubt fiddling with gamma, etc.) Not only am I not good at assembly yet, I'm also (ironically -- since I'm lead developer of Tux Paint) not that great with these low-level intricacies of graphics.
  6. Yeah, even just adding a NOP causes the crash. (Thanks for the idea! Did I mention I'm extremely new to assembly language, too!? ) So it's almost certainly something about the memory set up. The memory configuration stuff is kinda black magic, so I think I'll need help from a cc65 guru. (I'd really love some kind of "cc65 on the Atari primer", or blog series or something!)
  7. Well, right now, the `bne` isn't even happening. If I add only ONE more opcode to the dli() function -- say, uncommenting the `asm("inc %v", rgb_ctr);`, or even just repeating that `sta` to COLBK, Atari800 emulator crashes.
  8. They don't HAVE to be 2 colors only, if you use Display List Interrupts! And you certainly don't need the entire screen to be in these modes, thanks to Display Lists. Also, say you wrote a high resolution (GRAPHICS 8, 320x192) image editor / paint program. These modes would give you 2x, 4x, and 8x zooms, basically at no cost!
  9. So a few months back I made a very simple little web app (just a PHP script) which would fetch the latest Astronomy Picture of the Day (APOD) and convert it to a few Atari 8-bit formats, so you could fetch it over #FujiNet. It was as simple as OPEN'ing the URL, GET'ing the bytes, and POKEing them to screen memory. The other day, I started putting together an actual 'client', in cc65, which does the same thing, with a slightly friendlier interface (than "type all this in BASIC"). Then I decided to spruce things up even more and added the ability for the server to spit out three greyscale images (GRAPHICS 9, 16 shades), after breaking the image into red, green, and blue components. It should be obvious that my goal then became creating a ColorView mode on the Atari in cc65. Welp, this is where my utter inexperience with this stuff comes to light. I've struggled with memory management (but I think I'm getting there, thanks to some posts by @Wrathchild in a thread @Yaron Nir started a few months back). And I'm also struggling with my actual Display List Interrupt. So far I have a display list that invokes an interrupt (DLI) on every scanline (so each line is a different color: red, green, blue, red, green, etc.), and invokes a load memory scan (LMS) to interleave the three bitmaps (image 1, image 2, image 3, image 1, image 2, etc.). Then I have a Vertical Blank Interrupt (VBI) that flips between three versions of this display list (an RGB one, a GBR one, and a BRG one). My problem is I'm doing something that's causing a crash in my display list interrupt. (It's straight assembly code, currently as inline assembly within the C source.) I'd love if someone could look at this and tell me everything I'm doing wrong with it, because I'm sure there's a LOT to unpack here. If you want to see the code, you can peruse it over in the #FujiNet github project: https://github.com/FujiNetWIFI/fujinet-apps/tree/master/apod Thanks in advance! I really need to learn more of these dark arts. I was seriously spoiled by BASIC, TurboBASIC XL, and Action! back in the day, and C under more modern systems, these days. (Even C on BREW cellphones, almost 20 years ago, didn't really require any thought when it came to memory management!)
  10. Thanks all for the comments! Yeah, I'm sure I can optimize a lot more of the code, but so far it seems to be working alright, now that I've converted the VBI to pure assembly. So I've released a beta! Video: Download: http://newbreedsoftware.com/gemdrop_deluxe/ Source code: https://github.com/billkendrick/gemdrop_deluxe If anyone wants to submit patches or pull requests, feel free to send them my way! I appreciate the experts helping out. PS - So far I've tried it (the XEX build) out on: "Atari800" emulator (stock XL mode, basically) "Atari800" emulator in Atari 800 mode (400/800 OS, 48K RAM) Atari 1200XL via SIO2SD Atari 1200XL via The Ultimate Cart Thanks!
  11. Woo! Thanks, Willie! That version actually had some glitches due to the VBI being written in straight C. I finally figured that out, and fixed it, and spruced up the title/menu screen, and made a new beta release today! (Yes, 5.5 years later. ) Still only available as an XEX, so no high score or highest-level save, like the original Action! version had, but it's coming along (finally!) Download: http://newbreedsoftware.com/gemdrop_deluxe/ (And source is on GitHub!)
  12. I'm losing steam, but I THINK it might have just been due to using straight C within my VBI. I've rewritten it as inline assembly, and things seem more stable so far. Need to test a lot more. I was obviously spoiled by Action! back in the day.
  13. So almost 5 years ago, I took the source-code to my game "Gem Drop", written in Action! back in 1997 and ported it to C for cc65. I got off on a tangent hacking on cc65 header files, buying a house and moving out of state, etc. etc. etc. I finally got some of my header file hacking included in the upstream cc65 codebase, so this evening I finally went back and updated my code so it can build with cc65 (and its Atari header files) that come with Ubuntu. Yay! My problem is, I'm getting a lot of glitching on the screen when I actually play the game (sometimes your character mysteriously gets redrawn one line above where it should go; sometimes a rogue tile piece appears randomly on the screen, etc.; one time it started totally ignoring keyboard input!) None of these things are bugs in the original game... it's a quirk to my C port. Some things to note: I'm using a VBI to flicker between two fonts. Press [F] to toggle this effect (however, the VBI will still be running! Edit the code to disable.) Joystick or arrow keys move left/right. Down to pull down a block (or group, if they match vertically). Up to throw what you're carrying back up. Match 3 or more in a row vertically; horizontal matches will then also be counted. Player graphics used to draw the score-explosions when you make a match. Space to Pause, or console keys or Esc to abort. Title screen / menu is not really operable. The game supports Genesis game pads (for B / C to grab/throw) as an option. It will try to detect them at start-up. Is anyone out here willing to take a look at it and see what I might be doing wrong? The code is here: https://github.com/billkendrick/gemdrop_deluxe On Linux, I can just run "make run-xex" and it will build the XEX file and launch Atari800 with the appropriate options. If you're not on Linux, I'm assuming you're versed enough in how to build things in cc65, otherwise why are you reading this? Thanks in advance! PS - The original game from 20+ years ago (augh!!!) is here: http://newbreedsoftware.com/gemdrop in case you want to compare... Trivia: I actually ported it to C once before, back in 1998. I ported it to X-Window, and soon after to libSDL. That port runs on a ton of platforms! (see http://newbreedsoftware.com/gemdropx/)
  14. Both my 1200XL and 800XL have 256KB total, which makes for a nice 192KB RAMdisk. Seeing how many folks have a meg, I feel like I'm behind the times! (Mine were upgraded, not by me, decades ago.)
  15. I posted the 'best of' my junk a few years back... categorized and "screenshots" (terrible cellphone camera photos of my C=1902 monitor) even! http://www.newbreedsoftware.com/atari/relics/ Don't judge... I was a kid.
  • Create New...