Forums

WIP1 -
WIP2 -

A work in progress has been posted showing the SMS emulation in RetroCopy. RetroCopy is a fully cycle accurate emulator which has 100% compatibility with the existing SMS software library.

It should be released "soon", and the requirements are going to be relatively high compared to other emulators. It will require at least a 2GHz+ single core CPU. Any dual core CPU will do fine, RetroCopy is optimized for multicore CPUs, certain features will be disabled without a multicore CPU. An OpenGL compliant video card is also needed (anything with 64MB or more of VRAM will be fine). It is going to be released on Windows first but I hope Linux versions will follow not too far behind. 64bit versions will also be available and are somewhat faster (10-15%) if you have a 64bit OS.

Finally it is also using a new ROM format, tools for conversion (including source) and details will be released a week or two before the actual emulator release. Basically it is a 7ZIP compressed rom image which specifies all the needed information needed to play the game, error detection, and is extremely simple to implement in any emulator. There will be no more need for other compression libraries or internal databases. RetroCopy will not support the old .SMS format.

Now that's something ;-)
Seems very promising, we gonna love the 3D interface

PS: sincerely hope you will release your code or some documentations someday, accurate emulation is good, sharing knowledge for posterity is better

Out of interest, what was the source for the scans?

Maxim wrote

Out of interest, what was the source for the scans?

Well I grabbed some from the scans section of this site, and I have some I already have collected in the past. I'm looking at ones that are greater than 1200pixels on the horizontal.

But it isn't like I am going to be bundling jpegs with my emulator, it is simply something the emulator supports.

I have higher-res scans offline, some at 600dpi, if you want to go overboard. Packaging a 10MB PNG with a 32KB ROM is probably overkill though.

Getting permissions can be tricky.

Maxim wrote

I have higher-res scans offline, some at 600dpi, if you want to go overboard. Packaging a 10MB PNG with a 32KB ROM is probably overkill though.

Getting permissions can be tricky.

Permissions from whom? The guys who scanned it? I'm not sure what the legalities are in regards to putting these images somewhere like this site... is there any real issue with hosting them?

From my emulator perspective anything upwards of 4096wide would be "possible", but it seems from my experience a jpeg at 200-250KB - 1243x800 resolution, is very nice, you can read all the text and see all the pictures clearly.

Provided the image is the correct aspect ratio (and the side is the same width) it fits nicely onto the box. It's likely a few scans might need mangling to work specifically with my emulator, that is if you want them to look good, all the ones I've done so far have needed no work though. Which is pretty much how I wanted it to be.

The biggest issue after having decent resolution is getting "clean" scans, whilst the folds and tears add some character to the images, perfect ones (nice colors, no cuts/folds, etc) would likely be preferable by most people. It's very hard to get such things these days though with such old games!

To me it seems fussing over perfection of a virtual reproduction of a cover overly vein.

If you need a clean copy then I'm sure something could be photoshopped together to make a facimile of the original.

djbass wrote

To me it seems fussing over perfection of a virtual reproduction of a cover overly VAIN..

Check the logo up the top of this page... fanaticism... ;)

Some people make scans and then complain if anyone else uses them, especially without credit. Some of us don't really care...

A 1200px wide scan of an SMS box is just about 150dpi, so I have a lot of originals at that size which I intend to post as time permits. Some games had insanely small text which isn't easily readable at that size.

Getting "clean" scans is hard work. Provided it's in "mint" condition, you still need some effort (mainly something heavy on the scanner lid) and a good quality scanner to capture it without creases, lumps, bumps and reflections. Even then, some "photoshopping" is often needed.

Maxim wrote

Some people make scans and then complain if anyone else uses them, especially without credit. Some of us don't really care...

Ahk, giving appropriate credit should be done though, at least that's my philosophy with things.

Maxim wrote

A 1200px wide scan of an SMS box is just about 150dpi, so I have a lot of originals at that size which I intend to post as time permits. Some games had insanely small text which isn't easily readable at that size.

Yeah, my emulator allows you to zoom in which makes it somewhat easier to read those "small texts".

Maxim wrote

Getting "clean" scans is hard work. Provided it's in "mint" condition, you still need some effort (mainly something heavy on the scanner lid) and a good quality scanner to capture it without creases, lumps, bumps and reflections. Even then, some "photoshopping" is often needed.

Yep, it certainly seems like an artform in itself. You can appreciate the work good scanners do. One of the star wars scan from this site looks fantastic in the emulator.

PoorAussie wrote

A work in progress has been posted showing the SMS emulation in RetroCopy. RetroCopy is a fully cycle accurate emulator which has 100% compatibility with the existing SMS software library.

100% as in not even one game has a single flickering pixel that shouldn't be there? :D

If so, really exciting stuff!

Charles MacDonald wrote

100% as in not even one game has a single flickering pixel that shouldn't be there? :D

If so, really exciting stuff!

I wouldn't go as far to say that yet! I have played every SMS title and homebrew game and they "work" how I think they should. However since I don't have a real machine to test side by side it's quite possible there are some small issues. The good thing is if there are any issues it will be easy to fix because every cycle of the VDP is emulated and whatever issues that will be found will be "is register X latched or instantly updated?". or "does tile table grabbing start at mclk 16 or 8?"

A lot of my VDP is "logical guess work" combined with trial and error, so there is definitely room for there to be errors, even if all the current software work correctly.

I know it's a work-in-progress and I'm sorry ahead of time if my comments seem rude. The 3D box thing is pretty nifty, I liken it to wandering around Toys'R'Us in the 90s looking at the game flap things (you saw the covers on the wall and flipped it up to see the back cover). It's pretty nostalgic and a nice novelty. However, I don't really understand the non-full screen TV thing you've got going on. Personally, I don't see a real use for it, and if you're going to have that in an emulator with 3D boxes you may as well make the a 3D model of an actual TV (yeah, I know, it's a work-in-progress). The interface art you may want to "hire" someone on to do -- we programmers don't make very pretty non-native GUIs.

All that rant aside, I like your emulator -- I just thought I'd share my opinion as a fellow emulation fan/emulator maintainer.

P.S. You said it will use a new detection in its file format for game specific settings. I suppose you should make it know PAL/NTSC, FM, controller, 3D, etc. (I assume you planned on that but in the video you had to tick FM for Alex Kidd).

olaf wrote

However, I don't really understand the non-full screen TV thing you've got going on. Personally, I don't see a real use for it, and if you're going to have that in an emulator with 3D boxes you may as well make the a 3D model of an actual TV (yeah, I know, it's a work-in-progress).

Well there will be an option so you can start in fullscreen mode. The plan is to have save states showing, and other little things in the TV mode that you can select. It's also to add to the classic feel. I replayed some games simply because they were a bit harder with it on an angle (like a real TV perhaps) and it's kind of mesmerizing playing it on the "emulated TV" for some reason. Due to specific features I will be adding in the future, the "TV mode" is there to stay though.

It could look better though, and if it was a 3D model, then it would likely be a lot better too like you say. :)

olaf wrote

The interface art you may want to "hire" someone on to do -- we programmers don't make very pretty non-native GUIs.

Yes it is true we do not! Takes so many hours to get what I have in there though, so there is a certain amount of "sweat" to make it look even as "good" as it does right now. A real artist would do it with ease.

olaf wrote

P.S. You said it will use a new detection in its file format for game specific settings. I suppose you should make it know PAL/NTSC, FM, controller, 3D, etc. (I assume you planned on that but in the video you had to tick FM for Alex Kidd).

FM is shown disabled unless the game supports it (the file format tells you _everything_ about a game). Games with settings that are "important" will get them set by default in my emulator, FM chip to most people outside Japan is "different" and shouldn't be the default in my opinion. Something like 3D glasses is enabled by default since the game is unplayable otherwise (though I plan support NVIDIA stereo glasses when possible).

The controllers and things of this nature are all controlled from the header of the ROM, basically freeing up future homebrew developers to use whatever input devices they want without needing emulators to write patches specific for them. Even games with multiple controllers (like hangon/safari hunt) are handled fine, users are given the option to select out of joypad or phaser in the interface before starting, similar to plugging in either joypad or phaser on the real console.

The format is mostly designed to allow games to tell the emulator how they work and the default settings that will work the best. If authors want to target only the SMS2VDP, then they can. The compression and error detection are the other important reasons. Without this format it makes it a lot harder to do what should be done in emulators going forward. It also cuts back on people needing help with an emulator because problems are easier to pinpoint.

