Jump to content
IGNORED

TIPI Usage and Support


jedimatt42

Recommended Posts

26 minutes ago, jedimatt42 said:

On real hardware, it just works... well, at least with "TIPI.PSAVE2" ... 

 


2021-02-19 22:47:20,752 TipiService : INFO     TIPI Ready
2021-02-19 22:49:12,118 TipiDisk    : INFO     Opcode 6 Save - TIPI.PSAVE2
2021-02-19 22:49:12,119 Pab         : INFO     opcode: Save, fileType: Sequential, mode: Update, dataType: Display, recordType: Fixed, recordLength: 0, recordNumber: 4096
2021-02-19 22:49:12,121 tinames.tinames: INFO     TIPI.PSAVE2 -> /home/tipi/tipi_disk/PSAVE2
2021-02-19 22:49:12,775 TipiService : INFO     Request completed.
2021-02-19 22:49:45,101 TipiDisk    : INFO     Opcode 5 LOAD - TIPI.PSAVE2
2021-02-19 22:49:45,101 Pab         : INFO     opcode: Load, fileType: Sequential, mode: Update, dataType: Display, recordType: Fixed, recordLength: 0, recordNumber: 4096
2021-02-19 22:49:45,102 tinames.tinames: INFO     TIPI.PSAVE2 -> /home/tipi/tipi_disk/PSAVE2
2021-02-19 22:49:45,104 TipiDisk    : INFO     LOAD image size 4096
2021-02-19 22:49:45,809 TipiService : INFO     Request completed.

I don't normally bother to map drives.. cause for what I do it is usually LVL3 IO.

 

So I ran:

 


10 CALL LOAD(8192,1)
20 CALL PSAVE(2,"TIPI.PSAVE2")
RUN

and then


10 CALL LOAD(8192,0)
20 CALL PLOAD(2,"TIPI.PSAVE2")
RUN

and then 


CALL PEEK(8192,A)
PRINT A

which printed 1

 

Mapping DSK1 to TIPI.TEST, such that TIPICFG shows: 


Drive Mappings
  1) DSK1=TEST
...

And re-running the basic code with DSK1. instead of TIPI., it also still works.

 


2021-02-19 22:55:27,570 TipiService : INFO     TIPI Ready
2021-02-19 22:56:21,158 TipiDisk    : INFO     Opcode 6 Save - DSK1.PSAVE2
2021-02-19 22:56:21,159 Pab         : INFO     opcode: Save, fileType: Sequential, mode: Update, dataType: Display, recordType: Fixed, recordLength: 0, recordNumber: 4096
2021-02-19 22:56:21,161 tinames.tinames: INFO     DSK1.PSAVE2 -> /home/tipi/tipi_disk/TEST/PSAVE2
2021-02-19 22:56:21,790 TipiService : INFO     Request completed.
2021-02-19 22:56:46,687 TipiDisk    : INFO     Opcode 5 LOAD - DSK1.PSAVE2
2021-02-19 22:56:46,687 Pab         : INFO     opcode: Load, fileType: Sequential, mode: Update, dataType: Display, recordType: Fixed, recordLength: 0, recordNumber: 4096
2021-02-19 22:56:46,688 tinames.tinames: INFO     DSK1.PSAVE2 -> /home/tipi/tipi_disk/TEST/PSAVE2
2021-02-19 22:56:46,690 TipiDisk    : INFO     LOAD image size 4096
2021-02-19 22:56:47,378 TipiService : INFO     Request completed.

 

So, I don't know... What problem are we trying to solve? 
I did not try using variables to compose the file name. Properly composing the filename into the PAB is the client's responsibility... 

...

ok, tried that, still works.


10 F=3
20 CALL PLOAD(2,"DSK1.PSAVE"&STR$(F))

 

So... to see the log data from the PI, I ssh into the PI from a modern PC. On a MAC it would be something like:


ssh tipi@tipi.local

 

password `tipi` unless you changed it. Then on the PI, I:


tail -F /var/log/tipi/tipi.log

 

If you reset the TI, you should see the TIPI READY message associated with a current timestamp. 

 

 

How come it works with SCSI, RAMDISK, Corcomp, Myarc hard and floppy but not TIPI?

  • Confused 1
  • Sad 1
Link to comment
Share on other sites

On real hardware, it just works... well, at least with "TIPI.PSAVE2" ... (Later I try a mapped drive with same result)
 
