The Missing Link and Classic99

[senior_falcon]

I discovered a couple days ago that TML and Classic99 are not as compatible as I thought they were. Classic99 runs the long TMLDEMO program just fine. Once in a while it doesn't start but you just run it again and things work properly. As I recall it runs "Who's behind the Mexican UFO's" properly as well. But you run into problems when trying to develop programs using the TML/Classic99 combination. Every 5th time (give or take) that you run the program it crashes and your work is lost unless you've saved it just before testing. This is quite aggravating. I don't know why this is so; evidently interrupts are handled differently in Classic99 than on real iron or Win994a, both of which run TML programs as expected. (Just to make it interesting, the 2 color mode works properly in Classic99 but not in Win994a) Unless a fix can be found it looks like development work with TML would have to be in Win994a, Mess or real iron.

[Tursi]

Are you sure it's interrupts and not the different disk system? Interrupts don't work differently than on real iron. TML had problems with the CF7 too.

[senior_falcon]

TML puts the pattern table at >2000 and the color table at >0000. When it starts up it changes the pointer (I think at >8370) to the the disk buffer and moves the 8 byte disk buffer header so that enough space is reserved for the pattern table. This is where it runs afoul of the CF7. Then a pointer to an interrupt routine is loaded into >83C4. This routine monitors whether the program is running or not and sets the VDP registers accordingly. If it is using 16 colors it also checks VDP ram at >0388 to see if it has been reset to >0958. If so the routine loads >1800 to VDP ram >0388 and also to >8324 and >836E. I believe this is where the problem arises. It can't be the different disk system; if it were then TML would misbehave in the 2 color mode as well. BTW, this mode uses half bitmap for the color table and full bitmap for the patterns and Classic knows to do the right thing.

 

You're in the best position to know how interrupts are handled in Classic, but what I have observed is that, although programs seem to run at the proper speed, sound lists (which run off the interrupt) play at about half speed. (I also feel that sprites move more slowly) It might be the old computers I use, but I would expect a more general slowdown and not just in processing sound lists. If you are interested, I can do some tests to see if my observations are correct.

[Tursi]

