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

[+InsaneMultitasker]

When I run the following program to create and write a new relative file, records zero and 30 do not survive and are 'overwritten' with record 25.  

 

If I run the same program a second time (and allow the program to write to the existing TEST30ROM file) records zero and 30 are written to the file. 

 

See attached program (MAKE30) and the created DF80 file (TEST30ROM).

 

1 !SAVE TIPI.BLOB.MAKE30
100 OPEN #1:"TIPI.BLOB.TEST30ROM",RELATIVE,UPDATE,DISPLAY,FIXED 80
110 PRINT #1,REC 30:"RECORD 30!"
111 PRINT #1,REC 0:"RECORD ZERO!"
112 PRINT #1,REC 25:"RECORD 25!"
120 CLOSE #1
 

 

MAKE30 TEST30ROM

[+jedimatt42]

10 hours ago, InsaneMultitasker said:

When I run the following program to create and write a new relative file, records zero and 30 do not survive and are 'overwritten' with record 25.  

 

If I run the same program a second time (and allow the program to write to the existing TEST30ROM file) records zero and 30 are written to the file. 

 

See attached program (MAKE30) and the created DF80 file (TEST30ROM).

 

1 !SAVE TIPI.BLOB.MAKE30
100 OPEN #1:"TIPI.BLOB.TEST30ROM",RELATIVE,UPDATE,DISPLAY,FIXED 80
110 PRINT #1,REC 30:"RECORD 30!"
111 PRINT #1,REC 0:"RECORD ZERO!"
112 PRINT #1,REC 25:"RECORD 25!"
120 CLOSE #1
 

 

MAKE30 346 B · 1 download TEST30ROM 2.88 kB · 2 downloads

Well, that's a bug  

 

My FixedRecord code is creating a new record, and assigning that same instance into all the record slots, and writing a new value to a record is copying bytes into that object instead of replacing that object... fun stuff... 

 

I think you want to see this result:

 

00000000  07 54 49 46 49 4c 45 53  00 0b 00 03 50 50 1f 00  |.TIFILES....PP..|
00000010  42 4c 4f 42 20 20 20 20  20 20 00 00 00 00 00 00  |BLOB      ......|
00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000080  52 45 43 4f 52 44 20 5a  45 52 4f 21 20 20 20 20  |RECORD ZERO!    |
00000090  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20  |                |
*
000000d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000008d0  52 45 43 4f 52 44 20 32  35 21 20 20 20 20 20 20  |RECORD 25!      |
000008e0  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20  |                |
*
00000920  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000a80  52 45 43 4f 52 44 20 33  30 21 20 20 20 20 20 20  |RECORD 30!      |
00000a90  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20  |                |
*
00000ad0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000b80

 

A new TIPI update will be coming... in a bit.

Edited December 19, 2020 by jedimatt42

[+InsaneMultitasker]

4 hours ago, jedimatt42 said:

I think you want to see this result:

cool, that looks good to me   

 

It looks as if you are setting the reserved records to null - certainly a much cleaner and better approach than the disk controllers' present-what-is-on-the-media-at-the-time approach, IMHO.  

 

Sort of along the same line of thinking, if an existing 30-record file is closed, re-opened as relative, and the program writes record 60 (without first writing to 31-59), will records 31-59 be set to null similar to your fixed sample?  

Updated to 2.14 and tested -- the original test program now works and the question re: re-opening a file has been answered as part of the test. Record 60 was added and records 31-59 were set to null.

[+InsaneMultitasker]

I ran into this weird one today while working on DSR code.

 

When accessing PI.STATUS, if the very first operation is the status opcode (9), an exception is reported and the system freezes:

 

2020-12-19 13:37:13,546 TipiService : ERROR    Unhandled exception in main
Traceback (most recent call last):
  File "./TipiService.py", line 79, in <module>
    if specialFiles.handle(pab, filename):
  File "/home/tipi/tipi/services/SpecialFiles.py", line 50, in handle
    handler.handle(pab, devname)
  File "/home/tipi/tipi/services/StatusFile.py", line 34, in handle
    self.status(pab, devname)
  File "/home/tipi/tipi/services/StatusFile.py", line 79, in status
    if readRec >= self.tipiStatus.len():
