mizapf

Do not create a separate studio2 folder. The ROM zip file must be in the roms folder, not in roms/studio2/. AFAIK, you can either unzip the contents into the studio2 folder, or you keep the zip file as is, but in the roms folder. So in my roms folder, I have all the zip files of all systems that I ever tried in MESS. Also, the default for the rompath is "roms", which is relative to your current position. If you want an absolute path you'll need a mess.ini file with rompath set to that path. But then, the mess.ini must be in the current directory. For example: Suppose that the full path of my mess64 executable is /home/michael/mess/mess64. So when I go into that directory, I can start it with ./mess64. Also, in /home/michael/mess/ there is a mess.ini file, and when starting in that directory, mess64 finds that file, and also gets the paths for the roms from there. Now if I decide to launch mess64 from my home directory, I would have to type mess/mess64. In that case, there must be a file /home/michael/mess.ini because I started from there. In this case, mess64 will not find the /home/michael/mess/mess.ini file, since it was not launched in that directory. This is plain Unix-ish behavior, so maybe this is the issue you encountered. As for your Parsec experience, please have a quick look at http://www.ninerpedia.org/index.php/MESS_version_history - just to see that "years ago", we had a pretty different MESS than today. :-)

Not sure how you actually did it, but just to make sure, the ROM zips should not be unpacked. Simply put them in the roms subdirectory. I do not know much about MacOS/OSX, including its search paths. A safe bet could be to create a ~/mess directory, put the executable into it, a ~/mess/roms directory, where you put the ROM zips. I always recommend to create a mess.ini file because you can set some paths and flags in it, for example, for windowed or full screen mode etc. The error message "required files are missing" is typical for the situation where MESS is unable to find one or all of the ROM files.

As a contrast, in Germany we just had the 4th warmest winter according to all climate records back to 18xx. We had three or four days near 0°C, and we had lots of days with temperatures above 12°C (including Christmas) which may be typical for early spring. We had two nights since November with light snow that thawed away till morning. I actually cannot remember a similarly warm winter. In that sense, winter was a complete failure here.

Maybe this could be solved with the mess.ini. You have some path properties right at the start of the file. Start mess with the option "-createconfig". You could try and tell me the error message, and I give you the solution. :-)

- Create a directory for MESS - Create a subdirectory "roms" in the MESS directory - Into that path, put the ROMs of the systems you are interested in - Create a mess.ini by running MESS with -createconfig; modify settings in that file to your preferences - Run MESS. Linux users actually do not require any frontend, since it is much more comfortable to write a small script file to launch the emulation. For instance, this is my ti99 start script: #!/bin/bash ./mess64 ti99_4ae -keymap -keymap_file keymaps/km_de_LINUX.map -peb:slot3 speech -peb:slot8 hfdc $* or for the Geneve: #!/bin/bash ./mess64 geneve -skip_gameinfo -keymap -keymap_file keymaps/km_de_LINUX.map -peb:slot2 horizon \ -peb:slot6 tirs232 -peb:slot8 hfdc -hard1 /home/michael/mess/disks/hd/scsi2.hd $* Exit the emulation by changing into "Keyboard partial mode" using ScrollLock, then ESC. Also, in partial mode you can open a On-Screen menu with settings. I usually ignore sentences that start or end with "everybody knows that".

