mizapf

I can confirm that CALL SECTOR("WDS1.",1,1,"0") leads to a File Error, but I do not know why this error occurs. There seems to be an access to the HD, but always to sector CHS=(0,0,0), regardless of the value in quotes. So either there is a problem with the parameter setup for the sector read subprogram, maybe due to an incompatibility between SCSI and HFDC, or actually an issue in MESS. As the hard disk is properly working (which somehow entails sector access), this may be not so easy to find out. I'll have to write a simple test program first, I suppose.

Really? I don't know of any depth limitation with HFDC. Or is it because I'm using GeneveOS to write to the hard disk? I just had a look at the HFDC manual. Page 12, last section: You can set up as many levels of subdirectories within subdirectories as you wish, subject only to some practical limits as to how many characters it takes to address them. [...] The total name can be up to 40 characters long.

It once was able to, then the GUI became more powerful, now I'm gradually bringing the command line features back. Import from the command line does not work right now, but you can import a whole directory full of TIFILES into a disk image, if that is somewhat helpful for you. Right now I'm preparing the next evolution of TIImageTool, featuring Drag and Drop. For that reason I cannot add the requested feature right now, being right in the middle.

Not here in Germany, I think. They are all avoiding any kind of open WiFi as hell because of a law that punishes people that willingly or negligibly provide support for a crime or offense. That is, if someone distributes unlicensed material (movie, music etc) over your WiFi, you will also be prosecuted. Ever wondered why German airports or train stations don't have free Wifi?

Ah, just found your answers within my quote ... ... well, the forum software is not really the yellow of the egg, as we say in German. If you want to break the code like I did, you must switch to the "BBCode mode" (leftmost switch in the editor) and add ... your reply ...

MESS is the collection of components for computer system emulation inside MAME, so what you get in touch is actually the MAME core. All documentation for MAME should apply for MESS usage. As I said, no, all your settings should be saved automatically when you leave MESS. Next time they should still be there. If you need different configurations you will have to do more work; for example, swap between different ti99_4a.cfg files, or you need to pass the -cfg_directory option on the command line to override the setting in mess.ini. Again, please check whether your mess.ini has a proper setting for cfg_directory. This is where the configuration file goes. I never had a SAMS, so I never had a need for 1 Meg of memory. And there came the Geneve. In turn, the internal 32K is visibly faster; it connects to the 16 bit bus and does not trigger wait states. Personally, I find it more helpful to have full control what is plugged in on startup. With writeconfig=1, you would call mess ti99_4a -cart invaders and next time, two weeks later, you call mess ti99_4a and wonder why TI Invaders is plugged in. I think this is a silly feature (as long as it is so easy to tell it using -cart that you want that cartridge to be plugged in). Really? That is strange. Try to move them out of the folder and restart MESS. Could they be zipped? All files in my cfg folder are plain text files. $ find cfg -type f -name "ti*" -exec file {} \; cfg/ti990_4.cfg: XML 1.0 document, UTF-8 Unicode (with BOM) text cfg/ti99_4ae.cfg: XML 1.0 document, UTF-8 Unicode (with BOM) text cfg/ti99_4.cfg: XML 1.0 document, UTF-8 Unicode (with BOM) text cfg/ti99_4ev.cfg: XML 1.0 document, UTF-8 Unicode (with BOM) text cfg/ti99_4e.cfg: XML 1.0 document, UTF-8 Unicode (with BOM) text cfg/ti99_4p.cfg: XML 1.0 document, UTF-8 Unicode (with BOM) text cfg/ti99_4qe.cfg: XML 1.0 document, UTF-8 Unicode (with BOM) text cfg/ti990_10.cfg: XML 1.0 document, UTF-8 Unicode (with BOM) text cfg/ti99_8e.cfg: XML 1.0 document, UTF-8 Unicode (with BOM) text cfg/ti99_224.cfg: XML 1.0 document, UTF-8 Unicode (with BOM) text cfg/ti99_232.cfg: XML 1.0 document, UTF-8 Unicode (with BOM) text cfg/ti99_4a.cfg: XML 1.0 document, UTF-8 Unicode (with BOM) text cfg/ti990_4v.cfg: XML 1.0 document, UTF-8 Unicode (with BOM) text cfg/ti99_4qi.cfg: XML 1.0 document, UTF-8 Unicode (with BOM) text cfg/ti99_8.cfg: XML 1.0 document, UTF-8 Unicode (with BOM) text

