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

    On 9/30/2020 at 2:19 AM, mizapf said:

    If you open a file for output and close it directly, it will have 0 content, just the File Information Block (1 sector).

    Interestingly, classic99 creates a FIAD that has a data sector with no records in it... so 0xFF, followed by all 0x00s  , when run the following in BASIC: 

      

    10 OPEN #1:"DSK1.EMPTY",OUTPUT
20 CLOSE #1

      

    ➜  DSK1 hexdump -C EMPTY 
00000000  07 54 49 46 49 4c 45 53  00 01 80 03 00 50 01 00  |.TIFILES.....P..|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000080  ff 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000090  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000180

     

    I'll take your word for how it behaves on a real disk. 

  2. Posted

    On 10/3/2020 at 4:53 AM, Vorticon said:

    I realized yesterday that the RMDIR command does not work on non-empty directories. And the DELETE command does not accept * as an argument, so I have to delete all the files in a directory one by one before being able to delete the directory itself.

    Therefore a wish list:

    • DELETE * to delete all files in a directory (with a confirmation prompt)
    • RMDIR with a switch for deleting all sub-directories and files in the requested directory

    Easier said than done, hence the wish part :)

     

    Out of curiosity, what devices are you deleting from? I seem to recall you had an IDE controller, and now a TIPI. The TIPI way to do this would be to open up the share on a modern PC, and use that modern PC for what it is good for. 

     

    But I see the value of these in spinny disk situations. They are added to the github issues list.

  4. Posted

    Ok, this seems to work for me. Months of rearranging code. I'm going to take an incremental approach to making each API function 'public'. So this isn't the public API release. There may be new bugs, but I thought I did a pass at retesting all of it. 

     

    The larger buffer work is in, and the empty file fix is in. 

     

    CALL was removed... so it's not compatible with some scripts, if your scripts called other scripts...  0.M is still in post #1, and I'll leave it there for a while.  

     

    It's free hobby software, so 1.0 doesn't mean it's bug free. LOL... download links in post #1

     

     

     

  6. Posted

    On 10/2/2020 at 11:41 PM, InsaneMultitasker said:

    Sticking with VDP is the only option for some floppy controllers e.g., TI and Corcomp,  however, some of the later peripherals do not lock you into VDP RAM buffers.  Leveraging existing DSR CPU buffer support is relatively straightforward, even if few people use it.    If you don't want to fork your routines to add CPU buffering, a VDP buffer of (17 "TI sectors" * 256 bytes/TI sector) works well to cover the 8k+ image scenario in two passes.  For years that was my chosen buffer size for terminal emulation to cover the GRAM Kracker format and others that had just enough residual data to be annoying.

     

    I have implemented the 17 sector thing, after moving my VDP usage around, and remembering today that my memory map in 40 column mode is greatly different from my 80 column mode...  But I've easily found a compromise that gives me that larger buffer size. 

     

    I don't ever copy it out of VDP, so the CPU RAM support for some DSR's would actually hurt if both the source and target device are not capable of the CPU RAM feature.  

     

    I'll probably drop an update soon, tonight still maybe... I'm trying to track down the empty file issue... So far it doesn't seem to be a ForceCommand issue.

  11. Posted

    39 minutes ago, webdeck said:

    Silly question - is there a way to repeat the previous command?  I'm thinking like the up arrow in linux which lets you go back in history and either redo a command or edit it.  I'm guessing there isn't enough memory to maintain a full history stack, but repeating the last command would be useful in some situations.

     

    I actually have 24k of RAM I'm not using.  I desire to support a 256 byte command line... so that's almost 100 lines of history. but if I get smarter, and use a circular linked list, with variable length entries, a new command might kick 2 out, or maybe several small commands fit in the space of one old one. And then 4k of history could look like 100 lines... 

     

    with SAMS, I can move history out of the memory map while executing an external command program. And then map it back in when returning to the command prompt. But, without SAMS, I might have to pull an AtariDOS trick and page it out to a file so external programs can use that fixed set of 24K ram. The bit unique to AtariDOS was the intelligence to only do that if a ramdisk was present... I could use TIPI as suitably fast storage for that, or allow an environment variable to configure a different location... or fall back on single line history only, if no TIPI and no config.

     

    A lot of TI software is not Force Command aware, ( how could it be, Force Command is new and under development ) so I'm thinking any multi-line history would be beneficial if flushed to disk on key events like FG99, XB, or LOAD, all events where Force Command has to give up control of the machine.

     

    ( I always forget BASH supports arrow keys... set -o vi ) 

     

    • Like 2

  12. Posted

    So, I keep thinking about memory usage, and seeking... and realize every lvl2 direct read/write has seek to go find the file in the filesystem layout, and then seek to the file block location to get some data or write some data... So to reduce this seeking, and stick with direct read/write, only using more VDP memory will help at all. 

     

    My current VDP memory map is pretty adhoc...  

    | Address | Size in bytes | Description         |
