Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

jedimatt42

Members
 View Profile  See their activity

  • Content Count

    3,419

  • Joined

  • Last visited

  • Days Won

    3

Posts posted by jedimatt42

  1. Posted · Edited by jedimatt42

    The 2.16 SD Card image was borked, in that I did not setup wifi on it before archiving it.

    It isn't totally DOA. You can use wifi on it by using CALL TIPI, set the wifi SSID and PSK , write, then wait a while... it reboots the pi.. ... then

    CALL TIPI("TIPI.NET.TELNET") login to localhost at port 23, and 

     

    sudo cp /etc/wpa_supplicant/wpa_supplicant.conf /boot/

    sudo reboot now

     

    wait a while, and then reset the 4A... if thing seem hung... wait a little while longer... 

    Then CALL TIPI should show an IP address in the upper right, provided you entered everything correctly.

     

    Or create the wpa_supplicant.conf correctly on the /boot partition of the sd-card before booting the PI with it. This is the official how to get yourself out of WiFi issues technique provided by Raspberry PI .org

     

    But, I'm going to fix it, and produce a new image.

    • Like 1

  5. Posted

    My link in is dead. :( They are indeed single pin machine sockets. I got them from peconnectors.com, but they no longer seem to be available there. More rigorous searching may find something.

     

    :(

     

    They are however the same thing that is available in a SIP format. With a fine solder tip, I suspect that technique could be adjusted.

     

    • Like 1

  7. Posted

    @wolhess regarding the flashing cursor from READKEY, I took the cursor away on purpose. It never printed the key that you pressed either. So I decided it was wrong to have READKEY act like a line input command. 

     

    Version 1.14 fixes the SAMS mapping before launching a cartridge. Mega Menu works for me with XB GEM 2.8 via the XB TIPI.MM.MM command.

     

    (Jumping directly into XB GEM 2.8's T80XB menu entry, and friends, still doesn't work.)

    • Thanks 1

  10. Posted · Edited by jedimatt42

    @retroclouds, I'll add it to github issues.  Along with the need to rework that. It hasn't handled long lines well - ever. You probably ran into a buffer overrun! Now can you use it to jailbreak your 4A? 

     

    Back when I was writing TIPICFG, I now realize I almost never prevented buffer overruns in my 4A code.

     

    (Ah, this is already recorded: https://github.com/jedimatt42/tipi/issues/141)

    • Like 1

  11. Posted

    18 hours ago, senior_falcon said:

    A different approach may solve the problem. Remember that if you can get into XB 2.8 you can change the graphics mode to 80 column text mode with CALL T80XB or CALL T80XB(n) if you want to change the number of disk files.

    Make that the first line of your program.

    That seems like a preferable approach, so the burden of knowing what extensions are used by a program remain with the programmer, and this knowledge requirement isn't distributed to all of the users of the program.

  13. Posted

    7 hours ago, wolhess said:

    ...

     

    What I think:

    - The XB command ignores the current tippimap

    - Force Command is mapping DSK1 to TIPI.FC for the XB command

    - If Force Command see no TIPI in the path it deletes the current DSK1 mapping, so the physical DSK1 is used to load the program.

    - The original TIPI.FC.LOAD program always deletes the DSK1 mapping so line 40 has to change from "D$=SEG$(A$,8,4)"  to "40 D$=SEG$(A$,9,4)"

    - I can't use XB DSK1.PROGNAME or XB TIPIPATH.PROGNAME if PROGNAME itself will load something from the mapped DSK1.,
      so I have to start a loading program first, which maps the correct tipipath to DSK1.

     

    @jedimatt42 
    I'm using the new FC v12 and XB2.8 with the main address: 31435
    Is it right that the XB command needs the full tipi path to find the program in the right tipi folder?
    Is it right that the tipimap command is unnecessarry for using the XB command?

     

    Back to on topic... 

     

    I was attempting to handle the case of a real disk drive in all that code in TIPI.FC.LOAD. But even that was wrongly coded... the SEG$(A$,8,4) should actually have been SEG$(A$,1,4) as I'm trying to pull the device name off the front of the full file path.

     

    But all of that is pointless if automap is on, DSK1 will get mapped again when the TIPI.FC.FC/XB is loaded. I need to simplify TIPI.FC.LOAD to 

      

    10 RUN "TIPI.FC.FC/XB"

     

    and change the generated TIPI.FC.FC/XB to handle the mapping restoration: 

    10 OPEN #1:"PI.CONFIG"
20 PRINT #1:"DSK1_DIR=<oldmapping>"
30 CLOSE #1
40 RUN "<yourpath>"

    That way, I've undone the temporary mapping to get XB to load TIPI.FC.LOAD, and restore your explicit mapped or unmapped state of DSK1 prior to running the actual desired xb program.

     

    That should allow running from mapped DSK1 or TIPI, or physical DSK1 without astonishment.

     

     

     

    • Like 2
    • Thanks 1

  16. Posted

    4 minutes ago, Omega-TI said:

    It's only going to be temporary Matt... unless you are so fast you get done before I get home this evening.  Ha!  😊

     

    Temporary stuff sticks around for months. If not years, and requires messaging campaigns to expunge. I think you are talking about @wolhess issue with XB, in which he clearly has a thorough understanding of what is going on and how to work around it. 

  17. Posted

    2 hours ago, wolhess said:

    Hi,

     

    in my system, if I run a program from Force Command, I saw always access on my physical drive DSK1.

    Today I tested it again to run the XB weather program on different way's.

     

    What I think:

    - The XB command ignores the current tipimap

    - Force Command is mapping DSK1 to TIPI.FC for the XB command

    - If Force Command see no TIPI in the path it deletes the current DSK1 mapping, so the physical DSK1 is used to load the program.

    - The original TIPI.FC.LOAD program always deletes the DSK1 mapping so line 40 has to change from "D$=SEG$(A$,8,4)"  to "40 D$=SEG$(A$,9,4)"

    - I can't use XB DSK1.PROGNAME or XB TIPIPATH.PROGNAME if PROGNAME itself will load something from the mapped DSK1.,
      so I have to start a loading program first, which maps the correct tipipath to DSK1.

     

    @jedimatt42 
    I'm using the new FC v12 and XB2.8 with the main address: 31435
    Is it right that the XB command needs the full tipi path to find the program in the right tipi folder?
    Is it right that the tipimap command is unnecessarry for using the XB command?

     

    XB certainly always overrides the DSK1 mapping on TIPI. It must set it to TIPI.FC. so that XB will find the TIPI.FC.LOAD program and run it on startup.

     

    XB also writes a second file TIPI.FC.FC/XB that contains the RUN "YOUR.PROGRAM.FULLY.QUALIFED"

    As you've seen this is what TIPI.FC.LOAD runs. I think I assumed people would have AUTOMAP on, so DSK1 would get remapped to the folder containing the target basic program when that is loaded by the PI. 

     

    The XB command should be able to take a file in the current directory, or a full path. These 2 cases seem to be what I do in practice. You should be able to use a relative path, but I'm guessing there is a bug with that. I'll test. There are a couple places in that code that could be going wrong. 

     

    There is room for improvement in the mapping handling. The generated TIPI.FC.FC/XB program could be written to hold the code to reset the DSK1 mapping to what it is before the XB command ran. This way if AUTOMAP is off, you shouldn't have to write little shims to set the mapping... If AUTOMAP is on, this would get overridden again, consistent with TIPI behavior. But if AUTOMAP is off, then this would undo the transient mapping to TIPI.FC for the LOAD magic. So this is an improvement I will make. 

     

    TIPI also has a feature where you can put a DV80 file in the directory of the PROGRAM file and if AUTOMAP is on, when that PROGRAM is loaded the mappings declared in that file loaded. 

     

    I pretty much never use manually mapped DSK1 for anything, so I only tested XB where the path passed was from TIPI, or is DSK1 it expected the real floppy. I didn't try DSK1. where it is mapped. If I reset the mapping of DSK1 in TIPI.FC.FC/XB that should also fix the issue with XB DSK1.WEATHER3 using the real floppy instead of the TIPI path that DSK1. was mapped to. 

     

    • Like 1
    • Thanks 1

  18. Posted · Edited by jedimatt42

    16 minutes ago, Omega-TI said:

    When I get home this evening I'll try a work around by putting something on the physical DSK1. and see what happens.  There is definitely a FUBAR in this version that will be repaired in the future.  Fortunately it will be easy to replace 1.12 with a new version on the FG99.

    Now what did I just get done saying about workarounds?

     

    Give a developer a chance at a proper solution before confusing the ecosystem with hacks.

    • Haha 1

  21. Posted

    1 hour ago, RXB said:

    So you need to look up the standard error handling instead of just making up you own?

    You could just us the TI OS it has most of those built in already.

     

    If it worked that way, wouldn't that be nice... I refer you to the developers resources thread, where all the documentation and specifications for most aspects of the 4A architecture are linked.  My statement about 'made up' was flippant, and not accurate.

     

    I don't think you understand what TIPI is... 

     

    I have adhered to the specifications of the 'TI OS' as much as practical... but as noted earlier, my copy was missing pages.

    • Like 5

  23. Posted

    1 hour ago, RXB said:

    RXB SOURCE same as XB: 

    [0149] 8345          FLAG   EQU  >8345            General 8-bit flag

[0262] 03B9          SAPROT EQU  >03B9             PROTECTION flag in SAVE

[1974] 8C15 86,45    G8C15  CLR  @FLAG             Otherwise clear protection

[2047] 8CBD 86,45    G8CBD  CLR  @FLAG             Otherwise clear protection flag

[2215]               * Has to be PROTECTED option here, crunched as unquoted str
[2216] 8DF4 D7,B0,2C G8DF4  DCEQ >C809,V*PGMPTR    Unquoted string with length 9
       8DF7 C8,09
[2217]               *                              has to be PROTECTED
[2218] 8DF9 41,09           BR   ERRSYN
[2219] 8DFB D7,E0,02        DCEQ >5052,[email protected](@PGMPTR) "PR" of PRotected
       8DFE 2C,50,52
[2220] 8E01 41,09           BR   ERRSYN             If not : SYNTAX ERROR
[2221] 8E03 D7,E0,04        DCEQ >4F54,[email protected](@PGMPTR) "OT" of prOTected
       8E06 2C,4F,54
[2222] 8E09 41,09           BR   ERRSYN             If not : SYNTAX ERROR
[2223] 8E0B D7,E0,06        DCEQ >4543,[email protected](@PGMPTR) "EC" of protECted
       8E0E 2C,45,43
[2224] 8E11 41,09           BR   ERRSYN             If not : SYNTAX ERROR
[2225] 8E13 D7,E0,08        DCEQ >5445,[email protected](@PGMPTR) "TE",of protecTEd
       8E16 2C,54,45
[2226] 8E19 41,09           BR   ERRSYN             If not : SYNTAX ERROR
[2227] 8E1B D6,E0,0A        CEQ  >44,[email protected](@PGMPTR)  "D" of protecteD
       8E1E 2C,44
[2228] 8E20 41,09           BR   ERRSYN             If not : SYNTAX ERROR
[2229] 8E22 8E,E0,0B        CZ   [email protected](@PGMPTR)     Check EOL
       8E25 2C
[2230] 8E26 41,09           BR   ERRSYN
[2231] 8E28 90,A3,B9        INC  [email protected]

    XB protection flag is at Hex >03B9 or Decimal 953 the flag named is SAPROT also set by flag named oddly FLAG

     

    CALL POKEV(953,0) ! Unprotects file and clears SAPROT flag

    CALL POKEV(953,1) ! Protects file and sets SAPROT flag

     

    XB does not have a CALL POKEV command so you are screwed in XB.

     

     

    We are talking about the FDR attribute of a file, not the XB flag. in the manual: "TI Extended BASIC", page 163, the reference for SAVE in Chapter 4, subsection 'options', second paragraph:

    Quote

     

    ... This is not the same as using the protection available with the Disk Manager module.


     

     

    It is the protection available with the Disk Manager module that we are discussing... not the SAVE PROTECTED option that those pokes manipulate.

     

    We are trying to discuss the thing that has to do with disk controller level stuff.

     

    Well, except we are done discussing it.

     

    The summary: TIPI doesn't support the disk manager protection feature, except to set and unset it. It fails to enforce it. Enforcing it could be a good thing, which I've filed as an issue in the project github repository. Native files (things not in TIFILES format) on linux are treated as read-only ( mostly ) and it could clarify things to users, if TIPI reported them as protected ( P ) in the catalog records it generates at the disk controller level. And if it uniformly enforced the protection.

     

     

     

  24. Posted

    4 hours ago, Omega-TI said:

     

    Anything is possible.  I'll have search the house though, the only SD cards I can find at the moment are all high speed high capacity cards used for photography.  If I remember correctly, the FinalGROM works best with smaller and slower cards, or was that just the FlashROM?  

     

    Arcadeshopper did some testing, and he gets the flashing light problem if FCMDG and XB28GEMG are together in a subdir. But not if they are together at the ROOT of the SD card. 

    I haven't verified this. But They do 'work' ( no flashing light ) in my setup, which has both in the ROOT of the SD card. 

    That might be a issue with the FinalGROM firmware, except, that Arcadeshopper verified he can go from XB28GEMG back to FCMDG... so that points to an subtle issue in Force Command's XB command.

     

    We can do more testing on our end before you need to spend your hobby time on this.

  25. Posted

    43 minutes ago, Tursi said:

    In that case - help me improve the loader. ;) What were you not able to load and why?

     

    I don't think the things I changed belong to that loader. 

     

    I had to reset the 26.5 row VDP register.

    Re-lock the F18A

    Map pages 0-16 of SAMS to addresses 0-64k, (I should then turn off the mapper, but didn't) 

     

    All of the why, was because I had turned on optional hardware. 

     

    I have to do these same resets before switching FinalGROM cartridges also.

     

    Maybe some of that matters if you want to support XBGEM's 80 column extension... Or maybe it isn't a problem since it isn't also doing 26.5 or 30 row mode.

     

    • Like 1
AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...