Jump to content
IGNORED

New MAME release


mizapf

Recommended Posts

Nope. The newer versions of the TI emulation support more games. If there is an issue please report it to me.

 

(I don't want to repeat my sermon about not keeping the old releases, but the longer you stay back, the more painful it will become to catch up at some time, which will come.)

 

With MAME, it always comes down to what release can you afford to run, I find. Current versions want current hardware. If your target system is a midrange Kaby Lake machine with 16GB of RAM and NV GTX 960 or ATI RX 480 graphics or better, … I don't have those specs on my primary workstation! A lot of people run mame on a secondary machine with specs like my i5-4460 with 12GB and a GTX 780—that's my primary workstation. I've also got an i7-3770 with 16GB and some low-end LOLworthy ATI caicos card. These aren't systems made to run any version of MAME probably since analog audio emulation.

 

I'm sure it's quite impressive, but my hardware suggests I should probably be running 165 or so maybe? I dunno, despite claims I was supposedly "working with mame devs to undermine libretro" or whatever, since I divorced that dumpster fire I haven't kept up with MAME much at all. Kinda want to try and figure out the magic incantation I've now forgotten for getting OpenEmu to start up retrocomputer systems with its version of MAME (which admittedly is out of date as well), but as I said it's been awhile since I've played with MAME.

Link to comment
Share on other sites

With evolving systems like MAME, don't trust your past experiences. I've been running MAME without problems on a 2012 laptop. You may bring it to its limits with the 99/8 emulation, which is the most demanding emulation due to its complicated architecture, but the other systems, particularly the 99/4A should have enough reserves.

Link to comment
Share on other sites

There was some talk around that time period of trying to convince some folks that there might be advantage to a couple of tiers of emulation to make things both more usable for people with less than top shelf hardware and still proceed with building the most accurate recreation possible under the assumption that at some point that will become the lower performance tier as hardware continues to improve.

Link to comment
Share on other sites

Last Wednesday of June, new MAME release (0.199).

 

Some interesting points for the TI family:

  • The Geneve boot EPROMs can now be selected in the OSD under "BIOS selection", or on the command line with the option "-bios x.xx". (Sorry for the name BIOS, I'd prefer "roms", but the other wanted to have it that way.) The default is "0.98".

 

mame64 geneve -bios 1.00 ...
  • The selection of BIOSes made it reasonable to split the Genmod from the Geneve, in particular to avoid using the wrong rom. Genmod is now a separate driver. For your current ROM zips, nothing should change as long as you do not use Genmod. If so, you have to unpack the geneve.zip and pack the gnmbt100.bin inside into a separate zip file "genmod.zip".

 

mame64 genmod ...

 

  • The HX5102 (Hexbus floppy drive) can now correctly handle double density. However, this currently only works for HFE images, not for DSK. This is not a big issue; will be available until next release.

The double density issue was quite a hunt; I tracked it down by analysing the HX5102 roms and the behavior as visible in the MAME logs. As I saw, the error was in the implementation of the floppy controller chip (i8272A) from another dev. The problem was that he interpreted the specs in a way that when no address marks can be read from a track, the status flags MA (Missing address mark) and ND (No data) must be set. In the ROM of the HX5102, the ND flag is tested first, and it obviously leads the code to decide that there are address marks, but the sector is not contained in that track. As a consequence, the HX5102 starts with single density, finds no mark (as the disk is DD), the controller sets both flags, the ROM thinks that it could find those marks, but not the sector, so it retries several times and gives up. Had it decided that there were no address marks, then it would have switched to double density and retried. Once I fixed that, the disk could be loaded. As always with MAME, you have to wonder whether you broke other emulations by that change, but if it the behavior complies with reality, this should actually not happen.

 

No updates for 99/2 this time.

  • Like 3
Link to comment
Share on other sites

  • 4 weeks later...

Just to let you know, today, MAME 0.200 has been released. The most exciting news about this is that it is a hundreds number, but since I had a lot of real-world things to do, there are no changes for the TI parts. I'm still working on the 16-sector support, and I was somewhat surprised to see that in this month, the last Wednesday is 6 days before the end of the month (and feature freeze was one week ago on July 18).

  • Like 1
Link to comment
Share on other sites

How does the newest release of Mame handle roms from around 2012. I run mame32 (back when MAME and MESS were 2 different products) and it works fine for me - my roms are from back in those days as well. I never upgraded because of two things - first "if it aint broke don't fix it" and second, I cannot take the time or effort to update all of my existing roms.

However, if the newest version of mame runs a lot better than the older versions and supports much older roms. I may be inclined to look at it. So I thought I'd inquire with those that are "in the know" first.

Link to comment
Share on other sites

However, if the newest version of mame runs a lot better than the older versions

 

Depends on what you consider "good". On https://www.ninerpedia.org/wiki/MAME_version_historyyou can always watch the progress; I don't want to copy the stuff again.

 

There are more things to come, of course.

 

There is no reason to *only* keep an old release. You can keep any earlier release, but, repeating myself, you can always install the recent MAME in parallel. I noticed this fear of updating from different people, and it really puzzles me. I mean, you let your Windows updater keep your installation up-to-date, so this is not so different.

 

So well, you could say the 2012 release is sufficient for you, but then you cannot try the 99/2, for example. Or the Geneve with PFM. Or the 99/8. Or if you have a Lotharek, you cannot read its images in the old release. You can always say you don't need this, but why not? Isn't it all about exploring?

  • Like 2
Link to comment
Share on other sites

 

You can always say you don't need this, but why not? Isn't it all about exploring?

Well, I never used mame for anything besides the arcade roms. I used to run mess for a little bit to check out some old computers but I often opted to use individual emulators for each hardware. MAME was the only game in town for original arcade roms tho'. That's really it. I've read a very long time ago about rom versions working in newer versions of mame so instead of worrying about it I just used what worked for what I wanted. I still run a windows 98 and multiple windows XP computers without ever updating them for the sake of older software that doesn't work in Windows 10. But that's just me I supposed.

Link to comment
Share on other sites

  • 2 weeks later...

Good news for next release (Aug 29): I was able to fix the remaining problems with the Hexbus system. This is a good step forward in many respects:

 

1. You can now format disks inside the 99/8 emulation:

 

 

TI EXTENDED BASIC II Ready
62457 Bytes free
> OPEN #1:"HEXBUS.FORMAT MEDIA.101"
>

 

This will format the disk in drive 1 as double sided, double density, 16 sectors. I don't know whether there is a way to select a different format. The blank between FORMAT and MEDIA is required. This function is documented in the 99/8 Basic manual.

 

Other than in the last release, all disk formats now support 16 sectors/track: DSK (sector dumps), DTK (track dumps), HFE (Lotharek/GoTek). It was a bit more difficult than expected, since I had a lot of hardcoded 9-or-18 code and had to add a handling for 16 sectors. I took the opportunity and rewrote the disk image handlers. If you did not notice, none of the DTK (pc99) images written by MAME were actually accepted by PC99 again. I checked the format with DSKCHECK and got errors: PC99 does not use real CRC values but simply writes F7F7 into the CRC fields. I thought that it would be acceptible to write real CRC values, but this is not accepted by dskcheck. This is now fixed. (Mind that the 16-sector DTK format is the only one not accepted by PC99.)

 

2. Moreover, you can now change densities when formatting. In Pascal there is a formatting function where you can choose between single or double density. I noticed that when the density changed, formatting failed; a second attempt would then correctly format the disk. The issue was inside the i8272A controller; it was not guarded against unexpected writes. I am not sure whether this fix will persist; it depends whether this change is working for all drivers using that disk controller. (Always a problem for developers in MAME: You can check in a fix you have been working for a week, but you cannot be sure that someone else reverts it again, claiming that his driver now fails.)

 

3. Even better: I was able to fix the Hexbus for the 99/2. You can now save and load programs. Yes! (Cassette is still not working, but on secondary priority.) This only works for the 32K version. Interestingly, the BASIC programs of the 99/2 are compatible with the other Basics, as long as you use the common commands. Note that DSKx is unknown for the 99/2.

 

 

   TI-99/2 BASIC READY
>OLD HEXBUS.101.SOMEFILE
  • Like 8
Link to comment
Share on other sites

Impossible ... just cannot believe it: The cassette loading of the TI-99/2 is working now. I've been researching on it for the last three days, and a SINGLE typo was the culprit! (Only 32K version, loading still fails for the 24K version.)

 

The error was in the TMS9995 implementation. I could not believe it, since the 9995 is now running in this fashion for 5 years or so, without problems. You just don't expect a problem there. So I analysed the assembly code of the cassette routine, understood that cassette operation is FM-encoded (single density, like on disk), and that the 99/2 is extensively using the decrementer of the 9995. This is an internal register mapped at FFFA that can be set at some unsigned 16-bit value and trigger a level-3 interrupt when reaching 0. The 99/2 must use it because it does not have a 9901. Many other systems, like Tomy Tutor, also make use of that feature.

 

I tended to believe that there was a bug in the assembly code of this 99/2 prototype. There are some questionable portions of code, but they seem to be working. Since I understood more and more of the code, I started to consider that I need a deeper look inside. This is a piece of code that seemed a bit odd to me (comments by me):

 

 

3BA0:     CLR  *R6                      Set decrementer to 0
3BA2:     DEC  *R6                      Set to FFFF
Wait for the next edge
3BA4:     TB   0                       
3BA6:     X    R8                       JNE >3BAC / JEQ >3BAC
3BA8:     XOR  R13,R8                   edge found
3BAA:     JMP  >3BC0                   
3BAC:     MOVB *R6,R7                  
3BAE:     JLT  >3BA4

 

This is a loop that should only be left when an edge in the cassette signal occurs (+1/-1, -1/+1). Otherwise, it stays in the loop until the decrementer reaches 0. Actually, this is bad style. The specs say that the decrementer should only be accessed as a full word (but concedes that reading should not be a problem). The MOVB should better be a MOV; since this is all on-chip, MOV and MOVB are equally fast. R6 is set to FFFA, by the way.

 

However, I noticed that the loop is left much too early, after some dozens of cycles. The values were still above FF00, so the JLT should still send the CPU back to 3BA4, but it did not, and so it became clear it was a glitch in the 9995.

 

My log output said:

 

 

[:maincpu] i3ba6
[:maincpu] dec=ff7a
[:maincpu] i3bac
[:maincpu] read dec=ff7a
[:maincpu] dec=ff79
[:maincpu] ST = c602 (val=7a00)
[:maincpu] dec=ff78
[:maincpu] i3bae
[:maincpu] dec=ff77
[:maincpu] i3bb0

 

(prefixed i means that these lines are executed after an interrupt, so i3ba6 means we're in line 3BA6). It reads the decrementer and sets the status register to C602, which is wrong! It means that FF7A should be arithmetically greater than 0, which is wrong. But the reason can be seen in the parentheses behind: The value used for comparison was 7A, not FF.

 

So I checked tms9995.cpp:

 

 

if ((m_address & 0xfffe)==0xfffa && !m_mp9537)
{
  LOGMASKED(LOG_DEC, "read dec=%04x\n", m_decrementer_value);
  // Decrementer mapped into the address space
  m_current_value = m_decrementer_value;
  if (m_byteop)
  {
   if ((m_address & 1)!=1) m_current_value <<= 8;
   m_current_value &= 0xff00;
  }
  pulse_clock(1);
  return;
}

 

This part is only active when the decrementer is accessed; it does not apply for other locations. Do you see the error? The flag m_byteop is set when we have a byte operation (like MOVB). I wanted to write: If you access FFFB, return the low byte. But in this case, the !=1 is the wrong choice!

 

When I changed that line, OLD CS1 worked!

 

Why could that typo remain all these years unnoticed? Because it only shows up when the decrementer is accessed by MOVB, and you should not do that.

 

It is clear that an error in the implementation usually has some effect, but as you see, it is completely unpredictable when and how it becomes obvious.

  • Like 9
Link to comment
Share on other sites

I hope that these stories are not too uninteresting for some of you; some points really require indepth knowledge. Still, this kind of error tracking is really like a detective story, and there is a Heureka moment at its end. Just a day ago, I almost decided to drop that path and to assume that there is a bug in the TI-99/2 operating system, so there would be nothing that could be fixed. And at the end it's just a == vs. !=.

 

This is also scary. It is an error that cannot be found automatically. It is syntactically valid code, and it has a specific, reproducible effect. Its effect could be intended, and only by comparing with the specifications, you notice that it is wrong.

 

Again, a very good and true XKCD comic: https://www.xkcd.com/2030/

  • Like 3
Link to comment
Share on other sites

I hope that these stories are not too uninteresting for some of you; some points really require indepth knowledge. Still, this kind of error tracking is really like a detective story, and there is a Heureka moment at its end. Just a day ago, I almost decided to drop that path and to assume that there is a bug in the TI-99/2 operating system, so there would be nothing that could be fixed. And at the end it's just a == vs. !=.

 

This is also scary. It is an error that cannot be found automatically. It is syntactically valid code, and it has a specific, reproducible effect. Its effect could be intended, and only by comparing with the specifications, you notice that it is wrong.

 

Again, a very good and true XKCD comic: https://www.xkcd.com/2030/

 

Please keep them coming! It's amazing work and I personally appreciate all of the effort you put in to emulate these beasts :)

Link to comment
Share on other sites

  • 2 weeks later...
  • 2 weeks later...

Hi there, another month is over, and we have MAME 0.201. You won't be surprised too much by the changes in this release, since I already mentioned them in this thread. Let me summarize:

  • All disk formats (DSK, DTK, HFE) now have a 16 sector/track variant. This required me to add new valid file sizes (320K) for the sector dump format, and also a new PC99-like track dump format that uses 16 sectors/track (which will not be accepted by PC99, but was necessary). HFE could already work with this sector count, since it is a low-level format.
  • The HX5102 Hexbus floppy drive now works with the TI-99/2 (32K). You have to use the device name "HEXBUS.101"; there is no "DSK1". A nice discovery is that the TI-99 BASIC programs are compatible with the TI-99/2 (as long as you use the common subset of BASIC). With this floppy support, we can now explore the TI-99/2 a bit further, and this will also be interesting for those of you who have a real 99/2.
  • When you use the HX5102 with the 99/8, you can actually format disks without a Disk Manager, because the DSR contains a formatting routine. This is not a MAME achievement, of course. But now we can format disks in this way in MAME's emulation of the 99/8. I fixed a problem which occured when you changed the recording format from FM to MFM or back (that is, when you reformatted the disk from single to double density). The reason was a glitch in the disk controller chip emulation that was not written by me. Now with a stable, working floppy emulation on the 99/8, we have the full potential to try old programs and write new ones. I think that is good news, in particular because the 99/8 emulation is already there since 10 years, but due to the lack of a supported disk system, we could not really make use of it until now.
  • I fixed a problem with the track dump format (aka PC99 format). I assumed that I could write the real CRC values in the image (for the header and the data fields), but PC99 (dskcheck) complains about an invalid format when it does not find the fake F7F7 CRC values. This is now fixed, so that a PC99 disk modified in MAME will load again in PC99. This error was there for 10 years, nobody noticed.
  • The cassette emulation is now working with the TI-99/2 (32K). You can save and load programs, and also here, they are compatible with the 99/4A. Since the 99/2 has no audio output, you do not hear anything from the recorder. Also, it has no motor control, so you have to start and stop it by yourself.
  • There also was a long-living legacy code from MESS times, used in the sound routing for the cassette drive. This code was buggy and created two channels for the cassette recorder, although only a single channel was used. The effect was that when you played back the cassette wav file in MAME, you got two sounds, shifted by some seconds, where the first one was ignored (not by you hearing it, but by the console). This has been fixed; there is only one channel left.

For other achievements in the latest MAME release (not related to the TI world), see the official announcement at https://forums.bannister.org/ubbthreads.php?ubb=showflat&Number=113859

 

Summer's is approaching its end, in some weeks the next semester is about to start, so I won't have that much time any longer, but I'd call that a quite productive month indeed.

  • Like 9
Link to comment
Share on other sites

For quite some time I've been thinking about writing a tool that allows you to install and update MAME and all necessary files by a single click (where 0 < single < 10). The tool should offer a graphical user interface, and it should be platform-independent (i.e. running in Windows, MacOS, Linux). Maybe we could even do that together, that is, if some of you are interested.

 

What would be the preferred language for this?

 

- Java: Pro: I have good skills in Java (TIImageTool completely written in Java), it is available for all platforms, and it comes with an integrated GUI support. Con: It requires you to install a recent JRE. This is not a big issue, but yet another step, and requires me to explain again and again that Java is as safe as any other programming language.

 

- Python: Pro: Smallest footprint, easy to write programs. Con: Requires a widget kit (which one to choose?) and then again to install Python and this module to make use of it in Windows. Linux typically comes with pre-installed Python, but not necessarily with the module. As for installation, this is not really simpler than Java.

 

- C++: Pro: I can link the required GUI lib to the program statically, thus no need to install anything. Con: I have to build the tool for each platform separately, and beyond that, I don't have any experience with widget kits in C++ (like Qt or GTK).

 

Something else?

 

The point is that you have to decide at the beginning which language to choose. Porting to another language may be extremely cumbersome. For instance, some years ago I briefly thought about rewriting TIImageTool, but this is not feasible with reasonable and justifiable efforts (it has more than 150 classes).

Link to comment
Share on other sites

For quite some time I've been thinking about writing a tool that allows you to install and update MAME and all necessary files by a single click (where 0 < single < 10). The tool should offer a graphical user interface, and it should be platform-independent (i.e. running in Windows, MacOS, Linux). Maybe we could even do that together, that is, if some of you are interested.

 

What would be the preferred language for this?

 

- Java: Pro: I have good skills in Java (TIImageTool completely written in Java), it is available for all platforms, and it comes with an integrated GUI support. Con: It requires you to install a recent JRE. This is not a big issue, but yet another step, and requires me to explain again and again that Java is as safe as any other programming language.

 

- Python: Pro: Smallest footprint, easy to write programs. Con: Requires a widget kit (which one to choose?) and then again to install Python and this module to make use of it in Windows. Linux typically comes with pre-installed Python, but not necessarily with the module. As for installation, this is not really simpler than Java.

 

- C++: Pro: I can link the required GUI lib to the program statically, thus no need to install anything. Con: I have to build the tool for each platform separately, and beyond that, I don't have any experience with widget kits in C++ (like Qt or GTK).

 

Something else?

 

The point is that you have to decide at the beginning which language to choose. Porting to another language may be extremely cumbersome. For instance, some years ago I briefly thought about rewriting TIImageTool, but this is not feasible with reasonable and justifiable efforts (it has more than 150 classes).

 

something that doesn't require us to install something else to use it.. jre for instance.. so c is probably the best

Link to comment
Share on other sites

 

something that doesn't require us to install something else to use it.. jre for instance.. so c is probably the best

I would say Java or C++, though I have no experience with either. But I am fine with any, as I have just a little bit of Python programming experience, Most of my experience is in C# and EF and so forth.

Link to comment
Share on other sites

Hi there, another month is over, and we have MAME 0.201. You won't be surprised too much by the changes in this release, since I already mentioned them in this thread. Let me summarize:

...

 

Summer's is approaching its end, in some weeks the next semester is about to start, so I won't have that much time any longer, but I'd call that a quite productive month indeed.

 

Hi Michael,

this is such great achievements of you, again!

Will you do a presentation about the latest Mame Updates at the TI Treff in Neuss?

Link to comment
Share on other sites

Hi there, another month is over, and we have MAME 0.201. You won't be surprised too much by the changes in this release, since I already mentioned them in this thread. Let me summarize:

  • All disk formats (DSK, DTK, HFE) now have a 16 sector/track variant. This required me to add new valid file sizes (320K) for the sector dump format, and also a new PC99-like track dump format that uses 16 sectors/track (which will not be accepted by PC99, but was necessary). HFE could already work with this sector count, since it is a low-level format.
  • The HX5102 Hexbus floppy drive now works with the TI-99/2 (32K). You have to use the device name "HEXBUS.101"; there is no "DSK1". A nice discovery is that the TI-99 BASIC programs are compatible with the TI-99/2 (as long as you use the common subset of BASIC). With this floppy support, we can now explore the TI-99/2 a bit further, and this will also be interesting for those of you who have a real 99/2.
  • When you use the HX5102 with the 99/8, you can actually format disks without a Disk Manager, because the DSR contains a formatting routine. This is not a MAME achievement, of course. But now we can format disks in this way in MAME's emulation of the 99/8. I fixed a problem which occured when you changed the recording format from FM to MFM or back (that is, when you reformatted the disk from single to double density). The reason was a glitch in the disk controller chip emulation that was not written by me. Now with a stable, working floppy emulation on the 99/8, we have the full potential to try old programs and write new ones. I think that is good news, in particular because the 99/8 emulation is already there since 10 years, but due to the lack of a supported disk system, we could not really make use of it until now.
  • I fixed a problem with the track dump format (aka PC99 format). I assumed that I could write the real CRC values in the image (for the header and the data fields), but PC99 (dskcheck) complains about an invalid format when it does not find the fake F7F7 CRC values. This is now fixed, so that a PC99 disk modified in MAME will load again in PC99. This error was there for 10 years, nobody noticed.
  • The cassette emulation is now working with the TI-99/2 (32K). You can save and load programs, and also here, they are compatible with the 99/4A. Since the 99/2 has no audio output, you do not hear anything from the recorder. Also, it has no motor control, so you have to start and stop it by yourself.
  • There also was a long-living legacy code from MESS times, used in the sound routing for the cassette drive. This code was buggy and created two channels for the cassette recorder, although only a single channel was used. The effect was that when you played back the cassette wav file in MAME, you got two sounds, shifted by some seconds, where the first one was ignored (not by you hearing it, but by the console). This has been fixed; there is only one channel left.

For other achievements in the latest MAME release (not related to the TI world), see the official announcement at https://forums.bannister.org/ubbthreads.php?ubb=showflat&Number=113859

 

Summer's is approaching its end, in some weeks the next semester is about to start, so I won't have that much time any longer, but I'd call that a quite productive month indeed.

Hi Michael,

 

Do we need to download updated .zip files for the various 99/x and HX5102 device along with 0.201? The ones on whtech look to be from around 0.198-ish based on the dates. If we need newer ones to utilize all these new features, where can we obtain them?

 

Thanks for all your hard work on this! I love playing with the machines that never were released. The 24k 99/2 is really interesting in what doesn't work still in TI BASIC. :)

 

Thanks!

Link to comment
Share on other sites

The ROM set on WHTech is organized this way:

  • All ROM zips in /System\ ROMs/MAME shall be used for the latest MAME release ... unless:
  • you are using an earlier release; in that case, check the subfolders pre-... and replace the current ROMs with those in the subfolder.

So if you use MAME 0.180, you should download all zips from the main folder, then replace geneve.zip with pre-0.199/geneve.zip

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