TIPI - TI-99/4A to Raspberry PI interface development

[+9640News]

40 minutes ago, jedimatt42 said:

The Geneve still uses the 9995 8bit multiplexer the same in GPL vs MDOS mode. 

 

It seemed to me that the Geneve doesn't have an independently controllable wait state generator. So cycle speeds depend on which type of memory your code is running from. 

 

Also you could have memory map conflicts on the Geneve depending on what mods your Geneve is running with... 

 

My TI disk controller ROM didn't work with it either. But roughly the same code in the master DSR running out of onboard RAM has worked fine. 

 

I came to believe the thing needed a wait state generator when accessing the DSR page addresses from actual ROM on peripherals.

 

 

As long as the devices are decoded with respect to the available memory and pass the memory testing tests, I don't think the memory map issue would be the cause.

 

As far as wait state generation, I will have to look over some code as that may be a route to solving the issue.  I just did not know what area to target since the code runs fine in GPL mode.  That means, there is probably a CRU bit set somewhere in the GPL Interpreter code that is likely the solution.

 

Thanks for the feedback.

 

[dgrissom]

On 1/28/2023 at 1:53 PM, jedimatt42 said:

Ok, this image should fix itself on boot for the Raspberry PI it is being run on. https://jedimatt42.com/downloads/tipi-sdimage-bullseye-3.1.zip

 

I have not taken down the 'buster' image yet. I'll leave that 'buster' image up for a while under the 'old' section of my downloads page in case this blows up in my face. 

 

 

Good Afternoon @jedimatt42!  Hope you are doing well!

 

I encountered a problem the other day while writing a small app using the TIDBIT translator on the TIPI. I thought there might be corruption of my PI/TIPI installation.  I decided to install the new "bullseye" image.  The upgrade went without a hitch.  After the upgrade, I found that my problem on my TIDBIT was my programming skills. I introduced a typo that caused the translator to choke with a "OLD DSK1." load error.

 

Long story short, everything is working well except for one tiny problem.  I am probably the only one who would ask if this is possible.

 

I have a "shutdown button" connected to pin's 5 and 6 of the PI.  With the addition of "dtoverlay=gpio-shutdown" to the pi's "/boot/config.txt",  the button would both start and safely shutdown the PI with the older TIPI version.  With the new "buster" image the button will start the PI, but it will no longer shut it down.

 

I know that there are plenty of of ways to shut down the PI though software but kind of miss the ability to just turn it off turning on my console or ssh.

 

Is there any work around(s) to restore this?  If not, I will live 😉...

 

David G

[GDMike]

Google the command

"dtoverlay=gpio-shutdown"  maybe you need to add. .true or .yes or something.

Or maybe related to "key" down???

Look in the raspberry help sites

Edited March 17, 2023 by GDMike

[+jedimatt42]

@dgrissom I can look into it. This must be on the 'bullseye' 3.0/3.1 tipi version.. should be easy enough to reproduce.

[dgrissom]

38 minutes ago, jedimatt42 said:

@dgrissom I can look into it. This must be on the 'bullseye' 3.0/3.1 tipi version.. should be easy enough to reproduce.

Thanks for the solution during the zoom meeting! 

 

That's a great reason to participate!

[+jedimatt42]

On 3/16/2023 at 3:20 PM, dgrissom said:

Good Afternoon @jedimatt42!  Hope you are doing well!

 

I encountered a problem the other day while writing a small app using the TIDBIT translator on the TIPI. I thought there might be corruption of my PI/TIPI installation.  I decided to install the new "bullseye" image.  The upgrade went without a hitch.  After the upgrade, I found that my problem on my TIDBIT was my programming skills. I introduced a typo that caused the translator to choke with a "OLD DSK1." load error.

 

Long story short, everything is working well except for one tiny problem.  I am probably the only one who would ask if this is possible.

 

I have a "shutdown button" connected to pin's 5 and 6 of the PI.  With the addition of "dtoverlay=gpio-shutdown" to the pi's "/boot/config.txt",  the button would both start and safely shutdown the PI with the older TIPI version.  With the new "buster" image the button will start the PI, but it will no longer shut it down.

 

I know that there are plenty of of ways to shut down the PI though software but kind of miss the ability to just turn it off turning on my console or ssh.

 

Is there any work around(s) to restore this?  If not, I will live 😉...

 

David G

 

The problem was that the i2c usage of GPIO 3 (physical pin 5) is enabled by default on Raspberry PI OS Bullseye. Somewhere along the way I misplaced my instruction to disable it while crafting an SD card image. I have fixed my instructions.

 

