mizapf

If you search for "Wumpus" and "artificial intelligence" you will find an abundance of papers, slides, and references to AI literature. However, I don't know which one was first - the game or the application in AI. I presumed it was an original AI problem, but as I saw, it may also be the opposite. Anyway, the Wumpus world is well-known in AI but not for the game.

I would like to add Moonsweeper. Although it had some elaborate graphics, this was mainly all it had to offer. while (ships>0) { Shoot some objects in the orbit; Go down on a moon; Pick up people; Lose some ships because of being hit by alien missiles; Don't miss the accelerators; Go back in orbit; } That is, you had a good chance to see the complete gameplay in the first minute.

Hunt the Wumpus was never intended as an *action* game. It is a sample game for Artificial Intelligence. People in that area know about the Wumpus but usually can't believe we put humans in control. :-)

Makes sense to add PFM to MESS, I guess? (oops, a rhyme)

Use the "-mouse" switch at any location in your command line. This will make the emulation capture the mouse (some of the menus release it temporarily, but I'm also waiting for a better solution, like a capture/release key), but it will not have a visible effect beyond that unless you start a program that uses the mouse (like my Fractals program).

One thing to keep in mind - if you change settings in MESS you may have to reset the emulation (F3 in partial mode) to make them effective. Only a few settings have immediate effect. Back in 1990 there were certainly some people who asked me whether it made sense to spend a lot of money on an abandoned platform. It did, in any respect. Now that I know the TI-99/8 I must say that actually a lot of things were done in the Geneve in the right way. There's still potential for more, but what we had and have is a really well done machine. And it turned out that most of that Myarc bashing all over the time was not only inappropriate but utter nonsense. What I'm sometimes missing in my Geneve is a EEPROM where you could store things like boot device, just like in a PC. Of course, there are always some more ideas for the Geneve OS (MDOS), but this does not depend on the hardware. For MESS users: Remember to use the command line switch "-mouse" to get mouse support in the Geneve emulation.

TIImageTool says that there are some files on the HD image that are suspiciously not OK. Maybe some of them will run nevertheless, but if you look at XCOPY the last sector is filled with e5. This need not be an issue because it means that the file is simply one sector too long. For all reported files one should check whether the problem is caused by the tail of the file and not in between. If this is OK for all, I will upload a copy of that hard disk image to WHTech and put a link on said HTML file. ... Robert, concerning the tools in Linux, there is far more to be discovered, and although I've been using it for the last 15 years I suppose I did not even find out all goodies. Ever exploited all features of the "find" command? For instance, find all directories in a subtree and change their permissions? Or use a script to turn all file names to lowercase (since the Windows users still don't know about case sensitivity in other worlds). Or take your list of photographs, throw away some of them, and renumber all files contiguously. All things that can be done in a few lines of script. Also, if you want to clip off the last 256 bytes of the file, you can use split and tell it to create pieces of (length-256). And more.

BTW, you can create your custom HD with TIImageTool, open some of these prepared other HDs, and copy parts from there to your own drive. Mark some files or directories, press CTRL-C, paste them with CTRL-V into your new image. Oh, and pay attention (and everyone using this HD image)! This is an outdated MESS HD format. You can convert it in TIImageTool to the new version 5. I recommend that someone replaces the MdosGpl files with new ones pretty soon. One of the most notable features of the CHDv5 format is that it produces much smaller images since it does not store tracks that are filled with zeros. (That is, if the image is full, it will of course not be smaller.)

$ cat MdosGpl.zip.001 MdosGpl.zip.002 MdosGpl.zip.003 > mdos.zip $ unzip -t mdos.zip Archive: mdos.zip testing: MdosGpl.hd OK No errors detected in compressed data of mdos.zip. $ unzip mdos.zip Archive: mdos.zip inflating: MdosGpl.hd $ cat is the command for "catenation"; it can be "abused" to output data from text files (and thus plays a role like TYPE in MSDOS), but indeed it copies the contents of the argument files to stdout, one after another, without any change. So you want to redirect stdout to a file, and hence I'm using mdos.zip in this example. Works for me without any problem. So your "does not work" should have worked; you did not say why it did not for you.

You know that you can use "cat" to join files in Linux? cat file1 file2 file3 > filecomplete (and split to do the opposite). No need for WINE. Michael

We should collect the most important tools for the Geneve at a location like WHTech. I already started to create a web page on WHTech some time ago: http://ftp.whtech.com/info/geneve.html (note the http access to the ftp server!) This is intended to become a helpful page for Geneve newbies, in particular those who got to know the Geneve via emulation. I have write access to WHTech so if you send me appropriate images I can upload them and complete that page. We can then store all important programs on disk images or as single TIFILES files.

Matthew, I fully second this, this is pretty much what I warned about some weeks ago. I don't want to discourage people from trying new paths, but they should be aware that this means to abandon the TI to some degree. I already did that back in 1990 when I got my Geneve, but in the hope there would be enough users around. However, I have to say the 9995 is superior to the 9900 in almost any conceivable aspect, so it very much makes a difference. When I recently verified the cycle times in MESS for the 9900 I was once more startled to see how slow the 9900 is in comparison to the 9995, which can do many things in a single machine cycle. Just as an example, a ADD R0,R1 needs 14 cycles (@333 ns) for the 9900 with register in scratch pad but 4 (four!) cycles (@333 ns) on the 9995 with registers on-chip. My dream machine, by the way, would be a TMS99110 or similar together with a 9958, some RAM, PC keyboard, mouse, and sound. I imagine I could create something like this as a pure virtual solution in MESS some day. I mean, why should that be less fun compared to a hardware solution? Just need some more people to write an operating system.

Well, then we're back at the question which a former collegue of me laughed about when I was asking "why does it work"? Other people seem to be satisfied with the fact, not me. I think I remember some of those discussions (it should not be wrong to say some of the SNUG people are not really friends of Myarc) that there were issues with the Geneve and the BwG. Either this was solved in a later hardware layout, or with some minor mod. One way would be not to check for access to 5FF7 but 5FF6 (cut the A15 line); this should be sufficient for both TI and Geneve. I'm currently fixing the ti_fdc (standard TI controller) which has multiple problems. One interesting thing that I found is that the TI controller has bad problems reading a file information block with a file status flag 90 (meaning DIS/VAR, modified). It only accepts 80 (DIS/VAR, unmodified). This modified flag was added later, and it seems to bother the old controller.

I just tried it on MESS; feels a bit slow (somewhat like a BASIC program), but MESS runs at full speed here. I don't know how fast it is supposed to be, though.

If it starts, your RPK definition is OK.

One problem remains for the BwG, which is there for a longer time, obviously: When reading single density, the BwG sometimes fails to read the file on the first attempt. The problem is that the BwG always tries double density first (also after a "floppy restore" command) and when it fails, tries to read it as single density. However, the images in MESS deliver data even when accessed in the wrong mode (because the sector dumps do not contain information about density), so the controller falsely assumes that double density (with 18 sectors/track) is OK and fails to find the next sector if it is beyond sector 8 in track 0. --- The double density problem was pretty difficult to find out. The controller was unable to write any sector; reading was OK. I found out the solution in many small steps by log analysis: - We want to save a file - The controller reads the sectors 0, 1, and 2, which works flawlessly. - The controller tries to write sector 1 - After writing it tries to verify the sector data - Verify fails. The controller retries several times, then gives up and switches to single density. - The image is still formatted for 18 sectors/track, but now the controller assumes 9 sectors/track. - The controller creates a file information block in sector 3. It says the contents are at sector >22 - Now the controller divides the sector number by 9, thus calculates a wrong track, and writes the contents to the wrong location. - As a result, the file shows up in the directory, but the contents are gone. Why did this happen? - After saving the DSR tries to read the sector again - The read sector operation is triggered on the WD1773 controller - The sector is found, the first byte is being assembled. This takes 8*4 microseconds. - Meanwhile a SBO 2 is executed. This connects the DRQ line with the READY line, and accordingly, the CPU goes into wait state. - When the byte is complete, the DRQ goes to 1, and the CPU continues. - The program now heads for the compare loop while the next byte is already being assembled - Unfortunately, the CPU needs about 40 microseconds to reach the compare loop after the SBO 2. - This means the first byte is overwritten by the next byte, and verify fails. I had some discussions with Harald Glaab who wrote the DSR. As a matter of fact, there are way too many commands between the SBO 2 and the CB @>5FF6,*R2. Using the cycle table you can calculate that you need more than 118 cycles to reach it, and 32 microseconds are just 96 cycles. I had a closer look at the schematics of the BwG. There I discovered that the address bus lines A13-A15 are combined with the DRQ, which delivered the answer: The wait states are created as soon as the address 5FF7 is read. Why 5FF7? Because the TI-99/4A always reads two bytes, the second byte first. Accordingly, the program proceeds until the CB line is reached, and then the wait states are created, so it need not hurry to reach the compare loop in time, in particular because the first byte takes longer to be read (have to find the sector first etc.). The implementation in MESS did not contain any check for the address bus, but since the emulation was not cycle-precise at that time, the controller worked as expected. Now, after I rewrote the core to operate on cycle precision, the controller indeed failed. This had another consequence: I had to remove the BwG from the Geneve emulation because the BwG should not be able to work with the Geneve. Remember it waits for address 5FF7 to be read - but the Geneve only reads single bytes, not words, so it will never trigger the wait state creation and will receive lots of wrong values from the WD1773 because of premature access.

It was very fortunate that Ciro got a pretty "advanced" console; remember how many (of the few) TI-99/8 consoles are out there with missing speech, missing Pascal, or other defects. I sent Ciro dump programs (written and tested with the emulation of the 99/8 in MESS at the previous maturity state) that were intended to save the GROM contents to disk. This worked quite well. The problem was now that Pascal still did not work. In the schematics one can find a ROM (16 KiB) which is named "P-Code ROM" (aside from the GROMs). However, neither the specifications mention this ROM, nor does the schematic of "Mofetta" alias "Skunk", one of the custom chips on the board (the physical address mapper). That means I knew of that ROM, but not where it can be found in the 16 MiB address space. With the recent dumps from Ciro I was able to find out the position; for that it was important to have a consistent set of ROMs from a working system. Then I used log outputs and the MESS debugger to find out where things start to go wrong. I noticed that a new physical address was set in the mapper that was not used before or mentioned in the specs (f0xxxx), so I updated my dump tool to try to dump the 16 K starting at that address from Ciro's console. As it seems, we hit gold. The next thing to be done for the TI-99/8 would be a Hexbus floppy emulation. This would be extremely helpful because the built-in Extended Basic II requires a Hexbus floppy.

Yippieee ... dancing in circles ... :party: look here, what do say to that!

Just to inform you if you are using some recent MESS release: I fixed an issue with the BwG controller which corrupted double density images on write. This fix will be available with the next release (0.152). And, by the way, we may have the first complete 99/8 emulation with that release. As it seems I have a complete, consistent ROM set by now.

TIImageTool has a disassembler for ROM images as well as for D/F 80. It can store your specific settings for a file (like data and text lines and so on). You just have to put the ROM dump on a disk image ("Import plain binary file").

You should not unzip the RPK unless you really want to change something inside. It's just like the OpenDocument (odt) or Microsoft's OOXML files (docx) which are ZIP containers as well. I believe if I called them *.zip instead of *.rpk, everyone starts to unzip them first and asks later. Anything concerning the dsk images can also be done easily with TIImageTool (create, copy files from/into them, rename, view archiver files, ...)

Yes, significantly more. I rewrote the CPU core from scratch; it is now based on a microcode interpreter. All instructions are executed by (virtual) clock ticks, including setting signal lines, checking incoming READY, and more. Previously the emulation more or less simulated the behavior by result, now by process. I noticed that the software renderer causes some additional load, which is lower with the opengl. As far as I know there is a way to use multithreading for video output (see mess.ini) which can lower the load a bit further. As MAME/MESS is not multithreaded beyond that, it only runs on a single core, so on my Core i7 the top command reports a CPU load of about 30% for the TI-99/4A and about 40% for the TI-99/8 and Geneve emulations.

Yes, the machine must have some good performance to run MESS. I was told from Robert that his Pentium 4 2.8 GHz has problems with the recent MESS versions, so 1.8 GHz on a x86 platform is way too slow (even with dual core). You may gain some speed by using opengl as video renderer and a fast display driver. This is a quite general statement which I (luckily) cannot second.

I think it's not meant to be off-topic but it should be better preserved. I'm thinking about a section in ninerpedia. Still, it is not really easy to write a comprehensive manual that is at the same time quick and simple to read. The questions raised here may be interesting now, but the benefit of a sequence of questions and answers is not for sure. Pictures of FAQs with hundreds of entries come to my mind.

If you tell me more I may be able to help here. What is "not nicely"?