Jump to content
IGNORED

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


Recommended Posts

12 minutes ago, 9640News said:

I found this on page 18 of the manual referenced:

 

This format is compatible with the cpu buffer addressing used by the Myarc floppy controller, Myarc hard and floppy controller, IDE controller, and HDX controller. For example: if the opcode byte contains >42 instead of the normal >02, then the ROS will read the record into CPU RAM instead of into VDP RAM.

 

Something I did not expect.  Shouldn't the opcode byte be >82 and not >42 ?

 

 

Opcodes are the 'read' 'write' 'load' etc, not the LVL 2 IO 'subprogram' names. So they are things like >02 and then with the 'second highest' bit set, it becomes >42. 

  • Like 1
Link to comment
Share on other sites

Posted (edited)
31 minutes ago, 9640News said:

I found this on page 18 of the manual referenced:

 

This format is compatible with the cpu buffer addressing used by the Myarc floppy controller, Myarc hard and floppy controller, IDE controller, and HDX controller. For example: if the opcode byte contains >42 instead of the normal >02, then the ROS will read the record into CPU RAM instead of into VDP RAM.

 

Something I did not expect.  Shouldn't the opcode byte be >82 and not >42 ?

 

Must be a typo. As the original ros manual is a very bad scanner version.

 

Here is the related source code section:

*****************************
* ROS MUD Misc Unfixed Data * #7
*****************************
ERR4   EQU  $                 ERROR: Diskette full
ST0    DATA >8000             Used to check BIT #0
******************************
* Link to >10,11,12,13,14,15 *
******************************
TEST   LWPI HIWS              Load our workspace
       MOV  @SRHADR,R1        Get pointer to CALL table
       MOV  @6(R1),R11        Get address of CALL program
       MOVB @>834C,R2         Get drive # for this CALL
       CLR  @VDPCPU           Assume VDP transfers
       COC  @ST0,R2           Check if MSBit is SET
       JNE  WNUMB             Nope, so use VDP transfer mode
       SETO @VDPCPU           Yep, so switch to CPU transfers
       SZCB @ST0,R2           Clear flag to get correct drive #

 

Edited by Gary from OPA
Link to comment
Share on other sites

Looks like the conversation is conflating the opcodes and the level 2 subprograms.  The code snip above is level 2.  

 

See link to the ROS level 3 opcode entry point. 

 

https://github.com/horizonramdisk/Horizon-Ramdisk-ti994a/blob/7672a794f1707b1ed195fbcf9430f08af37d422e/ROS/ros-s.txt#L643C1-L654C57

 

The manual is correct.  The current document is not a scan - it was typeset and reworked as part of the Horizon 4000 effort with @Ksarul and @FALCOR4

https://github.com/horizonramdisk/Horizon-Ramdisk-ti994a/tree/7672a794f1707b1ed195fbcf9430f08af37d422e/Tech Docs

  • Like 1
Link to comment
Share on other sites

16 minutes ago, InsaneMultitasker said:

Looks like the conversation is conflating the opcodes and the level 2 subprograms.  The code snip above is level 2.  

 

See link to the ROS level 3 opcode entry point. 

 

https://github.com/horizonramdisk/Horizon-Ramdisk-ti994a/blob/7672a794f1707b1ed195fbcf9430f08af37d422e/ROS/ros-s.txt#L643C1-L654C57

 

The manual is correct.

https://github.com/horizonramdisk/Horizon-Ramdisk-ti994a/tree/7672a794f1707b1ed195fbcf9430f08af37d422e/Tech Docs

yes, seems there is some confusing on which opcodes and level we talking about. I guess the manual doesn't mention both versions, depending on the level being used. i need to print it out, i hate reading pages of pdf on the monitor screen.

 

So to be clear, low-level operations, disk read/write by sectors, etc. it is the most msbit >8x set.

But for normal file operations, open/read/write/close files, it is the second msbit >4x set.

 

**************************
* DSK./DSKx. ENTRY POINT *
**************************
DSTRT0 BL   @WNUMB            INIT THE DRIVE
       BL   @PADLP            Pad the name, and write it!
       CLR  R1                Make sure below calcs work!
       MOVB @PAB,R1           Get the DSR OPCODE
       CLR  @VDPCPU           Assume VDP transfers
       COC  @ST1,R1           Check if second MSBit SET
       JNE  DSTRT1            Nope, so use VDP transfer mode
       SETO @VDPCPU           Yep, so switch to CPU transfers
       SZCB @ST1,R1           Clear the flag from the OPCODE
DSTRT1 SRL  R1,7              Make it a word and * 2
       CI   R1,>C*2           If OPCODE higher than >C
       JGT  NOTFND            Then switch to the next card!
       MOV  @OCODE(R1),R11    Else get address of OPCODE program
       RT                     EXECUTE THE OPCODE

 

Link to comment
Share on other sites

  • 1 month later...

Status update, cause if I was at the zoom call today @dhe would ask :)  - I've implemented the LVL2 cpu buffer DSR support for all the sector-io, direct-input/output, and dir/filename operations. This was a pretty small code change overall. 

 

Looking at the PAB operations ( lvl 3 ) opcode read, write, load, save are implemented. open, close, and others don't use any buffering. The filename is in VDP still, as is the PAB itself. 

 

I know I said the Myarc HFDC doc was perfectly clear, but I lied. Page 55 ( version 4 ) says the the CPU RAM PAB has a subset of the 9640 PAB layout, and shows a table that is not parallel to the VDP pab layout on a 4A. And then is followed by a sentence completely contradicting that. I would read "The content of the CPU-only PAB is the same as the VDP-only PAB except for the VD/CPU flag..." as having the same structure... maybe content means the individual fields have the same value criteria as their same named counterparts?  IDK... I'm inclined to ignore the CPU PABs, they seem like a solution looking for a problem, while promoting creation of problems, like software that only works on hard drive like devices and no longer works on TI floppy controllers without significant burden to the application programmer. 

 

Anyway, I've written the DSR ROM code, I haven't tried testing it yet. I've also dabbled at updating force-command to leverage this feature... but there is a lot more work to do.

  • Like 6
Link to comment
Share on other sites

@dhe

 

I have already updated the TIPI LOAD-TIP file to be multi CRU aware.  Modification to make direct CPU transfer will be fairly simple as it will pretty much involve commenting out code rather than adding any code. So, when Matt is happy with his code, it should not take long to test things.

 

Beery

 

  • Like 2
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...