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

[+InsaneMultitasker]

4 hours ago, BeeryMiller said:

Matt,

 

Got a question.  Is there a way to flush the buffer for the socket read command without disrupting the connection?

 

With a serial RS232 connection to a BBS, most terminal software has a CTRL-C function that breaks the current routine on the server side.  Since it is single character based, there is not much data stored.  I can still send a CTRL-C with a TIPI socket connection, however the PI has already buffered or could have buffered a significant amount of data that is waiting to be read.

 

It would be nice to be able to empty the contents with a "FLUSH" socket command via keystroke on the TIPI client.

 

Alternatively, I could have the client read without processing the data to an empty large buffer location until things are empty but thought a FLUSH command to the Socket commands may be more appropriate.

 

Beery

In Mass Transfer I had originally tied CTRL-SHIFT to a routine that flushed the buffer by reading from the TIPI until there was nothing left to read.  I reverted back to just pausing the screen (to match TIMXT) while the keys were held down as I found that I disliked the purge.... so it is do-able. 

[+9640News]

Got a question trying to figure out what may be going on.

 

I've got an XMODEM routine, originally coded for DSKX.123456789A with a 10 character filename length.  I have mapped a directory to DSK1.

 

The DSRLNK calls up the following code that works for a 10 character filename length, but fails on anything longer:

 

BLWP @DSRLNK

Data >0114

 

The routine is for direct file sector access.

 

Is there any restriction to that call that limits the filename to 10 characters, nothing longer the DSR? 

 

I have traced the error to that specific call.  I modified the code in all the places so a filename could be larger than the filename I am entering, however I am getting a report back the file can not be found.  If the filename is 10 characters, it is found in the TIPI mapped DSK1 folder.

 

It's possible I may have overlooked something handling longer filenames, so at this moment I am still reviewing the code.  Any thoughts would be appreciated.

 

Beery

[+arcadeshopper]

Got a question trying to figure out what may be going on.
 
I've got an XMODEM routine, originally coded for DSKX.123456789A with a 10 character filename length.  I have mapped a directory to DSK1.
 
The DSRLNK calls up the following code that works for a 10 character filename length, but fails on anything longer:
 
BLWP @DSRLNK
Data >0114
 
The routine is for direct file sector access.
 
Is there any restriction to that call that limits the filename to 10 characters, nothing longer the DSR? 
 
I have traced the error to that specific call.  I modified the code in all the places so a filename could be larger than the filename I am entering, however I am getting a report back the file can not be found.  If the filename is 10 characters, it is found in the TIPI mapped DSK1 folder.
 
It's possible I may have overlooked something handling longer filenames, so at this moment I am still reviewing the code.  Any thoughts would be appreciated.
 
Beery

Can't do sector access to TIPI

Sent from my LM-G820 using Tapatalk

[+9640News]

13 minutes ago, arcadeshopper said:

Can't do sector access to TIPI

Sent from my LM-G820 using Tapatalk
 

I realize one can't do sector I/O.  However, the DSRLNK call does work on the TIPI I referenced with a 10 character filename.  It just does not appear to work on any filenames longer than 10 characters the best I can figure out.

 

The original author of that code called it a direct sector read of file access.  Maybe he didn't quite use the correct description.  Myself, I am not that well versed in some of the DSR code to know if that routine could be limited to 10 characters, or whatever may be passed as part of the PAB.  It's not a normal PAB, so my understanding of its use is limited.

 

What I do know is that using a DSKx device name and a filename length of 10 characters or less, it works.  It appears to fail after anything larger is given for the filename (after I expanded the code to use a longer filename).

 

Beery

 

 

[+jedimatt42]

1 hour ago, BeeryMiller said:

I realize one can't do sector I/O.  However, the DSRLNK call does work on the TIPI I referenced with a 10 character filename.  It just does not appear to work on any filenames longer than 10 characters the best I can figure out.

 

The original author of that code called it a direct sector read of file access.  Maybe he didn't quite use the correct description.  Myself, I am not that well versed in some of the DSR code to know if that routine could be limited to 10 characters, or whatever may be passed as part of the PAB.  It's not a normal PAB, so my understanding of its use is limited.

 

What I do know is that using a DSKx device name and a filename length of 10 characters or less, it works.  It appears to fail after anything larger is given for the filename (after I expanded the code to use a longer filename).

 

Beery

 

 

 

>10 is sector input&output

 

You are talking about direct_input and direct_ouput... those are not sector io, those are block io... blocks happen to be the same size as a sector... but a sector is relative to the DISK, and a block is relative to the file.

 