This emulator sure looks exciting! Will it be able to run on Windows 2000?

And how's the progress going?

I have updated the first post with a new WIP video for anyone who is interested.

mk1995 wrote

This emulator sure looks exciting! Will it be able to run on Windows 2000?

And how's the progress going?

Yes it should work on Windows 2000, there are very few dependencies in the project so it could work on a variety of systems (even DOS). Though the more systems you add, the more support you have to do with them all. The Windows 2000 "branch" will be the same as the Windows XP/Vista/7 32bit ones so it should be fine.

Progress is good, but I still have to make a website and finish a few more polishing type things on the project.

PoorAussie wrote

Progress is good, but I still have to make a website and finish a few more polishing type things on the project.

So you wanna say that the emulator is pretty much done now?

mk1995 wrote

So you wanna say that the emulator is pretty much done now?

The core emulation is pretty much done. A few peripherals, NES mappers, things like this still need to be done. The polish I talk about is things like configurations of input, video, etc, saving the settings, etc.

I'm working on the website at the moment so once that is done to a decent level I will be only a week or so off releasing something. The website needs to be done first so I can deliver the program and tools needed for it and to give a central access point for testing.

"NES mappers"? Has that anything to do with Ni******?

mk1995 wrote

"NES mappers"? Has that anything to do with Ni******?

Yes, take a look at the WIP2 video right at the end there. ;)

If you are going to include savestates in this emulator, my brother suggested creating savestates in the locations of the pictures on the back of the box so you could click on it and go to that location.

What do you guys think?

also are there going to be any instruction manuals included in the future? I know that would take a TON of time, heck I don't know how you did all those boxes but yeah, being able to click on the box and it open and the manual pop out would be great, maybe even have a render of the cart. I know that's a bit extreme but just throwing ideas out there.

panzeroceania wrote

heck I don't know how you did all those boxes

http://www.smspower.org/scans/

I have to say 3 things.

1) The interface and the features look definitely kickass, nice work
2) I think you should [provide an option to] hide the mouse cursor while playing a game
3) I'm still against the fact you created a new rom format :(

panzeroceania wrote

If you are going to include savestates in this emulator, my brother suggested creating savestates in the locations of the pictures on the back of the box so you could click on it and go to that location.

What do you guys think?

also are there going to be any instruction manuals included in the future? I know that would take a TON of time, heck I don't know how you did all those boxes but yeah, being able to click on the box and it open and the manual pop out would be great, maybe even have a render of the cart. I know that's a bit extreme but just throwing ideas out there.

Some nice ideas. In regards to the box scans, it is only thanks to the great work people have done scanning them, and then people like Maxim/Bock who put them up for others to use/look at. The Ni****do "emulation scene" is like a mere shadow compared to the work people put into the Master System (and GameGear I guess). It makes you really appreciative of the work people have done on the SMS side. One could contrast the fact that SMS did well in europe/australia whilst the NES did well mostly in the USA/Japan, different cultures. ;)

There are lots of things like manuals that would be relatively easy to include but we will have to see. Maybe people will get together and start scanning them if they can see their results in an emulator I'm not sure. It is one reason why I am not going to be writing some emulator specific format for these things and just keep them in jpeg or other standard formats (using XML to link them) so others can use them like I have. Even if people only get the motivation to do such things because they can see it an emulator if other people want the stuff (like SMSPower) they should be able to use it imo.

good deal sir.

yeah if you have savestates, linking from the images on the back of the box would be a great flashy touch to an already amazing idea.

As an american that grew up in the south pacific I appreciate all that aussies have done for emulation, video game preservation, and computers in general (see PuppyLinux) so more power to you :D

my brother was a diehard genesis and saturn owner, and also big into preservation stuff like the box art so he's going to LOVE this.

Replacing the screenshots will be hard because they're in a different place on every box - and some boxes don't have any.

Better might be to show the savestates in the background of the "TV mode", perhaps just as a grid (which could scale to many saves; I know I'd want at least 4 or 5 sometimes).

It might be nice to have a history timeline for the rewind feature, by showing a bunch of screenshots horizontally. How much history are you keeping?

It's sad that I probably can't be bothered to convert/package my games just to try this emulator, when there's no compelling reason to switch. (It took me a long time to switch to Meka's crazy interface, only because Massage was so inaccurate/out of date.)

Nice, keep up the good work! ;)

If there is one thing I'd ask, it would be the support for the normal ROM format alongside your format. Even if it meant for some features to be disabled.

So, can you please add that support? Or at least make special build just for those of us who want it? (and maybe even distribute it by PM/email or something) =P

Good luck!

AamirM wrote

Nice, keep up the good work! ;)

If there is one thing I'd ask, it would be the support for the normal ROM format alongside your format. Even if it meant for some features to be disabled.

So, can you please add that support? Or at least make special build just for those of us who want it? (and maybe even distribute it by PM/email or something) =P

Thanks for your support. I'm not going to be supporting the old format though, the interface relies upon information in the new format to work and I don't want to mess the code up with separate paths for such things. I have a different philosophy than some I guess, where I don't mind getting rid of the past if there is a better way (imo) to do things even if that means less people like what I do.

As Maxim has shown, some people just don't see any compelling reason to use my emulator and they have no problems using existing ones with the old format. The tool for conversion only takes a single click and a minute of time to process every SMS game down to 60MB. I know however that anything at all is too much for some, so I'm sorry about that! There are many great emulators for SMS like MEKA, Kega and Regen that support the old format so I'm sure everyone can be happy.

BTW I'm looking forward to your cycle accurate SMS emulator in your future versions!

I was just wondering, WHY cant you use .sms??
I mean, all that extra info, cant you just have that stored within the emulator itself?

Peder Johnsen wrote

I was just wondering, WHY cant you use .sms??
I mean, all that extra info, cant you just have that stored within the emulator itself?

Yes I could store it in the emulator, but I would still need to do something like checksum the file (ie read the entire file and checksum it) to then load certain things for that file. If you don't have a dynamic interface then it's not such a problem doing this as it only happens when you load the game to play it, the SMS also doesn't have large ROMs which makes this a lesser concern, but it is an issue for other systems and future larger games. It can be a noticeable delay, even with a 512-1024kb file and a few clicks, as I had this setup previously.

I just have no desire to use the old format and store information like that in my emulator or config files. If no one ever breaks the cycle then we will never go forward. On the real system the cartridge "tells" the system more than a .SMS file does. Emulator authors for the SMS have been forced into very generic programs due to being unable to test "weird" programs in emulators and not wanting them unplayable. The new format allows authors to put similar information into the file as they would in a real cartridge (and instruction booklet) so they work like they should.

Whilst I call it "my format" in here, I don't really see it as "my" format and I haven't branded it for personal glory or anything of this nature. It's a system generic ROM format. I really wish someone had already done this as it is a complete PITA for me, but the global economic crisis has given me time to do things I otherwise wouldn't..... ;)

You can read the CRC32 from the Zip structure incredibly quickly. The same applies to RAR and (probably) 7z.

Worst case, you can have the metadata indexed by filename (and check the checksum on load).

Maxim wrote

You can read the CRC32 from the Zip structure incredibly quickly. The same applies to RAR and (probably) 7z.

You can't rely on roms being zipped though in the "old model" can you. :)

So I can either add support for RAR, ZIP, 7Z, ACE, ARJ and whatever else people demand due to there being no standard or I can do what I've done.

Plus CRC32 is so 1990s. ;)

Maxim wrote

Worst case, you can have the metadata indexed by filename (and check the checksum on load).

So I have to force users to a certain rom naming scheme? ie I have to make them run a converter to the "right" filenames. ;) Why not make them run a converter to a new format while I'm at it?

There are no real solutions in the old model unfortunately, only hacks and half solutions. I'm not really sure why anyone defends the old format, I mean change is something that takes work but sometimes it has un upside, and I have done most of the work for whoever is interested. Plus it is not like anyone is forcing you to use my emulator or the new format. If your philosophy is you only like the .SMS format and nothing else then there are plenty of good emulators to use with it, even ones in development like MEKA, Kega and Regen.

Personally I cannot see why having 2 sets of your roms in the worst case is that big of a deal to some people, especially when it is only 60MB extra. My emulator also forces you to put ROMs in a specific folder, another design decision some people may not like. Until people have used the emulator though and understood why I did the things I did they may not see the whole picture. I'm going to have to put a fancy credit window in the emulator now to get you to use it I think.... bribes still work right? ;)

