Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

mizapf

Members
 View Profile  See their activity

  • Content Count

    5,366

  • Joined

  • Last visited

  • Days Won

    3

Posts posted by mizapf

  3. Posted · Edited by mizapf

    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.

  4. Posted · Edited by mizapf

    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.

  5. Posted

    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.

  7. Posted

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

  8. Posted

    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

  9. Posted

    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.

    • Like 1

  10. Posted

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

  11. Posted

    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.

  12. Posted · Edited by mizapf

    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.

  15. Posted

    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.

  17. Posted

    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.

    • Like 1

  18. Posted

    The bytes between the sectors.

     

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

  19. Posted

    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.

  20. Posted

    Alas, files transferred by many terminal emulators will retain these bits from Myarc systems. I seem to recall suggesting that Fred mask these bits in DM2K and TIDIR and his DSRs, though I don't know if he did. I do not recall if Michael's utility masks the bits, I suppose he can chime in if he reads this message. :)

     

    Many years ago I made it a point to mask the backup bit during level 2 file copying or modem transfers.

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

  22. Posted

    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.

    • Like 1

  24. Posted

    Er, then why does this work? I haven't set anything special up in my mess.ini file to make it function. (Yes, there's also an unzipped copy in the roms/studio2 folder.)

     

    EDIT: Never mind, I reread your post and now I understand. What's the reasoning behind that, out of curiosity? It seems kind of arbitary: if it's zipped it doesn't go in the folder, if it's unzipped it does.

     

    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.

     

     

    Ah, OK. I would have assumed that, if the location hadn't been specified or there was no mess.ini, it would be relative to the location of the binary I'm running, rather than the current directory location of the open command prompt. I'm guessing this is Unix behavior -- I've seen it before -- and, to be honest, it's never made sense to me. :)

    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.

  25. Posted · Edited by 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. :-)

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...