jedimatt42

My intention is I'll update the links to not contain the embedded password, require the lobby, and I'll manually set the password to some random + a term we know... so it can't just be web-scraped. Then I'll share the random part with you all.. and share the TI trivia question that contains the piece you need to know...

@globeron - so far you cannot use TIPI with MDOS on a Geneve. You can use it in ROMPAGE mode only in GPL... none of my other storage devices work in ROMPAGE, so I cannot transfer files to MDOS through TIPI.. You mileage will vary, depending on what storage devices you have in your Geneve. --- Splitter's should work fine with sideport TIPIs. I tested most of my TIPI PEB compatibility using a sideport TIPI with a PEB connected downstream. Using this adapter: https://oshpark.com/projects/7y5ux27q You solder a female-right-angle-2.54mm header connector in, and then this can connect to the right hand header pins on the TIPI board. The PEB 'boot' can connect to it. The edge connector is a little narrow, so you have to make sure it is lined up well in the 'boot' (the flex cable end that plugs into the 4A) ( Someone could refine this design to fit more correctly - I designed it for myself, and it was a 1 and done sort of thing )

@globeron I wouldn't expect it to have ever worked. The copy command needs to know that TIPI. is unit # 0. You can assign any TIPI DSK1-4 to '.' and it will be the same as 'TIPI.', or you can try 'DSK0.' which is always an alias for 'TIPI.'

For Omega's purposes, TIPI.FC.LOAD could just be 1 RUN "TIPI.WEATHER80.WEATHER" Using older features of Force Command, a script could also have been used, but you don't get the auto-jump into GROM of XB.. In this case, that TIPI.WEATHER80 directory could contain a program like the 1 liner above called TIPI.WEATHER80.LOAD Then the Force Command script would look like: TIPIMAP DSK1 TIPI.WEATHER80 FG99 TIXB_G But, you still have to tap the 2 button a couple times to get the weather program in this case.

Sorry, that is what I meant by my typo... should have read 'does NOT seem to be a problem' I'm on windows 10 - 64 bit... Running the browser on the same system... I've only tried google-chrome..

I get the bad register message too, does seem to be a problem