And yes, the TI filesystem only supports 10 character filenames... TIPI supports name translation.. if the name is too long you can see the 10 character version of the name in the web-ui

 

https://github.com/jedimatt42/tipi/wiki/Level2-IO

 

The TI disk controller implementation, and most that followed implemented IO in 3 layers...

 

Level 1 - Sector IO ( get some data onto or off of the physical medium )

Level 2 - File system allocation - be able to refer to Files and work relative to them.

Level 3 - The high level Record and PROGRAM image based model we know.

 

Level 3 builds on Level2 and level2 builds on Level1.. 

 

For TIPI... Level 3 works directly with the PI... and I have many things only implemented at level 3, like PI.PIO, PI.CONFIG, etc...

Level 2 also directly interacts with the PI, but only with TIFILES

 

[+jedimatt42]

The best docs on Level 2 and Level 1 are at Fred Kaal's site... ti99-geek.nl

[+9640News]

1 hour ago, jedimatt42 said:

 

>10 is sector input&output

 

You are talking about direct_input and direct_ouput... those are not sector io, those are block io... blocks happen to be the same size as a sector... but a sector is relative to the DISK, and a block is relative to the file.

 

And yes, the TI filesystem only supports 10 character filenames... TIPI supports name translation.. if the name is too long you can see the 10 character version of the name in the web-ui

 

That's what I was afraid of, but now I know where and how to address the issue.  That means I can restore my original Xmodem code and it is just a file naming issue I need to address. 

 

I was able to use your web-ui to do a copy & paste over into Excel that gives me the 10 character filename for the longer filename.  I will be able to sort on the native name to identify the filenames that are too long.  I will replace the filenames that have the "`" in the filename with a "-" for something a bit more "normal" in the filenaming.

 

Those files that are marked with the original filename that were renamed, I will write some VBA excel code to rename the files in the TIPI directory and also include a workbook replace string function to find the occurrences and rename them.

 

And if anyone wonders why I don't go in and manually do it, there are about 1550 files of the 2800+ files that need to be renamed.  Manually, it would take some time...…...

 

Thanks for the feedback, and the web-ui sure makes things easier to identify.

 

Beery

 

 

[+9640News]

21 hours ago, jedimatt42 said:

The best docs on Level 2 and Level 1 are at Fred Kaal's site... ti99-geek.nl

 

Matt,

 

Throwing an idea out there, whether it is thought to be worthy or not, it is up to you.  I may be looking at things too simple, or it could be creating more trouble than it is worth.  

 

I listed Fred's subprogram ID's below.  Pretty straight forward.  I see SCSI has a couple of specific subprograms, as well as the IDE has a subprogram unique to those controllers so expanding the Subprogram list beyond TI's original list is not something new.

 

Would it be possible to have a library of TIPI specific subprograms that permit longer filenames than the TI standard of 10 characters?  If users are writing something very specific to the TIPI, and since the TIPI can support longer filenames, I'm wondering if there is some value there. 

 

I'm thinking >32, >33, >34, >35 Subprograms and possibly >38, >39, and 3A.

 

Existing programs would use the current subprograms, but if someone wanted to tap into using longer filenames outside the Web-ui, then they could do that as well.

 

I know it would have been of benefit to me, but I do have a solution/path I can proceed.  Right now, I would be the only person that could have used it.  Maybe there are other things others could have in mind that would use this capability???

 

Just asking.  I realize it would create an Eprom upgrade so maybe it is too much trouble.  If you do think there is value, and you do foresee a future eprom upgrade outside of this idea  for TI-99/4A users, maybe incorporate????

 

Just a suggestion.

 

 

[+jedimatt42]

I have a proposol for level3 io from Tursi to support longer filenames... but I don't recall much thought about how the level 2 should work... 

 

I haven't put much energy into thinking about really bringing long names to the 4A... I'll probably explore it some time in Force Command... but like after 30 other projects I have on my list.

 

[+jedimatt42]

19 minutes ago, jedimatt42 said:

I have a proposol for level3 io from Tursi to support longer filenames... but I don't recall much thought about how the level 2 should work... 

 

I haven't put much energy into thinking about really bringing long names to the 4A... I'll probably explore it some time in Force Command... but like after 30 other projects I have on my list.

 

 

They mostly work already with level 3 routines, except you can't get a listing... 

 

[Asmusr]

I have released a new version of JS99er with some bugfixes related to the TIPI: there was a problem when you enabled and disabled the emulation,  and the CPU is now suspended until the websocket is running.

 

I have managed to load programs from the TIPI, but when I try to save a simple BASIC program (SAVE TIPI.BAS.HELLO) I get an I/O ERROR 66. What am I doing wrong?

 

