Interesting ... the maintainer for this MAME package for Ubuntu may have hardcoded /etc/mame/ as a search path for ini files, where MAME starts to search for a mame.ini. My MAME executable does not search for mame.ini in /etc/mame, in contrast, and I did not find any hints for that behavior in the source code. It could make sense to have it this way when you do a system-wide installation, as possibly intended here with this PPA.

The problem is that this hardcoded /etc/mame/mame.ini defines that MAME search for the mame.ini file in ~/.mame and some other locations, but not in the current directory. If you want to allow for multiple mame.ini files (e.g. one for the arcade machines, one for the TI machines), you have to either add ".;" (period, semicolon) at the start of the value for inipath in /etc/mame/mame.ini, or you have to explicitly specify the inipath when invoking MAME, as I wrote above (which overrides the hardcoded path).

I guess it cannot be done much shorter without using a special installer program.

Michael,

Are the contents of that wiki article still valid? I see references to things on whtech that are not obvious. I see stuff for MESS, but not MAME. Might not hurt to have some info in there about utilization of the Geneve and your tool to convert V4 to V5 HD images, etc.

I've got a puzzling issue I am trying to resolve. I've got two keyboards I am trying to sort out with MAME/Windows

Keyboard #1: USB, Has Scroll Lock button

Keyboard #2: USB, No Scroll Lock Button

If I use Keyboard #1, I am not able to use the function keys. The F9 button selects a search function. Seems as though none of the function keys are being properly captured within the geneve emulation.

If I use Keyboard #2, I do not have a way to exit back to the settings since it has no Scroll Lock button.

As for your first keyboard, what search function is that? Could it be configured in Windows?

I tried configuring, and after playing with both keyboard for some time, figured out there were more toggles on the SCROLL LOCK key. Just wasn't grasping it initially. I got it now.

With everything running, I figured out why Tim's interrupt code was not working in my setup and I am in the process of modifying the keyboard interrupt routine. Turns out, it was spending all it's time in the keyboard interrupt routine and not breaking out. MAME's debugger allowed me to figure that out while having the UDS-10 connected.

Tomorrow night, I will try and complete the modifications and see where that goes.

Is there a command line switch available so one can turn off the disk drive chatter sound? I know one can turn it off from the menu screen, but would be nice to have a command line option if one exists and/or were possible.

Also, would be nice if it were possible to run at maximum speed on floppy and hard drive access, such as a switch to turn off the real emulated speed of accessing the drives. It was just nice in the past to be able to assemble source code faster than the real hardware.

the floppy/hard disk speed is not adjustable; it's not because of waiting loops which could be turned off, but because of the timing of cells on the media which is defined precisely. No, sorry. If you want higher speed, you can possibly use the Horizon Ramdisk.

Also sorry to hear you want to turn off the drive sounds. We had that discussion several times, and personally I find it so helpful in so many cases that I really cannot imagine to do without, honestly. No kidding.

You can turn them off either by lowering the sound volume for the floppy sound, or by removing the samples directory.

The sounds are really helpful for me as I am currently working on the HX5102 emulation, and I need to know what it is doing, whether the motor is still running, the head is stepping etc. In fact, I had some master students do a project in which they were to create an Arduino-driven "floppy tester" which can be used (officially) to verify the function of the stepping motor and its timing constraints, but (unofficially) will allow me to record step sounds for different step rates so that the sounds will be hopefully improved (and most unofficially allows for playing floppy music).

I pulled up the option and saw where I could add a Horizon in a slot, however, I do not see any other information where I can point it to a file, etc. Does this use a DSK file, or some other file?

Just trying to figure out what kind of file I need to configure and where it would be stored, etc. Is there a "rom" that needs to be added to use it or something else?

Thanks for that information. I thought the floppy and hard drive access "speedup" would be an issue, but it did not hurt to ask.

As far as sound, the first few times hearing it, it was nice. I will check out the samples directory.

Beery

Beery,

I put this together a couple of years ago for Michael on setting up a HRD in MESS/MAME and posted it HERE it may help. At that time I was working on getting FuSiON to work on MESS and poked around enough to figure out how to setup the HRD.

