Re: Ami99 Official Bug Report... OR ...Tursi on Trial... ;)

[ Follow Ups ] [ Post Followup ] [ TI-99 Emulator Forum ] [ FAQ ]

Posted by Tursi on November 15, 1999 at 07:33:11:

In Reply to: Ami99 Official Bug Report... posted by Stiletto on November 12, 1999 at 22:37:50:

If it pleases the court, here be my answers to the charges brought against me... ;)

: "The AMI99.EXE file is linked to missing export KERNEL32.DLL:CreateWaitableTimerA."

Guilty. I checked the documentation and CreateWaitableTimer is available only under Windows 98 or higher. It's used only in the interrupt thread, so I'll see if there's something adequate in Win95.

So, the current build is only compatible in Win98 and up.

: By the way, why is "time short?" I'd sure wish you had the time to work on the program.

Why is time short? Because I multitask myself too heavily. :)

-I'm currently temporarily living in Virginia, waiting for notice to pack up and move to California, while trying to stay unpacked just enough to live. ;)
-My current job frequently has me working long days, and as it's programming, I sometimes don't care to continue when I get home. This is subject to change when I move, whenever that will be.
-I have no fewer than 7 currently open projects of varying importance on my personal shelf, with seven more waiting to begin, and I'm easily distracted. ;)
-On top of all that, I have a relationship and am occasionally required to spend time with my mate. ;)

: I wish I could help you with your sprite priority problem, but I can't.

No worries, that's been answered for me. ;) Thanks to the two who checked for me (one in email, one here.)

:But even CADD isn't selling the module images of, say, Q-Bert.

Perhaps it'd be worth a letter to Hasbro, see if they'd release the TI Versions of the old Atarisoft games to Public Domain, the same way many companies are being convinced to release old Amiga stuff for emulators. :) Perhaps TI would eventually follow suit. (not! sigh.)

:Well, they've at least let CADD be licensed ROM distributors, but while it's cheap, they don't have EVERYTHING.

Because they're only licensed by TI to distribute the TI stuff. Remember that Atari made their cartridges without TI's approval, prompting the change to the console which locked out ROM-only carts.

: Is the speech synthesizer the 5500 or 5520? i'm confused. Would digging up more info on the 5500 help make the speech sound better than in the speechtest program?

5500... and prolly not. I don't understand the speech generation, despite all the docs I've read, and so I've just plugged it in. I think I did something since that made things a bit clearer, I was confusing whether I needed signed or unsigned samples... but in Windows I still need to get the streaming audio pinned down correctly. Among the timing problems I've got with it.

: Finally - the old build 101799 worked great on my machine, if slow and no sound. Now the new one just crashes with this "missing export" error. What gives???

The two versions are markedly different internally, with the new one being multi-threaded (interrupts, CPU/Sound and Video on separate threads). The interrupt routine uses a waitable timer for synchronization (which allows easy change of refresh rate), and that's only available in Win98 and up. I never checked, having Win98 at home and Win2000 at work. ;)

: P.S. To load a cart, say, Alpiner, in MESS - type "mess ti99 alpinerc.bin alpinerg.bin" and

Ah, there we go. ;)

: P.P.S. If you hang in there another week or so until I have my new 20.4GB UltraATA 66 HD formatted and partitioned how I want, I can test Ami99 on Win2000 Release Candidate 2, if ya want. :)

Done, and some development done there, too. ;) Works well. ;)

:In other words, remove that shite about my gfx card! Leave my Number Nine Imagine 128 Series II 8 MB VRAM alone! ;)

Wah. ;) Actually, that comment came from your request on this board to make Ami99 DX3 compatible. ;) Since I didn't build Allegro, I had no control over what it wanted and little idea what it was doing. It's not as important now, as all I use are blits and stretchblits, and I can nuke that comment. I just wanted to make sure you saw it, since "-DirectX 6.0 (earlier MAY work, but no promises)" has *always* been in the doc file. ;) I never once mention your video card. ;)

: June 1993 - TI Emulator 386 is the
: Well, you asked, Tursi. ("This project started

Fixed. :) I have an old version of v9t9 still, too, on a floppy disk with the version of Space Acer that I had to hack to get running. ;) I had the same error with Ami99, so it was nice to know what one bug was. ;)

: 2.) Complete the VDP with support for multicolor mode, though I've no way to test it
: I don't suppose you can write a XB program to test it? What's multicolor mode? Do I see it in any game I might recognize?

The only game I've seen that used it was a side-scroller called 'dragon', which was a bit like Scramble. ;) It's the 64x48 block graphics mode. Adding it should be easy and I'll do it someday. Right now that bit is ignored and the machine stays in graphics mode.

