TheMole

Warning, don't have your sound too loud for this one, there's a small bug that I haven't fixed witch garbles the sounds when Alex dies. I added the overworld screen back again, this time around with room for your score, life and amount of money. It was interesting, but I'm actually using the same screen in 9918a mode and F18A mode. The only difference with the F18A is a slightly tweaked, more vibrant palette. There just wasn't much reason to create a separate F18A version as I thought the 9918a version looks very good as-is. I also fixed the moonwalking sprites in ECM3 mode. I'm close to the point where I think it can be released for playtesting. We'll see how long it takes, but I'm hopeful .

I plan to make one version that detects and supports both chips. I was thinking about doing something for the v99x3 as well, but I don't know how feasible it is.

Thank you sir.

Rasmus, do you still support a downloadable version of js99er? I'd like to add some debugging tools that would benefit me personally (and anyone else using js99er to do GCC development in). Basically, I'd like to be able to read in a linker map file (such as the one attached) and be able to use the symbols in that file to watch memory, set the breakpoint, etc... linker_map.txt

Well... I don't want to put the cart before the horse (HAH! ), but I'm toying with the idea of doing a real cartridge release in professional/commercial packaging if I can garner enough interest in it to offset the cost of doing a run of manuals, stickers, boxes, ... currently I think somewhere north of 50 preorders should be enough. I'll definitely also release a ready-to-burn image, but I might wait until I've given preorders a chance. And as Ksarul pointed out, I'm looking to target the red 512k boards (which will be the minimum requirement), but it will work with the Ubergrom as well.

Thanks for the kind words everyone. Here's another update video, this time with ECM3 sprites and f18a graphics for the second level as well. Some small bugs here and there in my export tools (red edge on blue balls in first level, glitchy fire sprite in second level), but the engine is humming along nicely and getting more flexible by the day. Oh, remind me to do something about those moonwalking scorpions...

Really excited about this one. I'm repeating myself, but this looks absolutely stunning.

Is there any way to get off of the middle platform in the second level? I keep falling to my death... At least with this one, I'm in the ballpark of some those other scores... (for now ).

Indeed. Omega, I remember that, but I think any solution we come up with will reach a wider audience if you don't have to open up the console. I have some spare master system controllers laying around, let me see if I can slap together a prototype over the weekend.

Ugh... I gotta stop posting late at night when I've been looking for a bug for too long. Sorry for pointing fingers, turns out that there was a bug in my (long standing) loading code, which loaded the wrong values in my replacement table. That piece of code had been working great for a long time, so I never bothered checking it. Thanks for the quick replies regardless guys, much appreciated!

I'm seeing a strange issue with non-positional attributes in js99er (maybe issue is the wrong word, I might not be understanding how it's supposed to work). Haven't been able to test on real hardware yet, but I'm hoping you guys can help regardless. So, I've got a setup with two tile layers, with TL2 being the foreground, and TL1 a parallax scrolling background. Hence, a lot of tiles in TL2 are either fully transparent or have transparent pixels. I'm using the following register values: VDP_SET_REGISTER( 4, 0x04); // Pattern table at 4 * 0x800 (0x2000 - 0x3800) VDP_SET_REGISTER( 2, 0x04); // Nametable, 0x04 * 0400 (0x1000 - 0x1400 & 0x1800 - 0x2000) VDP_SET_REGISTER( 3, 0x4c); // Attribute table, 0x4c * 0x40 (0x1300 - 0x1400) VDP_SET_REGISTER(10, 0x00); // Second name table at 0 * 0x400 -> 0x0000 - 0x0300 & 0x0400 - 0x0700 VDP_SET_REGISTER(11, 0x0c); // Second attribute table at 12 * 64 = 0x0c * 0x40 -> 0x0300 - 0x0400 & 0x0700 - 0x0800 VDP_SET_REGISTER(25, 0x00); // Reset scroll registers TL2: Horizontal VDP_SET_REGISTER(26, 0x00); // Vertical VDP_SET_REGISTER(27, 0x00); // Reset scroll registers TL1: Horizontal VDP_SET_REGISTER(28, 0x00); // Vertical VDP_SET_REGISTER(29, 0x20); // Set 2 horizontal pages for TL1 VDP_SET_REGISTER(49, 0xb0); // 0xb0 = TL2 enable | ECM3 for tiles VDP_SET_REGISTER(50, 0x01); // Per tile attributes: TL2 adheres to sprite/tile priorities So, attributes are per pattern and not per nametable entry. I have copies of the attribute table in both pages for TL2 and a copy for TL1. I'm unsure whether it is necessary to have all three copies, but I figured better safe than sorry... This seems to work just perfectly, but when I 'wipe' stuff out by dynamically changing the nametable entries for the changing location of TL2 (in either page) by writing zeroes to it (pattern zero is all zeroes and has the transparency flag set in it's attributes), it neatly writes the pattern as expected, but it forgets about the transparency. At the end of this video, you can see an example of this in action (around the 40th second or so, Alex punches two blue blocks and they get replace by black squares while it should be transparent, like the rest of instances of that pattern all around it). I only see two possibilities at this moment: either I'm completely misunderstanding how per-name attributes work (entirely possible and perhaps even way too likely), or there's a bug in js99er (but that would be the first I've seen in the F18A implementation)?

Still a lot of work on this one, but I'm too excited not to share a sneak preview: F18A features used: ECM3 tiles, two independently smooth scrolling layers; but still 'classic' non-ECM sprites. Also, a small annoying bug that I'm not understanding at the end there...

