Jump to content
IGNORED

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


Recommended Posts

1 hour ago, RXB said:

RXB SOURCE same as XB:


[0149] 8345          FLAG   EQU  >8345            General 8-bit flag

[0262] 03B9          SAPROT EQU  >03B9             PROTECTION flag in SAVE

[1974] 8C15 86,45    G8C15  CLR  @FLAG             Otherwise clear protection

[2047] 8CBD 86,45    G8CBD  CLR  @FLAG             Otherwise clear protection flag

[2215]               * Has to be PROTECTED option here, crunched as unquoted str
[2216] 8DF4 D7,B0,2C G8DF4  DCEQ >C809,V*PGMPTR    Unquoted string with length 9
       8DF7 C8,09
[2217]               *                              has to be PROTECTED
[2218] 8DF9 41,09           BR   ERRSYN
[2219] 8DFB D7,E0,02        DCEQ >5052,V@2(@PGMPTR) "PR" of PRotected
       8DFE 2C,50,52
[2220] 8E01 41,09           BR   ERRSYN             If not : SYNTAX ERROR
[2221] 8E03 D7,E0,04        DCEQ >4F54,V@4(@PGMPTR) "OT" of prOTected
       8E06 2C,4F,54
[2222] 8E09 41,09           BR   ERRSYN             If not : SYNTAX ERROR
[2223] 8E0B D7,E0,06        DCEQ >4543,V@6(@PGMPTR) "EC" of protECted
       8E0E 2C,45,43
[2224] 8E11 41,09           BR   ERRSYN             If not : SYNTAX ERROR
[2225] 8E13 D7,E0,08        DCEQ >5445,V@8(@PGMPTR) "TE",of protecTEd
       8E16 2C,54,45
[2226] 8E19 41,09           BR   ERRSYN             If not : SYNTAX ERROR
[2227] 8E1B D6,E0,0A        CEQ  >44,V@10(@PGMPTR)  "D" of protecteD
       8E1E 2C,44
[2228] 8E20 41,09           BR   ERRSYN             If not : SYNTAX ERROR
[2229] 8E22 8E,E0,0B        CZ   V@11(@PGMPTR)     Check EOL
       8E25 2C
[2230] 8E26 41,09           BR   ERRSYN
[2231] 8E28 90,A3,B9        INC  V@SAPROT

XB protection flag is at Hex >03B9 or Decimal 953 the flag named is SAPROT also set by flag named oddly FLAG

 

CALL POKEV(953,0) ! Unprotects file and clears SAPROT flag

CALL POKEV(953,1) ! Protects file and sets SAPROT flag

 

XB does not have a CALL POKEV command so you are screwed in XB.

 

 

We are talking about the FDR attribute of a file, not the XB flag. in the manual: "TI Extended BASIC", page 163, the reference for SAVE in Chapter 4, subsection 'options', second paragraph:

Quote

 

... This is not the same as using the protection available with the Disk Manager module.


 

 

It is the protection available with the Disk Manager module that we are discussing... not the SAVE PROTECTED option that those pokes manipulate.

 

We are trying to discuss the thing that has to do with disk controller level stuff.

 

Well, except we are done discussing it.

 

The summary: TIPI doesn't support the disk manager protection feature, except to set and unset it. It fails to enforce it. Enforcing it could be a good thing, which I've filed as an issue in the project github repository. Native files (things not in TIFILES format) on linux are treated as read-only ( mostly ) and it could clarify things to users, if TIPI reported them as protected ( P ) in the catalog records it generates at the disk controller level. And if it uniformly enforced the protection.

 

 

 

Link to comment
Share on other sites

I made a upgraded version of the Disk Manager Module too.

It handled RAMDISK like DSKA. or Disks 1 to 9 too.

That would be a better upgraded Disk Manager Module then the one I see people use.

RXB 2012 also had a routine to strip all Protections off disk files on a disk and make a unprotected disk copy sector by sector.

 

How come TIPI does not support that option, it is only 1 byte flag?

Link to comment
Share on other sites

On 12/28/2020 at 10:00 AM, jedimatt42 said:

A nice way to tie some stuff together, would be for me to implement this protect flag properly and report all the magic native conversion type files as protected, since they are implicitly already, but the error handling is ... made up. 

So you need to look up the standard error handling instead of just making up you own?

You could just us the TI OS it has most of those built in already.

Link to comment
Share on other sites

1 hour ago, RXB said:

So you need to look up the standard error handling instead of just making up you own?

You could just us the TI OS it has most of those built in already.

 

If it worked that way, wouldn't that be nice... I refer you to the developers resources thread, where all the documentation and specifications for most aspects of the 4A architecture are linked.  My statement about 'made up' was flippant, and not accurate.

 

I don't think you understand what TIPI is... 

 

I have adhered to the specifications of the 'TI OS' as much as practical... but as noted earlier, my copy was missing pages.

  • Like 5
Link to comment
Share on other sites

Don't know if this has been already reported and fixed in the past, so please ignore if necessary:

 

The config program ("CALL TIPI") locks-up if the URL in URI1 is too long. Just verified it again. Had to ssh into the PI and edit the tipi.config manually to make it work again.
After I removed the URL and restarted the TI-99/4a, the config started responding normally again.

 

Tested with TIPCFG v10, PI-Version 1.65 

 

The URL I used was: URI1=https://github.com/kl9900/TMS9900Family/blob/master/Consoles/TI-99/99-8/Rom/TXT

 

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

Don't know if this has been already reported and fixed in the past, so please ignore if necessary:
 
The config program ("CALL TIPI") locks-up if the URL in URI1 is too long. Just verified it again. Had to ssh into the PI and edit the tipi.config manually to make it work again.
After I removed the URL and restarted the TI-99/4a, the config started responding normally again.
 
Tested with TIPCFG v10, PI-Version 1.65 
 
The URL I used was: URI1=https://github.com/kl9900/TMS9900Family/blob/master/Consoles/TI-99/99-8/Rom/TXT
 
giphy.gif?cid=349c9dd7eg72gfnwrn1ams1cr1kh5yokoojy7w5xb7s0rmya&rid=giphy.gifHoly giant url batman

Sent from my LM-V600 using Tapatalk

  • Haha 3
Link to comment
Share on other sites

@retroclouds, I'll add it to github issues.  Along with the need to rework that. It hasn't handled long lines well - ever. You probably ran into a buffer overrun! Now can you use it to jailbreak your 4A? 

 

Back when I was writing TIPICFG, I now realize I almost never prevented buffer overruns in my 4A code.

 

