mizapf

From time to time I still learn new things in Java ... The first invocation (with -jar) made the class loader fetch the ti.image.TIImageTool class (declared as the main class within the jar manifest), which references some Swing classes (graphic toolkit). Although no window is brought up, this seems to imply a lot of additional (but useless) class loading, maybe also initialisations in static parts. The second variant loads ti.image.CommandShell which does not reference TIImageTool itself but only the support classes for interpreting images. Accordingly, no Swing elements are loaded, and things become much faster. The HFDC has support for floppy directories, but (as with GeneveOS) only for three subdirectories in the root directory and no deeper nesting. The SUBDIR argument is comparable to the argument of directory list commands in DOS or Unix shells. That is, if you have a directory ABC on your floppy disk or hard disk, you get a directory listing of ABC if you add it as the final argument (CommandShell dir imagefile.dsk ABC). On my hard disk, I can use "CommandShell dir myharddisk.hd ASM.DIV.PROG" to get a list of all files (and subdirectories) of the directory HDS1.ASM.DIV.PROG. If you have some skills in shell programming, you may be interested in the "lsf" command. It decorates directories with a ".d" suffix. That way you can implement a recursive search in a script file by getting the names, looking for strings with the ".d" suffix, and using them for a new invokation (clipping off that suffix, of course). The lsf command also decorates file names of type DIS/VAR 80 with a ".t" suffix. Again, you may make use of that, for instance, to implement a search tool in a shell script. (BTW, I uploaded yet another version, now including a "type" command for text file output.) Did I already say that I love script programming?

I had the steel box, but there was never a issue with interference. But maybe I just happened to put it in a suitable location behind the TV set.

Dano, try this instead: java -classpath tiimagetool.jar ti.image.CommandShell dir <Image file> This is running substantially faster for me.

The SUBDIR is used to go into subdirectories like DSK1.MYART. or HDS1.ASM.SOURCE. which can be created with the HFDC or with GeneveOS, so you only need it if you have subdirectories on your image. Also, you can list both sector dumps ("v9t9") and track dumps ("pc99") and all supported hard disk image formats. The "ls" command allows you to collect the files and directories in a list for further processing. I'll check the issue with the speed (didn't notice). It only makes limited sense to accept a collection of image files in the command line with e.g. "*.dsk", because if you actually have a large number of disks the shell buffer may not be large enough to hold all expanded path names.

Get the latest update (1.55) from WHTech ("PC utilities") or http://www.ninerpedia.org/index.php/TIImageTool You can invoke the command interpreter by passing the argument "CommandShell" to TIImageTool in the shell: $ java -jar dist/lib/tiimagetool.jar CommandShell dir ~/mess/disks/geneve/gdisk01.dsk SUBDIR (as an example; use your paths appropriately). Instead of "dir", you can also use "-h" (help text) or "ls" or "lsf". You can pass a final argument as subdirectory name. Check whether it suits your needs.

I can only read object code for some few commands, e.g. when I search for a LI Rx,>yyyy, DEC, JNE. Apart from that, I seemed to have substantially impressed my students in the beginners' lecture by converting decimal to binary, hexadecimal and back ... in my mind. I had to admit, though, that I can do that for numbers up to 255, and that I know only a couple of special numbers with 16 bit. ("You know that there's a known number close to that one, the 49152, aka C000 ... well, maybe you don't, anyway ...") And that there is a reason for my skills ending at 65535. People just don't learn mental arithmetics anymore.

Sigh ... my TIImageTool *had* that feature some releases ago, but I pulled it out because it seemed to have become obsolete. Maybe I can put it back in. There were two commands - "dir" produces a full listing, and "ls" only delivered the file names. (You know Unix-like systems, I suppose.)

The 16/8 multiplex is not such a big problem; mind that modern PCs may also need to do something similar (64/32 bit multiplexing) when memory is not configured to allow a full 64 bit access. A much bigger problem is that the TMS 9900 processor supports byte operations while it has a 16 bit architecture. AFAIK, Intel chips have (had?) a control line to turn off a part of the data bus, but this is not available for our processor, which, accordingly, has to perform this awkward read-before-write. The TMS9980 also has a 16 bit architecture with an 8 bit data bus and suffers from the same issue. The problem was solved with the TMS 9995 which can indeed address bytes with a single memory access. If only we had that processor for our 99/4A ... (and they messed it up again in the 99/8). It is one of the major reasons why the Geneve is so much faster than the TI (although the 12 MHz clock is divided internally by 4).

I think it really depends on the emulated system. We certainly did not intentionally implement a brake or so ... In principle, if the emulation remains on a higher level, the performance could be enough. As soon as we apply some deeper emulation detail (e.g. subcycle emulation of the CPU) we may cross the line where performance becomes vital

With the ubiquity of today's smart phones and tablets I can certainly understand that there is some interest to get MAME or MESS running on those platforms. Many people keep saying that the PC is already dying, but I wonder whether those people indeed do their job on a tablet, including text processing, creating presentations, video work and so on. I surely don't, and I appreciate my 24" monitor and Cherry keyboard. MAME and MESS are not designed for performance, that's a major trouble for older PCs and these other devices, also including these micro-systems like the Raspberry Pi, Arduino boards, Beagle Bone etc. When performance is an issue, there may be some point in the design where you have to concede that you cannot get any deeper with the emulation but have to stay on a certain abstract level. As much as I have learned from the project objectives, this is not the intended direction. It is a problem to claim to build an emulation that is as precise as possible but only to a degree that allows it to run on weaker platforms. I would guess the current release requires a PC power of at least a high-end P4 or a Dual core machine; it does not smoothly run on PCs older than about 10 years. On my current Core i7 64 bit the TI emulation of MESS causes about 35% CPU load, running on one core (the 9995 systems, i.e. Geneve and TI-99/8, need a bit more). Maybe later someone will find out how to make better use of parallelism; this would certainly boost performance.

