Jump to content

Recommended Posts

The floppy drives 3 and 4 are not connected by default. Also, you have to make sure that you use a controller that supports four drives.

 

mame ti99_4a -ioport:peb -ioport:peb:slot8 hfdc -ioport:peb:slot8:hfdc:f3 525dd -ioport:peb:slot8:hfdc:f4 525dd [further options]

 

If you want 80 track drives, you have to use 35dd (3.5" drives, not the 5.25" as given here).

 

While this is working, I rarely use more than one floppy drive. I don't see any particular advantage of using so many drives, as you can easily create emulation configurations with suitably mounted floppies.

I have some issues with building the current release on Raspberry Pi. The GCC has been failing for quite a number of releases by now, but now Clang also fails to compile. This occurs since an update in a 3rd party library (LZMA). It is not MAME-specific; maybe someone here has an idea:

 

Compiling 3rdparty/bx/src/dtoa.cpp...
../../../../../3rdparty/lzma/C/7zCrc.c:158:1: error: unknown architecture 'armv8-a+crc' in the 'target' attribute string; 'target' attribute ignored [-Werror,-Wignored-attributes]
ATTRIB_CRC
^
../../../../../3rdparty/lzma/C/7zCrc.c:89:58: note: expanded from macro 'ATTRIB_CRC'
           #define ATTRIB_CRC __attribute__((__target__("arch=armv8-a+crc")))

 

  • Sad 1
  • 4 weeks later...
On 6/9/2023 at 3:27 PM, mizapf said:

I have some issues with building the current release on Raspberry Pi. The GCC has been failing for quite a number of releases by now, but now Clang also fails to compile. This occurs since an update in a 3rd party library (LZMA). It is not MAME-specific; maybe someone here has an idea:

 

Compiling 3rdparty/bx/src/dtoa.cpp...
../../../../../3rdparty/lzma/C/7zCrc.c:158:1: error: unknown architecture 'armv8-a+crc' in the 'target' attribute string; 'target' attribute ignored [-Werror,-Wignored-attributes]
ATTRIB_CRC
^
../../../../../3rdparty/lzma/C/7zCrc.c:89:58: note: expanded from macro 'ATTRIB_CRC'
           #define ATTRIB_CRC __attribute__((__target__("arch=armv8-a+crc")))

 

Did you make any progress with this error on RasPi?

 

I understand the weird target string.  Raspian would show up as  armv8-a (32 bit), and the armv8-a ISA has an optional CRC32 instruction.  

Looking at C/7zCrc.c  I think that it assumes you have this, unless configure tells it otherwise (does MAME use configure?).

 

To skip this, I guess that you need compiler flag:

 

-D__ARM_FEATURE_CRC32

or

-D__ARM_FEATURE_CRC32=0

 

it seems redundant, but there is another flag:

-DUSE_CRC_EMU

 

This will cause ATTRIB_CRC  to be blank.

 

 

Otherwise -- what is actually using lzma?  Chances are, it is an optional dependency... it's not for zip support. 

 

 

 

On 12/10/2018 at 4:54 AM, mizapf said:

I'm using the resolution switch in mame.ini, setting it to e.g. 960x720. It is located in the section "OSD PER-WINDOW VIDEO OPTIONS".

 

If you want to set in on the command line:

 

 

./mame64 ti99_4ae -window -resolution 960x720

 

I don't know the switches -no-max and -window-resolution you mentioned, though. Mind that there is a blank between -window and -resolution.

 

when using RetroBat (using MAME) I get a very sharp output (not sure how to find the settings)    "ASTRO CUBE".

 

when I start from command line (same MAME) the output is a bit fuzzy.   ("BLASTO")

 

(both are full screen, not window,  I tried with resolution settings, but could not get the same as Retrobat)

 

1144661669_SCR554.thumb.jpg.bdfde0ef025ea7011affa2dd519dcdd4.jpg179721132_SCR557.thumb.jpg.d09dd51b70a67d6ed92f876e13179ade.jpg

 

