Jump to content
IGNORED

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


Recommended Posts

@jedimatt42 I have a Pi hat and I’m wondering if I can write a DSR for it. Without any changes to the TIPI itself.
 

So I thought of creating a socket interface to the Hat on Linux. Then the TI accesses it as a file like TIPI.TCP=
 

I did not think a DSR could call other DSRs, so I looked into using the Pi message interface directly. Then I saw that you left a subroutine entry point table!

 

calling the console DSRLNK… scary. I suppose it’s easier to devise a scanning routine that fits into FAC. Something kludgy that expects to find the first device name=TIPI. 
 

however, I just realized that I can’t plug in both the Hat and the TIPI interface. Duh. 
 

So this is not going to work. 


 

  • Like 1
Link to comment
Share on other sites

The TIPI uses a small subset of the PI's GPIO for the purpose of allowing extension in the field.

 

Also, without any modifications of the DSR ROM, the PI. device capabilities can be expanded with simple python additions - ~/tipi/services/SpecialFiles.py

 

This is how I provided things like PI.PIO without a ROM update.

  • Like 2
Link to comment
Share on other sites

11 hours ago, jedimatt42 said:

What kind of hardware wants to couple itself to TIPI?

a Pi Hat! I’ve worked out how to disable the pins that Tipi shared. So I need to unsolder the header and use tall stacker header on those 10 pins. Actually that will make room for the Tipi IDC connector to fit better. 
 

Quote


 

 

---

I would think (guessing) the smallest RAM usage to detect TIPI's CRUBASE would be to use ROM code to setup a console ROM DSRLNK (via XMLLNK?) . Actually call the link from console RAM, return to it... R12 should have the CRUBASE value as a side-effect. Then return back to your ROM. It would have to be a request like 'close' to PI.CLOCK or something benign like that.


 

that seems the best. Let me think through my best idea, scanning.

 

in PAD
SBZ 0   map out DSR
LI R12,>1000
! SBO 0      Enable DSR ROM
MOV @>4008,R0  device chain
INCT R0    skip link to next
MOV *R0,R0
SBZ 0        leave DSR ROM
CI R0,>0454   length 4 'T' kludge
JEQ DONE
AI R12,>0100
CI R12,>2000
JL !
DONE  RT

* caller compares R12 to >2000 to validate
* 18 words. in PAD, 4A to 6B. 6D is MAX!
Quote

The TIPI CRUBASE is not stored. However maybe with more context, there can be a way for a hint to be provided by the caller of your DSR entry?

I could also assume the user runs the configuration program from BASIC and enters it there. I’m not sure where to store it. Ideally persistent. But the persistent storage is on the Pi Hat. Urghh. 
 

optimizing…

* replace AI,CI,JL

SWPB R12

INC R12

SLA R12,11

JEQ DONE * reached >2000

SRL R12,3

JMP !


Nope, that’s 6 words to replace 5

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

12 hours ago, FarmerPotato said:

I had an idea where another DSR calls the send/receive routines in the TIPI DSR.

 

In the source, header and tipi-io, there are pointers to the 4 send/receive routines ,in a table at >4010. So other programs  might call them and be relatively future compatible. 
 

I worked out how one DSR could move its trampoline code into >834A. About 8 words is enough to map out the calling DSR, map in TIPI, make the call, then put things back. 
 

The trampoline doesn’t need any more registers, since the DSR copies it up to PAD and modifies the instructions to restore R12 and branch return address. 

The message would be in VDP, most likely,  since a DSR can’t own any cpu RAM. 
 

the thing I can’t figure out, is how can one DSR find the cru base of the TIPI DSR? Is this stored anywhere?
 

Unless it were possible to fit a small enough scanning routine in >834A ?

 

I don't know enough on the 4A side of things, but I did do a fair amount of building a library of calls to the TIPI in the AfterHours source code that I then stored in the >6000 to >7FFF range of an 8K-EA cart.

 

Can you scan for the CRU of the TIPI once, and store the CRU somewhere?  Possibly in some self modifying code ???

 

Second thought, can you use the ISR to your advantage and activate it to leverage some code for you?

 

 

 

  • Like 1
Link to comment
Share on other sites

  • 11 months later...

Is it necro posting if you are still alive? 

 

I've been working on getting Plato and PCode to work with TIPI... (old school TI-Forth should end up working as well) 

 

One of my early tests was the Infocom games loaders... I saw no call to the sector IO routine, and the funny 40 / 80 column loaders just worked... I can't remember if someone rewrote them, or maybe I fixed some of my DIS/FIX code a while back, and that assumption of sector io was wrong. 

 