If you want to disable the internal 32K you must start MESS, go into the OSD menu, System configuration, and turn it off. When you quit MESS, it will save these settings in a file ti99_4a.ini in the "cfg" directory. The configuration settings were not intended to be set in the command line. Little misunderstanding (I had to look it up as well :-) ). The ini folder is for copies of the mess.ini file. You can have a per-system emulator ini file. If you set writeconfig to 1 in the mess.ini file, MESS will create a copy of mess.ini as ti99_4a.ini in the ini folder, depending on the setting inipath in mess.ini. This feature is activated when you set writeconfig to 1 in mess.ini. However, I would strongly discourage from doing so, despite the recommendation in the MESS manual. If you use it, the emulator will save the last inserted cartridge and floppy disks. When you start the emulation next time you will automatically get the same cartridge and disks inserted even if you planned to use no cartridge at all. Think of the educational cartridges that immediate grab control when you start the TI. I think this feature is a nuisance, but obviously there are other systems where it makes more sense. That is, readconfig=1, but writeconfig=0. What you are actually looking for is the config directory. All changes to configuration, dip, and input settings are saved to a configuration file. These files are located in the directory defined by cfg_directory in mess.ini. Check whether this directory exists. Rich, my suggestion: Ask more and try less. I'll help you where possible. I'd like to add aome "philosophical" stuff: MESS is a tool that exposes many knobs, switches, and levers, all of which you can operate and try to achieve some outcome. However - and I also consider it as a shortcoming - there are roughly 10 times more ways to do it wrong than to do it right. If you don't really know how to achieve something and you start guessing, MESS will disappoint you by making you fail 90% of the time. If you know well how to do it, you may enjoy the small 10% for almost 100% of the time. This is what makes it difficult for me to anticipate the issues that many users encounter when working with MESS. I'm doing it in the intended way; installing takes me 3 minutes, configuration another 2, copying the required ROMs 5 more, so I'm possibly done 10 minutes when starting from scratch. But I benefit from my "hidden" knowledge that I'm even not aware of. I'm not trying to mock people saying that MESS is simple to set up and use for me. This is obviously the case, but not because of some alien capabilities of mine; I'm just not hitting the problems that other people do. The thing is that this observation does not only hold for MESS but for many other tools in the technological world, just compare operating systems or modern devices like TV sets or Bluray players. Most of them require you to do it perfectly, not just close to, and by that they keep frustrating people.

Should not sound as if I did not trust you, I just wanted to know that we can be absolutely sure. :-) In that case we can say all different ROMs are either buggy or beta releases. Unfortunately I don't have a TI console anymore ... but actually, I could try to run it on my real Geneve. I just need to create cartridge files for the GPL loader.

Just checked: The Robotron RPK as provided by Robert can be fixed by splitting the file into two 8K parts and gluing them together in reverse order. $ split -b8192 RT-3-13.bin $ cat xab xaa > RT-3-13.bin

Why did you upload it with "txt" suffix? This can be dangerous because servers or clients may be inclined to drop unprintable characters or change linefeed encoding. zip suffix should work. How do you know the dump is good? Did you dump it by yourself?

You should not trust the length value from the softlist, since it was autogenerated from the lengths of the bin files. I suppose the bin files are overdumped, i.e. they have trailing bytes. The correct length must be 8192. Last time when I uploaded the updated RPK, I used new bin files that I trimmed to 8192 on purpose. The cartridge type is "paged". The softlist is NOT required for RPKs. The softlist is the alternative cartridge handling method where you put the bin files into a ZIP file. As for the cartridge, you either have to use two 8 K files with "paged" or one 16 K file with paged379i. However, the RPK is invalid because of a Zip file error. What zip utility did you use? I found that it requires version 0x0314 instead of 0x0014, and this is not accepted by MAME's unzip implementation.