2021-02-19 22:47:20,752 TipiService : INFO     TIPI Ready2021-02-19 22:49:12,118 TipiDisk    : INFO     Opcode 6 Save - TIPI.PSAVE22021-02-19 22:49:12,119 Pab         : INFO     opcode: Save, fileType: Sequential, mode: Update, dataType: Display, recordType: Fixed, recordLength: 0, recordNumber: 40962021-02-19 22:49:12,121 tinames.tinames: INFO     TIPI.PSAVE2 -> /home/tipi/tipi_disk/PSAVE22021-02-19 22:49:12,775 TipiService : INFO     Request completed.2021-02-19 22:49:45,101 TipiDisk    : INFO     Opcode 5 LOAD - TIPI.PSAVE22021-02-19 22:49:45,101 Pab         : INFO     opcode: Load, fileType: Sequential, mode: Update, dataType: Display, recordType: Fixed, recordLength: 0, recordNumber: 40962021-02-19 22:49:45,102 tinames.tinames: INFO     TIPI.PSAVE2 -> /home/tipi/tipi_disk/PSAVE22021-02-19 22:49:45,104 TipiDisk    : INFO     LOAD image size 40962021-02-19 22:49:45,809 TipiService : INFO     Request completed.

I don't normally bother to map drives.. cause for what I do it is usually LVL3 IO.
 
So I ran:
 

10 CALL LOAD(8192,1)20 CALL PSAVE(2,"TIPI.PSAVE2")RUN

and then

10 CALL LOAD(8192,0)20 CALL PLOAD(2,"TIPI.PSAVE2")RUN

and then 

CALL PEEK(8192,A)PRINT A

which printed 1
 
Mapping DSK1 to TIPI.TEST, such that TIPICFG shows: 

Drive Mappings 1) DSK1=TEST...

And re-running the basic code with DSK1. instead of TIPI., it also still works.
 

2021-02-19 22:55:27,570 TipiService : INFO     TIPI Ready2021-02-19 22:56:21,158 TipiDisk    : INFO     Opcode 6 Save - DSK1.PSAVE22021-02-19 22:56:21,159 Pab         : INFO     opcode: Save, fileType: Sequential, mode: Update, dataType: Display, recordType: Fixed, recordLength: 0, recordNumber: 40962021-02-19 22:56:21,161 tinames.tinames: INFO     DSK1.PSAVE2 -> /home/tipi/tipi_disk/TEST/PSAVE22021-02-19 22:56:21,790 TipiService : INFO     Request completed.2021-02-19 22:56:46,687 TipiDisk    : INFO     Opcode 5 LOAD - DSK1.PSAVE22021-02-19 22:56:46,687 Pab         : INFO     opcode: Load, fileType: Sequential, mode: Update, dataType: Display, recordType: Fixed, recordLength: 0, recordNumber: 40962021-02-19 22:56:46,688 tinames.tinames: INFO     DSK1.PSAVE2 -> /home/tipi/tipi_disk/TEST/PSAVE22021-02-19 22:56:46,690 TipiDisk    : INFO     LOAD image size 40962021-02-19 22:56:47,378 TipiService : INFO     Request completed.

 
So, I don't know... What problem are we trying to solve? 
I did not try using variables to compose the file name. Properly composing the filename into the PAB is the client's responsibility... 
...
ok, tried that, still works.

10 F=320 CALL PLOAD(2,"DSK1.PSAVE"&STR$(F))

 
So... to see the log data from the PI, I ssh into the PI from a modern PC. On a MAC it would be something like:

ssh tipi@tipi.local

 
password `tipi` unless you changed it. Then on the PI, I:

tail -F /var/log/tipi/tipi.log

 
If you reset the TI, you should see the TIPI READY message associated with a current timestamp. 
 
Copying one of the PSAVE generated files with DM2K also works fine.  I copied from 1000.DSK0.TEST. to 1000.DSK0. quite happily.
 
 

Interested if you have a disk controller in your ti

Sent from my LM-V600 using Tapatalk

Link to comment
Share on other sites

@RXB  I'm saying, it works fine on TIPI. There appears to be nothing wrong with your PSAVE or PLOAD. On real hardware, including TIPI, it just works. As an example, I transcribed above exactly what I performed. It worked with a filepath of "TIPI.PSAVE2" and it worked with a mapped DSK1 to TIPI.TEST, giving a path of "DSK1.PSAVE2"

 

Yes, @arcadeshopper, I do have a Corcomp Floppy Controller in my TI... but my TIPI is at >1000, so this code never interacts with the Corcomp. I used a debugger to verify that.

 

This code is doing a LVL3 LOAD, the first operation implemented in TIPI's service routines (SAVE was second so I could play ToD), and the most used operation in TI file IO... Seriously nothing special about these data files.

 

