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,431

  • Joined

  • Last visited

  • Days Won

    3

Posts posted by jedimatt42

  1. Posted

    3 hours ago, klrw111-78 said:

     I decided to do some experimentation and wanted to report my observations in case anyone might be interested.  My system has the following in the PEB:  SAMS, TI FDC 80-TRKmod, TI RS232 with HDX, HRD4000B with 8MB, TIPI, and IDE.  I had installed FC 0.9 on the FG99 a while back and have been using for a while.  The IDE was set with CRU 1000, HRD400B with CRU 1200, TIPI with CRU 1400.  The DSK and DSK1 emulation was off on IDE and HRD4000B.  I upgraded FC to 1.1 and 1.2 failed to recognize the HRD4000B, but other software worked fine.  I went back to FC 0M worked fine all cards and all disks worked with it.

    I decided to swap the CRUs on the IDE and HRD4000B and tried FC 1.3.  FC 1.3 recognized and worked with the HRD4000B and the IDE but stopped recognizing TIPI and HDX.  It would not take "cd" or "dir" commands to 1400.DSK4, TIPI or 1300.HDX1 or HDX1.  Changed CRU on TIPI to 1200 and IDE to 1400.  After the change FC recognized HRD and TIPI but not HDX1 or IDE.  Changed IDE back to 1200 TIPI to 1800 and tried again.  FC recognized HRD and IDE but not HDX1 or TIPI.  Pulled the TIPI card and restarted.  FC now recognized all remaining cards and devices.

    The only DSK mapped on TIPI was DSK4 to "."

    I bet I know what I did... I think I decreased the number of drives I have crubase indexes for. I can fix that.

    • Like 2

  3. Posted

    39 minutes ago, InsaneMultitasker said:

    Cool.  That makes sense except for the entry "DM2K" which I presume is a shortcut/call (it's not a device) though it doesn't end in a number and is not one of the special cases referenced above.  Not sure what the "failing" command is doing (opening the device name to test validity?) or why the CALL would matter, or even if the two are related. For me its been a week of chasing rabbit holes at work so I'm not keen on suggesting new potential RHs for hobby stuff. 

    Maybe I didn't special case 'TIPI' and just allowed any 4 letter names... when Arcadeshopper shares a screenshot with the SNUG voice card, it lists a pile of other stuff... maybe I should just let the future happen when/if it happens and add a known device name list.

    • Like 1

  4. Posted

    ArcadeShopper also noted the SAMS memory conflict with ROS CFG1 and the Force Command LOAD command. 

     

    I configure SAMS if detected, so that the first 8 pages are mapped into the 32k memory expansion without page number gaps.. This is different from transparent mode. So, I needed to restore transparent mode before loading an EA5 type program that has no expectation of other programs having gone before it... Otherwise when it turns sams mapping on, the loaded program gets swapped out/re-arranged and crashes. 

     

    so, this is fixed in version 1.3 - as usual, see post #1.

    • Like 5

  5. Posted

    3 hours ago, InsaneMultitasker said:

    It's good that 842c works but I do find it strange the earlier versions failed as the visible high level operations have not really changed since 8.32.  ROS initializes cartridges to bank 0 (via MOVE @>6000,@>6000) but that has been present since 8.32.  Only thing I noticed in the non-working picture is that two CALLs were included in the device list. Doubt that is a problem but it caught my attention.  and sometimes ROS just needs to be reloaded. ;)

     

     

    The bank normalization on startup shouldn't impact Force Command, it has starting point replicated in all banks, that does that also.

     

    Those ROS names setup in the CFG1 program are in the device names in the Device Service Routine entry list... my DRIVES command only lists things in the DSR lists, not the subroutine/CALLs lists. It also only lists 4 letter things ending in numbers along with special cases for TIPI, and PI - I have a separate LVL2 command that list the BASIC subprogram names, but only the ones with single character names. But I have to admit, maybe CALLs doesn't mean TI BASIC CALL... cause I've never bothered to learn ROS. I assumed they are some sort of shortcut device names like Gazoo had in XB2.7 Suite to trigger different cartridges with DSRLNK names, but that doesn't seem to be the case. - I'll have to go read. ( manual found and read... My assumptions are correct, just didn't realize I have to put stuff on the first ramdisk for them to do anything ) 

  7. Posted

    So, your object file doesn't look like it is a FIAD, not sure if you are using DIS/FIX options for native files. 

     

    Second, your source should have a DEF and label and that sets up the symbol you can use as an entry point. 

     

    His tutorial example dump of the object file shows the START near the end in the DEF table. I don't see a hint of that in your dump.

  8. Posted

    935072815_Screenshotfrom2020-11-1122-56-33.thumb.png.2489c554f3c20672271e31453e8281db.png

     

    So, I got my MAME (ver 220) working again... ROS842C loaded up... and the latest Force Command seems to work fine with it. 

     

    `CD DSK5` works, `CD DSK5.` works... I was still able to copy a disk full of junk to a ROS drive. DIR it, and such... 

    Note, you do not have a device name conflict for your ROS drives, so you should not need to use the crubase naming scheme to disambiguate. You do have name conflicts with the TIPI, IDE and Floppy controllers DSK1, DSK2, and DSK3... so those are the only times Force Command might need you to specify the CRUBASE... 

     

    Force Command's LOAD command doesn't seem to agree with ROS's CFG1 anymore.  I think it hangs when detecting SAMS... cause if SAMS is there, I have it all enabled and in use... I need to fix my LOAD command to turn SAMS back off and reset the default bank mapping.

     

  9. Posted

    4 hours ago, klrw111-78 said:


    The drives command shows all active cards with crus including cru 1400 with all ram disks including the calls setup in ROS842C


    FC 0.M addresses the drives and works as it should, but fails in versions 1.1 and 1.2


    Sent from my iPad using TapatalkIMG_0457.jpg

    Ok, I must have inadvertently broken something. 

     

    Hopefully I can get my MAME working again tonight. Supporting things you don't use yourself is always a bad idea. But, that is the road I went down.

  10. Posted

    1 hour ago, jedimatt42 said:

    I tested it months ago with the MAME Horizon Ramdisk emulation using what I think was latest ROS DSR.  I will have to try that again, but I haven't changed anything at that level. 

     

    Try the 'drives' command. What do you see?

     

    Some portions may be more strict requiring a '.' at the end of a device name or directory.

     

    Expected hardware compatibility is documented on this page: https://github.com/jedimatt42/fcmd/wiki/Compatibility

     

    OS updates or something broke my MAME, so retesting generic HRD compatibility will take me a while. HRD devices have a soft-DSR, so compatibility with Force Command can break with any ROS update also. When I get the HRD emulation running again, I'll document the version of ROS it was tested with. 

  11. Posted

    2 hours ago, klrw111-78 said:

    Upgraded to 1.2 yesterday on the fg99.  Tried to access DSK5 on the RAM disk, but it would not take it or CRU.DSK5 for a dir or cd command.  Loaded DM2K and it had no problem with DSK5.  Does FC work with HRD400B ram disks?

    I tested it months ago with the MAME Horizon Ramdisk emulation using what I think was latest ROS DSR.  I will have to try that again, but I haven't changed anything at that level. 

     

    Try the 'drives' command. What do you see?

     

    Some portions may be more strict requiring a '.' at the end of a device name or directory.

    • Like 1

  12. Posted

    9 hours ago, BeeryMiller said:

    Matt,

     

    I know you released a standalone version of the FTP client some time ago and you have your latest release.  Got a question based on another question a user asked in the MDOS 7.00 thread.

     

    Will your newest release, and/or the older standalone release that worked on the Geneve in Rompage mode, allow one to to do a FTP transfer from a WDS1/HDS1/IDE1/SCS1 device  to a TIPI path?  More specifically, if it is a FTP GET * (I think that is the context, though not 100% sure), would it copy all files and directories from one place to the other?

     

    What I am wondering is if the FTP client can be used as a backup tool from one device to the other with it creating sudirectories, etc. on the fly as needed with wildcard functionality?  I think the answer is no, but wanted to check.

     

    There may be a tool, though not 100% sure, that may already have the capability (HardBack) to backup to the TIPI, but not sure how if it does direct sector I/O that would prevent it from working or not.  


    Beery

     

    No, the old FTP EA5 code would need much more work to do any kind of recursive copy. And it does not copy from TIPI to TI. It copies from an FTP server to the TI. The new versions doesn't move the ball in that direction either.

  14. Posted

     

    More work has been done with the API. allowing for the FTP code to be re-implemented as an external command. 

    Publishing now, so the REDO command recall can be used. 

     

    FTP can be loaded from the PATH - it is included in the ZIP under FC.BIN.

    PATH can be set per the examples this post: 

     

     

    The FTP command supports a hostname and port argument... like:

    FTP 192.168.1.105 21

    ( I don't remember 21 being a default, but it should be, will be if it isn't... ) 

     

    A preview of using the API is visible here: https://github.com/jedimatt42/fcmd/tree/master/example/gcc

     

     

    • Like 2

  15. Posted

    15 hours ago, mizapf said:

    Is the optional 32k RAM also battery-backed? It is not really clear from the schematics. 

    I don't think you can choose to power part of a chip with SRAM, without powering all of the chip.

    • Like 1

  16. Posted

    15 minutes ago, acadiel said:

    I need to burn a new image today.  I was like .7 versions behind and went to update, and it tried all day.  Thanks for the heads up - I’ll just set it up again. 

    Well, 2.12 - 0.7 is 2.5, the latest image that I've produced. 

     

    So you'll just be back were you started. 

     

    If people have trouble with updates, try an ethernet cable. 

    • Like 2

  17. Posted

    @pcoderdude14 - I hooked my TIPI PI up to a display today, and only see a little trouble, easily fixed in raspi-config

     

    The default display mode is 'monitor default' so it detects what the monitor can do, and tries to do that. On my monitor, this partially fails... ( I see this sometimes on my MiSTer as well ) - My symptom is simply the screen image is cut off a bit on 3 of four sides. Going into raspi-config, under the advanced options, and selecting a fixed display mode seems to fix that for me. I've tried 640x480, and 1920x1080 - after that, it doesn't do screen detection, and just uses what it was told, and my issues go away.

     

    This isn't exactly your symptom, but it does indicate there can be display specific quirks, that can be cured by using raspi-config -- there is also a screen blanking feature that can be disabled in there.

     

    ( I've been exploring this on the PI 3B )

  18. Posted

    Update 2.12 - 2020-11-08

     

    - FIAD fixer take 2 - (still) happens synchronously during update

     

    If you are curious, it logs to the /var/log/daemon.log - it will list each file it is fixing.

    Most TIers will see nothing fixed cause they have no problems, or were completely fixed yesterday.

     

    I do see evidence that bad files have leaked out into community distributions. File copying from TIPI to disks, or DSK images with anything will preserve the error. This is not a problem unless they are intended to be consumed off TIPI by programs that care. File copying back to TIPI also preserves the error.

     

    If these leaked malformed files haven't been problematic already, they probably never will be.

  19. Posted

    36 minutes ago, webdeck said:

    After doing the upgrade, I tried running the fix script manually because I was worried I may have rebooted the tipi too quickly afterwards.  It shows this error: 

    (ENV) [email protected]:~/tipi/services $ python -m ti_files.fix_dv_fiads
Traceback (most recent call last):
  File "/usr/lib/python3.7/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/usr/lib/python3.7/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/home/tipi/tipi/services/ti_files/fix_dv_fiads.py", line 39, in <module>
    if is_broken(data):
  File "/home/tipi/tipi/services/ti_files/fix_dv_fiads.py", line 20, in is_broken
    return data[ridx-1] == 0xff and data[ridx] == 0x00
IndexError: bytearray index out of range

     

    1st, do you mean rebooting the PI? Why would you do that? The update process restarts all the services. 

     

    2nd, looks like you have an edge case on record size I didn't consider or some foreign or empty files. I will have to update the script, and do more testing I guess. It will have done no harm, but won't have fixed everything. Good find.

  20. Posted

    Somewhere way back in time, in this thread, Insomnia describes it... 

     

    basically:

    * functions are called with BL

    * they respect R11 as the return address

    * R10 is the stack pointer, counts down.

    * parameters are passed in the current workspace as R1 - R8? maybe... I'm sure there is a limit ( it might start using stack after that limit ) 

    * R10 should be the same when the function returns

    * return value is in R1

    * byte type parameters are placed in high byte of register (fact check me) 

     

    BLWP/RTWP is not used, and R13-R15 are also generally not used. 

    R12 is generally not used, - I've observed the general practice of abusing it in inline assembly, or properly using it for crubase in inline assembly - 

    I don't think I've ever seen it generate code with R0 used. I abuse R0 in my inline assembly.

     

    Object files produced are in ELF-32 format (or some elf format), gcc linker also produces an ELF file, gcc objdump tools are used to extract binary images linked to specified addresses ( like program images without the EA5 header ), other tools will convert the ELF to EA5 or ELF to cartridge bin.

     

     

     

    • Like 3
    • Thanks 1

  25. Posted

    20 minutes ago, dgrissom said:

    On my TIPI/32K my Version would not update to 2.10.   If forced an update with instructions from a July post.

    This is the first time my unit has not detected an update from CALL TIPI?

    Curious?

     

    David G 

     

    UPDATE:  I found my FinalGROM99 needed reseating.  May have affected the update?

     

    Probably a bug in my version string comparison... I'm used to upgrading from an upgraded state, so I didn't think enough of this.

     

    in 'CALL TIPI' / TIPICFG, press FCTN-U to trigger an upgrade even if it isn't detected.

     

    This just worked for Arcadeshopper.

     

    (I'll take some time off from FTP this afternoon, and fix TIPICFG)

    • Like 1
AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...