New MAME release

[+InsaneMultitasker]

4 minutes ago, mizapf said:

The RS232 is a component (unlike the speech synthesizer) which can actually raise interrupts. It also depends on the card; is it an original TI RS232?

 

It remains to find out why the interrupt is raised at all. But that may be quite easy to find out - in an emulation. This may also be a bug, I don't know yet but I'll find out.

 

This shows again why I always recommend to drop the cards and whistles and bells as far as possible when things don't run well in the emulation.

Yes, it is an original TI RS232.  I am wondering if the interrupt is raised as part of the emulated /4a powerup or reset, then never serviced. I'll check the loader and Pinball for anything that might be changing the interrupt mask.  For example, the Geneve keyscan might be performing a limi 1/limi 0 which in turn yields to the interrupt handler.  I still think that I should update the loader to page in the DSR properly,which would render the whole discussion moot as the interrupt would be serviced.  If I have time tonight, I will create an updated loader that I will PM to you and @9640News

[+dhe]

1 hour ago, InsaneMultitasker said:

PINLOAD is built upon EXEC code.

 

  I can't contain myself... I was looking at the source code to exec a while back, and that's the most far out code, I've ever seen.... Worth a look by one and all.

[+mizapf]

The interrupt is raised by the second 9902 chip; more precisely, the XBIENB flag is set to one by a SBO >13 (Transmit Buffer Interrupt Enable). As the transmit buffer is empty, this raises the interrupt. Sometimes there is a SBO >1F later, which resets the UART and the interrupt line, but not in this case. The interrupt is still active.

 

I wondered what happened to the SBO >1F that we can actually see in this code ... but R12 is changed in between (from 1380 to 1540).

 

[+Lee Stewart]

13 minutes ago, mizapf said:

The interrupt is raised by the second 9902 chip; more precisely, the XBIENB flag is set to one by a SBO >13 (Transmit Buffer Interrupt Enable). As the transmit buffer is empty, this raises the interrupt. Sometimes there is a SBO >1F later, which resets the UART and the interrupt line, but not in this case. The interrupt is still active.

 

Isn’t this the “nasty bug” described by Thierry Nouspikel?:

 

“As you can see, this routine is buggy: if the interrupt did not come from the card, the second TMS9902 in the card will start generating interrupts whether this was intended or not!”

 

...lee

[+InsaneMultitasker]

I pulled the TI RS232 out of my PEB.  What I thought was a code issue with another program has been resolved.  Now I have two reasons to fix the interrupt handler, thanks to this whole discussion.  Nice, indirect way for MAME to debug code!

 

[+mizapf]

This is the beauty of emulation. We should have had that back in those days.

 

If you like, I can give you some tips for advanced bug tracing with MAME. As you saw above, it did not take long until the culprit was identified.

 

The only thing that still bothers me - if the interrupt handling is faulty, why does it not crash the real Geneve?

[+InsaneMultitasker]

1 hour ago, mizapf said:

The only thing that still bothers me - if the interrupt handling is faulty, why does it not crash the real Geneve?

Perhaps the interrupt is serviced before the loaded program sets the interrupt mask to 0.  My real Geneve does lock up with a different project and removing the RS232 resolves the issue. The loader has been updated and I will PM it tonight or this weekend, for testing. 

[+mizapf]

On 7/19/2023 at 1:54 AM, Lee Stewart said:

Isn’t this the “nasty bug” described by Thierry Nouspikel?:

I think this is yet another problem, as it is concerned with the interrupt-driven reception code (inside the RS232 ROM).

 

While most of TI's code looks fairly good, this is a complete mess. I can't imagine how this made it through QA. Was it a job for the intern?

[+mizapf]

OK, the new DSR for TIPI has been uploaded by me to WHTech. It is available as ti99_tipi.zip. The zip file contains - for archival purpose - both old and new dsr files: tipidsr.u2 and tipidsr_2023.u2.

 

I added the hash codes to the new MAME release so you will not get any more warnings about bad hashes once you upgrade MAME.

 

If you use the earlier and current MAME (<=0.257) with the new zip file, it will use the 2021 DSR (without the CS1 enhancement). To force it to use the new DSR, you have to swap the file contents in the ZIP file (put the 2023 DSR into the tipidsr.u2 file). But then you will get warnings about the bad hashes.

 