And what is the correct way to shut down QEMU?

 

Thanks.

[+jedimatt42]

6 hours ago, Asmusr said:

I have released a new version of JS99er with some bugfixes related to the TIPI: there was a problem when you enabled and disabled the emulation,  and the CPU is now suspended until the websocket is running.

 

I have managed to load programs from the TIPI, but when I try to save a simple BASIC program (SAVE TIPI.BAS.HELLO) I get an I/O ERROR 66. What am I doing wrong?

 

And what is the correct way to shut down QEMU?

 

Thanks.

 

assuming the BAS directory exists, that should be fine... there is a log inside the qemulation  /var/log/tipi/tipi.log that might say why if failed to write.

 

to shutdown, while logged into the console in QEMU:

 

sudo shutdown now

 

wait until there is some error looking nonsense on the screen. Then use the menu to quit QEMU. That will have flushed everything to the sd card image.

[+jedimatt42]

@Asmusr  your error 66 reproduced... 

 

Saving a PROGRAM image looks broken in the python3 upgraded code... I missed testing that...

 

for BASIC, I usually just use the web-ui and save / edit there, or from a native file... and let the PROGRAM image loader convert it to basic... but.. I'll get that fixed...

 

try something else.

 

 

[+jedimatt42]

I have fixes for the PROGRAM save issue, and a few other things, and was trying to stream-line the sdcard image configuration to be more friendly to QEMU and to the user... but I cannot get beyond reset now..

 

Are there un-pushed changes required? 

 

I don't see anything pending in js99er-angular's branch for tipi vs master, or pete's tipi fork of tipi...

[Asmusr]

25 minutes ago, jedimatt42 said:

I have fixes for the PROGRAM save issue, and a few other things, and was trying to stream-line the sdcard image configuration to be more friendly to QEMU and to the user... but I cannot get beyond reset now..

 

Are there un-pushed changes required? 

 

I don't see anything pending in js99er-angular's branch for tipi vs master, or pete's tipi fork of tipi...

Looks like I broke the TIPI emulation. I will fix it later tonight.

[Asmusr]

32 minutes ago, jedimatt42 said:

I have fixes for the PROGRAM save issue, and a few other things, and was trying to stream-line the sdcard image configuration to be more friendly to QEMU and to the user... but I cannot get beyond reset now..

 

Are there un-pushed changes required? 

 

I don't see anything pending in js99er-angular's branch for tipi vs master, or pete's tipi fork of tipi...

Just a stupid mistake. Try now.

[+jedimatt42]

2 minutes ago, Asmusr said:

Just a stupid mistake. Try now.

 

Nice! THanks! works now...

 

I'll resume work to make my other changes available

[+jedimatt42]

Updated image / bundle of joy... for use with js99er

 

https://www.jedimatt42.com/downloads/tipi-js99er-1-64-b2.zip

 

* Includes README.txt with simple steps to get going

* All necessary files included - except QEMU itself - link in the README.txt

 

- Includes the WinNfsD.exe and scripts... TIPI image configured to tolerate the missing NFS and store on the sdimage instead. 

- Some more python3 fixes - SAVE PROGRAM... 

- Removed the ramdisk allocations - where about 230 meg of TMPFS allocated - I suspect this is why over time arcadeshopper's 'it ate itself' phrase would arise. 

- Disabled PDF part of PI.PIO, cause it doesn't work... it just crashes out in a 3rd party tool... some day I'll re-enable

- Code pivots on /home/tipi/.js99er file being present. So less between hardware branch and this branch will need to deviate.

- Upgrade should work for future changes - created and set this image up for a tipi emuRelease branch, so the upgrade system can be targeted, and you probably don't have

to download full images again.

 

Additionally contains my fixes for the automatic unpacking of track dump disk images - I had a bug for anything not single density. 

 

(Wiki updates pending)

 

 

[+jedimatt42]

A new emulation bundle is up on my downloads page...   https://www.jedimatt42.com/downloads.html

 

tipi-emulation-2.3.zip : 

  the inner directory was renamed - others have expressed a desire for this to support their emulators and there is nothing coupling this specifically to js99er.. ( except js99er is the only one available today that supports it. )

 

ditching the idea of an emuRelease branch.. all merged in nicely to the primary branches, and so there are really only 2 external changes made to the emulation sdimage : 

• creating /home/tipi/.emulation
• and removing the tmpfs entries from /etc/fstab

 

 

[+9640News]

On 6/21/2020 at 3:10 PM, jedimatt42 said:

 