| ------- | ------------- | ------------------- |
| 0x0000  | 0x0960        | Image table         |
| 0x0A00  | 0x0100        | Sprite table        |
| 0x1000  | 0x0800        | Pattern table       |
| 0x1800  | 0x0960        | Color attributes    |
| 0x2160  | n/a           | free space          |
| 0x3000  | 0x0100        | IO Buffer           |
| 0x3200  | 0x010A        | PAB                 |
| 0x3FF8  | 0x0008        | Nanopeb stats       |
| 0x4000  | 0x0034        | Fast scroll routine |

     

    I'm sure I can push some of that around and get a 4K VDP buffer. Something like:

      

    | Address | Size in bytes | Description         |
| ------- | ------------- | ------------------- |
| 0x0000  | 0x0960        | Image table         |
| 0x0960  | 0x00A0        | /free space-------/ |
| 0x0A00  | 0x0100        | Sprite table        |
| 0x0B00  | 0x010A        | PAB                 |
| 0x0C0A  | 0x03F6        | /free space-------/ |
| 0x1000  | 0x0800        | Pattern table       |
| 0x1800  | 0x0960        | Color attributes    |
| 0x2160  | 0x1000        | 4K IO Buffer        |
| 0x3160  | varies        | /free-vdp stack---/ |
| 0x3FF8  | 0x0008        | Nanopeb stats       |
| 0x4000  | 0x0034        | Fast scroll routine |

    The perfect balance might be just over 4k, so that those 8k + header EA5 files are only 2 operations instead of 3.

    • Like 2

  13. Posted

    35 minutes ago, webdeck said:

    I'm loving Force Command.  I've been using it to copy files off of my somewhat flaky Seagate ST-225 drive and onto my TIPI.  I have a few questions:

    1. It sounds like it reads one sector at a time from the hard drive, re-seeking after each sector, which takes a very long time.  Is there any way to make it copy faster (e.g. use a larger buffer in RAM)?
    2. Right now, I have to copy the files in each directory separately, including subdirectories.  Is it possible to do a recursive copy?
    3. It gives an error when trying to copy an empty file.  Why is that an error as opposed to copying the empty file?
    4. My hard drive is not reliable - is there any way to have it keep retrying sectors some number of times before giving up with an error?

    Thanks again for the awesome tools!

     

    It does indeed copy one sector at a time. I do plan to address that at some point.

     

    There is no way to change these behaviors without modifying the software. I don't have bad hard drives to test against, or any hard drives to test against... so I'm not going to implement anything to deal with retries. I have no way of testing that my code would work. If you want to submit a Pull Request in Github, I would entertain it. 

     

    I have been revamping the memory model, and am in a position to apply more memory to the file copy issue... I don't have any spinny disks, or things that seek, so I never noticed this overhead... it will be some weird balance, between seek time, and duplicate memory copying. Does anyone know the magic number of sectors that pays for a seek? Hmm. maybe 2 sectors at a time cuts seeks in half? 4 reduces seeks to 25%. Once you are doing any copying from VDP to RAM, you are doing that twice per sector anyway... Right now, I don't have to copy the sector out of VDP and back in, and it is optimal for my seekless drives. 

     

    Regarding empty files... You can have empty files? like... 0 sector files? I assumed that's an error state. 

     

  15. Posted

    If it is BASIC that you are messing with, you can open the source files in the TIPI browser UI. 

     

    Or, you can use a properly named PC text file and just let the TIPI transform it to BASIC when loading. This takes discipline though, which can be remarkably hard in the face of 35 year old habits.

     

     

  16. Posted

    Uh, yep, I cloned the source, but the installation script doesn't build it if the 'directory' is there, instead of checking for the executable. So I'll need to fix the update script... and build new base images. 

     

    In the mean time, you can ssh into the PI as user tipi and run:

      

    sudo /home/tipi/tipi/setup/printing_setup.sh

     

    After that, your PI.PIO printing pleasantries should proceed to produce. No reboot required.

     

    This will take a while on slower devices. There are some 80-ish 3rd party packages required that it will fetch and download, and then compile the epson converter. I will craft the update fix in a way that this will not repeat if you have done it already.

    • Like 2

  18. Posted

    13 hours ago, Omega-TI said:

    Future Feature Request for Force Command

    (Once you start taking them of course)

     

    CALL SAY filename  - A method for playing short voice files from the command prompt or embedded into scripts.

     

    1) Storage space for sound files on a TIPI system is not a problem, as there can quite literally be gigabytes of unused space on an SD card.

    2) I propose by default all sound files reside in a TIPI.AUDIO. subdirectory for organizational neatness.

     

    A PC based program to easily record and save the audio files would be necessary.  Naturally once a recording program such as this is developed, it would not be limited to Force Command, I'm pretty sure people would start adding their own sounds into games or other programs a well leading to an explosion of new programs.

     

    As for the coding of such sound files, that is up for grabs.  I know this is probably a "chicken and egg endeavour", but I bet our resident audio guru could release a "new standard" that could easily be adopted by the entire community.

    Counter proposal:

     

    Part 1: I release the API, and then anyone who has a favorite sound format and the will, can write a command to play sounds from whatever storage they want organized however they want. There can even be multiple players. The command could take the full path or a relative path to the sound file to play. Then if people want to organize them differently, they can. There is no reason for it to make assumptions about a TIPI being present.  

     

    Part 2: Anything named 'SAY' remains specifically about speech on the 4A, and not generically sound.

     

    ---------

     

    This reminds me, CALL will probably go away, now that I've implemented PATH searching. I will more likely detect if the file is a PROGRAM image and treat it as a command, or if it is a DV/80, treat it like a script.

    • Like 3

  19. Posted

    3 hours ago, Keneg said:

    Ok, I think I understand that.  I will try it and see how well it works.  Thanks for the information.

     

    You can also write code to change the configs using simple high level file record writing routines. Or use "Force Command" to create 'batch' files to configure things before loading the 'thing you are going to do' cartridge in the FinalGROM99... 

    • Like 1

  20. Posted

    Update 2.7 - Fix the DSK unpacking problem with rolling volume_name to dirname 

     

    This was a victim of the python3 upgrade.

     

    This is a light update, ( if you are current ) python code is fetched, services are restarted, nothing is 'rebuilt' and no dependencies are updated.

    • Like 3
    • Thanks 1

  21. Posted

    Took me a while to understand your point, as I was stuck on "but aren't those pattern definition spots overlapping with memory used for something else..." 

    The patterns may be garbage from a character definition point of view, but as you instruct, if the foreground and background are the same, the pattern is invisible, and they can then be used as solid blocks. 

     

    That's cool.

    • Like 2

  23. Posted

    57 minutes ago, webdeck said:

    I figured out an issue I was having when uploading a number of .dsk images using the web UI.  I was puzzled why some of them would not be recognized as proper disk images.  Apparently, the issue was that they had the same disk name as an existing directory.  I see that when that happens the first time, the second directory gets named with an _1, but if there is already a _1 version, then it silently fails.  Would it be possible to have it keep incrementing the number?  Otherwise, I need to ssh in and rename the conflicting directory and re-upload the .dsk image.

     

    It is supposed to find the next number automatically.. but I guess that is broken. 

     

  24. Posted

    Many era-similar systems use the same simple memory mapped mapper latch for bank switching a small address space. The difference is that all the ones I've seen are smart enough to put that mechanism as the last address of the bank, instead of the first. By being the last.. it isn't in the way of platform headers for ROMs etc... 

     

    Just map an 8 bit latch to 7FFF, or a 16 bit latch to 7FFE-7FFF, and keep it simple... Yes, that means your banks aren't 8k, they are 8k - 1 byte. But when writing code that runs from bank switched memory, this is not an actual issue. For data streams, it is a bit more of an issue, but your writing custom code to copy in or out of them... so it is easy enough to navigate around.

     

    Bam, tons of memory... 

  25. Posted

    23 hours ago, retroclouds said:

    Thanks.

     

    I’d like to integrate my Stevie Editor in FC, so I’ll be taking a close look at this.

     

    The thing is that Stevie is a cartridge image itself with multiple banks and using most of the 32K memory space and some SAMS banks. Having said that, don’t see this as being impossible, guess it’s a matter of setting up the proper environment on startup and doing a proper exit.

     

    Well, there is only one cartridge in the system at a time, but FG99 does allow switching which cartridge that is. 

     

    Could write a ForceCommand launcher program that uses the FG99 features to bounce to another cartridge. The launcher could take the parameters, and stuff them in a mailbox in memory that Stevie would look for. Stevie, would consume the mailbox, and then mark(erase) it so it knows not to use it again, until unmarked. Stevie could then bounce back to ForceCommand by switching cartridges again.  I've thought about adding a feature in ForceCommand if TIPI is present, to use TIPI storage as a mailbox for returning to the same directory... 

     

    • Like 3
AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...