openemu problem?..

[Running man]

Guys, I would greatly appreciate if someone could help me run Intellivision roms on Openemu...

Just updated to their latest version but when I drag any Intv game rom to Openemu, it pops a window that tells me I need a "exec.bin" and "grom.bin" files to play them!?...

please help!

 

[mr_me]

Exec.bin is the copyrighted software embedded in every Intellivision. Grom.bin is mostly the character graphics library embedded in every Intellivision. Most Intellivision games won't work without them. Some Intellivision games will work with free versions called miniexec.bin and minigrom.bin.

 

See this for more information.

https://www.google.ca/search?q=exec.bin+grom.bin&gws_rd=cr&ei=A53FWLrYJom6jwTQvLXAAg

 

Was it working before you updated?

.

Edited March 12, 2017 by mr_me

[+SpiceWare]

It tells you more than that:

 

It tells you what those files are, and what you need to do with them once you get them.

 

Basically, besides the ROM from inside the game cartridge you also need the ROM(s) from inside the console. Typically these ROMs will contain the BIOS(standard routines for reading controllers, showing things on screen,etc), default character graphics, and so on. So search for Intellivision Executive BIOS and Intellivision Graphics ROM (most likely to be found where you acquired your game ROMs) then drag & drop them onto OpenEmu's Intellivision page(ie: click on Intellivision in the list on the left, then drag those ROMs into the area on the right were you see the games). After that the games will run OK.

 

In the menu OpenEmu->Preferences is a System Files tab that will tell you what's installed, missing, or incorrect for the various consoles that are supported:

 

Do note the filenames themselves don't have to be an exact match. OpenEmu will use a checksum md5 Hash to determine what the file is. The two I just found are called this:

• Executive ROM, The (1978) (Mattel).int
• GROM, The (1978) (General Instruments).7z

The GROM's in a file compressed using 7z. Don't worry about that as OpenEmu will automatically uncompress and rename files as it imports them:

[Jetboot Jack]

Just to add to this - there is no emulator that makes this more simple than OpenEmu - especially as Intellivision emulation is pretty dreadful on all other platforms, I've been trying to get good coverage under Launchbox front end on Windows and it REALLY not fun :-(

 

SpiceWare's exhaustive guide is 100% accurate, but just for completeness this is the official information:

 

https://github.com/OpenEmu/OpenEmu/wiki/User-guide:-BIOS-files

 

sTeVE

[+SpiceWare]

https://github.com/OpenEmu/OpenEmu/wiki/User-guide:-BIOS-files

Interesting, that says the filename needs to be correct. They must have changed that requirement at some point and forgot to update the page.

[mr_me]

Just to add to this - there is no emulator that makes this more simple than OpenEmu - especially as Intellivision emulation is pretty dreadful on all other platforms, I've been trying to get good coverage under Launchbox front end on Windows and it REALLY not fun :-(

 

SpiceWare's exhaustive guide is 100% accurate, but just for completeness this is the official information:

 

https://github.com/OpenEmu/OpenEmu/wiki/User-guide:-BIOS-files

 

sTeVE

JzIntv is perfect for Launchbox. There are some Launchbox specific notes here. https://www.reddit.com/r/intellivision/comments/4etfy4/howto_use_jzintv_emulator_the_easy_way/

[Jetboot Jack]

I have tied JzIntv, Boss and Nostalgia under windows I find all ahem problems that make them problematic

 

I see poor image quality with JzIntv - perhaps I am not configuring it correctly, but it always appears slightly smooth scaled whatever resolution I set, which I dislike...

 

Also with JzIntv the non Intellivision carts require individual ???.cfg files to set the memory mapping correctly which is a bit of a pain too - makes it fiddly.

 

I have great picture quality and no need to setup the mapping files with OpenEmu - it just works...

 

However I need it under windows so I will have another go with JzIntv mr_me!

 

sTeVE

[mr_me]

