The Missing Link and CF7 compatibility

[senior_falcon]

The Missing Link does some tricks with the disk buffer locations that make it incompatible with the CF7. At one time I tried to make them compatible with each other, with no luck. I don't even know whether this is possible, but would like to try one more time. Perhaps twice is a charm. If someone was willing to work with me on this, I would send an XB program that maps the VDP and disk buffers like TML to see whether disk access is possible. I think this is what I tried before, but it's a good starting point. If (more likely when) this doesn't work, I would send a second program that copies the memory from the VDP disk buffers into a file. Perhaps some insight could be gained from that. Of course, ideally  I would borrow a CF7 from someone for a week or two, which would give me instant feedback on what works or doesn't work.

Any takers?

[+OLD CS1]

I can offer up my CF7 for you to test on.

[Opry99er]

Yep, I've got an original CF7.  I'd be happy to send it your way for as long as you need.  

[+arcadeshopper]

Matt worked this out for the TIPI. He may have some insight

Sent from my LM-G820 using Tapatalk

[senior_falcon]

First, try this out. Attached is an XB program that moves the disk buffers. With the CF7, run this program and then see if you can load or save an XB program. I think we tried this once and it didn't work, but let's start with the simplest approach.

TMLCF7.zip

[senior_falcon]

Results?????

[Opry99er]

I'll have to try it out tonight when I get home.  

[+hloberg]

Harry, 2 things

Does the NanoPEB effect TML the same way as the CF7 ?

When I do a CALL LINK("GRAFIX") in TML I get SUBPROGRAM NOT FOUND, also for CALL LINK("BITMAP") the same thing? am I doing something wrong?

 

 

 

[senior_falcon]

1 hour ago, hloberg said:

Harry, 2 things

Does the NanoPEB effect TML the same way as the CF7 ?

When I do a CALL LINK("GRAFIX") in TML I get SUBPROGRAM NOT FOUND, also for CALL LINK("BITMAP") the same thing? am I doing something wrong?

 

Using the NanoPEB, after loading TML are you able to load and save XB programs written for TML? If you can run TMLDEMO from disk one then disk access is normal.

CALL LINK("GRAFIX") and CALL LINK("BITMAP") are additional subprograms that are not normally part of TML. If you want to use them you have to add them to your XB program using HMLOADER. Page 28 of the manual describes how to do this.  

[+jedimatt42]

On 11/30/2019 at 2:25 PM, arcadeshopper said:

Matt worked this out for the TIPI. He may have some insight

Sent from my LM-G820 using Tapatalk
 

 

I didn't work anything out about CF7's when working with TIPI, it was just that originally TML exposed that TIPI was not initializing the VDP stack pointers and that some software assumes a TI floppy controller or facsimile would have done so. I changed TIPI's powerup to be more of a facsimile if running at crubase >1100.  However, along the way, I became aware of this nugget of information ( cause when you can't get something to work, read Tursi's prior art  ) 

 

Tursi's classic99 source code has a comment regarding the CF7 and what it does to VDP:

 

https://github.com/tursilion/classic99/blob/eae60d9952760eb06e4fc29da84a9b2b7db6b4de/disk/diskclass.cpp#L240

 

Quote

CF7 will change top of VRAM value by 6 bytes

 

I believe this is to say CF7 powerup routine allocates 6 extra bytes of VRAM. 

 

(Note: Lee Stewart corrects us a few posts below with the knowledge that it allocates 8 extra bytes, not just 6)

-M@

[Opry99er]

Having issues out of my CF7.  Let me try something else.

[Opry99er]

Seems to be working as expected on both XB2.7 and vanilla XB.

[senior_falcon]

OK, that looks promising. If you don't mind, here are a couple more test you could do just to be sure:

RUN "DSKn.TMLCF7"    (This will adjust pointers to disk space in the VDP and at >8370.)

1 <Enter> 

SIZE

You should get a stack space of around 5206.

If all is working you should be able to save and load XB programs. (One possible pitfall is when the program is >5206 bytes long.  In this case it will have to be converted to IV254 format to load properly. A large program will automatically save in IV254 when necessary.)

Try:

10 REM DISK TEST

and SAVE this program.

Try loading the program.

If both these work then write a short program that opens a DV80 file and saves something to it. Then try reading what you just saved. 

If this works then I think we can declare victory.

[+Lee Stewart]

11 hours ago, jedimatt42 said:

I believe this is to say CF7 powerup routine allocates 6 extra bytes of VRAM. 

 