Once you upgrade to the new MAME (assuming that my update was in time for the new release), the 2023 DSR will be used by default. You should then use the attached new ZIP file (or the one that is available on WHTech). You can then choose between both variants in the OSD ("BIOS selection") or in the command line by adding ",bios=2021" or ",bios=2023" to the tipi slot device:

 

-ioport:peb:slot6 tipi,bios=2021
-ioport:peb:slot6 tipi,bios=2023 (=-ioport:peb:slot6 tipi)

 

 

 

ti99_tipi.zip

[+mizapf]

OK, good news: The recent changes made it into the 0.258 release. As described above, this means that the updated DSR of the TIPI is used by default if you put the new ti99_tipi.zip in the rompath.

 

Another fix goes to the HX5102 (Hexbus floppy drive): When you turn on logging with "-oslog" or "-log", the drive accepts DSDD floppy disks. Without the logging, it does not. This is an example of a Heisenbug: It changes behavior the closer you observe it. I found out that the reason was a boolean member variable that was not initialized, so the activation of logging seems to shift memory contents in a way that makes the variable return a false, while without logging, it returns true. Ugly stuff.

 

As always, you can find pre-built packages on WHTech for Windows, Linux, Raspberry Pi OS 32 bit and 64 bit. I'll add MacOS as soon as it becomes available.

 

https://ftp.whtech.com/emulators/MAME/ti99/

[+dhe]

On 7/3/2023 at 8:39 AM, mizapf said:

No new features right now; as I said, the summer break is coming, guess I'll find some more time then.

 

 I have combined this statement, with this information found on the web: Fall begins in Germany - Saturday, 23 September 2023

 

 Are there kewl/new feature enhancements in MAME and TI Image Tool coming our way tomorrow? 🙂

[+mizapf]

Nothing new in MAME 0.259, TIImageTool 3 nearing completion (with lots of enhancements).

 

Surprise: Fall begins everywhere on Sep 23. 🙂

[globeron]

27 minutes ago, mizapf said:

Nothing new in MAME 0.259, TIImageTool 3 nearing completion (with lots of enhancements).

 

Surprise: Fall begins everywhere on Sep 23. 🙂

Looking fwd to the new release, it is a useful tool !

[JB]

5 hours ago, mizapf said:

Surprise: Fall begins everywhere on Sep 23. 🙂

Except Australia!

[+arcadeshopper]

[:maincpu] Variant = standard (with on-chip RAM), Overflow int = no check
[:peb] AMA/B/C address prefix set to 00000
[:peb] Slot 2 = empty
[:peb] Slot 3 = empty
[:peb] Slot 4 = empty
[:peb] Slot 5 = :peb:slot5:speech
[:peb] Slot 6 = :peb:slot6:tipi
[:peb] Slot 7 = empty
[:peb] Slot 8 = empty
Soft reset
[:peb:slot6:tipi] Trying to connect to Raspberry Pi at tipipz2:9901/tipi
[:] Video RAM set to 128 KiB
[:maincpu] RESET; automatic wait state creation is disabled
[:kbd:geneve_kb_101] Reset triggered
[:peb:slot6:tipi] Connection established
[:peb:slot6:tipi] TIPI server offers ASYNC communication
[:] Keyboard reset (line not connected)
[:kbd:geneve_kb_101] Reset triggered
[:peb:slot6:tipi] Got error: End of file (2)
[:peb:slot6:tipi] Trying to connect to Raspberry Pi at tipipz2:9901/tipi
[:peb:slot6:tipi] Connection established
[:peb:slot6:tipi] TIPI server offers ASYNC communication
[:peb:slot6:tipi] Got error: End of file (2)
^C[:peb:slot6:tipi] Stopping TIPI
 

sigh ok i figured this out.. nm

 

if i have js99er connected..even with it stopped.. it does this.. disconnect it first.. goes away

[+dhe]

Somewhere in Germany, it's the first.

  As an eager crowd await...

     A New Mac M3 PRO you say?

        Pah...

           A new MAME release is what we await!

                                                😃

[+9640News]