All Intellivision emulators have to be told each game's memory map. Some like Bliss, Nostalgia, and MAME have a database of game memory maps. But for newer games it would have to support .cfg files or memory map embedded .rom files otherwise you'd have to manually update the database. Jzintv defaults to the Mattel standard memory map if no memory map is given. All Intellivision games should come with a memory map .cfg file or an embedded .rom file. Not sure about your jzintv smooth scaling issue unless you are using the --prescale switch. Openemu's Intellivision emulator core is Bliss. You can also get Bliss for Windows, but jzIntv and maybe MAME are the only emulators that I know are actively maintained by the programmers.

 

One issue with jzintv is that the border is too thin. But when I looked at Bliss it has no border at all. MAME has a decent Intellivision border.

Edited March 14, 2017 by mr_me

[Inky]

The biggest problem with jzintv is configuring the controllers. I'm trying to get a Colecovision controller, via Vision-dapter running on it, and it's just a pain to set up. It runs fine with a keyboard, and to these eyes, it looks and sounds correct, so I'm going to keep plugging away at trying to get the controller working.

[mr_me]

Edit:

The joystick and first three buttons should work automatically without any button mapping file.

------------------------------------------

 

It's a straightforward button mapping file. Once you know the visiondaptor button numbers in your computer you just put them in a file. The only limitation is it automatically uses the first four game controllers so the fifth cant be used. The column on the left is the system button number starting with zero. JS0 is the first system controller, JS3 is the fourth. PD0L is the Intellivision left controller, PD0R is the right. Joystick/disc mapping (and first three buttons) are automatic but can be reassigned.

 

MAP 0 ; default map F5

ESCAPE QUIT

; first joystick defaults to left controller

JS0_BTN_00 PD0L_A_T

JS0_BTN_01 PD0L_A_L

JS0_BTN_02 PD0L_A_R

JS0_BTN_08 PD0L_KP1

JS0_BTN_09 PD0L_KP2

JS0_BTN_10 PD0L_KP3

JS0_BTN_11 PD0L_KP4

JS0_BTN_12 PD0L_KP5

JS0_BTN_13 PD0L_KP6

JS0_BTN_14 PD0L_KP7

JS0_BTN_15 PD0L_KP8

JS0_BTN_16 PD0L_KP9

JS0_BTN_17 PD0L_KPC

JS0_BTN_18 PD0L_KP0

JS0_BTN_19 PD0L_KPE

Edited March 14, 2017 by mr_me

[+SpiceWare]

All Intellivision emulators have to be told each game's memory map.

Thats how Stella used to be - every game needed a *.vcs file.

 

I maintained the OS/2 port back then and we were discussing how to do away with the VCS files. I suggested using a checksum to identify games, and implemented a test build. Results were good, the original games generated unique IDs, though sometimes hacks were identified as the original game. Brad changed my routine to use MD5 instead - a better solution, though I wasn't familiar with it at the time.

 

After that the data that used to be in the *.vcs files was moved into an internal database, the current version of which can be seen here.

 

Over time detection routines were implemented/improved so many things like bankswitch type and TV format could be figured out automatically, so the database now mostly contains things like the name and manufacturer of the game, non-joystick controllers, or games that fail the auto-detect routines. If you search the database you'll see Warlords specifies Paddle controllers, one variation of Dig Dug specifies a bankswitch type of F6SC, etc.

[Jetboot Jack]

All Intellivision emulators have to be told each game's memory map. Some like Bliss, Nostalgia, and MAME have a database of game memory maps. But for newer games it would have to support .cfg files or memory map embedded .rom files otherwise you'd have to manually update the database. Jzintv defaults to the Mattel standard memory map if no memory map is given. All Intellivision games should come with a memory map .cfg file or an embedded .rom file. Not sure about your jzintv smooth scaling issue unless you are using the --prescale switch. Openemu's Intellivision emulator core is Bliss. You can also get Bliss for Windows, but jzIntv and maybe MAME are the only emulators that I know are actively maintained by the programmers.

 

One issue with jzintv is that the border is too thin. But when I looked at Bliss it has no border at all. MAME has a decent Intellivision border.

 

 