AttributeError: 'list' object has no attribute 'len'

 

--

If I reset the system I can open/read/close PI.STATUS properly.  After the first read, I can also use status(9) multiple times with no reported exception; all PI.STATUS records are also read as expected.  The below log shows two consecutive reads of PI.STATUS. 

--

;first pass without status opcode
2020-12-19 13:47:44,278 StatusFile  : INFO     open PI.STATUS
2020-12-19 13:47:44,694 StatusFile  : INFO     read PI.STATUS
...
2020-12-19 13:47:50,708 StatusFile  : INFO     close PI.STATUS

 

; second pass with status opcode:
2020-12-19 13:47:57,366 StatusFile  : INFO     status PI.STATUS  (no exception)
2020-12-19 13:47:57,426 StatusFile  : INFO     open PI.STATUS
2020-12-19 13:47:57,684 StatusFile  : INFO     read PI.STATUS
...
2020-12-19 13:47:58,302 StatusFile  : INFO     close PI.STATUS

 

As far as I can tell, there are no PAB differences between the failed and successful attempts. I am running version 2.14 as released today.

 

PI.CONFIG doesn't seem to be adversely affected by the status(9) opcode:

 

2020-12-19 14:36:41,306 Pab         : INFO     opcode: Status, fileType: Sequential, mode: Input, dataType: Display, recordType:                 Variable, recordLength: 80, recordNumber: 14
2020-12-19 14:36:41,364 Pab         : INFO     opcode: Open, fileType: Sequential, mode: Input, dataType: Display, recordType: V                ariable, recordLength: 0, recordNumber: 14
2020-12-19 14:36:41,423 Pab         : INFO     opcode: Read, fileType: Sequential, mode: Input, dataType: Display, recordType: V                ariable, recordLength: 80, recordNumber: 0
2020-12-19 14:36:43,041 Pab         : INFO     opcode: Close, fileType: Sequential, mode: Input, dataType: Display, recordType:                 Variable, recordLength: 80, recordNumber: 14
 

[+jedimatt42]

Yep. Those aren't real files. So they implement a minimum feature set. Just read records until it errors. Then close.

[+jedimatt42]

1 hour ago, InsaneMultitasker said:

I ran into this weird one today while working on DSR code.

 

When accessing PI.STATUS, if the very first operation is the status opcode (9), an exception is reported and the system freezes:

 

2020-12-19 13:37:13,546 TipiService : ERROR    Unhandled exception in main
Traceback (most recent call last):
  File "./TipiService.py", line 79, in <module>
    if specialFiles.handle(pab, filename):
  File "/home/tipi/tipi/services/SpecialFiles.py", line 50, in handle
    handler.handle(pab, devname)
  File "/home/tipi/tipi/services/StatusFile.py", line 34, in handle
    self.status(pab, devname)
  File "/home/tipi/tipi/services/StatusFile.py", line 79, in status
    if readRec >= self.tipiStatus.len():
AttributeError: 'list' object has no attribute 'len'

 

--

If I reset the system I can open/read/close PI.STATUS properly.  After the first read, I can also use status(9) multiple times with no reported exception; all PI.STATUS records are also read as expected.  The below log shows two consecutive reads of PI.STATUS. 

--

;first pass without status opcode
2020-12-19 13:47:44,278 StatusFile  : INFO     open PI.STATUS
2020-12-19 13:47:44,694 StatusFile  : INFO     read PI.STATUS
...
2020-12-19 13:47:50,708 StatusFile  : INFO     close PI.STATUS

 

; second pass with status opcode:
2020-12-19 13:47:57,366 StatusFile  : INFO     status PI.STATUS  (no exception)
2020-12-19 13:47:57,426 StatusFile  : INFO     open PI.STATUS
2020-12-19 13:47:57,684 StatusFile  : INFO     read PI.STATUS
...
2020-12-19 13:47:58,302 StatusFile  : INFO     close PI.STATUS

 

As far as I can tell, there are no PAB differences between the failed and successful attempts. I am running version 2.14 as released today.

 

PI.CONFIG doesn't seem to be adversely affected by the status(9) opcode:

 