Right to the point. The official statement is that MAME and MESS are (originally) not written to have "users". I actually do *not* share this attitude, but I know some MAME/MESS devs who do, and I had more than one argument over the years with respect to this point of view. Me, I just don't like to write software that is not intended to be used. So why are users a "problem"? Most users of MESS only make use of a very few systems; in that sense their angle of view is narrower than that of the developers. In our TI community, people usually use the TI-99/4A and Geneve emulation. Of course, for the TI-99/4A there are many other emulators around, and it is certainly valid to compare emulations among each other, in particular concerning ease-of-use. MAME/MESS, however, is not a TI emulator, but a generic emulation framework for some hundreds of systems. You can argue about the sense of having one common emulation core or not, but for MAME/MESS one should accept that this is the definitive idea of the project. C64 users could also use MESS, but many still use VICE or other emulations. And by the way, as I recently heard about Amiga users here, the Amiga emulation in MESS is also quite good. Yet, I think the UAE emulators (WinUAE et al.) are more popular, not least because they are more user-friendly. One big issue is that each system has some specialities that are not applicable for other systems. Since we are running the same core engine, in the end we will get an intersection of features (like disk drives, expansion ports) that we find everywhere. It won't make sense to add system-specific features for each of that hundreds of systems. This also reflects in the user interface. It is very difficult to design a framework that is likewise user-friendly in each facet, compared to a specialized system. MAME and MESS will probably never win a prize in that category and accordingly do not even try. Instead, the MAME project and its sister project MESS understand themselves as an endeavour to preserve the history of computing technology, like a museum. With that intention in mind, there is indeed no immediate pressure to make it "user-friendly". With the analogy of the museum, you let people in, but you don't care whether they feel comfortable. Even if there were only a few visitors, the museum is still there. In particular when it does not cost anything. In the last years, new devs have joined the team, and as it seems, the attitude begins to shift a bit more to make it better usable, maybe also because in the meantime, MAME and MESS are appreciated for their emulation quality by a growing user base. There are indeed some enhancements like attachable, specialized user interfaces as work in progress. Just give us some more time; the project is still evolving.

If someone of you already got a new copy please get a new one right now; I found another issue with CRCs caused by TIImageTool which has not shown up before because neither TIImageTool nor PC99 nor the old WD1773 emulation in MESS actually cared about CRCs. But the new WD1773 implementation in MESS does.

Hi there, just a minor update to TIImageTool because of these two issues: 1. When you copy into a directory and you get a message that a file already exists and you want to skip that file, the dialog popped up for each following file in the list. 2. When writing into a track dump image (aka PC99 format), the sector contents were shifted by one byte, and CRCs became invalid. I don't know why this actually worked for so long, but it was definitely a bug which should have broken PC99 images when writing. Both bugs are fixed; I recommend to get a fresh copy via http://www.ninerpedia.org/index.php/TIImageTool Michael

I'll be here, waiting for you to ask some sensible questions. MESS is not intended to make it as simple as possible to you, but to emulate the systems as precisely as possible. You should better try another emulator if it does not suit you.

MESS and TIImageTool have been supporting this PC99 format for some time now, but as I learned there is a little glitch in there, concerning the single-sided formats, and while I'm working on the floppy modernization, I guess this is a good time to fix that. Is it correct that PC99 stores single-sided formats into the same image files as double-sided ones, just leaving the second half uninitialized? This would mean we have only two valid sizes: - FM recording (single density): 260240 bytes - MFM recording (double density): 549760 bytes each one for both single sided and double sided images. Are there any other known formats for track images? (80 tracks? 36 sectors?)

We know that floppy drives can be used for music, but a dot matrix printer? Have fun.

What MESS version are you using? MESS can use the serial port, but only with an additional tool that I wrote (TIImageTool). I use a serial connection between MESS and my real Geneve and it works pretty well, also with TELCO.

Two TI RS232 cards if one card is configured for the second CRU area (1500). Only one 32K memory card can be used.

BTW, in MESS you can start with the option -debug to activate the debugger window. Press F5 to let the emulation run, then continue as usual, load the game, click on the debugger window again, press F11 to stop the emulation at the next operation. Press Ctrl-M to open the memory window, then type 7000 in the input field (or any other address), and that way you can check the memory contents.

In MESS it loads at 7118 (entry point START at 740E) to 7DF8. You should, however, disable the internal 16-bit memory expansion (OSD menu, "System configuration"). I noticed that when it is on (default), the program is loaded into the memory expansion. Which, by the way, causes a crash when you try to run the program after restarting the computer because the entry in the DEF table is still there, but it points to a memory area that has been wiped.

