mizapf

v9938: The EVPC and Geneve emulation currently do not support 192 KiB VRAM. When I last tried it, the additional VRAM was not detected in MEMTEST on the Geneve, so I removed it again. If it will be supported in a later release, you will find an option in the on-screen menu under "System configuration". SCSI: There is no SCSI emulation yet. You can use TIImageTool to convert a SCSI image to HFDC format and back. Files import/export: MESS requires you to use a disk image in sector dump (v9t9) or track dump (pc99) format. TIFILES files are not recognized by MESS because it can only work on disk images, not on files. One of the main features of my TIImageTool is to make it simple to interchange files between the emulators by importing / exporting files on images. You can use a TIFILES file and import it into the disk image, and you can export a file on the disk image which creates a TIFILES file. So that is what Robert already wrote, but MESS itself is not involved.

You would have to replace the FD1771 controller with a WD1773 or higher, and possibly also the data separator, and finally write a new DSR. The 1771 on the card simply cannot do double density.

Here's another program using the v9938 on the Geneve. I uploaded the disk image here: http://www.mizapf.de/ti99/xmas.dsk. Just download the disk and use it in MESS or copy it to a real floppy disk and run it on the real Geneve. Start the program by entering XMAS on the GeneveOS prompt. The current directory must contain all the files on the image. This is a TIC program which features - using G6 mode and video commands in C - playing 3-voiced music by notes from a list Have fun.

Hi Rich, I just watched your video (about half-way, not completely). One thing I have to say is that the v9938 emulation in MESS is of low quality, not comparable to the TMS 9918/28. For instance, the colors of the palette do not look correct. I have my real Geneve side-by-side, and there are differences in the saturation of blue and some other colors, but not completely different hues. There is a long standing comment in the file, asking for somebody's favor to modernize the implementation. The G6 and G7 modes should be correct. What could be the case is that the other modes show wrong behavior. I do not know what modes Alexander used in his XHi demo. It would be necessary to verify all operations of the demo step-by-step and see where we have differences. It need not even be the color palette, maybe the command implementation is faulty. Maybe I can verify some points if I can get Fractals to run on the EVPC.

Robert, concerning your profile icon, you're not seriously showing us you losing a base in round 1 of TI Invaders? My goodness. First base to lose is at about 4000 points on a bad day, really. TI Invaders was my very first game cartridge which I got for Christmas 1982, age of 13. I'm not quite sure how far I got over time; at least until the magenta, pulsating, button-like enemies; I think there were some blue blinkers even later (first blinkers are green). And I got to the xxx in the mothership round (hitting the 500 points). Maybe we should start a competition in old TI games? There was a suggestion from Wolfgang Bertsch at the last meeting in Eindhoven, using the Errorfree website: http://www.errorfree.de/Menu16.html

"Check filesystem" was one of the first features of TIImageTool because I needed a tool to verify that the disk images were correct which I created by reading my TI floppy disks in a PC drive. So maybe these lost sectors also come from bad imaging.

If you are talking about the e5 bytes, yes, seems to be a lost sector. But I just saw you have the same graphic output issues as I have. This started to occur just recently, maybe a current Java release. I mean, this is a standard JTextArea I'm using, what could be done wrong?

You must enable the mouse with the "-mouse" command line switch when starting MESS. This will capture the mouse for the emulation. You'll see that you get a text mode mouse that you can use to select a language.

If you use "Check filesystem" in the "Utility" menu you can make TIImageTool check each file for signs of corruption. Of course, in this case, it won't bring back the original contents. :-) (Have to add a time machine in some later release.)

To be precise, if you stop early (after 15 iterations) you will falsely paint a location black that is not member of the Mandelbrot set, so your black shape is a upper approximation to the real shape. It actually looks similar, but if we had a much higher resolution and iteration depth we would see that the big right part and the first one on the left are actually connected by a single dot, just one point on the real axis. BTW, the whole Mandelbrot set is simply connected (which is hard to believe when we see the complicated patterns). That means every closed path in the set surrounds only set members.

One more point to Mandelbrot set generation: If some of you are using a recent KDE desktop, have a look at the Background settings. There is a Mandelbrot set generator which actually allows to zoom into the graphics with the mouse wheel. Unless you are doing it with a maximum quality setting, the regeneration is tremendously fast. Well, it makes use of all my 8 cores, there should indeed be a good speedup. But even with 1920x1200? Wow. Adding a picture here. (No, this is not from my FRACTALS program :-) This is the seahorse valley (where the big black, apple-shaped part on the right and the part on the left approach.)

