jedimatt42

I'll fix it today.

Fred's EA II has his linking loader for option 3, the editor and assemblers in ROM, and he says he rewrote the loader, but it isn't clear from his page if that is just the EA3 linking loader, or the option 5 loader. For any contemporary software, I would just grab the latest and re-test. I believe his EA V has his debugger and improved editors as well built into the ROM.

aH... EA II ... so is it fixed in Fred's EA V r6 ? and we can ignore it I admit I tested with an TI EA GROM.

maybe there is some hint in the /var/log/tipi/tipi.log if you can capture that when the EA5 from EA is failing? we can see if TIPI is interferring... It should say something like 'skipping' and then things go on to the floppy controller... Which floppy controller BTW?

I forgot press 'BUMP' the other day... so better late than never... bump. Today at 3 Pacific.

Released 1.11, see post #1

for consideration, "TIPI." is unit 0 on the python side of lvl2 operations, wouldn't "TIP1." cause more problems with other conventions? "DSK1." is unit 1 on the TIPI python side.

But from a system architecture point of view this request is distributing the solution to all software instances, instead of accepting the existing... what is it? F5 instead of <enter> option to run in a compatible mode. Or stepping up and building a generalized solution to a problem that can be centralized. Someone could write an EA5 Loader that is an EA5 loadable program, that maps the DSR space in, then loads the binaries, and runs... Or.. another that loads the binaries, then maps the DSR space in, and then runs... These things can have some big ol' hex-editable string at the end with the path to , or someone could write a program that creates customized instances of it to load your ROMPAGE requiring programs... (Like the scratchpad loader, for instance, or as a starting place) You could also improve BOOT or whatever it is called when run on the Geneve, to have such an option built into its EA5 loading functionality.. Or a sub-boot, that does this for all things it loads, so ROMPAGE requiring stuff sits on a sub-menu... or write a new menu.. Any of those solutions would be FAR more enabling. --- And if anyone is looking at me like : "You have a Geneve, why don't you do this?" - I just can't figure out why I would want to turn it on, and I have spent a great deal of effort trying.

I just loaded DSK1.DM2K from my FlashFloppy-Gotek via EA5 ( from original EA grom in a supercart ) - TIPI is in system, DSK1 is not mapped. (and with DSK1. mapped, it still worked, as when LVL3 ops can't find the file, TIPI allows it to run down the chain. ) Do you have a crubase conflict with the TIPI and the Floppy controller?

Weird, and relevant let me check.

Programs that just use the TIPI messaging system (for mouse, or TCP communications) activate the TIPI DSR, and do stuff, but often don't do actual file IO. Then you get to this hybrid mode where the app doesn't work cause it does do file IO, and the user has to understand they can only use ROMPAGE compatible storage... they have a TIPI in this case, so that's not a blocker... but you wouldn't expect it if you didn't enter ROMPAGE mode. @arcadeshopper, I would have thought EXEC /R option would be good, but it doesn't actually set up much of a 4A environment... No system ROMs or GPL... so only good for 4A EA5's that are completely self contained (have their own DSR code, own font, etc... ) - maybe 70% (made up stat) of the EA5's out there are like that. Setting graphics mode or text mode and loading the character set using gcc+libti99 copies from the console GROMs, so those programs don't work well in EXEC... Again... if a Geneve wants to run 4A code, it should make the effort. It wouldn't be hard to individual Geneve owners to patch these binaries themselves... learn a little machine code. learn a little about the EA5 format... Bob's your uncle... But it isn't reasonable to ask this of 4A developers. On a 4A, 8002 is high byte of R1 if your workspace pointer is 8300. So if you are developing in anything other than assembly, and aren't careful it is pretty easy for this to just crash your program on a 4A.. You do have to coerce it into nearly the first instructions for it to be benign on a 4A.

NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO... Holy ... NO Now, this is one of the many things that rubs me the wrong way about the Geneve... users expectation that software for a 4A should be written for a Geneve... You can't expect people to put 1 instruction in their code for a machine they don't have... That is ridiculous. You should build a shim EA5 loader for the Geneve that does this for you to load any program you want in this mode... instead of making 4A programs adapt to the non-4a-compatible mode of the Geneve. Absolutely Ridiculous. Take responsibility for your own platforms incompatibility.

I dug up the tandy 1000 HX DOS manual, and the example PROMPT setting they provide is $p$g which is path > I haven't spent much time at a MS-DOS prompt since 1992. Anyway, yesterday I wrote the PROMPT environment variable feature... and barrowed some codes from the MS-DOS manual. (DOS uses $ for these codes. I use \ because I use $ for variable references, and am not going back to %var%) \c - crubase followed by a '.' \p - drive and directory (includes trailing '.') \b - backspace \g - greater than symbol '>' (this is escaped in MS-DOS cause they support redirects... maybe someday I will too) \n - new line \r - pipe '|' (cause MS-DOS supports process redirects... maybe late 2021 for me) \s - space ' ' \t - 12 hour clock with am/pm (hint if you don't want the AM PM, use 2 backspaces) so you can PROMPT=\p\g if you like. If you really have trouble remembering your name, you can add that too (just kidding.. it has significance on multi-user systems): [email protected] \p\g Notice, I didn't use \s for the space here... it isn't necessary the way I process the input unless you want a trailing space... I personally think \p\g looks too packed... so I like a trailing space. --- Of course, now that you can hide what your working directory is, I have to add a command that prints the working directory... PWD --- and cut-n-paste some of this post into the Force Command wiki.

