Stuart

If you look at the code at http://www.stuartconner.me.uk/ti/ti.htm#tipi_network_socket_interface, starting at the line before label ISDSR, that steps through the CRU space looking for the TIPI DSR. Should be relatively easy to adapt code for what you're after.

Wasn't there some sort of problem with CF7 and F18A due to the F18A taking longer to initialise itself at power on than the original VDP? Can't remember the details, and might be completely wrong!

1N914 and 1N4148 are silicon diodes with a larger forward voltage drop than the germanium 1N34A. May be significant if they're in the battery backup circuit.

I've got as far as copying and cleaning up a copy of the browser code ready to add in the TIPI stuff, but unfortunately 'life' is getting in the way of any further progress as the moment.

I did think about including some sort of file download functionality, but the problem is that each new feature reduces the size of web page that can be downloaded and displayed. So the only practical way to do it would be some sort of code overlay facility, where the browser loads some overlay code to handle file downloads, and that then reloads the browser code when the file download is complete. And that gets very time consuming to do when trying to support disk- and cartridge-based version of the browser. One day maybe ...

Have you got CTS wired correctly in the cable? CTS needs to be active in order to transmit.

Thanks Matt. My code is here (http://www.stuartconner.me.uk/ti/ti.htm#tipi_network_socket_interface), should anyone find it useful in the future. Now to incorporate it into my TI Browser ...

Unless of course you're a Technical Writer …

I've now got a working example of using the TIPI socket interface to download a web page (and big thanks to Omega for testing many iterations of the code on his TIPI setup). I have a query though over opening a socket to an invalid host ... I've (temporarily) set up the TIPI calls so the 'open socket' command is to an invalid host, and the 'write socket' command is an HTTP GET request to a valid host and a valid web page. I was expecting the open socket command to fail, but it succeeds, and the response to the GET request is a valid page with a 'refresh' link to a page at http://webhelper/centurylink.com. So I'm wondering if: (1) Whether the open socket command always reports as succeeding (that is, the command itself was processed successfully even though the specified host was invalid). or (2) Omega's ISP is intercepting the open socket request, reporting it as OK, and redirecting further requests to this webhelper page. Any ideas?

There are a couple of programs that restore Desktop Gadget functionality to Windows 10 (although I'll point out that gadgets were dropped because some were deemed to be a security risk, as you probably know). I use a program (installer) called "DesktopGadgetsRevived-2.0.exe", which you can download through http://www.mediafire.com/download/jbbgksdbqsble9p/DesktopGadgetsInstaller.zip. Works fine for the couple of gadgets I use (clock, CPU meter, Network Meter). The only drawback is that some of the 'big' Windows 10 updates disable it, so you've got to uninstall it and re-install it (so keep a copy of the installer exe).

Thanks Matt. Polling for read data - do I need to: send read command do receive message and check length send read command do receive message and check length send read command do receive message and check length etc. or send read command do receive message and check length do receive message and check length do receive message and check length do receive message and check length etc. When receiving a web page that could be several kilobytes, is there any guarantee that I'll receive it all through the one read? Or once I've got data, do I need to do multiple reads (adding any further data to my buffer) until a read returns a length of zero?

Thanks Beery. How did you go about checking if there was data ready to be read?

Matt, a couple of questions as I haven't got a TIPI to test against. (1) The open socket command. -- Can I assume that if the specified host does not exist, the open socket command returns a value 0 'failed to connect'? -- The command accepts text and dotted-decimal host addresses (www.bbc.co.uk and 12.456.789.1)? -- I do a MOV @SENDMSG,R4 and BL *R4 to send the message (after setting up R0 and R1). How quickly after that does the Pi have the return value available? Can I immediately prepare R0 and R1 and call the RECVMSG routine? Does the receive routine block until the send command has completed? Or do I need to faff around changing the workspace and resetting/setting the CRU bit to give time for the send command to complete? -- If I don't 'receive' the return value (for any open/close/write command), does that cause any problem with the next command? (2) The write command. An HTTP GET request comprises multiple lines, each terminated with a >0D >0A. Can these be sent as separate, multiple write commands, followed by a read command for the response? Or does the GET request have to be a single write command? (3) The read command. After writing an HTTP GET request, do I need to send a read command and check the length returned in GPLWS R0, and loop (need to repeatedly send the read command, or just call RECVMSG?) until this is greater than zero? Thanks!

Thanks all. I'll start again!

Well yes, that's a question, and what I was hoping to find clear documentation for! What I'm trying to do is reproduce what's in the video here (TIPI Does TCP - https://www.youtube.com/watch?v=VpYcPHIbxU4) in assembler. That video shows (in BASIC) opening the device TIPI.TCP. So that's what I've tried doing (opening the device TIPI.TCP=WWW.CWFK.NET:80) using the standard PAB and DSRLNK call, and checking the equal bit in the status error to check if the DSRLNK completed successfully or not. So am I on the right track (although it seems to be failing) or do I need a different approach?

Thanks all. Tursi's suggestion of loading the file in the E/A Editor in Classic99 then saving it again under a different filename did the trick!

I'm trying to get a small E/A 3 object file to Omega to test. I'm assembling it using Asm994a and I can load and run it fine using Classic99. I tried sending a copy of this file to Omega to test; Omega copies the file from his PC to the TIPI with the TIPI's browser based transfer routine, like he does with other files. He tries to load it using E/A but gets I/O error 2. Omega sends me an E/A 3 file which works for him for me to look at. It looks like it has a TI files(?) header on it. So I take my object file and use the Ti99Dir program "Convert PC File to TI File" command to convert the file, using the options file type "DIS/FIX", record length 80, "Remove CR and/or LF (EDITOR/ASM)". Omega isn't able to load this file either. I've attached a copy of this file. What do I need to do to get the E/A 3 file to work? TIPI.zip

You might want to try a vial of the conductive paint sold to repair the demister elements on a car rear windscreen, applied using a sharpened cocktail stick.

The LVC245A - isn't that rated for operating up to 3.6V? Will it reliably drive the 5V TTL TI-99 bus? Have you got a circuit diagram? I don't understand where the pull-up resistor is. If its on the RDBENA* output from the card, then I'm not sure it is needed as there's a pull-up resistor in the flex cable circuit.

If you get an I2C thermometer such as https://learn.adafruit.com/adafruit-mcp9808-precision-i2c-temperature-sensor-guide/overview, you could interface it through the joystick port using the circuit and adapting the (assembler) code here: http://www.stuartconner.me.uk/ti/ti.htm#i2c_interface.

Any of the chips getting particularly hot? Can you use MiniMem EasyBug to examine a couple of memory locations - is it just a small number of bits failing in each byte, or failing completely?

Welcome. By all means replace the VDP as that is already socketed, but the 4116 RAMs are not likely to be causing the problem you have (assuming none of them are pulling the power supply voltages down). A couple of people with the beeping problem have found one of the MCM6810 RAMs to be bad - you might want to try replacing those first. Also make sure the pins on all the socketed chips are clean. Once you've got a picture, if it's corrupted, we got some diagrams somewhere to help you identify which of the 4116 RAMs is bad. The keyboard connector cable tends to go brittle with age and can break as you take the console apart. If you find some keys don't work, check for breaks in the connector cable. Some types of keyboard (TI used several) can be temperamental as well after not being used for years.

I'm hoping to do a TIPI version of the browser. I'm waiting for some decent documentation and example code on how to interface with the TIPI device in assembler ... not sure if Matt has got any further in producing anything yet.

Most likely something from the TI990 or DS990 ranges. Try a Google image search with those terms, see if anything looks familiar.

http://www.mainbyte.com/ti99/hardware/power_supply.html Scroll down below the photos.