Jump to content
IGNORED

New MAME release


mizapf

Recommended Posts

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

  • Like 1
Link to comment
Share on other sites

  • 4 weeks later...

As we had this topic recently, I put together a short recipe to get MAME running. We had a new release last week, 0.191.

 

https://www.ninerpedia.org/wiki/Installing_MAME_on_Windows

 

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.

 

Beery

Link to comment
Share on other sites

Everything on Ninerpedia referring to MESS also applies to MAME. I have to update that description, right.

 

I could add some lines concerning the conversion; they were not needed until now because most people already converted their images, or started later.

Link to comment
Share on other sites

  • 1 month later...

Michael,

 

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.

​I am sure there is an obvious workaround? Just haven't found it yet.

 

Beery

Link to comment
Share on other sites

Hello Beery,

 

as with many bits of interesting information about MAME, Ninerpedia is a good resource: https://www.ninerpedia.org/wiki/Change_MESS_menu_mode_key

 

:)

 

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.

 

Beery

  • Like 2
Link to comment
Share on other sites

  • 1 month later...

Michael,

 

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.

 

Beery

Link to comment
Share on other sites

Hi Beery,

 

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

As for the Horizon, you need to install a ROS.

 

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

  • Like 1
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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 do use the latest version, just not for code writing).

 

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

OK, I got it to work.

 

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.

 

 

Beery

Link to comment
Share on other sites

Perhaps to Michael's chagrin

 

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

  • Like 3
Link to comment
Share on other sites

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.

Edited by InsaneMultitasker
Link to comment
Share on other sites

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.

 

Beery

Link to comment
Share on other sites

Tim, Beery,

 

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.

  • Like 2
Link to comment
Share on other sites

  • 2 weeks later...

This is Good Friday, but also in another sense, that is, a really good friday. I may report some great success - after almost two years, and after some busy weeks right now.

 

I guess you'd better watch my video. You should carefully watch (and listen).

 

 

In the meantime, I'm going to dance in circles in my room.

 

Unfortunately, the recent MAME release has just been issued last Wednesday, so we have to wait another month, but I have still some work to do, removing debug output and so on.

 

 

./mame64 ti99_8 -hexbus hx5102 -flop1 disks/tests/ti998.dsk
  • Like 10
Link to comment
Share on other sites

 

This is Good Friday, but also in another sense, that is, a really good friday. I may report some great success - after almost two years, and after some busy weeks right now.

 

I guess you'd better watch my video. You should carefully watch (and listen).

 

 

In the meantime, I'm going to dance in circles in my room.

 

Unfortunately, the recent MAME release has just been issued last Wednesday, so we have to wait another month, but I have still some work to do, removing debug output and so on.

./mame64 ti99_8 -hexbus hx5102 -flop1 disks/tests/ti998.dsk

 

Awesome!

 

giphy.gif

Link to comment
Share on other sites

wow, that is some milestone! you really got it working!
congratulations to you and to the community :)

 

next things to check for how it behaves when you try:

- OLD/SAVE DSK.DSKNAME.PRGNAME

- OLD/SAVE HEXBUS.101.PRGNAME

- OLD/SAVE HEXBUS.100.DSKNAME.PRGNAME

 

Klaus

Link to comment
Share on other sites

next things to check for how it behaves when you try:

- OLD/SAVE DSK.DSKNAME.PRGNAME

- OLD/SAVE HEXBUS.101.PRGNAME

- OLD/SAVE HEXBUS.100.DSKNAME.PRGNAME

 

Works as expected! (I did not record a new video; I suppose you believe it. :-) )

 

The DSKNAME must match the volume name, otherwise you get an IO error 07. The only unexpected thing I noticed is that it does not issue an error for DSK2 and DSK3; just treats it like the same drive DSK1. The same is true for HEXBUS.102 and HEXBUS.103.

  • Like 1
Link to comment
Share on other sites