That may be a local issue on the speed thing -- I do a lot of interrupt programming (I just released a sound player, for example!) and I use Classic99 for all my dev and testing, they run at the proper speed for me. The thing that is different from the other emulators is that the interrupt timing is detached from the rest of the system (where most emulators will block for interrupt handling), so if something is causing that thread to run slowly, you would probably see those effects. If a slow interrupt breaks TML... then yeah, I can buy that. (Although I'm still not completely sure why the system would run apparently at the right speed but interrupts are not, because the CPU cycles are gated through the interrupt processing thread - slow interrupts would give the CPU fewer opportunities to run).

 

Silly question.. you don't have a Frameskip value set in the configuration or in the Classic99.ini? It's still in there (Options->Options), but, I am pretty sure it's completely broken, and might be causing issues like that if it's anything but 0. (Although I tested here and it doesn't seem to do anything.. but I'm not sure what else it may be).

 

Before the last update, my laptop was having trouble keeping up with interrupts, but it behaves better under 373 -- there was a race where an interrupt that was /just/ missed could be lost.

 

If we can prove it's interrupts, though, I can put it on my list to revisit that code. It's pretty old and I want to redo it anyway.

[senior_falcon]

I've done a few speed tests on this. Here's the program:

5 CALL CLEAR

10 CALL SPRITE(#1,65,16,100,1,0,4)

20 FOR I=1 TO 10000 ::DISPLAY AT(24,1):I::NEXT I

I ran this for 30 seconds, then pressed Fctn 4

Classic99 and Win994a both read about 540, so they execute the program at about the same speed.

Then I ran the program in both environments and pressed break when the sprite reappeared on the left.

For Classic99 the number was 556 to traverse the screen

For Win994a the number was 317 to traverse the screen

So clearly Classic is moving the sprite slower

Here's the weird thing:

When Win99 is also running, the sprite moves faster in Classic99! To traverse the screen the number is about 415

Will test this out on a faster computer and real iron later today.

[Asmusr]

In my Classic99 the counter is about 300 when the A has traveled the screen. In my own emulator the counter is 320.

[Tursi]

I'm getting about 300-310 as well. But my netbook, which used to have trouble with the bug I mentioned above, is also getting the same range.

 

Can you please confirm that you are running version QI373 (help->about) and that your CPU is set to 100% with 0 frameskip (Options->Options)?

 

I should note that my real hardware scores 282 (with 8-bit 32k and real 9918A). The A takes about 18 seconds to cross the screen, versus about 20s on Classic99.

 

The Win994A difference is likely caused by Win994A changing the system tick rate with the multimedia API (you can change the system quantum from 15ms to 1ms for more accurate timing - but this affects the entire system, not just the application who calls it). Classic99 doesn't do this because I was restricted to Windows 95 APIs for a handful of users. I do plan to ditch that backwards compatibility.

[senior_falcon]

Good news!!

I tested a benchmark on my newer computer (Dell Optiplex GX620 - which is not all that new) and things seem a whole lot better. The speeds are roughly comparable with real iron and, best of all, the tendency to crash is almost non-existant. Here's the program to test for crashes:

10 CALL LINK("CLEAR")

20 CALL LINK("PRINT",100,100,"HELLO WORLD")

30 CALL LINK("CHAR",96,"0123456789ABCDEF0123456789ABCDEF")

40 RUN

On my old laptop (HP Pavillion ze2000) it was lucky to get 4 or 5 iterations before crashing. On the newer optiplex there might have been a crash in 500 to 1000 iterations. Not perfect, but quite useable. Still, it would be a good idea to save a program you are developing before testing it out, just in case. I suppose there's no need to worry too much about this problem, as this old computer is probably the slowest in use on this forum.

I will check the version of Classic99 just to be sure, but I have to go to Windows to do that. I just checked the version running in wine and it is 372, as is the version on the Optiplex, so the version on the HP is probably 372 as well.

[senior_falcon]

Version 373 makes no difference on the old laptop.

[Tursi]

373 did fix an interrupt timing bug, but it's a shame it didn't make any difference for you. It does mean there is an interaction (or lack of interaction) I was not aware of though. Did you check that the CPU slider in Options->Options was set to 100%?

 

Thanks for the details, it's on the list. I know everyone's moving away from Classic99 again, but at least for my own use.

[+Lee Stewart]

373 did fix an interrupt timing bug, but it's a shame it didn't make any difference for you. It does mean there is an interaction (or lack of interaction) I was not aware of though. Did you check that the CPU slider in Options->Options was set to 100%?

 

Thanks for the details, it's on the list. I know everyone's moving away from Classic99 again, but at least for my own use.

 

Not to get too far off topic; but, certainly not here. I use Classic99 exclusively for development. It's only after I get to a fairly stable place that I even think about other emulators or even real iron, for that matter!

 

...lee

[senior_falcon]

 

Not to get too far off topic; but, certainly not here. I use Classic99 exclusively for development. It's only after I get to a fairly stable place that I even think about other emulators or even real iron, for that matter!

 

...lee

I feel the same way, which is why it was so distressing to find that development work with XB256 and TML might be a problem with Classic99. But it seems to work well enough on my newer desktop computer.

Tursi, you're just gonna love this... I felt that 373 was sluggish compared to 372. I loaded TML and started it up, then loaded and ran TMLDEMO. From the time I pressed Enter it took 19 seconds to display the full title screen with 372; it took 35 seconds with 373. Don't know the cause, my 1.6GHz Sempron is humming along just fine using only around 5 % of the cpu time for either version. FWIW, Classic99 running in Linux using wine uses pretty much 100% of the cpu time and the cooling fan speeds up and is on all the time. Which is why I return to XP to use Classic99.

The slider is at 100% on both 372 and 373 and the frameskip is 0.

Edited July 1, 2014 by senior_falcon

[Gary from OPA]

I tested a benchmark on my newer computer (Dell Optiplex GX620 - which is not all that new) and things seem a whole lot better. .

Hey, I just bought myself a used Dell Optiplex GX620 computer here, as my current desktop got on fire, so I needed an asap replacement right away.

 

I should test this benchmark myself and see what it does, but where do you get TML from?

[Asmusr]

373 did fix an interrupt timing bug, but it's a shame it didn't make any difference for you. It does mean there is an interaction (or lack of interaction) I was not aware of though. Did you check that the CPU slider in Options->Options was set to 100%?

 

Thanks for the details, it's on the list. I know everyone's moving away from Classic99 again, but at least for my own use.

 

I'm certainly not moving away either. The debugger in Classic99 is essential for assembly programming.

 

I don't think this has any relation to the problems senior_falcon is reporting but it has happened a few times that I was jumping between breakpoints in my code and then Classic99 ended up in a infinite interrupt routine loop. I will try to put together some code to replicate this,

[Willsy]

Thanks for the details, it's on the list. I know everyone's moving away from Classic99 again, but at least for my own use.

 

I don't think that's true. I actually think the opposite is true. *More* people are starting to use it in anger. That's a good thing. Previously, it's mostly been us developers that have been using it (for me, the killer is the debugger, which is brilliant) and we've been willing to put up with it's various idiosyncracities (e.g. timing, dodgy speech) etc. Now, more people are coming to it - Win994A has dropped by the wayside, MESS is conceived as being hard to use, the Java emulator hasn't taken off. The reason you're seeing more noise/complaints about Classic99 is because people are turning towards it, not away from it.

 

It might just be time to seriously sit down with it and start ironing out some of the issues that I know you've been frustrated with over the years. Maybe the time to bite the bullet is now. I'd be happy to make another donation to classic99's development if it's going to get some of the issues ironed out! Strip out those old API interface calls, maybe use WinXP or Win Vista as the baseline, and have at it! If I were a decent Win C programmer I'd even help you, but C generally makes me want to kill someone, and Windows C makes me want to start WWIII

[senior_falcon]

Hey, I just bought myself a used Dell Optiplex GX620 computer here, as my current desktop got on fire, so I needed an asap replacement right away.

 

I should test this benchmark myself and see what it does, but where do you get TML from?

Hi Gary:

Just go to the top of the page which is "Development Resources" , scroll down a bit and The Missing Link will be right there.

I haven't tested TML with Classic99 373 on the optiplex but it seemed to work OK with 372. The problems I have had have been with my ancient HP laptop.

[Tursi]

Tursi, you're just gonna love this... I felt that 373 was sluggish compared to 372. I loaded TML and started it up, then loaded and ran TMLDEMO. From the time I pressed Enter it took 19 seconds to display the full title screen with 372; it took 35 seconds with 373. Don't know the cause, my 1.6GHz Sempron is humming along just fine using only around 5 % of the cpu time for either version. FWIW, Classic99 running in Linux using wine uses pretty much 100% of the cpu time and the cooling fan speeds up and is on all the time. Which is why I return to XP to use Classic99.

The slider is at 100% on both 372 and 373 and the frameskip is 0.

Thanks! Hmm.

 

To be honest, I felt it was a little sluggish too, but that's pretty extreme. It's clear that refocusing on that area of the code needs to be my next priority (but it may be a few weeks :/ )

 

Wine has been weird over the years, but, I haven't really been able to provide any support there. I suspect the main difference is that the bitdepth conversion code or conversion from DIB to display buffer in Wine's video emulation is probably less efficient and/or unaccelerated compared to a full Windows installation, and Classic99 makes the OS take care of that. The quality of the video driver has always made a huge difference for that reason.

 

Rasmus -- I've seen this too, but I wasn't sure that I didn't do something myself. Certainly if you work out what triggers it, I'm all ears, and I'll pay more attention the next time I see it too.

[Tursi]

I don't think that's true. I actually think the opposite is true. *More* people are starting to use it in anger. That's a good thing. Previously, it's mostly been us developers that have been using it (for me, the killer is the debugger, which is brilliant) and we've been willing to put up with it's various idiosyncracities (e.g. timing, dodgy speech) etc. Now, more people are coming to it - Win994A has dropped by the wayside, MESS is conceived as being hard to use, the Java emulator hasn't taken off. The reason you're seeing more noise/complaints about Classic99 is because people are turning towards it, not away from it.

Dodgy speech, that's it. I didn't want to put that in in the first place. It's coming out! (Nah, I'm kidding, I just don't care how well the speech works. Yet. )

 

Although I'll note that the comments are "Classic99 doesn't work like the real hardware so I'm using MESS". That's turning away.

 

Anyway, I appreciate everyone jumping on that comment, it was just a little whine and it's fine to ignore them. If Classic99 was going to die /fully/, it would have happened in the 90s when the community ticked me off so much I wanted to stop all development. It's much more fun now.

 

It might just be time to seriously sit down with it and start ironing out some of the issues that I know you've been frustrated with over the years. Maybe the time to bite the bullet is now. I'd be happy to make another donation to classic99's development if it's going to get some of the issues ironed out! Strip out those old API interface calls, maybe use WinXP or Win Vista as the baseline, and have at it!

It's definitely building up to it, but, it's very hard to get the binge time I used to have (especially during the year I wasn't working ). Is Vista a good baseline for people (I guess XP is old enough to be obsoleted, but people made such a fuss). But Vista has some beautiful APIs I was looking at as part of my research that would make some things much cleaner. (Alternately, maybe I shouldn't care if Vista is too new, I dunno.) I'm trying to get a lot of things cleaned up, in six months I'm scheduled to ship out to Shanghai (where I will either suddenly have more time or, more likely, no time at all ). But, that's excuses. It is bubbling up.

 

And, I appreciate the offer of a donation, but that's okay. I never delivered your last feature request! (Keyboard!)

[RXB]

Ok using TML is driving me nuts.

What I want to do is load the fonts 6x8 and look at them to see if they are a better alternative to my old RXB 2012 font set.

I make make a single line in XB:

 

11111 ! Just for MERGE

MERGE DSK1.LOADER

RUN

 

crash and long beep sound forever.....

 

So I reset Clasic99 and try this:

RUN "DSK1.TML"

reply no to hard drive.

reply 2 for 2 colors.

type NEW

OLD DSK1.LOADFONTS

RUN

 

Here is the program LOADFONTS:

10 A$="DSK1.68FONT"
20 GOSUB 100
25 CALL LINK("CHSIZE",6,
30 OPEN #2:"DSK1.FONTS",OUTPUT,DISPLAY,VARIABLE 80
40 FOR A=30 TO 128 :: CALL CHARPAT(A,A$)
50 PRINT #2:"      DATA  "&A$
60 NEXT A :: CLOSE #2 :: END
100 OPEN #1:A$,VARIABLE 241,INPUT,INTERNAL :: FOR C=33 TO 128 STEP 15 :: INPUT #1:A$ :: CALL LINK("CHAR",C,A$) :: NEXT C :: CLOSE #1 :: RETURN

And here is what I get for output from TML:

      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010

[Gazoo]

 

Ok using TML is driving me nuts.

What I want to do is load the fonts 6x8 and look at them to see if they are a better alternative to my old RXB 2012 font set.

I make make a single line in XB:

 

11111 ! Just for MERGE

MERGE DSK1.LOADER

RUN

 

crash and long beep sound forever.....

 

So I reset Clasic99 and try this:

RUN "DSK1.TML"

reply no to hard drive.

reply 2 for 2 colors.

type NEW

OLD DSK1.LOADFONTS

RUN

 

Here is the program LOADFONTS:

10 A$="DSK1.68FONT"
20 GOSUB 100
25 CALL LINK("CHSIZE",6,
30 OPEN #2:"DSK1.FONTS",OUTPUT,DISPLAY,VARIABLE 80
40 FOR A=30 TO 128 :: CALL CHARPAT(A,A$)
50 PRINT #2:"      DATA  "&A$
60 NEXT A :: CLOSE #2 :: END
100 OPEN #1:A$,VARIABLE 241,INPUT,INTERNAL :: FOR C=33 TO 128 STEP 15 :: INPUT #1:A$ :: CALL LINK("CHAR",C,A$) :: NEXT C :: CLOSE #1 :: RETURN

And here is what I get for output from TML:

      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010
      DATA  1010101010101010

 

Hey Rich, load up XB v2.7 in Classic99. Look at the font. It's the one I've been using for everything forever. The capitals are one dot less in height from most fonts and the lower case has true descenders. The Upper case and Lower case letters line up properly. There's no touching between lines. I believe it's the perfect TI Font. Check it out and see if you like it.

 

Gazoo

[RXB]

Thanks Gazoo figured it out by looking at the way TML loads the characters and rewrote a program to print them out.

 

I will take a look at yours and see.

[senior_falcon]

You have to remember that TML is running in the bitmapped mode. Printing characters on the screen is not the same as it is in graphics or text mode. There is no pattern table located in VDP memory; instead it is stored in low memory. This is why the CALL CHARPAT in line 40 returns what seems like a bogus value - you are actually looking at the 6K long color table which is set to black on transparent at startup.

 

68FONT is simply a file containing concatenated strings that let you read and define 15 character definitions at a time. If RXB lets you define 15 characters in a single CALL CHAR then you can bypass TML and simply define the characters directly like this:

10 A$="DSK1.68FONT"
100 OPEN #1:A$,VARIABLE 241,INPUT,INTERNAL :: FOR C=33 TO 128 STEP 15 :: INPUT #1:A$ :: CALL CHAR(C,A$) :: NEXT C :: CLOSE #1 :: RETURN

If not you can break up the strings into shorter lengths that can be used by CALL CHAR.

 

I think this font was borrowed from the Funnelweb word processor.

[RXB]

You have to remember that TML is running in the bitmapped mode. Printing characters on the screen is not the same as it is in graphics or text mode. There is no pattern table located in VDP memory; instead it is stored in low memory. This is why the CALL CHARPAT in line 40 returns what seems like a bogus value - you are actually looking at the 6K long color table which is set to black on transparent at startup.

 

68FONT is simply a file containing concatenated strings that let you read and define 15 character definitions at a time. If RXB lets you define 15 characters in a single CALL CHAR then you can bypass TML and simply define the characters directly like this:

10 A$="DSK1.68FONT"

100 OPEN #1:A$,VARIABLE 241,INPUT,INTERNAL :: FOR C=33 TO 128 STEP 15 :: INPUT #1:A$ :: CALL CHAR(C,A$) :: NEXT C :: CLOSE #1 :: RETURN

If not you can break up the strings into shorter lengths that can be used by CALL CHAR.

 

I think this font was borrowed from the Funnelweb word processor.

Yea just noticed that it is same as the FW version I made.

 

What I need it characters from 33 to 126 and MUST be 7 bytes per character as I do not have space for 8 bytes per character in RXB.

 

All the sets I see are always 8 bytes per character so I have had to modify them to fit so a few look really bad on screen.

 

I did try 6 byte by 8 version for 40 column mode but look like crap in XB.

[+Lee Stewart]

Yea just noticed that it is same as the FW version I made.

 

What I need it characters from 33 to 126 and MUST be 7 bytes per character as I do not have space for 8 bytes per character in RXB.

 

All the sets I see are always 8 bytes per character so I have had to modify them to fit so a few look really bad on screen.

 

I did try 6 byte by 8 version for 40 column mode but look like crap in XB.

 

There seem to be a couple of issues here:

1. All character sets for the TI-99/4A are 8 bytes/character. The reason CHARA1 files have the characters stored that way is that they are directly loaded to the VRAM Pattern Descriptor Table (PDT).
2. The repository for the default 8-byte character patterns is in console GROM, where they are stored as follows:

• "Standard Character Set" (8 bytes per character)

• "Small Capital Letters Set" (7 bytes per character)

• "Lower Case Set" (7 bytes per character)

Most applications on the 4A do not use the "Standard Character Set" because the character rows all touch each other. I think the TI-99/4 is the only platform that uses it. On the 4A, the other two character sets are used and, because the top row byte of each character is always 0 to allow for the inter-row space, the repository does not need to store the top row. The GPL load routine, however, must (and does) zero the first byte of each character's PDT location before loading the remainder of the character.

 

The problem, then, with using character sets defined in CHARA1 files for adaptation to the GROM 7-byte-per-character repository is that many of them use descenders for lowercase g, j, p, q and y that extend into the last byte, with all the other characters blanking that last byte but not the first byte. The blanked byte is backwards from the usual GPL load. If such character sets were desirable for RXB, you could store the two character sets with the last byte of each character's definition removed, change the load routines to blank the last byte and patch the g, j, p, q and y last bytes in VRAM after the load.

 

I think Tony (@Gazoo) said his complete character set for the multi-program cartridges he's been posting uses TI Writer's font, which has all the characters (including those with descenders) in a 6x7 matrix, which would allow for either the first or last byte to be blanked and the font stored in GROM as 7 bytes/character per your space requirements.

 

...lee

[Willsy]

Check out the lower case characters in turbo forth. They line up perfectly with TIs upper case set and they have descenders. User it if you want. The definition data is in initialise.a99 i the second bank of the source code on the tf website.