Jump to content
IGNORED

New MAME release


mizapf

Recommended Posts

Hi everyone, MAME release 0.180 is ready for download. No big changes, but probably this one may be interesting for you:

 

You can now use the state save feature of MAME to freeze the current state to one of nine slots, and restore it later. To save the state, press Shift-F7 in partial keyboard mode*, and type a number for the slot. To restore a saved state, press F7.

 

I tested the save feature for the TI-99/4A, Geneve, TI-99/8, and SGCPU, and it looks good. For the 99/8 there are still some rare occasions when the state restore does not work properly. Also, be careful not to save the state during disk operations; the disk state is not saved, so when you restore later, you will very likely corrupt your image. There is no problem for saving the state while a BASIC or machine program is running; it will continue right at that point.

 

You can start the machine and immediately load a saved state with the option "-state" and the slot number.

 

[*The default key to switch between the modes is ScrollLock.]

  • Like 13
Link to comment
Share on other sites

By the way, if you wonder why I did not update the release notes on Ninerpedia: I can't. I'm getting 403 Forbidden messages, and after some retries my current IP address becomes banned.

 

I already informed Rich Polivka. We're obviously suffering from false positives of Apache's ModSecurity; whenever I try to edit a page, and in the uploaded text there is a semicolon, followed by a word that happens to be a SQL command, that paranoid security module considers it a SQL injection attack. For instance, a text like "Several fixes; selectable speed" or "Interrupts now working; LOAD interrupt handler rewritten" or "This is a test; create a page like this" all lead to a 403 for me. It would be a ROFL if it were not that serious.

Link to comment
Share on other sites

  • 5 months later...

Dear friends,

 

another MAME release has become available: 0.186. As I said, I won't announce every release, since you may have heard already that there is always a new release on last Wednesday of a month.

 

However, this time there is an important change with the configuration parameters of the TI-99/4, 4A, and 8. The Peripheral Expansion Box (PEB) has turned into a "slot option", that is, it will have to plugged into a new slot named "ioport". This is indeed what you see with the real iron. With this change, you have to add "ioport" as a prefix to all cards that are plugged into the PEB, or you will get an error message on start. So I recommend that you update your starter scripts or the configuration in QMC2 with this new release.

 

 

mame64 ti99_4a -ioport peb -ioport:peb:slot3 speech -ioport:peb:slot8 hfdc

 

This change does not affect the Geneve 9640 and the SGCPU (inofficially called TI-99/4P) because these systems have no console outside of the PEB, but the flex cable interface card of the TI-99/4A is replaced by their respective system boards. Accordingly, there is nothing where the PEB would be plugged into.

 

The ti99_4ev driver (which is a TI-99/4A console without video processor and with a modified GROM 1) will have the PEB as default option for the I/O port, and the EVPC card will be inserted by default in slot 2. I decided to go this way because otherwise you will get no output at all, since the ti99_4ev driver has no VDP. Still, all further devices need the "ioport" prefix.

 

The good news is that this is a one-time change in your start scripts, or in QMC2, and once done it will not bother you anymore.

 

So what is the reason for this slightly disruptive change?

 

1. From an architectural point of view, the PEB emulation was somewhat inconsistent with the rest of the machine. It was modeled as a subdevice, just like the CPU or the sound chip, while the cartridge port and the joystick port were already proper slot devices which allow for plugging in a device from a specific collection.

2. There is more than the PEB which may go into the I/O port - consider games like Arcturus. Currently, we can only use a modified version that runs as a normal cartridge, but this is different to the real iron.

 

3. There is a whole bunch of "sidecar" peripherals, which are plugged into the I/O port as a daisy chain. To be able to emulate them some day, we need the I/O port available as a slot device.

 

