Jump to content
mizapf

New MAME release

Recommended Posts

Yes, MAME tries to guess the interleave and gaps. Check the comments at the beginning of https://github.com/mamedev/mame/blob/master/src/lib/formats/mfm_hd.cpp

 

I'm not sure how you plan to do a byte-by-byte copy. The locations inside the CHD are not as simple to calculate as with a DSK image. The CHD has a lookup table where the hunks are located. Also, you would need a full CHD support in your tool that cares for allocating new hunks etc.

 

The easiest and fastest way would be if I wrote a support for DREM in TIImageTool, but due to my current workload this is not going to happen within the next weeks.

 

 

Share this post


Link to post
Share on other sites

The new release of MAME (0.213) is some days late, but I guess only few people really noticed. But there is one possibly interesting feature that has changed:

 

The busmouse (used with the Geneve and with the EVPC or SGCPU) is now detachable. You might wonder why I announce an absence as an improvement, but the point is: Running under Windows, the mouse was always automatically captured when MAME was started (not so under Linux or MacOS) when there was a mouse device in the emulation. You had to terminate the emulation to get it back.

 

Now, unless you specify the option "-colorbus busmouse", the mouse remains detached, and your desktop mouse is free. If you typically need the mouse (maybe 0.5 to 0.8 people here 🙂 ) you should add this option to your run script.

  • Like 5
  • Thanks 1

Share this post


Link to post
Share on other sites
8 hours ago, mizapf said:

The new release of MAME (0.213) is some days late, but I guess only few people really noticed. But there is one possibly interesting feature that has changed:

 

The busmouse (used with the Geneve and with the EVPC or SGCPU) is now detachable. You might wonder why I announce an absence as an improvement, but the point is: Running under Windows, the mouse was always automatically captured when MAME was started (not so under Linux or MacOS) when there was a mouse device in the emulation. You had to terminate the emulation to get it back.

 

Now, unless you specify the option "-colorbus busmouse", the mouse remains detached, and your desktop mouse is free. If you typically need the mouse (maybe 0.5 to 0.8 people here 🙂 ) you should add this option to your run script.

Nice improvement..

Share this post


Link to post
Share on other sites
On 9/4/2019 at 1:02 PM, mizapf said:

The new release of MAME (0.213) is some days late, but I guess only few people really noticed. But there is one possibly interesting feature that has changed:

 

The busmouse (used with the Geneve and with the EVPC or SGCPU) is now detachable. You might wonder why I announce an absence as an improvement, but the point is: Running under Windows, the mouse was always automatically captured when MAME was started (not so under Linux or MacOS) when there was a mouse device in the emulation. You had to terminate the emulation to get it back.

 

Now, unless you specify the option "-colorbus busmouse", the mouse remains detached, and your desktop mouse is free. If you typically need the mouse (maybe 0.5 to 0.8 people here 🙂 ) you should add this option to your run script.

were you able to get around to the problem with the 99/2 not working properly with the hexbus?

Share this post


Link to post
Share on other sites

@mizapf

 

Hi,

I am having problems getting Ti99/4a Ambulance (Funware) cartridge running in newer versions of MAME 202 - 214.

tried several memory /port settings without any luck.

so i *think* it could be a bug.

 

ambulance.png.1af212c00e143cb0ea150d01e341411a.png

 

It does work ok in OLD MESS 140.

  • Like 1

Share this post


Link to post
Share on other sites

Thanks for reporting. I'll check. 0.140 is, architecturally speaking, light years away from the current state, so I hope we can find some release that is a bit closer.

 

Edit: It seems as if the video mode is changed on keypress. If you start it and don't touch a key, does the screen remain correct? If that is the case, and a keypress triggers this symptom, it could be an issue with video register 1 and location 83D4.

Edited by mizapf

Share this post


Link to post
Share on other sites

If i start using this to clear the keybuffer...

ADD_CLP( -autoboot_delay 1 -autoboot_command "")

it works until you pickup a patient.

then it buggs out again.

 

if anything is in the keybuffer, it fails.

ADD_CLP( -autoboot_delay 1 -autoboot_command "x2")

 

changing to NATURAL keyboard mode.

and press [F12] to reset (twice).

then press cursor right to start.

it looks ok until another key press.

Edited by .mad.

Share this post


Link to post
Share on other sites

Ambulance was broken in MESS/MAME after version 0.143. In version 0.188 it's start having problems (garbage on the screen) after the fire button pressure. In v0.212 after the inital screen, when moving in the game.

 

There are also some other SSS that stopped working, at least starting from version 0.188:

- Starship Pegasus
- Super Fly

- Accounting Assistant
- Activity Accountant
- Amateurfunk 1
- Attendance Recorder
- Class Data Recorder
- Course Manager
- Early Reading
- Payroll Assistant
- Salary Planner
- School Mailer

 

