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

[+jedimatt42]

So, @jrhodes asked if it was possible for TIPI to act as the cassette storage device as well. I always assumed due to some mis-reading of the console rom, that the GROM DSRs were looked at first, and then the expansion card ROMs... but that isn't true.

 

The console DSRLNK does go to expansion cards first, and then falls back on the GROM list. 

 

So, it is totally possible with a small change to the TIPI DSR ROM to include a device name for CS1, that the TIPI can service the PAB request first. And the TIPI can reject the request if not configured for it, return the to DSRLNK to resume scanning for other devices that might service CS1 and the real GROM CS1 device will be found and allowed to continue. Just like when DSK1 directories are not mapped...

 

There is at least one program that only supports CS1. Milton Bradley's Hangman. 

 

My implementation just delegates to TIPI's handling of a file in the TIPI. filesystem. All the weird things like loading Tidbit source as a BASIC Program Image file works for CS1 if that's what you map it to. There will be no prompts to rewind

 

I've added a setting in PI.CONFIG - CS1_FILE which should be set to the file name you want CS1 to read or write to. If it is empty, then no mapping is made, and the GROM DSR will kick in. I've updated TIPICFG so you can set this from the 4A easily. I have also updated the TIPI Web UI. There are some screen shots below. I'd be interested if anyone has a more intuitive recommendation for managing this. Maybe I'll through the word 'file' in there a few times to make it more clear it's not the same as all the DSK dir mappings. 

 

Feedback, and other thoughts are welcome. 

 

(Use of this feature will require a TIPI ROM upgrade, and TIPI services upgrade. TIPI services upgrade will not require the ROM upgrade, but the CS1 feature will simply not work.)

 

---------

Here if CS1 is unmapped, you'll see a text box next to it so you can set the CS1_FILE mapping to whatever name or path you want. This should be a TI type path with '.' for directory separators, etc... and it should represent a file, not just a directory like the other mappings. Enter something, hit 'save' and your next interactions with CS1 will create or use that file.

 

 

 

Alternatively you may navigate to a file in the TIPI filesystem, select it, and then use the Action dropdown to choose 'Map to CS1', and submit... 

 

 

 

When it is set, you'll see the value. To unset the mapping, just click the red X next to it.

 

 

 

[+jedimatt42]

What kind of trouble would I cause if I added DSK5-9?

 

Would it create coexistence issues with an HRD?

[+jedimatt42]

Plowing ahead.

[+InsaneMultitasker]

If you are referring to adding DSK5-DSK9 to the TIPI DSR EPROM, coexistence will depend on the user's configuration and their program usage.  A few thoughts come to mind: 

 

With the /4A, the Horizon Ramdisk and its "partitions" are typically formatted starting with DSK5. to fully avoid conflicts with the floppy controller devices DSK1-4.  Devices DSK6-9 and DSKA-Z are also available to the Ramdisk.  If you are looking to expand the TIPI to emulate DSK5-9, the Horizon Ramdisk user can avoid conflicts by using Ramdisk drive letters A-Z.  Programs that are CRU-aware - such as FC or DU2K - become important for level 2 IO if there is a need for a Ramdisk device to use DSK5-9.   I don't know if any /4A users with both the TIPI and Ramdisk hardware use programs that do not allow DSK A-Z, with a need for Ramdisk drives 5-9.

 

The Geneve's boot EPROM reserves DSK6. for a Horizon Ramdisk boot device.  I cannot think of any other conflicts, since the Geneve OS manages its devices internally without utilizing the on-card DSR EPROMS. Theoretically, if the TIPI DSK6. mapping is not enabled and the TIPI DSR fails through to the next device, I doubt there would be any issues with the bootup sequence. 

 

[jrhodes]

@jedimatt42 Would it be possible to have added into TIPI's web interface, a option to make a .dsk image and download it to PC, from a selected directory containing TI files and a Sectors file?

 

I.E. if you had a folder name TEST with PROGRAM and a Sectors file, you could download a TEST.dsk file that should contain all TI data, whether stored in TI files/programs or raw on the disks sectors.

[+Vorticon]

On 12/27/2023 at 8:07 AM, jrhodes said:

@jedimatt42 Would it be possible to have added into TIPI's web interface, a option to make a .dsk image and download it to PC, from a selected directory containing TI files and a Sectors file?

 