PoorAussie wrote

So I have to force users to a certain rom naming scheme?

You can scan once and cache local information.?

I can see so many cons of doing that, some have been enumerated already (the worse being the nature of the information you are storing which are bounds to keep changing in the following years) but the point is that you can have all those improvement for your emulator without the hassle of a new format.

And you'll have to provide those scans/meta infos in some way, you are not going to distribute ROM ? Meaning that you already need to do package them as separate data somehow. And your transformation tool probably use a checksum database to associate this data to the .sms files? It is difficult to take seriously that you have problem finding a creative solution to checksumming when you've done such a brilliant work with the emulator. I agree with moving forward but that sounds like stubornly breaking interopability.

Looks like you're not going to change your mind so soon anyway, let's see what happens.

Btw I haven't replied on this thread before but the emulator looks good. Again it is losing a lot of appeal for not being open-source in 2009, but I'm hoping it might happen eventually. I think there should be more pride today as a programmer to lead and succesfully maintain an open-source project with contributors that an isolated effort. This is so 1990s :)

PoorAussie wrote

On the real system the cartridge "tells" the system more than a .SMS file does.

Well not much more. Nothing about inputs, which system it is supposed to run, game title, etc. I'm not teaching you anything. It would be much more sensible to setup an external format exported from a DB that could be globally maintained and even updated automatically for users.
My 2 yens.

Bock wrote

PoorAussie wrote

On the real system the cartridge "tells" the system more than a .SMS file does.

Well not much more. Nothing about inputs, which system it is supposed to run, game title, etc. I'm not teaching you anything. It would be much more sensible to setup an external format exported from a DB that could be globally maintained and even updated automatically for users.
My 2 yens.

The best person to design a header for a ROM is the author though, which is what my tool allows. Author sets the header once (uses lightgun port 2, joypad port 1, has a RAM mapper, etc) and then can distribute their game and have it work in emulators which support the format. There is no middle man here, no bureaucracy to get his game settings incorrect or a wait period.

Having a database means someone has to react to this ROM and then add it for others to be able to use it. What is the point of doing it this way? Either way you have to change emulators to be able to support the new global database. And then you are still stuck with other issues, uncompressed roms, numerous compression schemes to support, no quick checksumming features, untimely database updates.

The future in my vision is the following :-
1) A single modern compression library to support. Reducing emulator complexity, bloat and easing portability.
2) A header that tells the emulator the best settings for the game
3) Allowing quick checks for modern checksums and proper error detection.

A global database only offers one of those things. My tool already has a database with settings for many game. But the tool also allows you to create your own databases (which I ran on .SMS files after smschecker for my database)., and then to go around and edit the headers as you please. Fixing/changing headers is easy too if mistakes are made. Users are going to be stuck using tools like SMSchecker or my database tool to verify their games pretty much forever, so if mistakes are made or tweaks needed in the header they aren't a big deal (though hopefully the current library will have no issues).

Game settings such as input/3d glasses are things that are known about the game, whether through the back of the box or the instruction manual. If they are needed to play the game a person who owns the real thing knows this, so it's implied knowledge that should be in the header. So whilst not in the "cartridge" per se, it's in the "game packaging".

Bock wrote

Btw I haven't replied on this thread before but the emulator looks good. Again it is losing a lot of appeal for not being open-source in 2009, but I'm hoping it might happen eventually. I think there should be more pride today as a programmer to lead and succesfully maintain an open-source project with contributors that an isolated effort. This is so 1990s :)

The programmers who can contribute anything but minor things to my emulator though would be few and far between, at least those with the TIME to do such things. The only reason someone like myself who has high competency in coding has been able to pour time into this is unemployment and not wanting to work at the moment.

If I wasn't so obsessed with doing this I would be off making my 180+K/year doing what I usually do. Only someone with a silly obsession would abandon making that much money for 18 months and put it into a massive project like I have been working on... silly, obsessed and now poor. ;)

That said if I ever see the end in sight I will open source it, like you did with MEKA. There just is no point right now doing such things..... so we will wait and see. Talk is cheap and I need to deliver something.

MEKA basically failed its open source conversion because it came too late and was too much the result of me working in an igloo for the past years. (added to the general factor that techniques and knowledge have evolved a lot since interned boomed).

We agree that very few people might contribute, but you don't need many people. eg: I already offered to help and you know I am rather obsessed with this. Arguably I might be lacking skills on some areas but probably could contribute decent debugging tools for example. Open-source doesn't mean you must hand over source control write access to everyone. There are other people here and elsewhere on the internet would can bring good things.

PS: No need to brag about salary, I found a decent balance at getting underpaid - relatively speaking to other IT industry - to do my hobby :)

Wait... it's not open source?

PoorAussie wrote

You can't rely on roms being zipped though in the "old model" can you. :)

So I can either add support for RAR, ZIP, 7Z, ACE, ARJ and whatever else people demand due to there being no standard or I can do what I've done.

Plus CRC32 is so 1990s. ;)

CRC32 is about 60 bytes too small for the collision probability you might want.
The current standard (for SMS) is (1) uncompressed or (2) zipped, one per zip. Hardly any emulators support anything else.

PoorAussie wrote

Maxim wrote

Worst case, you can have the metadata indexed by filename (and check the checksum on load).

So I have to force users to a certain rom naming scheme?

No: have a map of filename to metadata index. Also have an option to populate the current dir's metadata, like Meka does, rather than wait for the user to prime the cache by loading all the files. You check the checksum on file load in case the user overwrote the file.

PoorAussie wrote

Personally I cannot see why having 2 sets of your roms in the worst case is that big of a deal to some people, especially when it is only 60MB extra. My emulator also forces you to put ROMs in a specific folder, another design decision some people may not like. Until people have used the emulator though and understood why I did the things I did they may not see the whole picture.

I can see you're going for "it just works" - if legality weren't an issue, you could just bundle all the ROMs in the app installer. (If the emulator's any good, there'll soon be copies on file sharing sites and burned CDs on eBay which do just that.) The problem I see is how you will manage to update the metadata in old .game files. The central DB approach is the only real solution to that.

PoorAussie wrote

I'm going to have to put a fancy credit window in the emulator now to get you to use it I think.... bribes still work right? ;)

I may still check it out if I find the time. Why not bundle the converter in with the app? How well does it run on an 800MHz machine with crappy integrated graphics, at 1024x600 maximum resolution?

Btw reminds me that the original idea of Meka - that never was - was based on a realtime 3d interface where you would manipulate cartridges (1998 with fancy perspective correction).
And then a bit later Mekadrive (mockup courtesy of Marbleman) an idea that was floating in the air at some point with Charles (Charles already worked quite extensively on MD at some point as I recall).
I don't remember if those were published already?

meka3d.png (21.39 KB)

mekadrive.jpg (121.34 KB)

Maxim wrote

No: have a map of filename to metadata index. Also have an option to populate the current dir's metadata, like Meka does, rather than wait for the user to prime the cache by loading all the files. You check the checksum on file load in case the user overwrote the file.

There are certainly ways to "hack" it in, but it's just too much work really. I don't want to have to track files and caches to make sure it's dirty or correct. It adds complexity to something which shouldn't have it imo. A more reasoned developer may care about losing .SMS compatibility and decide it's worth it, but yeah.

Maxim wrote

I can see you're going for "it just works" - if legality weren't an issue, you could just bundle all the ROMs in the app installer. (If the emulator's any good, there'll soon be copies on file sharing sites and burned CDs on eBay which do just that.) The problem I see is how you will manage to update the metadata in old .game files. The central DB approach is the only real solution to that.

Yes you can see what I am going for, ease of use pretty much.

You could hotpatch .game files quite easily. My emulator doesn't support non writeable media for it's ROM folders but other emulators could support such a thing if they want. Every SMS game will be tested though before I release the database fully to the public, so in theory there will be no mistakes (famous last words).

Maxim wrote

I may still check it out if I find the time. Why not bundle the converter in with the app? How well does it run on an 800MHz machine with crappy integrated graphics, at 1024x600 maximum resolution?

It will run quite horribly on that unfortunately. Minimum resolution is also 1024x768 (4:3) or 1280x720 (widescreen). Graphics card isn't that big a deal, it's only my custom GUI which really NEEDS onboard VRAM (texture blitting is much faster). On a 6 year old laptop I have with a really crappy onboard gfx (sysram) I only get 6fps at 1280x720 in my "complex areas" of the GUI and fullspeed during gameplay. This is an athlon-m 1.8GHz. It's pretty much my "min requirement" test.