OpenEmu does indeed use a memory map cfg file, it's just a little different than the JzIntv ones - one file called "knowncarts.cfg" which is inside the "Bliss.oecoreplugin" package - which selects memory mapping settings based not on file name:

 

C047D487:Info:Beauty and the Beast:Imagic:1982

C047D487:ROM:4800:2000:16

Which does not look like the md5 hash for the rom...

sTeVE

[mr_me]

Right that would be the database file that Bliss uses. And thats a crc32 checksum. What happens if the game is not in its database. It would have to be compatible with the .cfg file or .rom file the others use.

[Jetboot Jack]

righto - that makes sense, seems easy to extend and eliminates the separate per rom files so that makes it quite tidy.

 

I will do some windows experimentation with JzIntv this weekend to see if I can get things working better - at least try some cfg files and get those non-standard games working and try and sharpen the output if it is to replace Nostalgia in my setup

 

Is it easy to create custom keyboard mappings - I like to use Xpadder to parse joystick to keyboard from non-retroarch emulators?

 

sTeVE

[mr_me]

Jzintv can do all button mappings with its mapping file aka 'keyboard hackfile'. You can even setup a batch script so some games use a unique button mappings file. The only thing it doesn't do is make use of the right analog stick. I use something called 'JoytoKey' for windows that lets me map the right analog stick to eight buttons (good for ADD, Tron DD, Night Stalker).

Edited March 15, 2017 by mr_me

[mr_me]

righto - that makes sense, seems easy to extend and eliminates the separate per rom files so that makes it quite tidy.

 

I will do some windows experimentation with JzIntv this weekend to see if I can get things working better - at least try some cfg files and get those non-standard games working and try and sharpen the output if it is to replace Nostalgia in my setup

 

Is it easy to create custom keyboard mappings - I like to use Xpadder to parse joystick to keyboard from non-retroarch emulators?

 

sTeVE

You can use something like Xpadder or JoyToKey in windows rather than the jzintv 'keyboard hackfile'. All Intellivision controller functions are automatically mapped to the keyboard by default. However since jzintv automatically maps the first nine buttons of the system controllers you might need a 'keyboard hackfile' just to disable the automatic mappings. Third party joystick to keyboard mappers work with jzIntv windows but I don't know about Linux or Mac.

 

jzintv.txt - default keyboard mapping doc

kbdhackfile.txt - jzintv button mapping reference

zz_jzintv_help.txt - jzintv command line switches

Edited March 15, 2017 by mr_me

[Jetboot Jack]

Wow - thanks for all the information, I feel the need to give this a proper go!!

 

sTeVE

[ThomH]

Thats how Stella used to be - every game needed a *.vcs file.

 

I maintained the OS/2 port back then and we were discussing how to do away with the VCS files. I suggested using a checksum to identify games, and implemented a test build. Results were good, the original games generated unique IDs, though sometimes hacks were identified as the original game. Brad changed my routine to use MD5 instead - a better solution, though I wasn't familiar with it at the time.

 

After that the data that used to be in the *.vcs files was moved into an internal database, the current version of which can be seen here.

 

Over time detection routines were implemented/improved so many things like bankswitch type and TV format could be figured out automatically, so the database now mostly contains things like the name and manufacturer of the game, non-joystick controllers, or games that fail the auto-detect routines. If you search the database you'll see Warlords specifies Paddle controllers, one variation of Dig Dug specifies a bankswitch type of F6SC, etc.

 

By coincidence I was working on this problem in the last week or so and found that Atari bank switching schemes can be discerned automatically ahead of time through the combination of disassembly + file size. It'd be interesting to see whether the same thing works for Intellivision titles, but it sounds like quite possibly not?

[+SpiceWare]

By coincidence I was working on this problem in the last week or so and found that Atari bank switching schemes can be discerned automatically ahead of time through the combination of disassembly + file size. It'd be interesting to see whether the same thing works for Intellivision titles, but it sounds like quite possibly not?

