Horizon RAMdisk ROS and CFG Development

[+InsaneMultitasker]

3 hours ago, globeron said:

Do i put the Menu file on DSK5? Because i did not copy the MENU file, is that maybe the cause it is locking up...hmmm

Yes, try adding MENU to DSK5 if powerup is on.  It must be named "MENU" (unless you change it in CFG). 

The default powerup setting for an unconfigured ramdisk will be changed to "N" in future release of ROS.

Perhaps your ramdisk does not have the three hardware fixes for that model? There were changes released to fix certain corruption issues. 

[Gary from OPA]

On 5/8/2020 at 8:07 AM, apersson850 said:

I had a look in the source code and noticed that this DSR will still not work with the p-code card. I understand that the user base for that system is too small to bother with, but it would be good if the wiki and/or code contains a note about that the ROS is compatible with the built-in operating system, but not with the p-system.

 

If anyone with a p-system would ever be interested in getting it to work, like I was, here's the reason for the incompatibility.

The p-system only uses the sector read/write in normal operation. This is the part of the ROS where such a function call is decoded.

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 #

On the second line, the MOV @SRHADR,R1 is supposed to get the address of the found subprogram in the DSR. The address SRHADR is >83D2, which works with the console's operating system, when it uses its DSRLNK routine to find the proper DSR. This is a clever trick to make the DSR code smaller.

The p-system, however, uses a more efficient method to call a DSR than the regular DSRLNK routine does. With this method, the address of the desired program in the DSR program isn't available at >83D2, so this clever trick backfires.

 

It's not difficult to write a sector read/write program for the RAMdisk which doesn't make assumptions about the caller, but resolves the call in the "old way", so to speak. Then it works with the p-system. As the file handling is all built into the p-system, and a RAMdisk doesn't need formatting like a physical disk, that's all that's needed.

I recently been able to get a couple of p-code cards, and having them shipped down to me next week, and i will for sure take a look at this.

[Gary from OPA]

On 5/9/2020 at 6:31 AM, globeron said:

Hey, look its a rambo clone....

 

And that wiring... giving me nightmares, hope you never have to repair it.

[+Schmitzi]

On 5/8/2020 at 8:53 PM, Schmitzi said:

Is there a known issue between RamDisk and SuperAMS ?

Sometimes updating ROS works, most times not.

Pulling the SAMS, and the HRD works fine.

Not my cards, will get some more info later.

 

 

On 5/9/2020 at 9:30 AM, Schmitzi said:

thanks, I´ve passed through these infos, and investigation will go on.

I also think, it is a bad PEB slot, or a loose contact, or or or

 

PS: Latest info I got: HRD4000 is at >1200, SuperAMS 512k is at >1E00

 

 

 

 

Hi, final update

 

some 74LS244 or 245 (is this something one can eat ?)   on the RamDisk were changed and the show goes on

 

thx

 

 

[globeron]

20 hours ago, Gary from OPA said:

Hey, look its a rambo clone....

 

And that wiring... giving me nightmares, hope you never have to repair it.

The troubleshooting is more on the software (not the hardware I think, or maybe with the PEB box config, it might be the causing issues).

 

The battery holders, IKEA batteries en wiring in between these + black tape is my unprofessional work, but the batteries keep the data on the chips when I turn it on/off, now testing overnight, hope it works. Not too sure how long these batteries last and if they get charged with the board.

 

It is a wonder that it is working. The idea was to use this for the Geneve 9640 I am installing (everything works, except probably an issue with the video via the GBS8200 device, waiting for new ones hope that solves it), but I have too many issues with the Horizon that I will leave it for the TI-99/4A and probably use the Corcomp Ram512 with the Geneve if that works.  

 

 

These are my latest troubleshooting activities, now with ROS842C and DM2Kv2.6 things work better now it seems

(but still need to figure out Power On=Off (I do not like the SHIFT pressing),  using MENU (it seems to hang the card)

and even in the video I got the card hung more to the end.

 

I noticed that when loading the ROS842 from DSK1.  it sometimes goes to the TIPI (even it is at >1800), so I renamed ROS842CC then it loads from the floppydisk. No clue why that is happening.

(furthermore with DM2K I can browse DSK0.subdirectories, but I cannot copy from it (probably TIPI DSR issue ?)

and I cannot copy DIS/FIX 128 file types of the TIPI).   Furthermore it seems that files with "/" in it also could not

be copied but in this video it worked (maybe it is DM2K v2.5 related).

 

Not sure if it is important (maybe too many cards and floppy diskdrives connected to draw the power?)

 

*everything runs at 38 degree Celsius outside temperature, I think much higher in the box)