Ah yes, what I actually wanted to say is that more advanced chips like the WD1773 were used. It's not correct to say that all other cards used the same WD1773. (I wrote that message on a tablet while sitting in a train, so I was actually glad to have somehow completed and submitted that message ... :-) ) I just checked the photograph of my DDCC-1 controller from Myarc, and it shows that the WD1770 was used. It is a bit confusing to see that the WD1770 had more capabilities than the WD1771 (aka FD1771).

All later cards from third party used the more advanced WD1773 controllers from the same family. For an upgrade there are some problems to solve: - The MFM-capable controllers need a higher clock rate (8 MHz vs. 1 MHz for the 1771) - Also, data separation circuits may need modification. Apart from that, the 1771 and 1773 are quite similar. There are specs available; search for FD 1771.

It's the controller chip FD1771 which does not support double density.

It's *1+ or *R1+, not @*1+. (If you prefix the register numbers with an R, do not forget to add the "R" option when assembling.)

It is somewhat disappointing to see that after decades and generations of AI researchers, we are still far from a "universal translator" like in Star Trek which instantly translates between languages. Apart from the fact, of course, that this is not even possible if we had the computing power, just because of the different concepts in the languages. The best results so far come from Google - using a brute-force strategy, and nothing really intelligent.

There is a cartridge as a MESS RPK that combines Editor/Assembler with Extended Basic. Maybe someone actually invested the effort to rewrite all addresses in the E/A GROM. Just unzip the attached ZIP container (rename it to *.rpk to use it in MESS). ea_exbas.zip

Hello Jens-Eike, great, thanks for the specs! I just saw that in MESS we actually have the Epson SMD-165 with 40 tracks at 3.5", just had to scroll down the file to the end. :-) @Ksarul: Indeed, I just noticed that there is also a class "floppy_525_qd" with 80 tracks and 300 rpm. The 360 rpm apply to the HD drives only. I hope that once I'll have switched to the new floppy system I can finally do what I've had in mind for so long: Adding drive sounds! I recorded some samples of my 3.5" and 5.25" drives, and according to the other devs it should be pretty easy.

Do you happen to remember the drive name? In MAME/MESS we currently do not have any 40-track 3.5" drive; this will have to be added. DD is MFM, SD is FM recording, so this definitly matters for the controller. Also, for higher densities (like 36 sectors/track), magnetic cells are half as long, so transfer rates are doubled. If the rotating speed were the same I would not have bothered, but when I saw that the 5.25" HD drives are rotating at higher speed I started to wonder whether anyone is known to successfully attach such a drive. I believe most people directly went for the 3.5" drives and did not even try a 5.25" HD drive. Background: I'm currently updating the floppy support for the TI systems in MESS to catch up with the latest emulation features (and, in particular, to allow legacy code to become obsolete at last). Indeed, disk images are now read and converted to magnetic flux sequences in memory, and the emulated controllers really need to interpret FM or MFM recordings.

Two questions: 1. Are there 40-track 3.5" drives? All drives I found specify 80 tracks. I know there are HD disk media (with two holes) versus DD disk media (with one hole), but both are using the same track count of 80. I actually have a 3.5" drive with 80 tracks in my PEB which I use to boot my Geneve. 2. Has anyone ever used a 80-track 5.25" drive with the TI/Geneve? 80-track 5.25" drives were the latest class of minifloppy drives used in PCs; they were also called 5.25" HD drives (for disk capacities of 1.2 MiB). I just learned that the 5.25" drives have an interesting property: they are rotating at a higher speed (360 rpm instead of the standard 300 rpm). I would expect problems with DSRs that expect 300 rpm. The background of my question is that for the next evolution step of MAME/MESS I have to take care whether the attached floppy drive is compatible with the inserted disk image. For instance, it does not make sense to use a 5.25 drive and try to read 80-track images if this combination is not realistic; this must cause a read error.

OK then, here's the image as produced by TIImageTool. map2.zip