Author Topic: How do I compile DOS MAME .36? (Read 8407 times)

SirPeale · « **on:** April 23, 2004, 06:21:18 pm »

I downloaded the DOS compiler off mame.net and it gives me crap:

H:\mame36src>make
Compiling src/driver.c...
In file included from src/driver.h:8,
                 from src/driver.c:15:
src/mame.h:41:25: C++ style comments are not allowed in ISO C89
src/mame.h:41:25: (this will be reported only once per input file)
In file included from src/sound/2608intf.h:4,
                 from src/sndintrf.h:28,
                 from src/driver.h:10,
                 from src/driver.c:15:
src/sound/fm.h:18:1: C++ style comments are not allowed in ISO C89
src/sound/fm.h:18:1: (this will be reported only once per input file)
In file included from src/driver.h:16,
                 from src/driver.c:15:
src/tilemap.h:173:1: C++ style comments are not allowed in ISO C89
src/tilemap.h:173:1: (this will be reported only once per input file)
In file included from src/driver.c:56:
src/driver.c:1209:1: C++ style comments are not allowed in ISO C89
src/driver.c:1209:1: (this will be reported only once per input file)
In file included from src/driver.c:65:
src/driver.c:1209:1: C++ style comments are not allowed in ISO C89
src/driver.c:1209:1: (this will be reported only once per input file)
src/driver.c:1209:1: C++ style comments are not allowed in ISO C89
src/driver.c:1209:1: (this will be reported only once per input file)
make.exe: *** [obj/driver.o] Error 1

H:\MAME36~2>

What am I doing wrong? I'm guessing I need an older version.

SirPeale · « **Reply #1 on:** April 24, 2004, 12:33:32 pm »

Certainly, SOMEONE must still compile the old versions occasionally.

JoyMonkey · « **Reply #2 on:** April 24, 2004, 12:53:31 pm »

I tried compiling .36 a few weeks ago, but ran into a bunch of error messages and gave up after a few hours.
My errors were different than yours though.

SirPeale · « **Reply #3 on:** April 25, 2004, 06:18:25 pm »

Yeah, I'm doing it for a couple reasons:

1) going to swap out the old sidearms driver for the new one.

2) remove the 'ok' screens.

Mostly #1. I did a Google search but didn't come up with much except a tutorial on compiling .67 (which AFAIK is what the compiler on mame.net supports)

So I'm still in the same boat.

Buddabing · « **Reply #4 on:** April 26, 2004, 11:00:19 am »

Quote from: Peale on April 23, 2004, 06:21:18 pm

I downloaded the DOS compiler off mame.net and it gives me crap:

Code: [Select]
H:\mame36src>make Compiling src/driver.c... In file included from src/driver.h:8, from src/driver.c:15: src/mame.h:41:25: C++ style comments are not allowed in ISO C89 src/mame.h:41:25: (this will be reported only once per input file) In file included from src/sound/2608intf.h:4, from src/sndintrf.h:28, from src/driver.h:10, from src/driver.c:15: src/sound/fm.h:18:1: C++ style comments are not allowed in ISO C89 src/sound/fm.h:18:1: (this will be reported only once per input file) In file included from src/driver.h:16, from src/driver.c:15: src/tilemap.h:173:1: C++ style comments are not allowed in ISO C89 src/tilemap.h:173:1: (this will be reported only once per input file) In file included from src/driver.c:56: src/driver.c:1209:1: C++ style comments are not allowed in ISO C89 src/driver.c:1209:1: (this will be reported only once per input file) In file included from src/driver.c:65: src/driver.c:1209:1: C++ style comments are not allowed in ISO C89 src/driver.c:1209:1: (this will be reported only once per input file) src/driver.c:1209:1: C++ style comments are not allowed in ISO C89 src/driver.c:1209:1: (this will be reported only once per input file) make.exe: *** [obj/driver.o] Error 1 H:\MAME36~2>
What am I doing wrong? I'm guessing I need an older version.

Remove the -pedantic compile option. I'm still working on getting a compile going for you....

SirPeale · « **Reply #5 on:** April 26, 2004, 12:04:05 pm »

Thanks, it actually starts. But now I get this:

Code: [Select]

H:\MAME36~2>make
Compiling src/driver.c...
Compiling src/mame.c...
Compiling src/drawgfx.c...
Compiling src/common.c...
Compiling src/usrintrf.c...
Compiling src/cpuintrf.c...
src/cpuintrf.c:310:153: pasting "&" and "Dummy" does not give a valid preprocessing token
src/cpuintrf.c:312:137: pasting "&" and "z80" does not give a valid preprocessing token
src/cpuintrf.c:318:137: pasting "&" and "i8080" does not give a valid preprocessing token
src/cpuintrf.c:321:129: pasting "&" and "i8085" does not give a valid preprocessing token
src/cpuintrf.c:324:129: pasting "&" and "m6502" does not give a valid preprocessing token
src/cpuintrf.c:327:129: pasting "&" and "m65c02" does not give a valid preprocessing token
src/cpuintrf.c:339:129: pasting "&" and "m6510" does not give a valid preprocessing token