Note, with PI.CONFIG, you don't have to write all the records... it's actually a key-value map, and only records written are modified. Other records are preserved. So, you can OPEN, just WRITE an entry (or a few), and CLOSE.

Get to Force Command 2.0 with the API documented. Take up Forth again. Write a game. Finish a personal hardware project I started prototyping back in 2017.

I have logged the issue, so if I'm looking for something to do, I'll find it: https://github.com/jedimatt42/tipi/issues/143

I should apologize, my response was unnecessary. I did not think you were asking for anything like title screen banners I dislike, but I put up a wall to explain my boundaries on this to the general population. Regarding recognizing the speech synthesizer... I hope to expose something eventually that utilizes it.

Yep. Those aren't real files. So they implement a minimum feature set. Just read records until it errors. Then close.

Update 2.14 - 2020-12-19 - Fixed record creation when seeking beyond existing high record.

Well, that's a bug My FixedRecord code is creating a new record, and assigning that same instance into all the record slots, and writing a new value to a record is copying bytes into that object instead of replacing that object... fun stuff... I think you want to see this result: 00000000 07 54 49 46 49 4c 45 53 00 0b 00 03 50 50 1f 00 |.TIFILES....PP..| 00000010 42 4c 4f 42 20 20 20 20 20 20 00 00 00 00 00 00 |BLOB ......| 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000080 52 45 43 4f 52 44 20 5a 45 52 4f 21 20 20 20 20 |RECORD ZERO! | 00000090 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 | | * 000000d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 000008d0 52 45 43 4f 52 44 20 32 35 21 20 20 20 20 20 20 |RECORD 25! | 000008e0 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 | | * 00000920 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000a80 52 45 43 4f 52 44 20 33 30 21 20 20 20 20 20 20 |RECORD 30! | 00000a90 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 | | * 00000ad0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000b80 A new TIPI update will be coming... in a bit.

I really only imagined displaying things in my sysinfo command that influence the behavior of Force Command itself.. such as VDP type, and CPU memory. An external command could be written by someone using the API to more deeply analyze each potential piece of hardware and try to display it by brand or something... Like ROS does. I personally don't agree with all the expansion things that urinate on the TI title screen, just to show they exist. So I would never want that to be a default behavior in Force Command either.

The 3 tone beep does not happen if an AUTOCMD is found on the first device. AUTOCMD is like an AUTOEXEC.BAT $ was chosen cause I spend all my time at a bash prompt. It isn't bash, it isn't MSDOS, l should probably change it to a something unique. I do imagine adding a SYSINFO command that would display some detected system summary.

Keep in mind, there is also English -> English translation going on when I read this stuff... It's not like any of the 80s era manuals tell you 'this is how it should be', they are full of 'here's an option' and 'here's an option' and oh, if you use option 3, it behaves differently if you use the card this manual wasn't written for... or something... So someone who never touched this stuff, and doesn't have the ability to do so, trying to understand how the 'system' works requires synthesizing a mental model of the system. ( in 15 minutes or less cause this was just a misguided effort to determine if the system is PAL or NTSC for what turned out to be something I didn't want to use. ) Manuals originating in the language I'm supposed to call my 'native language' probably would have led me to the same difficulty.

TIPI returns whatever is in the record length field of the TIFILES regardless of if it is a PROGRAM file or record type file. Typically that value is already 0.

The TI filesystem specification requires that a device return the file entries in the CATALOG file in sorted ascending order. It is case sensitive. So, 'Z' comes before 'a'. TIPI should already be respecting that.