Go back, and re-read what I posted. Try my simple examples yourself.

 

The only thing I can think of is if you have AUTOMAP on for TIPI, and you load a PROGRAM from some directory on the TIPI, then "DSK1." temporarily becomes mapped to the location of that PROGRAM image. If that location is not the same as where you expect you've saved your data files, then your LOAD won't find the files. When I tested, I was in the same 'session' of RXB for my load and save operations. This feature is usually as it saves caring about mapping most of the time. For instance: you have a game like DEADLINE that is an EA5 set with some data files. They can be sitting in TIPI.GAMES.INFOCOM.DEADLINE. Then you go into EA, pick option 5, and enter TIPI.GAMES.INFOCOM.DEADLINE.DEADLINE to load the PROGRAM binary... at this point, with automap on, DSK1. becomes GAMES.INFOCOM.DEADLINE, and the binary can find the datafile it expects to be on DSK1. Similiarly with XB programs like say Old Dark Caves. Go into TI XB, RUN "TIPI.GAMES.OLDCAVES.LOAD" and TIPI's automap feature, if enabled, will map DSK1 to GAMES.OLDCAVES and all the overlay binaries and data files are found naturally by the game.

 

So, consequentially, if you have AUTOMAP on, and you have DSK1. mapped to DATA in TIPICFG, but you go into RXB, and OLD "TIPI.TESTS.LOADTEST" then DSK1. will be mapped to TESTS instead of DATA after the OLD. 

 

I forget about this myself because it makes so many things natural and easy, but it can confuse things while developing. Thus, you can turn the feature off in TIPICFG. Or you can customize the before per directory.

 

Here is the documentation on this feature: https://github.com/jedimatt42/tipi/wiki/Auto-mapping

 

As you can see in my examples using PLOAD, it also just works with "TIPI." paths, so you don't need to always pretend TIPI is a floppy. LVL3 IO almost never needs drive mapping unless the client program is making assumptions about floppy usage. In this regard, TIPI shows it is harddrive like device with device mapping for legacy software compatibility. If it isn't legacy software, I wouldn't expect a developer to use DSK mapping. 

Edited by jedimatt42
Link to comment
Share on other sites

23 minutes ago, arcadeshopper said:

Yes I have auto on

I also have a Corcomp

I had cru at 1000

I got errors in run mode I posted earlier

 

I'm at the coast today so not able to test until I get home Sunday night

 

 

 

Sent from my LM-V600 using Tapatalk

 

 

 

 

 

My only guess then is that the CALL SAMS from @RXB example is corrupting the runtime state of RXB... For instance, is it failing to disable the SAMS '612 registers from being in address space >4000->5FFF? That would create conflicts with the ROM in a controller card. The nature of those conflicts would be unique to each card. That would be a possible explanation why loading an RXB program would work, but not the data files. Why PLOAD never hits the TIPI. I did not try that code. I stripped things down to the IO aspects. Surely @RXBcan verify this himself in the debugger on classic99.. or just comment out the CALL SAMS and see if that eliminates the IO error. 

 

The equivalent of this assembly must be performed at the end of any routine that manipulates the SAMS registers if DSRs are going to be subsequently used:

 

       LI R12,>1E00
       SBZ 0

crubit 0 controls if the SAMS card is in the DSR space for configuration. Entirely different from crubit 1 which controls 'transparent mode'.

Edited by jedimatt42
  • Like 1
Link to comment
Share on other sites

1 hour ago, jedimatt42 said:

 

My only guess then is that the CALL SAMS from @RXB example is corrupting the runtime state of RXB... For instance, is it failing to disable the SAMS '612 registers from being in address space >4000->5FFF? That would create conflicts with the ROM in a controller card. The nature of those conflicts would be unique to each card. That would be a possible explanation why loading an RXB program would work, but not the data files. Why PLOAD never hits the TIPI. I did not try that code. I stripped things down to the IO aspects. Surely @RXBcan verify this himself in the debugger on classic99.. or just comment out the CALL SAMS and see if that eliminates the IO error. 

 

The equivalent of this assembly must be performed at the end of any routine that manipulates the SAMS registers if DSRs are going to be subsequently used:

 


       LI R12,>1E00
       SBZ 0

crubit 0 controls if the SAMS card is in the DSR space for configuration. Entirely different from crubit 1 which controls 'transparent mode'.

If TIPI can not run my game INTHEDARK then that would be proof of the issue.

Here is the CALL SAMS RXB routine in GPL:

*******************************************************
* CALL SAMS(memory-boundery,memory-page[,...])        *
*******************************************************
* SAMS replaced AMSPASS, AMSMAP, AMSOFF, AMSON      *
* CALL SAMS("PASS",...)                             *
* CALL SAMS("MAP",...)                              *
* CALL SAMS("OFF",...)                              *
* CALL SAMS("ON",...)                               *
***************************************************** 
* SAMS replaced AMSBANK full RAM memory management  *
***************************************************** 
* CALL SAMS(2,page,3,page,A,page,B,page,C,page,     * 
* D,page,E,page,F,page,...)                         *
*                                                   *
* Numbers 2 is >2000, 3 is >3000                    *
* Letters A is >A000, B is >B000, C is >C000        *
* Letter  D is >D000, E is >D000, F is >F000        *
* page now is SAMS 4K pages from 0 to 255           *
*****************************************************
* BSAVE and BLOAD replaced with full memory address *
* 4K RAM boundries same as SAMS addressing RAM      *
*****************************************************
SAMS   DATA BEEP
       STRI 'SAMS'        
       DATA $+2
       CALL COMB            * ( ?
**************************************************
* Get stirng or token or numeric                 *
* String is for PASS,MAP,OFF, ON                 *
* 2 and 3 are numeric as no token exist for them *
* thus need a numeric interpetation for 2 and 3  *
* A, B, C, D, E, F are tokenized already for use *
**************************************************
SAMS2  XML  PGMCHR          * Skip ( OR COMMA 
       CEQ  >C7,@CHAT       * STRING?
       BR   SAMSPS          *  Must be a TOKEN?
SAMSTR CALL STRPAR          * GET STRING?      
       CEQ  >65,@FAC2       * STRING?
       BR   ERRBV           * ERROR BAD VALUE
       DCZ  @FAC6           * 0 Length?
       BS   ERRBA           * ERROR BAD ARGUMENT 
       DCEQ >5041,V*FAC4    * PA? PASS MODE
       BR   AMSMAP          * SAMS MAP
* CALL AMSPASS ************** 
       CALL PASAMS          * SAMS PASS
       BR   SAMS3           * CHECK FOR COMMA
AMSMAP DCEQ >4D41,V*FAC4    * MA? MAP MODE
       BR   AMSOFF          *SAMS OFF
* CALL AMSMAP ***************
       CALL MAPAMS          * SAMS MAP 
       BR   SAMS3           * CHECK FOR COMMA
AMSOFF DCEQ >4F46,V*FAC4    * OF? SAMS OFF
       BR   AMSON           * SAMS ON
* CALL AMSOFF ***************
       CALL OFFAMS          * AMS OFF
       BR   SAMS3           * CHECK FOR COMMA
AMSON  DCEQ >4F4E,V*FAC4    * ON? SAMS ON
       BR   ERRBA           * ERROR BAD ARGUMENT 
* CALL AMSON ****************
       CALL ONAMS           * AMS ON
       BR   SAMS3           * CHECK FOR COMMA   
******************************************************
* Moves 12 bytes ASSEMBLY into >8300 Scratch Pad RAM *
* Executes address at >8300 BLWP FAC & ARG workspace *
******************************************************
PASAMS CALL AMSSUB            * AMS PASS SUBROUTINE
       DST  >1E01,@STORE      * LOAD PASS VALUE 
       BR   SAMSUB            * EXECUTE IT
ONAMS  CALL AMSSUB            * AMS ON SUBROUTINE
       DST  >1D00,@STORE      * LOAD ON VALUE
       BR   SAMSUB            * EXECUTE IT
OFFAMS CALL AMSSUB            * AMS OFF SUBROUTINE
       DST  >1E00,@STORE      * LOAD OFF VALUE
       BR   SAMSUB            * EXECUTE IT
MAPAMS CALL AMSSUB            * AMS MAP SUBROUTINE
       DST  >1D01,@STORE      * LOAD MAP VALUE
SAMSUB XML  >F0               * EXECUTE ASSEMBLY
       RTN                    * RETURN
**********************************************************
* MOVES CPU PROGRAM TO SCRATCH PAD                       *
AMSSUB MOVE 18,G@AMSCRU,@>8300 * GET ASSEMBLY FROM GROM  *
       RTN                     * RETURN                  *
**********************************************************
* SAMS PAGE CHANGE    
******************************************************
* SAMS PAGES 2,3,A,B,C,D,E,F TOKENS                  *
* PAGES range from 0 to 255 now instead of 16 to 255 *
* Also now all SAMS RAM range not just lower 8K      *
******************************************************
SAMSPS CALL SAMS4A         * ADDRESS IN TEMP & PUSHED 
       CEQ  COMMAZ,@CHAT   * COMMA?
       BR   ERRSYN         * ERROR SYNTAX
       XML  PGMCHR         * Skip COMMA
       CALL STRPAR         * Get Number
       XML  CFI            * PAGE Convert to integer
       CALL MAPAMS         * AMS MAP
       CALL ONAMS          * AMS ON
* TEMP has RAM address >A000 up to >F000 
* Shift address to be 2* value for SAMS register
* i.e. >F0 would be >1E so >401E would be register 15
       SRL  3,@TEMP        * MOVE TO LOWER NIBBLE
       EX   @TEMP,@TEMP+1  * SWAP BYTES INDEX ADDRESS
       EX   @FAC1,@FAC     * SWAP BYTES PAGE:BANK
       ST   @FAC1,@>4001(@TEMP) * SET BANK
       ST   @FAC,@>4000(@TEMP)  * SET PAGE
       CALL OFFAMS        * AMS OFF <<<<<<<<<<<< SORRY WRONG MATT IT TURNS OFF SAMS EACH TIME <<<<<<<<<<
SAMS3  CEQ  COMMAZ,@CHAT  * COMMA?
       BS   SAMS2
SAMS4  CEQ  RPARZ,@CHAT   * )?
       BR   ERRSYN        * SYNTAX ERROR
       XML  PGMCHR        * Skip ")"
       CALL RETURN        * RETURN TO CALLER
****************************************************
* SAMS PAGES 2,3,A,B,C,D,E,F                       *
* Get 2 and 3 numeric or A to F tokens             *
* input in CHAT is >C8 is numeric or must be token *
* output TEMP has RAM ADDRESS of 4K page to save   *
****************************************************
SAMS4A DCLR @TEMP      * Clear address storage
       CEQ  >C8,@CHAT  * NUMBER?
       BR   SAMSAL     * No must be 2 or 3 or A to F 
       CALL STRPAR     * Get number 
       XML  CFI        * Convert to integer
       CHE  4,@FAC1    * 1 or higher
       BS   ERRBA      * ERROR BAD ARGUEMENT
       ST   >20,@TEMP  * Defualt address >2000
       CEQ  2,@FAC1    * 2?
       BS   SAMSP3     * Ok so done
       CHE  4,@FAC1    * 4 or higher?           
       BS   ERRBA      * ERROR BAD ARGUEMENT
       ADD  >10,@TEMP  * Get address 
SAMSP3 RTN             * RETURN
* 24K ADDRESS PAGES
SAMSAL CHE  >47,@CHAT  * G OR HIGHER
       BS   ERRBA      * ERROR BAD ARGUEMENT
       CHE  >41,@CHAT  * A OR HIGHER?
       BR   ERRBA      * ERROR BAD ARGUEMENT
       ST   @CHAT,@ARG * Save TOKEN
       SUB  >41,@ARG   * 0 TO 5
       ST   >A0,@TEMP  * Default address >A000
SAMSLP CZ   @ARG       * 0?
       BS   SAMSD      * RETURN 
       ADD  >10,@TEMP  * >B000 TO >F000 
       DEC  @ARG       * 5 TO 1
       B    SAMSLP     * LOOP FOREVER
SAMSD  XML  PGMCHR     * SKIP TOKEN
       RTN             * RETURN
***********************************************************

Example would be:

CALL SAMS(2,28,3,29,A,30,B,31,C,32,D,33,E,34,F,35) ! loads entire 32K into SAMS pages 28 to 35

From source code you can see each time for every page it TURNS ON SAMS DSR IN MAP MODE and each time TURNS OFF SAMS DSR!

 

 

Link to comment
Share on other sites

Yep, even in classic99, CALL PLOAD worked fine.. without the CALL SAMS. 

If I add the CALL SAMS, such as CALL SAMS(2,17) prior to the CALL PLOAD, then it hangs... because the mapper registers are in memory at the same time as the FDC ROM. 

 

Classic 99 complains with this wonderful error message in the debug log: 

 

WARNING! DSR Conflict between >1E00 and >1000 at PC >0AE6

 

This is clearly not a TIPI issue, but a RXB issue with the CALL SAMS routine.

  • Like 2
Link to comment
Share on other sites

As I am turning off the SAMS each time it changes pages the only thing I leave on is MAP mode instead of PASS mode.

 

As for FILE ERROR how come using TIDir it can test my SAMSDEMO program without a single error on Classic99 and once moved to TIPI crashes everytime?

 

Guess I can show you when in ZOOM.

 

  • Like 1
Link to comment
Share on other sites

1 hour ago, RXB said:

As I am turning off the SAMS each time it changes pages the only thing I leave on is MAP mode instead of PASS mode.

 

As for FILE ERROR how come using TIDir it can test my SAMSDEMO program without a single error on Classic99 and once moved to TIPI crashes everytime?

 

Guess I can show you when in ZOOM.

 

 

We found the problem in RXB, the routine turning off the sams cru bit 0 actually was turning it on. 

 

Classic99 shows the warning. Lesson learned, believe the warnings in classic99 :)

 

  • Like 5
  • Thanks 2
