Jump to content
mizapf

New MAME release

Recommended Posts

14 hours ago, mizapf said:

Concerning the issues with the parallel use of IDE and HFDC, mind that the "hardN" switches have no path specification. That is, they are assigned in order of initialization of the peripheral cards. The IDE defines one hard disk connector and picks hard1; then the HFDC gets hard2, hard3, hard4 (on h1, h2, h3).

 

I would still need to put in 'hard1', 'hard2', etc?  or just 'hard' in the command and MAME will automatically pick hardN based on what has already been assigned?

 

 

Share this post


Link to post
Share on other sites

You have to use hard1, hard2, hard3 etc. (the same holds for all other media like flop1, flop2, ...). The problem is that the MAME core assigns this sequence of media to the devices that declare to be connected to this type, and there is (currently) no way to specify which device gets which one - possibly some legacy of the arcade origins of MAME.

 

The cards in the PEB are initialized in sequence of their slots. When the IDE controller is initialized, it requests a medium of type "hard disk"; you have to provide that in the command line as "-hard ..." or "-hard1 ..." (if there is only one, you can omit the 1).

 

When there is another card that requests such devices, it continues with "-hard2", "-hard3" etc. This has nothing to do with the "h1", "h2", "h3" connectors.

 

The whole thing would be cleaner if we had to provide the path, but I am quite sure that not everyone would gladly agree if you had to write "-ioport:peb:slot8:hfdc:h1 harddisk1.hd"  instead of "-hard1 harddisk1.hd".

Share this post


Link to post
Share on other sites
18 hours ago, mizapf said:

Concerning the issues with the parallel use of IDE and HFDC, mind that the "hardN" switches have no path specification. That is, they are assigned in order of initialization of the peripheral cards. The IDE defines one hard disk connector and picks hard1; then the HFDC gets hard2, hard3, hard4 (on h1, h2, h3).

Excellent.  I found where my statement was messing up.  I was actually assigning the HFDC h1,h2,h3 before the IDE in slot7.  all working now.

  • Like 2

Share this post


Link to post
Share on other sites
12 hours ago, arcadeshopper said:

The KEEP BBS Still online since 1983, http://www.thekeep.net, telnet: thekeep.net:23 modem: (503) 852-3170

Is your KEEP BBS named after the book/movie The Keep from 1983 as well or is that coincidence?

Share this post


Link to post
Share on other sites

I  thought that I would "spice" MAME up a bit by using a couple of "Insanemultitasker's' programs. My copied system is set up with the EVPC (80-column card) and a Horizon RAMdisk as DSK4-D (DSK1-3 are virtual floppy drives). SPLASH is used to display a TI-ARTIST picture at startup for eight seconds (unless cancelled by pressing the space bar) after which it displays the 80-col MENU program. The only caveat is that both must reside on the first partition of the RAMdisk. Anyway, MAME starts like this: 

Screenshot (29).png

Screenshot (30).png

  • Like 3

Share this post


Link to post
Share on other sites
13 hours ago, atrax27407 said:

I  thought that I would "spice" MAME up a bit by using a couple of "Insanemultitasker's' programs. My copied system is set up with the EVPC (80-column card) and a Horizon RAMdisk as DSK4-D (DSK1-3 are virtual floppy drives). SPLASH is used to display a TI-ARTIST picture at startup for eight seconds (unless cancelled by pressing the space bar) after which it displays the 80-col MENU program. The only caveat is that both must reside on the first partition of the RAMdisk. Anyway, MAME starts like this: 

Screenshot (29).pngScreenshot (30).png

where do I find SPLASH?

Share this post


Link to post
Share on other sites

I've tried to compile version 225, but I get an error:

In function ‘char* strcat(char*, const char*)’,
    inlined from ‘void nubus_image_device::file_cmd_w(uint32_t)’ at ../../../../../src/devices/bus/nubus/nubus_image.cpp:262:10:
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:128:33: error: ‘char* __builtin___strcat_chk(char*, const char*, long unsigned int)’ accessing 129 or more bytes at offsets 988 and 860 may overlap 1 byte at offset 988 [-Werror=restrict]
  128 |   return __builtin___strcat_chk (__dest, __src, __bos (__dest));
      |          ~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I guess I need to change that to a memcpy, but I don't know exactly where and how.

 

Have there already been official patches for this?

 

EDIT: I found where, but not how. 😅

 

EDIT²: I found the mamedev note about _FORTIY_SOURCE.

Edited by ralphb

Share this post


Link to post
Share on other sites

Maybe you can restrict the build to the TI family (using SOURCES=src/mame/drivers/ti99_4x.cpp etc. as arguments to make), so you'd bypass this position if it has not been fixed.

 

What compiler do you use? (Version?)

Share this post


Link to post
Share on other sites
3 minutes ago, mizapf said:

Maybe you can restrict the build to the TI family (using SOURCES=src/mame/drivers/ti99_4x.cpp etc. as arguments to make), so you'd bypass this position if it has not been fixed.

 

What compiler do you use? (Version?)

It's a compiler problem (according to MAME devs), and there's a workaround by allowing unsafe functions with _FORTIY_SOURCE.  I'm trying that now.

Share this post


Link to post
Share on other sites

Ah, I misspelled FORTIFY, but it worked on the second try:

cassiopeia /vol/src/mame225 > time make -j 24
...
Linking mame64...
15366.948u 980.779s 14:04.90 1934.8%    0+0k 688+9040208io 2pf+0w

I was basically burning-in my new system, and it passed the test. 😀  The -j 24 hints at the processor, and 14:04 is the elapsed time in minutes and seconds (of which 980 seconds were spent inside the kernel).

  • Like 1

Share this post


Link to post
Share on other sites

What good is a new MAME when most every game says ONE OR MORE ROMS MISSING? 

 

I added every rom folder to it, can't get one Genesis game to run or any 7800 or 2600 games!

 

All the roms work on MAME32 0.94!

Share this post


Link to post
Share on other sites

Obviously, you are missing some ROMs.

 

I can only help you for the TI family, and in that respect, we have up-to-date ROMs for the current MAME on our WHTech server.

 

Apart from that, a newer MAME is a better MAME.

  • Like 2

Share this post


Link to post
Share on other sites

Does using the evpc card, since it requires a different 'machine' in mame, mean that the non-volatile storage for a horizon ramdisk is in a different filesystem location? 

Share this post


Link to post
Share on other sites
7 minutes ago, jedimatt42 said:

Does using the evpc card, since it requires a different 'machine' in mame, mean that the non-volatile storage for a horizon ramdisk is in a different filesystem location? 

ah, yes, new nvram directories under ~/.mame/ for each system... It seems to work to remove the ti99_4ev and ti99_4ae and soft link them over to the ti99_4a directory. 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...