It was indeed an important step that was worth the efforts, as I believe.

 

  • It is the first time that I saw Extended Basic II running non-trivial BASIC programs (i.e. more than a loop or PRINT "HELLO"). Up to now, we did not have a floppy support for the TI-99/8 in MAME, because Extended Basic II assumes that the PAB may be put in CPU RAM, and the floppy controller cards in the PEB expect it in VRAM, and this is not caught properly, leading to a crash on entering.
  • With the Hexbus floppy we can now write and exchange programs (as long as we keep using DSSD; the DSDD format is not compatible with the existing floppy controllers, using 16 sectors per track instead of 18). This will be very helpful for people with a real 99/8.
  • This also proves that the Hexbus implementation seems to work so far; I did not have a chance to validate some specific functions like service requests, though. This is good news for the people using emulations of the CC-40 and the TI-74 because we can now also emulate the Wafertape or Hexbus printer. And in principle, it should be possible to save and load from the HX5102 for these devices as well.
  • We can now carry on with the emulation of the 99/4B and 99/5, which depend on Hexbus. Also, the 99/2 should profit from that.
  • You always feel good when an item on your todo list is checked, in particular, when it's been there for many years.

It was also this Hexbus development that gave the final reason for changing the external device handling for the TI-99/4A console. As you noticed, some time ago I changed the PEB handling; from then on you had to explicitly "plug in" the PEB in the emulation (-ioport peb), whereas it was connected and not removable in earlier versions. This allowed me to remove the PEB from the emulated 99/8 console, where it is less useful anyway. Additionally, the PEB decreases the emulation performance, which is critical for the 99/8. Moreover, the other consoles (99/4B and 99/5) do not use a PEB, and we have games that connect to the ioport (like Arcturus). These can now be emulated in their original form.

 

The Hexbus emulation turned out to be much harder than expected. When I found out that we already have the i8272A disk controller chip, I first believed this should be a matter of days, but I needed about four weeks more. The problem was that this was the first time that I had to handle a multiprocessor setup: the 9995 in the 99/8 console, and the 9995 in the Hexbus floppy drive. In the 99/8 console, the "Oso" chip is a multi-functional device that has a simple interface to the CPU: Write a byte to it, and it will autonomously transfer the byte via the Hexbus; likewise, it receives bytes and sets a flag when reception is done, so you can pick up the byte via a port address - no bothering with the Hexbus protocol.

 

The Oso chip is therefore clocked by CLKOUT and has internal states that advance on each clock tick. In reality, this is a good solution, and it proved to work: In particular, you had a guarantee that between two CLKOUT ticks on the floppy side, there is one tick on the Oso side. Or, in other words, when the floppy side performs some action, the Oso side is able to follow and advanced its internal state.

 

However, MAME cannot emulate that. The concept in MAME is that between two events (like video interrupts), every executing device (like a CPU) is allowed to run a certain amount of cycles. That means, if an event is due in about 33.3 ms time, the CPU is allowed to perform 100 cycles (with 333 ns each), which mean a certain number of instructions. There is no guarantee that all executing devices advance at the same time. What happened now is that the floppy CPU had its turn and attempted to send the bytes of the loaded sectors via the Hexbus, pulling down the handshake line as expected. In reality, the Oso chip would sense this change, since there is certainly a clock tick before the floppy CPU is able to do its next instruction. It would sense this handshake signal, pull down the line by itself, and thus signal to the floppy CPU that it shall wait until the byte has been picked up by the DSR. Then it would release the handshake line again.

 

What happened in MAME was that the floppy sent the byte, pulled down the handshake, lifted the handshake, sampled it, and found it up again (interpreting this as Oso having delivered the byte), then sent the next byte, and so on. Then, the MAME core passed control to the Oso side, which has missed a lot of bytes in the meantime.

 

My solution was to trigger "fake ticks" on the Oso side whenever the handshake was pulled down by the peripheral device. This was not the final solution, though, because this fake tick advanced Oso, which pulled down the line as expected, but which caused a change on the floppy side again, which lifted the line, which was sensed by Oso again, which caused another fake tick inside the current fake tick, and so on. It was not so much a problem of recursion, but the Hexbus is a concurrent bus that defines its current state by logically and-ing all values for all participants; when you write a byte, you have to check which levels you actually have and possibly feed them back to the state machine. When you have a nested tick, you will possibly overwrite your detected values.

 

In the end I was finally able to master these issues, introducing some more functions to sense line levels, and avoiding these nested ticks. The last issue was that some flag inside Oso was not cleared in time before the next transmission of the floppy began, so I cheated a bit more and cleared that flag directly with the handshake operation. And then the floppy loaded. Yes. And it saved - which meant no further issues were left. This is when you just cannot believe what you see.

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