Also, would be nice if it were possible to run at maximum speed on floppy and hard drive access, such as a switch to turn off the real emulated speed of accessing the drives. It was just nice in the past to be able to assemble source code faster than the real hardware.

Beery

Perhaps to Michael's chagrin, speed is now the only reason I still maintain an old version of MESS/MAME together with the newest version. The disk access speed is what drew me to the emulation platform in the beginning and is something I cannot shake from a development perspective, especially when assembling something like MDOS or PORT.

I pulled up the option and saw where I could add a Horizon in a slot, however, I do not see any other information where I can point it to a file, etc. Does this use a DSK file, or some other file? Just trying to figure out what kind of file I need to configure and where it would be stored, etc. Is there a "rom" that needs to be added to use it or something else?

To use the Horizon RAMdisk with MDOS and GPL as a natively supported drive, you must format it with FORM v1.23 or FORM3MEG, both written by J Schroeder. you must then also REMAP the drive to the appropriate slot, 1401 and 1601 being the most common for 16-bit addressable ramdisks. ROS will only work if you plan to use the RAMdisk in GPL with the ROMPAGE switch.

I assembled a set of source files. From hitting enter, loading GenASM and subsequently GenLINK on the ramdisk, then assembling the emulated source files on Horizon ramdisk, the whole process took 22 seconds.

With everything on the HFDC, the process was 60 seconds.

A couple of questions regarding MAME and the Horizon ramdisk. MAME indicates up to 16 MB while FORM3MEG formats out just over 8000 sectors. Is there someway to tap into that other memory that MAME allows to be configured? I have used a SETDSK 5N command. Just not aware if there is somewhere to tap into more memory or not I may not be aware.

If I understand all the MDOS changes, the Horizon ramdisk still only supports 3 directories with the same structure as floppies?

Thanks for the guidance everyone that jumped in with comments on the setup. Took some time searching for the docs for REMAP that was archived in a MDOSDOCS archive on the original MDOS650 distributable disk. Good job organizing everything all together Tim.

Thanks for adding that word to my vocabulary. Rare enough, but sometimes I have to pick my dictionary, and the (also stylistically) matching translation would be "Verdruss" in German.

Being a big boy, I'll get along with it. No, honestly, it's not a big issue, and you said you have a recent release in parallel. I'd just like to add some points that I find important to say:

In general, software is evolving, and features are added, removed, or fixed over time. Using an old release means that you deliberately stick to some past snapshot of the software. If you find issues, maybe instabilities, a missing feature that was later added, you could wish to have your particular release amended to your wishes. This may sound much easier than it actually is. Some features may have become obsolete by changes in the core, other may have become available just because the core was updated. Not only for open-source software but also for typical, commercial software, backporting is a difficult job, and in most cases it cannot be done, at least not with considerable efforts. These efforts multiply when people even have different past releases. It should therefore be understandable that on every encounter of an issue, my first question will be: Are you using the latest release?

A critical point is the data exchange. Formats have changed over time, and they may be unusable for one or the other release. Floppy formats like HFE were added, track dumps fixed, sector dumps did not change, hard disk formats have changed from sector dumps to CHDs of version 4, then version 5. Data processed on one release may be unreadable on a much older or newer release. For instance, you may be unable to use hard disk images in the old releases that have been recently created, and vice versa. Only the sector dump images of floppies remain for exchanging data. As I said in 1., I cannot backport these formats to the old release, mainly because they depend on other features in the core.

Most of us are writing software or creating hardware with no or little refund for the efforts, apart from the appreciation of others. It is not always clearly visible from the user perspective what has actually changed, so a user tends to evaluate it from his own view - what has improved for me? I'll not cite MAME's mission again, already sounding like a mantra ... I'd be happy if people remember it when there are changes that are not primarily improving their personal usage experience.

Concerning the floppy emulation, the primary objective was not to make it as slow as in reality. In fact, there are systems with quite sophisticated copy protections - we already talked about that. In particular, some systems measure the time between the index hole and a specific sector they are locating on the track - in milliseconds. One of the developers - not me - rewrote the floppy emulation and developed this highly precise system, which I consider one of the most brilliant parts of MAME. He even used a "time machine" which can travel back in time to synchronize events, at least on that current track. In consequence, the disk controller chips could be rewritten to allow for a precise emulation of their internal behavior with all state machines and so on. Hence, floppy systems run at their exact speeds, and cannot be sped up like before (unless you added a complete second path with stripped-down controllers, simplified data paths etc.).