You can imagine that things from before 1983 that use direct sector access also assume crubase >1100.  

 

I have implemented a system of capturing the DSK sector dump when you upload a DSK file to TIPI with the web-ui. Should also work over the file share. If it was a track dump, I already was converting it to a sector dump first, before handing off to xdm99.py to extract all the files into a directory. Now I also capture the sector dump ( your original or my conversion ) to a '.sectors' file inside that extraction directory. 

 

Plato and PCODE disks both have a sector 0 that is well behaved. 

 

Plato disks have a file they access via traditional Level 3 record read operations named '$$1', and then a bunch of stuff read by sector operation elsewhere throughout the disk. 

 

One of the things that is sort of a pain, but not a show stopper, is that each Plato disk has the volume name of 'LESSONDISK' ... so for organization purposes, I end up making a directory named "Numbers 0-9" in the web-ui... then upload the lesson disk there, which makes a subdir called LESSONDISK, with the .sectors file and the $$1 file.  Then from the web-ui you can select the LESSONDISK dir and set it to map as DSK1. 

 

Seems slick. Just a lot to know and understand. 

 

In playing with PCODE, I found the web-ui lacking in the ability to un-map a drive. So I'm fixing that. It'll be obvious. Look for red X's.

 

PCODE disks have good and distinct VOLUME names compatible with the 4A filesystem. And then they have a single file named PASCAL on them that gets extracted, but never used as the system strictly uses the sector 0x10 routine. 

 

---

 

I do not want to encourage authoring new software that uses 0x10.  What I have now allows read and write to the sector dump.  For the PLATO disks, there is no writing to the sector dump. For PCODE and TI-FORTH there would be writing, and writing is supported. However if the software uses a hybrid access approach, writing to the sector dump is not reflected in the record (LVL3) access files as read by TIPI. PCODE and TI-FORTH will not care.

 

---

 

There are other programs that use sector access to catalog the disk. If no '.sectors' file is present, one is created on the PI in /tmp/<sha256-of-pathname>.img. That file will live until you reboot the PI. If a file in the directory it represents is updated, the next time a sector operation is requested, the cached sector dump will be reconstructed...  

 

I don't have bounds on that image construction scenario... I delegate to xdm99.py. One file at a time. So it'll make the disk ( with 1440 sectors ) and then add files that it can... if they fail or it is full they'll fail... but I also don't check for failure, so you get what you get. If what was there should have fit, it'll fit. 

 

---

 

I do have to submit a pull-request to Ralph B. for xdm99.py as this ran across a bug in bytes to chars when adding a file to the image. 

 

It requires a ROM update. 

 

It requires the TIPI running at crubase >1100  which is unusual for a PCODE system, cause you have to pull your floppy controller out. 

 

It is only supported for unit numbers 1-4 with a DSK mapping.

Sub-directories within the sector image are not supported.

 

But, all that PLATO works nicely for sideport TIPI users. And old fashioned TI-Forth should... Although you have fbForth now... so why? ( oops, asked "why?" which violates the vintage computing act of 2019 ) 

 

---

 