No, the keyboard mapping is required for non-US keyboards to avoid dead keys. In fact, the SGCPU is falsely emulated as having a TI keyboard. I have it on my todo list for almost two years now, but lots of things with higher priority also made it on the list in the meantime. Next thing will be the HFDC rewrite for the modern floppy system, and after that I guess there's indeed time for the SGCPU. :-) What I would recommend is to use the natural keyboard (-natural).

Just a wild guess, but your description of the lockup reminds me of the Pause feature which you get when you press P while in partial keyboard mode. I just mention that because it once happened to me that I thought there was a lockup, but it was just paused as I had forgotten to switch back to full keyboard mode.

Dano, please remember to report any issues with MESS to me so that something can be done about it. Concerning Caps Lock you should redefine another key to become Caps Lock (of course, one that you don't usually need). There is a known issue with the PC Caps Lock key in the MAME core keyboard handling which lets it get out of sync with the emulation; maybe this also applies for the Mac. As this is in the MAME core I did not yet have a deeper look, but I'll put that on my todo list. I do not have any reports about lock-ups in the Geneve emulation at this time, so also here, please give me some details, best would be a reproducible test. In recent times I did some productive work on the Geneve emulation without any issues of that kind.

Sounds a bit as if he came from Austria, doesn't it?

BTW, this one was not mentioned, but it was the first computer magazine I got, showing a dedicated TI-99/4A section.

I tried it on the current MESS, and I have keyboard and joystick. I have to lock Alpha Lock when using the keyboard (using ESDX, not esdx); remember to unlock it when using the joystick. The joystick is mapped to the cursor keys of the PC keyboard.

Just didn't fit, I guess: 8 GROMs, 2 ROMs. Access to the GROMs on the card is 5BFC/5FFC (GROM data) and 5BFE/5FFE (GROM address), provided that the card has been selected on CRU 1F00.

I was not aware of sendkeys till now, just saw it is a Windows.Forms feature. I cannot say why there are problems with the emulated keyboard. What is the exact problem: no keys at all, or false keys in emulated mode? I could try to ask other devs with Windows background.

No, this would account for the difference between the track size of 3253 bytes for single density compared to 9*256 = 2304 bytes. I'd say the extra 90K that acadiel is wondering about are simply unused, similar to a floppy disk that is recorded on one side only. By the way, I found that the tracks of the PC99 format (which is used for the TDF in MESS) are somewhat too long. This became apparent when I was working to adapt the TI floppy emulation in MESS to the new core floppy system and tried to put one such track into an emulated floppy track. Simple calculation: We have 300 rpm, which means that reading a complete track takes 0.2 seconds. The cell sizes for FM recording are 4 µs, so we have 50000 cells on the track, and it takes 16 cells to encode 8 bits, so this means we get 3125 bytes at max per track. For MFM the cell sizes are 2 µs, which means 6250 bytes. PC99 defined 3253 bytes (FM) and 6872 bytes (MFM). My guess is that the track sizes are a result of reading a track with the "read track" function of the disk controller, which is known to deliver trailing bytes for some time after the track is finished (until it "interrupts out" (spec of WD177x)).

OK, on page 70 the manual says that there are only two sizes: 260240 or 549760, which depends on the emulated controller (1771 or 1772) that is used in PC99; single-sided formats use the same file size as the corresponding double-sided format. I suppose only the first half of the file is used, and the second half is either zeros or simply ignored; I did not see anything about that in the text.

I actually did not remember, but my code says: // We remove the modified flag because older disk controllers may // get into trouble (in particular the TI FDC) abyTFContent[10] = (byte)(file.getFlags() & ~ti.files.File.MODIFIED);

I've got a reply from Ernest Pergrem via PM, confirming that there are only two PC99 formats around (single density and double density), each one used for both single and double-sided. I guess this should be found in the PC99 manual as well.

Hi all, in particular the Geneve users, I just uploaded a hard disk image (MESS CHDv5 format) to WHTech, containing all the folders of 9640news. Caution: The image is a bit longer than 90 MiB. You can mount that image in MESS and use it with the HFDC controller, or you can open it in TIImageTool, and from there create your disk images with the files you are interested in. In TIImageTool you can transparently open ARK files (Archiver) like ordinary subdirectories, so you can quickly browse through that vast amount of files with a few mouse clicks.

I have an MBX here that James Fetzner sent me ... so well, maybe ...

Makes sense when you look at it this way: A zip file is a container for files, just like a directory. The MESS file loader searches for files in a container with the name of the system, and it treats zips the same way as directories. The modern operating systems and their respective file explorers just do the same. The "working directory" is the same concept as back in old DOS days, actually (or, to be precise, DOS took the idea from the older Unixes). It makes less sense (in my view) to have access relatve to the location of the executable file. Think of using system programs, like editors, or the file system commands like ls (dir). For this reason, when you create a desktop icon for an application in Linux, Windows, and supposedly also MacOS/OSX, you can specify the working directory. In the case of MESS, if I set up a directory /home/michael/mess as the base from where roms, mess.ini, and other files shall be found, I would set /home/michael/mess as the working directory. The executable file may be located elsewhere, and you can provide an absolute path to it.