mizapf

Reminds me of: Do you know how to get to the train station? - Yes. 🙂

As I said, the problem is not with GeneveOS and its mapper. You can always attempt to write to address 9400 or read from 9000. The problem right now is that two devices in the PEB may feel accessed by that, so this is a physical issue. The memex blocks accesses to bank BA from its memory to avoid this, but to my knowledge, it does not do that for bank BC where the 9000/9400 addresses are. The bad thing is that the speech synthesizer has no CRU bit for turning off and on. It is slower than other memory, so this may save the real system from these collisions, but they may show up in MAME as you noted.

You have to be aware that either one may corrupt the other one's memory access. If the speech synthesizer is in a higher slot, you may have proper speech, but in turn the accesses to memory locations 9000 and 9400 may be corrupted. I am not aware of particular limitations of the speech emulation in MAME. I mean, that part is not from me, but it worked pretty well for all other applications. I'd have to know what "does not like" means here. It's always possible we still have a glitch in the integration of the speech chip in the Geneve system. Tim wanted to give it a try, as he told me.

It's not only the problem for GeneveOS to avoid the page BC, but when we directly write to 9400 or read from 9000 in the PEB, this is an access to memory that is also available on the MEMEX. The description of the MEMEX does not say that this bank is blocked like the BA bank. ... which would lead me to suspect that using speech and MEMEX in the same box is probably not recommended. Timings in the real system may trigger a different behaviour, but it is at least hard to predict.

The MEMEX overrides the accesses of the speech card. The PEB emulation starts with slot 2 and steps through each slot until 8, so if there are concurrent accesses, the last one wins. The line that produces HELLO also means that values from the MEMEX are spoilt, while the opposite occurs for the other ordering. As far as I remember, and also implied by the dip settings, only the pages BA and multiples are blocked, not BC.

I found that this line produces "HELLO": ./mame geneve -window -bios 2.00 -peb:slot4 memex -peb:slot5 speech -peb:slot6 tipi -peb:slot8 ddcc1 -conn rpi.tipi while this one produces "UHOH" (5 times): ./mame geneve -window -bios 2.00 -peb:slot4 memex -peb:slot2 speech -peb:slot6 tipi -peb:slot8 ddcc1 -conn rpi.tipi See the difference? Which is a bit unsettling and requires more thoughts. Not a trivial bug.

Weird. Really, works for me: http://www.mizapf.eu/files/mame/genevesay.webm Please test this minimal configuration: mame ti99_4a -cart exbasic -ioport peb -ioport:peb:slot3 speech Next, try it with the Geneve, with minimum config: mame geneve -peb:slot2 speech -peb:slot8 hfdc -peb:slot8:hfdc:h1 generic -hard1 Bootdisk1.HD -flop1 dsdd1.dsk

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.

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?

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.

I need to take high dose Vitamin D (20000 IE) to treat my deficiency. Test results showed 9.8 ng/ml (normal: 20-100). My doctor said this is a strong deficiency, and that she'd normally advice patients to get out in the sun, but with my skin color (I) she'd rather not recommend that to me. Vitamin D deficiency, or skin cancer.

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.

Sigh ... too many options ... too few Raspberries. (I keep the MicroSD cards in their adapters when not plugged into the Raspberry.)

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 -

On that last screen with Venkman, is there something supposed to happen, like sound output or wait for a key press? I'm running that on MAME, and it seems it is waiting in a loop forever. Even though there was a LIMI 2 before, no video interrupt seems to occur, so did you disable the interrupt by CRU operation before?

Try mame ti99_4a -rompath c:\retrobat\bios and maybe check that ti99_4a.zip contains the files as listed above - just to make sure you did not use an outdated rom package.

I could reproduce this error message when I removed the ti99_4a.zip file, so it seems that your installation does not find the file in the dedicated path. If you have a mame.ini, what does your rompath setting say? (for me, 11th line from the top) I usually run MAME from a command line, not by clicking the mame executable, so your situation may vary from mine.

And your console ROMs? (ti99_4a.zip) (Note: The RPKs may be put wherever you want; they need not be put in a preset path, since you have to provide the full path name anyway. Only the *.zip files must be put into the rompath.)

Yes, it seems that using Genmod is not the origin of the problem. As for the write accesses - remember that you can always look into the source code at github: https://github.com/mamedev/mame/blob/master/src/devices/bus/ti99/peb/tipi.cpp: In setaddress_dbin, the m_dsr flag was set because the write access was indeed to the DSR space (>174xxx) and not to the ports, while the card was selected. Hence, the write method complains about that fact. You could use the debugger (-debug). There you can set a watchpoint which stops execution when the condition is true. wpset a000,4,w will stop when you write to A000-A003 (w=write). Type "go" to continue (or hit F5). Note that you have to put a prefix before the address: You need to watch out for 174f9a (with Genmod) if it complains about a write access to 4f9a; for the Geneve it is 074f9a if I recall correctly. (Edit: right so) When it stops you can see the portion of code that caused the access in the disassembler window. Edit: So you could set a watchpoint this way for the Genmod: wpset 174f9a,1,w.

This is not MAME's fault, perhaps Windows buffering? When I start MAME in Linux in one terminal and do a tail -f error.log in the other, the output shows up as soon as it is produced. Please send me the DM files you are using.

I just uploaded release 0.256 to WHTech for Linux, Windows, and macOS (ARM64): https://ftp.whtech.com/emulators/MAME/ti99/linux/mame0256b_ti99_linux64bit.tar.gz https://ftp.whtech.com/emulators/MAME/ti99/windows/mame0256b_ti99_win64bit.zip https://ftp.whtech.com/emulators/MAME/full/macos/mame0256b_macos64bit_arm64.zip As for Raspberry Pi, see the above posts.

Please tell us the precise error message; this will likely give the answer.

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.

I did not try on the Genmod yet. Could you try it on a Geneve setup? Edit: I just tried it; the Genmod works with the tipi as expected; boots and shows the directory. So it occurs only when you use DM?

geneve or genmod?