mizapf

I'm afraid not so simple. Error 6 is a kind of unexpected error, and usually says that the device or medium is faulty. As we have an emulation here and the image is correct (already tested), the device and medium are OK, so unexpected is what remains. If I remember correctly, switching between video modes may become a problem, since the controller expects buffer space at the high end of the video RAM. Maybe something goes wrong here. For a first test, my suggestions would be 1. If SPRITES is not the first file to be loaded, try to swap the order of loading. When I had a look, DSK1.SPRITES was the file name in VDP RAM when the error occured. 2. If possible, load all files in standard video mode, then switch to the graphics mode. What you can do to track the problem: Use the debug mode in MESS. Start the emulation with "-debug". You will get a debug window and the emulation window which remains black. F5 is run up to the next breakpoint (if any), F11 is single step. You should start by pressing F5 to get the emulation going. While the emulation is running, go into the debug window and type "bpset a000" (so it sets a breakpoint at >A000). You can set breakpoints at any time. Of course, you must do it before you start your program if you want to get control right from the start. Continue as normal, E/A option 5, load the file. The emulation will stop as soon as the program starts. In the "Debug" menu of the debug window you have some items like a disassembler window (Dasm window) and a memory inspection window (Memory window). Open one of each. You can enter an address in the line at the top of the new windows. The memory window can show different memory areas; you should probably have a look at "TMS9929A ':vdp' vram space memory" so you can check the VDP RAM where the PAB and the buffers are. While the program is still suspended, you can set some breakpoints, maybe right before or after the DSRLNK calls. Note that the symbols are not available in the program code; you must find the calls by yourself; look out for data >0008. As said, pressing F11 will execute the next command. On the left of the main debug window you see the workspace and status register (flags). When you press F5, the program continues.

The problem is that you will very likely run into the same problems on the real hardware. Or, the other way round, if the real HFDC does not produce the file error, I'm having a problem in MESS. :-)

If your concern with cartridges is that .bin is not supported anymore, all cartridges are available on Whtech for RPK. I'd really suggest you upgrade MESS to the latest version and give my improvements and patches a chance. Please keep in mind that if you run into problems you're on your own. A fix for that old version is hardly possible and won't be made available.

Interestingly, when I start it with the TI floppy controller (instead of the HFDC), the game is running. However, I should warn everyone that I observed some issues with the BwG and TI controllers in recent releases, maybe due to the fact that other developers are "messing" around with the WD17xx chip. I did not have time to fix the regression yet. The HFDC, however, is not affected because it uses another controller chip. The problems are seen here may be related to a different VDP RAM usage by the controller. I suppose you only tested with the tifdc?

I'm getting a FILE ERROR when I start it in MESS, and the last entry in [email protected]>2F00 is 00 cc 2f 80 80 00 00 00 00 0c DSK1.SPRITES Looks like an error 6. (MESS from subversion, Linux)

There is a new paradigm on commenting, as I had to learn recently. But maybe those people just decided to interpret stuff for their own needs. This change comes from the "Agile" people with their "Agile manifesto" which, essentially, in each of its points contradicts to my ideas of good software development, but hey, it's new, and my view may be stone-age in the meantime. http://agilemanifesto.org/ One particular point is documentation. I admit that working on bigger projects often requires you to write lots of text that nobody ever reads again. This is especially true for publicly funded, international projects as we have in the EU. I remember one day our group leader said we had to stop coding now, or otherwise we would not be able to complete the deliverable documentation in time. Well, and just some weeks ago I had an argument with one of my students, concerning the documentation of source code for a practical assignment. My request was to suitably document the source code, preferably declaring the functionality of block structures, methods, the semantics of member variables, and so on, using Javadoc style and end-of-line comments where required. And he just refused and said, I could not be serious, requiring to comment code that way. Comments were superfluous, always outdated, and you always should write programs in a way that you can immediately get the meaning from reading the source. It was not meant to be an important work, so we got to a compromise. However, I was a bit surprised that there are people who refuse to comment their code not because of laziness but because they object to commenting as such. I can understand that comments may be unneeded when you can immediately get the meaning from the line, but in many cases I cannot easily understand what is going on when looking at longer portions of code. Also, when functions are called, you usually don't know the exact meaning of the actual parameter without having a quick look at the function signature. MESS is just another example of sparsely documented code. When I have to find out something outside of my own code, I'm first using a debugger, setting a breakpoint to determine the call stack, then I have a look at each file that seems to be involved. The function of my editor that I mostly depend on is the hyper search function so that I can find out where is the file that contains the class definition. As we have C++ here and not Java, finding class definitions is a challenge sometimes. Luckily MESS has been converted from C to C++ some years ago, because things were a LOT more difficult to read with these C macros that tried to mimic classes.