The "sharp output" is without any filters, the default filter slightly blurs the pixels.

 

You can achieve that in possibly several ways by the command line; one that works for me is "-bgfx_screen_chains unfiltered". The default is "default".
 

On 7/4/2023 at 7:10 PM, FarmerPotato said:

Did you make any progress with this error on RasPi?

 

[...]

Otherwise -- what is actually using lzma?  Chances are, it is an optional dependency... it's not for zip support.

 

As far as I found out, the problem is with the LZMA 22.01 package. The first bad git commit is a504bde3a, the last good one before is befb9bf, and it uses 16.04, so quite a leap forward. I'm not really confident that I can convince the devs to revert to 16.04 to make it compile on the Raspberry Pi again.

 

In fact, I cannot even build LZMA on my Raspberry Pi when I pull the sources of 7zip from Sourceforge; I'm getting the same errors, so the problem does not occur in MAME but in 7zip.

 

The releases are on https://sourceforge.net/projects/sevenzip/files/7-Zip/. There have been some releases already, and there are bug reports, but I can't believe that no one cares about this issue. Maybe there is some special problem with my installation.

 

So what I'm trying to do now is to get a newer OS for my Raspberry (switching from Buster to Bullseye). Maybe this has some effect. If some of you have a Raspi 4, you may also try to build MAME on it - maybe you are luckier.

5 hours ago, mizapf said:

The "sharp output" is without any filters, the default filter slightly blurs the pixels.

 

You can achieve that in possibly several ways by the command line; one that works for me is "-bgfx_screen_chains unfiltered". The default is "default".
 

 

Thank you!

 

in mame.ini  I had to change it, but is old style sharp output now!

 

#
# OSD VIDEO OPTIONS
#
video                     bgfx

 

  • Like 1

Good news: I managed to build the recent MAME release for my Raspberry Pi 4 again.

 

