Jump to content
IGNORED

New MAME release


mizapf

Recommended Posts

Yes, I found the E-mail as well, and actually, nothing has changed in the last 8 years:

 

Quote

Some years ago when working on the existing code I tried to fix it according to what the mouse driver does. I never had the exact hardware specs, so things may still be different than what we see with the real mouse.

 

Have a quick look at the comments at the top of the file

http://git.redump.net/mame/tree/src/mess/machine/ti99/mecmouse.c

Edit: This is now https://github.com/mamedev/mame/blob/master/src/devices/bus/ti99/joyport/mecmouse.cpp

 

So there is a way to confuse the mouse, but I don't know whether and how the real mouse prevents that.


 

So my problem is not to fix a bug, but that I generally do not understand how to avoid the axis swap. Do you have a real Mechatronics mouse? (or anyone else?)

 

Edit: I noticed that TI-DOS crashes for the DDCC-1 controller and the BwG controller; it works for the HFDC and the normal TI controller. I saw that a click causes the axis swap, maybe I can do some investigation there. The problem with the mouse is that you actually cannot set anything, as everything is done via the joystick port. The only action you can do is to select stick 1 or stick 2, and by this way, the axes are swapped. If this is not done properly, X and Y remain swapped.

 

Edited by mizapf
  • Like 1
Link to comment
Share on other sites

2 hours ago, mizapf said:

Yes, I found the E-mail as well, and actually, nothing has changed in the last 8 years:

 


 

So my problem is not to fix a bug, but that I generally do not understand how to avoid the axis swap. Do you have a real Mechatronics mouse? (or anyone else?)

 

Edit: I noticed that TI-DOS crashes for the DDCC-1 controller and the BwG controller; it works for the HFDC and the normal TI controller. I saw that a click causes the axis swap, maybe I can do some investigation there. The problem with the mouse is that you actually cannot set anything, as everything is done via the joystick port. The only action you can do is to select stick 1 or stick 2, and by this way, the axes are swapped. If this is not done properly, X and Y remain swapped.

 

 

I have one. It didn't do that when it worked, it stopped working a while back

 

Greg 

Link to comment
Share on other sites

Yes, I found the E-mail as well, and actually, nothing has changed in the last 8 years:
 
Some years ago when working on the existing code I tried to fix it according to what the mouse driver does. I never had the exact hardware specs, so things may still be different than what we see with the real mouse.
 
Have a quick look at the comments at the top of the file

http://git.redump.net/mame/tree/src/mess/machine/ti99/mecmouse.c

Edit: This is now https://github.com/mamedev/mame/blob/master/src/devices/bus/ti99/joyport/mecmouse.cpp
 
So there is a way to confuse the mouse, but I don't know whether and how the real mouse prevents that.

 
So my problem is not to fix a bug, but that I generally do not understand how to avoid the axis swap. Do you have a real Mechatronics mouse? (or anyone else?)
 
Edit: I noticed that TI-DOS crashes for the DDCC-1 controller and the BwG controller; it works for the HFDC and the normal TI controller. I saw that a click causes the axis swap, maybe I can do some investigation there. The problem with the mouse is that you actually cannot set anything, as everything is done via the joystick port. The only action you can do is to select stick 1 or stick 2, and by this way, the axes are swapped. If this is not done properly, X and Y remain swapped.
 
I'm using bwg. You can see in my video

Sent from my LM-V600 using Tapatalk

Link to comment
Share on other sites

Could it depend on single density vs. double density? I'm normally only using double density, of course. But here, I had to prepare another disk for the TI controller with SD.

 

Now I noticed that the SD works with BwG in TI-DOS, but not the DD.

  • Like 1
Link to comment
Share on other sites

I seem to remember a weird formatting/copy issue between Myarc and CorComp/BwG controllers BITD. It had nothing to do with the Myarc 16-sector double density--but on disk copies, data appeared corrupted on the other controller. I know this one bit me a few times back when I was still in Germany.

