Jump to content

Photo

New MAME release


138 replies to this topic

#126 strizzuth OFFLINE  

strizzuth

    Combat Commando

  • 4 posts
  • Location:Philadelphia, PA

Posted Sun Jun 17, 2018 2:29 PM

*bows down* Thank you for being awesome!



#127 iKarith OFFLINE  

iKarith

    Moonsweeper

  • 351 posts
  • Location:Portland OR

Posted Tue Jun 19, 2018 6:42 PM

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.



#128 mizapf OFFLINE  

mizapf

    River Patroller

  • Topic Starter
  • 3,312 posts
  • Location:Germany

Posted Tue Jun 19, 2018 11:57 PM

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.

#129 iKarith OFFLINE  

iKarith

    Moonsweeper

  • 351 posts
  • Location:Portland OR

Posted Wed Jun 20, 2018 12:13 AM

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.



#130 mizapf OFFLINE  

mizapf

    River Patroller

  • Topic Starter
  • 3,312 posts
  • Location:Germany

Posted Wed Jun 27, 2018 4:09 AM

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.



#131 mizapf OFFLINE  

mizapf

    River Patroller

  • Topic Starter
  • 3,312 posts
  • Location:Germany

Posted Wed Jul 25, 2018 9:32 AM

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



#132 Sinphaltimus OFFLINE  

Sinphaltimus

    River Patroller

  • 2,510 posts
  • Distracted at the Keyboard
  • Location:Poconos, PA

Posted Wed Jul 25, 2018 9:41 AM

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.



#133 mizapf OFFLINE  

mizapf

    River Patroller

  • Topic Starter
  • 3,312 posts
  • Location:Germany

Posted Wed Jul 25, 2018 12:03 PM

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

 

Depends on what you consider "good". On https://www.ninerped...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?



#134 Sinphaltimus OFFLINE  

Sinphaltimus

    River Patroller

  • 2,510 posts
  • Distracted at the Keyboard
  • Location:Poconos, PA

Posted Wed Jul 25, 2018 4:26 PM

 

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.



#135 mizapf OFFLINE  

mizapf

    River Patroller

  • Topic Starter
  • 3,312 posts
  • Location:Germany

Posted Wed Aug 8, 2018 2:54 PM

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


#136 mizapf OFFLINE  

mizapf

    River Patroller

  • Topic Starter
  • 3,312 posts
  • Location:Germany

Posted Fri Aug 10, 2018 12:38 PM

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.



#137 BeeryMiller OFFLINE  

BeeryMiller

    Moonsweeper

  • 475 posts
  • Location:Campbellsburg, KY

Posted Fri Aug 10, 2018 1:54 PM

Good detective work!



#138 mizapf OFFLINE  

mizapf

    River Patroller

  • Topic Starter
  • 3,312 posts
  • Location:Germany

Posted Fri Aug 10, 2018 4:29 PM

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/



#139 arcadeshopper OFFLINE  

arcadeshopper

    River Patroller

  • 3,496 posts
  • Location:Portland, Oregon USA

Posted Sat Aug 11, 2018 10:07 AM

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






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users