I.E. if you had a folder name TEST with PROGRAM and a Sectors file, you could download a TEST.dsk file that should contain all TI data, whether stored in TI files/programs or raw on the disks sectors.

That would actually be a great added functionality. 

[+arcadeshopper]

On 12/27/2023 at 2:07 PM, jrhodes said:

@jedimatt42 Would it be possible to have added into TIPI's web interface, a option to make a .dsk image and download it to PC, from a selected directory containing TI files and a Sectors file?

 

I.E. if you had a folder name TEST with PROGRAM and a Sectors file, you could download a TEST.dsk file that should contain all TI data, whether stored in TI files/programs or raw on the disks sectors.

 you are going to be limited to the size of disks for the data in the directory this seems to be a complexity

[+Vorticon]

7 hours ago, arcadeshopper said:

 you are going to be limited to the size of disks for the data in the directory this seems to be a complexity

Not necessarily. The utility would have a disk size specification switch (90, 180, 360) and it would write as many files sequentially as would fit on the disk. It would then be up to the user to make sure the directory used has the correct number of files in it. Obviously such a utility would likely need to perform a format procedure first as well, something Matt might actually be considering. 

 

[+jedimatt42]

TIPI already has a total sector size setting, but sure a drop down to pick wouldn't be hard. If a .sectors already exists, It should respect that.

 

The harder part is merging files in the sector dump with the loose TIFILES. So I'd probably have to provide a selection form, with defaults selection of files to override the sector dump based on timestamp.

[+retroclouds]

Quick question on TIPI VDP memory usage: Does the TIPI DSR use VDP memory besides the memory specified in the PAB header or record/file buffer?

Is there anything in the TIPI DSR that writes to the VDP >0980 memory range?

 

Reason I'm asking is because I'm refactoring VDP memory usage in Stevie. I'm trying to make free space for FIO level 3 opcode 5 loading EA#5 image.

Works fine with ROS (which is not using any VDP memory at all I guess). And having some issues with especially the TI Disk Controller and a little with the TIPI controller as well.

 

Edited April 2 by retroclouds

[+jedimatt42]

The TIPI DSR only uses the VDP memory that your PABs tell it to use. 

 

If at crubase 1100 it will adjust the system VDP stack on console power up/reset just like a TIFDC does. But it does not use that space. It does this for compatibility with The Missing Link.

 

 

[+9640News]

 

@jedimatt42

 

I can find no indication this has been implemented looking at the Eprom source code.  In the Myarc HFDC manual, the Level 1 and Level 2 commands have the ability to transfer directly to CPU instead of VDP if the MSB byte is set in the Unit Number.  At least that is what it says in the Myarc HFDC manual.

 

I don't know if this is supported with the current TIPI Eprom, so my thinking is this may be an eprom upgrade request if that is the case.  I know the eprom has the ability to send/receive data with the SNDMSG/RCVMSG routines to VDP or CPU, but it looks like that capability is not available with the current Eprom revision.

 

Now, I realize anyone making use of this would be coding something for specific use with the TIPI.  Where I believe a benefit for the Geneve would be directly loading MDOS straight to CPU rather than buffering through VDP before copying then to CPU.  Thus, faster booting times.

 

With the TIPI, I could imagine if someone implemented it, someone could transfer data from the TIPI straight to RAM, and with the SAMS, that would be even faster.

 

Beery

[Gary from OPA]

18 minutes ago, 9640News said:

 

@jedimatt42

 

I can find no indication this has been implemented looking at the Eprom source code.  In the Myarc HFDC manual, the Level 1 and Level 2 commands have the ability to transfer directly to CPU instead of VDP if the MSB byte is set in the Unit Number.  At least that is what it says in the Myarc HFDC manual.

 

I don't know if this is supported with the current TIPI Eprom, so my thinking is this may be an eprom upgrade request if that is the case.  I know the eprom has the ability to send/receive data with the SNDMSG/RCVMSG routines to VDP or CPU, but it looks like that capability is not available with the current Eprom revision.

 

Now, I realize anyone making use of this would be coding something for specific use with the TIPI.  Where I believe a benefit for the Geneve would be directly loading MDOS straight to CPU rather than buffering through VDP before copying then to CPU.  Thus, faster booting times.

 

With the TIPI, I could imagine if someone implemented it, someone could transfer data from the TIPI straight to RAM, and with the SAMS, that would be even faster.

 