Link to comment
Share on other sites

  • 3 weeks later...

I just uploaded the recent MAME 0.231 release to WHTech:

 

https://ftp.whtech.com/emulators/MAME/ti99/linux/mame0231b_ti99_linux64bit.tar.gz

https://ftp.whtech.com/emulators/MAME/ti99/raspbian/mame0231b_ti99_raspbian32bit.tar.gz

https://ftp.whtech.com/emulators/MAME/ti99/windows/mame0231b_ti99_win64bit.zip

https://ftp.whtech.com/emulators/MAME/full/macos/mame0231b_macos64bit.zip

 

The only interesting change to previous releases is that I changed the default setting of the floppy drive step rate to 6 or 8 ms on all disk controllers (that allow setting the rate). The previous default of 20ms led to a failure on the Corcomp controller, in conjunction with a too short motor-on time. That is, if you had problems with the Corcomp controllers, you should download this release and just copy it over your existing installation.

 

Edit: Apart from the Corcomp problem, you will also generally notice a slightly faster floppy operation, since the floppy heads move faster now (unless you already chose a shorter step time by yourself).

Edited by mizapf
  • Like 3
Link to comment
Share on other sites

MAME 231 (and earlier versions) doesn't play nice with my new machine (using an Nvidia graphics card and the proprietary driver) in that starting MAME completely locks up the machine -- I had to log into a virtual console and kill -9 the MAME process.

 