It should be. Stella doesn't even do a disassembly for that, it just searches for key bits of info. Take a look at Cart.cxx. In create() the first thing it does is run autodetectType() which first uses the size to narrow down the types of carts it could be. It then runs a bunch of isProbably???() functions to determine the type. Those functions look like this one, which was used in a couple of Activision games:

bool Cartridge::isProbablyFE(const uInt8* image, uInt32 size)
{
  // FE bankswitching is very weird, but always seems to include a
  // 'JSR $xxxx'
  // These signatures are attributed to the MESS project
  uInt8 signature[4][5] = {
    { 0x20, 0x00, 0xD0, 0xC6, 0xC5 },  // JSR $D000; DEC $C5
    { 0x20, 0xC3, 0xF8, 0xA5, 0x82 },  // JSR $F8C3; LDA $82
    { 0xD0, 0xFB, 0x20, 0x73, 0xFE },  // BNE $FB; JSR $FE73
    { 0x20, 0x00, 0xF0, 0x84, 0xD6 }   // JSR $F000; STY $D6
  };
  for(uInt32 i = 0; i < 4; ++i)
    if(searchForBytes(image, size, signature[i], 5, 1))
      return true;

  return false;
}

---

or this one which detects Superchip carts (those with an extra 128 bytes of RAM):

bool Cartridge::isProbablySC(const uInt8* image, uInt32 size)
{
  // We assume a Superchip cart contains the same bytes for its entire
  // RAM area; obviously this test will fail if it doesn't
  // The RAM area will be the first 256 bytes of each 4K bank
  uInt32 banks = size / 4096;
  for(uInt32 i = 0; i < banks; ++i)
  {
    uInt8 first = image[i*4096];
    for(uInt32 j = 0; j < 256; ++j)
    {
      if(image[i*4096+j] != first)
        return false;
    }
  }
  return true;
}

[ThomH]

It should be. Stella doesn't even do a disassembly for that, it just searches for key bits of info. Take a look at Cart.cxx. In create() the first thing it does is run autodetectType() which first uses the size to narrow down the types of carts it could be. It then runs a bunch of isProbably???() functions to determine the type. Those functions look like this one, which was used in a couple of Activision games:

bool Cartridge::isProbablyFE(const uInt8* image, uInt32 size)
{
  // FE bankswitching is very weird, but always seems to include a
  // 'JSR $xxxx'
  // These signatures are attributed to the MESS project
  uInt8 signature[4][5] = {
    { 0x20, 0x00, 0xD0, 0xC6, 0xC5 },  // JSR $D000; DEC $C5
    { 0x20, 0xC3, 0xF8, 0xA5, 0x82 },  // JSR $F8C3; LDA $82
    { 0xD0, 0xFB, 0x20, 0x73, 0xFE },  // BNE $FB; JSR $FE73
    { 0x20, 0x00, 0xF0, 0x84, 0xD6 }   // JSR $F000; STY $D6
  };
  for(uInt32 i = 0; i < 4; ++i)
    if(searchForBytes(image, size, signature[i], 5, 1))
      return true;

  return false;
}

---

or this one which detects Superchip carts (those with an extra 128 bytes of RAM):

bool Cartridge::isProbablySC(const uInt8* image, uInt32 size)
{
  // We assume a Superchip cart contains the same bytes for its entire
  // RAM area; obviously this test will fail if it doesn't
  // The RAM area will be the first 256 bytes of each 4K bank
  uInt32 banks = size / 4096;
  for(uInt32 i = 0; i < banks; ++i)
  {
    uInt8 first = image[i*4096];
    for(uInt32 j = 0; j < 256; ++j)
    {
      if(image[i*4096+j] != first)
        return false;
    }
  }
  return true;
}

 

I've tried not to look too much at Stella, but I guess we've ended up at almost the same tests. The only difference is that I'm introducing an intermediate form into my byte signature search. And using different signatures. I guess in theory I'd avoid some potential false positives through keeping everything PC aligned, but miss some genuine positives for failure statically to spot complicated branching strategies. There's at least one title that naively disassembles to only about ten instructions because its reset program just pushes a couple of values to the stack and then performs an RTS, and my disassembler isn't that smart.

 

