Jump to content
IGNORED

New MAME release


mizapf

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?

 

 

Link to comment
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".

Link to comment
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
Link to comment
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
Link to comment
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?

Link to comment
Share on other sites

  • 2 weeks later...

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
Link to comment
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.

Link to comment
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
Link to comment
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. 

  • Like 3
Link to comment
Share on other sites

Well since I have been rained out today and can't work on my trucks, I decided to see exactly which version of sdlmame got changed and broke my ability to use it on my macbook air. At this time version 215 will work, but 217 gives the plugin.ini error for the bgfx files and the Engine translation error. I am downloading 216 now to see if it was the finale working one for me or not. I want to get 226 working, but don't know why they changed it.

Link to comment
Share on other sites

5 minutes ago, RickyDean said:

Well since I have been rained out today and can't work on my trucks, I decided to see exactly which version of sdlmame got changed and broke my ability to use it on my macbook air. At this time version 215 will work, but 217 gives the plugin.ini error for the bgfx files and the Engine translation error. I am downloading 216 now to see if it was the finale working one for me or not. I want to get 226 working, but don't know why they changed it.

I ran into the same issue on a virtual mac.  anything over .215 will not work.  

 

I fixed it in my INI file.  you may be able to do the same, it's worth a shot.

 

I had to force 'OpenGL' within the main.ini file

 

Under #OSD VIDEO OPTIONS

 

Changed video from auto to opengl and now it fires right off.

 

 

Link to comment
Share on other sites

7 minutes ago, Shift838 said:

I ran into the same issue on a virtual mac.  anything over .215 will not work.  

 

I fixed it in my INI file.  you may be able to do the same, it's worth a shot.

 

I had to force 'OpenGL' within the main.ini file

 

Under #OSD VIDEO OPTIONS

 

Changed video from auto to opengl and now it fires right off.

 

 

Okay confirmed 216 does not work either. Will give this a try on 226.

20201029_162256.jpg

Link to comment
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.
Note: Your post will require moderator approval before it will be visible.

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...