The gcc is freely available; I guess you can find that in your software installation management. Unfortunately, I do not know enough about OSX to give helpful advice.

Rich, if I understood you correctly you are using OSX. I don't understand why there are issues for you building or running MESS under OSX. Don't you have a gcc compiler? Also, within Windows, the recommended tool chain is MinGW. Nothing about Visual Studio or so.

Download link: http://www.mizapf.de/ti99/fractals.dsk I just took the time ... for the standard image (whole Mandelbrot set; -2.6 < x < 0.9, -1.25 < y < 1.25) the program runs 76 minutes, with a maximum of 100 iteration per pixel, 512 x 212 pixels on screen. The number format that the program uses allows for a resolution of 2^-48, which is 3.5*10^-15.

If you use TIImageTool you'll notice a menu item "install Geneve OS" in "Utility". Use an existing image or create a new one and select this item. You can then use this disk image to boot the Geneve in MESS. (Of course, you need the geneve.zip from the ROM collection.)

The last version of Fractals was intended to run on the EVPC, but I did not quite succeed with that; there were some memory issues. My particular problem was that I did not have an EVPC card and a TI console to test it outside of the Geneve, so I depended on reports from other people. Of course, now ... I could finish that by using MESS. The program was written by me to fully exploit the on-chip RAM of the 9995. I wrote a multiplication and an addition procedure based on fixed point arithmetics (1 word integer, 3 words fraction) that fit completely into the 256 bytes (together with workspaces). So it became really fast. Recently I tested Fractals on MESS against my real Geneve to fine-tune the timing in MESS, and both showed slight differences (fractions of a second) not before several minutes had passed. I can upload a copy (disk image) here.

Does this count (I posted it half a year ago already)? It's running on the Geneve, though. In my FRACTALS program I made use of several 9938 features: - Clear screen with fill command - Multicolored mouse pointer - Graphics mode 6 (512x212) - Definable color palette - Zoom window is drawn with line command using XOR mode - and mouse, of course.

Die Barbaren kommen so oft ... = The barbarians come so often ... Yes, there are similarities. :-) As one can see, writing a parser may be more challenging for some languages than for others. By the way, the longest German word officially used was Rindfleischetikettierungsüberwachungsaufgabenübertragungsgesetz, the beef (Rindfleisch) labelling (etikettierungs) supervision (überwachungs) duties (aufgaben) delegation (übertragungs) act (gesetz), appearing in the Mecklenburg-Vorpommern parliament, which was reported to have triggered quite some amusement among its members.

Difficult to type this text because I'm partly still rolling on the floor, laughing. You don't need to understand German. But now you might find a reason why to learn it ... or maybe not. The story is about a girl called Barbara with her Rhubarb pie. Enjoy. (No, we don't usually build such words. But we could.)

Here are pictures of the consoles: http://www.ninerpedia.org/index.php/Hardware

Maybe until then MESS is good enough so that I do not need the real hardware anymore. It's hypothetical, anyway. I wanted to point out something beyond. Gregallenwarner saying "the F18A actively supported ... eventually, the last 9938 will fail" hits me as a Geneve user, as it sounds in my ears like "why bother about the 9938", and this is something I certainly won't agree with. There are still people with a 9938 in a Geneve or on the EVPC (80 column card). The F18A is not intended to show 9938 compatibility. But it should be reasonable to include some kind of auto-detection in future code to adapt to either one of the chips as far as similar features are concerned (like 80 cols). This should be possible.

This will be supported by my TIImageTool in one of the next releases, maybe some time next year. (Sorry, cannot give you an earlier delivery date.)

The day my 9938 fails will be the day when my TI (more specifically, Geneve) hardware era will be over. Sad thought. If I'm going to write new software it will certainly support the 9938, but this is a personal preference and has no real connection to the F18A discussion.

Is there a description of that GPL assembler? Because in that case I could add a compatibility mode to the GPL disassembler in TIImageTool to produce code that can be assembled.

There is a difference between internal labels and external labels. If you use a DEF, the label will be put into the object code so that the linking loader can resolve REFs with it. If it does not appear in a DEF or REF, the symbol length is just a matter of the assembler. [Edit: I was too slow... ]