2020-12-19 14:36:41,306 Pab         : INFO     opcode: Status, fileType: Sequential, mode: Input, dataType: Display, recordType:                 Variable, recordLength: 80, recordNumber: 14
2020-12-19 14:36:41,364 Pab         : INFO     opcode: Open, fileType: Sequential, mode: Input, dataType: Display, recordType: V                ariable, recordLength: 0, recordNumber: 14
2020-12-19 14:36:41,423 Pab         : INFO     opcode: Read, fileType: Sequential, mode: Input, dataType: Display, recordType: V                ariable, recordLength: 80, recordNumber: 0
2020-12-19 14:36:43,041 Pab         : INFO     opcode: Close, fileType: Sequential, mode: Input, dataType: Display, recordType:                 Variable, recordLength: 80, recordNumber: 14
 

I have logged the issue, so if I'm looking for something to do, I'll find it: https://github.com/jedimatt42/tipi/issues/143

 

[+InsaneMultitasker]

3 hours ago, jedimatt42 said:

Yep. Those aren't real files. So they implement a minimum feature set. Just read records until it errors. Then close.

Got it. For now I'll work around the status opcode and I appreciate you logging it for a rainy day.   By skipping the status opcode I successfully loaded PI.CONFIG into an editor, changed the URI1 entry, saved PI.CONFIG, then proceeded to load a program file from the internet.  Thank you.  

[+jedimatt42]

9 minutes ago, InsaneMultitasker said:

Got it. For now I'll work around the status opcode and I appreciate you logging it for a rainy day.   By skipping the status opcode I successfully loaded PI.CONFIG into an editor, changed the URI1 entry, saved PI.CONFIG, then proceeded to load a program file from the internet.  Thank you.  

Note, with PI.CONFIG, you don't have to write all the records... it's actually a key-value map, and only records written are modified. Other records are preserved. So, you can OPEN, just WRITE an entry (or a few), and CLOSE. 

[+9640News]

Beery

Edited December 20, 2020 by BeeryMiller

[+jedimatt42]

NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO... Holy ... NO

 

Now, this is one of the many things that rubs me the wrong way about the Geneve... users expectation that software for a 4A should be written for a Geneve... You can't expect people to put 1 instruction in their code for a machine they don't have... That is ridiculous.

 

You should build a shim EA5 loader for the Geneve that does this for you to load any program you want in this mode... instead of making 4A programs adapt to the non-4a-compatible mode of the Geneve.

 

Absolutely Ridiculous. 

 

Take responsibility for your own platforms incompatibility.

Edited December 20, 2020 by jedimatt42

[+mizapf]

28 minutes ago, jedimatt42 said:

You can't expect people to put 1 instruction in their code for a machine they don't have... That is ridiculous.

Nope. That's called adaptability.

Surprise, people might write software that runs on different VDPs, even for the F18A, without owning one.

 

But anyway, I did not understand the intention if Beery's request. If you place BA into 8002, this is actually ROMPAGE, right? It hides the GeneveOS DSR. So where is the advantage over entering GPL mode with ROMPAGE?

 

 

[+arcadeshopper]

Nope. That's called adaptability.
Surprise, people might write software that runs on different VDPs, even for the F18A, without owning one.
 
But anyway, I did not understand the intention if Beery's request. If you place BA into 8002, this is actually ROMPAGE, right? It hides the GeneveOS DSR. So where is the advantage over entering GPL mode with ROMPAGE?
 
 

Doesn't exec do this?

Sent from my LM-V600 using Tapatalk

[+Vorticon]

I was wondering if someone could do a quick check for me.

With the TIPI-PEB in place, can you access the PHYSICAL drives (DSK1-3) from the EA module option #5? This is not working for me although option #3 does work. No issues with XB either. The only way to load an option #5 program (memory image) from the physical drives on a diskette is to use the LOAD command from within FC... If I take out the TIPI, then everything goes back to normal.

 

 

[+jedimatt42]

31 minutes ago, mizapf said:

Nope. That's called adaptability.

Surprise, people might write software that runs on different VDPs, even for the F18A, without owning one.

 

But anyway, I did not understand the intention if Beery's request. If you place BA into 8002, this is actually ROMPAGE, right? It hides the GeneveOS DSR. So where is the advantage over entering GPL mode with ROMPAGE?

 

 