Now use - tipi-js99er-beta1.64.zip    https://www.jedimatt42.com/downloads/tipi-js99er-beta1.64.zip  - this is just a snapshot of the qemu image after following @PeteE 's instructions. Then I disabled the tipiwatchdog.service which fails to start ( looks for GPIO pins ) 

 

commands for 4 are no longer needed. 

 

 

Seems for best use, wait a moment after you go to the TI Title screen, as sometimes the service reset happens after you've begun something like Force Command's AUTOCMD or XB's LOAD  - I haven't really debugged that, it is an impression

(maybe that reset behavior should be made synchronous for js99er)

 

 

OK, trying to set this up on my Windows 10 64 bit system.  I installed qemu, and then typed the  tipi-qemu.bat file.

 

I am getting this when I run it in a command.com window:

 

C:\tipiqemu>tipi-qemu

C:\tipiqemu>"\Program Files\qemu\qemu-system-arm"   -M versatilepb   -cpu arm1176   -m 256M   -drive file=sdimage.img,format=raw   -net nic   -net user,hostfwd=tcp::9900-:9900,hostfwd=tcp::9901-:9901,hostfwd=tcp::9922-:22   -dtb versatile-pb-buster.dtb   -kernel kernel-qemu-4.19.50-buster   -append "root=/dev/sda2 rootfstype=ext4 rw"
\Program Files\qemu\qemu-system-arm: Could not set up host forwarding rule 'tcp::9900-:9900'

C:\tipiqemu>

 

Trying to figure out what I may doing wrong.

 

 

 

 

 

 

 

Edited July 8, 2020 by BeeryMiller

[+jedimatt42]

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

[+9640News]

I'm running Mystic BBS, though inbound calls are not available.  It has several ports tied up at 9640, 8080, 24xxx(?), and I believe at least one other port.  I will have to double-check 9901 as I may have set that up for the FTP port.

 

Probably won't be able to check things out until tomorrow evening.  Celebrating 20 years with the wife and I don't need to be messing with computers this evening.

 

Beery

 

[+9640News]

Matt,

 

You were correct.  I had some ports tied up with my BBS running in the background.  I took the board offline.

 

I copied files over from one of my tipi's to the tipi_disk folder in the tipiqemu folder  I run nfs_tipi_disk.bat in one dos window.  I get a message at the end of "vpb_sic_write: Bad register offset 0x2c".  Not sure how critical this is.

 

I then run tipi-qemu.bat and after about a minute, I get tipi window to boot and I am sitting at the tipi@tipi:~$ prompt.  I am able to do a DIR on the files in the tipi_disk folder and I see the files I copied over.  

 

(Matt, at this point I know you have nothing to do with JS99er, so I am posting this in the event someone sees something I am doing wrong and can report).

 

At this point I go to js99er.net.  If I have under options Sound and 32K ram enabled checked, and nothing else checked, js99er pulls up fine.  If I enable TIPI under Options, I get a black screen and nothing else.

 

I've got a Windows 10 system, Microsoft Edge browser, 16 GB ram, quadcore, 2.2 GHz setup.

 

Anyone have thoughts????

 

Beery

 

[+arcadeshopper]

Matt,
 
You were correct.  I had some ports tied up with my BBS running in the background.  I took the board offline.
 
I copied files over from one of my tipi's to the tipi_disk folder in the tipiqemu folder  I run nfs_tipi_disk.bat in one dos window.  I get a message at the end of "vpb_sic_write: Bad register offset 0x2c".  Not sure how critical this is.
 
I then run tipi-qemu.bat and after about a minute, I get tipi window to boot and I am sitting at the tipi@tipi:~$ prompt.  I am able to do a DIR on the files in the tipi_disk folder and I see the files I copied over.  
 
(Matt, at this point I know you have nothing to do with JS99er, so I am posting this in the event someone sees something I am doing wrong and can report).
 
At this point I go to js99er.net.  If I have under options Sound and 32K ram enabled checked, and nothing else checked, js99er pulls up fine.  If I enable TIPI under Options, I get a black screen and nothing else.
 
I've got a Windows 10 system, Microsoft Edge browser, 16 GB ram, quadcore, 2.2 GHz setup.
 
Anyone have thoughts????
 
Beery
 

Did you confirm the address in the TIPI enable line? ws://localhost:9901/tipi

Sent from my LM-V600 using Tapatalk

[+9640News]

3 minutes ago, arcadeshopper said:

Did you confirm the address in the TIPI enable line? ws://localhost:9901/tipi

Sent from my LM-V600 using Tapatalk
 

What does one do to confirm the TIPI enable line?  I am running both .BAT files that were in the distribution file Matt provided.  Is there something else I need to do?  If so, how?

Beery