I decided for various reasons to force things like high quality audio filters and full 32bit alpha blended GUI on people, which isn't so intensive compared to the cycle accuracy cost but it all adds up. It's really an emulator geared towards modern computers in nearly every way. We might have to start a donation fund for you to get you a better computer I think, you've done a lot of work afterall. :)

Bock wrote

Btw reminds me that the original idea of Meka - that never was - was based on a realtime 3d interface where you would manipulate cartridges (1998 with fancy perspective correction).
And then a bit later Mekadrive (mockup courtesy of Marbleman) an idea that was floating in the air at some point with Charles (Charles already worked quite extensively on MD at some point as I recall).
I don't remember if those were published already?

Wow looks nice, especially for the time! What happened to this? :)

PoorAussie wrote

It will run quite horribly on that unfortunately.

Well, I have a decent Core 2 Duo machine sitting unused for lack of space, so I'm mostly using a netbook these days. It's adequate for most tasks, just not for anything expecting to run through a GPU. (My coding competition entry was done on it, for example; it runs Meka at 60fps at 800MHz on battery power.)

By the way, will this support GG eventually? Will you display a 3D animation of the GG? :)

Quote

BTW I'm looking forward to your cycle accurate SMS emulator in your future versions!

Haha, I never said cycle accurate "SMS" emulator but rather cycle accurate Z80 emulator :P. I am getting more interested in implementing SMS on an FPGA now.

Anyways, if it converts in just only one click, I'll try it. No more no less. :D

while it may be a big hassle for many, there are also lots of people who don't mind trying a new format so long as it does have real benefits.

Looking forward to the release :D

Tom wrote

By the way, will this support GG eventually? Will you display a 3D animation of the GG? :)

Yeah GG support is already in there I just haven't enabled it fully yet, I have tested it though (it's basically a NTSC VDP2 which I already support at the cycle level) and it works nicely. It's actually a nice help for SMS emulation since some GG games are timing sensitive.

I just didn't want to bite off too much for the first release, and I want to implement full GG emulation including the networking link (one reason dual+ core is nice since you need two GG emulators running in parallel) so I've put it slightly on the back burner until what I have is working nicely.

PoorAussie wrote

The best person to design a header for a ROM is the author though, which is what my tool allows. Author sets the header once (uses lightgun port 2, joypad port 1, has a RAM mapper, etc) and then can distribute their game and have it work in emulators which support the format. There is no middle man here, no bureaucracy to get his game settings incorrect or a wait period.

Are we talking about ROM releases of old commercial Sega games or what? You only need one Sega mapper for all commercial games, though that might go against the philosophy of the emulators goal.
What about new homebrew that makes use of the mapper in the ToToTek cart (as an example) or some new unknown Korean games, you would still have to update your converter and you emulator to support those games.

The other part is what hardware to run the game on, but that is up to the user right? I can put my cartridge in a SMS1 or a SMS2, that is what can happen in real life but not in your emulator, or? And why force a new format when you could have made it compatible with every other SMS emulator by using PK zip format and just include an extra header file in the zip? Then I might actually consider supporting it on my SMS emulator for the DS.

I really like your emulator so far, just hate the rom file format.

Metadata packed in a zip file seems to be the way a lot of things are going when they have a bundle of data to include - for example, Java JARs, Google Earth KMZ files, Winamp WSZ (skins), Office 2007 DOCX/XLSX/etc. (On the other hand, many also do it because they have XML inside and they want to offset the bloat.) So I wouldn't be too surprised if .game was a standard archive format underneath.

Regarding cover scans, I suppose you can consider a ROM dump, metadata, cover/manual scan etc as analogous to taking a CD and its cover/inserts/etc and producing an MP3/FLAC/whatever with embedded metadata, covers, etc - it's in no way authoritative, different people will always come up with slightly different results, even if they are broadly the same. The only difference is that ripping CDs is a lot easier.

I second the general opinion about a new ROM format, seems to me as a "control freak" feature (no offense) and a waste of time as it is more easily handled by an internal database (especially when this new ROM format is probably going to be only supported by this emulator) or by a customizable "cartridge emulator" (rom size, mapper type, etc... supported inputs being also configurable, there is no reason you could not try to plug a light phaser while playing alex kidd, even if it was not designed for ;-) )

I think it will also brings lots of confusion among current ROM sets, adding ROM file versions when it's not required. I don't know, maybe you could add these informations as a trailer so the ROM header remains intact and the file compatible with other emulators ?

Otherwise, this seems very promising (but you already know it), especially if the accuracy level is as claimed. I also hope that even if ou choose the closed-source way, you will release detailled informations about cycle accurate VDP as it would benefit to a lot of similar projects :-)

Author	Message
PoorAussie Joined: 26 Aug 2008 Posts: 292 Location: Australia	New SMS emulator: RetroCopy Posted: Tue Jun 23, 2009 6:48 am Last edited by PoorAussie on Fri Jun 26, 2009 1:54 am; edited 1 time in total
	WIP1 - WIP2 - A work in progress has been posted showing the SMS emulation in RetroCopy. RetroCopy is a fully cycle accurate emulator which has 100% compatibility with the existing SMS software library. It should be released "soon", and the requirements are going to be relatively high compared to other emulators. It will require at least a 2GHz+ single core CPU. Any dual core CPU will do fine, RetroCopy is optimized for multicore CPUs, certain features will be disabled without a multicore CPU. An OpenGL compliant video card is also needed (anything with 64MB or more of VRAM will be fine). It is going to be released on Windows first but I hope Linux versions will follow not too far behind. 64bit versions will also be available and are somewhat faster (10-15%) if you have a 64bit OS. Finally it is also using a new ROM format, tools for conversion (including source) and details will be released a week or two before the actual emulator release. Basically it is a 7ZIP compressed rom image which specifies all the needed information needed to play the game, error detection, and is extremely simple to implement in any emulator. There will be no more need for other compression libraries or internal databases. RetroCopy will not support the old .SMS format.

Chris Guest	Posted: Tue Jun 23, 2009 8:51 am
Chris Guest	Now that's something ;-) Seems very promising, we gonna love the 3D interface PS: sincerely hope you will release your code or some documentations someday, accurate emulation is good, sharing knowledge for posterity is better

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14735 Location: London	Posted: Tue Jun 23, 2009 10:18 am
	Out of interest, what was the source for the scans?

PoorAussie Joined: 26 Aug 2008 Posts: 292 Location: Australia	Posted: Tue Jun 23, 2009 10:41 am
	Maxim wrote Out of interest, what was the source for the scans? Well I grabbed some from the scans section of this site, and I have some I already have collected in the past. I'm looking at ones that are greater than 1200pixels on the horizontal. But it isn't like I am going to be bundling jpegs with my emulator, it is simply something the emulator supports.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14735 Location: London	Posted: Tue Jun 23, 2009 11:07 am
	I have higher-res scans offline, some at 600dpi, if you want to go overboard. Packaging a 10MB PNG with a 32KB ROM is probably overkill though. Getting permissions can be tricky.

PoorAussie Joined: 26 Aug 2008 Posts: 292 Location: Australia	Posted: Tue Jun 23, 2009 11:20 am
	Maxim wrote I have higher-res scans offline, some at 600dpi, if you want to go overboard. Packaging a 10MB PNG with a 32KB ROM is probably overkill though. Getting permissions can be tricky. Permissions from whom? The guys who scanned it? I'm not sure what the legalities are in regards to putting these images somewhere like this site... is there any real issue with hosting them? From my emulator perspective anything upwards of 4096wide would be "possible", but it seems from my experience a jpeg at 200-250KB - 1243x800 resolution, is very nice, you can read all the text and see all the pictures clearly. Provided the image is the correct aspect ratio (and the side is the same width) it fits nicely onto the box. It's likely a few scans might need mangling to work specifically with my emulator, that is if you want them to look good, all the ones I've done so far have needed no work though. Which is pretty much how I wanted it to be. The biggest issue after having decent resolution is getting "clean" scans, whilst the folds and tears add some character to the images, perfect ones (nice colors, no cuts/folds, etc) would likely be preferable by most people. It's very hard to get such things these days though with such old games!

