• Please review our updated Terms and Rules here

Making TI-74 LOAD.PGM a bit more convenient

Unfortunately TI-74 CALL IO has not the same functionality as CALL IO on CC40. For that reason IOX is needed.
It also can be done by POKE (very slowly), but that is the same issue.......
 
Q

Amigaharry said:
Edit to RWCASS.B74: Read docs again and recognized, that it should be possible to write images from cassette to (RAM) cartridge! Crazy!
I can't believe that it is also possible to flash! Will try this in future!
The only problem I see for CI7-only owners: How can they load IOX.SUB? I found no way till now, to save LOAD.PGM or any assember-extension to cassette.
Click to expand...
Hi Harry - A reason .pgms & .subs can’t be loaded from cassette may be that in these files, on disk, instruction
Operators are Absolute, but instruction Operands may not be; these Operands are indicated by placeholder
values after the Operator opcode, where a Table of Offsets (relative to the EXEC address IIRC) is appended from
which the actual value of the Operand (which itself may be an offset (to the Pgm Counter this time) or an address)
is calculated. Confusing, ain’t it? 😎

In the CC40/TI74/TI95 world all this book-keeping is handled by the Console, PCIF.EXE, LOAD.PGM, & (maybe)
TIC74. BUILD also comes to mind…
But, AFAIK its not written in stone anywhere that it could’nt have been done with cassette storage, but apparently
if it was implemented, it’s well-hidden…



Amigaharry said:
The only way at moment is to send them a .wav from a 8KB image, created with CALL PUT and saved to cassette with RWCASS.B74. (This I will try...)
I Parallel I'm in contact with a famous programmer, who wrote a DOS-prog (LIST74.EXE) to convert a .vaw to a TI-Basic-listing!! Works fine. Only the other way round - Basic2Wav -doesn't work for now.
Remove .txt at attatched files.
Record wit CI7 a program to your PC, lets say test.wav. Then in DOS: LIST74 -w test.wav test.b74 - be surprised!
Of course you can read then .wav back to the TI (CI7). Mybe you have to play a bit with loudness-level....
So, if you don't have nothing else as a CI-7 for program exchange , you can send a .wav to your friend.....hehe!
Click to expand...
 
Hmm, TI say something different:


The LOAD subprogram loads assembly language subprograms from
an external storage device, such as an audio cassette, into
computer memory. These subprograms are normally CALLable
directly from BASIC. Refer to sections on memory images,
headers, and assembly language subprograms for further
information.

More than one subprogram may be loaded into memory. When
space permits, assembly language subprograms may reside in memory
in addition to BASIC programs and subprograms. When loaded in
this manner, these subprograms are appended to the memory space
reserved for system operation.

"Device.filename" identifies the device where the assembly
language subprogram is stored and the particular file to be
loaded. "Device" is the number associated with the physical
device and can be from 1 through 255. "Filename" identifies the
particular file. ..........


I would say, the main reason is, that we don't (?) know how to save LOAD.pgm and .subs to cassette. TI seems to have done this in the past.
LOAD does the relocation in RAM - I think, this works with cassette too.
 
I can’t say I’ve ever tried to save LOAD.PGM to Cassette - So what happens?

(I don’t have access to a CI-7 or a cassette player at the moment…}
 
LOAD.pgm isn't possible to save from TI-7 (error 14: Bad program type!) with SAVE
Makes no difference whether to CI-7 or TIIF or HEXTir.
*.sub - progs aren't even recognized by SAVE. To save via peek is also not possible, because at this time *.sub is reclocated in RAM and all jump-adresses are different to original.
 
Amigaharry said:
LOAD.pgm isn't possible to save from TI-7 (error 14: Bad program type!) with SAVE
Makes no difference whether to CI-7 or TIIF or HEXTir.
*.sub - progs aren't even recognized by SAVE. To save via peek is also not possible, because at this time *.sub is reclocated in RAM and all jump-adresses are different to original.
Click to expand...

Exactly - _If_ the 74’s ROM _can_ pack & unpack a relocation table - LOAD can…

I presume OPENing a BINARY file with a Record length of the file length on disk has been tried?
 
> LOAD can…

Maybe. That LOAD can unpack itself on-the-fly seems unlikely, so how is it unpacked?

The remaining suspects seem to be PCIF. EXE, & Console ROM.

But if PCIF or ROM can process relocation tables, why is LOAD needed at all? Go figure…
 
Amigaharry said:
Hmm, TI say something different:


The LOAD subprogram loads assembly language subprograms from
an external storage device, such as an audio cassette, into
computer memory. These subprograms are normally CALLable
directly from BASIC. Refer to sections on memory images,
headers, and assembly language subprograms for further
information.

More than one subprogram may be loaded into memory. When
space permits, assembly language subprograms may reside in memory
in addition to BASIC programs and subprograms. When loaded in
this manner, these subprograms are appended to the memory space
reserved for system operation.

"Device.filename" identifies the device where the assembly
language subprogram is stored and the particular file to be
loaded. "Device" is the number associated with the physical
device and can be from 1 through 255. "Filename" identifies the
particular file. ..........