(Ah, this is already recorded: https://github.com/jedimatt42/tipi/issues/141)

Edited by jedimatt42
  • Like 1
Link to comment
Share on other sites

  • 4 weeks later...
Hello all -
 
Just wondering: has anyone utilized the TIPI as a FP math coprocessor for the TI?  Seems like a natural fit, passing arguments and results back and forth by means of the messaging interface. 
 
 
Nope

Seems slow to use a hard disk as a fpu

Sent from my LM-V600 using Tapatalk

Link to comment
Share on other sites

2 hours ago, Reciprocating Bill said:

Hello all -

 

Just wondering: has anyone utilized the TIPI as a FP math coprocessor for the TI?  Seems like a natural fit, passing arguments and results back and forth by means of the messaging interface. 

 

 

 

People have asked about general computation facilities on the PI, and I have rejected that as crossing a line I am not interested in supporting.

 

What I think would be cool, is actual integration of an early 80s floating point coprocessor. There were general purpose FPUs not targeted to specific CPUs.

 

Link to comment
Share on other sites

8 minutes ago, jedimatt42 said:

 

People have asked about general computation facilities on the PI, and I have rejected that as crossing a line I am not interested in supporting.

 

What I think would be cool, is actual integration of an early 80s floating point coprocessor. There were general purpose FPUs not targeted to specific CPUs.

 

Matt, not disagreeing with you here, but does one even think by the time you pass the data back and forth from the TIPI through the messaging system that it would be quicker?  I ask because Lee took the floating point routines written in assembly for the Geneve XOP and ported them over into Forth on a TI-99/4A.  I would think something similar could be done and a floating point library saved to a SAMS page and likely be as quick.  

 

Maybe there are more involved math computations others are thinking about that would take more time, but throwing a different approach out there for others to consider as an option if they have something with a lot of math involved.

 

Beery

Link to comment
Share on other sites

You could easily use the F18A as a math co-processor. The speed of the GPU far outstrips the main CPU, and since you can code it in 9900 assembly, you could probably even port the console routines and patch the ROM to use them. You'd have to define a couple of VDP addresses for interface to it, but the code itself could live in the GPU extended 2k space, so you'd probably only need 8 bytes for a FAC and maybe one or two more for handshaking.

  • Like 4
Link to comment
Share on other sites

32 minutes ago, Tursi said:

You could easily use the F18A as a math co-processor. The speed of the GPU far outstrips the main CPU, and since you can code it in 9900 assembly, you could probably even port the console routines and patch the ROM to use them. You'd have to define a couple of VDP addresses for interface to it, but the code itself could live in the GPU extended 2k space, so you'd probably only need 8 bytes for a FAC and maybe one or two more for handshaking.

 

Interesting idea. The Floating Point Library alluded to by @BeeryMiller takes 5618 bytes (5.5 KiB) of ROM, so, to get that to work in 2 KiB of GPU would likely take some code swapping (overlays) or settling for a subset of functions that are the most compute-bound.

 

...lee

  • Like 2
Link to comment
Share on other sites

2 hours ago, jedimatt42 said:

 

People have asked about general computation facilities on the PI, and I have rejected that as crossing a line I am not interested in supporting.

 

What I think would be cool, is actual integration of an early 80s floating point coprocessor. There were general purpose FPUs not targeted to specific CPUs.

 

Something like the AM9511.

 

@pnr disassembled the 99000 macrostore ROM and did an excellent writeup of the floating point instructions

 

This code is 9900 and fits into 2K. It would run at half the speed inside a 4A ROM, worse in slow RAM. But in a F18A it could go much faster!

It does use IBM single precision, not RADIX 100. Suppose all the 4A routines in ROM were replaced by this? Would everything work after being on top of that layer?

 

 

@pnr   estimates the 99110 6MHz at 15 kFlops/s and concludes:

 

 

Quote

This compares well with the FPU chips of the late seventies and early eighties. The three main choices in 1981 were the AMD9511/i8231 from 1978, the AMD9512/i8232 from 1979 and the i8087 from 1980/81. The 99110 is from 1981 as well.

http://www.cpushack.com/2010/09/23/arithmetic-processors-then-and-now/

 

 

 

  • Like 1
Link to comment
Share on other sites

3 hours ago, BeeryMiller said:

Matt, not disagreeing with you here, but does one even think by the time you pass the data back and forth from the TIPI through the messaging system that it would be quicker? 

 

Beery

 

I'm saying I'm not interested enough to think about math over messaging at all.

Link to comment
Share on other sites

5 minutes ago, jedimatt42 said:

 

I'm saying I'm not interested enough to think about math over messaging at all.

No, that wasn't what I was trying to say or imply.  I was trying to imply I did not think the overhead of even using the TIPI  as a messaging system for such an idea would unlikely lead to an improvement in speed versus some assembly code that already exists and alerting other parties there may be other ways to skin the cat.

  • Like 1
Link to comment
Share on other sites

TIPI is a highly extensible bit of code, and people are free to extend it, but to be clear, I will reject PR's around pure computation. However, the instructions for installing on a fresh Raspbian are there. Anyone can take up distributing a fork. I have purposely licensed away my right to stop anything.

 

----

 

I really like the idea of loading up the F18A with 9900 assembly to do computational tasks. Even that probably has a bit of a barrier/cost. For IPC, you have to use mailboxes in VDP ram. I'm not sure how you know when the work in complete, except to keep it faster than you can ask. Someone could probably design a real nice software package to load in that has a little bytecode language and establishes a set of VDP RAM addresses that act as mailboxes to receive commands, and hold accumulated results. Issue one or more commands, then fetch results. 

 

Although, I really admire the 8 bit programmers that figure out how to solve the problem without even a multiply and divide instruction in their 6502s.

  • Like 2
Link to comment
Share on other sites

14 hours ago, BeeryMiller said:

No, that wasn't what I was trying to say or imply.  I was trying to imply I did not think the overhead of even using the TIPI  as a messaging system for such an idea would unlikely lead to an improvement in speed versus some assembly code that already exists and alerting other parties there may be other ways to skin the cat.

This would be worth testing. Check my reasoning:  Extended Basic performs 100 sines and cosines in a For-Next loop in about 15-16 seconds.  fbForth (to my surprise) isn't significantly faster performing the same calculations, using the Geneve-derived functions. Thats around 13-14 FP transcendentals per second - a LOT of assembly instructions per calculation.

 

Would shipping a couple of BCD arguments and an opcode to the PI through the registers on the TIPI, then retrieving results, be equally time consuming? From the perspective of the TI, the PI and Python calculations, exclusive of this overhead, would be next to instantaneous.

Link to comment
Share on other sites

15 hours ago, jedimatt42 said:

I really like the idea of loading up the F18A with 9900 assembly to do computational tasks. Even that probably has a bit of a barrier/cost. For IPC, you have to use mailboxes in VDP ram. I'm not sure how you know when the work in complete, except to keep it faster than you can ask. Someone could probably design a real nice software package to load in that has a little bytecode language and establishes a set of VDP RAM addresses that act as mailboxes to receive commands, and hold accumulated results. Issue one or more commands, then fetch results. 

Yeah, exactly. The main barrier is probably the need to use at least some VDP memory, and whether that's okay depends on the application. If your app is /written for/ the system, then you can choose, so even the 5k library mentioned above is potentially okay. We know from the CF7 that allocating a few extra bytes at the top of VDP works for /most/ software. ;)

 

If you don't want to assume performance, then sync is easiest with a pair of control bytes in VDP, which you would think of as control registers. I'd do one in to the GPU and out back out. But one could certainly get more clever than that.

 

The code @FarmerPotato mentioned is interesting though... ;)

 

