Jump to content
IGNORED

Classic99 Updates


Tursi

Recommended Posts

Oh this will come in really handy for me! :thumbsup: I'll download it tonight from home. I have a batch file that does builds for me, and I can add a call to classic99paste to reset classic99 for me (which is all I need to do, since resetting it causes the module binary to be re-loaded) and that will be the final link that I was missing for a fully automated build/test cycle.

 

Nice one!

 

Is there any chance you could make it make a nice cup of tea? Oh, and let the cat out? :)

Link to comment
Share on other sites

Hey Tursi, I recently downloaded "adventures in dinosaurland" (attached) which will only work in MESS using the TI SD floppy driver (will not work with myarc or other variants) and was wondering what emulated floppy hardware Classic99 uses by default and if the standard TI SD mode could be implemented?

DOD.zip

Edited by OX.
Link to comment
Share on other sites

Strange indeed. I tested it with the BwG controller in MESS, and it seems to work as well. The TI FDC has a FD1771, while there is a WD1773 in the BwG (both the same family), but the HDC 9234 in the HFDC fails. So that's a direct controller access?

Link to comment
Share on other sites

Strange indeed. I tested it with the BwG controller in MESS, and it seems to work as well. The TI FDC has a FD1771, while there is a WD1773 in the BwG (both the same family), but the HDC 9234 in the HFDC fails. So that's a direct controller access?

 

It would appear the failure is a direct result of using TI-defined VDP memory pointers and/or locations for file and boot tracking. Myarc cards do not use memory in the same fashion, thanks to on-board cache. Unfortunately, what worked fine with TI and CorComp fails with Myarc controllers. Editorial: for all the creativity some programmers had, to me it seemed they were either (1) being lazy or (2) taking a jab at Myarc products.

 

Based on a quick disassembly the load program has an embedded program image file loader. It loads the selected EA5 file, which immediately relocates itself from 0x3000 to 0x2000. From there it pulls some info from VDP and scratchpad, sets up the filename, and begins its magic. I saw no direct track or DSR access, just the usual DSRLNK surrounded by some simple display code.

Link to comment
Share on other sites

Hey Tursi, I recently downloaded "adventures in dinosaurland" (attached) which will only work in MESS using the TI SD floppy driver (will not work with myarc or other variants) and was wondering what emulated floppy hardware Classic99 uses by default and if the standard TI SD mode could be implemented?

 

I'll accept Tim's analysis and just answer the question:

 

Classic99 does not emulate any classic floppy hardware. :) And I do not intend to implement any floppy controller chips for low level access. There is no classic disk-controller specific software on the TI that makes any sense for me to develop new software for under emulation, and that is one of my main criteria. My stance is that new software should be as agnostic to the file system as possible, so that it runs no matter what the user has. Running old software is slightly less important to Classic99's development, although doing so helps prove the hardware. ;)

 

Classic99's file system is a DSR written entirely by me for theoretical hardware backed by the PC file system. This DSR uses no TI memory at all (which has caused more issues than I originally expected). I've been working on getting that as close as I can for some years now, and that was one of the reasons floppy image support was so late (that and I don't like the limitations). Even the floppy image support currently uses my custom, from-scratch DSR to read the images. It doesn't have write support mostly because I'm a coward and worried that my first attempt to get file allocation right will have bugs that corrupt people's disk images. ;) Someday I will take the chance.

 

The point is one day that disk code will run in a piece of hardware attached to a real TI, and so I need to try to get it right. ;) For a piece of software as described above, I'd be inclined to patch the program to be generic.

 

 

Link to comment
Share on other sites

Quick update regarding the Dinosaur DIsk code:

 

The XB LOAD program utilizes the Millers Graphics GPLLNK/DSRLNK code nearly identical to that published in the July 1986 SmartProgrammer magazine. It contains LINKs to (a) load an EA5 program and (b) load character sets from the console. The EA5 load routine will read single or chained images based on the 6-byte file header; (b) it uses GPLLNK to set the character sets found in the console; © it sets a few VDP registers and (d) launches the EA5 program.

 

The EA5 program contains the standard DSRLNK routine. It too has an EA5 image loader though written in a different manner. Its purpose seems simple - load a few images and display them.

 

Honestly, the whole load and execute process is convoluted, IMHO. I do not know if the two loaders were written by the same or different people, perhaps one familiar with XB and the other EA5 environments?

 

Why the program fails to work with a Myarc card is not yet evident. The XB program simply refuses to load a file. Either the universal DSR is not universal.. or there is something else at play. DSR pointers at 0x8354 and 0x8356 appear to be used as expected. PABs are set up normally. I am still leaning toward the boot tracking theory. This silly little puzzle has me hooked for the moment.

Link to comment
Share on other sites

