• Please review our updated Terms and Rules here

Making TI-74 LOAD.PGM a bit more convenient

Just read Harry’s post - Good stuff, Harry! Also agree with his battery-backed Write-protected

(I’d use a jumper, not a switch) RAM scheme for most use scenarios other than mass production.

Flash is a pain in the <BLEEP>…. 😎

Jack
 
Now its time for me to ask: What is RBUG.SUB?

I cannot test it with COMBO at moment, because the TI with this cartridge is at another location. Can do it on weekend.
Perhaps I have time to solder one more of my 32KB-RAM-Cartridges (GITHUB-Project) in the next days.....

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.
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...)
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!
 

Attachments

Last edited:
I've also ordered one, but nowadays it takes a very long time to send anything from USA to EU - I'm waiting for more then a month now....
I'm not sure, whether HEXTIr can flash or save images to cartridge - someone told me, that it won't work. I'll see myself......
 
@ClassicHasClass:

Please test following (perhaps it works with HEXTIr): Take attatched binary (remove .txt) and load it with RWRAM.B74 to your 32KB COMBO-RAM. y choosing "L(OAD) 8(KB)" : The binary is only 8KB - therefore it fills only the first 8KB of your COMBO-RAM (Bank1)
Then type call GET(1) and your free RAM should be shrinked to ~4,9KB. If I did right, you should have now following extensions available:

CHAR.SUB CLEANUP.SUB EXEC.SUB GETMEM.SUB INDIC.SUB IOX.SUB MEMADD.SUB PEEK.SUB POKE.SUB RBUG.SUB RELMEM.SUB

Will also work with bank 2,3,4, but then you have to save/load full 32KB cartridge. RWRAM is not capable (restricted by IOX) to save/load seperate ranges (banks) - not without modification.

