jedimatt42

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.

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.

It just dawned on me that I control the implementation of TIPI, so while it never produces errors for good data, I could introduce random errors while trying to implement some retry logic in the Force Command copy read code.

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

Thanks, I was trying to go back and see what the actual usage situation was... I mis-remembered and thought it was an issue cataloging with empty files.. Anyway, I'll take a swing at that now!

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.

This would be good to know. Anybody?

I think it is perm-fixed for the future. Sorry about the mishap

I'll practice before next time this happens. [email protected]

Today at 11am pacific. I have set it up so you all can start without me. I may be late.

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 )

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.

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.

Ever since I had a rave keyboard back in the 80s, I've placed my 4A console on top of the PEB in normal orientation. Use one of those 'foot' extenders to tuck it under and behind.

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.

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.

I am aware. Just didn't perceive it as a priority.. more of a novelty feature to me. In diagnosing it just now, it looks like the conversion tool didn't compile during one of my image creations... hopefully just something I forgot to do/document

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.

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

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.

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.

Issue filed: https://github.com/jedimatt42/tipi/issues/142

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

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

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