If we can identify one ROM set for Robotron as working, and we can prove that MESS is reproduceably failing where the real iron is working, then I can actually go for hunting that bug. So if someone has a working real cartridge, can you check whether the recently posted as_robotron2084.rpk is identical to that one? This makes it understandable why in MAME/MESS we always have hash codes with the ROMs (which rule out modified ROMs from working). The problem is that you have to make sure whether the copy of the ROM is indeed correct, just for cases like this. You cannot clearly find out whether you got a bad dump, or whether there is a bug in the emulation. For that reason, the ZIP cartridge format was favored to the RPK format, because we put the hash codes into the RPK (so everyone can change them at own will), while in the ZIP format, the hash codes are distributed with MESS. And this is why I (and some others) insist on keeping the RPK format, because this is more comfortable for homebrew software that is still evolving.

Taken from Wikipedia: The CR-LF sequence was indeed used with teletypes, but it was not fully correct either because of the long time the carriage needs for its return, so in fact a NUL sequence was usually inserted in between (CR-NUL*-LF) Multics systems abstracted from this detail by only using LF which should be translated to the appropriate sequence. Unix (and then also Linux) inherited that from Multics. Whatever, it's different, and it won't change. Anyway, I'd rather like to see Windows finally using UTF-8 encoding as default.

Even worse: Game code is buggy.

Yes, as I wrote in another thread, Robotron is not stable. Classic99 seems to have similar problems with it. The dumps you uploaded do not show any evidence of a crash; did you copy them immediately when your system froze? (... wait, this sounds somewhat silly ... ) If you look at the Xorg.0.log after a reboot, it doesn't have the stack trace of the previous run; in that case we need the Xorg.0.log.old. You're using the fglrx driver, which I'm also using, but it seems as if mine is more recent: "module version = 14.10.2".

Will we ever get to know all of Bill Gates' weird design decisions from MS-DOS times? Unix line endings have always been LF only (\n), inherited from Multics (1964). I don't believe the different newline encodings will change in foreseeable time.

Ah, I just noticed that the Robotron ROMs are overdumped, i.e. there are trailing zeros (check their lengths). So that is the point where they differ from other Atarisoft cartridges. Here is a new RPK; try that one as_robotron_2084.rpk

Robotron also crashes after some time in MESS. So I guess the issue is inside the game.

In that case it's likely your system at fault, possibly the graphics card driver. An application like MESS should not be able to cause a freeze, yet it's still possible that it triggers the bug. Can you still do a dmesg or check your /var/log/Xorg.0.log for evidence that there is a crash somewhere? Maybe keep a terminal window open on the desktop.

I actually found an issue in the MAME core which causes a crash on exit; already posted it on the mamedev list. But I can always reset the emulator using F3 in partial mode. Are you running it on Linux?

The attached zip file is really a zip file, containing the rpk. Did you just rename zip to rpk?

This kind of crash should not happen. What have you done to make it crash? Can you upload the cartridge? What MESS version are you using?

Chris, as a suggestion, before all people set up their own directory in the root of WhTech, maybe we should rather create a directory "/people" where such directories could be located, or you could move the file into "pc utilities". The WhTech FTP has always been looking like a big heap.

Rich, 1. MESS uses a "file system" that is also used by other emulators like v9t9. The DSK files are a dump of sector contents. Yes, this is a good thing. Most emulators on the world make use of disk images. 2. Also, MESS and TIImageTool support PC99 format. No need to convert anything. You can open those disk images directly. 3. Classic99 uses plain TIFILES. You can import them into the DSK image files using TIImageTool. Open the DSK image, go to "edit", choose "import files". If the files are not shown, remove the file filter by choosing "All files". 4. As I said several times, I cannot make any use of "results in errors" if you don't tell me the error. In most cases, as it shows, the problem is on layer 8, sorry.

This seems to me like the ultimate appreciation.