Link to comment
Share on other sites

Yea a simple fix:

***********************************************************
* CPU PROGRAM FOR >8300 SCATCH PAD SUBROUTINE AMSCRU      *
***********************************************************
*                 *        AORG >8300
AMSCRU DATA >8302 * AMSCRU DATA >8302     * First address.
       DATA >C04C *        MOV  R12,R1    * Save R12 
       DATA >020C *        LI   R12,>1E00 * Load CRU bits
       DATA >1E00 *
       DATA >1D00 *        SBO  0         * Set bits ones
       DATA >C301 *        MOV  R1,R12    * Restore R12
       DATA >04E0 *        CLR  @>837C    * Clear for GPL
       DATA >837C *
       DATA >045B *        RT             * Return to GPL.
                  *        END
***********************************************************
******************************************************
* Moves 12 bytes ASSEMBLY into >8300 Scratch Pad RAM *
* Executes address at >8300 BLWP FAC & ARG workspace *
******************************************************
PASAMS CALL AMSSUB            * AMS PASS SUBROUTINE
       DST  >1E01,@SETCRU     * LOAD PASS VALUE 
       BR   SAMSUB            * EXECUTE IT
ONAMS  CALL AMSSUB            * AMS ON SUBROUTINE
       DST  >1D00,@SETCRU     * LOAD ON VALUE
       BR   SAMSUB            * EXECUTE IT
