mizapf

What is also dangerous for the 9901 is when you connect a pin to e.g. a switch that closes to ground, and then reprogram that pin from input to output. I discussed those scenarios on Ninerpedia some time ago (in the scope of my knowledge). https://www.ninerpedia.org/wiki/Programmable_Systems_Interface_TMS_9901#Safety_precautions

Not likely because the TI produces pseudo-random numbers only, and those are perfectly emulatable.

HTTP/1.1 306 Curse redirected

We have a P-system on the Geneve?

There is no READY line from the VDP to the CPU. Would have made a lot of things easier.

Actually, at some few points in certain games I fired up the Adventure Editor and looked inside. Savage Island 1 is yet another candidate of suspended logic (if I remember correctly, this was particularly the question of the nature of drying puddles and behavior of hurricans).

I recently re-played all Scott Adams Adventures from 1 to 12, and this was really an angry moment. I think there was some logic, but really far-fetched. Something with a black heart of the statue. Yes, spoiler, but that one does not deserve a better fate. 🙂

Ah, sorry about that drop-down menu - I thought you were using the serial bridge inside TIImageTool (with GUI). If you start it normal, what happens when you select Serial bridge in the Utils menu? Edit: I'm getting the same error with BRIDGE, but not when I launch TIImageTool and use the menu function.

This is an unofficial update. I have to admit that I've created a true mess with the TIMT development that I am currently sorting out. My problem was that I went for a major update two years ago, but it was so major that I could not finish it during my free time. So I continued with small steps, but there were bugs every now and then, and then there was the update of RXTX (which was abandoned in the meantime, then someone else came and fixed it), but this release does not work with the 2.4.7 anymore. So I maneuvered myself into a no man's land of releases.

Could you try this version of TIImageTool (2.5)? I think there may be some issues with the integration of the renewed RXTX and the older code of TIMT 2.4 timt25.jar

THROW RUBY (in pool) 😠 I'll never forget that one...

OK, it's generally working. Do you get a dialog window that allows you to select between those interfaces? ("Serial adapter [v ...]", drop-down menu). Usually, I'd expect that if there is a problem with the detection of the serial ports, you should already get an error message at that point ("No serial ports found"). If it finds some, you should be able to select one of them, and then it tries to open that port. What version of TIImageTool are you using?

Can you build and run this, together with both rxtx jars in the classpath? import gnu.io.CommPortIdentifier; import gnu.io.DriverManager; import java.io.IOException; import java.util.Enumeration; /** * rxtx Hello world! * lists all available ports on std out */ public class RXTXTest { public static void main(String[] args) throws IOException { DriverManager.getInstance().loadDrivers(); // list all available ports System.out.println("listing ports:"); Enumeration<CommPortIdentifier> identifiers = CommPortIdentifier.getPortIdentifiers(); while(identifiers.hasMoreElements()){ CommPortIdentifier a = identifiers.nextElement(); System.out.println(a.getName()); } } } Edit: I built it already, just take this one. RXTXTest.class

Is it really /dev/ttyUSB0? And if so, do you have access to /dev/ttyUSB0? (i.e. are you in the dialout group, as it is typically required?)

I'm using openjdk 11 and these files (attached). Unpack them in some folder and add them to -classpath. This is working for me, just tested: java -classpath /home/michael/lib/rxtxapi.jar:/home/michael/lib/rxtxbin.jar:/home/michael/lib/tiimagetool.jar de.mizapf.timt.TIImageTool (I put the files in the folder /home/michael/lib.) rxtx.tar.gz

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?

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?

Whenever I ask my students about HTTP status codes, I hesitate to ask for 404 because everyone knows it. Nope. Not anymore, since the servers or the browsers themselves start to give you weird textual answers like "oops, this should not have happened..." or "I'm sorry, I did my best but could not find the page you requested" or other b***it.

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

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.

Oops, it's working now. Guess how? - I left away the RS232 card. Ah, and speech is working too. The only glitch left is that it says "Welcome to Pinball on the TI-99/4A computer". Should sound more like "Geneve" .

I should say that I don't get too far when starting Pinball. The last thing I see is "Loading program...", a graphics mode switch with something flashing up, then black screen, the speech synthesizer says something like "ho...", and the sound generator starts with a faint noise. The way I usually track down such an issue is that I activate the log to see if there is something like a crash (like here, MID triggered), and then I activate the logging of memory locations in the source code of the 9995 (LOG_EXEC) and recompile MAME. By that I can see where the execution was when the error occurred. Then I use the debugger of MAME (-debug) to set a breakpoint near that location.

@InsaneMultitaskerThis is the point where it happens; it's code from PINLOAD. I'm not sure what it tries to do here; R12 is set, but no CRU operation, could be. But then it gets a word from 400c which is (see the memory dump) some arbitrary value (63d7) which is not even suitable for the MOV at 1a54 because it is an odd number. R11 is then filled with F0F0 because this is what you find at 63d8. The words at that location look a bit like character definitions; definitely not a jump table. I'm not even sure we are at the proper location here or if the error occured earlier. The only thing I know is that on BL *R11 (really? this will overwrite the current R11) we land at F0F0 which contains a 0000, which then triggers MID.

When I tried to run pinball (1.5) on the MAME Geneve I got an illegal instruction (MID). Is that what you mean?

To my understanding, all pages B8-BF are sent external into the PEB. It makes sense to map BC to 8000 if it contains code (for the absolute addresses), otherwise you can map it anywhere. I described it like this: https://www.ninerpedia.org/wiki/Geneve_physical_memory_map and https://www.ninerpedia.org/wiki/Geneve_logical_memory_map