Jump to content

Photo

List of Hardware Incompatibilities


12 replies to this topic

#1 atrax27407 OFFLINE  

atrax27407

    Stargunner

  • 1,052 posts

Posted Mon Apr 16, 2018 12:32 PM

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. 



#2 InsaneMultitasker OFFLINE  

InsaneMultitasker

    River Patroller

  • 2,199 posts

Posted Mon Apr 16, 2018 1:37 PM

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.



#3 Casey OFFLINE  

Casey

    Moonsweeper

  • 290 posts

Posted Mon Apr 16, 2018 4:06 PM

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.



#4 adamantyr ONLINE  

adamantyr

    Stargunner

  • 1,349 posts

Posted Mon Apr 16, 2018 4:18 PM

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.



#5 jedimatt42 OFFLINE  

jedimatt42

    Stargunner

  • 1,798 posts
  • Location:Beaverton, OR

Posted Mon Apr 16, 2018 5:31 PM

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

https://github.com/j...atible-software

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

-M@

#6 --- Ω --- OFFLINE  

--- Ω ---

    --- Ω ---

  • 12,676 posts
  • Location:워싱턴 주

Posted Mon Apr 16, 2018 6:31 PM

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.



#7 Lee Stewart ONLINE  

Lee Stewart

    River Patroller

  • 3,726 posts
  • Location:Silver Run, Maryland

Posted Mon Apr 16, 2018 6:50 PM

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



#8 adamantyr ONLINE  

adamantyr

    Stargunner

  • 1,349 posts

Posted Mon Apr 16, 2018 6:56 PM

 

???

 

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.



#9 OLD CS1 OFFLINE  

OLD CS1

    Technomancer

  • 5,482 posts
  • Technology Samurai
  • Location:Tallahassee, FL

Posted Mon Apr 16, 2018 7:01 PM

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



#10 InsaneMultitasker OFFLINE  

InsaneMultitasker

    River Patroller

  • 2,199 posts

Posted Mon Apr 16, 2018 7:20 PM

 

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.  



#11 marc.hull OFFLINE  

marc.hull

    Stargunner

  • 1,297 posts
  • Location:Oklahoma CIty.

Posted Mon Apr 16, 2018 7:26 PM

 
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.

#12 RXB OFFLINE  

RXB

    River Patroller

  • 3,303 posts
  • Location:Vancouver, Washington, USA

Posted Mon Apr 16, 2018 9:59 PM

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

https://github.com/j...atible-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.



#13 apersson850 OFFLINE  

apersson850

    Dragonstomper

  • 500 posts

Posted Tue Apr 17, 2018 2:58 AM

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.






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users