Quick tip on the RAM test though, as it could help you to eliminate the special case you mentioned for Dig Dug: I initially had more or less exactly that but found it failed on the Dig Dug here on Atari Age. I switched to "if the first 128 bytes are a mirror of the second". That works correctly for all ROM images here, including Dig Dug. No false positives, no false negatives. My working theory is that somebody read the cartridge without physical disassembly in ascending address order, the first 128 bytes getting whatever happened to be on the bus of whatever device they constructed, but then getting the same values reported back because the read ports come after the write ports and the write ports also captured whatever was on the bus.

 

If you considered that as a strategy but discounted it for some reason, the warning would be appreciated.

[+SpiceWare]

Quick tip on the RAM test though, as it could help you to eliminate the special case you mentioned for Dig Dug: I initially had more or less exactly that but found it failed on the Dig Dug here on Atari Age. I switched to "if the first 128 bytes are a mirror of the second". That works correctly for all ROM images here, including Dig Dug. No false positives, no false negatives. My working theory is that somebody read the cartridge without physical disassembly in ascending address order, the first 128 bytes getting whatever happened to be on the bus of whatever device they constructed, but then getting the same values reported back because the read ports come after the write ports and the write ports also captured whatever was on the bus.

 

If you considered that as a strategy but discounted it for some reason, the warning would be appreciated.

Did a quick change and that version of Dig Dug now autodetects

 

I don't know if there was a reason, I didn't write that part of it. I'll post this info in the other topic for the rest of the team.

[DirtyHairy]

 

Quick tip on the RAM test though, as it could help you to eliminate the special case you mentioned for Dig Dug: I initially had more or less exactly that but found it failed on the Dig Dug here on Atari Age. I switched to "if the first 128 bytes are a mirror of the second". That works correctly for all ROM images here, including Dig Dug. No false positives, no false negatives. My working theory is that somebody read the cartridge without physical disassembly in ascending address order, the first 128 bytes getting whatever happened to be on the bus of whatever device they constructed, but then getting the same values reported back because the read ports come after the write ports and the write ports also captured whatever was on the bus.

 

Didn't know about that, pretty interesting. To add yet another variant: 6502.ts does not try to detect the presence of SC RAM beforehand, but instead switches it on at runtime once the code tries to write it. I was a bit worried about sloppy code giving false positives when I implemented it this way, but I haven't encountered any issues since --- the constructor argument to fix the behavior is still unused

Edited March 16, 2017 by DirtyHairy

[mr_me]

 

By coincidence I was working on this problem in the last week or so and found that Atari bank switching schemes can be discerned automatically ahead of time through the combination of disassembly + file size. It'd be interesting to see whether the same thing works for Intellivision titles, but it sounds like quite possibly not?

Intellivision games aren't bank switched (World Series Baseball might be). Their ROM chips are memory mapped. That memory map is normally read from the chip and stored separately. If all you have is the ROM data you'd have to figure out a way to come up with the memory map.

[ThomH]

Intellivision games aren't bank switched (World Series Baseball might be). Their ROM chips are memory mapped. That memory map is normally read from the chip and stored separately. If all you have is the ROM data you'd have to figure out a way to come up with the memory map.

 

The quickest summary here would probably be: I don't know what I'm talking about. Naturally I have some knee-jerk responses along the lines of "if there are N possible mappings, use the fact that computers are fast to run all of them simultaneously and keep whichever looks to be doing the most probable things re: painting the screen, scanning the inputs, etc". If I were writing an Intellivision emulator, perhaps I would quickly find out why the existing examples don't do that.

 

If the problem could be solved by somebody with no prior knowledge in an off-the-cuff forum post, it would have been solved a long time ago.

[mr_me]

There aren't too many active Intellivision emulator programmers. You may have something there but it would be low on your priority list.