thatawesomeguy Joined: 25 Jul 2007 Posts: 729 Location: Melbourne, Australia	Posted: Tue Jun 23, 2009 11:30 am
	To me it seems fussing over perfection of a virtual reproduction of a cover overly vein. If you need a clean copy then I'm sure something could be photoshopped together to make a facimile of the original.

PoorAussie Joined: 26 Aug 2008 Posts: 292 Location: Australia	Posted: Tue Jun 23, 2009 11:33 am
	djbass wrote To me it seems fussing over perfection of a virtual reproduction of a cover overly VAIN.. Check the logo up the top of this page... fanaticism... ;)

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14735 Location: London	Posted: Tue Jun 23, 2009 12:20 pm
	Some people make scans and then complain if anyone else uses them, especially without credit. Some of us don't really care... A 1200px wide scan of an SMS box is just about 150dpi, so I have a lot of originals at that size which I intend to post as time permits. Some games had insanely small text which isn't easily readable at that size. Getting "clean" scans is hard work. Provided it's in "mint" condition, you still need some effort (mainly something heavy on the scanner lid) and a good quality scanner to capture it without creases, lumps, bumps and reflections. Even then, some "photoshopping" is often needed.

PoorAussie Joined: 26 Aug 2008 Posts: 292 Location: Australia	Posted: Tue Jun 23, 2009 1:54 pm
	Maxim wrote Some people make scans and then complain if anyone else uses them, especially without credit. Some of us don't really care... Ahk, giving appropriate credit should be done though, at least that's my philosophy with things. Maxim wrote A 1200px wide scan of an SMS box is just about 150dpi, so I have a lot of originals at that size which I intend to post as time permits. Some games had insanely small text which isn't easily readable at that size. Yeah, my emulator allows you to zoom in which makes it somewhat easier to read those "small texts". Maxim wrote Getting "clean" scans is hard work. Provided it's in "mint" condition, you still need some effort (mainly something heavy on the scanner lid) and a good quality scanner to capture it without creases, lumps, bumps and reflections. Even then, some "photoshopping" is often needed. Yep, it certainly seems like an artform in itself. You can appreciate the work good scanners do. One of the star wars scan from this site looks fantastic in the emulator.

Charles MacDonald Joined: 28 Sep 1999 Posts: 1197	Posted: Tue Jun 23, 2009 7:14 pm
Charles MacDonald Joined: 28 Sep 1999 Posts: 1197	PoorAussie wrote A work in progress has been posted showing the SMS emulation in RetroCopy. RetroCopy is a fully cycle accurate emulator which has 100% compatibility with the existing SMS software library. 100% as in not even one game has a single flickering pixel that shouldn't be there? :D If so, really exciting stuff!

PoorAussie Joined: 26 Aug 2008 Posts: 292 Location: Australia	Posted: Wed Jun 24, 2009 3:14 am
	Charles MacDonald wrote 100% as in not even one game has a single flickering pixel that shouldn't be there? :D If so, really exciting stuff! I wouldn't go as far to say that yet! I have played every SMS title and homebrew game and they "work" how I think they should. However since I don't have a real machine to test side by side it's quite possible there are some small issues. The good thing is if there are any issues it will be easy to fix because every cycle of the VDP is emulated and whatever issues that will be found will be "is register X latched or instantly updated?". or "does tile table grabbing start at mclk 16 or 8?" A lot of my VDP is "logical guess work" combined with trial and error, so there is definitely room for there to be errors, even if all the current software work correctly.

olaf Joined: 14 Oct 2006 Posts: 256 Location: NYC	Posted: Wed Jun 24, 2009 4:15 pm
olaf Joined: 14 Oct 2006 Posts: 256 Location: NYC	I know it's a work-in-progress and I'm sorry ahead of time if my comments seem rude. The 3D box thing is pretty nifty, I liken it to wandering around Toys'R'Us in the 90s looking at the game flap things (you saw the covers on the wall and flipped it up to see the back cover). It's pretty nostalgic and a nice novelty. However, I don't really understand the non-full screen TV thing you've got going on. Personally, I don't see a real use for it, and if you're going to have that in an emulator with 3D boxes you may as well make the a 3D model of an actual TV (yeah, I know, it's a work-in-progress). The interface art you may want to "hire" someone on to do -- we programmers don't make very pretty non-native GUIs. All that rant aside, I like your emulator -- I just thought I'd share my opinion as a fellow emulation fan/emulator maintainer. P.S. You said it will use a new detection in its file format for game specific settings. I suppose you should make it know PAL/NTSC, FM, controller, 3D, etc. (I assume you planned on that but in the video you had to tick FM for Alex Kidd).

PoorAussie Joined: 26 Aug 2008 Posts: 292 Location: Australia	Posted: Wed Jun 24, 2009 4:40 pm
	olaf wrote However, I don't really understand the non-full screen TV thing you've got going on. Personally, I don't see a real use for it, and if you're going to have that in an emulator with 3D boxes you may as well make the a 3D model of an actual TV (yeah, I know, it's a work-in-progress). Well there will be an option so you can start in fullscreen mode. The plan is to have save states showing, and other little things in the TV mode that you can select. It's also to add to the classic feel. I replayed some games simply because they were a bit harder with it on an angle (like a real TV perhaps) and it's kind of mesmerizing playing it on the "emulated TV" for some reason. Due to specific features I will be adding in the future, the "TV mode" is there to stay though. It could look better though, and if it was a 3D model, then it would likely be a lot better too like you say. :) olaf wrote The interface art you may want to "hire" someone on to do -- we programmers don't make very pretty non-native GUIs. Yes it is true we do not! Takes so many hours to get what I have in there though, so there is a certain amount of "sweat" to make it look even as "good" as it does right now. A real artist would do it with ease. olaf wrote P.S. You said it will use a new detection in its file format for game specific settings. I suppose you should make it know PAL/NTSC, FM, controller, 3D, etc. (I assume you planned on that but in the video you had to tick FM for Alex Kidd). FM is shown disabled unless the game supports it (the file format tells you _everything_ about a game). Games with settings that are "important" will get them set by default in my emulator, FM chip to most people outside Japan is "different" and shouldn't be the default in my opinion. Something like 3D glasses is enabled by default since the game is unplayable otherwise (though I plan support NVIDIA stereo glasses when possible). The controllers and things of this nature are all controlled from the header of the ROM, basically freeing up future homebrew developers to use whatever input devices they want without needing emulators to write patches specific for them. Even games with multiple controllers (like hangon/safari hunt) are handled fine, users are given the option to select out of joypad or phaser in the interface before starting, similar to plugging in either joypad or phaser on the real console. The format is mostly designed to allow games to tell the emulator how they work and the default settings that will work the best. If authors want to target only the SMS2VDP, then they can. The compression and error detection are the other important reasons. Without this format it makes it a lot harder to do what should be done in emulators going forward. It also cuts back on people needing help with an emulator because problems are easier to pinpoint.

mk1995 Joined: 11 Jan 2009 Posts: 116 Location: Germany	Posted: Thu Jun 25, 2009 5:33 pm
mk1995 Joined: 11 Jan 2009 Posts: 116 Location: Germany	This emulator sure looks exciting! Will it be able to run on Windows 2000? And how's the progress going?

PoorAussie Joined: 26 Aug 2008 Posts: 292 Location: Australia	Posted: Fri Jun 26, 2009 1:58 am
	I have updated the first post with a new WIP video for anyone who is interested. mk1995 wrote This emulator sure looks exciting! Will it be able to run on Windows 2000? And how's the progress going? Yes it should work on Windows 2000, there are very few dependencies in the project so it could work on a variety of systems (even DOS). Though the more systems you add, the more support you have to do with them all. The Windows 2000 "branch" will be the same as the Windows XP/Vista/7 32bit ones so it should be fine. Progress is good, but I still have to make a website and finish a few more polishing type things on the project.

mk1995 Joined: 11 Jan 2009 Posts: 116 Location: Germany	Posted: Sat Jun 27, 2009 11:50 am
mk1995 Joined: 11 Jan 2009 Posts: 116 Location: Germany	PoorAussie wrote Progress is good, but I still have to make a website and finish a few more polishing type things on the project. So you wanna say that the emulator is pretty much done now?

PoorAussie Joined: 26 Aug 2008 Posts: 292 Location: Australia	Posted: Sat Jun 27, 2009 2:54 pm
	mk1995 wrote So you wanna say that the emulator is pretty much done now? The core emulation is pretty much done. A few peripherals, NES mappers, things like this still need to be done. The polish I talk about is things like configurations of input, video, etc, saving the settings, etc. I'm working on the website at the moment so once that is done to a decent level I will be only a week or so off releasing something. The website needs to be done first so I can deliver the program and tools needed for it and to give a central access point for testing.

mk1995 Joined: 11 Jan 2009 Posts: 116 Location: Germany	Posted: Sat Jun 27, 2009 5:07 pm
mk1995 Joined: 11 Jan 2009 Posts: 116 Location: Germany	"NES mappers"? Has that anything to do with Ni******?

PoorAussie Joined: 26 Aug 2008 Posts: 292 Location: Australia	Posted: Sat Jun 27, 2009 5:24 pm
	mk1995 wrote "NES mappers"? Has that anything to do with Ni******? Yes, take a look at the WIP2 video right at the end there. ;)