Beery

It would be great if it supported the direct to CPU for transfers. The horizon Ramdisk does, and I used that feature many times for my programs. And also when I used to have a working mfm drive for my hdfc. Thinking of this does the Scsi DSR support it?

[+jedimatt42]

It's possible with a DSR change... The spec was a little spread out amongst the HFDC manual, the couple times I've seen it. 

[+InsaneMultitasker]

I seem to recall that Fred documented the pab and buffer bit settings on his project page.  He and I conversed about this long ago when he added some cpu-ram support to his DSRs. 

[Gary from OPA]

3 minutes ago, InsaneMultitasker said:

I seem to recall that Fred documented the pab and buffer bit settings on his project page.  He and I conversed about this long ago when he added some cpu-ram support to his DSRs. 

There is three different CPU parts instead of using VDP ram for DSR stuff.

 

1: VDP for PAB but CPU used for DATA transfers (high-level functions) - open/read/write/close file functions.

2: VDP for PAB but CPU used for DATA transfers (low-level functions) - read/write disk sectors, etc.

3: CPU for PAB plus CPU used for DATA transfers for low-level functions.

 

I will look later on for all the info on how it is set, but part of its covered in the Horizon ros 8.14f manual as well. and i will see if I can find some sample source code of each usage.

[+jedimatt42]

I think the thing that I got hung up on when working on TIPI in the early days, as Tim has talked to me about this before, was how to tell ( as a client of the DSR ) if you can use a CPU buffer or if a VDP buffer is required... This doc is pretty clear about most if not all of it... https://ftp.whtech.com/datasheets and manuals/Hardware/Myarc/MYARC HFDC Manual 4th edition.pdf <- re-reading.

 

I was browsing the HFDC manual for other reasons the other day, and the best I could tell, for sector-read/write and Level 2 management routines, is that maybe, since the 'cpu buffer' flag is packed into the unit number, if the card doesn't support it, it would presumably error with a DEVERR for a bad unit number.  And then, the client would have to try again with the legacy VDP buffer approach.  Is there a convention that has been adopted, or spec'ed, for deciding how to interact with a device based on some runtime available indicators?

 

 

[+jedimatt42]

So, if I implement CPU PABs and CPU Buffers, I have to first implement a client, such as updating ForceCommand to support this for HFDC, and HRD, and TIPI... and have my DSR interactions work for TIPI's without support for CPU PABs and CPU Buffers, as 95% of the population won't update the EPROM.

 

I can craft a signature to identify in the TIPI ROM, but do I just assume that all HRD's support it, and all HFDC's support it? So, if crubase has device 'WDS1" for HFDC, I don't know what provides a signature for an HRD...  does it have a unique device name, or lvl2 io sub-program name? 

[+9640News]

18 hours ago, jedimatt42 said:

So, if I implement CPU PABs and CPU Buffers, I have to first implement a client, such as updating ForceCommand to support this for HFDC, and HRD, and TIPI... and have my DSR interactions work for TIPI's without support for CPU PABs and CPU Buffers, as 95% of the population won't update the EPROM.

 

I can craft a signature to identify in the TIPI ROM, but do I just assume that all HRD's support it, and all HFDC's support it? So, if crubase has device 'WDS1" for HFDC, I don't know what provides a signature for an HRD...  does it have a unique device name, or lvl2 io sub-program name? 

Here's my take, and I welcome others with their options to comment as well.

 

It is true it is documented in the Myarc HFDC manual, and I was not aware the HRD had the potential. It also was not a TI specification. I did know the HRD one could page things in on the 4A and directly copy from HRD memory to CPU, but did not know the DSR for the 4A support had that capability until @Gary from OPA mentioned it.

 

Anyone using the direct to CPU capability with the HFDC, HRD, and/or if you choose to support with the TIPI would be writing very specific software for a very specific need or application.  And those individuals writing such software would be responsible for testing the installed hardware for the capability and respond accordingly. Testing the version byte at >4001 would be all that is necessary to determine if they had an upgraded TIPI eprom.

 

In the case of the Geneve, the advantage is one could have a Geneve and boot from the TIPI faster.  The savings  in time due to increased speed would be the time to copy 136K from VDP to CPU.  After MDOS is booted, the Geneve already supports reading from TIPI to CPU and/or VDP in MDOS mode.  Presently in GPL mode on the Geneve, everything is straight to VDP unless in ROMPAGE modeand the eprom were updated.

 

