Jump to content
jrhodes

Low level disk access required

Recommended Posts

Posted (edited)

Is there a list of software that requires the kind of low level disk access that you can only get from a gotek / nanopeb / real floppy?

There is a small list of software that does not work with TIPI at https://github.com/jedimatt42/tipi/wiki/Known-incompatible-software , but surely these are not the only reason to stick to using a nanopeb or real floppy?

Edited by jrhodes

Share this post


Link to post
Share on other sites

I've found issues with some software on the nanoPEB - mostly 3rd party software, but also including PLATO, as the list above does.  It would be good to see that running on both the TIPI and nanoPEB.

Share this post


Link to post
Share on other sites

The p-system does all disk IO via the read/write sector subprogram. Then it implements its own file system on top of that.

Share this post


Link to post
Share on other sites
Posted (edited)

Well, the p-system uses the concept of blocked devices for storage. Blocked devices are supposed to consist of a number of blocks, 512 bytes each, that can be addressed randomly. You have to simulate these blocks in some way, to allow anything to work in the p-system. Disk directories are stored in blocks at the beginning of each blocked device. The files then fill blocks further down. Note that the p-system doesn't use the file system used by the TI 99/4A at all. It implements its own file system, using the sector read/write routines to do the actual reading and writing of data.

When I implemented my own RAMdisk with the p-system, I copied the p-system's structure for normal disk access, changed the CRU base address and implemented a DSR, which responds at that "other" CRU base. This DSR contains the sector (256 bytes) read/write routine for the RAMdisk. The p-system then accesses the blocks just like it does for normal disks. This way means that as much as possible of the existing structure of the p-system can be maintained, an approach which always is the easiest.

Edited by apersson850
  • Like 2

Share this post


Link to post
Share on other sites

so in theory you could create a DSR at that CRU that just makes a file on a standard drive and uses level 2 access instead of level 3

Share this post


Link to post
Share on other sites

Not only in theory, as that is what I did in reality. I didn't have any real RAM disk to begin with. But I have a 56 K Maximem module and 64 K RAM expansion built into the console. Together that's 120 K bytes, which is larger than a standard TI disk, that I can use as a RAM disk. I also have two cards in the expansion box, at different CRU addresses, that hosts RAM for a DSR.

So I used one of these cards and implemented the level 2 subprogram for sector access in a DSR I stored on that card.

 

In the standard configuration, the p-system on the TI 99/4A can only use three disks. The p-system itself (version IV.0) can use six. To expand to a fourth drive, when replacing the TI with a CorComp controller, I only needed to copy the drive unit pointer table entry from the first disk drive (unit #4 in the p-system) to the fourth (unit #10 in the p-system). All four drives have the same pointer table, as they all access drives via the same disk controller, at the same CRU base.

 

But when accessing a drive on a RAM disk, it's normally done via a different controller, at a different CRU base address. Like in my case. So I took the normal disk access Peripheral control block (PCB) in the p-system, copied it and changed the CRU base from 1100 to 1600 hex, where one of my cards reside. Then I modified the pointer table for the next drive in the system (unit #11) to point to this modified PCB. As soon as that's done, the system will then work as intended when accessing this fifth disk.

 

When I much later got a Horizon RAM disk, I did the same for that one once again, to install it as unit #12 in the p-system. I had to write a DSR for the Horizon disk too, or use an old version, since the more current versions don't support the p-system. But that DSR is stored on the Horizon card itself.

 

The DSR that accesses the RAM disk made up of the Maximem module and the internal memory expansion in the console actually supports access to sectors 4 to 483. The p-system never accesses the first four sectors anyway, since they are reserved for making up a disk directory and a dummy file, which occupies the entire disk, in the standard file system. Then the p-system files reside in the remaining space. By shifting my sectors up I got the equivalent of a 121 K byte disk instead. No dummy file is needed on the RAM disk anyway.

  • Like 1
  • Thanks 1

Share this post


Link to post
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.

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...