I would say, the main reason is, that we don't (?) know how to save LOAD.pgm and .subs to cassette. TI seems to have done this in the past.
LOAD does the relocation in RAM - I think, this works with cassette too.
Click to expand...
 
Here’s another official pronouncement on LOAD - Both yours & mine are incorrect.


Or incomplete, depending on how we prefer our logic chopped.

Fact: LOAD.PGM is a _Main_ pgm, with a relocation table. Most .SUBs have relocation

tables too - Plainly visible on Disk with M$-DEBUG (or whatever). Since LOAD.PGM is not

loaded with LOAD.PGM, we may infer that ROM _can_ handle relocation tables…

So what’s up with the cassette implementation?


Back in the day I used a NEC 8201a to troubleshoot serial connections; that thing had cassette

storage, was even slower than CAS74 (300 Baud, IIRC) and handled machine code programs

on cassette just fine…
 
If you have a look at the first 2 byte of files you can always see the same difference between filetypes (the "identifyer"?):

*.C74 (and "normal! *.pgm starts with Hex 80 03 xx xx......
*.B74 (Basicprogs) starts with Hex 20 20 ....first line number.......
LOAD.PGM starts with Hex C4 0B xx xx xx......

This filetype isn't explained in docs. Therefore I think OLD has more functions then documented.

I tried to change first 2 bytes of LOAD.PGM to Hex 08 03. It doesn't run any more (W22 Too long), but LIST shows some strange characters. Before List did nothing.
Then I tried Hex 20 20: Now LIST says "E15 Protection Error" and RUN gives "E14 at 23943 Bad program type".

Do you know, what bit has to be toggled to remove protection?

For my understanding, it cannot be a pure basic-prog! How is it possible, to load and relocate .*subs without any assembler-extension?
Pure Basic has no commands, to do that (as far as we know.....?). It was possible on CC40, but not on T-74.

What can be:

a) OLD has more functionalities as known and can load such special progs. In a publication was mentioned, that it's "stand alone assembler program". Think it was PPC-Notes or in a internal TI-paper - not sure. Such progs are not described in my docs (or I haven't found it till yet).

b) Basic has commands nobody outside TI knows...

c) It's magic :alien: I really want to understand this "magic" trick.

I've also problems to load LOAD.PGM with HEXTIr (via USB or Serial / have no BPD+ Drive! ). Interface and TI crashes and have to be resetted or turned off/disconnected from power source. All other progs are doing well and flawless, but not this beast! Can even load/save/print all others via serial on my old Amiga3000......😄
This points to a filetype, HEXTIr-firmware cannot handle on USB and Serial-port (only with BPD+, I suppose.
 
TI calls the 1st byte in the pgm header the “FLAG” byte. Each bit identifies some aspect

of the file, some bits are “Reserved”, which means they’re not telling der Landser what

its function is…

For example >C4 is a common Flag byte on an Asm Main pgm. >44, an Asm sub-pgm;

>80, a common Flag on a BASIC pgm - All of these in System RAM. Not all FLAG bits are

significant IIRC, but random changes may produce “undefined” results, as you’ve noticed.

In BASIC main pgms the 2nd byte is the length of the pgm header, IIRC. The 3rd & 4th

bytes are a 16-bit value denoting the length of the pgm (which is maintained on-the-fly

by the BASIC line editor.) The pgm image then follows.

I’ll remember more of this, no doubt - As ever, YMMV… “8)
 
LOAD.PGM is definitely machine code. If I reverse the bytes, I can disassemble it and get something sensible:

Code: 
;   0014:    88 01 DC 59 
   MOVD     %$01DC, R89
;   0018:    D5 53       
   CLR      R83
;   001A:    EB 0A       
   TRAP 20  10
;   001C:    72 1E 53    
   MOV      %$1E, R83
;   001F:    EB 1A       
   TRAP 20  26
;   0021:    EB 18       
   TRAP 20  24
;   0023:    EB 04       
   TRAP 20  4
;   0025:    7D 4C 5C    
   CMP      %$4C, R92
;   0028:    E2 15       
   JZ       $003F
;   002A:    7D 6C 5C    
   CMP      %$6C, R92
;   002D:    E2 10       
   JZ       $003F
;   002F:    7D 71 5C    
   CMP      %$71, R92
;   0032:    E2 07       
   JZ       $003B
;   0034:    7D 51 5C    
   CMP      %$51, R92
;   0037:    E2 02       
   JZ       $003B
;   0039:    E0 E1       
   JMP      $001C
;   003B:    EB 17       
   TRAP 20  23
;   003D:    EA          
   TRAP     21
;   003E:    06          
   DINT     
{...}
 
Amigaharry said:
If you have a look at the first 2 byte of files you can always see the same difference between filetypes (the "identifyer"?):