4. As you may know, I am currently working on the Hexbus emulation that shall eventually be available for the existing emulations of the TI-99/8, /2, CC40, and TI-74 Basicalc. However, as with the TI-99/4A, the PEB is currently a hard-coded subdevice of the TI-99/8, and I'd like to get rid of this artifact, not only because the intended peripheral concept is Hexbus for the 99/8 but also because the PEB is just burning performance in the emulation without any benefit. Still, the 99/8 emulation has an I/O port (which differs from the one of the 99/4A, by the way), so the PEB may be attached if desired.

 

5. Finally, my working queue still contains the emulation of further prototype systems, particularly the "TI-99/4B" and "TI-99/5", as described on Fabrice's website. Both system do not even have an I/O port, so you cannot attach a PEB to it; they are Hexbus-only systems.

 

If those reasons are still not convincing enough, let me just add that now the way is clear for the Hexbus emulation.

 

If you are interested what happened in MAME outside of the TI-99 family, here are the official release notes from the MAME forum: http://forums.bannister.org/ubbthreads.php?ubb=showflat&Number=109718

  • Like 9
Link to comment
Share on other sites

I certainly appreciate all of your effort but this does look like additional complication from a usability perspective. I never really understood the earlier need for the SLOT requirement given that the PEB backplane is all interconnected and slots have little relevance to how the PEB operates. To me, it seems that a peripheral could be defined simply as that - a peripheral - regardless of what slot or interface is in use. For example, ioport:<peripheral>, e.g., ioport:flexcable; ioport:HFDC or ioport:arcturus.

 

Anyway, I am sure those of us who use MAME will adapt. All I ask is this: please do not make us "plug in" the various logic chips and processors for future cards and system choices. ;)

Link to comment
Share on other sites

Hi Tim,

 

you're taking the point of view of the user, obviously :) . Admittedly, many changes in MAME of the last years had a bigger impact "to the inside" than to what the user may be able to observe. However, some of these changes prepare evolutions that may be impossible without.

 

The "slots" in MAME are an abstract extension concept; it need not be a slot but something that allows another component to be connected. For example, the joystick port is implemented as a slot in MAME, and its possibly options are the joystick, the 99/4 handset (only for the 99/4), and the Mechatronics mouse.

 

With an ever increasing collection of emulated components, a reasonable structural concept becomes important. The early MAME releases, particularly the pre-0.100 releases which you once admitted still to be in use, were one big mess of code, where parts were turned on and off by switches. So you can carry on to glue more stuff to the big blob, or you can try to go for a component-oriented way.

 

Remember that the MAME vision is not to provide something that feels like the real thing, but to mirror the hardware by software as far as possible and hope that it turns out to work as desired. "Less code is better", being one of the mission statements. I'm still not really close to that one, but in some cases, my code barely does more than just propagate signals to other components, as the PEB emulation does. Maybe one day, those propagations just need to be declared, and not programmed anymore. But you need not be afraid that one day I would require you to plug together your main board from scratch - this would certainly be against the intentions of MAME. :)

 

My vision for the future is that we will get to a better user interface via the integrated Lua script system, maybe with a GUI that allows you to plug together your system as desired. For this to become possible, we need to have well-designed components with clean interfaces.

 

One thing you all can be sure of: Me, I'm using the TI emulations in MAME pretty often; sometimes for playing, but also all of my programming works were done in the emulation and not on the real iron, but later transfered there, and run. And, of course, all these ongoing works require me to work with MAME nearly every day. I certainly won't let it become awkward for me to use it.

Edited by mizapf
  • Like 3
Link to comment
Share on other sites

I may have missed something important in here. Did I interpret this correctly to say that 99/2 emulation is working?

 

Ähm ... no. :)

 

Partly, the video chip is still not properly emulated, it lacks the "stop code" feature. You know the problem where you have a dozen open issues and just cannot decide which one to take next? Because each one has a potential to tie you up for weeks... :)

Link to comment
Share on other sites

 

 

you're taking the point of view of the user, obviously :) . Admittedly, many changes in MAME of the last years had a bigger impact "to the inside" than to what the user may be able to observe. However, some of these changes prepare evolutions that may be impossible without.

 