RWRAM: You may modify DeviceNr. in line 191 to your HEXTIr. Afaik HEXTIr can handle files in INTERNAL -format at Dev. 100. I did the test above with TIIF (HEXTIr hasn't arrived till yet...)
Don't know whether it can handle such files on DEV 26/27 or not.
(Btw. If you use DevNr. 1 you can save/load it with CI-7 interface - takes time but it works.....! Saved yesterday a complete MATH-cartridge and loaded it back)

If it doesn't work because of IOX (no glue why it should not), you may use RWCASS.B74 from above! Modify lines 200/270/390 to your Dev.Nr. RWCASS.B74 needs only PEEK/POKE but not IOX (and needs more time).

This method leaks on one thing: Assembler-extensions, which are not in .sub format, can't be handled in this way. For example is @UNDIM/@REDIM or @EVAL, etc. not available, because they are only present in .obj - format, which can only be used in cartridge-images with header.
Unfortunately it's not possible to convert a .obj to a .sub (assembler-source-code is needed).
 

Attachments

Last edited:
ClassicHasClass said:
Is RWRAM.B74 supposed to be converted by TIC74.EXE first? It doesn't like it and emitted an 11-byte PGM.
Click to expand...
Depends on your system. It's a normal Basic-prog in ASCII and with TIIF I can load it to TI74, as it is. TIIF converts it to binary on-the-fly. I don't know whether HEXTIr can do the same, or if it needs to be compressed to binary before.....
To be safe I put you the binary as attachment (and RWCASS.C74 too, if IOX won't work)
For info: You can use TIIF also without the interface (off line) and use most it's features.......(Editor, Compressing, renumbering, syntax-check......)
ClassicHasClass said:
I assume I also need IOX.SUB loaded to run it?
Click to expand...
Yes, needs IOX.
 

Attachments

I'll be out of town for a couple days so I'll look at it when I get back. I don't use TIIF (no Windows machines here, and no source to port it to Mac or Linux), but I can use TIC74 because that will run in DOSBox and under NTVDM. Is a .C74 the same as a .PGM?
 
Yes, I think so - try it!
.c74 is comes up from redirection system of TIIF: TIIF places all files corresponding to their extensions in different directories on PC. This is a very powerfull feature - the user hasn't to care what type of file is incoming and how to use it.

FYI when talking about extensions: TI has defined a lot of filetypes for different purposes. It's a bit confusing....

*.sub = assembler subroutine
*.b74 = basic program (ASCII-format)
*.s74 = *.subs
*.p74 = Pascal program
*.b40 = Basic programm (ASCII, CC40)
*.p40 = Pascal program
*.k95 = Keystroke-program TI-95 (ASCII)
*.pgm = TMS70x0 binary (output by TIC74)
*.c40 = CC40 binary
*.c74 = TI-74 binary -> *.pgm
*.b95 = TI-95 binary
*.obj = relocatable ASM7-object file output
*.bin = ASM7 binary output
*.dat = Data (Dev. 101)
*.dmp = dump from Dev. 44
*.img = image-file
*.int = int. datafile (TIIF)
*.txt = ASCII-format files used by dev.101

This are only extensions, which used by calculator. There much more extensions (formats) used by ASM7, linker, convert,etc.....
 
I have to mention that *dmp (Dev44) is defined by TIIF (not TI). Dev44 provides an output on Dev45 (PC-Screen) and dump this output to a file named trace.dmp.
 
I’m missing something here - If .PGM = .C74, what’s the point of the separate extensions?

Jack
 
Not sure, but I think, TIIFs redirection-system needs this to different between TIIF(PCIF) user-compressed binary of BASIC-progs and binaries, which TI delivers, like LOAD.PGM, which are different to handle. Those TI-binaries cannot be decompressed or listed. That can be protected BASIC-progs and/or stand-alone assembler progs (afaik).
User-compressed BASIC- or Keystroke(TI 95) progs are decompressed on-the-fly, when loading to TIIF-editor.
 
It’s been awhile, but memory claims a “Protected” BASIC pgm has a bit set (flag byte?)

which stops the interpreter from de-tokenizing and LISTing the pgm. A COMPRESSed

BASIC pgm is a different beast, dispensing with line #s & resolving relative addresses,

for instance. I’m not saying it is’nt “Protected” - It may be, I don’t remember - But…

The objective may _not_ be encryption, but speed. It’s usual for a smallish

COMPRESSed BASIC pgm to be somewhat larger than the unCOMPRESSed pgm;

larger COMPRESSed BASIC pgms are typically smaller than the unCOMPRESSed

tokenized BASIC version, and they are always (?) faster…

Jack
 
You are right. Protection depends on the protection-byte. Basic progs needs to be converted/compressed to be transfered to TI-RAM. Pure ASCII-Data isn't accepted (as I've seen in TIIF).

Assembler Progs are always binaries and can only(*) be loaded with the LOAD-program, which seems to be a "hybrid" itself. It is loadable like a BASIC.-prog (but not saveable or listable, like a protected one) and, as doc says, its a "stand allone assemblerprogram" (whatever that means).

(*) It may also be poked into RAM as data-array from a Basicprog. Perhaps LOAD is such a thing......or OLD-command has more features then described in manuals or SDS-docs.
 
BASIC ASCII pgms are essentially “Source” files; each line entry must be “tokenized”

before it can be executed by the Interpreter. With pgm entry from the kybd, this occurs

“on-the fly” with each line entry, courtesy system routine CRUNCH. ASCII “.bas” pgms

written off-Console (in a PC text editor, say…) are pre-processed by TIC74 into “b74”

format; CRUNCHing, & all the other book-keeping necessary for a runnable “tokenized”

“.pgm” could then be done by the Console - I do suspect TIC74 of hidden talents in this

direction, though… 😎
 
I think it worked! I put RWRAM.C74 (renamed to RWRAM.PGM for consistency with my other files) and TEST8.BIN on the HEXTIr's SD card. I ran it according to your directions, and after the CALL GET(1) I was able to execute CALL POKE(8395,10):CALL EXEC(8395) - storing and executing a RETS - and it worked fine.

I wonder if there's a way to avoid the IOX dependency so it can just load and go.
 

Attachments

  • PXL_20251117_015739027.jpg
    PXL_20251117_015739027.jpg
    1.7 MB · Views: 2
You must log in or register to reply here.
Back
Top