* slot 1. Flex Interface card to the TI via extension cable to the Speech Synth to TI-99/4A

* slot 2 (and empty 3) Horizon3000/Rambo card (occupying 2 slots)

* slot 4 TI RS232 Card

* slot 5 (UCSD P-code card)

* slot 6 (TIPI PEB card with TIPI/Raspberry connected to it, using extension cable to easy switch between >1000 and >1800

* slot 7 Corcomp DS/DD Floppy Disk Controller  (FDC) with DOS Miller Graphics ROM0 / ROM1

* slot 8 TI 32K  (needed for the UberGrom XB Suite 2.7 and/or FinalGrom 99 to work, not sure for the Horizon3000/Rambo)

* 2x 5.25 Floppy drives (via the internal wiring to the Corcomp FDC)

* 1x 3.5 Floppy drive (using the external wiring to the Corcomp FDC) 

   (I think I heard before that a PEB box cannot handle it, but it seems to work on my box using internal power).

* Power is quit silent, not sure what the capacity is in W(attage)

   (everything on an power extension cord ? 10 (Amp?) with 4x devices (PEB Box, TI-99/4A, LCD TV,  Raspberry PI to the       USB port of the Extension cord (I guess min. 2A, it is a green port supposed to be 3A?).

 

 

 

.cc @F.G. Kaal 

 

 

Edited May 11, 2020 by globeron

[globeron]

22 hours ago, InsaneMultitasker said:

Yes, try adding MENU to DSK5 if powerup is on.  It must be named "MENU" (unless you change it in CFG). 

The default powerup setting for an unconfigured ramdisk will be changed to "N" in future release of ROS.

Perhaps your ramdisk does not have the three hardware fixes for that model? There were changes released to fix certain corruption issues. 

Maybe the fixes are not applied, I found some docs about that, but need to study it 

(and see if I am able to fix it myself, I am not so good at these hardware fixes...) and

kind of have it working (so try not to break things).

 

http://www.unige.ch/medecine/nouspikel/ti99/horizon.htm

 

[+InsaneMultitasker]

FYI, corcomp 512 ramdisk is not compatible with the Geneve.

Operating two or more cards with overlapping device names and/or device subprograms does create challenges.

 

hmm.  I do not recall seeing "0123456" when I inspect the devices in my system. I'm suspect there is a proper reason for this - I will confirm later in the week. The multiple "DSK<space>" devices are placeholders; the device number is NULL (0x00) until the drive is formatted.

 

 

[Gary from OPA]

today is my birthday... -- tomorrow i going to unwrap some ti99 presents i got, today i am too drunk, may plug the peb cards in backwards

[+mizapf]

Alcohol is no solution.

No alcohol neither.

 

[+Schmitzi]

45 minutes ago, Gary from OPA said:

today is my birthday... -- tomorrow i going to unwrap some ti99 presents i got, today i am too drunk, may plug the peb cards in backwards

 

 

So,  ♪ Happy Birthday to you ♫

 

[+InsaneMultitasker]

1 hour ago, Gary from OPA said:

, may plug the peb cards in backwards

been there, done that with a Geneve.

happy birthday.

[Tursi]

1 hour ago, mizapf said:

Alcohol is no solution.

No alcohol neither.

If you aren't part of the solution, you're a precipitate.

 

Happy birthday Gary!

 

[apersson850]

On 5/8/2020 at 6:38 PM, InsaneMultitasker said:

I do not consider reliance upon this address to be a 'trick'. The addresses 83d0-83d3 are defined to be used for the ROM and GROM searches.

Well, I do. Now I haven't dug up the DSR interface manual now, today, and it was many years ago I read it. I did that since I've made some PEB cards myself, and had to write DSRs for them.

But if I remember correctly, the DSR manual does not specify this address to be used for searching ROM and GROM links. I think it's the operating system in the console that specifies that this address is used when searching for the DSR. Thus it's a "trick", because the DSR makes assumptions about which operating system is calling it. Which it shouldn't, of course.

 

Now, again, it was decades ago I read these documents, but from memory this is the reason for incompatibility with the p-system.

 

I'll try to help you with examples of how to make it work. As I wrote, I did make a simple DSR for the RAMdisk that does work with the p-system. I'll just have to find the time right now to get that code to you.

 

I can give you the background to why it doesn't work with the p-system, though.

"Normal" DSRLNK calls, from the standard operating system, are as stupid as possible. Each and every time, the machine assumes it has no knowledge about where to find a requested device, so it starts scanning through the entire CRU range devoted to DSRs in ROM, and looks for the device name's entry, to find the entry address. When they did the p-system, they realized that although this scheme is very flexible, its also inefficient. To keep the flexibility, but reduce the inefficiency, they made the reasonable assumption that DSR entries will not move around while the machine is running. Now there they made an assumption which could be dangerous now, since we have DSR memory space in RAM. So in theory, we could move a DSR entry from one call to another.

Anyway, at that time, all DSR code was in ROM, so it wouldn't move or change while the machine was running.

Since the p-system is an operating system by itself, it already has a list of devices it interfaces with. These devices are like CONSOLE:, PRINTER: and various blocked devices (disks). The blocked devices have hardware numbers (#4:, #9: etc.), but also get the names of the disks in them. Thus a blocked device could be SYSTEM:, DEVELOP: or RAMDISK:.

When the p-system creates its list of devices (or units, as they are called), the list look the same in all p-systems. The commands (input, output, reset and so on) are also the same. In the next layer down, there is the BIOS, which is different depending on the hardware. In the 99/4A, the BIOS reduces the overhead in calling DSR code by splitting it in two stages. At boot time, the system looks for the proper DSR to call for each unit, to find the mapping between a p-system unit and the current hardware's implementation of it. Once the device entry is found (for example RS232 or disk sector read routine), the CRU address and the memory entry address for that routine is stored in a table. This table is located in the SYSCOM area, which in the 99/4A is resident in the 8 K RAM. Note that at this time, the DSR is not executed. It's just located.

Then, when the system continues to boot, and eventually releases control to the user, the appropriate DSR to call when a certain p-system unit is referred to is already known. Now the CRU and memory addresses from the table are used to enable the DSR and jump directly to the DSR code.

 

This works fine when the DSR has a separate entry for each subprogram/operation. But in the ROS for this RAMdisk, all subprograms have a common entry. Then, in the code snippet I posted before, at TEST, the address in the RAM PAD is inspected to determine which of the subprograms was actually called, and then the correct routine runs from there. But since the p-system already knows about what to run, and uses the RAM pad in a different way (the main PME workspace is at >8380, not >83E0), that address is in the table in the SYSCOM area, not in the console RAM. So whatever the DSR finds at 83D0 has nothing to do with what to run from the DSR code.

[+InsaneMultitasker]

On 5/12/2020 at 4:51 PM, apersson850 said:

Well, I do. Now I haven't dug up the DSR interface manual now, today, and it was many years ago I read it. I did that since I've made some PEB cards myself, and had to write DSRs for them.

But if I remember correctly, the DSR manual does not specify this address to be used for searching ROM and GROM links. I think it's the operating system in the console that specifies that this address is used when searching for the DSR. Thus it's a "trick", because the DSR makes assumptions about which operating system is calling it. Which it shouldn't, of course.

 

TI manuals provide a good baseline; they are not absolutes.  The easy response is for me to say the Horizon Ramdisk was designed for the TI-99/4A OS and its DSR is incompatible with the PCODE card.  Most hardware/software already 'assumes' the TI operating system is in place, ROS is no different. 

 

I reviewed the ROS code. Parsing the opcode out of the PAB is simple.  Scanning the table for the correct opcode will consume more DSR bytes than are currently available for the ROS code.  I have noted the situation as an issue for future , further review or implementation.

 

It is possible to fork the ROS code, strip a few opcodes to make some code space, and amend the code.  However, if you have already addressed the ramdisk/pcode situation with your own code, I am not clear what is to be gained by adjusting ROS at this time.  What is the use case for ROS in the PCODE environment. 

 

[apersson850]

Most hardware actually does work with the p-system, if the hardware maps any function the p-system can use. But if you add a Triple-Tech card, you can't use the real time clock just like that, since the concept of a real time clock doesn't exist in the p-system.

 

I have understood that the ROS does it the way it does to save a few bytes. That's why I called it a clever trick.

 

The benefit of making the DSR compatible with the p-system is that you wouldn't have to exchange the DSR each time you switch between the operating systems.

 

I have no problem with that it's compatible with the standard OS only. I happen to know enough about the system to find out why it fails with the p-system, and fix it. But I have previously sent code to people to make their RAM-disk work with the p-system, but it failed. This was before I had one, so I couldn't understand why.

That's why I'm spreading this knowledge and insist on that the manual should mention this issue.

[+InsaneMultitasker]

14 hours ago, apersson850 said:

The benefit of making the DSR compatible with the p-system is that you wouldn't have to exchange the DSR each time you switch between the operating systems.

Thank you, that makes sense to me.  Can you also explain what the PCODE expects to see on a formatted drive to make it usable and is there a size limitation?  If the setup is simple, it could theoretically be added to the CFG program as an alternate format, allowing one to format for either system.

 

I built the lookup table code and PAB extract code so that it is ready to insert when/if I find a way to cram it in.  One option is to eliminate the scratch record opcode for an alternate build, at least for test purposes. Check back with me in a few weeks on this if you like and I should be ready to send you a test version of the ROS...

[apersson850]

The p-system uses only the read/write sector subprogram. It doesn't expect to see anything special on the disk, as long as the sectors can be read and written.

Getting a physical disk ready for use with the p-system is a two step process.

1. Format the disk. This is something the p-system can't do by itself, since it's totally machine dependent. There's a special program, dformat, supplied for this. It's not very good, so I wrote a better myself. But this step is not needed for a RAM-disk, since you can always read a sector from it.
2. Install the p-system's file directory. This is something the p-system's Filer (disk manager) utility does, using the Zero command. This will write the p-system's disk catalog for an empty disk on the drive. For a RAM-disk, it's the only thing needed.

Then there's a special patch that needs to be installed in the p-system. That's because the p-system on the TI is limited to three drives. That's of course because only three drives were supported by the original disk controller. The p-system itself can handle six, but the system's tables need to be patched with the proper values first.

 

Due to the p-systems pre-scan of available units, you can add a fourth physical drive just by copying the information from one of the first three to the location for the fourth. That works because all four physical disks are accessed via the same DSR, on the disk controller. To add a RAM-disk requires creating space for a new drive definition, since the RAM-disk will have a different CRU base address. You remember I wrote before that the system pre-scans and stores the CRU address as well as the entry address for the sector read/write subprogram in its data structures. Since with a RAM-disk, there will be multiple devices providing access to blocked data storage units, the system also need different content in the tables for them. But this is a patch to the p-system, and has nothing to do with the DSR on the RAM-disk.

 

Step 2 above is the one where the read/write sector subprogram is needed, and then for all subsequent disk accesses, of course.

When the Zero command is run, you tell the system how many blocks are available on the drive. One p-system block is two sectors. 16 Megabytes is the theoretical limit for how large a p-system volume can be (32767 blocks). But you never want them that large with the IV.0 version. If the RAM-disk is gigantic, then it would be an advantage to allow two virtual drives on it.

 

The p-system on the 99/4A is version IV.0. Later versions, from IV.1, allow for subfolders. They are called subsidiary volumes, and reside as files on the host volume. Thus if you have a hard drive, you can create a master volume with up to 77 subsidiary volumes on it. Subsidiary volumes can't be nested, though, but each can be 16 Megabytes. These versions also allow for more than six base volumes.

Remember that the p-system was created when drives were small (a few hundred kilobytes at the most), so already the limit of 16 Megabytes was pretty farsighted. That they would cater for today's Terabyte drives would be a bit too much to expect.

Edited May 18, 2020 by apersson850

[+InsaneMultitasker]

Makes sense.  The sector access is similar to how the Geneve operates; it does not use ROS or CFG, it simply accesses the drive on a by-sector basis.  As a result, it was possible to leverage the Geneve OS to format the entire ramdisk as a 'hard drive format' using sector IO, allowing for subdirectories in the manner used by the HFDC, SCSI, and IDE devices.

 

I will not try to expand CFG to manipulate the partitions.  That being said, I -could- try to add simple protection to CFG to warn the user that the ramdisk is formatted for p-system usage.   Is there a unique identifier in the first sector that could distinguish a ramdisk for use with the p-system?

[apersson850]

It creates a dummy file, which occupies the entire disk. The p-system dosen't use any file IO inside that file, but to the native operating system it looks like the disk is full. This file is called PASCAL.

So if the first normal file entry is a file with that name, then the disk is likely prepared for use by the p-system.

The p-system then creates its own directory and files inside the space occupied  by the dummy file.

[+Lee Stewart]

42 minutes ago, apersson850 said:

It creates a dummy file, which occupies the entire disk. The p-system dosen't use any file IO inside that file, but to the native operating system it looks like the disk is full. This file is called PASCAL.

So if the first normal file entry is a file with that name, then the disk is likely prepared for use by the p-system.

The p-system then creates its own directory and files inside the space occupied  by the dummy file.

 

TI Forth did something like this for Forth work disks in that the disk was set up with a single file (SCREENS) that occupied the entire disk. TI Forth did not, however, actually care whether this was done. It was merely a device to discourage using that disk for anything else. I believe, as long as the first sector (VIB) was not touched, TI Forth could use the disk to read/write screens with impunity. Of course, avoiding writing to the first screen (block) avoided the first four sectors, the first three of which included the VIB, FDIR and the SCREENS file’s FDR, but I digress ....

 

...lee

[+InsaneMultitasker]

On 5/11/2020 at 11:31 AM, InsaneMultitasker said:

 I do not recall seeing "0123456" when I inspect the devices in my system. I'm suspect there is a proper reason for this - I will confirm later in the week. 

 

 

This "0123456" is just a placeholder. Nothing to worry about. I'm sure I'll forget again some day

 

[apersson850]

12 hours ago, Lee Stewart said:

 

TI Forth did something like this for Forth work disks in that the disk was set up with a single file (SCREENS) that occupied the entire disk. TI Forth did not, however, actually care whether this was done. It was merely a device to discourage using that disk for anything else. I believe, as long as the first sector (VIB) was not touched, TI Forth could use the disk to read/write screens with impunity. Of course, avoiding writing to the first screen (block) avoided the first four sectors, the first three of which included the VIB, FDIR and the SCREENS file’s FDR, but I digress ....

It's identical to how the p-system operates.

Unlike many other higher level languages, Pascal provides three different access methods to storage.

1. Typed file handling. Similar to the file handling in BASIC, but with better data types. Uses commands like read, write, put, get and seek.
2. Untyped file handling. You can read/write any p-system file, without knowing what the data represents. Access is within the area the file occupies on the storage media. Uses commands like blockread and blockwrite. Similar functionality for the native file system is available as subprograms on the disk controller card, but not directly accessible from BASIC.
3. Direct access. Will read/write any p-system block on a disk, for example. The blocks are 512 bytes long, so two sectors each. The p-system's block 0 starts at physical sector 4, since it assumes the BIOS requires the first four sectors to be protected. The p-systems disk catalog starts at block 0 (sector 4). Uses commands like unitwrite and unitread. You can set a control bit which allows access to physical sectors as well, so you can read/write to sector 0. By using unitstatus, you can get information about the physical sector size, number of sectors per track and number of tracks on a disk.

Since these commands are available in Pascal, it was for example possible to write a program which reads, or writes, a DIS/VAR 80 file in the native format directly in Pascal, without the need for any assembly support. Thus a converter between Pascal's text files and DIS/VAR 80 files could be written. Both the file itself and the directory entries could be handled from Pascal.

That's of course possible from Forth too, since it's much closer to assembly from the beginning.

 

[+jedimatt42]

Is there documentation for the various kinds of boards... I've seen the HRD2000-4000 docs on http://ftp.whtech.com/ 

but I'm looking at something labelled HRD17...  Looks like it has a combination of flash memory and 3Meg of SRAM...

 

Wondering what the 7 jumpers actually mean. 

 

SW:S1 dip switch, array of 4.  ?? crubase maybe?

JP1:SIZE  ??

JP2:WIDTH ?? Memory configuration maybe?

JP3:is a 5x2 ISP port

JP4:Disable - sounds like it disables the board?

JP5:Battery - probably disconnects the battery?

JU1:TYPE   ??

JU2:TYPE-H ??

JU3:TYPE-L ??

 

[+InsaneMultitasker]

18 minutes ago, jedimatt42 said:

Is there documentation for the various kinds of boards... I've seen the HRD2000-4000 docs on http://ftp.whtech.com/ 

but I'm looking at something labelled HRD17...  Looks like it has a combination of flash memory and 3Meg of SRAM...

 

 

 

Might be a SNUG ramdisk?  (I have never owned one)   https://www.s-n-u-g.de/hrd16/index_en.php

[+jedimatt42]

11 minutes ago, InsaneMultitasker said:

Might be a SNUG ramdisk?  (I have never owned one)   https://www.s-n-u-g.de/hrd16/index_en.php

 

Yep, that's what it looks like... Thanks.