Assembling a program on real TI hardware - interesting results

[wolhess]

Hello,
In the past three weeks I've started to write a program in TI Assembly language.
Now that some routines work, I wanted to know which system configuration on a real TI is the fastest for assembly.
 

I tested on two different sysytems:

System 1:
TI Console mit FG99
PEB mit TIPI/RPI (CRU:1000)
TI Controller mit 80 Track mod (CRU:1100)
DSK1.= 5,25" Drive DSSD 360KB
DSK2.= 3,5" Drive DSSD 360KB
DSK3.= 5,25" Drive SSSD 90KB
HRD4000B mit ROS842c v. 14.03.2020 (CRU:1700)
1MB/32KB SAMS 
Speech Synthesizer

System 2:
TI Console mit FG99
PEB mit CorComp DSDD Controller
DSK1.= 3,5" Drive DSDD 360KB
DSK2.= 3,5" Drive DSDD 360KB
DSK3.= 3,5" Drive DSDD 360KB
DSK4.= 5,25" Drive DSDD 360KB, compatible with SSSD 90KB
32KB RAM
RAVE99 Speech Adapter with TI Speech card in PEB

 

For a total of 22 tests I used the following test program:
My test program is a simple DV80 file viewer. You can input any DV80 file name 
like "DSK1.TFILE" and the program shows the file page by page in 40 column text mode.

RFILE1-S contains three copy commands for the files DSK2.99DSRLNK-S, DSK2.99SUB2-S 
and DSK2.99VDP4-S. DSK2 is my TIPI directory!

RFILE1-S1 loads the copy files from DSK1.
RFILE1-S4 loads the copy files from DSK4.
RFILE1-S9 loads the copy files from DSK9.

RFILE2-S contains all copy files in the main source file.

 

 

I gained the following findings from these tests:
1. The TIPI / RPI device offers the fastest working environment on a real TI system.
2. Compared to a floppy drive, the TIPI device is 5 to 7 times faster, depending on the controller!
3. Dividing the source files into several files increases the assembly time.
4. Splitting the files over several drives increases the assembly time.
5. A 5.25 "drive is slightly faster than a 3.5" drive.
6. The Ramdisk HRD4000B with the ROS842c cannot execute source files from a COPY command!
7. With the Ramdisk HRD4000B, the assembly took 1.3 to 2 times longer than with the tipi device.

8. And of course, on a PC, assembling a simple program takes seconds!

 

My test program disk:RFILE.dsk

 

EDIT: Many thanks @FALCOR4 and @InsaneMultitasker, they found out that the problem with assembling on the ramdisk is due to a defective file header in the source files.

After the correction I can now show the complete results.

 

 

 

[+FALCOR4]

10 minutes ago, wolhess said:

6. The Ramdisk HRD4000B with the ROS842c cannot execute source files from a COPY command!

That's interesting.  I wonder what's going on, I assemble source code using the HRD4000B with COPY commands all the time.  I have used both the TI assembler and the RAG assembler.  This deserves some sleuthing.

[wolhess]

1 hour ago, FALCOR4 said:

That's interesting.  I wonder what's going on, I assemble source code using the HRD4000B with COPY commands all the time.  I have used both the TI assembler and the RAG assembler.  This deserves some sleuthing.

maybe it is because I have a tipi card on cru = 1000?

[Omega-TI]

30 minutes ago, wolhess said:

maybe it is because I have a tipi card on cru = 1000?

Possible.  A quick check with the attached program can confirm it for him.

DU_2K-8.bin

[+retroclouds]

I am not surprised that assembly using HRD4000B took longer as on the TIPI. 

That kinda matches the test results I posted a while ago.

ROS level 3 file I/O is blazingly fast on reading, but very slow on writing.

[+9640News]

1 hour ago, wolhess said:

maybe it is because I have a tipi card on cru = 1000?

 

 

 

Edited October 24, 2020 by BeeryMiller

[+FALCOR4]

2 hours ago, wolhess said:

maybe it is because I have a tipi card on cru = 1000?

I renamed your source files to have 8 chars or less in the filenames and they assembled ok.  I put my HRD4000B at CRU >1000 and assembled your RFILE_S9 (I changed the name slightly) and it assembled, with list and cross table, in 1m 15s using the E/A assembler.