Programs that just use the TIPI messaging system (for mouse, or TCP communications) activate the TIPI DSR, and do stuff, but often don't do actual file IO. 

 

Then you get to this hybrid mode where the app doesn't work cause it does do file IO, and the user has to understand they can only use ROMPAGE compatible storage... they have a TIPI in this case, so that's not a blocker... but you wouldn't expect it if you didn't enter ROMPAGE mode. 

 

@arcadeshopper, I would have thought EXEC /R option would be good, but it doesn't actually set up much of a 4A environment... No system ROMs or GPL... so only good for 4A EA5's that are completely self contained (have their own DSR code, own font, etc... ) - maybe 70% (made up stat) of the EA5's out there are like that.  Setting graphics mode or text mode and loading the character set using gcc+libti99 copies from the console GROMs, so those programs don't work well in EXEC... Again... if a Geneve wants to run 4A code, it should make the effort. 

 

It wouldn't be hard to individual Geneve owners to patch these binaries themselves... learn a little machine code. learn a little about the EA5 format... Bob's your uncle... But it isn't reasonable to ask this of 4A developers. 

 

On a 4A, 8002 is high byte of R1 if your workspace pointer is 8300. So if you are developing in anything other than assembly, and aren't careful it is pretty easy for this to just crash your program on a 4A.. You do have to coerce it into nearly the first instructions for it to be benign on a 4A. 

[+arcadeshopper]

Sounds like we need a new exec

Sent from my LM-V600 using Tapatalk

[+jedimatt42]

4 minutes ago, Vorticon said:

I was wondering if someone could do a quick check for me.

With the TIPI-PEB in place, can you access the PHYSICAL drives (DSK1-3) from the EA module option #5? This is not working for me although option #3 does work. No issues with XB either. The only way to load an option #5 program (memory image) from the physical drives on a diskette is to use the LOAD command from within FC... If I take out the TIPI, then everything goes back to normal.

 

 

 

Weird, and relevant  let me check.

 

[+jedimatt42]

13 minutes ago, Vorticon said:

I was wondering if someone could do a quick check for me.

With the TIPI-PEB in place, can you access the PHYSICAL drives (DSK1-3) from the EA module option #5? This is not working for me although option #3 does work. No issues with XB either. The only way to load an option #5 program (memory image) from the physical drives on a diskette is to use the LOAD command from within FC... If I take out the TIPI, then everything goes back to normal.

 

 

 

I just loaded DSK1.DM2K from my FlashFloppy-Gotek via EA5 ( from original EA grom in a supercart ) - TIPI is in system, DSK1 is not mapped. 

 