OFFAMS CALL AMSSUB            * AMS OFF SUBROUTINE
       DST  >1E00,@SETCRU     * LOAD OFF VALUE
       BR   SAMSUB            * EXECUTE IT
MAPAMS CALL AMSSUB            * AMS MAP SUBROUTINE
       DST  >1D01,@SETCRU     * LOAD MAP VALUE
SAMSUB XML  >F0               * EXECUTE ASSEMBLY
       RTN                    * RETURN
**********************************************************
* MOVES CPU PROGRAM TO SCRATCH PAD                       *
AMSSUB MOVE 18,G@AMSCRU,@>8300 * GET ASSEMBLY FROM GROM  *
       RTN                     * RETURN                  *
**********************************************************

 

  • Like 2
Link to comment
Share on other sites

3 hours ago, jedimatt42 said:

 

We found the problem in RXB, the routine turning off the sams cru bit 0 actually was turning it on. 

 

Classic99 shows the warning. Lesson learned, believe the warnings in classic99 :)

 

Whew, good find.    What was/is the reason for the TIPI being "affected" when the other controller card(s) seemed to work?  Was that bit only turned on at CRU >1000?  Or was it something else like SAMS register interference?  

Link to comment
Share on other sites

Whew, good find.    What was/is the reason for the TIPI being "affected" when the other controller card(s) seemed to work?  Was that bit only turned on at CRU >1000?  Or was it something else like SAMS register interference?  
Worked great in classic 99 because classic 99 doesn't actually use the DSR for disk. It also worked sometimes in real hw depending on situation

It was on at the sams cru

Sent from my LM-V600 using Tapatalk

  • Like 1
Link to comment
Share on other sites

It was SAMS registers being left banked in to >4000 conflicting with any DSR ROM.

 

The failure could have happened to any other controller type. May have depended on board closeness to the Flex card, random luck, type of data bus driver chip, etc... 

 

Emulation doesn't simulate bus contention. (That would be a cool feature, to provide random values in this situation)

 

This had nothing to do with TIPI. TIPI's reputation was victimized by being the new thing in the box. Assertions that "it" works with every other controller are only credible if "it" is limited to the PROGRAM image loading code in RXB, which also works on TIPI. 

 

Too many pronouns in this thread. Too many apples and oranges equivalencies. 

 

At least with SAMS the registers would typically collide with the DSR ROM header causing failure during name list traversal instead of later in data transfer.

  • Like 4
Link to comment
Share on other sites