If I remember correctly I had this same problem and the loader was not written by the same person.

I got a complaint that the XB loader would not work with RXB and if I remember correctly the reason why is the goofy loader.

 

I did not have a problem with it as I used RXB with FW to load and run it.

Link to comment
Share on other sites

If I remember correctly I had this same problem and the loader was not written by the same person.

I got a complaint that the XB loader would not work with RXB and if I remember correctly the reason why is the goofy loader.

 

I did not have a problem with it as I used RXB with FW to load and run it.

How and what file did you run from FW?

 

I found a few problems with the code. The first is the loader trying to load beyond the VDP memory limits. The second and more difficult to track down is a DSR pointer (0x8356) which is being set wrong either by the loader or a device. In fact, the second program has a kludge to fix the filename, which may be the reason Myarc cards failed, and the reason the filenames have a duplicated first character.

 

Regardless, I am now able to successfully load the program in Classic99 and on the Geneve (with a Myarc card!) with no problems. I'm still not sure where the value is set wrong, though so far it -appears- to be a problem with the Millers Graphics DSRLNK/GPLLNK or the 4A ROM code. The mystery will have to wait until I have another chance to dig further...

 

Thanks to Tursi for verifying some Classic99 information and for running through the code following some initial conjecture.

Link to comment
Share on other sites

  • 2 weeks later...

Speaking of bugs... I noticed when I play some games keys get stuck or action stops. For instance, in "Spy's Demise" my spy keeps going in some direction even after I have released the key. In "Rabbit Trail," my rabbit stops hopping (sometimes stuck in the air) for a few seconds, but the weasels do not -- as a result, I can never pass the first level.

 

One interesting thing I noticed with "Spy's Demise" is if I press the Windows key to bring up the Start menu, then go back to the game, whatever directional key is stuck becomes un-stuck. I have tried this using the arrow keys as well as EXSD.

Link to comment
Share on other sites

I have noticed when running EA Assembling a file only size of 9 it takes 2 minutes to create a Assembly file in Classic99 normal mode?

 

I have a 3 Ghz Quad Core Xeon processor with 6 Gig of ECC RAM using a 1TB SATA3 drive. http://www.amazon.com/gp/product/B000XZ5JBW/ref=as_li_ss_tl?ie=UTF8&camp=1789&creative=390957&tag=atariage&creativeASIN=B000XZ5JBW&linkCode=as2

 

Only runing Classic99, Ti99Dir and Notepad. I have to turn off the Windows Media player for music as it should not have that much effect on the performance?

 

I mean I can run 4 movies at the same time and Itunes plus play a game like StarWars online with out a hitch? WTH is going on?

 

(I do love Classic99 the most of the Emulators for ease of use.)

Link to comment
Share on other sites

Speaking of bugs... I noticed when I play some games keys get stuck or action stops. For instance, in "Spy's Demise" my spy keeps going in some direction even after I have released the key. In "Rabbit Trail," my rabbit stops hopping (sometimes stuck in the air) for a few seconds, but the weasels do not -- as a result, I can never pass the first level.

 

One interesting thing I noticed with "Spy's Demise" is if I press the Windows key to bring up the Start menu, then go back to the game, whatever directional key is stuck becomes un-stuck. I have tried this using the arrow keys as well as EXSD.

 

Well, I'm going to undo that whole reply.. Classic99 already resets the emulated keyboard if anything else takes focus.

 

So in that case, I would expect that clicking any other window would also clear your problem.. does that seem to be true?

 

I've played with Rabbit Trail without any problem, have not tried Spy's Demise though. It's worth noting that depending on both your configuration and how the software scans the joystick lines, the arrows keys may be a joystick or they may be FCTN+ESDX.

 

 

Edited by Tursi
Link to comment
Share on other sites

I have noticed when running EA Assembling a file only size of 9 it takes 2 minutes to create a Assembly file in Classic99 normal mode?

 

I have a 3 Ghz Quad Core Xeon processor with 6 Gig of ECC RAM using a 1TB SATA3 drive. http://www.amazon.com/gp/product/B000XZ5JBW/ref=as_li_ss_tl?ie=UTF8&camp=1789&creative=390957&tag=atariage&creativeASIN=B000XZ5JBW&linkCode=as2

 

Only runing Classic99, Ti99Dir and Notepad. I have to turn off the Windows Media player for music as it should not have that much effect on the performance?

 

I mean I can run 4 movies at the same time and Itunes plus play a game like StarWars online with out a hitch? WTH is going on?

 

(I do love Classic99 the most of the Emulators for ease of use.)

 

Pretty hard to say. First question would be "how long does the same file take on hardware?" If you aren't running overdrive, then it should be comparable, only the disk access would differ. Does turning off Media Player make a difference or are you doing it just in hopes that it will? What does your CPU graph show while this is happening? Does the Classic99 debug log report any issues? Maybe it can't get the high performance timers and has to fall back on sleeping.

 

 

