List of Hardware Incompatibilities

[atrax27407]

With the proliferation of new hardware items recently available for the TI, I have noticed that there is also a number of compatibility issues that have appeared as well (ex. the FinalGROM99 and Vn 2.2 consoles and the 99/8, and the nanoPEB won't co-exist with some other hardware). I wonder if there is a list somewhere that documents problems between new hardware/software and existing hardware/ software? I know that the F18A, is not compatible with some of the 80-column programs written for the v9938/9958 as well. A list would make it much easier when it comes to time to buy one of the new pieces of hardware or a new software package.

[+InsaneMultitasker]

Sounds like a helpful endeavor. I keep reading about the various disk emulators and there are various wifi/modem replacements that come to mind.

 

I would suggest that any list of "incompatibilities" be documented within the context of each device's intended operation. For example, I don't think Matthew has ever touted the F18A as a 9938 replacement. Features like the 80 column mode go beyond the 9918 but that doesn't make the F18A incompatible with the 9918.

[Casey]

The only odd combination I've run into so far is that Video Chess, at least when run from the FG99, does not like the nanoPEB being attached to the console at all. It works fine if I just attach the speech synthesizer, or Matt's 32K device, but it crashes almost immediately after the title sequence if the nanoPEB is attached.

[+adamantyr]

Any full-bitmap editing program (Paint N'Print, TI-Artist, GraphX, and so forth) will fail on the CF7/NanoPEB, because it doesn't correctly handle the color table over-writing the beginning of the file buffers in VDP RAM. It doesn't appear to respect calls to FILES.

 

The programs will run fine, unless you try to save or load a full bit-map image.

 

I haven't tested Joypaint 99, which is in monochrome, but if it occupies the entire color table it will likely fail as well.

[+jedimatt42]

I'm trying to keep a TIPI compatibility issues list here:

 

https://github.com/jedimatt42/tipi/wiki/Known-incompatible-software

 

There will be lots, as I don't support sector IO, which was often used as a technique for reading catalogs.

 

-M@

[Omega-TI]

There will be lots, as I don't support sector IO, which was often used as a technique for reading catalogs.

 

 

Which should not be an issue once the P-Box version is released.

[+Lee Stewart]

Any full-bitmap editing program (Paint N'Print, TI-Artist, GraphX, and so forth) will fail on the CF7/NanoPEB, because it doesn't correctly handle the color table over-writing the beginning of the file buffers in VDP RAM. It doesn't appear to respect calls to FILES.

 

The programs will run fine, unless you try to save or load a full bit-map image.

 

I haven't tested Joypaint 99, which is in monochrome, but if it occupies the entire color table it will likely fail as well.

 

???

 

I am not really sure what you are saying here. The CF7/nanoPEB respects calls to FILES just fine. And, to my knowledge, it has absolutely nothing to do with any color table, bitmap mode or otherwise. It sounds like the programs you mention may be the culprits. They may be making assumptions they have no right to make. Calls to FILES update >8370 with the highest available VRAM, just as with all DSRs that follow the TI specs. It happens that the CF7/nanoPEB reserves 8 bytes at the top of VRAM for its own needs, which means that the address posted in >8370 by the CF7/nanoPEB FILES subprogram will be 8 bytes lower than with a TI diskette controller. But, it is incumbent upon any program flirting with the high VRAM limit to check >8370 for available space.

 

...lee

[+adamantyr]

 

???

 

I am not really sure what you are saying here. The CF7/nanoPEB respects calls to FILES just fine. And, to my knowledge, it has absolutely nothing to do with any color table, bitmap mode or otherwise. It sounds like the programs you mention may be the culprits. They may be making assumptions they have no right to make. Calls to FILES update >8370 with the highest available VRAM, just as with all DSRs that follow the TI specs. It happens that the CF7/nanoPEB reserves 8 bytes at the top of VRAM for its own needs, which means that the address posted in >8370 by the CF7/nanoPEB FILES subprogram will be 8 bytes lower than with a TI diskette controller. But, it is incumbent upon any program flirting with the high VRAM limit to check >8370 for available space.

 

...lee

 

I tested this with both the original CF card reader and the NanoPEB.

 

It was a source of constant frustration because I couldn't figure out WHY things didn't load. It also failed with my own assembly programs which I double and triple-checked to make sure they were calling the FILES subprogram and setting it to 1, and every single time it would fail on the device, behaving in the exact fashion that it does in emulation when you blew over the data.

[+OLD CS1]

Currently FG99 and the "QI" non-v2.2 console. I cannot speak for the v2.2 as the one I have is not operational.

[+InsaneMultitasker]

 

I tested this with both the original CF card reader and the NanoPEB.

 

It was a source of constant frustration because I couldn't figure out WHY things didn't load. It also failed with my own assembly programs which I double and triple-checked to make sure they were calling the FILES subprogram and setting it to 1, and every single time it would fail on the device, behaving in the exact fashion that it does in emulation when you blew over the data.

 

Got sample code? If this fails in emulation you should be able to check the Vid Regs and confirm where the tables reside and what is stomping on those 8 bytes that are shifted 'downward' as Lee pointed out in his post.

[marc.hull]

 

I tested this with both the original CF card reader and the NanoPEB.

 

It was a source of constant frustration because I couldn't figure out WHY things didn't load. It also failed with my own assembly programs which I double and triple-checked to make sure they were calling the FILES subprogram and setting it to 1, and every single time it would fail on the device, behaving in the exact fashion that it does in emulation when you blew over the data.

I would think (and Tim could actually explain) that the CF7 and variants actually create their own interface standard via the extra 7 ( is is seven ?) VDP Bytes it uses. It is not a FDC in the traditional sense and causes problems with software that predates this new (ish) design. Not a call files issue but a CF7 ONE?

 

Of course I could be wrong but since we are throwing and seeing what sticks I thought I would add my crap too.

[RXB]

I'm trying to keep a TIPI compatibility issues list here:

 

https://github.com/jedimatt42/tipi/wiki/Known-incompatible-software

 

There will be lots, as I don't support sector IO, which was often used as a technique for reading catalogs.

 

-M@

RXB has a compatible cataloger and REA too.

 

I am dropping CALL SECTOR out of RXB as no one is using RXB for SECTOR access except for me as

far as I know in the TI Community.

[apersson850]

I noticed that later versions of the ROS for the Horizon RAM disk makes assumptions about how the console's DSRLNK works. This make the RAM disk incompatible with the UCSD p-system, since the p-system uses a more efficient DSRLNK than the standard one in the console.

But this isn't really the hardware's fault, but the DSR. I made a simple DSR for the Horizon myself, and then it's compatible with the p-system.