Oh, and what I demonstrated in zoom was classic99 using a disk image with the actual TI DSR ROM. So the magic FIAD mode was not in play. I think if the FIAD mode was used, and conflict was simulated, there issue would have shown up. I believe classic99 FIAD mode magic doesn't kick in until after the DSR address is actually branched to.

 

Tursi's Classic 99 was the hero here! It provided the warning about the conflict. If payed attention to, that is more than enough. 

 

 

  • Like 3
  • Thanks 1
Link to comment
Share on other sites

20 hours ago, RXB said:

Yea a simple fix:


***********************************************************
* CPU PROGRAM FOR >8300 SCATCH PAD SUBROUTINE AMSCRU      *
***********************************************************
*                 *        AORG >8300
AMSCRU DATA >8302 * AMSCRU DATA >8302     * First address.
       DATA >C04C *        MOV  R12,R1    * Save R12 
       DATA >020C *        LI   R12,>1E00 * Load CRU bits
       DATA >1E00 *
       DATA >1D00 *        SBO  0         * Set bits ones
       DATA >C301 *        MOV  R1,R12    * Restore R12
       DATA >04E0 *        CLR  @>837C    * Clear for GPL
       DATA >837C *
       DATA >045B *        RT             * Return to GPL.
                  *        END
***********************************************************
******************************************************
* Moves 12 bytes ASSEMBLY into >8300 Scratch Pad RAM *
* Executes address at >8300 BLWP FAC & ARG workspace *
******************************************************
PASAMS CALL AMSSUB            * AMS PASS SUBROUTINE
       DST  >1E01,@SETCRU     * LOAD PASS VALUE 
       BR   SAMSUB            * EXECUTE IT
ONAMS  CALL AMSSUB            * AMS ON SUBROUTINE
       DST  >1D00,@SETCRU     * LOAD ON VALUE
       BR   SAMSUB            * EXECUTE IT
OFFAMS CALL AMSSUB            * AMS OFF SUBROUTINE
       DST  >1E00,@SETCRU     * LOAD OFF VALUE
       BR   SAMSUB            * EXECUTE IT
MAPAMS CALL AMSSUB            * AMS MAP SUBROUTINE
       DST  >1D01,@SETCRU     * LOAD MAP VALUE
SAMSUB XML  >F0               * EXECUTE ASSEMBLY
       RTN                    * RETURN
**********************************************************
* MOVES CPU PROGRAM TO SCRATCH PAD                       *
AMSSUB MOVE 18,G@AMSCRU,@>8300 * GET ASSEMBLY FROM GROM  *
       RTN                     * RETURN                  *
**********************************************************

 

 

So, before RXB had the same machine code being stuffed into @STORE , now you have them being stuffed into @SETCRU...  

For anyone following the code. SAMSUB calls machine code (originating at AMSCRU) that has been stuffed into >8300 cpu ram. CALL AMSSUB does the stuffing. Then DST (Double byte STore) moves a single word piece of machine code overtop... So presumably, @SETCRU must be equal to >8308 (Not shown) overwriting the SBO 0 instruction that is in the template machine code.

 

For ONAMS  >1D00 is machine code for SBO 0

For OFFAMS >1E00 is machine code for SBZ 0

For MAPAMS >1D01 is machine code for SBO 1

For PASAMS >1E01 is machine code for SBZ 1

 

After the machine code is modified in scratchpad, SAMSUB executes the code pointed to by >8300 in cpu ram.

 

Clever, but hard as hell to read. 


What was the old value of @STORE from the previous snippet?   The old code already had >1E00 SBZ 0 for OFFAMS. So the code posted here doesn't show the key to how it was fixed

Was the old GPL code stuffing the machine code into the wrong address? 

Edited by jedimatt42
Link to comment
Share on other sites

1 hour ago, jedimatt42 said:

 

So, before RXB had the same machine code being stuffed into @STORE , now you have them being stuffed into @SETCRU...  

For anyone following the code. SAMSUB calls machine code (originating at AMSCRU) that has been stuffed into >8300 cpu ram. CALL AMSSUB does the stuffing. Then DST (Double byte STore) moves a single word piece of machine code overtop... So presumably, @SETCRU must be equal to >8308 (Not shown) overwriting the SBO 0 instruction that is in the template machine code.

 

For ONAMS  >1D00 is machine code for SBO 0

For OFFAMS >1E00 is machine code for SBZ 0

For MAPAMS >1D01 is machine code for SBO 1

For PASAMS >1E01 is machine code for SBZ 1

 

After the machine code is modified in scratchpad, SAMSUB executes the code pointed to by >8300 in cpu ram.

 

Clever, but hard as hell to read. 