Link to comment
Share on other sites

Well, I'm going to undo that whole reply.. Classic99 already resets the emulated keyboard if anything else takes focus.

 

So in that case, I would expect that clicking any other window would also clear your problem.. does that seem to be true?

 

Interestingly, I cannot replicate the problem, now. I will ket you know once it reappears.

 

EDIT: It started doing this while playing Parsec... maybe something with my environment, but it seems only to have recently occured. Yes, clicking on another window does reset this. Killed one of my best Parsec games in a long time. *sigh*

 

I've played with Rabbit Trail without any problem, have not tried Spy's Demise though. It's worth noting that depending on both your configuration and how the software scans the joystick lines, the arrows keys may be a joystick or they may be FCTN+ESDX.

 

I can reproduce this, and I will try to get some video into a GIF later. One thing I just noticed is if the Classic 99 window is partially covered by another window the emulator runs faster. This could be due to my system: Core2Duo 1.6GHz, 2GB RAM, XP x64, Intel graphics decellerator. I do not run C99 on another system, but perhaps I should try sometime.

Link to comment
Share on other sites

Pretty hard to say. First question would be "how long does the same file take on hardware?" If you aren't running overdrive, then it should be comparable, only the disk access would differ. Does turning off Media Player make a difference or are you doing it just in hopes that it will? What does your CPU graph show while this is happening? Does the Classic99 debug log report any issues? Maybe it can't get the high performance timers and has to fall back on sleeping.

 

Maybe I am just used to using my SCSI instead. It is tons faster then DISK. Turning of the Media player helps slightly so maybe it is hard drive access slowing it down.

Link to comment
Share on other sites

  • 2 weeks later...

Um. It would be, but I can't see how it's possible.

 

Can I see this test app, too? :)

 

This is the code in VDPDisplay that checks for blank. It occurs before any display or sprite processing occurs, right after the buffer is cleared.

 

		if (!bDisableBlank) {
		if (!(VDPREG[1] & 0x40)) {	// Disable display
			return;
		}
	}

 

I can't reproduce here.

 

Link to comment
Share on other sites

My code to disable the screen looks like this:

 

LI R0,>0182 * Reg 1: 16K, display off, no interrupt,
BL @VWTR * graphics 2, size = 1, mag = 0.

 

Could it have something to do with the else statement in this part of your code? Looks like you're only checking for text mode and not for blank.

 

if (redraw_needed) {
...
}
else {
// we have to redraw the sprites even if the screen didn't change, so that collisions are updated
// as the CPU may have cleared the collision bit
// as long as mode bit 2 is not set, sprites are okay
if ((VDPREG[1] & 0x10) == 0) {
 DrawSprites();
}
}

Link to comment
Share on other sites

I have run into a problem with RXB and Classic99

 

Often times when I write a program I use my CALL KEY("P",0,K,S) but Classic99 stores the character in the buffer so the next CALL KEY("",0,K,S) is just ignored.

 

Like in IN THE DARK I had change to this in the game.

 

140 ! KEYS IN Z$=ARROWS OR Ss Dd Xx Ee SPACE ENTER AID Pp

150 Z$=CHR$( 8)&"Ss"&CHR$(9)&"Dd"&CHR$(10)&"Xx"&CHR$(11)&"Ee"&CHR$(32)&CHR$(13)&CHR$(1)&"Pp"

 

200 ! ARROWS OR L,R,D,U,SPACE,ENTER,FCTN7,P,p

210 CALL ONKEY(Z$,0,K,Z)GOTO 370,370,370,410,410,410,450,450,450,510,510,510,580,690,810,1590,1590

 

360 GOTO 200

 

1570 CALL HPUT(24,8,"<PRESS ANY KEY>") :: CALL KEY(0,K,Z) :: IF Z=0 THEN 1570 ELSE RETURN

 

 

1590 ! PAUSE KEY

1600 CALL CLEAR :: CALL HPUT(10,13,"PAUSED!") :: GOSUB 1570 :: GOTO 160

 

In Classic99 I was forced to change 1570 to a normal XB CALL KEY as the below line would refuse to ever execute.

 

1570 CALL HPUT(24,8,"<PRESS ANY KEY>") :: CALL KEY("",0,K,Z) :: RETURN

 

It would just ignore that CALL KEY("",0,K,Z) and act like the same at the first one because of the Classic99 key buffer.

 

Even if I put FOR Z=0 to 1000 :: NEXT Z before the CALL HPUT or CALLK KEY("",0,K,Z) it would just ignore it.

 

100% the key buffer in Classic99 as the issue, but at least I can do a work around.

Edited by RXB
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...