The CF7/nanoPEB uses the top 8 bytes of VRAM. >3FF8 always contains >AA03. The remaining 6 bytes (at 2 bytes each) contain the volume numbers mounted in DSK1, DSK2 and DSK3. You can verify this by checking RAM at >8370 for the highest available VRAM byte. For a maximum available open files of 3 and with only the TI disk controller installed, >8370 will contain >37D7. With the CF7/nanoPEB installed, that address will be >37CF.

 

...lee

[Tursi]

9 hours ago, Lee Stewart said:

 

The CF7/nanoPEB uses the top 8 bytes of VRAM. >3FF8 always contains >AA03. The remaining 6 bytes (at 2 bytes each) contain the volume numbers mounted in DSK1, DSK2 and DSK3. You can verify this by checking RAM at >8370 for the highest available VRAM byte. For a maximum available open files of 3 and with only the TI disk controller installed, >8370 will contain >37D7. With the CF7/nanoPEB installed, that address will be >37CF.

 

...lee

Ah, this matches my memory. I clearly thinko'd when I wrote that comment, but in fairness, that comment was written for my later research.

 

Classic99 actually supports loading and running the CF7 now, I used that to develop the programming software for Dragon's Lair (which had to read the image from CF ). You have to provide the BIOS yourself and add a section to the Classic99.ini:

 

[CF7]
BIOS=D:\work\ti\cf7+\CF7+_DSR.bin
Disk=D:\work\ti\Disks\work_cf7.bin
Size=268435456

 

BIOS is the name of the BIOS file, which must be a raw image with no headers. The presence or absence of this entry in the INI enables the emulation.

Disk is the name of the Compact Flash image file. It doesn't have to be formatted but it might need to be the right size - I never tested starting raw.

Size is the size of the Compact Flash image, and must be a power of two and a multiple of 512 bytes (which is implied by power of 2).

 

It's a rudimentary Compact Flash emulation, but it supports all the opcodes the CF BIOS uses as a few others besides. You can definitely use it for debugging CF-related issues. This will, of course, replace the configured DSK1 through DSK3. The only difference from the real CF device is that it mounts at CRU >1000 instead of >1100 (this allowed the Classic99 DSR to remain unchanged). I didn't find any issues with the change but be aware.

 

Disclaimer: beta, not intended for general use, etc etc.

 

[senior_falcon]

3 hours ago, Tursi said:

Classic99 actually supports loading and running the CF7 now, I used that to develop the programming software for Dragon's Lair (which had to read the image from CF ). You have to provide the BIOS yourself and add a section to the Classic99.ini:

 

What if you don't have the BIOS? 

[Tursi]

6 hours ago, senior_falcon said:

What if you don't have the BIOS? 

I don't have any permission from the author to distribute it in the emulator, so I guess you ask if anyone has dumped it.

 

[RickyDean]

5 hours ago, Tursi said:

I don't have any permission from the author to distribute it in the emulator, so I guess you ask if anyone has dumped it.

 

Has anyone dumped it? There question asked.

 

[senior_falcon]

I will explain what happens when TML starts up and maybe someone can work out how to make this function the CF7.

 

Normally XB starts with CALL FILES(3) having been performed at startup. After this, >8370 in the scratchpad contains >37D7 as the highest available address in VDP.

v37D8 to v3FFF are used for disk access. v37D8 has these 5 bytes: >AA,>3F,>FF,>11,>03 - validation code for disk controller, top of VDP memory, CRU base, max number of opened files. Following this are three 518 byte buffers which allow you to open up to 3 disk files and then some more disk stuff.

 

Take the value at >8370 and subtract >19E4, giving >1DF3. Put this at >8370. Then copy the 5 bytes at v37D8 to v1DF4. The >03 will be at v1DF8. Change this to 1. Now the TI disk controller knows you will have a maximum of 1 file open at a time and it uses v1DF9 to v1FFF as the buffer. v2000 to v3DEE are now available for bit mapped graphics. 

 

Now for the CF7. As before subtract >19E4 from the value at >8370. Copy bytes from the old address at >8370 to the new address at >8370 until you come to v1DF8. (This should be 13 bytes total). And as before, at v1DF8 change the 3 to a 1. Simple so far. 

 

Now for the part I don't know. What do the 8 additional bytes do? They must point to buffers something similar. If they are just moved as described above, will file access still work? Or do they have to be modified to point to the new disk buffer location starting at v1DF9? Or maybe it's just not possible to make it work. Also, if you do CALL FILES(1) are there still 8 additional bytes, or are there less. 

 