Ok, why am I foretelling this feature, instead of just sharing it? Because you all are smart people and maybe know some more software I should test with? or some use cases to try? Maybe more programs like TI-Artist that use sector access for cataloging... (I've tried TI-Artist but I had no art to list, and once I burn an actual ROM I'll try fbForth's sector CAT and the TIF2FBF tools.) 

 

Burning a ROM is a pain for most, so while there is very little code in the ROM, I'd like to know it's good enough... 

 

I'll probably get a beta of the ROM out this weekend with the PI side update for those that burn ROMs like candy.

 

---

 

How large of a disk image can PCODE support? I think I found a thread saying 360k images exist? 1440 sector... seems like I should be able to copy the 4 disks onto 1, and then have my other 2 drives for my own work files... ( oh, I'm getting greedy already ) 

 

---

 

(I have mastered numbers 0 through 9, extracting marbles from Pat's bag, and I don't even know what the thing with the blocks was supposed to be...) 

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

15 minutes ago, jedimatt42 said:

I've been working on getting Plato and PCode to work with TIPI... (old school TI-Forth should end up working as well)

 

WOW!

 

17 minutes ago, jedimatt42 said:

However if the software uses a hybrid access approach, writing to the sector dump is not reflected in the record (LVL3) access files as read by TIPI. PCODE and TI-FORTH will not care.

 

I suppose this would not be a problem with TI Forth reading/writing normal files because they should not be on the same disk as TI Forth blocks. There is, however, the circumstance of someone following my procedure of Appendix L “TI Forth System for Larger Disks” in my editions of the TI Forth Manual. Does that qualify as “a hybrid access approach”? And, of course, there is the system disk, which has three “normal” files (FORTH, FORTHSAVE, SYS-SCRNS)—the latter, containing the system blocks, probably cannot be considered normal except that it can be accessed that way. But, I digress ....

 

18 minutes ago, jedimatt42 said:

But, all that PLATO works nicely for sideport TIPI users. And old fashioned TI-Forth should... Although you have fbForth now... so why? ( oops, asked "why?" which violates the vintage computing act of 2019 )

 

Ha! Ha!   :grin:

 

...lee

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

11 minutes ago, Vorticon said:

So if I understand correctly, we should be able to point the DSK drives to TIPI folders and the pcode system will be able to use them instead of the physical drives? 

You'd have to remove the floppy controller at crubase >1100, and set the TIPI to crubase >1100. But then, yes. I don't expect to be able to do better than that. TIPI won't understand anything any about the pcode filesystem. It is just serving a disk image.

 

This suggests I should probably provide a spinny disk to sector image tool for folks that already have work files... 

Link to comment
Share on other sites

1 hour ago, jedimatt42 said:

You'd have to remove the floppy controller at crubase >1100, and set the TIPI to crubase >1100. But then, yes. I don't expect to be able to do better than that. TIPI won't understand anything any about the pcode filesystem. It is just serving a disk image.

 

This suggests I should probably provide a spinny disk to sector image tool for folks that already have work files... 

Hmmm... That would be inconvenient at best. I wonder if there is a way to patch the pcode system so it looks for a controller at 1000. A good question for Anders Persson.

Link to comment
Share on other sites

Michael Thomas had this to say:

Well, I can only check in an emulator but when I change the CRU base of the disk controller the system still works - so I guess the Pcode interpreter is scanning all CRU bases for a "DSKx" service routine?

 
If that is the case then there will be no need to remove the disk controller as long as TIPI is at 1000. Are you pushing an update for TIPI with these changes soon?
 
This is Anders' take:
The p-system has its own IO system. It implements two types of devices, character based and block based.
Character devices are things like the keyboard and serial interfaces. One character at a time.
Blocked devices are storage devices like a floppy disk. They are read 512 bytes at a time, i.e. two sectors on a standard disk drive.
The implementation is like an onion, where the p-systems data file access is at the top. Below that you have block access to files, to be able to handle undefined data blocks. Next level down is unit access, where you read blocks from a device without being constrained to files. That's the inner level of the p-systems IO-management. So far all p-systems are the same.
Next level down is the BIOS, which converts requests for a certain block on a disk drive to sector access, in the way the machine requires it. This is a part that's different for different machines running the p-system. Here the TI 99/4A starts getting involved with DSR programs.
I don't remember if the p-system starts scanning at 1000 or 1100. I would have to look in the code. But that should be easy to verify in an emulator, as you write. I do know that the access is different than the standard DSRLNK in the console. The p-system finds IO-devices in to stages. At startup, it will scan for DSR programs that implement what the BIOS wants, like a disk sector read/write program. When it finds one, it stores the entry point and the CRU base addess in that device's driver table.
Next, when it's time to access the device, it will not do a full scan again, but simply turn on the associated CRU address and jump to the entry point. This is why the Horizon RAMdisk doesn't work with the later DSR versions. That DSR does a dirty trick, in looking into the data structure used by the standard DSRLNK program to figure out which subprogram is looked for. But there's no such data there, when the p-system calls the disk controller, since it has already traversed the linked list and knows the entry point from before. But with the Horizon DSR, that entry point isn't the real one, but a common entry point for all subprograms, and then the DSR attempts to resolve the last link at call time. There it fails.
Anyway, since the p-system implements its own file system on the disk, it reads it by sector, and by sector only. It will never look for a standard file, starting with DSKx in the file name. Instead, it will read the whole disk directory from the disk, using sector access, find the file it's looking for in the directory, then read that file with more sector accesses. Hence a FIAD system will not work, since it provides parts of files, not parts of the disk area.
 
  • Like 2
Link to comment
Share on other sites

I wouldn't expect anyone to desolder their ROMs from the PCODE card. But it would probably be a relatively easy hack to change where R12 is loaded with >1100 to load it with >1000. 

 

I was testing in emulation (MAME) and changing the crubase caused failures... maybe they were my failures, so I'll retest. I don't know of any emulator that allows changing the crubase of a floppy controller. PCODE wouldn't be scanning for a DSK service routine, it would be scanning for the 0x10 basic subroutine for sector read/write. 

 

What Anders is saying matches what I've observed mostly... I see the PCODE system access the TIPI at >1000 for the first sector request, but it appears to activate crubase >1100 for subsequent calls. My TIPI ROM does not behave the way he describes as the source of failure for the HRD. 

 

I don't know who Michael Thomas is, or who Anders is... are these people in this community? @Vorticon did you have to go ask them, or is this something they have published that is available to read up on? 

 

Link to comment
Share on other sites

Ok, retested. ( all in MAME )

 

TIPI at >1000, no FDC, PCODE fails, reads sector 4 of first drive, then eventually goes into illegal opcodes and crashes with pretty graphics. 

TIPI at >1100, no FDC, PCODE works... reads all the mapped drives... Welcome COMPILR... 

TIPI at >1000, w/TIFDC, PCODE works... reads all the mapped drives... I hear it access the floppy controller once in MAME ( thanks to sound effects ) 

TIPI at >1800, no FDC, PCODE fails, reads sector 4 of first drive, and does pretty ( undesirable ) things after that.

TIPI at >1800, w/TIFDC, PCODE comes up with no drives, never sees TIPI's 0x10 operation cause the TIFDC implementation accepts full responsibility. 

 

So, TI knew they planned on >1000 and >1100 for drives... and it dies trying to read a sector from the controller at >1100, it tries to run the code there even if it isn't there. ( seems like... )

 

 

  • Like 3
Link to comment
Share on other sites

The p-system stores a table of data for the different units (devices) it supports. There are units for the screen, keyboard, serial communication, disks and so on. This table has pointers to driver tables. The driver tables contain the CRU address of the device. Serial input and output points to the same driver. All disks (units #4, #5 and #9) points to the same driver table, as they assumed only one disk controller, supporting up to three drives.

To add a drive, if you have a CorComp controller, takes nothing more than populating the unit table for unit #10 with the same data as for unit #9. Then you have a fourth drive.

To add another drive on a different controller (like a RAMdisk) is trickier, since it can't point to the same driver table. The CRU address will be different.

After the system has started, you should be able to change an existing floppy drive to instead look in a RAMdisk. I've never tried this, though. I've added a driver table for the RAMdisks, and made them units #11 and #12 instead, since I have no reason to remove the disks in my real TI.

When you add a driver table, you have to make room for it. The unit table allows for 33 units, but the driver tables are created in VDP RAM for the existing units. I use to put it high up in the character definitions, or in a sprite table. Now I know enough to modify the VDP RAM free memory pointers and tuck it away there, or even to generate an operating system call with a request to allocate space for them. But I didn't know how to do that back then.

 

I skipped some details in this description, but it should be enough to understand the concept.

With a real p-code card, it's probably difficult to prevent the system from trying to access the disk controller at boot. But if it starts loooking for devices already at CRU 1000, then it should pick the first device pretending to be a disk controller.

It's a bit tricky to see in the real hardware. At boot time, the p-code card runs code which transfers a code repository from GROM on the card to low RAM expansion, then runs it from there. This code lives only during boot time. After a while, when the code has been used to build tables and stuff the system needs, it's replaced with the content of the 80 column screen and some other stuff. In an emulator it would be easier to see what's going on.

Edited by apersson850
  • Like 2
  • Thanks 1
Link to comment
Share on other sites

On 7/20/2022 at 5:50 PM, Vorticon said:

Hmmm... That would be inconvenient at best. I wonder if there is a way to patch the pcode system so it looks for a controller at 1000. A good question for Anders Persson.

If you are OK with starting with the p-system using a physical disk, then switch over to TIPI, it could be done inside the p-system itself. You would have to change the CRU and entry addresses in the BIOS, but that's no big deal.

If you want the p-system to boot directly from the TIPI it's probably a bit more tricky, since the p-system isn't running any user's program at that time. But nowadays, when a lot is just emulated, then it's easier, of course, since you can change anything in the p-code card too.

Link to comment
Share on other sites

1 minute ago, apersson850 said:

If you are OK with starting with the p-system using a physical disk, then switch over to TIPI, it could be done inside the p-system itself. You would have to change the CRU and entry addresses in the BIOS, but that's no big deal.

If you want the p-system to boot directly from the TIPI it's probably a bit more tricky, since the p-system isn't running any user's program at that time. But nowadays, when a lot is just emulated, then it's easier, of course, since you can change anything in the p-code card too.

In my mame environment with TIPI and floppy, it boots off TIPI fine. I was imagining writing a ForceCommand tool that copies a physical disk to TIPI directory and .sector file. If you are starting from Gotek's you can just upload the DSK image in the TIPI web-ui (after I release) and it'll do the right thing. 

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

6 minutes ago, apersson850 said:

If you are OK with starting with the p-system using a physical disk, then switch over to TIPI, it could be done inside the p-system itself. You would have to change the CRU and entry addresses in the BIOS, but that's no big deal.

I wouldn't mind using a floppy for initial boot given how convenient it would be to subsequently use the TIPI mapped drives instead. As to how to do the BIOS changes, no clue on my end. Could you be enticed (bribed?) to come up with such a program by any chance? ?

Incidentally, assuming the BIOS changing program is run, re-initializing the OS should do the trick then?

Link to comment
Share on other sites

4 minutes ago, jedimatt42 said:

In my mame environment with TIPI and floppy, it boots off TIPI fine. I was imagining writing a ForceCommand tool that copies a physical disk to TIPI directory and .sector file. If you are starting from Gotek's you can just upload the DSK image in the TIPI web-ui (after I release) and it'll do the right thing. 

I have tried using disk images of the pcode system (taken from my Classic 99 setup) on the TIPI to boot pcode and it has uniformly failed in the past, likely because the conversion to a TIPI folder was not what the pcode card expected to see. Happy to test on real hardware once you have a release version of FC for this.

And my deepest condolences for your PEB's demise. A good opportunity to upgrade to an ATX supply :)

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

2 hours ago, Vorticon said:

I wouldn't mind using a floppy for initial boot given how convenient it would be to subsequently use the TIPI mapped drives instead. As to how to do the BIOS changes, no clue on my end. Could you be enticed (bribed?) to come up with such a program by any chance? ?

Incidentally, assuming the BIOS changing program is run, re-initializing the OS should do the trick then?

Not much bribing is needed, since such a program I've written already. I've done several enhanchements to the storage facilities in my p-system.

  1. With CorComp controller, added a fourth disk drive. This becomes #10, and the only thing needed is to insert a pointer in the table, with the same value as for the other disks, since the fourth one is handled by the same controller as the first three. A simple POKE is enough.
  2. Then I created a RAMdisk with RAM that's not used by the p-system. A 56 K Maximem module and the 64 K RAM I've installed in the console provides the memory. A DSR is needed, so I wrote one and placed it in memory I have on my IO-card. It has nothing to do with that card itself, but it can host the DSR anyway. This drive is installed as unit #11, but now it's not as easy as just another POKE. It can't point to the disk controller, but must point to a data structure for the virtual disk controller on my IO-card. But since that DSR implements the sector read/write subprogram in the same way as the disk controller does, the only thing needed is a similar structure as for the disk controller, but with the CRU address being 1600 and the correct entry address for the subprogram. With that patched, you call unitclear on unit #11, and the system does the rest. The "similar structure" I have so far tucked away in the upper character definitions, or in a sprite table, whatever is not needed.
  3. Finally I got a Horizon RAMdisk. After writing a DSR for it, which implements the sector read/write without making assumptions about the caller, that works too. Yet another structure for this controller has to be created, but then just POKE a pointer to that in the table for unit #12, call unitclear and it's ready to run.

Now what you get here is the physical disks as they used to be, but then augmented by two RAM disks. The program I've written also changes the tables in the p-system so that I can move the files SYSTEM.EDITOR, SYSTEM.FILER, SYSTEM.COMPILER, SYSTEM. ASSEMBLR and SYSTEM.LINKER  to the RAMdisk. When these programs are then invoked, the p-system will run them from the RAMdisk. Compile time on the real machine is reduced to half.

 

This program doesn't solve the issue of booting directly from the TIPI or similar, but for just using the system, it's fully enough. The few real disk accesses I see are often to *SYSTEM.LIBRARY. But if you want to, you can create a pointer file which directs the system to look in a library elsewhere too.

Still, it will probably show you how to do everything. And anoher advantage is that you tell it where the controller is. Thus it doesn't matter which CRU base the TIPI has. My two RAMdisks are at 1600 and 1700, but they could occupy any free address. In my PEB I have the following:

1100 Disk controller (CroComp)

1300 RS-232

1400 Clock card

1600 IO-card (with DSR for my own RAM-disk)

1700 RAMdisk Horizon

1F00 P-code

The other two positions are the interface and memory expansion cards. If I let one card double as memory expansion, I could have one more card with a CRU address in there.

Edited by apersson850
  • 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...