mizapf

Isn't it contained in ti_family.zip on whtech? I cannot check right now, will do that later this evening.

The 32k option is not redundant; however, you have the console mod (32K 16 bit 0 WS) active by default. You should not use both expansions at the same time. Yuo can turn off the console expansion in the TAB menu. BTW, it proved already helpful to have both kinds of expansions, because some programs like TurboPasc99 have problems with the 16 bit expansion.

I admit, I find it somewhat painful to find TI stuff on a website dedicated to 8 bit computers ... :-) Isn't that defamation? At least the author says that the TI-99/4A should rather be considered a 16 bit computer ("eigentlich schon ein 16Bit Rechner").

We need not even use Base64; RPK is a ZIP container, so we can include any file we want. Just need to reference the file from one of the XML files inside (layout.xml or meta-inf.xml).

It is indeed possible to extend the existing RPK layout format. In MESS I only have a look at a predefined set of elements in the layout.xml, so others would be ignored. Maybe the meta-inf.xml could be even more appropriate. How is the emulator supposed to handle the information? At this time, the TI emulations in MESS do not have "artwork", i.e. graphical elements to build a user interface (as used with arcade machines, calculators etc.). Or do you think of simply producing some strip to put on the PC keyboard? As for the hacks, a simple alternative would be to patch the ROM dumps and create a new cartridge RPK. If desired to be used within the emulation, one could think about a config switch.

Just to clarify, for me this was the 2012 award; as I was not at the Treffen in 2012 the "ceremony" was re-done.

Let's see ... if you load C0 into the sound chip, it waits for a second byte, so this could consume a following byte that should have set the attenuation. If you can find out the byte sequence written to the sound chip that causes the malfunction you'll get special credits in sn76496.c. :-)

Very good, Rasmus. I'll check that more closely. According to my definition, the sound chip is reachable on 8400 with a mask of fc01, that is, when (address & fc01) == 8400. So it should ignore odd addresses, but it responds on all 84xy to 87xy with even y.

You mean the watchpoint feature from the MESS debugger? I recently noticed that this feature interferes with my revised memory access emulation, so I'll have to check that first. If the effect only occurs from within the debugger, don't mind.

You mean sound corruption in terms of "sticky" sounds? This is a known issue, and I already have some theories on that. Concerning joystick up: First try to put Alpha Lock on another key (like the Windows key if your keyboard has one); there is a strange thing about the caps-lock in MAME/MESS - it seems as if its state gets out of sync sometimes. If this does not have the desired effect you should try the system configuration setting ("Alpha Lock block joystick up") - unless that was the option that you referred to. Finally try a BASIC program like CALL JOYST(1,A,B), PRINT A;B, GOTO first line.

Hmmm, I think there should be some feasible way. I don't know how your database looks like, but maybe there is a simple way to say, for instance, that TI Invaders consists of the c.bin file, the g.bin file, and the rpk file, and for Classic99 you can deliver the first two options, while MESS gets the third one. Anyway, you have specific parameter settings for each emulator. The problem is that the bin format is long deprecated in whole MAME and MESS (not only in the TI branch) because of being too cumbersome and error-prone for using. Actually, with all subsequent changes in the MESS code since that time I included RPK support, it has by now become virtually impossible to restore the bin support (apart from being undesirable). In fact, in particular after I saw its presentation this weekend, I believe the Gamebase is really a great tool for all TI emulation users, but it makes me worried to see that we get an either-or here. There have been so many fixes, improvements, and new features in MESS since 0.140 (notably speech, new cartridge types, serial connection, fixed HSGPL and SAMS, GKracker, Multicolor mode...) that it would be a pity if users were locked to an old version.

0.149 should work; it is pretty new. Try the following: - Direct speech by running Parsec - Vocabulary speech by running Extended Basic and using CALL SAY - Text-to-speech by running Terminal Emulator 2, enter BASIC, type OPEN #1:"SPEECH",OUTPUT and then PRINT #1:"HELLO" If you run MESS from a shell (command line), check whether the emulator returns with "Average speed: 100%".

By the way, Rasmus, I presented your Scramble clone on the Eindhoven meeting, with lots of cheers from the audience, too bad you couldn't be there.

