jedimatt42

Just a reminder, there is a password required now, so if you didn't already get a PM from me, you'll need to PM me or get it from a friend...

One would have to update https://github.com/jedimatt42/tipi/blob/master/services/ti_files/CatalogFile.py to recognize some other open mode or record length or whatever the extension was. And then provide the alternative record encoding.

The answer to a few of these questions is that it is only version 0.something. There is a roadmap many posts back... Give it a year.

Sorry, yes, the FG99 command doesn't know the entry point of your cartridge, so it just resets the console after instructing the FG99 to load the bin. I haven't been ambitious enough yet to scan the cartridge headers after the FG99 has loaded it... to determine the target address myself. XB, requires you to set XBADDR (or defaults ot the value for TI Extended BASIC v110) and that is why it is able to launch right into XB.

Found a nice bug in command line parsing last night... for now, keep you arguments down to 40 characters and you shouldn't have any trouble. That includes in scripts. Of course I'm neck deep in refactorings that touched every source file, so no ETA on when I'll publish that fix. I've changed the screen output routines to remain in ROM. A step towards getting my memory map under control so that API can have room to be used. The refactoring helped me shake this out of the tree. Found while trying to get a script like this, which should already work, to behave correctly: TIPIMAP URI1. HTTP://big-log-uri-to-weather.gov/with/some/long/path/to/plain/text/files TYPE URI1.KPDX.TXT or TYPE PI.HTTP://the-really-long-url.com/directly/I_m_too_lazy_to_find_the_real_example/hahaha/LOL.TXT

Of course there is no reason why a Future version of Force Command can't... It just doesn't at this time. And there are hundreds of hours of development planned ahead of such things. You could write a full multitasking windowed operating system on the 4A architecture given even just the added code storage of today's cartridges. The Geneve was full of tech demos that showed how possible it was. There really isn't anything special about the 8086 architecture except speed and popularity. All theoretical questions about vaporware are answered with 'yes, sure it is possible'. Until you qualify the goal with specifics about performance and/or engineering time constraints. Speculating without intent to write the code yourself is just hot air. I have already shared a roadmap that includes SAMS.

You just have to do step 1 on this page: https://github.com/jedimatt42/tipi/blob/master/emulation/README.md but then it won't talk to your hardware again until you delete the file.

It is the lack of mentioning the actual goal that makes this approach to 'questioning' read like an agressive manipulation. More than likely the goals you have in mind can be accomplished with far simpler mechanisms.

You don't need SAMS unless you are talking about a large program. and you haven't talked about any program at all... so it is really impossible to answer this non-question, except to say 'no'. you can't do that with Force Command as it is, because it owns the machine and doesn't allow anything to hook in anywhere to do anything. My posterior has a lot of opinions about the form of your question. Maybe if you tried again with an actual stated goal... instead of a mechanism.

redacted...

Password length limits are kind of low.. 10 characters... You all are just going to have to PM me for the password. Link in first post are updated.

I store the originally cartridge games on the FG99. I store the originally disk and cartridge to disk conversions on the TIPI. In my ideal world, I would canonicalized the sets so cartridge->disk->cartridge conversions no longer exist in that mix. But, they are pretty much just stored... Going back to the eighties, I rarely play games.

So I've discovered 2 things. 1. I increased my own copy of Force Command to 128k, and now I need to extend the delay between telling the FG99 to load it, and actually starting the cartridge. The FG99 wasn't meant to be used this way.. 2. I'm not reproducing the problem... My PI is always on... I'll return this bug to sender... you can compare on your TIPIPEB system.. or independently powered PI Zero W.

I'm going a bit off topic, but, I measured the PI Zero W USB power consumption today... It sits idle at 180mah. I saw it peek at 230mah... during boot up. I don't know the quality of this device, or the sample rate... etc... but that + about 100mah (depending on the version of my 32K, don't know about J-Data's, should be less) of TIPI+32k on the sideport... == 330mah... Texas Instruments rated the +5V there for just 50mah. There are configuration things you are supposed to be able to do to save power, but I don't measure any power savings... If it doesn't prove to be a reproducible software thing, you'll be asked to unplug your mouse, test, plug it back in, use external power, test... etc... But that would really be a topic for the TIPI-in-speech thread.

