Horizon RAMdisk ROS and CFG Development

[+dhe]

Heck, I'm interested in what it was like to be an east german TI user in the 80's! ?

[DomLeBel1]

HI Ksarul,

i am interested in two 400B bare board with difficult parts to get if available.

Thank you

Dominique

[DomLeBel1]

4000B

[GDMike]

On 2/21/2023 at 7:09 AM, DomLeBel1 said:

4000B

I picked up the last one on arcade shopper today I think it's the 8mb version though..

Corrected....I was thinking a 8000B would be a 8MB version, my bad...

Edited February 23 by GDMike

[+Ksarul]

2 hours ago, GDMike said:

I picked up the last one on arcade shopper today I think it's the 8mb version though

That one is the last assembled and tested one I had on hand, @GDMike. I have a few more assembled boards I need to test, but I don't want to make them available until they pass the tests. I have LOTS of bare boards on hand, as my aim is to keep them (and any other board I make) available for at least as long as I remain alive. 

[+DuaneAL]

47 minutes ago, Ksarul said:

That one is the last assembled and tested one I had on hand, @GDMike. I have a few more assembled boards I need to test, but I don't want to make them available until they pass the tests. I have LOTS of bare boards on hand, as my aim is to keep them (and any other board I make) available for at least as long as I remain alive. 

May you live happily forever!

[GDMike]

@KSARUL, thank you again for building these!

[+InsaneMultitasker]

On 7/24/2021 at 4:01 PM, InsaneMultitasker said:

Does someone have a copy of the CHART file that is required to interpret the TST program results?  I've been asked to incorporate it into the distribution.  In the meantime, I had a few free clock cycles today:

• Post #1 has been cleaned up to show only the most recent release files
• CFG now prohibits the user from selecting the "transparent color" for foreground/background
• When loading/saving ROS, the file IO routine error trap now informs the user there was a disk/file error

Still looking for CHART.  Anyone?   

It seems that I never uploaded these last few changes to Github, so I'm sorting through the code today.

There is also a problem with SAMS detection if a previously run program changed the default mapping, so I may end up removing that routine for the time being. SAMS detection is neat but not necessary for program operation.  There is also an experimental option that tries to pull ROS from Github via TIPI but I don't think that Github allowed me to pull the binary file in that fashion, so I'll probably disable that too. 

 

[+InsaneMultitasker]

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

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.

This is in response to the conversation from the 4000B topic. I re-read our posts from a few pages back.  If I understand the PCODE startup process, the system identifies the peripherals and caches the sector IO subroutine address. The problem with the Horizon Ramdisk ROS is the common entry point and the use of >83D2 (SRHADR), since the latter doesn't exist as "defined" once the PCODE system is operational.

 

Instead of reworking the level 2 table and its common operation, would a simple fix like this suffice?  The proposed change would bypass SRHADR for sector routine >10. 

 

The follow-up question is whether the common entry point the only stumbling block? 

NEXT0  DATA NEXT1,SECPCO, TEST,>0110,SECIO      Sector Input/Output

;pcode fix
secpco lwpi hiws
       li   r1,next0    ;intercept >10 and bypass >83D2 usage
       jmp  tstpco

 

; common entry from the subprogram table for >10,>11...>15
TEST   LWPI HIWS              Load our workspace
       MOV  @SRHADR,R1        Get pointer to CALL table
tstpco MOV  @6(R1),R11        Get address of CALL program
       MOVB @>834C,R2         Get drive # for this CALL

[apersson850]

I think it is the only issue. The p-system doesn't use anything but the sector access routine. It implements it's own file system on the disk.

 

And yes, you're right about the p-system boot sequence. It looks for the appropriate DSR for each of its devices, disks included, when it starts the first time. When it finds a disk controller, it caches the CRU base address and the subprogram entry address, so it can just enable the card and jump to the routine it wants to execute.

This means no conventional DSRLNK is running during all normal calls, and the first one isn't executed by a DSRLNK code that uses memory in the same way as the standard DSRLNK in the machine either. The p-system uses scratch pad RAM differently and also has some maneuvers to handle the issue that it's already running from a card enabled by a CRU address and present in DSR space when it's supposed to access another DSR.

 

This is also the reason for why the p-system (officially) can only have one disk controller. It finds one and simply accesses it with different disk numbers. You can easily expand from three (TI standard) to four (CorComp, for example) drives, since that's just a question about copying values for drive three to empty slots in the table for drive four. And drives five and six, if you like. But if you want the fifth drive to be a RAMdisk, that implies it's not accessed by the same controller as handles physical disks. Hence you have to create a new PCB (that's the p-systems version of a PAB) and hide it somewhere in VDP RAM where you don't need the space. You can't change the p-system's pointer to end of VDP memory, since it's such a tight fit that if you do, you can't use system programs like the editor. It needs all the memory normally available.

 

Note: A PCB (Peripheral Control Block) is used by the p-system's BIOS. It's more or less a PAB augmented by information about the found CRU base address and branch address to the routine you want to run. It does the same for units like REMIN:, REMOUT: and PRINTER:, which normally are directed to the RS 232 card.

[+InsaneMultitasker]

25 minutes ago, apersson850 said:

I think it is the only issue. The p-system doesn't use anything but the sector access routine. It implements it's own file system on the disk

I added an entry to the issue tracker with a link back to this thread.

Today I made a few edits to the user guide and reviewed the open issues. My goal is to update the repository before I make any more code changes. 

[+InsaneMultitasker]

On 9/11/2023 at 5:24 PM, apersson850 said:

This means no conventional DSRLNK is running during all normal calls, and the first one isn't executed by a DSRLNK code that uses memory in the same way as the standard DSRLNK in the machine either. The p-system uses scratch pad RAM differently and also has some maneuvers to handle the issue that it's already running from a card enabled by a CRU address and present in DSR space when it's supposed to access another DSR.

ROS 8.42c has 16 bytes available in the affected DSR segment. My proposed fix requires 10 bytes.  There are additional uses of >83D2 within ROS, for auto-start and some of the CALLs that are executed via the MENU or via BASIC. I don't think these will affect the PCODE card. 

 

Does the ROS autostart feature override the PCODE startup?  If so, the ROS autostart bypass key (SHIFT) might be an option to cede control to the PCODE card, for a manual dual-boot configuration.

 

I am ready to compile the fix into a usable ROS file for you to test before I move to release stage.  If interested, let me know when you would like to try it. 

[apersson850]

The p-code card uses RAM for different purposes, but some of them are the same as for the ordinary operating system. Can't say about 83D2 without a lot of checking.

 

How does the ROS autostart? The p-code card does that by never returning from the power up routine. This normally works fine since the p-code card has the last CRU base address. Everybody else can run their startup first, provided they do return from them.

 

Testing would be interesting, but I've never made a really good way of transferring files from the internet/PC side to the TI. The other way around I normally print text files to a PC running Hyper Terminal using a serial port. The ROS I do have came of disks with the card.

Edited 10 hours ago by apersson850