In Windows you can also create such a command line and store it in a batch file. Or you can install the QMC2 frontend, create a configuration with the appropriate cards plugged in and start the emulation from there. OX., I have another question: I noticed that Gamebase relies on the old BIN format for cartridges in MESS. This format was dropped quite some time ago in favor of the RPK format because the RPKs are much easier to handle (and I could throw out hundreds of lines that were merely there to support both formats). Could you include the RPKs in Gamebase so that people are able to update their MESS version without losing Gamebase support? It should not be too hard to achieve because all RPKs are available at Whtech and it would only mean to reference a single new file instead of the bin files.

What MESS version are you using? The recent versions have a flawless speech output. This is also true for the recent MESS versions. I can imagine that this is due to an improper sound chip emulation with lost bytes, and I have to take a closer look. It would be easier for me if Rasmus can strip off all other code and just keep the sound routine that triggers this behavior.

I'll be there late Friday evening. Have to work until 13:00 this Friday. (Oops, I can post again?)

A safe way to tell apart 9918 and 9938/58 is to read status register 4, which has the first seven bits set to 1 (always returning FF or FE). The 9918 only has one status register, so it will ignore the status register selection and return status register 0, which is highly unlikely to return such a value.

I plan to attend the Eindhoven meeting, anyone else? ... BTW, I seem to have become unable to post messages with Firefox (23) on this forum. It does not accept the message in the text field and says I need to enter a post after pressing "Post new topic". "Preview Post" returns me to this form again, again with an empty text field, and no "Post Preview" field. :-( Doing this right now with Konqueror.

We're having issues with the PHP support on the server. I hope Rich Polivka can fix it soon. In the meantime, just put your MESS question here.

The Geneve has a RTC on board. BTW, the RTC proved to be quite useful for me to calculate command execution and wait state times.

LOL ... honestly, it was not long ago that I, as a non-native speaker, finally discovered the pun with Uranus - gladly, in German, there is nothing even remotely similar to that word. By the way, as I learned, the astronomically correct way to call it is "Yooo-rannas". :-)

Oh nooo ... could someone please make the game a little harder? :-) I remember well, nearly 30 years ago, when me and three of my friends were playing Parsec in turns; we changed each time that we lost a ship. Except for one of us who was told to crash the fleet up to a single ship. This took some time in later levels; must have been more than 20 ships in reserve. This was the time when we reached the levels which did not change in color anymore. I think we stopped playing after two hours or so. No, honestly, the problem was that the score for each enemy ship gets higher from level to level, up to some maximum, but after that point, if you are at least moderately skilled, you gain new ships faster than you lose them. I would say that once you get past the first 10 levels, you are very likely to get 10 levels farther.

I'm still wondering what was the intention behind the strange LDCR. I don't know of any controller that has its ROM enable at CRUBase+>10 so that one could have argued that setting both bits (CRU+0, CRU+>10) is a safe way to turn on the ROM for all cases. Maybe it was just a misunderstanding about CRU programming. Or the author originally intended to load less than 8 bit into the CRU space, in which case only the first byte would have been used. That is, the code would have worked if he had written LDCR @ONES,1 (up to ,7). Still, setting more bits in CRU than required is generally a really bad idea, even when you are setting zeros. I think the reason why CRU programming has always been a mystery is that at this point, you are leaving the clean, comfortable world of software and get to the rough, real world of hardware. To create useful effects you would have to study the specifications of the attached circuits. The 9901 was a particular mysterious piece of hardware for me ... until I had to rewrite its emulation in MESS.

Apart from the CRU issues I should not forget to add my congratulations to you, Rasmus, for this outstanding programming work. And at the same time I'm feeling somewhat sad when I see it. Because it shows me how much potential was wasted in those times.

ONES=0000000100000001 LDCR @ONES,0 means it sets to one [email protected]+0: DSR select (maps ROM into >4000) [email protected]+16: RAM page select at 0x5800 So this is a killer for HFDC, because you swap the RAM pages. Why are two bits set? Maybe try a SBO 0 here and SBZ 0 later instead of the second LDCR.