[+InsaneMultitasker]

DSR speed tests are affected by the CRU address of the card and the number of cards, subprograms, and devices the DSR must search to find the final target.  In theory, if you move the RAMDISK to >1000 and TIPI to >1700 I would expect slightly different timing.  There are other assemblers and other hardware devices one should consider as well if there is to be a claim to the 'fastest' working environment, and some of this is dependent upon the programmer's needs and desired feature set.

 

@FALCOR4 I have noted the filename length error.  While I suspect this is related to the assembler, I cannot rule out a bug in ROS seeing the other peripherals' results. 

[GDMike]

Just FYI...

What I do when I'm assembling on real steel. I don't.

What I mean is, I like writing my code using the TI but not assembling with it.

 

I'm mapped on my laptop to my share on tipi using classic 99, and I place CL99 in overspeed and assemble that way.

Just my way...

[wolhess]

On 10/24/2020 at 8:52 PM, FALCOR4 said:

I renamed your source files to have 8 chars or less in the filenames and they assembled ok.  I put my HRD4000B at CRU >1000 and assembled your RFILE_S9 (I changed the name slightly) and it assembled, with list and cross table, in 1m 15s using the E/A assembler.

Hi,

 

I renamed my files to a three letter name but always get the DSR ERROR:02F4!

 

I tested some ROS versions 8.41, 8.42 from 2/16/20 and 8.42c from 3/14/20 but with the same DSR ERROR.

 

So yesterday I made all the three RAM tests provided with the HRD4000B card. All tests passed without an ERROR.

Then I configured the HRD completly new and configured the RAM Disk DSK9. with 3200, 1600 and 800 sectores. In any case I got the DSR ERROR.

 

So it seems on my PEB configuration the HRD DSR has this problem all the time.

 

My PEB configuration is:

CRU:1000 TIPI Device

CRU:1100 TI Floppy Controller with 80 TRACK mod.

CRU:1300 RS232 and PIO

CRU:1700 HRD 4000B with RAMBO RAM

CRU:1E00 SAMS card 1MB

 

I used the original E/A cartridge, the E/A complete cartridge from Tursi, the EA version V from Fred KAAL and the RAG Macro Assembler.

All Assembly is working on the tipi device or on the real floppy drives. 

The assembler process begins on the HRD up to the point at which the first COPY command is to be executed.
At this point I am getting the DSR ERROR:02F4 (refers to an error reading a display variable file = the COPY source file I think) 

 

 

[wolhess]

On 10/25/2020 at 3:33 PM, GDMike said:

Just FYI...

What I do when I'm assembling on real steel. I don't.

What I mean is, I like writing my code using the TI but not assembling with it.

 

I'm mapped on my laptop to my share on tipi using classic 99, and I place CL99 in overspeed and assemble that way.

Just my way...

Sometimes I use my PC to compile or assemble some stuff, but mostly I will use my little old TI computer even for some serious program developing and learning assembly.

It's my hobby!

[+FALCOR4]

4 hours ago, wolhess said:

Hi,

 

I renamed my files to a three letter name but always get the DSR ERROR:02F4!

 

I tested some ROS versions 8.41, 8.42 from 2/16/20 and 8.42c from 3/14/20 but with the same DSR ERROR.

 

So yesterday I made all the three RAM tests provided with the HRD4000B card. All tests passed without an ERROR.

Then I configured the HRD completly new and configured the RAM Disk DSK9. with 3200, 1600 and 800 sectores. In any case I got the DSR ERROR.

 

So it seems on my PEB configuration the HRD DSR has this problem all the time.

 

My PEB configuration is:

CRU:1000 TIPI Device

CRU:1100 TI Floppy Controller with 80 TRACK mod.

CRU:1300 RS232 and PIO

CRU:1700 HRD 4000B with RAMBO RAM

CRU:1E00 SAMS card 1MB

 

I used the original E/A cartridge, the E/A complete cartridge from Tursi, the EA version V from Fred KAAL and the RAG Macro Assembler.