panzeroceania Joined: 28 Jun 2009 Posts: 17 Location: Salem, OR	Posted: Sun Jun 28, 2009 8:27 pm
	If you are going to include savestates in this emulator, my brother suggested creating savestates in the locations of the pictures on the back of the box so you could click on it and go to that location. What do you guys think? also are there going to be any instruction manuals included in the future? I know that would take a TON of time, heck I don't know how you did all those boxes but yeah, being able to click on the box and it open and the manual pop out would be great, maybe even have a render of the cart. I know that's a bit extreme but just throwing ideas out there.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14735 Location: London	Posted: Sun Jun 28, 2009 9:56 pm
	panzeroceania wrote heck I don't know how you did all those boxes http://www.smspower.org/scans/

Tom Joined: 16 May 2002 Posts: 1356 Location: italy	Posted: Sun Jun 28, 2009 9:57 pm
Tom Joined: 16 May 2002 Posts: 1356 Location: italy	I have to say 3 things. 1) The interface and the features look definitely kickass, nice work 2) I think you should [provide an option to] hide the mouse cursor while playing a game 3) I'm still against the fact you created a new rom format :(

PoorAussie Joined: 26 Aug 2008 Posts: 292 Location: Australia	Posted: Mon Jun 29, 2009 1:09 am
	panzeroceania wrote If you are going to include savestates in this emulator, my brother suggested creating savestates in the locations of the pictures on the back of the box so you could click on it and go to that location. What do you guys think? also are there going to be any instruction manuals included in the future? I know that would take a TON of time, heck I don't know how you did all those boxes but yeah, being able to click on the box and it open and the manual pop out would be great, maybe even have a render of the cart. I know that's a bit extreme but just throwing ideas out there. Some nice ideas. In regards to the box scans, it is only thanks to the great work people have done scanning them, and then people like Maxim/Bock who put them up for others to use/look at. The Ni****do "emulation scene" is like a mere shadow compared to the work people put into the Master System (and GameGear I guess). It makes you really appreciative of the work people have done on the SMS side. One could contrast the fact that SMS did well in europe/australia whilst the NES did well mostly in the USA/Japan, different cultures. ;) There are lots of things like manuals that would be relatively easy to include but we will have to see. Maybe people will get together and start scanning them if they can see their results in an emulator I'm not sure. It is one reason why I am not going to be writing some emulator specific format for these things and just keep them in jpeg or other standard formats (using XML to link them) so others can use them like I have. Even if people only get the motivation to do such things because they can see it an emulator if other people want the stuff (like SMSPower) they should be able to use it imo.

panzeroceania Joined: 28 Jun 2009 Posts: 17 Location: Salem, OR	Posted: Mon Jun 29, 2009 1:34 am
	good deal sir. yeah if you have savestates, linking from the images on the back of the box would be a great flashy touch to an already amazing idea. As an american that grew up in the south pacific I appreciate all that aussies have done for emulation, video game preservation, and computers in general (see PuppyLinux) so more power to you :D my brother was a diehard genesis and saturn owner, and also big into preservation stuff like the box art so he's going to LOVE this.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14735 Location: London	Posted: Mon Jun 29, 2009 9:58 am
	Replacing the screenshots will be hard because they're in a different place on every box - and some boxes don't have any. Better might be to show the savestates in the background of the "TV mode", perhaps just as a grid (which could scale to many saves; I know I'd want at least 4 or 5 sometimes). It might be nice to have a history timeline for the rewind feature, by showing a bunch of screenshots horizontally. How much history are you keeping? It's sad that I probably can't be bothered to convert/package my games just to try this emulator, when there's no compelling reason to switch. (It took me a long time to switch to Meka's crazy interface, only because Massage was so inaccurate/out of date.)

AamirM Joined: 03 Mar 2008 Posts: 25	Posted: Mon Jun 29, 2009 10:45 am
AamirM Joined: 03 Mar 2008 Posts: 25	Nice, keep up the good work! ;) If there is one thing I'd ask, it would be the support for the normal ROM format alongside your format. Even if it meant for some features to be disabled. So, can you please add that support? Or at least make special build just for those of us who want it? (and maybe even distribute it by PM/email or something) =P Good luck!

PoorAussie Joined: 26 Aug 2008 Posts: 292 Location: Australia	Posted: Mon Jun 29, 2009 11:17 am
	AamirM wrote Nice, keep up the good work! ;) If there is one thing I'd ask, it would be the support for the normal ROM format alongside your format. Even if it meant for some features to be disabled. So, can you please add that support? Or at least make special build just for those of us who want it? (and maybe even distribute it by PM/email or something) =P Thanks for your support. I'm not going to be supporting the old format though, the interface relies upon information in the new format to work and I don't want to mess the code up with separate paths for such things. I have a different philosophy than some I guess, where I don't mind getting rid of the past if there is a better way (imo) to do things even if that means less people like what I do. As Maxim has shown, some people just don't see any compelling reason to use my emulator and they have no problems using existing ones with the old format. The tool for conversion only takes a single click and a minute of time to process every SMS game down to 60MB. I know however that anything at all is too much for some, so I'm sorry about that! There are many great emulators for SMS like MEKA, Kega and Regen that support the old format so I'm sure everyone can be happy. BTW I'm looking forward to your cycle accurate SMS emulator in your future versions!

Peder Johnsen Joined: 14 Jan 2006 Posts: 84 Location: UK	Posted: Mon Jun 29, 2009 11:34 am
Peder Johnsen Joined: 14 Jan 2006 Posts: 84 Location: UK	I was just wondering, WHY cant you use .sms?? I mean, all that extra info, cant you just have that stored within the emulator itself?

PoorAussie Joined: 26 Aug 2008 Posts: 292 Location: Australia	Posted: Mon Jun 29, 2009 11:53 am
	Peder Johnsen wrote I was just wondering, WHY cant you use .sms?? I mean, all that extra info, cant you just have that stored within the emulator itself? Yes I could store it in the emulator, but I would still need to do something like checksum the file (ie read the entire file and checksum it) to then load certain things for that file. If you don't have a dynamic interface then it's not such a problem doing this as it only happens when you load the game to play it, the SMS also doesn't have large ROMs which makes this a lesser concern, but it is an issue for other systems and future larger games. It can be a noticeable delay, even with a 512-1024kb file and a few clicks, as I had this setup previously. I just have no desire to use the old format and store information like that in my emulator or config files. If no one ever breaks the cycle then we will never go forward. On the real system the cartridge "tells" the system more than a .SMS file does. Emulator authors for the SMS have been forced into very generic programs due to being unable to test "weird" programs in emulators and not wanting them unplayable. The new format allows authors to put similar information into the file as they would in a real cartridge (and instruction booklet) so they work like they should. Whilst I call it "my format" in here, I don't really see it as "my" format and I haven't branded it for personal glory or anything of this nature. It's a system generic ROM format. I really wish someone had already done this as it is a complete PITA for me, but the global economic crisis has given me time to do things I otherwise wouldn't..... ;)

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14735 Location: London	Posted: Mon Jun 29, 2009 1:02 pm
	You can read the CRC32 from the Zip structure incredibly quickly. The same applies to RAR and (probably) 7z. Worst case, you can have the metadata indexed by filename (and check the checksum on load).

