TIPI - Geneve 9640 to Raspberry PI interface development

[+9640News]

3 hours ago, Omega-TI said:

Yeah no kidding!  I hope he posts the file that genetated it... and here is hoping it's not Geneve specific.

It's Geneve specific.

[+arcadeshopper]

Yeah no kidding!  I hope he posts the file that genetated it... and here is hoping it's not Geneve specific.

You're in a topic about writing software for the Geneve.

Sent from my LM-V600 using Tapatalk

[+jedimatt42]

6 hours ago, Omega-TI said:

Yeah no kidding!  I hope he posts the file that genetated it... and here is hoping it's not Geneve specific.

The Force Command (TI-99/4A) equivalent is 

 

TYPE PI.STATUS

and 

 

LOAD TIPI.TIPICFG

 

So, hopefully, nobody actually is in need of hoping...

[+InsaneMultitasker]

7 hours ago, Omega-TI said:

Yeah no kidding!  I hope he posts the file that genetated it... and here is hoping it's not Geneve specific.

I will post the program eventually however, it is Geneve-specific.  I wrote it to test Geneve's PI DSR support.  The program reads from the appropriate PI.file and checks the key values to determine whether or not an update is available.  If available, the user is given the option to initiate the update.  The other options are there to show PI.CONFIG and to initiate and/or wait for a restart/halt/update.

[Omega-TI]

On 12/24/2020 at 5:51 AM, BeeryMiller said:

It's Geneve specific.

[Omega-TI]

22 hours ago, arcadeshopper said:

You're in a topic about writing software for the Geneve.

Yeah, I see that now.  Sometimes I enter a forum at work using my cell phone during a break or on lunch, via the "latest activity" and get distracted, but from the timing of that post, I probably was not even totally conscious.

[+InsaneMultitasker]

While digging into a folder creation problem, I discovered what I believe is an undocumented status response that may be a unique extension used by Myarc.

 

The STATUS opcode (>09) is used to report file existence and if it exists, some basic file attributes. 

 

The Geneve also uses this opcode to report the directory status. It returns (via PAB offset SCNOFF) a value of  >54 [exists, protected, internal] when the directory is present. 

 

To address the immediate situation, when the Geneve TIPI DSR processes a status opcode, it tests two conditions before returning to the host: (1) Was a status requested for a Directory and (2) was the TIPI status byte returned as successful i.e., >00?  If both conditions are met, I return a status of >54.   

 

Myarc defined the structure extensions used by the HFDC, SCSI, IDE, etc. however there is no mention of a special Directory status that I can find in Myarc documentation nor in the GENREF DSR reference guide.  

 

I've noted this in the tracking log and will look for any other information for this undocumented 'extension' and status opcode usage.

 

@jedimatt42 and @F.G. Kaal ,  for your awareness.

 

[+InsaneMultitasker]

On 12/20/2020 at 2:11 PM, InsaneMultitasker said:

2. Level 3 implementation is about 95% complete, i.e., opcodes 0-9 (open,close,read,write,restore,load,save,delete,restore,status) function both in the Geneve OS and /4A modes.

3. Level 2 implementation is nearly complete for Geneve OS mode, i.e., direct input/output, protect, rename, create directory, delete directory.

Although further testing might coax a few bugs out of the woodwork, items #2 and #3 are now "complete".   For the remainder of the weekend we'll be digging into the /4A support code. 

 

It is likely that the final /4a support will be managed by the TIPI DSR EPROM via a pass-through mechanism (partially implemented in the MDOS 7.00 beta) to minimize OS interference.   The cons to this include the need to rework the DSR device table/code and extend the device mappings so the OS can properly determine where to send ambiguous device requests such as level two calls to unit #1. 

 

Beery and I discussed releasing a TIPI-specific beta soon while we work towards the integration of v6.70/7.00 enhancements into the code base.  More on that in the near future.

 

[+InsaneMultitasker]