This came at a (small) cost, though: I had to upgrade from the older Raspbian operating system to the recent Raspberry Pi OS (see https://www.raspberrypi.com/software/). Here, the 7zip library (LZMA) can be successfully compiled, and the MAME build process runs to completion.

 

This may mean that users will also have to install Raspberry Pi OS to their Pi 4, but I will have to test.

 

Actually, the build failed at first, but at another point. As recommended, I installed the 32bit version of Raspberry Pi OS. However, it reports "aarch64" as architecture, which is mistaken by the MAME build process as a 64 bit system. This architecture may run both 32bit and 64bit applications, and the recommended distribution is just a setup of all 32bit builds of system programs. So I had to patch the MAME makefile to force it to compile for 32 bit, and this worked ... surprisingly.

 

However, in the end I guess it makes much more sense to run the 64 bit version of Raspberry Pi OS; it may also increase the performance of MAME. I'll test that as well, just ordered another MicroSD card.

 

With this change, I added another folder to the Whtech repository: rpios. This will be the location where new builds for the Raspberry can be found. I will probably try to build for both 32 bit and 64 bit.

 

Index of /emulators/MAME/ti99

  Name Last modified Size Description

  Parent Directory   -  
  linux/ 2023-07-08 15:50 -  
  macos/ 2020-02-15 03:55 -  
  raspbian/ 2023-04-30 05:43 -  
  rpios/ 2023-07-11 09:28 -  
  windows/ 2023-07-08 15:50 -  

  • Like 5
  • Thanks 2

Well, I spent some more time with the Raspberries and MAME. Some insights:

 

1. You need to upgrade the OS to Raspberry Pi OS if you want to run MAME 0.255 and newer releases. I hoped that I just needed to build MAME on the newer platform, and that it might also run on Raspbian, but this is not the case. MAME is linked to a newer libc version than is available for Raspbian. The libc library suffers ABI changes every now and then, which makes it incompatible to earlier versions.

 

2. You can build MAME on the Raspberry Pi OS 32 bit as well as on Raspberry Pi OS 64 bit. On the 32 bit platform, however, the main makefile must be patched to prevent the PTR64 flag to be set. This flag would later cause the compilation to stop, as it detects a mismatch between the binaries that were built as 32 bit, and the PTR64 flag that is set. On the 64 bit OS, no changes are required.

 

3. Running MAME in the 64 bit environment actually shows better performance results. See my table on Ninermame: https://www.ninermame.org/info/requirements. Notably, the Geneve emulation advances from 63% to 78% (same MAME release, once run as 32 bit, then as 64 bit). The TI-99 emulation was already running at 100% for the 32 bit version.

 

4. There is a little performance loss from MAME 0.223 on Raspbian to MAME 0.256 on Raspberry Pi OS 32 bit. However, it is unclear whether this is caused by higher demands from MAME, or from the 32 bit operation mode of the newer operating system.

 

Edit:

5. One more thing about compilation. If you want to compile the 64 bit version on the Raspberry, you will need more than 4 GiB of RAM. I had to stop the compilation because it used up all of the 4 GiB, and also the 100 MiB (default) swap file, so it went into thrashing hell. When I increased the swap size to 1 GiB, it took about 60% of it, but it went over that hill, and finished the process. But note that using a swap file stored on the MicroSD will eventual ruin the card. Interestingly, the 32 bit version did not require such changes.

  • Like 2

Not exactly the Rave speech card, but some kind of speech adapter for the box, yes, available all along. The name is speech. BTW, you cannot use slot1.

 

-peb:slot5 speech

 

(or another slot). In the menu option "Machine configuration" you can choose whether or not to decode the AMA/B/C lines.

  • Like 1
10 hours ago, mizapf said:

Not exactly the Rave speech card, but some kind of speech adapter for the box, yes, available all along. The name is speech. BTW, you cannot use slot1.

 

-peb:slot5 speech

 

(or another slot). In the menu option "Machine configuration" you can choose whether or not to decode the AMA/B/C lines.

OK, I changed the slot and tried it.  Well, I get speech, however if I go into Abasic and type 

 

CALL SAY("HELLO")

 

I get speech, but it is not "Hello".  It is "Oh-oh".  It repeats this phrase 5 times.

 

Can you confirm on your system?

35 minutes ago, mizapf said:

No, works for me with both Geneve and Genmod, with GeneveOS 7.30, ABASIC 4.09. I get a clear HELLO output. Did you set the AMA/B/C decoding to on?

Decoding was set to ON.  Doesn't work for me.

 

Hmmm.  

The Uh-ohs indicate that the letters of the speech string are invalid. I can trigger this by entering CALL SAY("hello") (i.e. in lowercase). When I type an unknown word like HALLO, I get "H-A-L-L-O" (letters pronounced one by one).

 

I don't have a real answer to that. I tried it multiple times, and it always worked, in Linux and Windows.

Everything was uppercase, using the latest MAME executable, 64 bit, from the MAME website.  My bat file contains the following:

 

mame geneve -colorbus busmouse -peb:slot2 speech -peb:slot4 memex -peb:slot3 horizon -peb:slot5 tirs232 -peb:slot8 hfdc -peb:slot8:hfdc:h1 generic -peb:slot8:hfdc:h2 generic -peb:slot8:hfdc:h3 generic -peb:slot8:hfdc:f3 525dd -peb:slot8:hfdc:f4 525dd -hard1 Bootdisk1.HD -hard2 Bootdisk2.HD -hard3 Bootdisk3.HD -flop1 dsdd1.dsk -flop2 dsdd2.dsk -flop3 dsdd3.dsk -flop4 dsdd4.dsk -peb:slot6 tipi -conn rpi.geneve2

 

Version 7.40 of MDOS and 4.09 of Abasic.

 

 

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