The various Scott Foresman titles need a blank disk inserted, however with version 0.188 they are not working anymore. Moreover, for some version of the MBX games (Sewermania, Space Bandits, Honey Hunt) it seems that only the cracked/converted disk version is working fine, while the SSS version is not working (the same SSS were working fine under old v0.106 or v0.67 versions).

 

Please, let me know if you need MD5 of such SSS and/or additional details. MAME/MESS was and is my preferred TI99 emulator, so I'm happy to help its support.

 

  • Like 1

Share this post


Link to post
Share on other sites

You can see changes in MAME under https://www.mizapf.de/ti99/mame/changes

 

The problem, as I said, will be to isolate the issue when things stopped working in a release long time ago. In particular, 0.144 and 0.145 are so different that the delta is the whole emulation.

 

In the best case, it is a common issue, and once it is solved, all those games work again.

  • Like 1

Share this post


Link to post
Share on other sites

Try this version of Starship Pegasus.

 

Apart from that, in any case (if you don't already do that), use the ZIP cartridges instead of RPK when available. This is an exception here because I have not found a non-patched version of Starship Pegasus. In the ZIP collection we only have authentic cartridges. (The RPK format may be removed from MAME in some future release, provided that we find a way to extend the ZIP format for homebrew cartridges.)

 

One of the notable changes was that I disallowed "fake GROMs" in cartridges to be handled as real GROMs. Many issues with older cartridges arise because they still use the "standard" cartridge type (with 6K GROMs). For cartridges with 8K "GROMs" (which never existed), the type must be changed to "gromemu".

 

In the example of Pegasus, this is obviously such a case. It works as soon as the type is changed.

mb_starship_pegasus.rpk

Share this post


Link to post
Share on other sites
1 hour ago, mizapf said:

Try this version of Starship Pegasus.

 

Apart from that, in any case (if you don't already do that), use the ZIP cartridges instead of RPK when available. This is an exception here because I have not found a non-patched version of Starship Pegasus. In the ZIP collection we only have authentic cartridges. (The RPK format may be removed from MAME in some future release, provided that we find a way to extend the ZIP format for homebrew cartridges.)

 

One of the notable changes was that I disallowed "fake GROMs" in cartridges to be handled as real GROMs. Many issues with older cartridges arise because they still use the "standard" cartridge type (with 6K GROMs). For cartridges with 8K "GROMs" (which never existed), the type must be changed to "gromemu".

 

In the example of Pegasus, this is obviously such a case. It works as soon as the type is changed.

mb_starship_pegasus.rpk 9.9 kB · 5 downloads

 

Many thanks for the clarification. The .C and .G files in your version and in mine are identical. The layout.xml file, instead, has the <pcb type="standard"> line. Now it's working perfectly.

 

Share this post


Link to post
Share on other sites

Concerning Accounting Assistant:

 

I found out that after "DISK CHECK", it loads sector 0 successfully from DSK1, but then it disconnects DSK1, selects DSK2, not finding a disk in it, and then prints the error screen. This looks as if it does not agree with what it gets from sector 0. Are you sure you can use any blank disk in the drive, or does it have to be prepared somehow, maybe a special disk name?

Share this post


Link to post
Share on other sites
10 hours ago, mizapf said:

Concerning Accounting Assistant:

 

I found out that after "DISK CHECK", it loads sector 0 successfully from DSK1, but then it disconnects DSK1, selects DSK2, not finding a disk in it, and then prints the error screen. This looks as if it does not agree with what it gets from sector 0. Are you sure you can use any blank disk in the drive, or does it have to be prepared somehow, maybe a special disk name?

 

I have a note that I've written on a very old MESS 0.67 installation, indicating that a blank/formatted disk is needed for the Accounting Assistant to work. So, I was able to run it. However, I've just tried again today with that version, but unsuccessfully. I've also tried the Class Data Recorder and I was able to pass the disk check using a blank disk the first time (I've seen the date insertion page), but after the first attempt I'm always getting the disk error page.

 

I've checked again with Class Data Recorder with MESS version 221 and it seems to work with a blank DSDD disk. Accounting Assistant and Activity Accountant are not working. I'll check again with this version of MESS the other SSS of the SF serie.

 

I do not think there is any disk shipped with Accounting Assistant. It seems that Scott Foresman has only these disks:

Part N. 30457 - Blank Disks
Part N. 30450 - Course Manager Gr 3
Part N. 30451 - Course Manager Gr 4
Part N. 30452 - Course Manager Gr 5
Part N. 30453 - Course Manager Gr 6
Part N. 30454 - Course Manager Gr 7
Part N. 30455 - Course Manager Gr 8
Part N. 30460 - Demonstration

 

If someone have the original Accounting Assistant could kindly confirm if a disk is included? Many thanks.

Share this post


Link to post
Share on other sites
On 10/30/2019 at 7:25 PM, mizapf said:
Quote

  use the ZIP cartridges instead of RPK when available.

 

Hi,

I have ZIP version carts, but can not get ANY running from the command line.

i read you do not use the ZIP extension in the commandline.

"-cart honeyhnt"

Do they need to be in a fixed set folder for MAME to see them or something?

 

also please can you give me one example of a RPK layout.xml for the new multi grom files.

phm3156c.bin

phm3156g3.bin

phm3156g4.bin

phm3156g5.bin

 

this is what i came up with... ;)