I just wanted to be able to reproduce your scenario exactly... RXB 2015E, is that correct? RXB challenges me in that I don't understand how to determine the latest available release.

So, it shows NO PROGRAM Hard to tell. Probably inbetween 2 and 3.. I'll have to see what RUN does when a bad file name is specified. Maybe sometimes FC is specifying it corruptly. I can't tell the answer to this from your video, @Omega-TI

Well, at least we have a video of the expected behavior!

It gets into XB, but says 'SYNTAX ERROR' Can you do LIST? It appears to have launched over in XB.. Force Command doesn't have the error message 'Syntax Error' anywhere, and the font has changed, and you've gone from 80 column to 32 column mode. So something is wrong with the XB program it loaded.. the Force Command 'XB' actually travels through 3 programs. 1. TIPI.FC.LOAD 2. TIPI.FC.FC/XB 3. your target program Did it get stuck in 1, the program you showed us you had modified the other day. Did it get stuck in 2, the program written on the fly by Force Command Or did it make it into 3, your program? Oh, and we'll need to know which XB you are running, and what your Force Command environment variable XBADDR was set to.

Here is a the little XB program that you can launch from within any XB with a RUN command and the literal path, that will cause FinalGROM99 to relaunch Force Command. FCMDXB It is 100% the exact same source code as the EA5 tool I provided earlier. But it was built with the --embed-xb option from @ralphb's xas99 cross assembler, instead of the -i option. Woot It'll be in the FC directory with future releases of Force Command... You can place that on your TIPI, in the TIPI.FC. folder and then from any XB program you want to facilitate a return to Force Command option from, you can add a line with this statement: RUN "TIPI.FC.FCMDXB" @Omega-TI - sorry I'm such an jerk sometimes. And I hope this makes up for it a bit.

Hopefully with the intermittent issues out of the way, we will be back to stable.

The SD card image is also now available: https://www.jedimatt42.com/downloads.html

TIPI PI software 2.5 - 2020-07-12 - Fix PI Zero W communications issues ( often manifested as the crubase 2000 issue ) - This has been tested by @PeteE ( who fixed the issue ) @arcadeshopper and @J-Data ( I tested it too, but I don't count ) - Fix SNEK high score sync issues - some TipiVariables messages are not ascii, but latin1 - Finally correctly fixed unicode file names from the host-os.. ( correct : it shouldn't crash for anyone, and the author agrees with the behavior ) - still uses the '`' + crc15 suffix, but the entire unicode name is fed into the crc now, and the 6 character prefix coming from the unicode file name is romanized to single byte characters... using a python library called unidecode. - applies to any host os file name that has a character requiring more than one byte to represent in utf-8, or with a name longer than 10 ascii characters. A new SD Image will be released in a bit... If you are on a PI Zero W, and it works well enough to trigger the upgrade process, then it should get you fixed. If not, you can ssh in as user tipi, and: sudo /home/tipi/tipi/setup/upgrade.sh --upgrade

My SAMS based heap and stack management doesn't exist yet... it's be like a standard C malloc library... with a management function to add or release pages into the heap. Moving the gcc stack into SAMS would slow things down quite a bit... as you'd have to replace all the mov blah,*r10+ to not do the + and then do bank boundary checking... Since the eco-system I'm thinking of has a gcc base system, that then loads overlays, it could gain usable memory without performance issues, by just paging the stack out completely when initializing an overlay. That way the overlay can choose how the address space is divided between stack and heap.

I think you have to write new software anyway.. the existing software doesn't need SAMS.

We already have TurboForth, that includes a module to naturally program in forth and just have your code load into extended banks of SAMS. You have to specify the banks, but you don't have to write the code very differently. Then there is the way I write GCC C code for banked switch cartridge space... I will eventually abstract that to SAMS, along with sams based heap and stack management. This will probably fold into what I do in force command when I get to supporting overlay programs.