Link to comment
Share on other sites

36 minutes ago, Reciprocating Bill said:

Would shipping a couple of BCD arguments and an opcode to the PI through the registers on the TIPI, then retrieving results, be equally time consuming? From the perspective of the TI, the PI and Python calculations, exclusive of this overhead, would be next to instantaneous.

I think you are missing one piece of the equation here.  That would be the processing necessary to get the data through the TIPI ports, and then the code waiting for the response back, and then transferring the data, that could have been spent processing the floating point operation.  Now, I don't know how many memory cycles it would take for straight assembly code, the F18A route, or the TIPI concept, but I would have thought dealing with straight assembly may have had the fewest cycles with all things considered.  That's just a guess though.

 

I think a card that just you gave it CPU memory pointers to the data and the instruction to be completed that I think what Matt eluded to earlier would be the direction that would be the fastest.  There, I would envision a fast chip would give you the answer back in maybe the fewest clock cycles????

 

Just guessing.  I am sure some of the coding could be streamlined to minimize loops and calls.

 

Beery

 

Link to comment
Share on other sites

1 hour ago, Reciprocating Bill said:

This would be worth testing. Check my reasoning:  Extended Basic performs 100 sines and cosines in a For-Next loop in about 15-16 seconds.  fbForth (to my surprise) isn't significantly faster performing the same calculations, using the Geneve-derived functions. Thats around 13-14 FP transcendentals per second - a LOT of assembly instructions per calculation.

 

Most of the FPL code ported from the Geneve L10 library was ported from the TI-99/4A console ROM ALC and GROM(s) GPL. The console ROM code functions (FADD FSUB FMUL FDIV FCOM CSN CFI CIF) execute on the 16-bit bus in XB, which is faster than the ROM code in fbForth, which executes on the 8-bit bus. Those functions executing in GPL (CNS INT ^ SQR EXP LOG COS SIN TAN ATN) will be slower in varying degrees, depending on how much code of each function is actually executing console ALC.

 

...lee

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...