: 3.) Complete joystick support (correct CRU response)
: Again - I highly agree. Add mouse emulation of joystick, keyboard emulation of joystick, and DirectInput support, please.

Once the input routines are properly sorted out. :)

: 4.) Write GPL interpreter (distant future)
: What's a GPL interpreter? What's GPL, then?

GPL aka Graphics Programming Language was developed at TI, it seems, for the 99/4A. Pretty much the whole OS, TI BASIC, and many TI Modules were written in it. It's an interpreted language fairly close to 9900 assembly. It's the biggest reason TI BASIC is so slow on such a decent machine... it's interpreting the interpreter!

A native interpreter, which right now I don't have a lot of interest in doing, would speed up anything that was written in GPL by making it run as if there was a CPU that directly understood it in the machine. I do have sufficient documentation thanks to the PDF of TI Intern. :)

: 6.) Write psuedo DSR for RS232 and PIO support.
: What's PIO, again?

Parallel IO - the printer, anyway. ;)

: 7.) Complete psuedo DSR for disk.
: Please add disk image support, besides using Ed's novel FIAD format. Perhaps you could include not only V9T9 image compatibility but also PC99? (Ask that guy who made the file converter programs)

Geez, I hate disk on a disk formats. For what it's worth, I'm not using Ed's FIAD format, either, I'm just writing the data the TI asks for. ;) I support his format for reading because it's easier to come by.

I know *why* everyone wants DOAD format, to use all the images out there, and supporting the PC99 disks is doable if I get some docs about what all the extra data in there is. I don't *want* to, but it's doable. It should be possible in the config menu to let you select either a disk image or a directory for each DSKx.

: 8.) Replace CPU core with assembly routines from V9T9 source?
: I'm not sure the speedup we'll see, since it's already as fast as it was using Allegro (or so you say) Do it anyhow, when you have the chance - perhaps we'll need speed limiters!

It should make a substantial improvement, though I think using Ed's code is (again) out of the question due to compatibility. I'll prolly have to do it myself. Some of the things I work around to do in C can be done directly in assembly. ;)

: Correction to Readme: ghostly "cart." at EOF.

I have no idea what you mean here. :)

: 1.) Would having non-simulated interrupts be an improvement? It would make those programs that relied on reading the changed registers work, at least.

I haven't seen any that do, else I'd be seeing programs switch to that workspace randomly, and it really wouldn't make any sense for them to do so, since nothing useful is left in the registers. Remember that the program doesn't know when the interrupt takes place. Letting the CPU interpret the interrupt routine would work, sure, but would substantially slow things down and force me away from a real-time goal. Even v9t9, by default, simulates the interrupt routine. (As best as I can determine).

: 2.) Please make speed control a NON-hack. :)

The only way to accomplish this correctly is with a list of the 9900 opcode timings - how many cycles per instruction. It doesn't seem to be floating around. I once had a book - Compute!'s Guide to Beginning Assembly Language on the TI-99/4A - it had that among other useful tables in the back. But I don't have that book anymore. Even the MAME/MESS core doesn't know the TMS9900 timing - they default to 3 cycles for every instruction. (Check the source. ;) )

: 3.) I'm sure that most of the TI99'er hardcore fans will want a 50Hz switch.

Done and ready, just need to implement the menu. (If replacing CreateWaitableTimer doesn't break it. ;) )

: 4.) Cassette loading/writing WOULD be rather cool then... if you don't want to do that, then specify how a *.WAV file containing the casette info should read, and randomly access THAT.

The TI's cassette routine is one of the parts of the TI I never did delve into, being so absolutely thrilled to leave it behind when I got my first floppy drive after about 5 years. ;)

It would take a fair bit of effort to get it working. As for size, I don't know the highest pitch used, but I have software that can tell me. But the average TI BASIC program for me recorded for about 4 minutes.

Using WAVs is a nice idea, though.. you could treat them just like disk files. Hell.. it could be made transparent with the right work.

I'll consider it.

: 5.) Please add the ability to remap Key's on the PC keyboard to the TI-99's, if you can. I hate pressing all those keys just to do "Redo."

Yeahyeahyeah. ;) I hate it too. But it isn't as easy as it sounds, I need to rewrite the keyboard routine to have two layers - Windows and TI. ;)

:And finish the joystick interpretation if you can. I'd love to play Parsec, with speech, full-screen and in full-speed, using my Logitech Wingman Digital Extreme USB joystick.

That'll all come together at the same time - whether implemented or simulated (I'm thinking of re-simulating the whole keyboard routine - wouldn't be too hard. Could do that and still map CRU lines to the programs that directly check CRU. Hmm.. flipflopflipflop.. which way..)

