jrhodes Posted June 27, 2020 Share Posted June 27, 2020 (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 June 27, 2020 by jrhodes Quote Link to comment Share on other sites More sharing options...
WhataKowinkydink Posted June 27, 2020 Share Posted June 27, 2020 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. Quote Link to comment Share on other sites More sharing options...
apersson850 Posted June 27, 2020 Share Posted June 27, 2020 The p-system does all disk IO via the read/write sector subprogram. Then it implements its own file system on top of that. Quote Link to comment Share on other sites More sharing options...
+Schmitzi Posted June 27, 2020 Share Posted June 27, 2020 Can´t you "bend" that ? Quote Link to comment Share on other sites More sharing options...
apersson850 Posted June 28, 2020 Share Posted June 28, 2020 (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 June 28, 2020 by apersson850 2 Quote Link to comment Share on other sites More sharing options...
+arcadeshopper Posted June 28, 2020 Share Posted June 28, 2020 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 Quote Link to comment Share on other sites More sharing options...
apersson850 Posted June 29, 2020 Share Posted June 29, 2020 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. 2 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.