New MAME release

[+mizapf]

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.

 

 

[+mizapf]

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.

[Shift838]

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

[+hloberg]

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?

[+mizapf]

Still on my list ...

[.mad.]

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

 

 

It does work ok in OLD MESS 140.

[+mizapf]

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 October 30, 2019 by mizapf

[.mad.]

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 October 30, 2019 by .mad.

[tmop69]

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.

 

[+mizapf]

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.

[+mizapf]

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

[tmop69]

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.

 

[+mizapf]

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?

[tmop69]

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.

[.mad.]

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!

[+mizapf]

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

 

[.mad.]

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"

[+mizapf]

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.

[+mizapf]

New MAME releases: 0.217 was released on Dec 25 (Christmas present, you could say). Here is a summary from Tafoid:

 

More important, some changes for next release: I fixed the 99/2 floppy issue. Almost, to be honest. Remember: The 99/2 BASIC failed to load a file from the HX5102 Hexbus floppy when it took more than one sector. I reworked some parts of the Hexbus emulation, and I think I found out the meaning of bit 6 (there was a thread about the 99/2 emulation by a FPGA, see there). The problem was that the 99/2 Hexbus emulation timed out while waiting for the next sector; this seems to work now.

 

"Almost solved" because loading is still unstable. Sometimes it works, sometimes an I/O error is produced. You can retry to load, it may work next time. I'm still chasing that bug. At least, we proceeded from 0% success of loading longer programs to 70%.

 

The new implementation is already checked in to Github, so you may want to pull and compile it instead of waiting for three weeks.

[Tursi]

On 11/1/2019 at 1:19 PM, mizapf said:

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.

Why not put the hash file inside the zip, in that case? 

[+mizapf]

This would indeed be solution 2. The challenge is to make that concept somehow compatible with the existing ROM loader in the MAME core. I have not yet studied the internals closely enough to tell whether this is simple task or not.

[+mizapf]

Good news: The instabilities seem to be gone for the Hexbus support in the 99/2! At least after more than 20 tries, I had no failure anymore.

 

The culprit was again the undocumented bit 6. My latest theory which seems to work now: Bit 6 indicates whether the HSK* line has been released (to high) and is now pulled down again. The bit is cleared when the 99/2 pulls down the line itself.

 

Last time I actually had a race condition; in that case the HSK* line was released between TB 4 and TB 6. It is quite a bit harder to get things going with an emulated multi-processing system like the TI-99/2 and the HX5102 floppy. Assuming that both devices have a perfect interleave when their clocks are equal will only work for the real device, not for the emulation.

 

However, I just noticed that someone else broke the cassette support, maybe several months ago. Need to check that...

[+mizapf]

More good news: Ambulance works again

 

The reason was the following line in the Ambulance code:

 

7EF6:     MOVB @>8802,@>8802

 

I don't know what this was supposed to do; maybe the author wanted to clear the status register by reading it; next line is a RT. The point is that I obviously forgot to block the write access to 8802, which triggered the two-byte latch in the VDP. From that moment on, the second byte was mistaken as the first when writing to video registers. I did not notice this bug until now because it has no effect in correct code.

[+mizapf]

Just to remember: Today, MAME 0.218 has been released, including the above-mentioned fixes (in particular the fix for the 99/2 floppy drive).

[+hloberg]

6 hours ago, mizapf said:

Just to remember: Today, MAME 0.218 has been released, including the above-mentioned fixes (in particular the fix for the 99/2 floppy drive).

???