New MAME release

[+mizapf]

As I keep recommending ... reduce your command line to the absolute minimum. This is my typical line (bash script):

 

#!/bin/bash
#
# Boot from MFM HD via HFDC; image from real HD
# No mouse
#
./mame geneve -window -peb:slot5 speech -peb:slot6 tirs232 -peb:slot8 hfdc -peb:slot8:hfdc:h1 generic -hard1 /home/michael/mame/disks/hd/maindisk.hd $*

 

If I need more, I add it to the script command, or if I need it more than once, I set up another script file with the special configuration. The point is: I need the other devices, or even a second floppy drive, for roughly 0.124% of the time I'm using the emulation. Each device you plug in needs to be serviced, and there is a good chance for unknown bugs to appear because of some unexpected interaction. (I mean, it's good to have reproducible errors, but I would rather discover them by myself.)

 

The 79% are really not good, and this alone fully explains the stutters in sound. You should not get errors for "-bench", unless you mistyped something.

 

$ ./mame geneve -bench 20
Average speed: 749.60% (19 seconds)

 

Your results may vary; my system is a quite new one, with a Core i5-12600KF. Anyway, you must get around 150% with bench in order to get a 100% with full graphics.
 

[Golden Child]

If your system is struggling to keep up you can always do some frameskipping, like -frameskip 1 and that will skip 1 out of every 12 frames.

 

You might also try -window and make the window smaller than full screen.

 

 

[globeron]

Here are the benchmark results mame gives errors, mame64 runs okay. I switched back to mame64 and reduced the command line. It now runs at 98%  and set GPL speed to 1. Now seems to be all good with the sound and speech!

 

 

[+mizapf]

Which release is this? The stack dump shows that the emulator crashed; this needs to be fixed, or maybe I did it already.

[globeron]

10 hours ago, mizapf said:

Which release is this? The stack dump shows that the emulator crashed; this needs to be fixed, or maybe I did it already.

 

0.251  I downloaded it last Saturday and overwrote all the files of .234. Maybe that was not the proper way to upgrade it.  I can do a new install.

https://www.mamedev.org/release.html

 

I saw your post bout .251

 

 

[+mizapf]

Just pick 0.250 and install it over your files, that should be OK. I remember an issue with the Geneve doing a premature memread, but I thought this was longer ago.

 

We have that release on WHTech.

[+arcadeshopper]

On 2/5/2023 at 9:02 PM, arcadeshopper said:

and in my process of testing tonight, i tried 249 and it works so reinstalled 250 and now it works.. 

 

SO just reinstalled mame again.. through ooigui mame 250.. didn't work with a real pi

installed 249, didn't work either

grumble

waited a bit..  tried again from commandline instead of ooi..  worked in 249.. tried 250 again.. works now..  tried both in ooi, works now

 

this is unreliable in windows

 

 

[+mizapf]

I'll do some tests at home with Windows and MAME 0.250; maybe I can find something. I did all previous tests with Linux, so maybe there's something different.

[TI_Master]

On 6/15/2022 at 3:01 PM, dhe said:

I think playing with the audio gate was how Barry Boone produced the sound he did with Sound F/X.

Actually this was done by modulating the volume registers of the 9919 to create a 4-bit resolution 50Khz carrier wave (amplitude modulation of the volume registers) to reproduce the sound.  Other methods seemed to work by modulating that audio gate, but I had better luck with volume of playback and clarity with the 9919.

Edited February 15, 2023 by TI_Master

[.mad.]

slightly off topic.

can anyone test this basic COMPILED cart for joystick control in MAME.

cg0148.rpk

 

I can't seem to map any keys for the movement.

*other joystick games are working ok.

It does however work in Classic99 using cursor keys.

 

Just wondering if the compiled code is the problem.

i don't have the original BASIC file to test.

And looking at the screenshot the game is impossible to win anyway.

thanks.

[+mizapf]