(and with DSK1. mapped, it still worked, as when LVL3 ops can't find the file, TIPI allows it to run down the chain. )

 

Do you have a crubase conflict with the TIPI and the Floppy controller? 

Edited December 20, 2020 by jedimatt42

[wolhess]

I can run EDIT40 from physical disk drive 1-3, from tipi maped DSK4. and from Ramdisk DSK5.

 

All running with TI Editor/Assembler Option 5  without a problem.

 

 

 

Wolfgang

[+InsaneMultitasker]

EXEC is not a replacement for TI emulation (GPL) nor was that ever its intent.  EXEC provides a method to load most option 5 programs from the Geneve OS command line.    If a Geneve user wants to play in TI-emulation land where GROM and ROM are expected, GPL is the way to go.  If someone wants to re-enter GPL quickly, use GPL Cheater.  For further discourse I suggest moving the Geneve-specific items to another topic.

56 minutes ago, mizapf said:

Nope. That's called adaptability.

Many Geneve and TI programs over the years have required fine-tuning for hardware compatibility reasons, whether due to conflicts, enhancements, and/or not following prior 'practices'.  The Geneve is just another spoke on the same wheel.  Nothing new to see here. 

[+jedimatt42]

27 minutes ago, InsaneMultitasker said:

EXEC is not a replacement for TI emulation (GPL) nor was that ever its intent.  EXEC provides a method to load most option 5 programs from the Geneve OS command line.    If a Geneve user wants to play in TI-emulation land where GROM and ROM are expected, GPL is the way to go.  If someone wants to re-enter GPL quickly, use GPL Cheater.  For further discourse I suggest moving the Geneve-specific items to another topic.

Many Geneve and TI programs over the years have required fine-tuning for hardware compatibility reasons, whether due to conflicts, enhancements, and/or not following prior 'practices'.  The Geneve is just another spoke on the same wheel.  Nothing new to see here. 

But from a system architecture point of view this request is distributing the solution to all software instances, instead of accepting the existing... what is it? F5 instead of <enter> option to run in a compatible mode. Or stepping up and building a generalized solution to a problem that can be centralized. 

 

Someone could write an EA5 Loader that is an EA5 loadable program, that maps the DSR space in, then loads the binaries, and runs... Or.. another that loads the binaries, then maps the DSR space in, and then runs...

These things can have some big ol' hex-editable string at the end with the path to , or someone could write a program that creates customized instances of it to load your ROMPAGE requiring programs... (Like the scratchpad loader, for instance, or as a starting place)

 

You could also improve BOOT or whatever it is called when run on the Geneve, to have such an option built into its EA5 loading functionality.. Or a sub-boot, that does this for all things it loads, so ROMPAGE requiring stuff sits on a sub-menu... or write a new menu.. 

 

Any of those solutions would be FAR more enabling.

 

---

And if anyone is looking at me like : "You have a Geneve, why don't you do this?" - I just can't figure out why I would want to turn it on, and I have spent a great deal of effort trying.

 

 

 

 

Edited December 20, 2020 by jedimatt42

[+InsaneMultitasker]

1 hour ago, jedimatt42 said:

But from a system architecture point of view this request is distributing the solution to all software instances, instead of accepting the existing... what is it? F5 instead of <enter> option to run in a compatible mode. Or stepping up and building a generalized solution to a problem that can be centralized. 

Ah.  I was not touting the >BA/rompage solution as it often creates as many problems as it solves; rather, I was trying to convey my agreement  with the general comment about adaptability. Unfortunately for the Geneve this is often an uphill battle, which is in part what keeps me (and I suspect others) engaged and interested.  It is a hobby after all, even if it seems like work some days. 

[+Vorticon]

5 hours ago, wolhess said:

I can run EDIT40 from physical disk drive 1-3, from tipi maped DSK4. and from Ramdisk DSK5.

 

All running with TI Editor/Assembler Option 5  without a problem.

 

 

 

Wolfgang

Yes, but did you try using a real disk drive with an EA5 program on a diskette and loading it from the EA module directly?

[+Vorticon]

5 hours ago, jedimatt42 said:

 

I just loaded DSK1.DM2K from my FlashFloppy-Gotek via EA5 ( from original EA grom in a supercart ) - TIPI is in system, DSK1 is not mapped. 

 

(and with DSK1. mapped, it still worked, as when LVL3 ops can't find the file, TIPI allows it to run down the chain. )

 

Do you have a crubase conflict with the TIPI and the Floppy controller? 

The disk controller is at 1100 and TIPI is at 1000. Weird... And I don't honestly remember is it was working previously or not after I got the TIPI. Why would this be isolated to the EA option 5 though??? It works with EA option 3, XB, DM2K etc... A real head scratcher...

[+jedimatt42]

3 minutes ago, Vorticon said:

The disk controller is at 1100 and TIPI is at 1000. Weird... And I don't honestly remember is it was working previously or not after I got the TIPI. Why would this be isolated to the EA option 5 though??? It works with EA option 3, XB, DM2K etc... A real head scratcher...

maybe there is some hint in the /var/log/tipi/tipi.log if you can capture that when the EA5 from EA is failing? we can see if TIPI is interferring... It should say something like 'skipping' and then things go on to the floppy controller...

 

Which floppy controller BTW? 

[+Vorticon]

13 minutes ago, jedimatt42 said:

maybe there is some hint in the /var/log/tipi/tipi.log if you can capture that when the EA5 from EA is failing? we can see if TIPI is interferring... It should say something like 'skipping' and then things go on to the floppy controller...

 

Which floppy controller BTW? 

I checked the log and there is nothing unusual in there. On the other hand, I switched out my FG for a real EA module and now the physical drives are accessible again, so it looks like TIPI does not like the EA II image I have on the FG. What was different with that EA version again?