Oh well, already some months ago... To relax, now a little bit of math for you. Got more time now, so I had a new look at the DIVS overflow detection, and now I think I got it. I have produced a heap of paper with wrong solutions, most of the attempts ending in sufficient but not necessary criteria (if the check indicates overflow, there will be an overflow, but if it says no, there could still be an overflow). But now here is a solution which worked with all test cases. Signed division, V=32 bit signed value, D=16 bit signed divisor, not 0. Case: V>=0 and D>0. Overflow iff V > D << 15 - 1. Case: V>=0 and D<0. Overflow iff V > (-D) << 15 + (-D) - 1. Case: V<0 and D>0. Overflow iff (-V) > D << 15 + D - 1. Case: V<0 and D<0. Overflow iff (-V) > (-D) << 15 - 1. (Non-math people: "iff"="if and only if". "D<<15" = shift left D by 15; alternatively: D*2^15; << binds stronger than +/-) The symmetry in the solutions gives me some confidence that this should be correct, even catching the cases with that nasty 8000. My fault in earlier attempts was that I divided the value by 2^15 and threw away the important bits in the lower positions.

Why ".cas"? When you call "mess ti99_4a" with the option "-listmedia" you can see that the cassette expects ".wav" files. Would be too easy if it's just the suffix ... but maybe, try.

It was just that very feature about six years ago that made me care for the TI MESS emulation. I did a SAVE CS1, then later an OLD CS1, and when the DATA OK appeared, I rolled on the floor, laughing. Beside that, I found the TI emulation in MESS in a pitiable condition in that time. So I started to fix it step by step (keeping track of that on ninerpedia).

OK, just tried to save a TI BASIC file to CS1, and this worked correctly. The resulting WAV file is about 1 min long. Some things that came to my mind: - During emulation, NEVER keep the on-screen menu (where you have the tape controls) visible during reading or writing. You should select Rewind, Stop, Play, Record, and then immediately exit the menu, even when you know you will have to return there soon. The problem is that the menu seemingly has a very bad impact on performance. The longer the menu is displayed, the worse are the average speed numbers. - For some unclear reason (at least for me), the cassette uses stereo recording and playback. Only Channel 0 will be read by the emulated computer. To make things worse, channel 1 is shifted by some seconds, so this may sound like a canon. Or similar. OK, in principle. In the "Slider controls" you can set the volume of CH.1 to 0. This has no effect on a correct reading or writing, though, it's just the sound output that is more familiar. - The internal error may indeed occur on reading (cassimg.c:570), but as I'm not the expert on the cassette support in MAME/MESS, I don't know when this occurs, and how I can trigger it. Maybe listen to it in a media player, check whether it sounds good. If you continue to have problems, please mail me the WAV file or upload it somewhere and give me the link.

This DATA ERROR, did it occur when you tried to load a program that you previously saved by MESS? Or was it a program that you read from a WAV file that you created from a real cassette? The cassette handling in MESS has been working flawlessly for me, so either this is a regression, or something else went wrong. I was even able to get my 30 year old cassettes read (from the "Test Trainer" (language training with cartridge and data cassettes)), so it should work basically. Real cassette recordings should be cleaned with some audio tool like audacity; this proved to be very helpful (remove noise, increase volume, equalize amplitude etc.) Also, the "internal error", did it say anything more? (In general, if anyone observes these kind of issues, please report to me, so I can try to fix that.)

The time is now ... finally. This was my most delayed release ever. Originally planned for February, TIImageTool v1.5 is now ready for release. You can get an overview of all functions at http://www.mizapf.de...iimagetool.html Download the latest version from http://www.mizapf.de...tiimagetool.zip New in this release: Picture viewer: TIImageTool can display TI ARTIST, MyArt, and YAPP pictures GPL Disassembler: As it says, allows for disassembling GPL binary code. Tagged Object Code disassembler: You can disassemble DIS/FIX 80 files. The DIS/FIX 80 disassembler took quite some time, but I think it was worth the effort. Given a D/F80 file, it tries really hard to get a syntactically correct source code from it. In most cases you should be able to assemble the resulting source code again. Although it most likely does not appear anywhere, it can cope with different memory scopes (program/common/data-relocatable). Note that TIImageTool is not only useful for MESS users. It can be used for disk image management (file operations), can work with Archiver files, and contains full XModem support. TIImageTool requires a Java Runtime version 1.5 or newer. A current Java 6 or 7 is fine. If you want to use serial connections you need the RXTX library.