So my thoughts, if you choose to accept the mission <grin>, is go "simple".  Looking through the TIPI eprom code, if I am not mistaken, there would just need to be a test for the MSB of the unit number and use the send/receive CPU message calls instead of the VDP message calls.  I haven't dug that deep into the source yet, but that was my initial thought.  My first thoughts were to run it by you to get your feedback and/or support, etc.

 

I don't know about the innerworkings of ForceCommand to know any coding/support would need to be dependent upon ForceCommand, or if it would need to be programmer and application specific to use the capability.

 

Beery

 

[+dhe]

1 hour ago, 9640News said:

and I welcome others with their options to comment as well.

My option is, it would be a killer feature!

[+InsaneMultitasker]

A few thoughts and opinions that come to mind, mostly from the perspective of writing a program with the intent of using CPU buffers and PABs. 

 

VDP PABs and buffers "just work"; their usage is ubiquitous and well-known.  CPU buffers are great for avoiding the VDP passthrough; CPU PABs aren't as easy to implement nor are they as worthwhile.

 

My suggestion is that if you are considering adding CPU extensions, start with CPU buffer support. This is the most 'bang for the buck' and relatively easy for programmers to implement. 

 

Since we know that the HFDC, SCSI, and IDE devices support CPU transfers, the programmer can test the device name (WDS, SCS, IDE) or subprogram (>2x, >2x, >8x); if there is a match, use a CPU buffer.  The CPU implementation path is relatively straightforward.

 

For the TIPI, a unique signature might be as simple as leveraging the DSR version byte.  The programmer would test both the version byte and the device name/subprogram. Almost as easy as the HFDC/SCSI/IDE CPU method.   I would think that the TIPI emulated "DSKx" devices and TIPI >1x subprograms would require some additional attention, though for ForceCommand, if you are already accessing the device by CRU address+device, it may be very straightforward.

 

For the "DSK" devices, testing the device name or subprogram (>1x) is insufficient. There is no clean method (that I know of) to determine whether the peripheral supports CPU-based access. Looking for a unique signature (devicename, subprogram) in the EPROM or polling the cards' CRU bits/ram may help determine the card type.  Do existing DSRs generate an error or skip to the next device if the CPU bit in the opcode is set and is unsupported?  If so, is this enough information for the programmer/program to select the CPU or VDP buffer?

 

Lastly, the standard DSRLNK expects a VDP-based PAB. For the PAB to reside completely in CPU RAM, an updated DSRLNK is required. Nice to have, though I'm not convinced it is worth the effort to implement in the DSR and certainly harder to use in a program that requires both VDP and CPU paths for overall compatibility. 

[+jedimatt42]

I am intrigued enough to give this a go.. But the Geneve use case seems like a small gain... how long does a Geneve take to copy 130k from VDP to CPU pages? 2-3 seconds? How long does it take to load from TIPI without the optimization? Are you all wanting to save 1% of the load time? 

 

The actual fastest way to get MDOS loaded would be to write a TIPI loader that skips the DSR and just uses the TIPI messaging routines in the ROM to make the block read requests. 

 

 

 

 

 

[+jedimatt42]

Oh, I still have a question from several posts earlier... How do I detect that I'm looking at an Horizon Ram Disk (HRD) ?  or more directly, ROS with CPU buffer support?  

[Gary from OPA]

33 minutes ago, jedimatt42 said:

Oh, I still have a question from several posts earlier... How do I detect that I'm looking at an Horizon Ram Disk (HRD) ?  or more directly, ROS with CPU buffer support?  

All ros from 8.14f and newer should support cpu buffer space. As how to tell if the dskx. Is horizon or normal disk you need to look at the dsr for key bytes. See the cfg source for horizon on how it detects what card is which. And it works the same as Myarc specs when msbit set then it's cpu operation for low level subroutines. If it doesn't support it should return as error but I never tested that by using a original ti controller or corcomp which doesn't support those modes.

 

See page 18 of the users manual for a bit more info.

https://github.com/horizonramdisk/Horizon-Ramdisk-ti994a/blob/master/Tech Docs/HORIZON RAMDISK USER OPERATING MANUAL 9-12-2023.pdf

 

Edited May 5 by Gary from OPA

[+9640News]

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 ?