All Assembly is working on the tipi device or on the real floppy drives. 

The assembler process begins on the HRD up to the point at which the first COPY command is to be executed.
At this point I am getting the DSR ERROR:02F4 (refers to an error reading a display variable file = the COPY source file I think) 

 

 

When I started with your files I also got the same DSR errors.  Another clue, maybe, is that each one of the files generated an error when I loaded them using the E/A editor but, they loaded.  Then I saved them back out which was successful.  Let me try again this weekend and I'll be a little more methodical this time.  This shouldn't be happening.  Question, what did you use to create the source files?

[+InsaneMultitasker]

@wolhess  - would you mind formatting your RAMdisk with ROS 8.14F then trying the same test?

[wolhess]

1 minute ago, FALCOR4 said:

Question, what did you use to create the source files?

I'm using the EA version V cartridge bin (the FG99 version) to edit and to store the files.

 

I will edit and save all with the EDIT of the original E/A cartridge and then test again.

 

I can also use the TI Writer and save with PF to disk.

 

So I will test both!

[wolhess]

2 minutes ago, InsaneMultitasker said:

would you mind formatting your RAMdisk with ROS 8.14F then trying the same test?

Yes, I can do it with the ROS 8.14F.

 

 

[GDMike]

Exactly what I was thinking.. just wondering if a different outcome may happen

[wolhess]

34 minutes ago, FALCOR4 said:

When I started with your files I also got the same DSR errors.  Another clue, maybe, is that each one of the files generated an error when I loaded them using the E/A editor but, they loaded.  Then I saved them back out which was successful.  Let me try again this weekend and I'll be a little more methodical this time.  This shouldn't be happening.  Question, what did you use to create the source files?

So, I tested right now to load the source files from the tipi device and stored it to the HRD with an original E/A cartridge and the EA disk in DSK1.

And now it works seamless!

 

Then I put the FG99 in and made the same with the TI E/A.bin and it works too.

 

Next I used the E/A version V to load the files from tipi and stored it to the HRD and this now was also working.

 

 

In the last day's I used DM2K v3.0 to copy the files from tipi to the HRD. So I did this now with my original long file names and I used the E/A V .bin. In this try the ERROR appears again!!!!

Then I edited the long DSR file name to 8 character and tried it again and the DSR ERROR was there.

Next I edited all the files with EA-V. and got an error while saving the file "99SUB2-S", so I saved it to 99SUB3-S and changed the main source file too. Now it assembled without an error!

 

All in all my problem is fixed.

 

I think I had two problems.

1. File names with more than 8 characters could not be assembled on the HRD.

2. Maybe DM2K v3.0 cannot copy files from a mapped tipi folder to a HRD drive with 3.200 sectors.

Anyway: Thank you to all for your suggestions and thank you @FALCOR4  for the right idea to check the source file itself.

 

The files from post #1 contains the wrong files, if anybody will try it again. After editing and saving with EA editor, the program can be assembled without errors.

 

@InsaneMultitasker should I try the ROS814F? I think the ROS is not the problem I had. It is possible that two files were damaged when copying from the tipi folder to the HRD drive formatted with the 3200 sectors.

 

Thanks again!

[+InsaneMultitasker]

16 minutes ago, wolhess said:

@InsaneMultitasker should I try the ROS814F? I think the ROS is not the problem I had. It is possible that two files were damaged when copying from the tipi folder to the HRD drive formatted with the 3200 sectors.

Yes, please.  I am curious to know if the 8-character limit is an issue with the old ROS.  Be sure to use the ROSCCTI file not the ROSMYARC when you load ROS. 

I use DM2K to copy from TIPI to HRD w/3200 sectors, so that should be ok, but I have not yet tried v3.0 to confirm.  There can be issues copying if you don't specify the CRU. Are you copying with device TIPI or device DSKx on the TIPI?

 

[wolhess]

3 minutes ago, InsaneMultitasker said:

Are you copying with device TIPI or device DSKx on the TIPI?

I copied with DSK2. (maped to a tipi folder) to DSK9. (HRD drive).
I put always DSK2. in DM2K and it finds the 1000.DSK2. on the tipi. 
 

I will try the ROS814F and report the results here.