This is one of the main use cases for TIImageTool. You can quickly create image files for MESS and also import TIFILES files quite easily.

I'm not quite sure whether it helps, but you could try to set "multithreading 1" in mess.ini. Yes, if your graphics card is not accelerated, this may have a bad impact on the system performance. As I said, these graphic cards and their drivers are optimized for 3D but not for 2D, and MESS in particular makes heavy use of 2D operations. Drivers are such a pain ... when I'm watching Sat TV in HDTV on Linux I have to use AMD's proprietary driver, because the open source driver unfortunately is not fast enough, pushes up the system load to 150%. Imagine - a Raspberry Pi can cope with HTDV, but not my Core i7 with a Radeon HD 7970. [Edit: Robert, by the way: full MESS build with 438 seconds ]

Hi Ernie, not in this case. The image size is 92160, which indicates it is a sector dump. Also, TIImageTool would be able to open a track dump (aka PC99 format). The e5 are sector contents after initialisation, so I suspect there are really data misssing.

Hi Robert, try "Check filesystem" in "Utility". I would say the image is broken; sectors have not been copied or were unreadable during the creation of the image.

I'm all ears for suggestions how to facilitate the setup. :-)

There is most likely something else broken in that installation. Quad core CPU are fast enough in any case to run MESS at full speed; at least I had a Q6600 for the last years, and there was no problem. Have you tried to use "video: opengl" in the mess.ini file? Sometimes the software renderer slows things down. Many performance problems arise due to video issues; it seems as if video drivers are optimized for 3D only, but have a very bad performance on 2D.

No, I guess it's my job to get that going ... :-) As I reported some weeks ago I noticed that Rich uses full 8K GROM emulations instead of the standard 6K. The ugly thing was that there was a bug in the MESS emulation which allowed GROMs to read past the first 6K. After I fixed that, some cartridges, including RXB, stopped working. So I had to introduce a new cartridge type called "gromemu" which allows for full 8K GROM emulations. However, I only uploaded one cartridge (rxb_2012.rpk) to Whtech, and all other ones remained broken. I just corrected all RXB cartridges, and except for two of them, all seem to be working now. You need MESS 0.149 (the most recent version) for these cartridges to work.

Within the first 16 lines of the TMS9901 you have only inputs, and when you set the bit to 1 you enable the interrupt for this line. Zero disables the interrupt for this line. When you do a SBZ, the state of the line can still be read with LDCR or TB, but it does not trigger an interrupt. See the TMS9901 manual on WhTech, page 6 (of the PDF).

You have a flag byte for that purpose (83C2). Have a look at http://www.ninerpedia.org/index.php/Programming#Useful_CALL_LOADs, a bit down the page. This flag byte is checked by the interrupt handler.

If you are writing programs or making use of interrupt-controlled processing, LIMI 2 is mandatory. You can turn off interrupts, gaining speed, but also losing features like automotion of sprites, sound processing, or QUIT key processing. I found it interesting to see that with TI's most advanced CPUs of the 99er family, the TMS99000 series, LIMI is taken away from the user processes. Only the operating system should have the right to disable interrupts. Calling LIMI within the user mode will cause a trap. Well, our 99/4A is not really a multiprocessing machine...

No, && is for boolean, & is bitwise AND for integers. R0 & 0xff would be ANDI R0,>00FF. The C compiler should optimize (x && 0xff) to simply x because 0xff is never false.

This is similar to how MESS is doing it. We don't just use one timer but any timer that is currently active. So we get varying periods of time between any two timer firings. The CPU speed is then translated into a number of cycles that can be performed until the next timer event (which is also done for any executing device, i.e. devices with own activity, so you can easily handle co-processors). Creating a wait state means to decrease the number of available cycles without doing anything, so you have less activity in a time period.

Also, what maybe everyone had to learn sooner or later is that sprite auto-motion and collision detection don't really go together. The reason is that sprite auto-motion is triggered 50 or 60 times a second, so this means if you want your sprite to visit every column on a 256 column screen it would need 4-5 seconds to go from one side to the other. That means a faster sprite will have to skip over screen locations. As I said, only if you use auto-motion.