For anyone else having trouble adding the gpio-shutdown overlay, before I release a new SD card image, just edit /boot/config.txt, find the line with 'i2c' in it... should be a dtparam line. And set it to off.  Hint, when you mount the sdcard on your windows machine, /boot/config.txt is the config file named 'config.txt' in the root directory on the removable drive named 'boot'. 

 

I believe a PI reboot is required after such a change for it to take.

[+9640News]

@jedimatt42

 

Matt,

 

When (version #) were the UDP and TIPI Log Extensions added?  I am adding these extensions as additional opcodes for the TIPI XOP.  I wasn't sure if the extensions were added before or after the new SDIMAGE you created.

 

 

[+jedimatt42]

Those are pretty old features by now. 

[+jedimatt42]

UDP was version 2.18  on  Feb 02, 2021

 

And the user log feature was in February 2022, still a 2.xx version.

[+9640News]

1 hour ago, jedimatt42 said:

UDP was version 2.18  on  Feb 02, 2021

 

And the user log feature was in February 2022, still a 2.xx version.

Thanks.  Much appreciated.

 

Going to ask a request as I find the Extension Log extension as a nice feature for both TI-99/4A and Geneve programmers for debugging programs.  I did not fully grasp its capabilities until I was adding to the TIPI XOP library.

 

The Extension Log extension writes comments out to the tipi.log file.  I see a definite advantage to writing out to the tipi.log file when doing any programming for the various extensions.  What I am wondering is whether 1) have a new name defined that would change the writing of the TIPI Log Extension to a new filename, or 2) have a new extension (0x26) with a filename defined in PI.CONFIG that would write entries out to another file.  This would make it easier to read the data that would not be intermixed with everything else that could be written to a tipi.log file.

 

Just an idea.

[+jedimatt42]

2 hours ago, 9640News said:

Thanks.  Much appreciated.

 

Going to ask a request as I find the Extension Log extension as a nice feature for both TI-99/4A and Geneve programmers for debugging programs.  I did not fully grasp its capabilities until I was adding to the TIPI XOP library.

 

The Extension Log extension writes comments out to the tipi.log file.  I see a definite advantage to writing out to the tipi.log file when doing any programming for the various extensions.  What I am wondering is whether 1) have a new name defined that would change the writing of the TIPI Log Extension to a new filename, or 2) have a new extension (0x26) with a filename defined in PI.CONFIG that would write entries out to another file.  This would make it easier to read the data that would not be intermixed with everything else that could be written to a tipi.log file.

 

Just an idea.

 

tail -F /var/log/tipi/tipi.log | grep UserLog

 

This will only show you lines that are written with this log mechanism. You can also have multiple terminals open tailing the same file, so you can be watching all the noise in one window, and see just your UserLog entries in another.

 

[+jedimatt42]

On 1/18/2023 at 6:32 AM, DuaneAL said:

Bumping this.  I'm hoping this works out, since pi stuff is unobtainium.

TIPI on Libre Computer Le Potato:

 

It's been a while, but I've got an SD Card image prepared for the Le Potato. It is experimental. https://jedimatt42.com/dl#experimental

Things to note:
- Le Potato does not have a WiFi, so you have to use ethernet, or a USB WiFi 'nub' 