[+FALCOR4]

Ok, here's what I found:

 

Loaded the files on my GoTek DSK4.  Used E/A and assembled RFILES1-S4 just fine.

 

Loaded the files on my HRD4000B DSK9.  Used E/A and assembled RFILE1-S9 and got DSR ERROR: 02F4 and I/O ERROR code 0 when it got to COPY "DSK9.99DSRLNK-S"

 

Then, I loaded the files one by one into the E/A Editor.  Files 99DSRLNK-S and 99SUB2-S gave an I/O ERROR code 7, RFILE1_S9 and 99VDP4-S loaded just fine.

 

Went into DM2K and noticed that 99DSRLNK-S and 99SUB2-S had write protect on them so I removed the write protect.

 

I loaded the files again into the E/A editor and got the same I/O ERROR code 7 on files 99DSRLNK-S and 99SUB2-S.  But this time I re-saved them back out to the HRD from the editor with the same filenames.  Now they do not generate the error when loaded into the E/A editor.

 

I assembled the RFILE1-S9 now and it assembled correctly.

 

So, something to do with the write protect bit that the HRD DSR doesn't like?

[+FALCOR4]

12 minutes ago, FALCOR4 said:

Ok, here's what I found:

 

Loaded the files on my GoTek DSK4.  Used E/A and assembled RFILES1-S4 just fine.

 

Loaded the files on my HRD4000B DSK9.  Used E/A and assembled RFILE1-S9 and got DSR ERROR: 02F4 and I/O ERROR code 0 when it got to COPY "DSK9.99DSRLNK-S"

 

Then, I loaded the files one by one into the E/A Editor.  Files 99DSRLNK-S and 99SUB2-S gave an I/O ERROR code 7, RFILE1_S9 and 99VDP4-S loaded just fine.

 

Went into DM2K and noticed that 99DSRLNK-S and 99SUB2-S had write protect on them so I removed the write protect.

 

I loaded the files again into the E/A editor and got the same I/O ERROR code 7 on files 99DSRLNK-S and 99SUB2-S.  But this time I re-saved them back out to the HRD from the editor with the same filenames.  Now they do not generate the error when loaded into the E/A editor.

 

I assembled the RFILE1-S9 now and it assembled correctly.

 

So, something to do with the write protect bit that the HRD DSR doesn't like?

But that also begs the question as to why those two files generated the code 7 error with the E/A Editor from the HRD?  Because, and here's a big because, those two files loaded into the E/A Editor just fine from my GoTek even with the write protect bit on.

[+InsaneMultitasker]

When I view the two protected files (from RDISK.DSK) using MENU/BOOT, there is problem with the file. I did not inspect the File Descriptor Record to determine the issue with the file but here is what I see as an example:  I'm guessing somewhere in the creation or transfer of these files, the EOF marker or record count has been corrupted.  Hard to tell which device may have caused it without further testing.

 

 

[+FALCOR4]

5 minutes ago, InsaneMultitasker said:

When I view the two protected files (from RDISK.DSK) using MENU/BOOT, there is problem with the file. I did not inspect the File Descriptor Record to determine the issue with the file but here is what I see as an example:  I'm guessing somewhere in the creation or transfer of these files, the EOF marker or record count has been corrupted.  Hard to tell which device may have caused it without further testing.

 

 

That would explain that particular error code.  I added some more information to my previous post.  For the record, I used DM2K to transfer the files from my GoTek to the HRD.  I suppose I could try another DM to see if that makes a difference?

[+FALCOR4]

4 minutes ago, FALCOR4 said:

That would explain that particular error code.  I added some more information to my previous post.  For the record, I used DM2K to transfer the files from my GoTek to the HRD.  I suppose I could try another DM to see if that makes a difference?

Just tried using the TI DM2 and got the same results.

[+InsaneMultitasker]

Strangely enough, if I mount the disk via Geneve emulation and copy from the disk to internal Geneve ramdisk, the file exhibits the same behavior on the ramdisk.  So this isn't limited to the Horizon.   I -can- view the file from the floppy without any issues.  I have run out of time but my next suggest step would be to compare the good and bad FDRs for any clues.