*.C74 (and "normal! *.pgm starts with Hex 80 03 xx xx......
*.B74 (Basicprogs) starts with Hex 20 20 ....first line number.......
LOAD.PGM starts with Hex C4 0B xx xx xx......

This filetype isn't explained in docs. Therefore I think OLD has more functions then documented.

I tried to change first 2 bytes of LOAD.PGM to Hex 08 03. It doesn't run any more (W22 Too long), but LIST shows some strange characters. Before List did nothing.
Then I tried Hex 20 20: Now LIST says "E15 Protection Error" and RUN gives "E14 at 23943 Bad program type".

Do you know, what bit has to be toggled to remove protection?
Click to expand...
Flag byte, bit 5, Set=Protection On, Reset=Off
Amigaharry said:
For my understanding, it cannot be a pure basic-prog! How is it possible, to load and relocate .*subs without any assembler-extension?
Pure Basic has no commands, to do that (as far as we know.....?). It was possible on CC40, but not on T-74.
Click to expand...
There are two options that I know of:

0) Write an Extension to BASIC which manipulates the Dockbus Protocol to do what you want…

b) Use CALL IO / CALL IOX to manipulate the Dockbus Protocol to do what you want…

In the Use case you cite Option (b) makes more sense, IMHO.

Amigaharry said:
What can be:

a) OLD has more functionalities as known and can load such special progs. In a publication was mentioned, that it's "stand alone assembler program". Think it was PPC-Notes or in a internal TI-paper - not sure. Such progs are not described in my docs (or I haven't found it till yet).
Click to expand...
“Stand-Alone Assembler Pgm” = Assembler Main Pgm, which LOAD.PGM is…
Amigaharry said:
b) Basic has commands nobody outside TI knows...
Click to expand...
Could be, I suppose…😎 Over the years I’ve heard several times about drop-in replacements for

TMS70C## uC’s that have an expanded Register File, 256 bytes instead of 128 - Sounds good,

No? Well, I’m still waiting for mine…

Amigaharry said:
c) It's magic :alien: I really want to understand this "magic" trick.
Click to expand...
Most of the “Magic” comes from understanding the System, including the Dockbus Protocol.
Especially the Dockbus Protocol…
Amigaharry said:
I've also problems to load LOAD.PGM with HEXTIr (via B or Serial / have no BPD+ Drive! ). Interface and TI crashes and have to be resetted or turned off/disconnected from power source. All other progs are doing well and flawless, but not this beast! Can even load/save/print all others via serial on my old Amiga3000......😄
This points to a filetype, HEXTIr-firmware cannot handle on USB and Serial-port (only with BPD+, I suppose.
Click to expand...
No opinion on HEXTir - No hands-on with it.
 
Amigaharry said:
LOAD.pgm isn't possible to save from TI-7 (error 14: Bad program type!) with SAVE
Makes no difference whether to CI-7 or TIIF or HEXTir.
*.sub - progs aren't even recognized by SAVE. To save via peek is also not possible, because at this time *.sub is reclocated in RAM and all jump-adresses are different to original.
Click to expand...
In both cases (LOAD.PGM, & *.sub) the files are relative files with relocation tables appended. SAVEing

either is not possible because the relocation table downloaded with the pgm file from DISK is destroyed by

the relocation process; thus the pgm image in System RAM is an Absolute file with no relocation table appended;

Which obviously can’t be SAVEd to disk - What’s needed is an image of the file on disk (with its relocation table)…

I wonder if the file on disk can be recreated from the OBJ file…?
 
Amigaharry said:
I've also problems to load LOAD.PGM with HEXTIr (via USB or Serial / have no BPD+ Drive! ).
Click to expand...
Odd. It loads perfectly on mine (in fact, I could only bootstrap your TEST8.BIN by using the HEXTIr, since I don't have a PC-IF). I do have a BPD+ drive as well and I'm sure that would work fine too. Are you running the most current firmware on your HEXTIr?
 
Unfortunately I've some problems with HEXTIr since today - it stops connection via DOCKBUS to TI74 and cannot be reactivated. Enter CLI-mode from USB or serial work neither.
Only Recovery-Mode works, but without BPD+ this doesn't help. Cannot do reset or flash new FW. In worst case I've to send it to a good friend with a BPC+ to recover.....hope it's no hardware-issue....

I've to say: It works the last days flawless (and astonishing quick). I could load/save progs via serial oder USB, printout data to dev 26/27 (even with TI95) and use CLI to config interface - nice little thing.
For me, this is enough, because all other things I can do with TIIF.
 
JGardner said:
........
b) Use CALL IO / CALL IOX to manipulate the Dockbus Protocol to do what you want…

In the Use case you cite Option (b) makes more sense, IMHO.
......
Click to expand...
Agree! Perhaps LOAD.PGM can be transfered with IOX to RAM-Cartridge "as it is" and then copied to CI-7 with the same method......hmm!
In this case no care to relocation or protection bit is needed. When loading it later from cassette it does it automaticaly.
The same method, if it works, has to be used for *.sub.
Cool! I see "The TI-74 Assembler Cassette" 😅
 
You must log in or register to reply here.
Back
Top