I guess you are walking with FCTN-ESDX? At least this works for me. (You don't use the "natural" keyboard, I suppose.)

[.mad.]

3 hours ago, mizapf said:

You don't use the "natural" keyboard, I suppose.

Correct, i don't use it.

always use the EMULATED keyboard mode.

 

Just deleted the cfg folder and created new default.cfg and ti99_4a.cfg.

now using ALT+E,S,D,X works.

 

i could swear, i had the texas cursor working without the need for holding the Function key (ALT) before.

not sure if i am remembering correctly or not.

maybe i edited the source in an old build.

 

is it possible to map the PC cursor keys in that way?

so only 1 key is needed to move, rather than holding 2.

 

thanks.

[+mizapf]

1 hour ago, .mad. said:

is it possible to map the PC cursor keys in that way?

so only 1 key is needed to move, rather than holding 2.

This would be against the idea behind the emulated keyboard. In this mode, the keyboard is emulated as a collection of individual switches, so for every mechanical switch in the TI system you have exactly one switch (key) on the PC keyboard.

[+mizapf]

On 2/14/2023 at 8:35 PM, arcadeshopper said:

SO just reinstalled mame again.. through ooigui mame 250.. didn't work with a real pi

installed 249, didn't work either

grumble

waited a bit..  tried again from commandline instead of ooi..  worked in 249.. tried 250 again.. works now..  tried both in ooi, works now

@arcadeshopperFirst thing to check: Do you have "Wait for initialization - On" in the Machine configuration?

 

Also, please specify "didn't work" so I can replay your actions and check whether I get the same result.

[+arcadeshopper]

15 hours ago, mizapf said:

@arcadeshopperFirst thing to check: Do you have "Wait for initialization - On" in the Machine configuration?

 

Also, please specify "didn't work" so I can replay your actions and check whether I get the same result.

yes i turned that on first thing

 

downloaded 250

loaded mame with tipi settings and real pi set to emulation mode (this PI works 100% of the time in js99er)

no connection just hangs on call tipi

 

downloaded 249

same ..  

 

waited a bit

go back to 249.. works

back to 250  works 

 

[+mizapf]

I did not yet find a problem with the TIPI access from MAME in Windows. It worked on every start. MAME version is 0.250.

 

I see this for CALL TIPI:

TIPICFG v11 PI-Version: 2.37

CRUBASE: 1800   IP:...

DSR Build: 2021-04-19T17:02:13-07:00

 

I'll try to upgrade to 2.40 now; see whether this makes a difference.

 

Edit: I am using a real PI 4 as the TIPI, not the QEMU emulation.

[+mizapf]

I've tried it now with a native Win 11 (i.e. not in a VM) connecting to a Pi4 in my network, and things ran smoothly for me, 10/10 tests successful; CALL TIPI opened its screen each time. I used MAME 0.250 and updated the PI to 2.40. <shrug>

 

Do you have this 4 second blank screen on startup (before the Master Title Screen comes up)? This should be an indication that the TI successfully connected to the PI. If the Master Title Screen immediately pops up after QUIT or BYE, this is a bad sign. I had these issues some time ago, but with the fixes back then, they never showed up again.

 

Try "-oslog" and have a look at the console output (or "-log" and check the file error.log). For me it looks like this:

 

$ ./ti99t -oslog
[:ioport:peb] AMA/B/C address prefix set to 70000
[:ioport:peb] Slot 2 = :ioport:peb:slot2:32kmem
[:ioport:peb] Slot 3 = :ioport:peb:slot3:speech
[:ioport:peb] Slot 4 = empty
[:ioport:peb] Slot 5 = empty
[:ioport:peb] Slot 6 = :ioport:peb:slot6:tipi
[:ioport:peb] Slot 7 = empty
[:ioport:peb] Slot 8 = :ioport:peb:slot8:ddcc1
Soft reset
[:ioport:peb:slot6:tipi] Trying to connect to Raspberry Pi at tipi:9901/tipi
[:maincpu] ** RESET triggered
[:ioport:peb:slot6:tipi] Connection established
[:ioport:peb:slot6:tipi] TIPI server offers ASYNC communication
[:ioport:peb:slot6:tipi] Closing connection
[:ioport:peb:slot6:tipi] Trying to connect to Raspberry Pi at tipi:9901/tipi
[:ioport:peb:slot6:tipi] Connection established
[:ioport:peb:slot6:tipi] TIPI server offers ASYNC communication

 

[+arcadeshopper]

[:ioport:peb] AMA/B/C address prefix set to 70000
[:ioport:peb] Slot 2 = :ioport:peb:slot2:samsmem
[:ioport:peb] Slot 3 = empty
[:ioport:peb] Slot 4 = empty
[:ioport:peb] Slot 5 = empty
[:ioport:peb] Slot 6 = empty
[:ioport:peb] Slot 7 = :ioport:peb:slot7:tipi
[:ioport:peb] Slot 8 = empty
Soft reset
[:ioport:peb:slot7:tipi] Trying to connect to Raspberry Pi at tipipz2:9901/tipi
[:ioport:peb:slot7:tipi] Connection established
[:ioport:peb:slot7:tipi] TIPI server offers ASYNC communication
[:maincpu] ** RESET triggered
[:ioport:peb:slot7:tipi] Closing connection
[:ioport:peb:slot7:tipi] Trying to connect to Raspberry Pi at tipipz2:9901/tipi
[:ioport:peb:slot7:tipi] Connection established
[:ioport:peb:slot7:tipi] TIPI server offers ASYNC communication
[:ioport:peb:slot7:tipi] Got error: End of file (2)
[:ioport:peb:slot7:tipi] Stopping TIPI

[+mizapf]

The EOF is the problem; it should not happen. If you press QUIT, does it appear again?

 

The EOF indicates that the TIPI closed the socket connection for some reason. Maybe you can find the reason in the logfile on the TIPI. I remember that issue, but it was gone after some updates to the TIPI and to the emulation, at least for me.

 

Edit: We were discussing that issue half a year ago in this thread (five pages ago). I'll have to read all that again, since I successfully swapped out all that stuff from my brain in the meantime. I did not even remember @PeteE fix for the client websocket implementation.

 

That is, we really need more tests from different people to see whether there is something particular with your installation, or whether the problem was not fully solved.

[+arcadeshopper]

23 hours ago, mizapf said:

The EOF is the problem; it should not happen. If you press QUIT, does it appear again?

 

The EOF indicates that the TIPI closed the socket connection for some reason. Maybe you can find the reason in the logfile on the TIPI. I remember that issue, but it was gone after some updates to the TIPI and to the emulation, at least for me.

 

Edit: We were discussing that issue half a year ago in this thread (five pages ago). I'll have to read all that again, since I successfully swapped out all that stuff from my brain in the meantime. I did not even remember @PeteE fix for the client websocket implementation.

 

That is, we really need more tests from different people to see whether there is something particular with your installation, or whether the problem was not fully solved.

agreed, like I said if i try it again in a bit sometimes it works but if i keep trying it fails

 

there's zip in tipi log 

 

2023-02-19 14:07:33,646 TipiService : INFO     websocket mode enabled
2023-02-19 14:07:33,657 TipiService : INFO     TIPI Ready

daemon log

Feb 19 14:07:32 tipipz2 systemd[1]: tipi.service: Succeeded.
Feb 19 14:07:32 tipipz2 systemd[1]: tipi.service: Service RestartSec=100ms expired, scheduling restart.
Feb 19 14:07:32 tipipz2 systemd[1]: tipi.service: Scheduled restart job, restart counter is at 26.
Feb 19 14:07:32 tipipz2 systemd[1]: Stopped TI-99/4A DSR Service.
Feb 19 14:07:33 tipipz2 systemd[1]: Started TI-99/4A DSR Service.
Feb 19 14:07:33 tipipz2 tipi.sh[19126]: checking for operation mode...
Feb 19 14:07:33 tipipz2 tipi.sh[19126]: Enabling emulation web-socket

[+mizapf]

MAME 0.252 has been released. As promised, the regression of 0.251 is fixed; besides that, we don't have new features inside.

 

Find the new release on WHTech: https://ftp.whtech.com/emulators/MAME/ti99/

(for Linux, Windows, Raspi; lean build for TI family only)

 

and https://ftp.whtech.com/emulators/MAME/full/

(for Windows and macOS; full build)

 

As a reminder, the lean build contains the following machines: TI-99/4A (NTSC/PAL, QI), SGCPU (aka TI-99/4P), TI-99/8, TI-99/2 (24K/32K), Geneve/Genmod, EVMBUG, CC-40, TM990/189, and Tomy Tutor; and all peripheral cards as listed on https://www.ninermame.org/info/scope.

 

Please notify me if you need more machines in the lean build or if you need the full build for Linux/Raspberry.

[ralphb]

Regarding MAME RPK carts, is there a way to specify the address of the first byte of the GROM binary in the layout.xml file?  There might be an (unwritten?) rule that all carts must start at >6000, but I don't really see a technical reason for this.

[+mizapf]

This is indeed a shortcoming of RPK. You have to provide the full GROM space beginning at 6000. If the cartridge only has a GROM 4 (8000-97FF) and no GROM 3, you have to pad 2K zeros before it.

 

The ZIP format does consider this. Example:

 

 <software name="exbasic">
                <description>Extended Basic</description>
                <year>1981</year>
                <publisher>Texas Instruments</publisher>
                <info name="serial" value="PHM 3026"/>
                <info name="version" value="110"/>
                <info name="comment" value="Common version"/>
                <part name="cart" interface="ti99_cart">
                        <feature name="pcb" value="paged12k"/>
                        <dataarea name="grom" size="0x8000">
                                <rom name="phm3026g3.bin" size="0x1800" crc="ce50e197" sha1="afd414eb29531de9411a959e3641534b8ac7faa5" offset="0x0000" />
                                <rom name="phm3026g4.bin" size="0x1800" crc="71f702c4" sha1="39224e621e227b1d491c1502437801c20bff33cd" offset="0x2000" />
                                <rom name="phm3026g5.bin" size="0x1800" crc="5510d76e" sha1="035477a5ca09b0efe0dfa051d815f60db9962fc2" offset="0x4000" />
                                <rom name="phm3026g6.bin" size="0x1800" crc="8621e071" sha1="6c9b195322f068c1529bbe9dfdab969d2bcc5712" offset="0x6000" />
                        </dataarea>
                        <dataarea name="rom" size="0x4000">
                                <rom name="phm3026c.bin" size="0x1000" crc="ac56064f" sha1="d4a6afa628adf45f585b1368bd682d91d223e838" offset="0x0000" />
                                <rom name="phm3026d.bin" size="0x2000" crc="95ed1f1a" sha1="1accb0e4d071ba8f47b6f5d4c21a0a6a030fac9d" offset="0x2000" />
                        </dataarea>
                </part>
        </software>

 

 

In contrast, this is the RPK definition:

 

<?xml version="1.0" encoding="utf-8"?>
<romset version="1.0" listname="exbasic">
   <resources>
      <rom id="gromimage" file="phm3026g.bin"/>
      <rom id="romimage" file="phm3026c.bin"/>
      <rom id="rom2image" file="phm3026d.bin"/>
   </resources>
   <configuration>
       <pcb type="paged">
          <socket id="grom_socket" uses="gromimage"/>
          <socket id="rom_socket" uses="romimage"/>
          <socket id="rom2_socket" uses="rom2image"/>
       </pcb>
   </configuration>
</romset>

 

[+dhe]

@mizapf any thing new for the MAME, April 1st release?

[+mizapf]

Thanks for asking. No, everything quiet here: https://www.ninermame.org/info/releases

During the last months I've been a bit busy with real-life things, in particular research work and the start of the new courses at our university. But I'll continue as soon as enough free time shows up.