- I don't think it 'halts' on shutdown... And shutdown/restart takes a while - I will probably have to put some creative effort into improving this.
- If a keyboard is attached ( I haven't tested mouse yet ) then boot takes quite a while. Without keyboard attached it moves along fine. 

- My experience, and Libre Computer literature suggests, you need high speed Micro SD card. I've used U3 rated SanDisk. The image is 32GB as that is the smallest U3 SanDisk I could buy at the time. The download is still just over 1GB cause blank space compresses nicely.

 

If anyone gives this a shot, understand that it is experimental. It seems to work, but I haven't tested every corner. 

Edited June 25, 2023 by jedimatt42

[+9640News]

@jedimatt42

 

I believe we have tracked down an issue with the Native_Files configuration option.  More details can be found before and after the link.  It looks like there is not a distinction when a file is written to the native files folder as an example when something should be DIS/FIX for object files.  As the native_files option is a new feature and works for text/source files, I do not know if you want/desire to be able to save something like object files out to the native files path as a DIS/FIX file.

 

For developers, it is simple enough as I think about it, to write the resulting object files out to a path not under the native files folder.  Or, once a native file in the native files folder which we presume to be text, can be copied through to a non-native files folder on the TIPI path.

 

Beery

 

 

[+jedimatt42]

The intent is that saving a DIS/FIX or PROGRAM to a native text folder would produce normal TIFILES headered files. 

[+InsaneMultitasker]

@jedimatt42

 

I sent @9640News a test program yesterday to compare notes. I chronicled my findings in the Geneve OS dev thread but I'll summarize a few findings here:

 

1. As 9640News indicated, attempting to create a new DF80 file results in a native file.  Inspection of the file shows "trash" in the first 100 or so bytes. I used Beyond Compare and captured a screenshot of the TIFILES versus non-TIFILES file, for reference.

 

2. Attempting to create Internal file types, i.e., Int/Fix or Int/Var, results in a native file.  Writing a record to the newly created native file throws an exception in the TIPI log and requires me to restart the Rpi via the web interface. Powering down the PEB does not resolve the halted condition.

 

3. Copying TIFILES headered files into the native_text folder allows subsequent, proper access to DF80 files and program files. What is the intended support case for the Internal file type, within the native_text folder?

 

[+jedimatt42]

The only thing that makes sense is that only DiS/VAR 80 files are headerless in a native folder. Any other file type should be treated as a TIFILES file. That is the intent.

 

Sounds like I got it mostly correct for direct-input and direct-output, but missed a bunch of test cases for record access. 

 

I will fix. But I have a busy week, so I probably won't get to start into it until Saturday.

[+jedimatt42]

A fix has been posted.

[JasonACT]

You will gain better compatibility in the CALL TIPI EA5 loader if you reload some sensible values after clearing scratch:
 

    LWPI    GPLWS
    LI    R1,>8300
    LI    R2,>C0
!    CLR    *R1+
    DECT    R2
    JNE    -!
    LI  R2,>9E7E ; sensible
    MOV R2,@>8372 ; value

JUMPMAN    EQU    >8320
 

Edited July 19, 2023 by JasonACT

[+jedimatt42]

Thanks,

 

It is a trade off... There are other programs that will fail if their workspaces are not pre-zeroed... Most assembly programs don't expect scratchpad to look like it came from BASIC. 

 

What does the value 0x9E7E at address 0x8372 represent? And what program cared?

[JasonACT]

Ah, yes.  See the EA manual page 404.  Default values. (Not internet error "not found" :)

And...

War Zone II,

DEMO (part of the Classic99's install).

Edited July 19, 2023 by JasonACT

[+mizapf]

2 minutes ago, JasonACT said:

Ah, yes.  See the EA manual page 404.  Default values. (Not internet error "not found" :)

Whenever I ask my students about HTTP status codes, I hesitate to ask for 404 because everyone knows it.

Nope.

 

Not anymore, since the servers or the browsers themselves start to give you weird textual answers like "oops, this should not have happened..." or "I'm sorry, I did my best but could not find the page you requested" or other b***it.

 

[+Lee Stewart]

2 hours ago, jedimatt42 said:

What does the value 0x9E7E at address 0x8372 represent? And what program cared?

 

1 hour ago, JasonACT said:

Ah, yes.  See the EA manual page 404.  Default values. (Not internet error "not found" :)

And...

War Zone II,

DEMO (part of the Classic99's install).

 

Well, page 404 of the E/A manual has it wrong! You, @JasonACT, however, have it right. >8372 is the data stack pointer for GPL. The data stack (grows upward) is 32 bytes starting at >83A0, so, initially, the byte at >8372 (after adding >8300) should point to 2 bytes below that stack, viz., >839E—not the >83CF of the E/A manual. >8373 is the subroutine stack pointer for GPL. The subroutine stack (grows upward) is 32 bytes starting at >8380, so, initially, >8373 (after adding >8300) should point to 2 bytes below that stack, viz., >837E, which is correctly shown.

 

Any code using GPL (GROMs, GPLLNK from assembly code, ...) would need the bytes at >8372 and >8373 properly initialized.

 

...lee

Edited July 19, 2023 by Lee Stewart
correction

[JasonACT]

Hi Lee.  Yes, page 405 is a must read...  You don't even need to turn the page, if you have the real thing in front of you, and why wouldn't you continue reading?   [one of the best books I've ever read.]

Edited July 20, 2023 by JasonACT

[+jedimatt42]

thanks for pointing out this section of the EA manual. After reviewing it, my stab in the dark at clearing all of scratchpad from 8300 -> the workspace used by the console interrupt routine, is clearly too aggressive. Seems like I should stop clearing at 834A, where pretty much everything beyond may have some value to a console routine, that some legacy program may depend on. 

 

I'll make a relevant change. -- what I'm really tempted to do is snapshot that memory in a little program loaded from EA5, and then restore that from the ROM before launching programs. I've got some 26k free... 

 

I'm playing around with another request that may require a ROM change, which is a better value add for anyone sourcing the DSR rom upgrade. 

Edited July 29, 2023 by jedimatt42
Removed nonsense about nonsense

[WhataKowinkydink]

Is the value >D0 correct after it has been accessed?