What was the old value of @STORE from the previous snippet?   The old code already had >1E00 SBZ 0 for OFFAMS. So the code posted here doesn't show the key to how it was fixed

Was the old GPL code stuffing the machine code into the wrong address? 

Yea sorry I try to use as few bytes in GPL as possible.

 

My code is pretty much my code and you can truly blame me for being confusing.

I should have included SETCRU EQU >8308 but was in a rush to post this fix.

I always loved SELF MODIFY CODE and RXB is full of it.

 

I do have one redeeming quality....I comment the hell out of my code.

  • Like 1
Link to comment
Share on other sites

7 minutes ago, RXB said:

Yea sorry I try to use as few bytes in GPL as possible.

 

My code is pretty much my code and you can truly blame me for being confusing.

I should have included SETCRU EQU >8308 but was in a rush to post this fix.

I always loved SELF MODIFY CODE and RXB is full of it.

 

I do have one redeeming quality....I comment the hell out of my code.

Then that should be correct now. But the question still stands. What was wrong before? Where was it stuffing the SBZ 0 machine code instruction for OFFAMS?

  • Like 2
Link to comment
Share on other sites

21 hours ago, jedimatt42 said:

Emulation doesn't simulate bus contention. (That would be a cool feature, to provide random values in this situation)

This is true, Classic99 doesn't emulate bus contention and it can not activate multiple DSRs as written (because it tracks which DSR is active instead of having a flag for each DSR, like real hardware does). That's why the warning is there.

 

Generating random values would just generate bug reports, force me to reverse engineer people's software to point out the bug, and then get "but it works for me". ;) But I would like to add a switch in 4 that will breakpoint on all warnings, that way I can just tell programmers to turn that on. ;)

 

  • Like 4
Link to comment
Share on other sites

3 hours ago, jedimatt42 said:

Then that should be correct now. But the question still stands. What was wrong before? Where was it stuffing the SBZ 0 machine code instruction for OFFAMS?

At least in the new source for RXB 202D, the symbol @STORE is >8314. So if that was true before, it used to not actually modify the routine as designed, and so all operations ONAMS, OFFAMS, MAPAMS, and PASAMS were behaving like ONAMS. Which is the behavior we saw, but with the modifying code, not evident from the snippets posted.

 

Sorry, I just wanted closure for such an epic adventure. 

  • Like 1
Link to comment
Share on other sites

5 hours ago, jedimatt42 said:

Then that should be correct now. But the question still stands. What was wrong before? Where was it stuffing the SBZ 0 machine code instruction for OFFAMS?

I think it was >8314 that is STORE and at time that was the original AMS code I was putting into Scratch Pad >8300, but later modified the code to be smaller.

When my SCSI drive died I got a few copies but lost all the in between versions so I think that was the issue. I lost the version that was correct in the dead SCSI drive.

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

Update 2.20 - 2021-02-24

 

Fix FIXED record file record counting from PI.HTTP...  Requires ROM update also to realize this fix. 

 

ROM download:

https://www.jedimatt42.com/downloads/tipi-dsr-2021-02-24.zip

 

ROM update includes record number update in PAB fix. Plus stupid code fix in CALL TIPI ea5 loading code, and cleans up code warnings presented by updates in xas99 ( mostly @0(R13) can be *R13, and B @SOMETHING can be JMP SOMETHING

 

 

  • Like 4
Link to comment
Share on other sites

On 2/25/2021 at 12:31 AM, jedimatt42 said:

I should add, that you can take the PI side update, without the eprom. It will just equate to no change in functionality.

For now, i'll skip the dsr update.

I mainly use TIPI to load games into xb and a couple of EA5 games. As long as i can keep doing that, i'm happy.

I may someday try to get a memory+tipi combo from arcadeshopper, as i could always use it on my second TI. By the time i purchase that, the newest dsr should ship with it.

Thanks for your hard work and dedication @jedimatt42 .

  • Thanks 1
Link to comment
Share on other sites

On 2/25/2021 at 12:23 AM, jedimatt42 said:

Update 2.20 - 2021-02-24

 

Fix FIXED record file record counting from PI.HTTP...  Requires ROM update also to realize this fix. 

 

ROM download:

https://www.jedimatt42.com/downloads/tipi-dsr-2021-02-24.zip

 

ROM update includes record number update in PAB fix. Plus stupid code fix in CALL TIPI ea5 loading code, and cleans up code warnings presented by updates in xas99 ( mostly @0(R13) can be *R13, and B @SOMETHING can be JMP SOMETHING

 

 

So basically pull out the ROM from the TIPI-PEB and update it?

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...