: 6.) Please add other audio file generation as well. (SINE.WAV, TRIANGLE.WAV) so I can play. :) Or, perhaps keep non-generation around also, to override auto- generation if switched on in the menu system.

I didn't think anyone cared about that. ;) I decided in the end I liked the original square wav better than the others, but adding SINE and TRIANGLE waveforms should be as easy.

Vibrato on the TI sound chip, anyone? ;)

: 7.) Want semi-thermal printer

Heh. I've never even seen the thermal printer. ;) Let alone seen any documentation for how it prints. Sorry.. when I add the PIO support you can print to the printer of your choice (if you have a TI compatible driver/program), but beyond that.. nope.

: 8.) 9938/58 VDP would be very cool.

It would. :) Funny that MAME doesn't have drivers for either chip - did anything ever use them?

: 9.) Ya never know when the 5-sprite-on-a-line effect might look good. It would be a feature of ACCURATE emulation, anyhow

Would add a lot of overhead to the way I draw the screen now, and that's why it's not in there. It's not to say it might be useful, I mean, *I* used it in one program I wrote to mask things out a certain way. But I don't see it ever becoming more than a tweak on a polished emulator, which I'm a long way from having. ;)

: 10.) Did you ever get volume control working?

When I switched from WinAlleg to Allegro 4.0

: 11.) "It would have been nice, if I had proceeded with this, to kick the screen into
: 640x480, and let you watch the TI screen in one corner, see the disassembly in a second corner, see the registers and a memory dump in the third, and had a little control panel/hex editor in the fourth. Wouldn't it?" This is actually doable now - just display the video in one window, and then the debugging info surrounding the frame.

It actually happens now, and has since the day after I wrote that line, and I thought I took that out of the docs. ;) But it puts it all in the one window (which is just compatible to the way it used to kick the screen into 640x480).

Oh, you're commenting on the dated notes now - note that those don't get changed just for a new update, they're history.

: 12.) There's a way that MAME and MESS uses to do auto-frameskip and speed-limiting in general based on some feature of the processor it's running on, but I

CPU speed limiting was based on: timing the speed of the CPU in MHz, and knowing how many cycles were used per instruction. I'm not currently aware of any info on the net on the 9900 instruction set timing.

Auto Frameskip has annoyed me from the day it was implemented, but it basically just checks how quickly the emu is running, and reduces the FPS until the CPU hits 100%. This requires that the CPU timing be accurate to work. It's annoying because it's too sensitive, it should check for sustained speed, rather than messing with the frameskip everytime the slightest slowdown occurs, even if it's only a frame or two long.

: 13.) Oh yeah, add screenshot support at least, possibly movie support. Think you could do demos as well? (Like V9T9)

Screenshot, yes. Movie support - hmm... it would be rather cool to save direct to AVI, as long as it's Windows anyway. ;) Demos? No.

Mind you, screenshot support is a bit silly since in Windows you can obtain a screenshot of any window any time. Press Alt-PrintScreen to capture the active window, or just PrintScreen for the whole screen. Then go into your favourite paint program (or MSPaint, if you have nothing else) and select Edit->Paste. One screenshot. ;)

: 14.) How about on-the-fly debug enabling/disabling?

Been in since the very beginning of debug support. HOME to enable and END to turn it off. Only in the latest build has it been fast enough to be cool as well as useful, though ;)

: 15.) Are the comments on the modules in TIDATA still valid?

To my knowledge. I haven't gone through them all lately, but I update them as I play with them.

: 16.) I bet I could find Ed Swartz on the Net, with a well-worn T-shirt for scent and a head start, if need be. Wouldn't that be cool? Full circle.

He's a good guy, but I dunno if he'd be interested. I'd be happy to say hi again, though. ;)

To insert another comment here, Jack said:

:The only problem other than speed I've noticed involves using Alt-= to re-boot the emulator. About 75% of the time, the emulator video is badly scrambled after doing this, though it appears to be running correctly.

I've seen that rarely... ah, heck. I think I'll just change the way it reboots. Right now it tries to be "legit" and does a BLWP @>0000. Actually, I bet it's an interrupt getting in the way... I'm forgetting to turn off interrupts before I do that. I'll try to fix that.

And Jim said...
:Upon examination I found out that the tidata file provided with this latest build does not have Dig Dug commented out, and since I didn't have Dig Dug in my mods folder the emulator wouldn't start.

D'oh! Sorry... I'm still trying to understand why the AtariSoft carts mostly screw up. I'll be more careful. ;)

Thanks for the comments, everyone, it was pretty surprising. :)

Follow Ups:

Post a Followup




Optional Link URL:
Link Title:
Optional Image URL:

[ Follow Ups ] [ Post Followup ] [ TI-99 Emulator Forum ] [ FAQ ]