If the group is going to pick up on the "build our own joystick" idea, I have a request: when building new joysticks, we should agree on a (standard) way to add more buttons for single player games. I would very much recommend to wire it so that the "player one" joystick has access to at least two fire buttons. For platform games, this is almost an absolute must, since it is very, very hard to be accurate when you have to push the stick up to jump. I would very much like to support a two button joystick in Alex Kidd. I had planned on simply reading out the P1 and P2 fire buttons for punching and jumping respectively, but if someone has a better idea, I'm happy to support that instead.

I'm targeting a standard 512k image, for price reasons (I want to make sure it stays affordable, and leave some room to splurge on packaging, manual, labels, ...). I have thought about saving your status in between levels though, but I'm not sure if I want to add it. Typically, these types of games have an average play-through time of 30-60 minutes once you know how to play it (there are 15 minute speed-runs of the original Alex Kidd on youtube...). A lot of the replay value comes from the fact that you'll need to start over again a number of times before you're good enough to get through it in one sitting. Having said that, times have changed, and modern gamers expect save functionality. If I do add it (undecided) it will be via a password system though (again, for that old skool type of feel). The cool thing about that approach is that all save data is encoded in the password, meaning you don't have to actually save anything on disk or NVRAM/battery backed RAM. Also, note that this game will require the 32k expansion. There's just no way I can fit the dynamic levels and graphics data in VRAM, AND keep the game running at an enjoyable speed.

Ok, we're finally back where we were before the move from disk to cartridge and we have enemies walking around our levels! This took a lot longer than I expected due to unexpected alignment issues and me stupidly forgetting that my tools needed to convert data to big endian format for the TI... (crazy that I hadn't ran into this before, but apparently all my previous tools only generated bytes and never words or double words... go figure...). Also, I now have more than 64k of data being loaded, which meant I had to revamp the way I let gcc pass on the location of data in the cartridge image: ld exports pointers to the data, which meant I was limited to 16bit. I had to write a script that pre-links the resource files, so I know where they will end up in the image and generates an include file from the linker's map file... cumbersome, but I think I found a cross-platform way of doing this in shell script. Added bonus: I no longer need to manually add external resources to my code, every file that I add to the resources folder will automatically get linked into the image . The first level in the clip is a relatively faithful copy of a level in the original game, including the enemy positions. For the second level, I just slapped some enemies where it looked ok to test the routines. Will need to do some serious tweaking to make the levels feel fair... . Next up (and before I release a demo cartridge image): Clean up collision detection with enemies a bit (I'm not going for pixel perfect, but currently it's way off sometimes) Add a third level Add some different looking enemies for the other 2nd and 3rd levels Add an F18A rendering path

Not really a mascot as such, but the TI logo was very present in a number of games .

Cool! Hopefully I'll have an update with enemies out in the next few days.

That's probably not impossible, given that there are open source interpreters for level 9's a-code adventures available: http://www.ifarchive.org/indexes/if-archiveXlevel9XinterpretersXlevel9.html I looked at a number of these as my next project a while back, but I'd really prefer to do a format that supports graphics. Sierra's sci games being the frontrunner .

Damn, those animations are beautiful! You're really raising the bar with this one. Regarding the horizontal scrolling: putting the panel at the bottom would impact gameplay more than just making the map narrower. One of the reasons it doesn't look very nice right now might be because you're forced to scroll relatively small distances in 8 pixel increments. It might look better if you could find a way to scroll less often, but 'further', if that makes sense... The example below uses this technique (but the other way around: it does smooth horizontal pixel scrolling, and vertical character based scrolling). Every time the character lands after a jump, the engine rapidly scrolls to center the image around the player. If you don't know which trick he's using you'd be hard pressed to notice that it's not using smooth scrolling techniques. In your case, you might consider splitting your map into two halves and scroll whenever the player ball lands in another half from where it started, each time scrolling as far left or right as you can. To say it with a meme: you wouldn't scroll very often, but when you do scroll, you scroll 64 pixels at once (over 8 frames, for instance). By the way, up until your Bouncy videos, these were some of the most impressive scrolling graphics I'd seen on the 9918a. Some very smart graphics design going on here.

Looks great, as usual. But in my test on js99er, only one out of three aliens moves around, and the particle ray doesn't collide with the aliens.

Yes, but I want an SD reading cartridge (I don't mind the CF card for the CF7+), to test and run new cartridge games I plan on writing . Also, it'd serve as the multicard to end all multicards: want a games compilation? Throw some games on the SD card. Want an educational software compilation? Ditto... Without the need to keep buying carts or to burn EPROMs. Something like the Mega Everdrive: http://shop.krikzz.com/Mega-EverDrive-v2-MEGAV2.htm

I'd love an SD card reading version of the ubergrom cart, and a small side-car version of the SAMS. Nothing in the console, 'cause that will limit it to a soldering-ready crowd. Nothing for the PEB, 'cause that would limit it to the PEB-owning crowd (I own one, but don't have the space to run it).

Isn't NV SRAM uber expensive at those sizes though? I was looking for a 512kB size chip on mouser and they're around $100! Does the atmega on the ubergrom board have access to the 512k ROM? If so, it should be feasible to add something like this to the atmega's SPI interface and replace the ROM chip with a non-NV (making it a non-non-volatile? ) SRAM chip. (Even if this isn't the case, you can route the data through the host system, I guess). But that's way beyond my skill level . Either way, I'm ordering my ubergrom cart today or tomorrow and will purchase an appropriate EPROM burner as well for testing Alex Kidd on real iron.

Cool, although I personally am not a big fan of the mega compilation cart concept (reminds me of those cheap pirate gameboy/NES 40-in-1 cartridges). I like browsing a collection of individual cartridges . Having said that, I know that's probably just me and other people will prefer the many-in-one approach. I can always burn an 8k cart myself (but if you ever do decide to put out a cart, you've got my money!).

Excellent, excellent game. Love the intro tune. Can we look forward to a real cartridge for this?