The ports, and purpose are as follows: 9900 is the TIPI webui, you HTTP to it. 9901 ( I just heard PeteE say ) is the websocket... 9922 is forwarded the the SSHD inside the emulated Pi, you ssh to it. If you telnet to 9900, it should just stare at you blankly until you submit an HTTP request - this is different than getting a connection failure... I would expect the 9901 port to also accept your telnet connection, but then just stare at you until you send something meaningful to it. It also does not speak the telnet protocol. 9922 sounds like it is working perfectly by your description. ---- (This isn't setup or configuration, just a confidence/verification dance) Login to the emulated TIPI, there should be a login prompt on the QEMU window.. Then tail -F /var/log/tipi/tipi.log Refresh the browser page for js99er.net - Wait a bit.. give it a minute... Observe the log, it may show a new round of TIPI READY, if the TI Title screen is showing up. Press the js99er RESET button. Wait a few seconds, and observe the log? It should show a new TIPI READY message, and the TI Title screen should come up. When you have TIPI enabled in js99er, the 4A emulation is blocked until it establishes a connection with the PI emulation on the websocket ( port 9901 ) - this can be intermittent when QEMU and the OS running inside is busy getting warmed up.. It'll act like js99er is locked up... just wait... Then, you should be able to go to BASIC, and run CALL TIPI. It should load the usual status and configuration details.

Because you constantly state that you are not a programmer, I have to assume you do NOT intend to work on these things you throw out there. I was not trying to discourage the goal or you. I had no idea you intended to work on the goal. I was trying to encourage the implementer to reach.

Great, I've given you a hammer, and now you want to bang on everything with it. It would be soooo much nicer to assert what a fun little project it would be to write a 80 column mode weather update program... Isn't there TX80T basic extensions? and the forths? and assembly? and gcc? You can still use LVL3 file IO routines to get the data from a website if you don't want to drop to the TIPI messaging level. There will someday be a wget/curl like command for Force Command. Then a hacky web-scraping thing can be assembled with just Force Command scripting. but wouldn't it be cooler to have a program that parses the data, and displays it in a more purposeful way? Something that remembers your location or places of interest in a data file. Separates the sections of the report into 'tabs' to switch between, so you don't have to scroll through all of it. Maybe refreshes every 15 minutes if it is still running... ^--- I really hate seeing this as the premise of any post... many of us are here to try to do things that are not easy.

That is an undue burden to place on games. There are systemic ways to achieve that like the one we discussed on Sunday.

That isn't the sort of thing that should be baked into games.

I don't know what people use on windows to create images of SD cards... Lots of tools to burn an image.. I use the really old dd command from unix to create my images. You might get mislead searching for creating an ISO. You just want to create an image of the sd card. Here, a little let me google that for you: https://thepihut.com/blogs/raspberry-pi-tutorials/17789160-backing-up-and-restoring-your-raspberry-pis-sd-card I guess now I know.

I missed the SNEK high score issue... I'll have to try that... I'm assuming a snowflake feature missed by the python3 conversion.

@Omega-TI , as such a Force Command advocate, why are you running TIPICFG regularly? The only thing you should need it for is 'U'pdate...

Just a summary: It isn't the upgrade process - failure occurs for upgrades as well as fresh SD card users It isn't drive the hardware nuts and actually changing CRUBASE - that was just a reporting error in TIPICFG It only manifests for PI Zero W users. It isn't isolated to the combination 32K/TIPI as we have 1 user on a TipiPEB. It is not all PI Zero W users - 2 users report it works fine - both with the older sideport TIPI. It isn't obviously power, as reporting users suggest they have Raspberry PI Org approved power supplies. @arcadeshopper reported seeing the problem on his 32K/TIPI system. We will likely also need a volunteer in the broken state to co-test any potential fixes. My strategy would start with a quest to eliminate any unnecessary services inherited from the operating system distribution. I have no idea how long this will take without hands on the problem.

So, the CRUBASE isn't actually changing... the code in TIPICFG that gets the crubase, opens a file using normal means and uses the side effect that R12 will be left at the crubase value after it succeeds. If the PI is flaking out, it might return to the TIPI DSR a 'skip' result code, and the DSRLNK will move on to see if other cards can handle the file request. If none handle it, then R12 holds 0x2000. I should fix TIPICFG to report the earlier error.

@BeeryMiller do you have something else running on your PC using those ports?

I was able to reproduce some flaky behavior for a bit when the PI first powers up... while the cpu load was over 100% After it settled down, it behaves fine for me... -- are the PI's being separately powered? During power up the power draw can be higher than normal also, and PI's operate erratically when under-powered. There might be things we can do to make the powered from 4A experience more viable... you can turn off WIFI, and take care to stop more services that we aren't actually using... I didn't prune down the Raspbian at all... as there wasn't a need... normally a PI Zero W should run at around 30% cpu load ( buster days )

If you update from 1.61 image, it will say the 1.65 update is available, but it will apply the 2.4 update.

If someone with the problem can make an image of their failing SD card available to me, I might be able to see what's going on. I reviewed the TIPICFG code, and crubase 2000 is a side effect of failing to read the PI.STATUS, and continuing to look for the file down the crubase line... I have tested PI Zero W, and had not had the problem...

Blanking out and mispelling a word doesn't change the fact that you said it... I do this for free. MIND YOURSELF!

Nothing on the SD card should be capable of affecting the CRUBASE discovered by TIPICFG... Nothing... Something else is changing physically... Those that have received this error have not recovered by starting fresh with a new SD card...

I've added this example to the Force Command wiki... which received a complete overhaul yesterday... https://github.com/jedimatt42/fcmd/wiki/Commands#copy-files

Also the same wildcard code is used for DIR, so you can test your pattern before committing to copy...

Also, you cannot have a period in a TI file name as that is the device and directory separator.