PoorAussie Joined: 26 Aug 2008 Posts: 292 Location: Australia	Posted: Mon Jun 29, 2009 1:50 pm
	Maxim wrote You can read the CRC32 from the Zip structure incredibly quickly. The same applies to RAR and (probably) 7z. You can't rely on roms being zipped though in the "old model" can you. :) So I can either add support for RAR, ZIP, 7Z, ACE, ARJ and whatever else people demand due to there being no standard or I can do what I've done. Plus CRC32 is so 1990s. ;) Maxim wrote Worst case, you can have the metadata indexed by filename (and check the checksum on load). So I have to force users to a certain rom naming scheme? ie I have to make them run a converter to the "right" filenames. ;) Why not make them run a converter to a new format while I'm at it? There are no real solutions in the old model unfortunately, only hacks and half solutions. I'm not really sure why anyone defends the old format, I mean change is something that takes work but sometimes it has un upside, and I have done most of the work for whoever is interested. Plus it is not like anyone is forcing you to use my emulator or the new format. If your philosophy is you only like the .SMS format and nothing else then there are plenty of good emulators to use with it, even ones in development like MEKA, Kega and Regen. Personally I cannot see why having 2 sets of your roms in the worst case is that big of a deal to some people, especially when it is only 60MB extra. My emulator also forces you to put ROMs in a specific folder, another design decision some people may not like. Until people have used the emulator though and understood why I did the things I did they may not see the whole picture. I'm going to have to put a fancy credit window in the emulator now to get you to use it I think.... bribes still work right? ;)

Bock Site Admin Joined: 08 Jul 2001 Posts: 8649 Location: Paris, France	Posted: Mon Jun 29, 2009 2:24 pm
	PoorAussie wrote So I have to force users to a certain rom naming scheme? You can scan once and cache local information.? I can see so many cons of doing that, some have been enumerated already (the worse being the nature of the information you are storing which are bounds to keep changing in the following years) but the point is that you can have all those improvement for your emulator without the hassle of a new format. And you'll have to provide those scans/meta infos in some way, you are not going to distribute ROM ? Meaning that you already need to do package them as separate data somehow. And your transformation tool probably use a checksum database to associate this data to the .sms files? It is difficult to take seriously that you have problem finding a creative solution to checksumming when you've done such a brilliant work with the emulator. I agree with moving forward but that sounds like stubornly breaking interopability. Looks like you're not going to change your mind so soon anyway, let's see what happens. Btw I haven't replied on this thread before but the emulator looks good. Again it is losing a lot of appeal for not being open-source in 2009, but I'm hoping it might happen eventually. I think there should be more pride today as a programmer to lead and succesfully maintain an open-source project with contributors that an isolated effort. This is so 1990s :)

Bock Site Admin Joined: 08 Jul 2001 Posts: 8649 Location: Paris, France	Posted: Mon Jun 29, 2009 2:31 pm
	PoorAussie wrote On the real system the cartridge "tells" the system more than a .SMS file does. Well not much more. Nothing about inputs, which system it is supposed to run, game title, etc. I'm not teaching you anything. It would be much more sensible to setup an external format exported from a DB that could be globally maintained and even updated automatically for users. My 2 yens.

PoorAussie Joined: 26 Aug 2008 Posts: 292 Location: Australia	Posted: Mon Jun 29, 2009 3:03 pm
	Bock wrote PoorAussie wrote On the real system the cartridge "tells" the system more than a .SMS file does. Well not much more. Nothing about inputs, which system it is supposed to run, game title, etc. I'm not teaching you anything. It would be much more sensible to setup an external format exported from a DB that could be globally maintained and even updated automatically for users. My 2 yens. The best person to design a header for a ROM is the author though, which is what my tool allows. Author sets the header once (uses lightgun port 2, joypad port 1, has a RAM mapper, etc) and then can distribute their game and have it work in emulators which support the format. There is no middle man here, no bureaucracy to get his game settings incorrect or a wait period. Having a database means someone has to react to this ROM and then add it for others to be able to use it. What is the point of doing it this way? Either way you have to change emulators to be able to support the new global database. And then you are still stuck with other issues, uncompressed roms, numerous compression schemes to support, no quick checksumming features, untimely database updates. The future in my vision is the following :- 1) A single modern compression library to support. Reducing emulator complexity, bloat and easing portability. 2) A header that tells the emulator the best settings for the game 3) Allowing quick checks for modern checksums and proper error detection. A global database only offers one of those things. My tool already has a database with settings for many game. But the tool also allows you to create your own databases (which I ran on .SMS files after smschecker for my database)., and then to go around and edit the headers as you please. Fixing/changing headers is easy too if mistakes are made. Users are going to be stuck using tools like SMSchecker or my database tool to verify their games pretty much forever, so if mistakes are made or tweaks needed in the header they aren't a big deal (though hopefully the current library will have no issues). Game settings such as input/3d glasses are things that are known about the game, whether through the back of the box or the instruction manual. If they are needed to play the game a person who owns the real thing knows this, so it's implied knowledge that should be in the header. So whilst not in the "cartridge" per se, it's in the "game packaging".

PoorAussie Joined: 26 Aug 2008 Posts: 292 Location: Australia	Posted: Mon Jun 29, 2009 3:27 pm
	Bock wrote Btw I haven't replied on this thread before but the emulator looks good. Again it is losing a lot of appeal for not being open-source in 2009, but I'm hoping it might happen eventually. I think there should be more pride today as a programmer to lead and succesfully maintain an open-source project with contributors that an isolated effort. This is so 1990s :) The programmers who can contribute anything but minor things to my emulator though would be few and far between, at least those with the TIME to do such things. The only reason someone like myself who has high competency in coding has been able to pour time into this is unemployment and not wanting to work at the moment. If I wasn't so obsessed with doing this I would be off making my 180+K/year doing what I usually do. Only someone with a silly obsession would abandon making that much money for 18 months and put it into a massive project like I have been working on... silly, obsessed and now poor. ;) That said if I ever see the end in sight I will open source it, like you did with MEKA. There just is no point right now doing such things..... so we will wait and see. Talk is cheap and I need to deliver something.

Bock Site Admin Joined: 08 Jul 2001 Posts: 8649 Location: Paris, France	Posted: Mon Jun 29, 2009 3:47 pm
	MEKA basically failed its open source conversion because it came too late and was too much the result of me working in an igloo for the past years. (added to the general factor that techniques and knowledge have evolved a lot since interned boomed). We agree that very few people might contribute, but you don't need many people. eg: I already offered to help and you know I am rather obsessed with this. Arguably I might be lacking skills on some areas but probably could contribute decent debugging tools for example. Open-source doesn't mean you must hand over source control write access to everyone. There are other people here and elsewhere on the internet would can bring good things. PS: No need to brag about salary, I found a decent balance at getting underpaid - relatively speaking to other IT industry - to do my hobby :)

olaf Joined: 14 Oct 2006 Posts: 256 Location: NYC	Posted: Mon Jun 29, 2009 3:55 pm
olaf Joined: 14 Oct 2006 Posts: 256 Location: NYC	Wait... it's not open source?

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14735 Location: London	Posted: Mon Jun 29, 2009 3:58 pm
	PoorAussie wrote You can't rely on roms being zipped though in the "old model" can you. :) So I can either add support for RAR, ZIP, 7Z, ACE, ARJ and whatever else people demand due to there being no standard or I can do what I've done. Plus CRC32 is so 1990s. ;) CRC32 is about 60 bytes too small for the collision probability you might want. The current standard (for SMS) is (1) uncompressed or (2) zipped, one per zip. Hardly any emulators support anything else. PoorAussie wrote Maxim wrote Worst case, you can have the metadata indexed by filename (and check the checksum on load). So I have to force users to a certain rom naming scheme? No: have a map of filename to metadata index. Also have an option to populate the current dir's metadata, like Meka does, rather than wait for the user to prime the cache by loading all the files. You check the checksum on file load in case the user overwrote the file. PoorAussie wrote Personally I cannot see why having 2 sets of your roms in the worst case is that big of a deal to some people, especially when it is only 60MB extra. My emulator also forces you to put ROMs in a specific folder, another design decision some people may not like. Until people have used the emulator though and understood why I did the things I did they may not see the whole picture. I can see you're going for "it just works" - if legality weren't an issue, you could just bundle all the ROMs in the app installer. (If the emulator's any good, there'll soon be copies on file sharing sites and burned CDs on eBay which do just that.) The problem I see is how you will manage to update the metadata in old .game files. The central DB approach is the only real solution to that. PoorAussie wrote I'm going to have to put a fancy credit window in the emulator now to get you to use it I think.... bribes still work right? ;) I may still check it out if I find the time. Why not bundle the converter in with the app? How well does it run on an 800MHz machine with crappy integrated graphics, at 1024x600 maximum resolution?

