Classic99 Updates

[Tursi]

Using the CPU to time the system is why Classic99 has timing problems in some applications, like speech -- sometimes the CPU is supposed to stop. The CPU and VDP are not executing in lockstep, so that trick won't work the same way as you observe on MESS.

[Asmusr]

Titanium is no longer working in the latest version of Classic99. The 'boot tracking' code is going into a long loop that overwrites the RAM (because the counter R4 is zero):

 

BOOTTR MOV @>83D0,R12 * GET THE CRU BASE IN R12

MOV @>83D2,R9 * GET THE ROM ADDRESS FOR DEVICE

SBO 0 * ENABLE THE ROM

AI R9,4 * ADDING FOUR PUTS US AT THE LENGTH BYTE

MOVB *R9+,R4 * PLACE THAT IN R4 AND INCREMENT R9

SRL R4,8 * RIGHT JUSTIFY LENGTH IN R4

LI R10,FILEDV * POINT TO TEXT BUFFER

MOVIT MOVB *R9+,*R10+ * MOV ONE BYTE FROM ROM TO TEXT BUFFER

DEC R4 * FINISHED?

JNE MOVIT * NO, DO ANOTHER BYTE

SBZ 0 * DISABLE THE ROM

B *R11 * BRANCH TO NEXT SECTION OF CODE

 

Can anyone explain how to post formatted code on AtariAge?

[matthew180]

Use the [ code ] [ / code ] tags, without the spaces. If you use the "visual" editor I think you can just highlight the code section and select "code" from the toolbar.

[Asmusr]

I though the BBCode mode would work the same as code tags? Now this is with code tags:

 

BOOTTR MOV @>83D0,R12  * GET THE CRU BASE IN R12
       MOV @>83D2,R9   * GET THE ROM ADDRESS FOR DEVICE
       SBO 0           * ENABLE THE ROM
       AI R9,4         * ADDING FOUR PUTS US AT THE LENGTH BYTE
       MOVB *R9+,R4    * PLACE THAT IN R4 AND INCREMENT R9
       SRL R4,8        * RIGHT JUSTIFY LENGTH IN R4
       LI R10,FILEDV   * POINT TO TEXT BUFFER
MOVIT  MOVB *R9+,*R10+ * MOV ONE BYTE FROM ROM TO TEXT BUFFER
       DEC R4          * FINISHED?
       JNE MOVIT       * NO, DO ANOTHER BYTE
       SBZ 0           * DISABLE THE ROM
       B *R11          * BRANCH TO NEXT SECTION OF CODE

This is the code that fails on Classic99. It works on a real console with nanoPEB and also in MESS.

[Willsy]

I think is because classic 99 simply doesn't use a "TI side" DSR at all so nothing gets paged into the DSR page on the SBO instruction.Set a breakpoint on the instruction after the SBO and examine >4000 on the debugger. What do you see?

[Asmusr]

Titanium works if you enable TI Disk Controller support, see:

http://atariage.com/forums/topic/165901-classic99-updates/page-28?do=findComment&comment=2830485

[Tursi]

I though the BBCode mode would work the same as code tags? Now this is with code tags:

 

 

BOOTTR MOV @>83D0,R12  * GET THE CRU BASE IN R12
       MOV @>83D2,R9   * GET THE ROM ADDRESS FOR DEVICE
       SBO 0           * ENABLE THE ROM
       AI R9,4         * ADDING FOUR PUTS US AT THE LENGTH BYTE
       MOVB *R9+,R4    * PLACE THAT IN R4 AND INCREMENT R9
       SRL R4,8        * RIGHT JUSTIFY LENGTH IN R4
       LI R10,FILEDV   * POINT TO TEXT BUFFER
MOVIT  MOVB *R9+,*R10+ * MOV ONE BYTE FROM ROM TO TEXT BUFFER
       DEC R4          * FINISHED?
       JNE MOVIT       * NO, DO ANOTHER BYTE
       SBZ 0           * DISABLE THE ROM
       B *R11          * BRANCH TO NEXT SECTION OF CODE

This is the code that fails on Classic99. It works on a real console with nanoPEB and also in MESS.

 

As I noted, I want to discourage software that makes use of side effects from DSRs, as they are likely to fail on other devices. Does your code work from hard drives in MESS, for instance?

 

New software should be written to the base level, so that it works on all the devices that we have at our disposal today.

 

As a result of this choice, the default configuration of Classic99 overwrites large blocks of data after it executes, anything that is commonly used to pull off tricks that are likely to fail on other devices. You should find that the data you are trying to access has been overwritten with >4A bytes.

 

As per the release notes, you can disable this behavior by clearing the switch in Classic99.ini:

 