I spent some time this evening poking at EXEC as I was curious about a problem posted in another topic (I think it was a TIPI topic but the issue isn't TIPI specific).

 

Anyway... Setting the character set involves these instructions: 

 

    gplvdp(0x004a, gPattern+0x300, 31);    // lower case letters
    gplvdp(0x0018, gPattern+0x100, 64);    // the rest of the character set (not shifted)
    vdpmemset(gPattern+(30*8), 0xfc, 8);    // cursor

 

The "challenge" for EXEC is that the character set data are being copied directly from GROM0 versus using a GPL function.  The former isn't possible because EXEC only mimics a GPL environment and only processes specific GPL instructions.  So the proposed work-around for EXEC is as follows: 

 

1. During startup, map in page >38 (GROM0) and check whether or not TI MODE is enabled.

    a. If enabled, go to step 2.

    b. If not enabled, save partial contents of page >38 (another task could have claimed the page for its own use)

2. Write the vector/table information for routines >4A and >18 in GROM0

3. Copy the character sets from MDOS to the two GROM0 table locations

4. Run EXEC and TI program as desired

5. Before exiting EXEC, check for TI Mode and if not enabled, restore the saved contents of page >38

 

I located my source for EXEC 2.4 though I haven't come across a few incremental fixes that I made later.  I've filed these steps for future implementation.

 

 

[+InsaneMultitasker]

Today I unexpectedly confirmed that the SCSI / MDOS 7.00 caching problem is more than an anomaly.  I need to enable some RS232 debug code to be certain but all signs point to not invalidating the cache before a write operation. 

 

The HFDC and Horizon Ramdisk hard drive code is seemingly unaffected, which actually makes sense since the cache is only used during SCSI IO.  What isn't clear to me is why this didn't show up in 6.70RC2...maybe the problem only shows up under certain conditions?  Once this is sorted out, we'll merge the 7.00 and 6.60 TIPI code bases for a test run. 

 

 

Fortunately, my TIPI/MDOS dev files live on a noisy ol' MFM drive that is backed up to TIPI. 

 

 

[+InsaneMultitasker]

Finally some good, hard evidence to track down the problem.  Excerpt from rs232 debug during a SCSI rename operation (sectors are 32-bit)

 

READ: 0000 0B04
READ: 0000 0B08  - FDR (file descriptor record) of the file we are renaming
WRITE: 0000 0448 - write the DDIR (directory index) with names re-sorted
READ: 0000 0B08  (cached)   - Ouch!  The read routine reported it used cache for FDR sector 0B08;  the write routine didn't invalidate the buffer!! The buffer contains 0448! 

(level 2 routine copies the new name into a buffer holding what it thinks is sector 0B08)
WRITE: 0000 0B08    - Sector 0448's information is written to sector 0B08 with a filename in bytes 0-9.

 

When I reviewed the disk sectors with SECTOR ONE, the saved data confirmed the log entries. With a bit of luck I'll resolve the problem tomorrow. 

[+InsaneMultitasker]

Corrections have been made to the OS cache routine.  In addition to invalidating the buffer after every write, the read routine now compares the sector number and the drive number before using the cache.  The latter ensures that a sector from one drive is not cached and read by another drive.  With a bit more memory, a dedicated cache is possible but that's a future problem/feature.   V7.00 SCSI sustained read speeds are now three times faster than v6.50. 

 

Much of the day was spent reviewing platters and platter backups with the hopes of confirming that the source Beery and I are working from is the latest, most stable v7.00.  It was very apparent that the SCSI cache issue was responsible for file corruption, as I witnessed the same corruption pattern on backups from 2018 and 2019.   I used   @mizapf 's TI Image Tool to check the file systems of the 'good' platters and was able to breathe a few sighs of relief. Barring any undetected bit-rot, I'm confident we are using the most recent source files for the next TIPI integration tasks.

 

Geneve OS 6.50 is not affected by the caching problem however, if you are using 6.70RC1 or 6.70RC2 or a v7.00 beta, you are strongly advised to revert to 6.50 for the time being.

 

(I'll start an OS development topic in the near future)

 

[globeron]

There was a MDOS program written back in the late 80's or early 90's that displays the Swan from the Swan eprom, same resolution.  I just searched for it on my BBS and it did not come up.  I'm sure someone has it if they read this area.

Beery
 

On the SECTORONE disk is a program, called DISP and TITLE to load a 16 color image.
The source is there as well.

Add it to AUTOEXEC

Downside:
* image loads only from DSK1.
(Unless the source code is changed to DSKx.) And compiled to run in MDOS

* 16 color image only. The Swan has higher colour resolution and not sure how to change to 16 colours, so now load the HDRAGON.
It loads slowly building up line by line.

Sent from my SM-A505F using Tapatalk

[+arcadeshopper]

On the SECTORONE disk is a program, called DISP and TITLE to load a 16 color image.
The source is there as well.

Add it to AUTOEXEC

Downside:
* image loads only from DSK1.
(Unless the source code is changed to DSKx.) And compiled to run in MDOS

* 16 color image only. The Swan has higher colour resolution and not sure how to change to 16 colours, so now load the HDRAGON.
It loads slowly building up line by line.

Sent from my SM-A505F using Tapatalk

Where's this disk archived?


Sent from my LM-V600 using Tapatalk

[+9640News]

Just booted MDOS with a TIPI from a simulated eprom.

 

I've been banging my head trying to understand why one PAB for the HFDC worked, but not the TIPI PAB.  Turned out, both PAB's were right after one another in the code, but not separated by an EVEN instruction.  Then, the TIPI code tried to do a MOV instruction on an odd boundary causing the issue.

 

Thanks to Tim's suggestion to use his RS232 "debugger" type interface for output, I chased the issue down.  Only took about 4 days.............

 

Beery

 

 

 

 

 

[GDMike]

And it booted. Awesome

[+9640News]

Just posting an update here.  Today, I burned the first eprom with the new TIPI code.  This was code from the 0.98 eprom with the new TIPI code and a TIPI specific LOAD-SYS.  Screen displays the swan, and loads MDOS from the TIPI.  Takes about 20 seconds to load as everything must pass through VDP as it is loading 32 sector chunks at a time, that then has to then be copied to CPU ram.

 

Right now, the only downside is the Swan display during the load process is corrupted in two spots as things pass into the VDP.  I think I will need to dump the Swan which was my original intention in the first place, however the VDP setup for the Swan is doing something I haven't understood yet from the earlier VDP initialization that has prohibited the display of any other screen I tried to display.

 

Anyways, wanted to give people an update.

[+InsaneMultitasker]

Are there [some, many, a lot, ?] programs that use the well defined addresses for the send/receive message routines? 

 

While working on adding Geneve /4A mode support for these routines, I ran into an issue where the Geneve already has an internal routine at one of the same addresses and it is used by multiple programs.  I'm trying to determine a path forward and have considered options like (1) requiring the affected /4a programs to enable ROMPAGE or use a rompage wrapper and (b) modifying the Geneve programs, which include GPL and EXEC.

 

Another challenge is that some programs are not scanning the DSR device table to look for "TIPI".   I'm not sure if this is for any particularly good reason but it seems contrary to the whole purpose of having a device list / search mechanism. 

 

Overall the Geneve-based TIPI, PI, and URIx routines seem to be functioning in the OS and /4A modes.  DSKx support is under review.  Beery and I are pressing ahead with some other OS updates concurrent to the TIPI work. 

[+9640News]

7 hours ago, InsaneMultitasker said:

Are there [some, many, a lot, ?] programs that use the well defined addresses for the send/receive message routines? 

 

While working on adding Geneve /4A mode support for these routines, I ran into an issue where the Geneve already has an internal routine at one of the same addresses and it is used by multiple programs.  I'm trying to determine a path forward and have considered options like (1) requiring the affected /4a programs to enable ROMPAGE or use a rompage wrapper and (b) modifying the Geneve programs, which include GPL and EXEC.

 

Another challenge is that some programs are not scanning the DSR device table to look for "TIPI".   I'm not sure if this is for any particularly good reason but it seems contrary to the whole purpose of having a device list / search mechanism. 

 

Overall the Geneve-based TIPI, PI, and URIx routines seem to be functioning in the OS and /4A modes.  DSKx support is under review.  Beery and I are pressing ahead with some other OS updates concurrent to the TIPI work. 

 

Tim,

 

I am pretty sure Stuart's web browser is using the send/rcv message routines.  I know the AfterHours BBS source does, Matt's Telnet and TIPICFG (I think), not sure about Chatti or Chess, and the mouse interface for TI-Artist as far as 4A programs.  On the MDOS side of things, MyTerm uses that address.  

 

Beery

 

[+jedimatt42]

Programs that are not searching for TIPI DSR entry to find the crubase before direct messaging should go on the WALL OF SHAME which I will gladly create. 

 

 

[+jedimatt42]

1 minute ago, BeeryMiller said:

 

Tim,

 

I am pretty sure Stuart's web browser is using the send/rcv message routines.  I know the AfterHours BBS source does, Matt's Telnet and TIPICFG (I think), not sure about Chatti or Chess, and the mouse interface for TI-Artist as far as 4A programs.  On the MDOS side of things, MyTerm uses that address.  

 

Beery

 

I don't remember TIPICFG using direct messaging. 

[+9640News]

1 minute ago, jedimatt42 said:

I don't remember TIPICFG using direct messaging. 

 

OK, that's why I had (I think).  Was thinking there was something going on with either a halt or reboot.  Guess not.

[+jedimatt42]

I wouldn't waste any effort on support for non-compliant 4A programs, except to document that they do or do not work in maximum 4A compatibility mode.

[+jedimatt42]

38 minutes ago, BeeryMiller said:

 

OK, that's why I had (I think).  Was thinking there was something going on with either a halt or reboot.  Guess not.

The TIPICFG reboot function peeks at the memory mapped IO state to see if it has been reset to 0 during the python startup code. Just looking for an indication that reboot finished. 

Edited January 19, 2021 by jedimatt42

[+InsaneMultitasker]

Yea, documenting and moving forward may be the best option.

 

Programs requiring and expecting direct access to the mapped IO ports will require rompage or a rompage wrapper anyway, since those ports are not visible under "normal Geneve" operation. 

 

Level 2 support for some operations will fall in the same bucket.  The Geneve is not a /4A so there will be limitations.   Full level 3 support has so far yielded good results, as one might expect.

 

Good fodder for one or more Geneve OS wiki entries.