+InsaneMultitasker Posted July 18 Share Posted July 18 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 1 Quote Link to comment Share on other sites More sharing options...
+dhe Posted July 18 Share Posted July 18 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. 1 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted July 18 Author Share Posted July 18 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). 2 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted July 18 Share Posted July 18 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 3 Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted July 19 Share Posted July 19 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! 5 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted July 19 Author Share Posted July 19 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? 1 Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted July 19 Share Posted July 19 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. 1 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted July 19 Author Share Posted July 19 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? 4 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted August 23 Author Share Posted August 23 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 5 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted August 31 Author Share Posted August 31 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/ 2 2 Quote Link to comment Share on other sites More sharing options...
+dhe Posted Saturday at 11:24 AM Share Posted Saturday at 11:24 AM 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? 🙂 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted Saturday at 07:03 PM Author Share Posted Saturday at 07:03 PM Nothing new in MAME 0.259, TIImageTool 3 nearing completion (with lots of enhancements). Surprise: Fall begins everywhere on Sep 23. 🙂 4 2 1 Quote Link to comment Share on other sites More sharing options...
globeron Posted Saturday at 07:32 PM Share Posted Saturday at 07:32 PM 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 ! 2 Quote Link to comment Share on other sites More sharing options...
JB Posted Sunday at 12:53 AM Share Posted Sunday at 12:53 AM 5 hours ago, mizapf said: Surprise: Fall begins everywhere on Sep 23. 🙂 Except Australia! 1 4 Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
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.