It seems like this would not be too difficult to figure out.

[Tursi]

As far as I have seen, the access to the 6 bytes at the top of VRAM is hard coded into the DSR flexible, and I don't think it checks the two header bytes at all... but that's easy to double check. They don't point to buffers at all - each 2-byte entry is the volume index of the disk image mounted there - DSK1, DSK2, DSK3. There are always 6 bytes plus a two byte header because they are data for the drives themselves, not file buffers.

 

The code gets tricky fast, as it uses a lot of the disk DSR's indirect function calls, but I did some testing and I proved that it does the right thing when the memory pointer is set lower than normal. This means everything, including the additional 8 bytes, does relocate.

 

The 8 bytes are always at the top of VRAM (as defined by >8370 when the powerup function is called). Assuming >3FFF:

// 3FF8: AA03 - header, 3 devices. TODO: Unclear if the 3 can be changed!
// 3FFA: xxxx - 16-bit big endian value for volume number mounted on DSK1
// 3FFC: xxxx - 16-bit big endian value for volume number mounted on DSK2
// 3FFE: xxxx - 16-bit big endian value for volume number mounted on DSK3

 

I don't think the DSR ever checks the AA03 header, nor do I think it validates the 03 part. I can change and corrupt those bytes without breaking the DSR. But it's probably good practice to assume they are meaningful.

 

If I changed >8370 to >1FFF before entry, then everything is nicely and neatly located with the first free byte of VRAM at >2000 instead. So it does appear that moving these tables should work fine, just as long as you keep space for that extra 8 byte table and put it right at the top of the disk's memory.

 