Regarding the corruption, in the normal FIAD or DSK modes, after a DSR call Classic99 will fill all VDP memory above the top of VRAM pointer, and known unsafe scratchpad locations, with the value "4A" - this can help you test if you are using assumptions from the DSR, which may fail on other DSRs. You can disable this in the Classic99.ini file by setting [DEBUG] "CorruptDSKRAM=0" -- it is ON by default. (We'll see if this bites me. So far it seems okay on most...) Note that Classic99 doesn't write this value in the INI right now - you have to add it.

So, in your code you're trying to pull up leftover data from >83D0 and >83D2 - interestingly these were addresses that I specifically looked at a few times in my own testing. Ultimately, they are set by the TI Disk Controller DSR itself, which means there is no guarantee that other devices will set them.

 

This was all inspired by the number of problems people had with /just/ Classic99's DSR, so I have swung the pendulum rather deliberately in the other direction - I don't believe we should write new software that only works on a TI disk controller, either. (Although a lot of devices are based on that DSR, it would be nice if they don't all HAVE to be.) I took a chance that you all may beat me up for this.

 

Now that said.. I feel the better way to do boot tracking is to control the DSRLNK function -- you can have that stash the important information away (for instance, in memory expansion) for later access by your loader. This is actually what the Editor/Assembler EA#5 loader does - it stores important data in low memory expansion.

 

I think is because classic 99 simply doesn't use a "TI side" DSR at all so nothing gets paged into the DSR page on the SBO instruction.Set a breakpoint on the instruction after the SBO and examine >4000 on the debugger.

Classic99 still has a DSR, it just isn't the TI DSR. The Classic99DSK DSR just contains the necessary vectors to link the disk, clipboard, and clock devices in, but no actual code. it still pages in and out normally.

[Asmusr]

As I noted, I want to discourage software that makes use of side effects from DSRs, as they are likely to fail on other devices. Does your code work from hard drives in MESS, for instance?

Yes is does work with the Myarc disk controller, both floppy and hard disk, but only the hard disk root directory.

 

Now that said.. I feel the better way to do boot tracking is to control the DSRLNK function -- you can have that stash the important information away (for instance, in memory expansion) for later access by your loader. This is actually what the Editor/Assembler EA#5 loader does - it stores important data in low memory expansion.

It's beyond my skills to modify the DSRLNK function, but if I don't have some kind of boot tracking in Titanium it will only work from DSK1.

[+InsaneMultitasker]

So, in your code you're trying to pull up leftover data from >83D0 and >83D2 - interestingly these were addresses that I specifically looked at a few times in my own testing. Ultimately, they are set by the TI Disk Controller DSR itself, which means there is no guarantee that other devices will set them.

 

 

If my memory serves correctly, 0x83d0 and 0x83d2 are values set by most DSRLNK routines during their systematic search for a peripheral card/device name within the DSR ROM's device name table. I would not consider the values specific to any one controller card and as such, they should be maintained and not be overwritten. Whether a peripheral card mucks around with the values is a separate issue, IMHO.

[Tursi]

Ramus, your skills are fantastic, I don't think you'd have much trouble with DSRLNK.

 

Tim, yes, I double checked and went through my notes. Those two addresses, as I noted, I personally went back and forth on several times (adding them, then removing them from the wipe list, and finally settled with leaving them in). Although they are set by some DSRLNK functions they are not set by all (for instance, our scratchpad loader doesn't**), and my ultimate reason for blanking them was the fact that this is the software assuming what its loader was. I'm trying to reduce the assumptions that cause incompatibility.

 

It's a tough call, because one can similarly make the assumption about low memory addresses being set by Editor/Assembler, which I advocated above, and at some point you have to use someone else's code to bootstrap the thing, so an assumption somewhere is needed! Ultimately I'd like to see some sort of new standard put together for what is accepted and what isn't needed - I'd like to release new DSRs in the future and I don't want to have to account for a whole bunch of assumptions (or worse, forget one that's widely used. )

 

That said, this is a /debugging/ tool, not a mandate. For the next release I'll switch the default to off, and you guys can use it only if you care to. But... I'll exclude >83D0 and >83D2 from the wipe list too. After all, I've learned that worrying about the first draft is silly, everyone will happily tell you you're wrong and then you know what to fix.

 

(**edit: well, I checked the scratchpad loader, because I was going to update my Extended BASIC version of it... but since it uses the Editor/Assembler DSRLNK for the first half, it actually DOES load those addresses, so all is well. We'll make them official then.. )

Edited September 29, 2013 by Tursi

[Tursi]

I meant to add...

 

To account for people using different loaders, maybe it would be nice to have the boot tracking code in new software verify that the data in those pointers looks reasonable, and if not, fall back to DSK1? For instance, >83D0 MUST be between >1000 and >1F00 (inclusive), and >83D2 from >4000 to >5FFE inclusive?

[Tursi]

Classic99 v370

 

-Don't corrupt >83D0->83D3 in disk emulation

-Make DSK RAM corruption an option

-Add disable for F18A

 

http://harmlesslion.com/software/classic99

 

(tested both new options with Titanium )

Edited September 29, 2013 by Tursi

[+InsaneMultitasker]

Ramus, your skills are fantastic, I don't think you'd have much trouble with DSRLNK.

 

Tim, yes, I double checked and went through my notes. Those two addresses, as I noted, I personally went back and forth on several times (adding them, then removing them from the wipe list, and finally settled with leaving them in). Although they are set by some DSRLNK functions they are not set by all (for instance, our scratchpad loader doesn't), and my ultimate reason for blanking them was the fact that this is the software assuming what its loader was. I'm trying to reduce the assumptions that cause incompatibility.

 

It's a tough call, because one can similarly make the assumption about low memory addresses being set by Editor/Assembler, which I advocated above, and at some point you have to use someone else's code to bootstrap the thing, so an assumption somewhere is needed! Ultimately I'd like to see some sort of new standard put together for what is accepted and what isn't needed - I'd like to release new DSRs in the future and I don't want to have to account for a whole bunch of assumptions (or worse, forget one that's widely used. )

 

That said, this is a /debugging/ tool, not a mandate. For the next release I'll switch the default to off, and you guys can use it only if you care to. But... I'll exclude >83D0 and >83D2 from the wipe list too. After all, I've learned that worrying about the first draft is silly, everyone will happily tell you you're wrong and then you know what to fix.

Hehehe. TI'ers can be a boistrous group, indeed.

 

Your approach seems to work well and like you said, it is a good debugging tool. I've already used the extended file IO debugging to indirectly track down problems in the IDE DSR. Somewhere in my library I have various DSRLNK routines saved, including one labeled 'ultra standard' which was common back in the 80s. Hmmm, I wonder if the base DSRLNK was extracted from the E/A utility code and modified to work regardless of its environment? I may add that to my 'fun' list to compare code some day.

 

While reading the EA manual I noticed information comparable to 83D0 and 83D2 may be stored (or mirrored) in the low memory E/A DSRLNK utility workspace. This would be of no benefit to the XB environment which again leads me to wonder if the long-standing "DSRLNK code" (for XB or those not wanting to REF the EA utilities) uses 83D0/D2 to avoid the utility WS. There isn't much in the way of documentation so I doubt we'll ever know for certain.

 

From my perspective these are the common elements to consider for documentation purposes:

1. We know how a DSR header must be constructed. This is documented fairly well.

2. We know the basic search mechanisms - whether via the DSRLNK routine or self-rolled code - to find a routine or name in the DSR's linked lists. Again, these are documented.

3. VRAM and CPU RAM usage with respect to PAB and buffer locations is moderately documented. Code written to use CPU RAM will break if the DSR support is missing. (as expected). Thus most programs still use VDP exclusively unless written for a specific controller (i.e., Myarc Disk Manager software).

4. Many DSR-related memory pointers and usage are documented in various places, including 8354/8356, the level 2 additional info blocks and PAD usage.

5. It is implied but not well-documented that DSRs are entered from GPLWS and that certain registers, including the VDPWA (R15) must be set prior to entry.

6. This leaves us with pointers like 83D0/83D2 which are not well documented or understood. Determining which are standard and which are kludges is a bit tougher.

 

From what I've seen most of the "broken" code relies upon eccentricities within the controller DSRs or specific VDP usage. A handful will be specific to direct hardware manipulation, e.g. Track copiers and similar software. Seems to me you're down to addressing hacks, kludges, and some lesser-known-but-still-acceptable routines. I dare say that most remaining "emulation" issues will be related to boot tracking or VDP usage.

[Tursi]

Yeah, I'd agree with all of that, Tim.

 

I have spent a lot of time in the E/A DSRLNK function, as I've adapted it twice now (once for my F18A Slideshow program, and then for my Extended BASIC loader). It actually stored in both locations -- it used >83D0/>83D2 for its own internal workspace, and then when it was done, copied them to the low memory expansion locations. Since I recently adapted it to XB, that forced me to go line by line through it. It's pretty straightforward, and contains at least one bug (it has a test to skip over the SBZ 0 for the first card that, as far as I can see, is never taken.. but there's no negative to that which I can see either.)

 

If you look at the source to my XB loader, I have the code in there (a combination of Thierry's and my own comments, and adapted to run as a BL rather than a BLWP). The moves to low memory I left in for reference, they are just commented out with a "not safe for XB" comment.

[Asmusr]

When I minimize the Classic99 window with the 'Pause when window inactive' option enabled the last second or so of sound is played repeatedly. It also happens when the debugger is at a breakpoint. Is it only on my system?

[Tursi]

Apparently not, I can reproduce it here. I don't use the 'pause when window in active' so I never caught it before

[Asmusr]

Apparently not, I can reproduce it here. I don't use the 'pause when window in active' so I never caught it before

Hope you will fix it because it's driving me nuts.

[Tursi]

hehe.. crunch time at work, but I'll see what I can do. I usually mute my PC audio, myself.

[Willsy]

Hope you will fix it because it's driving me nuts.

 

Just think of it as a bonus feature, for no extra charge

[Asmusr]

I have been experimenting with the feature in the debugger to save memory as a 379 bank switched cart file. The thing that strikes me as odd is that the generated file is not exactly 32K or 64K long. For instance, the attached file for TI Scramble is 28,330 bytes. And when I tried to make a cart for Titanium the file was 24,756 bytes, ending with a cartridge header. I also noticed that the cart doesn't work on Classic99 if there are fewer than 3 banks, perhaps it's starting up on a non-existent bank? [edit: perhaps that was something I did wrong, it seems to be working now.] Thank you for any help you can provide.

tiscramble3.zip

[Asmusr]

Another question about this feature: If you add more banks with data to a file generated by Classic99 and go from 4 to 8 banks, I suspect the copying code becomes invalid because the bank switching addresses change (because of the reverse switching order). Is there a 'poke' to fix this? [edit: I think I figured it out: I can just reverse the order of the banks in my ROM file and the code will work.] [edit 2: I couldn't make it work so I have decided to write my own loader.]

[Tursi]

I'd forgotten that ability was even in there, so I can't remember how exactly it does work. Your own loader is guaranteed to be more efficient, and there's not that much involved.

 

That said, you do need a power of 2 number of banks (because of the inverse numbering), and Classic99 assumes the last bank is the power up bank (IIRC). The fact that you couldn't extend an existing one is just like you figured out - the bank numbers change. We had enthusiastic discussions about wiring up the switches that way when the intial design was proposed, but the cart went with this one because that's the way XB was wired.

 

Your results definitely suggest something has gone wrong in here... the code looks like it's doing everything it's supposed to, so I will have to spend some time with it and see what went wrong.

[Asmusr]

Tursi, I'm trying to build Classic99 from the source of the latest version, but I'm getting these error messages:

 

1>d:\ti-99-4a\classic99\src\console\tiemul.cpp(1567): error C2065: 'ID_DISK_CORRUPTDSKRAM' : undeclared identifier

1>d:\ti-99-4a\classic99\src\console\tiemul.cpp(1570): error C2065: 'ID_VIDEO_ENABLEF18A' : undeclared identifier

1>d:\ti-99-4a\classic99\src\addons\windowproc.cpp(1085): error C2065: 'ID_DISK_CORRUPTDSKRAM' : undeclared identifier

1>d:\ti-99-4a\classic99\src\addons\windowproc.cpp(1085): error C2051: case expression not constant

1>d:\ti-99-4a\classic99\src\addons\windowproc.cpp(1090): error C2065: 'ID_DISK_CORRUPTDSKRAM' : undeclared identifier

1>d:\ti-99-4a\classic99\src\addons\windowproc.cpp(1092): error C2065: 'ID_DISK_CORRUPTDSKRAM' : undeclared identifier

1>d:\ti-99-4a\classic99\src\addons\windowproc.cpp(1220): error C2065: 'ID_VIDEO_ENABLEF18A' : undeclared identifier

1>d:\ti-99-4a\classic99\src\addons\windowproc.cpp(1220): error C2051: case expression not constant

1>d:\ti-99-4a\classic99\src\addons\windowproc.cpp(1225): error C2065: 'ID_VIDEO_ENABLEF18A' : undeclared identifier

1>d:\ti-99-4a\classic99\src\addons\windowproc.cpp(1227): error C2065: 'ID_VIDEO_ENABLEF18A' : undeclared identifier

 

Is it possible that resource.h is out of date?

[Tursi]

That does sound likely.. with the last few updates being rushed, I probably missed updating the source files in the zip.

 

Just add any unique IDs to get yourself past that... I'll add that to the list to check.. I've got some bugfixes to post anyway. Sorry that it's not building cleanly!

[Asmusr]

Thanks, now it's compiling, but the linker wants ddraw.lib. This is no longer part of the DirectX SDK so I don't know where to find it.