Are there directions somewhere out there on installing MAME on the Raspberry PI? Perhaps with the image Matt is using for the TIPI?  

[+mizapf]

You certainly know that I'm building Raspberry OS binaries with almost every new release, don't you? Please download the tarball from https://ftp.whtech.com/emulators/MAME/ti99/rpios/. Unpack it into a folder like ~/mame, run the mameprep script.

 

I was a bit busy over the last months, so the latest version there is 0.258. I'll have to update it again, but as I said, nothing new since then (https://www.ninermame.org/info/releases).

 

Note that you have to use Raspberry OS, not Raspbian OS.

 

Edit: The image that Matt uses for TIPI should not have anything to do with running MAME, or I did not quite understand what you plan to do. Do you want to run MAME on the PI and at the same time, use the PI as the TIPI component?

[+9640News]

13 minutes ago, mizapf said:

You certainly know that I'm building Raspberry OS binaries with almost every new release, don't you? Please download the tarball from https://ftp.whtech.com/emulators/MAME/ti99/rpios/. Unpack it into a folder like ~/mame, run the mameprep script.

 

I was a bit busy over the last months, so the latest version there is 0.258. I'll have to update it again, but as I said, nothing new since then (https://www.ninermame.org/info/releases).

 

Note that you have to use Raspberry OS, not Raspbian OS.

 

Edit: The image that Matt uses for TIPI should not have anything to do with running MAME, or I did not quite understand what you plan to do. Do you want to run MAME on the PI and at the same time, use the PI as the TIPI component?

Yes, I am familiar and already downloaded the file at least onto a Windows system.  I can transfer the file over via SSH.  It will be on a PI 3B, so I am not expecting it to be too fast at the moment.

 

And for your followup question, yes, I was going to play around with MAME connecting to the PI/TIPI on the same setup.

 

Please note, I am a novice on unpacking to a folder so I have yet to figure that part out.

 

I have already ordered a PI 5 that should ship in about 5 to 6 weeks which I want to try that out to see what kind of speed of emulation will exist for the Geneve.

[+9640News]

OK, I got the file unpacked.  Just have not figured out a way to run mameprep.  I unpacked it in a directory under tipi_disk.

 

I opened mameprep up in notepad and see it's purpose.  Right now, I do not know how to execute it.  Forgive me for being a novice with the linux system.

 

Beery

[RickyDean]

17 hours ago, 9640News said:

OK, I got the file unpacked.  Just have not figured out a way to run mameprep.  I unpacked it in a directory under tipi_disk.

 

I opened mameprep up in notepad and see it's purpose.  Right now, I do not know how to execute it.  Forgive me for being a novice with the linux system.

 

Beery

Beery, try putting the mameprep file into the mame folder in Linux. Then open a terminal and CD into that folder.  Then try this command "sudo bash mameprep" and see what happens? You should see activity going on as the script downloads the files needed for tI and Geneve emulation in Linux.

 

Sudo- puts you inter super user mode

bash- is like run in basic

script-the script you want to run

Edited December 9, 2023 by RickyDean
added content

[RickyDean]

@mizapf I understand that you do not have a Mac, in order to build a script to run like mameprep or mameprep_cygwin, but do you know if your mameprep script would run in a Mac terminal and download the files into the mame directory, since it similar to the the Linux terminal? I hesitate to try it fearing I may have to reinstall Mame. But that is always an option.

[+mizapf]

Please don't sudo when you don't really need it! You can install MAME into some home directory subfolder, and mameprep runs in that folder. MAME operations do not require any superuser rights.

 

For mameprep, it suffices to call it by name in the current folder:

 

$ ./mameprep

 

Its first line declares that bash be used for execution.

 

@RickyDeanIf you create a separate folder, just unpack everything there, and your existing MAME installation will not be harmed. Same for Mac as for Linux.

 

As I said, MAME installation is just a local thing. It does not alter anything in the rest of the system.

[+mizapf]

@9640NewsThe problem with the dual use of the Raspberry Pi is that the image from Matt may not have all the libraries installed that are required by MAME. As for me, I'm running the Pi for TIPI on a Raspi 3, while I run MAME on a Raspi 4.

 

[+mizapf]

OK, that's a good moment to create some new builds. Give me some minutes (an hour or so).