Indeed, a user :) It has been fun watching how you are evolving the emulation of these multiple systems and it seems you have a plan of attack thought out, particularly for the components and future interfacing. The emulation has come a long way since Ralph first implemented a working Geneve in MESS.

  • Like 2
Link to comment
Share on other sites

I just wonder how TI-99/4A / Geneve and such are emulated in MESS compared to other emulators. Is new hardware like F18A supported? And I also wonder why standalone emulators are still successful.

 

I also see MAME/MESS (do we call it MESS or MAME now? Since the both got merged and it's just a matter of compiling options) to be messy to use for the average user. I hope the new Lua GUI improves at this.

Link to comment
Share on other sites

Yeah honestly I still use mame32 for its simplicity. I haven't used mess in a while. I was going to use the new combo version recently but quickly became confused as it seemed very complicated combined when compared to when they were separate. That's just me though, not knocking it. I'm also concerned about my Rom images (mame) not working well in the new version.

Edited by Sinphaltimus
Link to comment
Share on other sites

@timofonic: Emulators are difficult to compare because you need some scale on which you evaluate them. You have points like ease-of-use, which is extremely subjective. For instance, people keep telling legends about the difficulties of running MAME, while I (in my view as one of the contributors, certainly biased) can't really imagine how it could become even easier. Then there are aspects like completeness, precision, expandability, stability, and so on. Setting up some overall judgement like better or worse is likely to become misleading or unfair.

 

As for the F18A, this will not become available in MAME. The reason is that MAME's goal is to emulate the hardware, not the function, and this would mean to emulate an FPGA at 100 MHz, which is unfeasible with the current computer power. Unless there are substantial improvements in the architecture and possibly some magic, there is no way, in my view.

 

The emulator is called MAME, with MESS only referring to a subset of emulated systems. Since you can pick the systems to be included in your binary, it does not make sense to specify some arbitrary subparts by an own name. Thus, MAME is the recommended reference.

 

Concerning the purported "messy" use, it is simply a matter of understanding the overall concept. After that, there is actually nothing to be called "messy". The arguably biggest hurdle is the initial setup, and the fact that you have to download the ROMs because they cannot be distributed with MAME. But since we set up a collection of ROMs on the Whtech server, this just means to download everything from there and dropping it into the respective folder.

 

I would like to emphasize that I am always here for answering questions about MAME. It rarely pays off to wildly guess what to do; in most cases I can clarify this with a few words.

  • Like 4
Link to comment
Share on other sites

@Sinphaltimus: I don't know what release is mame32, this most likely refers to the 32bit version.

 

I understand that you hesitate with upgrading, but there is no proper reason for that. It has not become more difficult, compared to the former MESS, apart from the fact that you have to start a different program name.

 

May I point out that you can always run different MAME releases next to each other; just create a different folder and throw everything into it. MAME has no system-wide variables and does not change anything in your registry. Uninstalling means to simply delete the folder.

 

I often hear people saying they prefer to stay with the old versions, maybe in fear of risking their configuration, which is pretty unlikely, as I just said. If you take my view for a second, with my 10 years contribution to MAME, you see why I'd rather wish people to be a bit more courageous, and if it's just to have a look at the new achievements.

 

Again, as I said: You cannot break anything when you install MAME in its own folder. You can keep your working setup. Mind that the ROMs on Whtech expect newer MAME versions, so you just keep your old ones and retrieve them again from there.

Link to comment
Share on other sites

@Sinphaltimus: I don't know what release is mame32, this most likely refers to the 32bit version.

 

I understand that you hesitate with upgrading, but there is no proper reason for that. It has not become more difficult, compared to the former MESS, apart from the fact that you have to start a different program name.

 

May I point out that you can always run different MAME releases next to each other; just create a different folder and throw everything into it. MAME has no system-wide variables and does not change anything in your registry. Uninstalling means to simply delete the folder.

 

I often hear people saying they prefer to stay with the old versions, maybe in fear of risking their configuration, which is pretty unlikely, as I just said. If you take my view for a second, with my 10 years contribution to MAME, you see why I'd rather wish people to be a bit more courageous, and if it's just to have a look at the new achievements.

 

Again, as I said: You cannot break anything when you install MAME in its own folder. You can keep your working setup. Mind that the ROMs on Whtech expect newer MAME versions, so you just keep your old ones and retrieve them again from there.

 

mame32 is the old "windows gui" version of mame that includes a user interface that's a lot easier for the average user to use I believe its called mameui now

 

Greg

  • Like 1
Link to comment
Share on other sites

Maybe I will. I never used Mess for TI. Just every other old computer I had that I couldn't find a separate emulator for back in the day. I use the old mame32.exe for my arcade machine.

 

Ah, you're using MAME for the arcade cabinets. I thought you also used MAME for the TI emulation. If you're happy with the old MAME in those arcade machines, well, then you may not have a need for upgrade. My comments particularly address the TI emulation in MAME where I added lots of features in the last years.

  • Like 2
Link to comment
Share on other sites

mame32 is the old "windows gui" version of mame that includes a user interface that's a lot easier for the average user to use I believe its called mameui now

 

I see. But again, there's the question - do I prefer a simple user interface with an old version, or a more advanced emulation core with lots of new features, but with a worse UI?

 

Interestingly, I rarely use the UI in MAME. I suppose it is mostly used to switch cartridges or floppy disks, but usually I quit the emulation and start again with another cartridge or floppy image, or I'm using the hard disk emulation right away. But this may be related to my heavy use of the console in Linux for starting MAME, which seems to be less popular in Windows.

  • Like 1
Link to comment
Share on other sites

The old Mame UI makes it super easy for friends at parties to change games. Press escape on the detachable KB and you're brought to a menu listed all working games and my personal favorites. Use the trackball as a mouse to double click the next game you want to play. I have at least 2 parties a year where this is of particular concern. Last thing I need is "Hey, can you come over here and load up.....etc..." :) Especially 2 sheets to the wind...

Edited by Sinphaltimus
Link to comment
Share on other sites

Old timers will get sick of me saying it (assuming they aren't already), but I actually still like QMC2 as a front end. Although, interestingly, they're still at version 183 (several releases back, they brought up the version number so it had parity with that of MAME itself). I WILL, however, drop to the command line anytime something doesn't seem to work. The QMC front end does a bad job of passing along errors (missing ROM/BIOS, config problems, etc.). But of course, it gives me the command line in its front end log window so it's easy to copy-and-paste that into a terminal window.

 

I have numerous configs saved for the 4A. E.g. one for straight-up game cartridges. Another for TE2 speech stuff (giving me the speech synth, TE2 cart, a disk system, etc.). Another for TOD (with the cartridge and a disk of TOD games at the ready). Although changing carts and disks is pretty danged easy from the command line, and I know I could save scripts to do the same thing. All down to preference, I suppose.

Link to comment
Share on other sites

i've used both CLI and GUI, and it always seemed easier if you have a kiosk-style machine to have the GUI with a few shortcuts setup. :)

 

that being said, i could see the definite advantage now with manually loading stuff from the command line.

 

I have a few batch files that I use that will load up different configurations. Makes it alot easier to do than typing the damn line out. I do this for running my BBS on a Geneve system via MAME/MESS.

Link to comment
Share on other sites

  • 4 months 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.

Thanks Michael, I was trying to get it running over the weekend, but didn't spend much time on it. To little time, a lot to do. :(

Link to comment
Share on other sites

Phew ... I just managed to emulate that part of OSO (the Hexbus controller inside the 99/8). Now that really gave me headaches. If you think you are good at following signal lines, try that one.

 

(To verify it, I used the free tool Logisim (http://www.cburch.com/logisim/ ) and added lots of log outputs in my MAME code, checking whether every clock tick changed the states as expected.)

post-35000-0-83148900-1509489351_thumb.png

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