Bock Site Admin Joined: 08 Jul 2001 Posts: 8649 Location: Paris, France	Posted: Mon Jun 29, 2009 4:07 pm
	Btw reminds me that the original idea of Meka - that never was - was based on a realtime 3d interface where you would manipulate cartridges (1998 with fancy perspective correction). And then a bit later Mekadrive (mockup courtesy of Marbleman) an idea that was floating in the air at some point with Charles (Charles already worked quite extensively on MD at some point as I recall). I don't remember if those were published already? meka3d.png (21.39 KB) mekadrive.jpg (121.34 KB)

PoorAussie Joined: 26 Aug 2008 Posts: 292 Location: Australia	Posted: Mon Jun 29, 2009 4:16 pm
	Maxim wrote No: have a map of filename to metadata index. Also have an option to populate the current dir's metadata, like Meka does, rather than wait for the user to prime the cache by loading all the files. You check the checksum on file load in case the user overwrote the file. There are certainly ways to "hack" it in, but it's just too much work really. I don't want to have to track files and caches to make sure it's dirty or correct. It adds complexity to something which shouldn't have it imo. A more reasoned developer may care about losing .SMS compatibility and decide it's worth it, but yeah. Maxim wrote I can see you're going for "it just works" - if legality weren't an issue, you could just bundle all the ROMs in the app installer. (If the emulator's any good, there'll soon be copies on file sharing sites and burned CDs on eBay which do just that.) The problem I see is how you will manage to update the metadata in old .game files. The central DB approach is the only real solution to that. Yes you can see what I am going for, ease of use pretty much. You could hotpatch .game files quite easily. My emulator doesn't support non writeable media for it's ROM folders but other emulators could support such a thing if they want. Every SMS game will be tested though before I release the database fully to the public, so in theory there will be no mistakes (famous last words). Maxim wrote I may still check it out if I find the time. Why not bundle the converter in with the app? How well does it run on an 800MHz machine with crappy integrated graphics, at 1024x600 maximum resolution? It will run quite horribly on that unfortunately. Minimum resolution is also 1024x768 (4:3) or 1280x720 (widescreen). Graphics card isn't that big a deal, it's only my custom GUI which really NEEDS onboard VRAM (texture blitting is much faster). On a 6 year old laptop I have with a really crappy onboard gfx (sysram) I only get 6fps at 1280x720 in my "complex areas" of the GUI and fullspeed during gameplay. This is an athlon-m 1.8GHz. It's pretty much my "min requirement" test. I decided for various reasons to force things like high quality audio filters and full 32bit alpha blended GUI on people, which isn't so intensive compared to the cycle accuracy cost but it all adds up. It's really an emulator geared towards modern computers in nearly every way. We might have to start a donation fund for you to get you a better computer I think, you've done a lot of work afterall. :)

PoorAussie Joined: 26 Aug 2008 Posts: 292 Location: Australia	Posted: Mon Jun 29, 2009 4:21 pm
	Bock wrote Btw reminds me that the original idea of Meka - that never was - was based on a realtime 3d interface where you would manipulate cartridges (1998 with fancy perspective correction). And then a bit later Mekadrive (mockup courtesy of Marbleman) an idea that was floating in the air at some point with Charles (Charles already worked quite extensively on MD at some point as I recall). I don't remember if those were published already? Wow looks nice, especially for the time! What happened to this? :)

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14735 Location: London	Posted: Mon Jun 29, 2009 5:19 pm
	PoorAussie wrote It will run quite horribly on that unfortunately. Well, I have a decent Core 2 Duo machine sitting unused for lack of space, so I'm mostly using a netbook these days. It's adequate for most tasks, just not for anything expecting to run through a GPU. (My coding competition entry was done on it, for example; it runs Meka at 60fps at 800MHz on battery power.)

Tom Joined: 16 May 2002 Posts: 1356 Location: italy	Posted: Mon Jun 29, 2009 7:15 pm
Tom Joined: 16 May 2002 Posts: 1356 Location: italy	By the way, will this support GG eventually? Will you display a 3D animation of the GG? :)

AamirM Joined: 03 Mar 2008 Posts: 25	Posted: Mon Jun 29, 2009 7:27 pm
AamirM Joined: 03 Mar 2008 Posts: 25	Quote BTW I'm looking forward to your cycle accurate SMS emulator in your future versions! Haha, I never said cycle accurate "SMS" emulator but rather cycle accurate Z80 emulator :P. I am getting more interested in implementing SMS on an FPGA now. Anyways, if it converts in just only one click, I'll try it. No more no less. :D

panzeroceania Joined: 28 Jun 2009 Posts: 17 Location: Salem, OR	Posted: Mon Jun 29, 2009 11:32 pm
	while it may be a big hassle for many, there are also lots of people who don't mind trying a new format so long as it does have real benefits. Looking forward to the release :D

PoorAussie Joined: 26 Aug 2008 Posts: 292 Location: Australia	Posted: Tue Jun 30, 2009 1:54 am
	Tom wrote By the way, will this support GG eventually? Will you display a 3D animation of the GG? :) Yeah GG support is already in there I just haven't enabled it fully yet, I have tested it though (it's basically a NTSC VDP2 which I already support at the cycle level) and it works nicely. It's actually a nice help for SMS emulation since some GG games are timing sensitive. I just didn't want to bite off too much for the first release, and I want to implement full GG emulation including the networking link (one reason dual+ core is nice since you need two GG emulators running in parallel) so I've put it slightly on the back burner until what I have is working nicely.

FluBBa Joined: 21 Jul 2005 Posts: 412 Location: GBG	Posted: Tue Jun 30, 2009 11:44 am
FluBBa Joined: 21 Jul 2005 Posts: 412 Location: GBG	PoorAussie wrote The best person to design a header for a ROM is the author though, which is what my tool allows. Author sets the header once (uses lightgun port 2, joypad port 1, has a RAM mapper, etc) and then can distribute their game and have it work in emulators which support the format. There is no middle man here, no bureaucracy to get his game settings incorrect or a wait period. Are we talking about ROM releases of old commercial Sega games or what? You only need one Sega mapper for all commercial games, though that might go against the philosophy of the emulators goal. What about new homebrew that makes use of the mapper in the ToToTek cart (as an example) or some new unknown Korean games, you would still have to update your converter and you emulator to support those games. The other part is what hardware to run the game on, but that is up to the user right? I can put my cartridge in a SMS1 or a SMS2, that is what can happen in real life but not in your emulator, or? And why force a new format when you could have made it compatible with every other SMS emulator by using PK zip format and just include an extra header file in the zip? Then I might actually consider supporting it on my SMS emulator for the DS. I really like your emulator so far, just hate the rom file format.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14735 Location: London	Posted: Tue Jun 30, 2009 12:21 pm
	Metadata packed in a zip file seems to be the way a lot of things are going when they have a bundle of data to include - for example, Java JARs, Google Earth KMZ files, Winamp WSZ (skins), Office 2007 DOCX/XLSX/etc. (On the other hand, many also do it because they have XML inside and they want to offset the bloat.) So I wouldn't be too surprised if .game was a standard archive format underneath. Regarding cover scans, I suppose you can consider a ROM dump, metadata, cover/manual scan etc as analogous to taking a CD and its cover/inserts/etc and producing an MP3/FLAC/whatever with embedded metadata, covers, etc - it's in no way authoritative, different people will always come up with slightly different results, even if they are broadly the same. The only difference is that ripping CDs is a lot easier.

Eke Joined: 06 Feb 2009 Posts: 110 Location: Toulouse, France	Posted: Tue Jun 30, 2009 1:18 pm
	I second the general opinion about a new ROM format, seems to me as a "control freak" feature (no offense) and a waste of time as it is more easily handled by an internal database (especially when this new ROM format is probably going to be only supported by this emulator) or by a customizable "cartridge emulator" (rom size, mapper type, etc... supported inputs being also configurable, there is no reason you could not try to plug a light phaser while playing alex kidd, even if it was not designed for ;-) ) I think it will also brings lots of confusion among current ROM sets, adding ROM file versions when it's not required. I don't know, maybe you could add these informations as a trailer so the ROM header remains intact and the file compatible with other emulators ? Otherwise, this seems very promising (but you already know it), especially if the accuracy level is as claimed. I also hope that even if ou choose the closed-source way, you will release detailled informations about cycle accurate VDP as it would benefit to a lot of similar projects :-)

Forums

View topic - New SMS emulator: RetroCopy