cdoty

I did look into Magellan, and designed a simple screen, but couldn't find any support for mode 2 color tables. I can't believe I didn't think of that; all I would have to do it draw one less row of the map. For some reason I was thinking the TMS9918 supported smooth scrolling.

Wow, Canada was a hotbed for small scale Atari 2600 development. Any idea on the number of cartridges produced?

The example has been updated again to support scrolling through the entire tilemap. The map currently scrolls cell by cell, rather than smooth scrolling, but it looks pretty decent when moving around the map. Download the example, with source, from http://www.rastersof...lkaExample2.zip The full tilemap takes up 24k of ROM space just for the tilemap. It does make it easy to calculate the scroll position as the Y position is the high byte, and the X position in the low byte, which can be added directly to the tilemap address to get the start of the map. I'm really liking sjasm (http://home.wanadoo.nl/smastijn/sjasm.html) for the z80 stuff. It make declaring variables in RAM a lot easier than it used to be, and the local label support has made it easier to write input handling without creating a ton of label names. Now my question is, can an area at the bottom (or top) of screen be locked as a score bar?

I've created a tool to convert from Polka's PPR to a pattern and color table for Graphics mode two. I've also include an assembly example that uses the data, along with the stg file exported from the VScreen editor. Mode 2 is setup to share the pattern and color table between each of the screen areas. It can be downloaded from: http://www.rastersof...olkaExample.zip (The SC4ToPPR tool is now included with the example). The PPR conversion tool will find the closest palette entry in the ColecoVision palette. This is only needed if the SC4 or PPR file uses a custom palette; which must be something that the MSX2 supports. If you create your tiles in Polka using the default palette, and import them into VScreen editor, the default ColecoVision palette will be used.

Here's a quick utility I threw together to convert an SC4 (screen mode 2/4 graphics file) to a PPR file, which can be loaded in Polka. I tested it with the sc4 file included with VScreen editor. http://www.rastersoft.net/SC4ToPPR.zip

Anyone checked out the MSX tools for graphics? Here's two decent ones I've found: Polka: http://www.msx.org/m...q=visit&lid=554 This allows you to make pattern, palette, and color data for a tile map editor. This creates tiles for graphics mode 2. VScreen Level Editor: http://abyssmsx.com/vscreen-editor.htm This is a tilemap editor. This can use the raw output of Polka to build tilemaps.The tilemap exported is based on the dimensions of the tilemap. For example, a 1x1 tilemap (1 screen wide and tall) is exported to 768 bytes. There is some work that needs to be done. The raw output of Polka has to be combined. In Windows you could use: copy /b Tiles.pal+Tiles.pat+Tiles.col Tiles.sc4 It wouldn't be hard to make a simple program to write the 32 bytes of the palette, the 2048 bytes of the pattern and the 2048 bytes of the color map to a single file. VScreen can also store additional information, such as sprite positions. I haven't looked into extracting this information. The formats are documented, and available on the VScreen manual page: http://abyssmsx.com/vscreen-doc.htm The sprite stuff is useless, as it uses sprite mode 2 of the V9938.

Beauty and the Beast. The graphics were amazing for it's time, and the graphics and gameplay were different than anything else available. I spent hours playing this game and still enjoy it today.

I'm not sure why people overlook the MESS debugger. MESS isn't the most accurate emulator, but the debugger is better than any I've seen in emulators. I typically use a more accurate emulator for testing and MESS for debugging.

Here's some info on an early Atari 2600 prototype: http://www.wired.com/magazine/2010/08/ff_prototypes/3/ Gives new meaning to 'Heavy Sixer'

Was the Amiga core able to run games and stuff? How far along did it appear to be?

That would be cool, especially if you supported other systems. Digital distribution could open up some possibilities. It would be easy to offer achievements/trophies. The achievements could be tracked by uploading a save from an emulator. This could be an incentive to purchase a digital version. The save could have your personal ID inserted into it by a PHP page; the ID could be set based on a purchase order number. The same web page could track your achievements, and allow them to be shared online. This rewards people for purchasing the game, rather than trying to penalize those that don't.

ULS sounds like a much better option, especially since it can build an encrypted CD image.

Wow, what haul. The SX-64 is worth it, by itself.

Having just completed a tool to sign a 3DO disk, I wonder if the same process could be applied to a Jaguar CD, especially since the keys are known. Has this been tried, or was it just easier to use the Jaguar CD?

Duplicate. Please delete.

How about this? Here's the demo, sources, and Windows tools: http://www.rastersoft.net/3DO/3DOInvades.rar And a repackaged set of lib/headers and a disk signing tool: http://www.rastersoft.net/3DO/HomebrewToolkit.rar http://www.rastersoft.net/3DO/3DODev.rar You still need to find a copy of 'Arm Software Developer Toolkit v2.50', but everything else is there. The tools use only the standard C library, so they will compile on Linux/Mac OSX without much problem. You would need to remove the windows.h include file and add typedefs for DWORD, WORD, and BYTE. For all the details check out the 3DO Zero forum post and the signing tool post.

The Commodore Amigo model looks interesting. Did you see their Com(m)odo OS? Definitely chuckle inducing; and brought back memories of the Commode 64 & Trash 80 days.

Don't forget the Wii exclusive NBA Jam! Boom-shaka-laka

Nice job on the release. What format did you use for the music? It was interesting to read that you limited yourself to the 68000 and OP. This is probably what a lot of professional Jaguar coders had to do, due to pressures from their companies.

Excellent job; It looks a little pixely. Possibly I've forgotten what the original PC version looked like.

I would say anyone that says that "you are an asshole", has no concept of the effort that goes into releasing a game for a classic platform. It would be nice if they took a few minutes of time to truly understand the time involved.

Uhm, I think you're actually proving his point. Many developers may have said, at one point, that the Jaguar was difficult to code for. But, once they grasp it, they change their mind.. I think that pretty much sums up programming, in a nutshell. Once you understand it, it's just a matter of finding a working solution. And programmers; it's easier to give an excuse than to actually try to figure it out. This seems to happen all the time. Take Valve, and their PS3 statement. They quickly changed their statement from "The PS3 is hard to code for" to "it takes a special talent to code for the PS3". Damn, I'm fresh out of clouds. I adopt Mr Morden's, we all need more cheeks, and clouds, like that. I mean, she is my girlfriend, but I'm willing to share pictures.

I finally got around to trying my Skunkboard last week. I am totally impressed with the quality and ease of use of the product. Now, if something like this was available on other systems (Genesis, SNES, TG-16, etc.) that would be close to Nirvana.

There are a few books for the BBC micro series of computers: http://members.aon.at/~musher/bbc/library.htm They have relevant information about 6502, but the BBC stuff would be useless.

Kudo's for keeping the price down. Looking at projects, like the Cuddle Cart, you could've easily raped people, and chose not to.