I saw some error messages about ALSA in the terminal window after killing MAME (not sure if they're responsible for locking up). 

Value 1 not supported for option sound - falling back to auto
ALSA lib confmisc.c:767:(parse_card) cannot find card '1'
ALSA lib conf.c:4732:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory
ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings
ALSA lib conf.c:4732:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory
ALSA lib confmisc.c:1246:(snd_func_refer) error evaluating name
ALSA lib conf.c:4732:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:5220:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2642:(snd_pcm_open_noupdate) Unknown PCM default
ALSA lib seq_hw.c:466:(snd_seq_hw_open) open /dev/snd/seq failed: Permission denied

Is there a way to reset or even auto-detect the mame.ini file?  Can MAME deal with pulseaudio?  Do I need additional permissions?  (I already added my user to the video group, which seems to be necessary for Nvidia.)

 

Link to comment
Share on other sites

6 minutes ago, mizapf said:

Yes, pulseaudio is now available (-sound pulse). You can delete the mame.ini file and let it be created by -createconfig.

Thanks, that option really helped.  I also deleted my mame.ini.  But now I got this error (after a black screen):

cassiopeia ~ > mame -sound pulse
Error opening translation file English
fpa_connect: Access denied

What is fpa?

 

Link to comment
Share on other sites

By the way, mame -showusage lists the options for command line and mame.ini with valid values. Did you recreate the mame.ini?

 

As for the translation file, do you have a folder "language" in your MAME home?

 

I searched the MAME source code, but I cannot find a "fpa_connect". It seems as if this error message is not created inside MAME.

 

(Hast du eventuell Signal, dann können wir das vielleicht schneller abhandeln?)

Edited by mizapf
Link to comment
Share on other sites

Well, funnily enough, if I omit -sound pulse, the error message is gone, and I still have sound.  (So, OF COURSE, the problem is with pulse.)

 

I re-generated a mame.init file, and everything seems to be working now.  Thanks for your guidance!

Link to comment
Share on other sites

  • 1 month later...
  • 2 weeks later...

Hi:

 

If you have access, you might want to make a slight change to the "mameprepcygwin" file on whtech.  The MAME developers no longer use "mame64.exe" as the executable name--they just use "mame.exe".  Not a big deal, and most of us know how to change it. but, thought I'd mention it.

 

Thanks!

  • Like 1
Link to comment
Share on other sites

That should be covered in the mameprep_cygwin file. The older version is mameprep_cygwin.pre229 (for mame64.exe).

You think of the directory /emulators/MAME/ti99/windows, right?

 

wait ... you probably referred to /emulators/MAME/full/windows. I'll update that.

 

Update: Done.

  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...

New release MAME 0.234 has been uploaded to WHTech.

 

There are no changes for the TI emulations, but I took that opportunity to update the genhd01.hd image file for the Geneve boot hard disk so that it contains GeneveOS 7.30.

 

Also, I updated the mameprep scripts to use "mame" instead of "mame64"; I noticed that the mameprep versions that were packed into the tar.gz files for Linux and Raspbian were not updated yet. The 0.234 release should be fixed in that respect.

 

Installation in Linux:

- Don't use the packaged MAME of your Linux distribution; if installed, I recommend to uninstall it.

- Unpack the mame0234b_ti99_linux64bit.tar.gz file in an empty folder

- Run ./mameprep in that folder. It downloads all ROMs, some cartridges, and disks, and prepares start scripts.

- Ready to go, try ./ti99

 

For Windows users, if you have Cygwin installed, you can use mameprep_cygwin for an initial installation.

  • Like 5
Link to comment
Share on other sites

  • 2 weeks later...

Fascinating ... I'm currently working on the WHTech SCSI emulation in MAME. I was not prepared for this early success.

 

In fact, I'm just somewhere in the middle and just hoped for some "reproducible behavior" so that I can proceed step by step, and on the first attempt, I just stopped the emulation because I thought it had locked up, and right before the moment when I clicked away the window, the cursor reappeared.

 

PDMA still does not work (I did not even try to emulate the complete circuitry of the PLD), and sometimes I still get an I/O error 57, but this will be solved.

 

BTW, I was searching for some error for the last two days, always getting an I/O error 57. In the end it turned out that SCS1 is mapped to SCSI ID 0, not 1.

0152_2x.png

  • Like 8
Link to comment
Share on other sites

  • 2 weeks later...
On 2/24/2020 at 10:31 PM, mizapf said:

Just a single video that shows how easy it has become to do the installation. I dare to say it's not going to become much easier :) . The sound is a bit chopped because VirtualBox has a heavy performance impact (about half as fast as the native system, at least here, running Windows as a guest), and the emulations cannot run at full speed.

 

Don't worry, I'm not going to turn this thread into a promotion channel (more than it is already now...). I'll return to MAME announcements after this.

 

The waiting times during installation are clipped, the real time from start to end is about 9 minutes.

 

It would be good to pin this video to the 1st post (as each time I am searching for it when changing PC ? how to do it again)

 

Just re-installed it via this procedure, now MDOS 7.30 is running in MAME!

 

Question:

1* How can I get MAME in full screen view in Windows 10-64 bit ? 

 

2* how do I get in the other menu with dip-switches, etc. (TAB does not work and ~ neither)

     and I vaguely remember to press the BREAK key,  but I do not have this on my computer

     and the onscreen keyboard the PAUSE key (which is PAUSE/BREAK does not work either)

     but according my video it is SCRL LOCK and TAB key (https://www.youtube.com/watch?v=DBaD-EhA0QY&t=657s

 

image.png

Edited by globeron
PAUSE key = BREAK key
Link to comment
Share on other sites

1. Full screen should be possible by setting window as 0 in mame.ini. You can add "-window" in the command line if you want to start in windowed mode again. I noticed that you cannot force full screen when window is set to 1 in mame.ini (there is no opposite to -window).

2. If I understand correctly (your question #2 does not formulate a clear question), you are looking for a way to enter partial keyboard mode. This is now indicated as "UI controls enabled" and is normally toggled by ScrlLock. You may choose a different key as the "uimodekey".

  • Like 1
Link to comment
Share on other sites

On 8/22/2021 at 10:57 PM, mizapf said:

1. Full screen should be possible by setting window as 0 in mame.ini. You can add "-window" in the command line if you want to start in windowed mode again. I noticed that you cannot force full screen when window is set to 1 in mame.ini (there is no opposite to -window).

2. If I understand correctly (your question #2 does not formulate a clear question), you are looking for a way to enter partial keyboard mode. This is now indicated as "UI controls enabled" and is normally toggled by ScrlLock. You may choose a different key as the "uimodekey".

 

Thank you!

 

Re1a: window changed to 0

 

Re1b: in the command line used -nokeepaspect (to stretch it out over the whole screen and remove the black side borders)

 

Re2: I changed the uimodekey to F2 (as on most PC's this is the key to get into the "BIOS")

 

mame.ini

 

and another batch file to start in -window mode

geneve-startinwindow.bat

 

 

geneve-fullscreen-nokeepaspect.bat

 

 

image.thumb.png.7ef3791587cceb41f1186bf6f7d96ffb.png

 

 

image.thumb.png.e00c689dbbb4a20055d7b64c2eb3d40f.png

 

geneve-fullscreen-nokeepaspect

Edited by globeron
added batch files -nokeepaspect
  • Like 2
Link to comment
Share on other sites

Some funny things ...

 

You remember that on several occasions I told you MAME users that the RPK format is deprecated and will be removed at some future point of time. For the standard modules, the ZIP format is the recommended way to go.

 

Right now there is a pull request on Github to remove RPK from the TI-99 subtree, but not to drop it - instead, it will now be used for the CoCo (TRS 80) as well, i.e. it is moved up in the repository tree to be usable for other systems beside the TI.

 

As you can see on https://www.mizapf.de/ti99/mame/changes, RPK was implemented for MESS 0.131 (year 2009), and the software lists were available in the following years; by MAME 0.149 (2013) almost all cartridges were available as ZIP files.

 

Obviously, in the last 10 years, no one has come up with a practical solution to expand the ZIP system for homebrew software. Maybe we're just lucky that the core developers guys just want to keep the ZIP system as is and don't care enough for computer systems where you have lots of selfmade software.

 

On the bottomline, RPK will remain in MAME for some longer time. Then I should defer my heads-up; by 2030, we should be ready to switch to ZIP if needed. ;)

 

...

 

The ZIP system has one big advantage for software archival: It contains verification codes (CRC and SHA1) and also checks them so that we can make sure that we have the original piece of software and not a patched one. (I came across several cartridge images that seem to be patched.) So it does make sense, and I use it preferably (like "-cart exbasic" instead of "-cart modules/cartridges/extended_basic.rpk").

  • Like 5
Link to comment
Share on other sites

A bit off-topic: The TRS-80 computers, including the "Color Computer" were more or less unobtainium in Germany, although I heard of them in those days. Wikipedia says that these computers were only distributed via Tandy stores, and those were extremely rare here (and only present between 1983 and 1985).

  • Like 1
Link to comment
Share on other sites

On 8/24/2021 at 3:27 PM, mizapf said:

A bit off-topic: The TRS-80 computers, including the "Color Computer" were more or less unobtainium in Germany, although I heard of them in those days. Wikipedia says that these computers were only distributed via Tandy stores, and those were extremely rare here (and only present between 1983 and 1985).

it was the same as the Dragon 32/64. Were they available in Germany?

Link to comment
Share on other sites

14 hours ago, hloberg said:

it was the same as the Dragon 32/64. Were they available in Germany?

I seem to remember that there were some differences between the Dragon and the Coco. I used to have a translation guide to modify Dragon BASIC programs to Coco BASIC. Most of the differences there were minimal, IIRC.

Link to comment
Share on other sites

4 hours ago, Ksarul said:

I seem to remember that there were some differences between the Dragon and the Coco. I used to have a translation guide to modify Dragon BASIC programs to Coco BASIC. Most of the differences there were minimal, IIRC.

the hardware was essentially the same with only minor tweaks, both off-the-shelf Motorola. But they used different drive formats so disk weren't exchangeable. I 'think' also tapes couldn't be swapped. BASIC was ever so slightly different, just enough to annoy & keep Dragon from being sued by Tandy. :) In reality the Dragon was a better machine due to it's more standard ports. 

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