SirPeale · « **Reply #6 on:** April 26, 2004, 12:45:34 pm »

twisty over @ mame.net forums sent me this: http://www.mame.net/compilefinal.html

Which looks like it would work, but it's not. Think I need to do this on a DOS box instead of via Windows XP.

Buddabing · « **Reply #7 on:** April 26, 2004, 12:56:57 pm »

Quote from: Peale on April 26, 2004, 12:04:05 pm

Thanks, it actually starts. But now I get this:

Code: [Select]
H:\MAME36~2>make Compiling src/driver.c... Compiling src/mame.c... Compiling src/drawgfx.c... Compiling src/common.c... Compiling src/usrintrf.c... Compiling src/cpuintrf.c... src/cpuintrf.c:310:153: pasting "&" and "Dummy" does not give a valid preprocessing token src/cpuintrf.c:312:137: pasting "&" and "z80" does not give a valid preprocessing token src/cpuintrf.c:318:137: pasting "&" and "i8080" does not give a valid preprocessing token src/cpuintrf.c:321:129: pasting "&" and "i8085" does not give a valid preprocessing token src/cpuintrf.c:324:129: pasting "&" and "m6502" does not give a valid preprocessing token src/cpuintrf.c:327:129: pasting "&" and "m65c02" does not give a valid preprocessing token src/cpuintrf.c:339:129: pasting "&" and "m6510" does not give a valid preprocessing token

Yeah, I see the exact same thing.

Are you using the files given here, or are you using later versions of make, gcc, etc.?

It may be that the newer versions of gcc won't compile it.

I'm running into some command line length issues in Windows XP, so you might be right about that.

Lilwolf · « **Reply #8 on:** April 26, 2004, 02:21:02 pm »

compiling mame today is SO MUCH EASIER then it used to be.

I have done it... and I try not to think of the grey hair it produced!

good luck!

SirPeale · « **Reply #9 on:** April 26, 2004, 02:25:55 pm »

Quote from: Buddabing on April 26, 2004, 12:56:57 pm

Yeah, I see the exact same thing.

Are you using the files given here, or are you using later versions of make, gcc, etc.?

It may be that the newer versions of gcc won't compile it.

I'm running into some command line length issues in Windows XP, so you might be right about that.

Yeah, I was using the files @ the URL you referenced.

So, I made a DOS 7.0 boot disk, put cwsdpmi.exe on it, and started compiling.

It went without a hitch, until it hit the 68000 series CPU set. It couldn't compile because the compiler was a Windows program! What a Windows compiler is doing in a DOS set is beyond me.

Since this is just for initial testing purposes, I commented out 68000 core from makefile, and it went on it's way.

When it got to the DOS Allegro part, it barfed. I'd post what it said here, but I'm not sure how to get it to log what it does. But it didnt' like the Allegro I used.

What I did was use the new Allegro set instead of compiling the one on the referenced page. When it barfed, I attemped to compile the other, and it barfed too, when it got to a certain point. Again, not sure how to log that, so I have no output.

So, pretty much, unless I suddenly make myself a whole Windows 98 box to compile this on, I'm stuck for now.

SirPeale · « **Reply #10 on:** April 26, 2004, 02:35:47 pm »

Hey, I ran it in Windows, and got the error. Well, the MAME error, haven't tried the Allegro library yet.

Code: [Select]

Compiling src/msdos/msdos.c...
cc1.exe: warnings being treated as errors
In file included from c:/djgpp/include/allegro.h:33,
                 from src/msdos/mamalleg.h:9,
                 from src/msdos/msdos.c:11:
c:/djgpp/include/allegro/timer.h:49: warning: declaration of `time' shadows global declaration
c:/djgpp/include/allegro/timer.h:74: warning: declaration of `time' shadows global declaration
c:/djgpp/include/allegro/timer.h:75: warning: declaration of `time' shadows global declaration
In file included from c:/djgpp/include/allegro/sound.h:23,
                 from c:/djgpp/include/allegro.h:49,
                 from src/msdos/mamalleg.h:9,
                 from src/msdos/msdos.c:11:
c:/djgpp/include/allegro/digi.h:85: warning: declaration of `time' shadows global declaration
c:/djgpp/include/allegro/digi.h:91: warning: declaration of `time' shadows global declaration
c:/djgpp/include/allegro/digi.h:97: warning: declaration of `time' shadows global declaration
c:/djgpp/include/allegro/digi.h:171: warning: declaration of `time' shadows global declaration
c:/djgpp/include/allegro/digi.h:176: warning: declaration of `time' shadows global declaration
c:/djgpp/include/allegro/digi.h:181: warning: declaration of `time' shadows global declaration
In file included from c:/djgpp/include/allegro.h:74,
                 from src/msdos/mamalleg.h:9,
                 from src/msdos/msdos.c:11:
c:/djgpp/include/allegro/platform/aldos.h:260: warning: declaration of `line' shadows global declaration
make.exe: *** [obj/msdos/msdos.o] Error 1

H:\mame36sc>

SirPeale · « **Reply #11 on:** April 26, 2004, 02:41:01 pm »

And here's the Allegro error:

Code: [Select]

C:\djgpp\allegro>make all
c:/djgpp/bin/make.exe msg lib
make.exe[1]: Entering directory `c:/djgpp/allegro'
Compiling Allegro for djgpp, optimised. Please wait...
make.exe[1]: Nothing to be done for `lib'.
make.exe[1]: Leaving directory `c:/djgpp/allegro'
c:/djgpp/bin/make.exe msg lib DEBUGMODE=1
make.exe[1]: Entering directory `c:/djgpp/allegro'
Compiling Allegro for djgpp, debugging. Please wait...
gcc -DDEBUGMODE=1 -Wall -Wno-unused -I. -I./include -x assembler-with-cpp -o obj
/djgpp/alld/iblit16.o -c src/i386/iblit16.s
c:/djgpp/tmp\ccDUCgIj.s: Assembler messages:
c:/djgpp/tmp\ccDUCgIj.s:381: Error: operands given don't match any known 386 instruction
c:/djgpp/tmp\ccDUCgIj.s:382: Error: operands given don't match any known 386 instruction
c:/djgpp/tmp\ccDUCgIj.s:624: Error: operands given don't match any known 386 instruction
c:/djgpp/tmp\ccDUCgIj.s:656: Error: operands given don't match any known 386 instruction
c:/djgpp/tmp\ccDUCgIj.s:672: Error: operands given don't match any known 386 instruction
c:/djgpp/tmp\ccDUCgIj.s:687: Error: operands given don't match any known 386 instruction
c:/djgpp/tmp\ccDUCgIj.s:701: Error: operands given don't match any known 386 instruction
c:/djgpp/tmp\ccDUCgIj.s:710: Error: operands given don't match any known 386 instruction
c:/djgpp/tmp\ccDUCgIj.s:718: Error: operands given don't match any known 386 instruction
c:/djgpp/tmp\ccDUCgIj.s:735: Error: operands given don't match any known 386 instruction
c:/djgpp/tmp\ccDUCgIj.s:742: Error: operands given don't match any known 386 instruction
c:/djgpp/tmp\ccDUCgIj.s:749: Error: operands given don't match any known 386 instruction
c:/djgpp/tmp\ccDUCgIj.s:794: Error: operands given don't match any known 386 instruction
c:/djgpp/tmp\ccDUCgIj.s:816: Error: operands given don't match any known 386 instruction
c:/djgpp/tmp\ccDUCgIj.s:861: Error: operands given don't match any known 386 instruction
c:/djgpp/tmp\ccDUCgIj.s:915: Error: operands given don't match any known 386 instruction
make.exe[1]: *** [obj/djgpp/alld/iblit16.o] Error 1
make.exe[1]: Leaving directory `c:/djgpp/allegro'
make.exe: *** [all] Error 2

Buddabing · « **Reply #12 on:** April 26, 2004, 02:47:34 pm »

For the first error, try removing the word "time" in the timer.h and the digi.h files.

for example, change "long time," to "long,"

On the second one, should you be doing a "make lib" followed by "make install" instead of a "make all" ?

It looks like "make lib" was actually successful.

Is your target a 386? If not, you might want to define a different processor.

SirPeale · « **Reply #13 on:** April 26, 2004, 02:53:32 pm »

Yup, x86 is my target.

I shouldn't *have* to change anything in source. The software is established as working, as well as the compiler. I'm not sure where the bumps I'm hitting are coming from.

This is the latest, after installing the old Allegro libraries:

Code: [Select]

Compiling src/msdos/msdos.c...
cc1.exe: warnings being treated as errors
In file included from c:/djgpp/include/allegro.h:33,
                 from src/msdos/mamalleg.h:9,
                 from src/msdos/msdos.c:11:
c:/djgpp/include/allegro/timer.h:49: warning: declaration of `time' shadows global declaration
c:/djgpp/include/allegro/timer.h:74: warning: declaration of `time' shadows global declaration
c:/djgpp/include/allegro/timer.h:75: warning: declaration of `time' shadows global declaration
In file included from c:/djgpp/include/allegro/sound.h:23,
                 from c:/djgpp/include/allegro.h:49,
                 from src/msdos/mamalleg.h:9,
                 from src/msdos/msdos.c:11:
c:/djgpp/include/allegro/digi.h:85: warning: declaration of `time' shadows global declaration
c:/djgpp/include/allegro/digi.h:91: warning: declaration of `time' shadows global declaration
c:/djgpp/include/allegro/digi.h:97: warning: declaration of `time' shadows global declaration
c:/djgpp/include/allegro/digi.h:171: warning: declaration of `time' shadows global declaration
c:/djgpp/include/allegro/digi.h:176: warning: declaration of `time' shadows global declaration
c:/djgpp/include/allegro/digi.h:181: warning: declaration of `time' shadows global declaration
In file included from c:/djgpp/include/allegro.h:74,
                 from src/msdos/mamalleg.h:9,
                 from src/msdos/msdos.c:11:
c:/djgpp/include/allegro/platform/aldos.h:260: warning: declaration of `line' shadows global declaration
make.exe: *** [obj/msdos/msdos.o] Error 1

H:\mame36sc>

Buddabing · « **Reply #14 on:** April 26, 2004, 03:18:22 pm »

Quote from: Peale on April 26, 2004, 02:53:32 pm

Yup, x86 is my target.

There are separate compiler options for 386, 486, Pentium, Pentium Pro.

Quote

I shouldn't *have* to change anything in source. The software is established as working, as well as the compiler. I'm not sure where the bumps I'm hitting are coming from.

Other than changing the source, the only other thing I can suggest is to remove the -Werror option from your makefile. That will cause warnings to not abort the compile.

I read something in the Allegro source about it not compiling with gcc 3.0 or higher. So I hope your gcc is 2.9.x.

Man this is a big PITA. Once you have everything compiled, you ought to zip up your entire djgpp directory, burn it to a CD-ROM, and have someone host the iso image.

SirPeale · « **Reply #15 on:** April 26, 2004, 03:56:19 pm »

Quote from: Buddabing on April 26, 2004, 03:18:22 pm

Quote from: Peale on April 26, 2004, 02:53:32 pm
Yup, x86 is my target.
There are separate compiler options for 386, 486, Pentium, Pentium Pro.

Oh, that. I'm just running stock 'make' without options. Right now what it's choking on is the Allegro libraries, for whatever reason. The last error set is what was causing me all that problem.

Quote

Quote

I shouldn't *have* to change anything in source. The software is established as working, as well as the compiler. I'm not sure where the bumps I'm hitting are coming from.

Other than changing the source, the only other thing I can suggest is to remove the -Werror option from your makefile. That will cause warnings to not abort the compile.

I read something in the Allegro source about it not compiling with gcc 3.0 or higher. So I hope your gcc is 2.9.x.

Man this is a big PITA. Once you have everything compiled, you ought to zip up your entire djgpp directory, burn it to a CD-ROM, and have someone host the iso image.

I'll give the -Werror option thing a shot.

I got the all the compilers straight from mame.net, so I would think using what they're telling me to, and following their instructions, should bring the desired result.

SirPeale · « **Reply #16 on:** April 26, 2004, 09:42:21 pm »

Well, I got it working. I had to pull out a spare hard drive, install Windows 98 and follow the instructions on mame.net to the letter. It compiled without a hitch.

Now to try swapping a couple drivers out.

JoyMonkey · « **Reply #17 on:** April 26, 2004, 10:25:36 pm »

Quote from: Peale on April 26, 2004, 09:42:21 pm

Well, I got it working. I had to pull out a spare hard drive, install Windows 98 and follow the instructions on mame.net to the letter. It compiled without a hitch.

Now to try swapping a couple drivers out.

Damn. I've also tried compiling it on a fresh Windows 98 machine, but no joy. I thought there must have been a mistake in the instructions, but I guess I must have missed something.

SirPeale · « **Reply #18 on:** April 26, 2004, 11:03:11 pm »

Well, so far it's been for naught anyway. I tried swapping out the driver for sidearms from .72 (where the starfield makes it's appearance) with no joy. There are too many changes to the driver, and to the MAME source itself for me to try to make the changes. Perhaps if I knew what I was doing I might give it a shot, but since I don't...

If anyone is interested, I'll zip the compiler I have up and put it up for grabs somewhere.

EightBySix · « **Reply #19 on:** June 13, 2013, 05:16:08 pm »

Do I win the award for best necro thread?

:

I'm wanting to compile mame 0.36 too, partly for the nonag, but also to make some tweaks. I've tried using dosbox but with little luck.
Is the trick to install windows 98 and build it in that environment?

Does anyone still have the tools / memory to help?

EightBySix · « **Reply #20 on:** June 13, 2013, 05:18:05 pm »

... Also, mame.net gives me a 403 forbidden... Lots of the instructions seem to refer to it. Does anyone know if it's still around somewhere?

404 · « **Reply #21 on:** June 13, 2013, 06:06:46 pm »

have you tried older versions of mame compiler? .036 might be a bit of a stretch though.

http://www.headsoft.com.au/?category=mame&page=mc64

It's not anywhere near as old as 36 but i do have a compiled version of 106 that is nag free.

Haze · « **Reply #22 on:** June 13, 2013, 07:55:28 pm »

http://mamedev.emulab.it/haze/reallyoldstuff/compile036dos.html
is a mirror of the old mame.net page.

I strongly advise AGAINST using 0.36 (or anything older than a few years) for any real purpose..

The only reason I even have these files around still is because 0.36 is now an interesting emulation *target* ie, we're at the point of emulating machines running old versions of MAME in MESS, that's how old it is!

The emulation in these old versions is vastly inferior in every imaginable way to modern versions, and unless you have absolutely antique hardware they shouldn't be a consideration at all.

Rigby · « **Reply #23 on:** June 13, 2013, 10:49:32 pm »

Quote from: Haze on June 13, 2013, 07:55:28 pm

The only reason I even have these files around still is because 0.36 is now an interesting emulation *target* ie, we're at the point of emulating machines running old versions of MAME in MESS, that's how old it is!

I wonder which version of MESS will emulate the version of MESS you're talking about.

There's still some value in a DOS target, I think. Booting to DOS via a USB key and running MAME from autoexec.bat is far faster and far simpler than anything Linux can offer, and built-in VESA video modes can go a long way.

Haze · « **Reply #24 on:** June 14, 2013, 08:10:45 am »

Quote from: Rigby on June 13, 2013, 10:49:32 pm

Quote from: Haze on June 13, 2013, 07:55:28 pm
The only reason I even have these files around still is because 0.36 is now an interesting emulation *target* ie, we're at the point of emulating machines running old versions of MAME in MESS, that's how old it is!

I wonder which version of MESS will emulate the version of MESS you're talking about.

There's still some value in a DOS target, I think. Booting to DOS via a USB key and running MAME from autoexec.bat is far faster and far simpler than anything Linux can offer, and built-in VESA video modes can go a long way.

sure, but the actual emulation is utter trash for many of the games compared to what we have today, and at the end of the day that surely matters more than 'boots fast'

I don't think there is a single supported driver that hasn't seen significant improvements of some form since then.

the value of seeing it is being able to see what came before, see what interesting hacks were needed for speed, the relative lack of any framework (meaning a lot of weight was placed on individual drivers instead) etc. It also makes nice abuse cases for the PC video emulation in modern mess builds with all the custom mode support etc.

Rigby · « **Reply #25 on:** June 14, 2013, 09:45:23 am »

Quote from: Haze on June 14, 2013, 08:10:45 am

Quote from: Rigby on June 13, 2013, 10:49:32 pm
There's still some value in a DOS target, I think. Booting to DOS via a USB key and running MAME from autoexec.bat is far faster and far simpler than anything Linux can offer, and built-in VESA video modes can go a long way.

sure, but the actual emulation is utter trash for many of the games compared to what we have today, and at the end of the day that surely matters more than 'boots fast'

I don't think there is a single supported driver that hasn't seen significant improvements of some form since then.

the value of seeing it is being able to see what came before, see what interesting hacks were needed for speed, the relative lack of any framework (meaning a lot of weight was placed on individual drivers instead) etc. It also makes nice abuse cases for the PC video emulation in modern mess builds with all the custom mode support etc.

Oh, I agree with you; the new stuff is definitely better, it's clear from the code and from the number of supported games, the quality of emulation, and everything else. I'm not saying that any of us want to throw away all your guys' work just for boot speed; that's silly.

I would not be attracted to a DOS MAME machine if I knew enough about Linux to get it booted up in a reasonable timeframe. "Reasonable" being less than 20s from power on to start of emulation. I'm certainly not saying it's not possible with Linux; hell, Windows 7 can do it if you have an SSD and if you tune it right, but it's dead easy to get that start up time with DOS. At least it was the last time I tried it.

I would welcome, with open arms, advice on how to compile 0.149 for DOS and/or advice on how to tweak/construct a live Linux CD/USB that can boot into emulation in a few seconds.

Haze · « **Reply #26 on:** June 14, 2013, 11:05:41 am »

Quote from: Rigby on June 14, 2013, 09:45:23 am

Quote from: Haze on June 14, 2013, 08:10:45 am
Quote from: Rigby on June 13, 2013, 10:49:32 pm
There's still some value in a DOS target, I think. Booting to DOS via a USB key and running MAME from autoexec.bat is far faster and far simpler than anything Linux can offer, and built-in VESA video modes can go a long way.

sure, but the actual emulation is utter trash for many of the games compared to what we have today, and at the end of the day that surely matters more than 'boots fast'

I don't think there is a single supported driver that hasn't seen significant improvements of some form since then.

the value of seeing it is being able to see what came before, see what interesting hacks were needed for speed, the relative lack of any framework (meaning a lot of weight was placed on individual drivers instead) etc. It also makes nice abuse cases for the PC video emulation in modern mess builds with all the custom mode support etc.

Oh, I agree with you; the new stuff is definitely better, it's clear from the code and from the number of supported games, the quality of emulation, and everything else. I'm not saying that any of us want to throw away all your guys' work just for boot speed; that's silly.

I would not be attracted to a DOS MAME machine if I knew enough about Linux to get it booted up in a reasonable timeframe. "Reasonable" being less than 20s from power on to start of emulation. I'm certainly not saying it's not possible with Linux; hell, Windows 7 can do it if you have an SSD and if you tune it right, but it's dead easy to get that start up time with DOS. At least it was the last time I tried it.

I would welcome, with open arms, advice on how to compile 0.149 for DOS and/or advice on how to tweak/construct a live Linux CD/USB that can boot into emulation in a few seconds.

DOS throws hundreds of limitations your way alone tho, the memory support is very limited, the way it handles executables is very limited, the filesystem is limited, no 64-bit support etc.

You wouldn't *want* to run 0.149 on DOS, because DOS would cripple it, your bottleneck becomes the OS and it's ancient ways.

Of course a semi-modern linux with no desktop might be a more feasible solution for 'fast boot' but all this DOS love is as stupid as the love for ancient versions of MAME themselves IMHO. It was a *horrible* environment.

Even looking at the compile guide you've got to laugh at the parts where the compiler crashes midway through and needs to be started again, I actually remember it BSODing / rebooting my machine several times during a full compile rather than just crashing too! We really have come a long way since those days, even if IMHO we peaked around winxp and have seen a rapid decline since.

Rigby · « **Reply #27 on:** June 14, 2013, 11:18:48 am »

Hah, yeah I didn't say I wasn't stupid.

I just love the quick boot nature of DOS. I wish it were easily done with other OSs.

EightBySix · « **Reply #28 on:** June 14, 2013, 07:05:14 pm »

Quote from: Rigby on June 13, 2013, 10:49:32 pm

There's still some value in a DOS target, I think. Booting to DOS via a USB key and running MAME from autoexec.bat is far faster and far simpler than anything Linux can offer, and built-in VESA video modes can go a long way.

This is where I'm coming from. I want to compile the most 'recent' version of MAME that was DOS based. It can boot in only a few seconds on my Pentium 166 - and silent too with a CF card instead of an HDD.

I only want to play classics - and whilst improved quality of the emulation is a good thing - it's not a priority for me.

Any pointers for sites still up with advice/resources ?

MonMotha · « **Reply #29 on:** June 14, 2013, 07:54:52 pm »

FWIW, it's possible to boot the Linux kernel in about 4-5 seconds without TOO much effort stripping it down. 10 seconds is readily achievable; you can probably even to do it on a distro stock kernel if you're careful about what gets thrown in the initrd.

The X server starts in about another 2-3, generally, and a tiny window manager like lightbox, twm, fvwm, etc. is almost instantaneous these days. It's the "desktop environments" and whatnot that take ages to start, as well as starting all the services and whatnot that you don't really need on a system like this. The embedded guys frequently try to get total system boot time (including bootloader, etc.) under 10 seconds, and many people go for under 5.

You won't do it with a stock desktop install of Ubuntu, mind you, but it's quite doable, and you get a lot more facilities for your trouble in terms of modern hardware support than you do with DOS. If you know what you're doing, I'm not sure it's even that much more of a hassle.

An SSD or CF/SD card for your storage will help. At those boot times, the time spent in the BIOS startup screens is probably a significant part of your boot time.

Actually doing it is left as an exercise to the reader...

(It's actually also possible to get pretty close with Windows, these days, but doing so is a real pain in the butt, and some of the tools you need are either not public or not really supposed to be public)

Also, you'd laugh at the boot time of some modern arcade games. While some of the old ROM based games with no startup checks were essentially instantly playable, I clocked a modern title at over 12 minutes, recently.

EightBySix · « **Reply #30 on:** June 15, 2013, 03:33:31 am »

Interesting. A pared down, non GUI Linux build would give me more options... Would the timings you quote apply to old kit too?

404 · « **Reply #31 on:** June 15, 2013, 07:43:27 am »

Quote from: Haze on June 14, 2013, 11:05:41 am

DOS throws hundreds of limitations your way alone tho, the memory support is very limited, the way it handles executables is very limited, the filesystem is limited, no 64-bit support etc.

You wouldn't *want* to run 0.149 on DOS, because DOS would cripple it, your bottleneck becomes the OS and it's ancient ways.

Of course a semi-modern linux with no desktop might be a more feasible solution for 'fast boot' but all this DOS love is as stupid as the love for ancient versions of MAME themselves IMHO. It was a *horrible* environment.

Even looking at the compile guide you've got to laugh at the parts where the compiler crashes midway through and needs to be started again, I actually remember it BSODing / rebooting my machine several times during a full compile rather than just crashing too! We really have come a long way since those days, even if IMHO we peaked around winxp and have seen a rapid decline since.

Quote from: MonMotha on June 14, 2013, 07:54:52 pm

FWIW, it's possible to boot the Linux kernel in about 4-5 seconds without TOO much effort stripping it down. 10 seconds is readily achievable; you can probably even to do it on a distro stock kernel if you're careful about what gets thrown in the initrd.

The X server starts in about another 2-3, generally, and a tiny window manager like lightbox, twm, fvwm, etc. is almost instantaneous these days. It's the "desktop environments" and whatnot that take ages to start, as well as starting all the services and whatnot that you don't really need on a system like this. The embedded guys frequently try to get total system boot time (including bootloader, etc.) under 10 seconds, and many people go for under 5.

You won't do it with a stock desktop install of Ubuntu, mind you, but it's quite doable, and you get a lot more facilities for your trouble in terms of modern hardware support than you do with DOS. If you know what you're doing, I'm not sure it's even that much more of a hassle.

An SSD or CF/SD card for your storage will help. At those boot times, the time spent in the BIOS startup screens is probably a significant part of your boot time.

Actually doing it is left as an exercise to the reader...

(It's actually also possible to get pretty close with Windows, these days, but doing so is a real pain in the butt, and some of the tools you need are either not public or not really supposed to be public)

Also, you'd laugh at the boot time of some modern arcade games. While some of the old ROM based games with no startup checks were essentially instantly playable, I clocked a modern title at over 12 minutes, recently.

Just a vague response to the two posts above.

I've personally never been able to successfully get DOS to run mame. I've also never been able to successfully get any of Arcade-catering linux distros to work properly without jumping through just as many hoops and getting completely stuck near the finish line so to speak.

I only get nominal results from using full fledged distros like Ubuntu which sort of defeats the purpose.

gonzo90017 · « **Reply #32 on:** June 15, 2013, 02:42:57 pm »

For those willing to give it a try ArcaDOS. It's similiar to Spystyle's boot cd. Forum is in spanish so Google Translator is your friend.

MonMotha · « **Reply #33 on:** June 15, 2013, 11:10:17 pm »

Quote from: EightBySix on June 15, 2013, 03:33:31 am

Interesting. A pared down, non GUI Linux build would give me more options... Would the timings you quote apply to old kit too?

In general, the limitation is getting the data you need to get off storage fast enough and making sure you're not running code you don't need to. For older (slower) kit, this may mean a custom kernel with everything you don't need turned off, no or minimal initrd/initramfs, and perhaps an upgraded/faster hard drive (or use e.g. a CF card in an ATA adapter) and ensuring that nothing you don't need is installed. People do pull this stuff off all the time on things no more powerful than e.g. a Raspberry Pi. Compiling a custom kernel for a PC isn't actually that hard, though the configuration is likely to be totally overwhelming if you've never done it before. The Linux kernel has a LOT of knobs. Fortunately, you won't have to mess with most of them: just turn on and off the drivers you need.

If you really want "non-GUI" you'll get stuck with using the framebuffer console for graphics. This is usually mostly unaccelerated, and I'm not sur e if there's a MAME target for it or not. You may end up needing to at least run the X server to get reasonable hardware acceleration (even for 2D), but this isn't a huge deal as long as you don't try to start a full DE like GNOME or KDE.

Gray_Area · « **Reply #34 on:** June 16, 2013, 01:11:02 pm »

Jeez, under sixty seconds is plenty of time to, ah, breathe. Take the opportunity.

EightBySix · « **Reply #35 on:** June 16, 2013, 02:39:27 pm »

Quote from: Gray_Area on June 16, 2013, 01:11:02 pm

Jeez, under sixty seconds is plenty of time to, ah, breathe. Take the opportunity.

I wouldn't disagree with you normally, but my project has a screen under a table top that is motorised and opens up when the control panel is pulled out. I want mame to be running by the time the top has opened.

Haze · « **Reply #36 on:** June 16, 2013, 03:30:55 pm »

Quote from: EightBySix on June 16, 2013, 02:39:27 pm

Quote from: Gray_Area on June 16, 2013, 01:11:02 pm
Jeez, under sixty seconds is plenty of time to, ah, breathe. Take the opportunity.

I wouldn't disagree with you normally, but my project has a screen under a table top that is motorised and opens up when the control panel is pulled out. I want mame to be running by the time the top has opened.

That kinda typifies what I hate about so many modern products tho, you're favouring shiny novelty functionality over a solid core product, if it's an emulation box then the quality of the emulation should come first, yet so many people pick atrocious solutions like ancient versions of MAME, 60-in-1 boards or Rasp. Pis for the job which means no matter how cool the unit is, it will ALWAYS suck. The thread about 60-in-1- vs Pi makes me laugh, it's like asking if cat s**t is better than dog s**t.

Rigby · « **Reply #37 on:** June 16, 2013, 09:48:50 pm »

Quote from: Haze on June 16, 2013, 03:30:55 pm

The thread about 60-in-1- vs Pi makes me laugh, it's like asking if cat s**t is better than dog s**t.

Dog poo, because it's usually outside. (Dog poo = Raspberry Pi, by the way, in the "cat poo vs. dog poo" debate.)

If I could find or create a quick booting solution that ran MAME/MESS 0.149, I would be ALL OVER IT. In my ideal world I have perfect emulation of everything and as soon as I powered it on, it would be as if I powered the actual hardware on.

I fear you may get the impression that we are not concerned with emulation quality; that is not the case at all. This topic is about DOS MAME, so that's what were talking about, but we ALL love MAME and MESS (at least I do) and I read every last word you post on your blog because I love to see how it's evolving and growing.

The Raspberry Pi topic you mentioned is relevant because the platform is inexpensive and technically it plays games. You must admit that for cash strapped people, a Raspberry Pi is an attractive option. Is it an ideal option, hell no it's not ideal, but there are a few games that play well on it, and to me that speaks more to how long MAME has been a viable piece of software.

Haze · « **Reply #38 on:** June 16, 2013, 10:01:53 pm »

yeah, I know some people will stick with it for financial reasons.. but also look at the Looping thread here, there are people who haven't realised the game works properly in MAME these days..

a brief scan of history would suggest it was fixed in 0.109u4
and that
"MAME 0.109u4 was released on 26 October 2006"

so we have people talking about 7 year old bugs as if they were current and a lot of that I think is because people are cheaping out on things rather than developing better more modern solutions based on newer versions and better hardware.

there are more competitive 'cheap' solutions out there than the Pi too... and any choice that involves DOS Mame or Mame4all is going to give you a whole host of bugs simply because those versions are so old.

I think it's a shame, that's all, and while I don't mind providing the instructions to build the old MAME 0.36 builds (MAME/MESS is a software project about documenting & preserving history afterall, so it follows that we really should preserve the history of MAME too) I do have to put sufficient warnings up when I make such information available because I don't consider using it for any 'real' purpose beyond the curiosity of seeing where we came from to be a good idea at all.

Obviously you get what you pay for, but it's sad to see so much work put into some areas of projects while others are left lacking..

I don't consider MAME immune from criticism too mind you, there are definitely cases where we too care too much about things that don't really matter much over core values, but I'm simply giving my honest opinion on things.


Main	Restorations	Software	Audio/Jukebox/MP3	Everything Else	Buy/Sell/Trade
Project Announcements	Monitor/Video	GroovyMAME	Merit/JVL Touchscreen	Meet Up	Retail Vendors
Driving & Racing	Woodworking	Software Support Forums	Consoles	Project Arcade	Reviews
Automated Projects	Artwork	Frontend Support Forums	Pinball	Forum Discussion	Old Boards
Raspberry Pi & Dev Board	controls.dat	Linux	Miscellaneous Arcade	Wiki Discussion	Old Archives
Lightguns	Arcade1Up	Try the site in https mode		Site News


Unread posts \| New Replies \| Recent posts \| Rules \| Chatroom \| Wiki \| File Repository \| RSS \| Submit news