The floppy sounds were only possible after the drives were ensured to run at real speeds, of course. It took me some weeks to write the support, and hours of recording samples of a floppy put into a cardboard box, together with a high-quality microphone. On Ninerpedia I reported about the difficulties to get a somewhat realistic output from these samples, since the first attempts were, let's say, not really satisfying (sucked completely). As I said elsewhere, I may now have a good chance to recreate the samples at different step rates in a quiet environment (without a running PEB). I'm not sure whether some people believe that the samples make the emulation slower, but this is clearly not the case; when you turn them off, they won't speed up, it's just quiet. Actually, I'm thinking about recording sound from my ST-512 MFM drive also. Maybe we can arrange that when time has come, the first response to me will not be "how can I turn them off?". This can be done the same way like turning off the floppy drive sounds. Talking about appreciation.

I wonder how much time you actually save by the untimed floppy access in the old releases, compared to the MFM drive connected to the HFDC in modern releases. I've been doing some development as well, and I never really felt uneasy during the assembling process - maybe because I expect the process to take exactly that time (I would feel bad if it was much faster, as I do now after learning that the v9938 emulation is significantly faster than on real iron.) Sometimes I believe this is similar to people sitting in their cars on a congested street, having a feeling like this should be going much faster, even when they are not heading for an appointment.

...

Consequences? I'll be continuing as before. Currently I'm sitting at the HX5102, and I already made it load a program on the 99/8 (internally), but it failed to send it over the Hexbus. I think it will not take too long until we can save Extended Basic II programs. On recent MAME releases, of course.

I wonder how much time you actually save by the untimed floppy access in the old releases, compared to the MFM drive connected to the HFDC in modern releases. I've been doing some development as well, and I never really felt uneasy during the assembling process - maybe because I expect the process to take exactly that time (I would feel bad if it was much faster, as I do now after learning that the v9938 emulation is significantly faster than on real iron.) Sometimes I believe this is similar to people sitting in their cars on a congested street, having a feeling like this should be going much faster, even when they are not heading for an appointment.

Alas, I am a bit of a 'speed freak'; the unlimited timing can assemble MDOS in a second or less. This is quite a feat considering it can take 15+ minutes on real hardware.

That said, I developed the MDOS 7.0 large RAMdisk support on/with the new MAME version, primarily because you have done so many enhancements like like adding Horizon RAMdisk support and PFM support. My current DSR investigation is intended to find ways to speed up the disk IO even further, so that using the real Geneve is faster. Not that I can cheat any of the physical timings or chip timings, mind you And much of that development is being done on the real Geneve these days. So I hope no one thinks I am promoting the old version, I was just pointing out the one reason I still use it. I suppose that after I convert the rest of my platters and data to the new formats, I can't/won't go back.

Oh, there is one thing I'm curious about. Could the debugger be modified to act like a network packet sniffer, that is, log all operations that are happening so that one can review them? I feel that if I had a "transactional log" (with some context like current WS, PC, etc) to see everything the computer did between breakpoints or from the point I start/stop logging, I could find bottlenecks or repeated routines much more easily.

Michael, you pretty much have me converted over to the latest version of MAME. About the only time I use MESS is when I am searching multiple disks looking for something. Just easier to navigate with the interface than what I have to do with MAME.

As far as the sounds, it was a great accomplishment. I am just lazy and do not want to turn my speaker volume down. My office area has a TV and I would prefer to be picking up audio from it rather than have sounds of the emulation compete. I did notice one thing on my system and I do not know what is going on. I was having intermittent lockups of the emulation with the Geneve after there had been disk access. When I renamed the sounds directory, it disappeared. I do not know if this is a "me-only" issue, or a symptom of something else. If nobody else is reporting it, it may just be me.

I don't want you to feel bad about this, and no one else, as a matter of fact. I hope my posting did not sound too negative. I just think we should keep in mind that for every software and hardware project that we see here on this forums, not only is there considerable effort behind the scene that may not immediately be visible, but there may also be objectives and long-term goals from the perspective of the author that differ from the user's view.