But, if you don't mind VRAM being messed with on init, I wonder - why not let the disk DSR deal with the VDP? Can you just set >8370 to the address that you want everything to be located under, then call the disk powerup routine followed by the equivalent of CALL FILES(1)? Then you don't have to trouble yourself with the specifics of how the disk device arranges the VRAM? (The one gotcha is to watch that the CF7 will write "CF7 Installed" to the screen at >1A9, and this seems hard coded, but if you can survive that all else should just work?

 

(edit: on exit from the CALL FILES(1) call you can check >8370 again to see where it finally landed, and so know how much VRAM the disk system allocated, if you need to. )

 

Edited December 5, 2019 by Tursi

[senior_falcon]

7 hours ago, Tursi said:

As far as I have seen, the access to the 6 bytes at the top of VRAM is hard coded into the DSR flexible, and I don't think it checks the two header bytes at all... but that's easy to double check. They don't point to buffers at all - each 2-byte entry is the volume index of the disk image mounted there - DSK1, DSK2, DSK3. There are always 6 bytes plus a two byte header because they are data for the drives themselves, not file buffers.

 

The code gets tricky fast, as it uses a lot of the disk DSR's indirect function calls, but I did some testing and I proved that it does the right thing when the memory pointer is set lower than normal. This means everything, including the additional 8 bytes, does relocate.

 

The 8 bytes are always at the top of VRAM (as defined by >8370 when the powerup function is called). Assuming >3FFF:

// 3FF8: AA03 - header, 3 devices. TODO: Unclear if the 3 can be changed!
// 3FFA: xxxx - 16-bit big endian value for volume number mounted on DSK1
// 3FFC: xxxx - 16-bit big endian value for volume number mounted on DSK2
// 3FFE: xxxx - 16-bit big endian value for volume number mounted on DSK3

 

I don't think the DSR ever checks the AA03 header, nor do I think it validates the 03 part. I can change and corrupt those bytes without breaking the DSR. But it's probably good practice to assume they are meaningful.

 

If I changed >8370 to >1FFF before entry, then everything is nicely and neatly located with the first free byte of VRAM at >2000 instead. So it does appear that moving these tables should work fine, just as long as you keep space for that extra 8 byte table and put it right at the top of the disk's memory.

 

But, if you don't mind VRAM being messed with on init, I wonder - why not let the disk DSR deal with the VDP? Can you just set >8370 to the address that you want everything to be located under, then call the disk powerup routine followed by the equivalent of CALL FILES(1)? Then you don't have to trouble yourself with the specifics of how the disk device arranges the VRAM? (The one gotcha is to watch that the CF7 will write "CF7 Installed" to the screen at >1A9, and this seems hard coded, but if you can survive that all else should just work?

 

(edit: on exit from the CALL FILES(1) call you can check >8370 again to see where it finally landed, and so know how much VRAM the disk system allocated, if you need to. )

 

If I understand this correctly, you can do the equivalent of CALL FILES(1) and put all the disk information so that nothing above >1FFF is used at all. The downside to this is that the stack space will be reduced by 529 bytes. Normally there are 1460 bytes of stack space available; reducing that by 529 is a deal breaker.

[RXB]

8 hours ago, Tursi said:

As far as I have seen, the access to the 6 bytes at the top of VRAM is hard coded into the DSR flexible, and I don't think it checks the two header bytes at all... but that's easy to double check. They don't point to buffers at all - each 2-byte entry is the volume index of the disk image mounted there - DSK1, DSK2, DSK3. There are always 6 bytes plus a two byte header because they are data for the drives themselves, not file buffers.

 

The code gets tricky fast, as it uses a lot of the disk DSR's indirect function calls, but I did some testing and I proved that it does the right thing when the memory pointer is set lower than normal. This means everything, including the additional 8 bytes, does relocate.

 

The 8 bytes are always at the top of VRAM (as defined by >8370 when the powerup function is called). Assuming >3FFF:

// 3FF8: AA03 - header, 3 devices. TODO: Unclear if the 3 can be changed!
// 3FFA: xxxx - 16-bit big endian value for volume number mounted on DSK1
// 3FFC: xxxx - 16-bit big endian value for volume number mounted on DSK2
// 3FFE: xxxx - 16-bit big endian value for volume number mounted on DSK3

 

I don't think the DSR ever checks the AA03 header, nor do I think it validates the 03 part. I can change and corrupt those bytes without breaking the DSR. But it's probably good practice to assume they are meaningful.

 

If I changed >8370 to >1FFF before entry, then everything is nicely and neatly located with the first free byte of VRAM at >2000 instead. So it does appear that moving these tables should work fine, just as long as you keep space for that extra 8 byte table and put it right at the top of the disk's memory.

 

But, if you don't mind VRAM being messed with on init, I wonder - why not let the disk DSR deal with the VDP? Can you just set >8370 to the address that you want everything to be located under, then call the disk powerup routine followed by the equivalent of CALL FILES(1)? Then you don't have to trouble yourself with the specifics of how the disk device arranges the VRAM? (The one gotcha is to watch that the CF7 will write "CF7 Installed" to the screen at >1A9, and this seems hard coded, but if you can survive that all else should just work?

 

(edit: on exit from the CALL FILES(1) call you can check >8370 again to see where it finally landed, and so know how much VRAM the disk system allocated, if you need to. )

 

Hmm the header from RXB 2018:

[0446] 6000 AA,12           DATA >AA12      * VALID GROM / VERSION 18
[0447] 6002 01,00           DATA >0100      * (FUTURE EXPANSION)
[0448] 6004 00,00           DATA >0000      * POWERUP
[0449] 6006 63,3B           DATA XBCART     * PROGRAMS

99/4 GPL-ASSEMBLER (Pass 3) correct                                   PAGE 0008 
EDIT-359
[0450] 6008 00,00           DATA >0000      * DSR 
[0451] 600A A0,26           DATA LINK1      * CALL
[0452] 600C 00,00           DATA >0000      * INTERUPT
[0453] 600E 00,00           DATA >0000      * BASIC CALL

>AA is the header and the next byte is version number per GPL Manual. i.e. >12 = 18 decimal

Next byte is >01 but that was for a future expansion card that TI never developed, I was hoping next byte would be a memory expansion. i.e. 256 pages of 32K

Edited December 5, 2019 by RXB
spelling error

[senior_falcon]

How is this relevant to disk access?

[+Lee Stewart]

2 minutes ago, senior_falcon said:

How is this relevant to disk access?

 

It is not. I think Rich misunderstands us.

 

...lee

[+Lee Stewart]

16 hours ago, senior_falcon said:

Take the value at >8370 and subtract >19E4, giving >1DF3. Put this at >8370. Then copy the 5 bytes at v37D8 to v1DF4. The >03 will be at v1DF8. Change this to 1. Now the TI disk controller knows you will have a maximum of 1 file open at a time and it uses v1DF9 to v1FFF as the buffer. v2000 to v3DEE are now available for bit mapped graphics.

 

The TI disk controller specs require(?) an additional buffer for one Volume Information Block (VIB) + other stuff for a total of 534 bytes. That plus one buffer (518 bytes) for one open file would seem to require starting one byte above >3BE3 - (>3FFF - >1FFF) = >3BE3 - >2000 = >1BE3 rather than >1DF3. How do you get away with room for only one buffer?

 

...lee