<?xml version="1.0" encoding="utf-8"?>
<romset version="1.0">
   <resources>
      <rom id="gromimage" file="phm3156g3.bin"/>
      <rom id="gromimage" file="phm3156g4.bin"/>
      <rom id="gromimage" file="phm3156g5.bin"/>
      <rom id="romimage" file="phm3156c.bin"/>
      <ram id="bufferedram" file="honeyhnt.nv" type="persistent" length="1024"/>
   </resources>
   <configuration>
       <pcb type="mbx">
          <socket id="grom_socket" uses="gromimage"/>
          <socket id="rom_socket" uses="romimage"/>
       </pcb>
   </configuration>
</romset>

many thanks!

Share this post


Link to post
Share on other sites

ZIP files go into a folder that is specified in the mame.ini file as "rompath". For example, my rompath entry is "rompath     roms;carts", where roms contains the system ZIPs and carts the cartridges. Then, the cartridge is selected by its name (no ".zip" added). You can check the names in the hash/ti99_cart.xml file or when you use the OSD (on-screen display).

 

The above layout won't work because you cannot use the per-chip dumps in the RPK. The RPK layout schema does not allow for separate contents for the same socket (here grom_socket). You have to glue all those GROM files together in one file, but you also have to all the missing 2K to each of the dumps; they are only 6 KiB long.

 

In Linux I'd create a 2K zeroed file with

 

dd if=/dev/zero of=empty2K.bin count=2048 bs=1

 

and then recreate the full GROM dump with

 

cat phm3156g3.bin empty2K.bin phm3156g4.bin empty2K.bin phm3156g5.bin empty2K.bin > honeyhuntg.bin

 

then use this layout.xml:

<?xml version="1.0" encoding="utf-8"?>
<romset version="1.0">
   <resources>
      <rom id="gromimage" file="honeyhuntg.bin"/>
      <rom id="romimage" file="phm3156c.bin"/>
      <ram id="bufferedram" file="honeyhnt.nv" type="persistent" length="1024"/>
   </resources>
   <configuration>
       <pcb type="mbx">
          <socket id="grom_socket" uses="gromimage"/>
          <socket id="rom_socket" uses="romimage"/>
       </pcb>
   </configuration>
</romset>

 

The ZIP format has become more advanced than the RPK in the meantime. On the other hand, the RPK format is only used for the TI console in MAME, so it is not officially supported as a cartridge format. However, we cannot get rid of it until we have a way to pack dumps for unregistered cartridges (not contained in ti99_cart.xml).

 

Share this post


Link to post
Share on other sites

Thanks for all the info. :)

 

The most important step i was missing...

ti99_cart.xml must be in the "hash" folder for it to work.

i had compiled a Texas only MAME, and put xml file in the same folder as the carts.

 

It might not be the MAME way of thinking...

 

As long as the cart files can be added and configured from the command line.

At least there will be a way to get most homebrew stuff working from a front end, without the need for a CRC check.

 

examples

-cart "alpiner.zip" -pcb "standard" -grom "phm3056g.bin" -size 8000 -offset 0000 -rom "phm3056c.bin" size 1000 -offset 0000

or

-cart "titanium.zip" -pcb "paged379i" -rom "titanium3.bin"

Share this post


Link to post
Share on other sites

Your suggestion does not consider the possibility to use a cartridge expander. If you use "-gromport multi" you get a three-slot cartridge expander, and then you have "-cart1", "-cart2", "-cart3".

 

There are two ideas for enhancing the zip system:

 

1. Allow for user-defined hash files. These could look like the ti99_cart.xml and would be provided in the command line. You could also consider to append new entries to the main hash file; but this means you have to save it before every update. Also, using separate hash files makes things somewhat complicated for the normal user: If you provide a homebrew cartridge, you would have to distribute "your" hash file as well. And when we have 30+ cartridges this way, you'd have to wonder what xml file you have to include in your command line.

 

2. Include the xml file in the ZIP file, much like the layout.xml. This would make it pretty simple to use homebrew cartridges: They would be used just like the RPKs; distributing the ZIP file would be enough. However, this requires a modification in the ZIP loader of the MAME core: Currently, ZIP files are loaded after matching some name (e.g. the system name, ti99_4a, makes it look up the ti99_4a.zip; the name exbasic for the Extended Basic cartridge makes it look up exbasic.zip); we would then have to include the case that the actual ZIP path name would be specified. This is already done with the RPKs, but it is done pretty ugly: When the name contains a period, the core loader assumes this is a file, otherwise it is a name. This is one of the reasons why I suspect that one future day the other devs will urge to remove the RPK support.

Share this post


Link to post
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.

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