Old News - 2000 | |
|
Old News (12/16) Seems like my ISP troubles are over for the moment. I've got a new e-mail address, listed below in the contact section. I've spent the last week or so working on a PC-Engine emulator. It's something I've always wanted to do, considering how poorly my MESS PCE driver came out. I don't know when it will be released, however it is fully portable (like SMS Plus), has decent performance, and plays a large number of games. So I think it's becoming fairly worthy of a public release. Here are some screenshots from a few of my favorite titles:
![]() ![]() There is no CD game support, but I have spent a lot of time working on that, mainly in disassembling the system card and learning how the CD hardware works. I have also considered adding SuperGrafx support, but the dual video chips make efficient rendering fairly hard to do. I'm also not sure how things like interrupts and layer priorities are handled with the SGX, so there's still a lot of research left. Probably of interest to emulator authors only, I have compiled some notes on the PC-Engine/SuperGrafx hardware, which will be included with the emulator's source code. Old News (12/03)
I've released a Super Magic Drive transfer utility, called smd. Old News (11/29) I've released a new version of the Sega Genesis Hardware Notes. Old News (11/24) I've released some documentation on the Super Magic Drive hardware. I basically disassembled the entire BIOS and figured out how everything worked. :) I was digging around through some of my old projects, and forgot just how cool the System 16 emulator I wrote was. Because I hadn't worked on it for a while, it was easy to fix a lot of bugs. :) I've got the sprite rendering pretty much perfect, minus scaling for some games like Altered Beast. I also finally removed the 8-bit rendering code (palette compression is a pain) and wrote some fairly good 16-bit rendering routines, which will make a very nice translation to assembly. I have been putting a lot of work in the System 24 emulator recently (still piecing together the memory maps), but have some problems figuring out the sprite hardware. If anybody owns Scramble Sprits, Hot Rod, or Super Master's Golf, I have some questions about the object test screen in the service mode, which could be answered by getting a screenshot or description of what display looks like. Old News (11/21) David McEwen has released an Acorn RISC OS port of SMS Plus! You can check it out at his website: http://www.acornemus.freeserve.co.uk Old News (11/19) More Genesis stuff today - I've updated my Genesis Hardware Notes with expanded information on the I/O registers. Old News (11/18) I've finally gotten around to compiling some information on Genesis display timing, which you can get here. I came across FFE's official SWC/SMC documentation from their old website, which would of been nice to have prior to looking at the VGS source. :) It's aimed towards the Super Famicom more than the Mega Drive, but things like the file header and transfer protocol are still relevant to both machines. The command list is somewhat different for the SMD. Old News (11/16) I fixed all my problems at once. :) I sifted through the VGS source code, and worked out the communication protocol for the SMD. Not only did I improvise on the cart loader to send SMS/GG games through the parallel port (no more hassles with floppy disks), but I also dumped the BIOS - the SMD's firmware allows you to peek and poke at any address, which made this a snap. I'd like to release the BIOS, but can't post ROMs here so I'll stick it somewhere else later on. I'll also add the transfer program to the other SMD utilities I'm working on, which should be finished in the near future. The BIOS is pretty neat - it's a Z80 program running in SMS mode. Oddly enough, the credits list Front Far East *and* China Coach as the developers. I thought they were rivals in the copier industry. And here's a snapshot of it running in everybody's favorite SMS emulator: smdbios.gif One of the things I worked out was how to initiate a dump of the cartridge from the PC side. The SMD BIOS will not attempt to read special cartridges, but forcing a dump through my transfer program seems to work fine. Through some cartridge stacking trickery, I was able to dump my Pro Action Replay II, and also a few SMS games. However the latter is severely limited, as only the first 48K can be read. It would seem that accessing the bankswitch registers cannot be done, even though you can page the SMS cartridge space through a 16k window on the SMD. Oh well.. there go my ideas for dumping Phantasy Star MD, though at least the first 48k of 512k could be easily retrieved. Regarding the Pro Action Replay II, I'm thinking simply emulating it would be a great way to add a cheat finder to my emulator. It's got some extra RAM that I have implemented, and if I can figure out how the game cartridge is swapped in and out, then this might be a viable solution. In the meantime, here's a snapshot from genecyst - the color problems are due to the extra RAM being emulated, btw. Old News (11/12) What the fuck is with Fresh Baked Games? These guys spammed me to ask permission to use my Metal Gear Solid FAQ on their website - my disclaimer clearly states they can't. Furthermore they reference the FAQ using the name GameFAQs gave it, meaning they are simply filtering e-mails off of GameFAQs pages and mass-mailing anyone who turns up. Last I've heard, about 50+ people who also have their stuff on GameFAQs have gotten mail from these guys, which is pretty bad. This goes against my ethics here. Spam sucks, and getting it from some half-assed FAQ site that is hardly even up and running isn't a very cool thing. I'd bet that Fresh Baked Games will end up stealing people's guides (am I talking about Cheat Code Central here?) in a pathetic attempt to add more content to their site. I'd like to urge anyone who has written a game strategy to not allow Fresh Baked Games to use your work. These guys just want to make buck or two off your FAQ. I love the Fresh Baked Games website - the links for 'LEGAL' and 'PRIVACY' conveniently do not work. ;) Looks like an indication of what's to come... Old News (11/11) After an extended bout of Genesis programming today, I finally got around to checking how interrupts work in mode 4. I was eager to see how the results match up to what I have in the SMS VDP documentation, and was more or less correct. :) The interrupt scheme in mode 5 is really confusing, so I needed to see what it was based on, which was part of my motivation.
Here are the notes I wrote up - should be very handy for SMS/GG emu authors: vdpint.txt. Old News (11/10) I've been doing a lot of Genesis programming recently, because it's a really cool machine to program on, and it's an interesting challenge to push the hardware as much as possible. Here's the latest thing I've whipped up:
![]() It may not look like much - but of course there is more 'behind the scenes' then a single low quality snapshot can show. The top half of the screen is in SMS mode, the bottom is the native Genesis display mode, which is then split again; the left half has shadow / hilight mode enabled, the right does not, and the blue column is made of high priority sprites which mask any flicker between the shadow/hilight display transition. So it's something of a 3-way split. :) One thing that made this rather difficult to do was that the SMS section of the screen doesn't react at all like it should. For some reason the first and next group of four bytes both define pixels for the same line. And the Y scroll register doesn't work (X does), instead it offsets the actual screen a bit. It's the exact same result as messing around with the vertical hold - now that's weird. To actually do vertical scrolling, it seems that any VSRAM entry beyond 32 will work. Why VSRAM would have any affect at all is also a mystery! I think this is probably some side-effect of when the SMS/Genesis mode switches are done. I originally thought that at a certain point, the VDP grabbed the register contents for whatever mode it thought it would display, and then ignore everything else. Not so. It's more like the VDP grabs settings at various points, so switching things at the wrong time gives unpredictable results. Case in point: messing with the interlace bits forced the display into a noninterlaced state, with only the odd frame being shown, and gap between every other line. I'm hoping to expand this program into something really neat, even though it's very basic right now. There's a console programming contest at www.y2kode.com, and old systems like the Genesis, SNES, NES, and SMS are included. I'm considering entering this program when/if I can add the effects I've got planned. :) In the same tradition as S!P's excellent Copper demo for the PC, I'd like to have something that has amazing visuals made soley by the video chip, without relying on CPU power to generate graphics. There's a lot of possibilities, so I've got to decide on some design factors first. Some other interesting things I've noticed (about mode 5): sprites are processed on the previous line than the one they are shown on, and are not processed when the display is blanked. This is why in the picture above, there's a one line gap between the middle border and the sprite column. Also, when the display is un-blanked, the last sprite setting the VDP looked at will be displayed - quite noticable in games that do sprite tricks mid-frame. (like Castlevania Bloodlines) Before you point out that this would limit sprites from being shown on the first scanline, I'll mention that the NES has a similiar behavior, and solves the problem by parsing sprite data on the *last* line (262), so everything is ready for the first. Neat, huh. :) I guess that's that - looks like a fairly big ramble this time around. Old News (11/7) I'm discontinuing the Sega System C2 arcade game emulator. I respectfully ask any website that has the source code to delete the archives for the current and past versions. Distribution of the Windows, Linux, or DOS binaries is fine with me. I don't have to say anything about the source code license now that this project is finished, since it prohibits all re-use anyways. Old News (10/29) Well, I finally got around to taking a screenshot of the Genesis shadow/hilight colors from a real machine running my test program. This was something I was meaning to do, since the old 183 colors demo I wrote actually had some bugs that didn't show up on an emulator.
![]() The colors make up a 256x192 block. I wanted to center the image as the resolution is 256x224, and came up with an interesting solution. What the test program does is enable the regular display mode (mode 5) at the top of the screen, wait a bit for everything to stabilize, then turn on the display. At the end of the frame (line $C0), the VDP is switched into mode 4 (the SMS display mode). This makes the VDP automatically center the first 192 lines in the middle of the display since it thinks it's going to show a mode 4 frame, but I just switch back before any of the graphics are actually displayed. It's a pretty neat trick, and all it took was a little clever thinking. :) Maybe I'll release the test program in the future - needless to say it does not work with any emulator. :) Old News (10/28) I visited emulition.com and found out that both SMS Plus and the Sega System C2 emulator have been ported to Linux by Ulrich Hecht. This is great news, as the more ports the merrier. :) You can check out the ports at emulinks.de. Old News (10/22) Another update to the Sega Genesis Hardware Notes, this time with 3-button and 6-button gamepad programming information added. News (10/20) And as promised, I've released my Sega Genesis Hardware Notes, which explains all the 'other stuff' that my VDP documentation didn't cover. Speaking of which, I am still working on the VDP docs. There's just a ton of material to validate and explain, plus I'm doing it in HTML format which takes a little extra effort. That's also amongst all the other projects I have going at once. :) News (10/19) I had the inspiration to try programming a GYM player for the Genesis, since in theory it shouldn't be too hard to do. What I ended up doing is not only finishing up the player (which sounds very cool btw, I've had the Gauntlet IV soundtrack running over and over :) but writing some very complete documentation on the Genesis sound hardware. Once I finish up the formatting a bit, I'll release it for public consumption. Maybe it will save a few headaches for Genesis emulator authors. :) I'll also release the source code for the player, but I'd like to add some improvements first - perhaps support for GYMX headers or some kind of visual display to go with the audio output. Old News (10/08) I added a link to Neo Zeed's Windows port of the Sega System C2 emulator. Apologies to anyone who came here and couldn't find their way to it. I might put up some screenshots of the Sega System 24 emulator in action soon. At the moment, I have the inputs working, the two lamps mapped to the keyboard LEDs, and the palette for the background layer partially working - I'm not entirely sure how the palette is allocated between the sprites, background, and whatever else. I've also figured out where the sprite patterns and attributes are stored. What's weird is that there's a large chunk of memory that sits between the object generator, and the mixer chip (which takes data and looks up palette entries while the display is scanned, for each pixel). Now that I've determined it's not intended to store sprite patterns, it's use is more of a mystery. I'm beginning to think this is the framebuffer hinted at in the System 24 flyer, since there would be enough memory for two 512x384 8-bit screens. Maybe a double-buffered system is used. Given the large on-screen sprite capacity, I'm guessing that they are drawn to the framebuffer instead of having the object generator sort through all 2048 sprite attributes for every single scanline. It would be very cool if either of the CPU's had direct access to the framebuffer beyond just being able to draw sprites. And if I'm right about this, it should be really interesting to see how it can be emulated without compromising speed. Anyway, I guess that's enough for now. :) Old News (10/04) As foretold in the Rumor Mill, I finally have my Sega System 24 arcade game emulator running some games. Regardless of System 24 games coming on disk or ROM, being encrypted or not, they all have some unprotected 'boot' code that gets the hardware up and running, using one of the two CPU's. Currently that's the part working in my emulator. It's the best way to get started, since all the problems related with getting data off the floppy disk or ROM board aren't present. Furthermore, the 'boot' code includes diagnostics, which means things like inputs, sound, colors, and the video hardware can be tested quite easily. What I might do is have a WIP section with screenshots and information about any progress made. I'm hoping development will be rapid as I already worked out quite a lot of the hardware prior to writing the emulator. The next step is to add some structure to the source code (probably by ripping the framework from SMS Plus or c2emu), so I can start implementing all the things I've got written down. The games that are working (not perfectly, I mean being able to navigate around in service mode only) are Hot Rod, Scramble Spirits / Super Master's Golf, and Quiz Ghost Hunter. Tokoro San 2 doesn't work at the moment, and beyond that I do not have dumps from any other games. (e.g. Gain Ground, Crack Down, Bonanza Bros, etc.) However, it seems that the early set of games all use the same or similar boot code, so chances are they'd work as well. Old News (10/02) I've been making a lot of progress with the Sega System 24 hardware. I found datasheets for all the types of RAM used, as well as ones for the floppy disk hardware. When (if) I get some games running, I can log commands to the FDC and figure out the disk format which may help in developing a PC tool to dump disks correctly.
I've also had some luck working out the memory map, and have determined out where the sprite attribute and name tables are located at. Old News (09/17)
NeoZeed has released the excellent Windows port of the Sega System C2 emulator! If you've read the Rumor Mill, you may know that I was planning to release a project today - well, giving out release dates ahead of time is not a good idea, as I've been busy with some other things and got sidetracked. I'll try not to do that again. :)
Expect a BIG update to my Sega Genesis VDP documentation
in the near future. Old News (09/15) As foretold in this weeks Rumor Mill, here's a new, bug-fixed version of the Sega Sytem C2 emulator. Minor changes, but important ones nevertheless. What's New: [Version 0.2b] - Haze submitted fixes for sample ROM loading in Stack Columns, and a bug with sprite width clipping. - Fixed version number display. - Improved sound channel disable switches.
There will probably be another minor update soon, as I've been changing some things in order to make it more portable to assist with the cool Windows port that NeoZeed is working on. In addition, Sadoru Nijino kindly informed me that the ROM set 'ichident' should be changed to 'ichidant', so be prepared for a ROM name-change in an upcoming release as well. I've also made a minor update to the System 24 info page. Old News (09/10) Sorry to make you download twice, but here's the source and binary to a fixed version which has the colors working right in Borench. Big thanks to Haze for the fix.
And here's what I had to say about the original release: I've decided to release a new version of my Sega System C2 Emulator Here's a list of what's new: [Version 0.2] - Many improvements and patches from Haze, including an in-game DIP switch editor. Now most games have correct colors and gameplay. - Zipped ROM support. - SN76489 PSG sound. - Preliminary uPD7759 sample support. - Second player input via gamepad or joystick. - DIP switch saving and loading. - Configurable paths for ROMs, snapshots, and DIP switch settings. - Shadow / Hilight display processing for Poto Poto and Puyo Puyo 2. - By default frameskip is disabled, can set up through configuration file. - Tweaks to the rendering code for unique sprite colors and 100% accurate priority handling. - Stereo sound swap option. - Fixed problem with button C not being mapped correctly.
And now for the post-release notes: I haven't gotten around to making a new DAT file for ClrMamePro, so please use the one from the previous release, or use one that somebody else might make. This is because I actually do not have all the correct ROM sets that are supported at the moment. :) Also, the palette code is a bit faulty, so currently Borench has bad colors when the dynamic palette is used. All other games appear to be fine, and I will upload a new fixed version in the future once I've worked out a solution. Other News: Added a new Video Game FAQs page with my latest work. Old News (09/02) I've made a very minor update to the Sega System 24 info page. Old News (09/01) I'm looking for the edge connector pin-out for Power Drift or Galaxy Force. Apparently the type of connector is custom, rather than JAMMA. If you have any details, please send an e-mail my way. Old News (08/29) Right, that was quicker than I thought - I've updated the Sega System 24 page with loads of detailed information on the hardware, which hopefully will be of use to people interested in emulating it. Old News (08/28) This might be old news to some of you, but I hadn't seen this until tonight - OverClocked head honcho David Lloyd deemed SMS Plus fit enough to grace the emulator list on the back of a very cool OverClocked-themed t-shirt! Not only am I honored, but I think it's great that SMS Plus is getting a little respect! It looks like Atlus have added a nice section on their upcoming PSX title, Persona 2: Eternal Punishment. Being a fan of the first game, I'm glad to see they are taking the risk of bringing over Persona 2 to the States, to please the die-hard gamers. Maybe they'll look into the loading time and random enemy encounter problems that plagued the original Persona. I'm going to have a large update to the Sega System 24 page, with detailed information on the hardware for you emu-programming types out there. At the moment I have all the inputs, sound hardware, interrupts, and some preliminary information on the FDC worked out. Can't exactly say when the update will occur, but I'm compiling my notes and writing up the HTML right now... Old News (08/21) Well, it seems like the Sega System C2 emulator was quite a success. I've gotten a lot of nice feedback, and hardly any ROM begs. I hope everybody has been table to find the right ROM sets, I decided not to upload all of them to a free site as I have a slow modem and they'd likely be taken down soon. So it's too much trouble on my behalf. :) A number of people have asked if my Sega System 16 emulator is still being worked on, and yes, it is. There's just a lot of work that needs to be done, and finding enough spare time is never easy. Maybe I should put up some screenshots of the new games I've added at some point. Since all my previous emulators have been for single systems, it's been quite difficult to come up with a clever way to support multiple games that can share some of the same resources, like memory maps, sound hardware, etc. Speaking of, I'm really interested in finding some schematics for the Sega System 18 boards. It doesn't matter what the game is, I just want to find out what custom chips it has, and how the VDP is used. There aren't enough bootleg/unprotected System 18 games (only three to my knowledge - Moonwalker, Alien Storm, and Shadow Dancer) for me to experiment with. That said, to my understanding schematics are very hard to come by for Sega games. Old News (08/16)
Time for another release - this time it's a Sega System C2 emulator
for DOS.
Old News (08/13) I didn't think it would actually come to this, but... To clear up any ambiguity about providing credit when using information from my Genesis or Master System VDP documentation, I have the following to say: If you use any information from this document, please credit me (Charles MacDonald) and optionally provide a link to my webpage (http://cgfm2.emuviews.com/) so interested parties can access it. The credit text should be present in the accompanying documentation of whatever project which used the information, or even in the program itself (e.g. an about box)Considering the amount of time and effort I have put into writing these documents for the good of the emulation community, I am not asking much to simply be credited for my work. I've also added some new links to cool sites that are worth visiting, including Emucamp, the Past-O-Rama homepage, the AGES homepage, and various places that focus on console (PSX, Saturn, DC) development. Old News (08/10) As promised, I've made another update to the Genesis VDP documentation. Old News (7/30) I've updated the Genesis VDP documentation with new information on VDP register sets that I finally figured out. Nice to see some long standing bugs go away. ;) There will be some more updates to the VDP docs in the future, too. Figured I'd share some interesting findings. It just so happens that the Sega System 18 VDP chip has the exact same part number as the Sega Genesis VDP. I can tell you that the similarities end there, since the System 18 video hardware is otherwise almost identical to System 16, meaning memory-mapped name tables, palette RAM, etc. I always assumed the identical part numbers was a coincidence. Now it gets a little interesting. I've been adding support for System 18 games in my Sega System 16 emulator. (see news item below for more) During debugging sessions, there is a lot of suspicious access to memory addresses C00004h, C00006h, and C00000h, which correspond to the Genesis VDP's control and data ports. What's even weirder is that they are being programmed the exact same way the Genesis would be. For instance, I have observed that Alien Storm, Shadow Dancer, and Moonwalker all write two words to the control port (thus sending a full command word) and repeatedly write data to the data port. Also, all three games will do VDP register sets, and the data they write matches the contents of each VDP register more or less exactly (none of the DMA registers are accessed - just up to the window control regs.) The only catch is that apart from the register sets, the data written is all zeroes, and the command word sent alternates between 40000000h (write to VRAM address zero) or 80000000h (illegal - seen as a register set). But suffice to say, it is very unusual that the video chip would be programmed in the same manner as the Genesis. From what I've heard, the Genesis video chip in the C2 hardware has it's palette RAM memory mapped to the same addresses used by System 18 games. Maybe there really is some similarity between the VDP chips used in the System 18, C2, and Genesis. I'll be looking into this more as time permits. Anyway, as you can guess, an update to my System 16 emulator (which really needs a name to prevent confusion) is coming soon, though I can't say exactly when. Old News (07/21) I tend to have a lot of partially finished projects collecting dust on my hard drive, lost in a maze of directories. Recently I put a little time into working on a Sega System 16 arcade game emulator, and now I have it running Shinobi fairly well. (my favorite game, by chance) I've decided to release the emulator, even though it's at a pretty early stage of progress.
![]() Sega System 16 emulator in action Turns out there's a minor bug in the Genesis VDP documentation. After doing some debugging with Golden Axe II, I found that clearing the address/code registers after a VDP register write screws up the 'SEGA' logo name table data. Kind of annoying, since some tests I had done earlier seemed to confirm that both registers are indeed cleared, but it's quite hard to get accurate results when you have to patch games two bytes at a time to run your own tests. Old News (07/07) I've made a small update to the Genesis VDP documentation. Hopefully for the next version, I'll have some concrete info on interlace mode 2 (finally got this working so I can do some experiments), and on line timing. (i.e. HBlank and all that) Also, I uploaded the YM2413 emulator source code from SMS Plus so people needing YM2413/VRC7 sound emulation can pipe the output from my code into a real OPL-2/3 sound chip or YM3812 emulator. You can get it at the emulation page. Old News (07/06) I just realized something really interesting. If you've checked out the example program listed in the previous news, the docs say there's a problem with nibbles being swapped within each byte of video RAM. This seems to be due to some video cards being designed loosely around the VGA specs. The neat thing is that you can have the VGA solve this problem automatically for you, with just one line of code. The solution comes from the barrel rotate function, which is normally of little use. The barrel rotator takes host data from the CPU, shifts it left by N bits (from 0 to 7), and writes the result to video RAM. You can set the rotate value to 4, so the data written by the CPU effectively has it's nibbles swapped around. This way, no matter what order of pixels are displayed on your video card, a simple write to the barrel rotate register will ensure the correct data is shown. Talk about an easy fix! :) Old News (07/05) I've uploaded the source and binary to a cool little program that shows how to set up a 16-color, packed pixel, linear VGA display. You can get the file in the programming page. Old News (07/05)
Oops! I realized the sound logs produced by SMS Plus are not GYM compatible. Old News (07/04)
Minor update: I've corrected the description of how VRAM fills work in my Genesis VDP documentation. Apparently KGen98 and genecyst don't emulate this correctly, as I had initially written up the VRAM fill section based on tests under those emulators . :) Old News (07/02) Time for version 0.9.3 of SMS Plus!
What's New: - Stereo Game Gear sound. - Save states, 10 per game. - Sound logging, output is .GYM compatible. - Optimized memory access for improved speed. - Screen snapshots in PCX format. - Stereo swap option for left and right speakers. - Added FPS meter. - Added some option toggle keys for in-game configuration. - Definable video driver. - Tweaked display modes for full-screen gameplay. - More of the usual internal changes and bug fixes.For your downloading pleasure:
I swore I'd get this out by the end of the week, and here I am typing
this text up at 11:55 PM. :) Soon, I'll release a music player for use with sound logs generated by SMS Plus. Hopefully something like a Winamp plugin will follow. In the meantime, my GYMplay utility works quite well for listening to PSG-only sound logs. Old News (07/01) Let's see...
I've updated the Genesis VDP documentation to version 1.5. Old News (06/25) I've got a few items worth mentioning: I've been having a heck of a time trying to get the current version of SMS Plus to be stable. The performance has dropped from 256FPS on some games down to ~190. I made very careful logs of exactly what things had changed, and there's nothing at fault - I think this is one of those things you can't control, like an important or often-called routine not quite fitting within a cache page, hence the slowdown. It's really annoying, but when I have some free time I will release a new version anyway. It's been too long since the last update, and there are a bunch of cool new features, like fixed save states, music logging, stereo sound, tweaked displays, etc. I've been putting together all my Sega Genesis notes to form a document describing the Sega Genesis VDP in detail, they are from tests on a real Genesis using a Pro Action Replay cart, programs I've written and run under KGen98, and my own experiences with Genesis emulation. Hopefully, they'll end up being at the same level of quality as my SMS VDP docs, for now you can read a preliminary version here. I've fixed up some missing files and HTML problems with the Console Info page, thanks to Mark for details. Old News (06/17) There is a new version of SMS Plus coming soon, so keep your eyes open. :) I've written a cool little program that displays 183 blazingly vivid colors on your standard Sega Genesis / Mega Drive console, using the underrated but very versatile "shadow / hilight" image processing mode. Here's a picture of the demo in action, taken from KGen98: ![]() Amazing, ain't it? Demo program: stetest2.zip (binary and source included) If you own a copier, such as the Super Magic Drive or Multi Game Hunter, I'd really like to get a picture (via video capture card, preferably) of this program in action. You'll probably have to append the appropriate header to the raw binary image before sending it to your backup device. Old News (06/07) Oops, there are a few things I forgot to take care of in the current release of SMS Plus. For DOS users, you can hit the tab key for the usual software reset, or press the delete key for a hardware reset. This is useful for games that don't support the reset button normally. I accidentally left some save state code in. It's very buggy and should have been disabled. If you want to risk using it, press F5 to save your state and F6 to load. The data is written to a file called 'state.sta', and there's only one available. But like I said, it's not very stable. Barring that, everything else works fine. After I had uploaded all the files, I got the inspiration to rewrite some of the DOS video code and add support for tweaked displays. (which gives you a nice fullscreen picture like the '-expand' switch does, but with much less CPU overhead) I'm not in the mood to have another release just to address these issues, so at least you know to expect tweaked modes and hopefully improved save states in the future. At any rate, enjoy the current version. :) Old News (06/07) I've released version 0.9.2 of SMS Plus: What's New: - Digital YM2413 FM sound emulation. Drums sound real good, too. - System territory switch, default is overseas (Europe / USA) - Made some internal changes and clean-ups to the source code. - Revised document on porting to be actually useful. - Adjusted version number to stay in sync with the Macintosh port. - Support for ZIPped game images and games with 512-byte headers. - Screen expansion now works for 16-bit displays. - Fixed some centering problems with screen expansion on GG games. - Sound output using SEAL should be a bit clearer. - Configuration file support.
Old News (06/06) Are any viewers having HTML problems? I've noticed the introduction of the banner code has caused some weird text corruption under Netscape 3.04, but Internet Explorer 4.0 seems fine. Old News (06/05)
I'd like to thank JoseQ for hosting my website. If you notice any broken links or other problems, please let me know. Old News (06/03) Updated the SMS/GG VDP documentation to version 4.4 If I can ever remember to do it, I will update the shadow/hilight info page with real screenshots, soon. If anybody else has a good video capture card (mine horribly dithers images) and owns Red Zone or Sonic 3D Blast for the Genesis, lemme know since I need some pics. :) Old News (06/02) Updated the emulation page with links to the Mac and Windows ports of SMS Plus. Old News (05/30) I do not host the Windows port of SMS Plus here, though it seems for the time being you can get it at www.emuhq.com, since it was recently (at the time of this writing) listed in their news column. And please remember that any messages about a certain port should go to the respective maintainer of that port. I handle questions about the PSX and DOS versions only. Old News (05/29) As I had hoped, SMS Plus has been ported to other platforms.
Richard Bannister has done an excellent Macintosh port.
Also, I've gotten to try a beta of a Win32 port too, though it hasn't been released yet.
Maybe somebody will do an Amiga or BeOS port? :) Old News (05/23) I've released version 0.9 of SMS Plus. New stuff includes: -Everything has been rewritten from scratch. The emulation is much more accurate, as a result compatability has improved greatly. -The DOS port has a lot of nice features added, including 16-bit color, display blurring, digital sound emulation, and scanlines, which were the most requested items. -Also new is a Sony Playstation port, though it's highly experimental and has some serious performance issues. -SMS Plus is now free software; the source code is available for anyone to use as they see fit, and is distributed under the terms of the GNU General Public License.You can get a DOS binary, PSX binary, and full source code here: sp052300.zip Old News (05/16) Hey folks, time for some more info on the DOS/PSX version of SMS Plus. I've got everything pretty much done at this point. Currently you can compile either version from the same source tree with no adjustment to the makefiles or anything. Both versions run games just fine, but I'm going to go into detail about performance issues. The actual system emulation is mostly complete. Only some obscure features have not been added:
The DOS version is very fast even though all the display rendering code is in "C", it's about as optimized as possible. It should run over full-speed on a Pentium 133. I'm going to see what kind of special effects can be added, like scanlines, tweaked video modes, etc. Right now it runs in a 320x200 VGA display, with keyboard input only. Regarding the PSX version; it's not very fast. You can watch games play with a frameskip of 32, but they are hardly playable themselves. This is because the CPU emulation takes *so* much time. (This is probably also because I cannot optimize the CPU emulator either, since the compiler crashes on -O2 or higher). Also, (under caetla) I get repeated errors about 'data store' exceptions, which I guess is caused by unaligned word or longword access to memory. I don't know what the problem is, but I've ruled out my handling of the display emulation and memory mapping for the SMS/GG, because some games can run fine for hours on end without ever producing an error, while the games that do always screw up at the exact same point. If anybody knows more about this kind of problem, I'd sure like to hear about it. I've had some ideas floating around for handling sound emulation under the PSX. I believe too much overhead is involved with converting a stream of 16-bit (mono) signed samples into the ADPCM sample blocks as required by the SPU, then playing those in sequence. The sound chip used by the SMS is quite simple, it has three tone and one noise channel. Only the frequency and volume can be modified. So, a possible solution would be to store a 'tone' sample in the SPU, and just play that back with varying frequency and volume settings. To my understanding, the PSX has a noise generator, which could be a replacement for the sound chip's noise channel too. Of course, the optional YM2413 sound chip probably couldn't be emulated this way (at least for the custom instrument; and I'd need to get the built-in instruments sampled to begin with), but that's something to work on later. :) I've got a lot of comments from people saying they were displeased with the PSX port of Master Gear, in that case I'll tell you to stick with it for the time being. :) Maybe in time SMS Plus for the Playstation will be a good competitor, but right now it does not exceed Master Gear's performance. At any rate, I will release the source code in a few weeks, probably sooner. Now I have to write up some docs, find a good license, and start wrapping things up... Old News (05/13) Wow, the counter is going up like crazy. I wonder if this site got linked from somewhere else, since I usually do not have so many visitors. Here are two new pics from the Playstation port of SMS Plus, taken from Shinobi 2 and Wonderboy 3, which show off the Game Gear emulation code that I recently added. I've included a funky border around the emulated display to make the rest of the screen look a little more interesting. :)
 
 
 
 
I've been working on writing a portable version of SMS Plus, that hopefully can compile both MS-DOS and Playstation binaries from the same source tree. When/if this makes enough progress, I'm going to release the source code under one of those really restrictive licenses, so everybody else can have fun and see how it works. I've never tried to write anything that was portable before, but I had to rip so much stuff out of the original version of SMS Plus that I figured this would be a good way to learn more about keeping programs hardware and operating system independant. One more thing; does anybody know of a utility to convert ECOFF object files into ELF format? Or how to adjust the stack size of a MSVC produced win32 binary? (something akin to stubedit for dos/djgpp, I guess). The compiler I use crashes due to stack overflow when compiling a large file with optimization enabled, and I'm stuck trying to come up with a workaround. Old News (05/09) Figured I'd share some pics from one of my current projects; a port of SMS Plus to the Sony Playstation. The in-game pic is dumped from the PSX's framebuffer, and the other pic is a DOS box at the time of the game running. Currently, a big problem is speed. Short of writing a Z80 emulator in R3000 assembly, I'm going to try and optimize the display rendering routines, and see what kind of improvement that gives. At the moment, the emulated display is stored in memory, and is drawn at an incredibly slow rate by using the putpixel function of the GPU to draw 49,152 pixels per frame. Not very efficient? I agree. :) What I'll probably end up doing is to store the image as a texture, and upload sections of the display that have been altered to the texture page. Or, I could use the masked drawing mode and 8x8 tiles and draw the display that way. Other items of interest; the emulator runs at 256x240, which is close to the real SMS resolution of 256x192. Oddly enough, the PSX output looks *exactly* like a SMS game running through the Power Base Converter, meaning the Genesis in SMS mode must display more lines per frame. Also, the PSX version of SMS Plus uses caetla, so I can load SMS and Game Gear ROM files directly off my hard drive, without having to send anything to the PSX beforehand. Very convenient.
Old News (04/24) I've recently written a guide on modifying the VMU save data generated by Resident Evil, Code: Veronica, for the Dreamcast. You can get the latest version at GameFAQs. I suppose I should blow the dust off gymplay and release a new version. I've been meaning to also add OPL-3 output via the SND library, which is an excellent alternative to more conventional sound emulation methods. While I can't make any promises, I'll see what I can do about a future release. The genecyst save state doc has been updated, with details on data formats and header validation. Thanks goes out to trzy for verifying and contributing information. Old News (04/11) Got a Dreamcast, RE:CV, memory card, and VMU. I'm very, very impressed. :) I say this every month, so here I go again: a new version of SMS Plus is on the horizon. What's interesting is that it really is almost done, I've got all sorts of cool features implemented, and improved emulation. All I have to tackle now are some save state problems, and fix some very minor bugs. I'm quite eager to finish SMS Plus, since I've been working on it now and then for some two years now. Old News (03/25) I finally got around to updating the Sega System 24 hardware info page. I've included ROM and disk images, and more detailed information on the custom chips and other components. Old News (03/24) It's nice to take some time off from doing a big project once in a while. I did a total re-write of SMS Plus, and it now plays every single game I have except for Aerial Assault (GG). There are some very minor bugs due to interrupts and timing problems, but overall SMS Plus is very close to 'perfect', which is hard to achive. :) I've also written standalone DOS emulators for the games 'Minivader' and 'Penguin-kun War', which are both emulated in MAME. What's really cool is that I've ported SMS Plus and the Minivader emulator to the Playstation! They both run incredibly slow, this is due partially to the unoptimized graphics routines, and the Z80 CPU emulator which takes up a lot of time. I'm going to be fixing up this site eventually. There are some broken links and other stuff that needs to be dealt with. I'm also going to be releasing the source code for a few of my projects, including SMS Plus, so keep an eye out for that. Oh yeah, the window intensity description in the shadow/hilight docs is incorrect. :) I need some way to run test programs on a real Genesis... Old News (03/16) Weird that an update to my shadow/hilight doc would come exactly one month later... Just a minor change, the hilight bug in KGen is explained, and the default intensity state of window tiles is also mentioned. I've also done some tests on a real Genesis regarding undocumented features, maybe I'll put together a text file explaining them.. some are actually used in a few commercial games! Old News (02/16) I've released a doc explaining the 'Shadow / Hilight' feature of the Sega Genesis VDP. You can check it out here. Old News (02/11) I've been developing a way of playing back Sega Genesis music that doesn't involve GYM logs, but instead is much more like the SPC files generated by Super Nintendo emulators such as ZSNES. The main problem is that where the SNES sound hardware is almost completely self contained, the Genesis is the exact opposite. The 68K has full access to the sound chips and Z80 RAM at any given time, and the Z80 can bank in anything on the 68K's bus. This can make for quite a lot of problems. What I'm currently experimenting with is dumping the state of the sound hardware at a given point; and keeping track of the 32k sections banked in. Luckily, this is almost always from ROM, though it's possible for the 68K to generate sound data on the fly in it's RAM and have the Z80 grab that when needed. I've only gotten two games to work, those being the intro music for Land Stalker and some music from the sound test of Galaxy Force. It's not much, but definately shows that this method is a viable option. The advantage to this is the size of the state file; 8K for the RAM, 512 bytes for the YM2612 register cache, a few bytes of miscelleneous data (Z80 banking, registers, etc.), and a variable number of 32K sections. (most games only use one to six ROM chunks anyways). Compare that to a ~5MB GYM file that has all the usual problems like no looping, and starting/stopping at the wrong points. It seems a lot of games will wait for the 68K to modify a byte in RAM to signify that the Z80 can go ahead and play the next sequence of music. This, unfortunetly, is impossible to support without emulating the 68K as well, and at that point you're pretty much writing a Genesis emulator, which isn't the idea. Nevertheless, I'll be sure to update in the future about any more developments I make with this program. And one more thing, it's quite possible to play sound from existing emulator save states (i.e. genecyst), though since they do not save the bank data, you'd have to have a copy of the ROM from the same state file you're using for it to work properly. (Not all games use the banking feature) Old News (02/10) Version 2.0a of GYMplay is now available, fixing a DAC enable bug which kept some GYM files from not playing properly, like Combat Cars. You can get it in the emulation section. Old News (02/08) I've released a small program which demonstrates how to set up a 320x800 16-color display without needing any Super VGA timing. Anything that's pure VGA is cool. ;) Old News (01/09)
Mega Man Secrets Revealed! There's a Genesis game called 'Wily Wars' or 'Mega Man World', depending on the territory the game was released in. It's a combination of the first three Mega Man games on one cart. It has a feature where you can save and load your progress, mainly it records what robot bosses you've defeated. When you beat all three games, there is some sort of special mode available, which from what I recall is a few extra levels. But, the battery backed RAM used to save data is not supported by genecyst or KGen, which means you can never record your progress and see the extra mode. Why is this? Let's dig a little deeper. Every Genesis game has a 256 byte header at location 100h to 1FFh in the cartridge ROM. The 16 bytes at location 1B0h onward define how the battery backed RAM is implemented. If battery backed RAM is present, bytes 1B0h and 1B1h are set to the ASCII values 'RA', while bytes 1B2h and 1B3h define how the RAM is set up. Bit 6 of 1B2h should be set to 1 to specify that battery backed RAM is being used, while bits 4-3 denote how the RAM should be accessed. (the documentation is sketchy on this, saying a code of 10 is for accessing the RAM at even addresses, and 11 is for odd addresses - or something like that.) The weird thing is that this Megaman game has bits 4-3 set to '01' which is an invalid code. Furthermore, the remaining bytes in the header define the RAM range, which is usually set from 200001h to 203FFFh. This game has the range set to just one byte, at 200001h. My answer to all this is that Megaman doesn't use battery backed RAM, but instead uses EEPROM. Why, you ask? Here's my evidence:
I could be wrong, and this is pure speculation based on what I have observed. Besides, it's late, and I need to sleep. :) But I hope this little overview will generate some discussion about how the battery backed RAM (or EEPROM) is implemented in Mega Man, and how it can be emulated. I would really, really like to get a scan of the board used in this game, if somebody has a copy and wants to rip it open. If you have any comments, or would like to help, please send some email. Old News (01/08) I've released version 2.0 of GYMplay, my GYM player for DOS. Here's the list of new stuff: What's New ---------- - Loads zipped GYM files. - Can write sound output to a WAVE file. - Support for DAC sound from Megasis GYM logs. - Options for volume level, sound card, sample rate, looping, etc. - Supports the GYMX header and data compression feature. - Uses environment variable to hold commonly used options. - Added help commands. - Some nasty memory leaks fixed.You can get it at the emulation page. Old News (01/05) I've released two utilities; one that interleaves files (ideal for working with ROM dumps from 68000-based systems), and another one that converts SMD files into BIN. I'm releasing the latter program because it seems it's being done 'the wrong way' by existing utilities. ;) I've also made a very minor update the genecyst save state format doc. You can get both programs in the miscellaneous section of the emulation page. Old News (01/03) I've been working on a comprehensive document that explains how the window plane and shadow / hilight display processing mode of the Sega Genesis' VDP works. It also touches a bit on the priority system between background planes and sprites. I'm currently debating if I should make an HTML version with pictures to illustrate how these concepts work (all of which are extremely complex and difficult to explain), or if I should be lazy and just have a plain text file. :) I might as well give a status update to SMS Plus. I've added save states, (10 per game, easier to implement than I thought), zipped ROM support, and a new method to handle sprite & background priorities that is quite fast. It's the same technique I'll be using in my Genesis emulator, which will allow complex stuff like shadow / hilight mode to be emulated with no overhead whatsoever. (theoretically, that is :) I also plan to tweak the sound emulation for SMS Plus, by adding better noise channel emulation to the PSG routines, and fix some parts of the YM2413 emulator, now that I have the YM2413 programmer's manual. The rhythm mode (drums and all that) should sound more accurate. I don't know when a new version of SMS Plus will be coming out, but I've got quite a lot of stuff done, so I'd like to guess that it will be released sometime this month.
| |
| Return | |