Supernotes

[HOME AUTOMATION]

Hope you don't mind my reposting this ...it seems fairly innocuous to me...

 

On 1/17/2022 at 1:59 AM, HOME AUTOMATION said:

Ok ...I took a stab at this.?

       DEF  START
       REF  LOADER,VMBW
PAB    DATA 0,0,0,0,11
       TEXT 'DSK4.HELPSO' 21 BYTES, EVEN, DIRECTIVE, NOT NEEDED(as assembler does it for you!)
START  LI   R0,>03C0
       LI   R1,PAB
       LI   R2,21
       BLWP @VMBW
       AI   R0,9
       MOV  R0,@>8356
       BLWP @LOADER
DONE   LIMI 0
       LIMI 1
       JMP  DONE
       END

I setup the PAB with all zeros except for the name length(11).

 

Looking at the PAB(>03C0) in the below pic., we can see that the LOADER placed the values >5050 into bytes >04, >05, and left >5C, in byte >07.

The first few lines of the screen acted as the 80 byte buffer.

 

 

Your segment loaded at >3000, as specified by >AORG...

 

 

We don't even need to determine the length, since the LOADER uses an EOF marker!

 

Looks good to me.

 

LOADMES 640 B · 2 downloads

LOADMEO 640 B · 3 downloads

 

When we left-off, from what I gather... you felt this code hadn't loaded properly because it didn't do what was expected when you... B @>3000.

Looking at the disassembled line(s)...

 

 

>  3000  C80B  mov  R11,@>0000            
         0000

 

This  code seems to contain >0000, on many lines that should contain addresses. I'm imagining you assembled this code without the needed labels, or something went wrong with the assembly process. This is shown in the OBJECT code as well...

 

 

I don't believe this happened at load-time, but that it could only have happed at assembly-time.

 

also...

 

Because your program loads as separate modules... If you don't load the expected modules first... The LOADER finds no DEFs to resolve your REFS. 

[apersson850]

On 11/15/2022 at 2:28 AM, Lee Stewart said:

One way to achieve your goal involves using @ralphb’s xas99 assembler.

Ah, perfect. I wasn't aware that kind of support already existed.

Similar idea to what I came up with for the p-system, to load various support stuff into various memory areas in different DSR spaces.

Edited November 16, 2022 by apersson850

[GDMike]

14 hours ago, HOME AUTOMATION said:

Hope you don't mind my reposting this ...it seems fairly innocuous to me...

 

 

When we left-off, from what I gather... you felt this code hadn't loaded properly because it didn't do what was expected when you... B @>3000.

Looking at the disassembled line(s)...

 

 

>  3000  C80B  mov  R11,@>0000            
         0000

 

This  code seems to contain >0000, on many lines that should contain addresses. I'm imagining you assembled this code without the needed labels, or something went wrong with the assembly process. This is shown in the OBJECT code as well...

 

 

I don't believe this happened at load-time, but that it could only have happed at assembly-time.

 

also...

 

Because your program loads as separate modules... If you don't load the expected modules first... The LOADER finds no DEFs to resolve your REFS. 

I believe I kept seeing raw text instead of code in my file read and I had to give up. 

[+Lee Stewart]

36 minutes ago, GDMike said:

I believe I kept seeing raw text instead of code in my file read and I had to give up

 

What file contains raw text? And...What does “raw text” mean?

 

As @HOME AUTOMATION and @apersson850 said, the object file has the hex code of the program (the part that will get loaded) as ASCII text strings between text tags, CRC, etc., not as actual binary code that goes into RAM—it must be translated at load time.

 

If you tell the assembler to emit compressed code, the hex code of the program (which is ASCII text above) is actual binary code between text tags, CRC, etc.

 

Perhaps, your “raw text” was uncompressed object code.

 

...lee

[GDMike]

19 hours ago, HOME AUTOMATION said:

 

Ignore the box above, my phone wasn't getting this right. . anyway... I meant ASCII...to me that's raw text. Anyway, when I looked at the file I was preparing AFTER assembling, it was readable by ea DF80 reader. So I assumed it wasn't binary executable code.

[+Lee Stewart]

19 minutes ago, GDMike said:

So I assumed it wasn't binary executable code.

 

So, now you realize it was supposed to be that way, right?

[apersson850]

What meets the description "binary executable code" in the TI 99/4A environment is a memory image file. But you don't get them out of the assembler.

[HOME AUTOMATION]

"binary executable code" ...is what the @LOADER places in memory.

[apersson850]

Yes, of course. And a memory image file is a snapshot of that memory, stored in a file.

[GDMike]

15 hours ago, Lee Stewart said:

 

So, now you realize it was supposed to be that way, right?

Haha...I really wasn't expecting it to be readable.lol...

 

I think i have enough information to attempt this from the "LOADER". I'll work on it.

Thx everyone... you are the best!

 

Edited November 16, 2022 by GDMike

[GDMike]

I also found this by Brian and Farmer Potato. This has been a popular item, I guess in the beginning to me it was clear as mud, but I'm starting to see thru it.

 

I'm sorry Brian that I made you answer this again... but I just found it. I suppose I should search the topic before asking..my apologies.

 

On 11/11/2020 at 5:38 PM, TheBF said:

How does that work? I have never built anything like that. 

The Assembler image has to flag that somehow I guess.

Does the loader correct any addresses in the image or is everything relative to some reference value in the image?

Although my Forth compiler's code is relocatable using PC relative branches, the location of the two stacks have to be initialized to something and there are system variables that point to various addresses in the system for parsing text and managing the linked list of labels.

 

I would need to do some real study to make a RORG image I suspect.

RORG is the default setting in the TI assembler.

 

The assembler produces tagged object code files, with directives for relocatable address (starting at 0), absolute address, etc. These are "EA3", DIS/FIX80 format files.

 

The linking loader "corrects" or rebases relocatable symbolic addreses.

 

If you are producing a binary file, in a PROGRAM type, this is also known as EA5, it is not relocatable. The 6-byte header at the start tells the EA5 loader where to put it, how long it is, and if there are more files.

 

I'm sure you guessed that tagged object format is much bigger than PROGRAM binaries. It uses 5 hex digits to represent 2 bytes. A tag and 2 bytes. It also has checksum tags and symbol REF and DEF tags.  A 'compressed' variant uses binary instead of ascii, so a tag is followed by 2 bytes 0-255.

 

The linking loader knows the first free address in memory, and puts any relocatable segments starting there. It adds the starting address to local symbolic addresses in the object file, which are assembled as offsets from the program's start.

 

On the 4A, loading begins at the high memory at >A000. If that fills up, it goes to low memory at >2000-ish.

 

If your object file is relocatable, and the loader begins by putting it at >A000, the result is just as if you specified AORG >A000. Except, the first free address isn't updated.

 

GENLINK is a lot more versatile. You tell it which address ranges can hold relocatable code. But it outputs a memory image (or set of images) that are binary dumps of that memory. It takes place virtually, so you can link into any address range, or produce more than one output that will be overlaid.

 

The 4A linking loader only loads, it doesn't save PROGRAM images. To save images, you need to use TI's SAVE utility, or my SuperSave which does all the work for you. - farmer potato.

 

This from FP is nice to see as well. 

And he has the "Super Save" utility that is also available.

Edited November 16, 2022 by GDMike

[+TheBF]

No worries.

This was what I was trying to get at a few posts back.

Convert your object file for your subroutines to E/A 5 programs that load at >3000.

Then as Lee said your program can use file function 5 to load each image.

If you MAP >3000 to a SAMS page, then the code will be loaded "into" the SAMS page. 

 

Where I get off the bus is the details of using Ralph's fancy assembler the way Lee described. Never been there. 

[GDMike]

2 hours ago, TheBF said:

No worries.

This was what I was trying to get at a few posts back.

Convert your object file for your subroutines to E/A 5 programs that load at >3000.

Then as Lee said your program can use file function 5 to load each image.

If you MAP >3000 to a SAMS page, then the code will be loaded "into" the SAMS page. 

 

Where I get off the bus is the details of using Ralph's fancy assembler the way Lee described. Never been there. 

I think the super saver by FP, (Farmer Potato), could do that..I'll have to check again because It'll have to be compiled as absolute code. Right? Because all my code will be AORG'd to >3000.

And then I can just use the PAB that @home automation supplied me back when. I think I've got this right..I think 

 

Edited November 16, 2022 by GDMike
Typo

[+Lee Stewart]

1 hour ago, GDMike said:

I think the super saver by FP, (Farmer Potato), could do that..I'll have to check again because It'll have to be compiled as absolute code. Right? Because all my code will be AORG'd to >3000.

And then I can just use the PAB that @home automation supplied me back when. I think I've got this right..I think 

 

That involves a lot more work than what I proposed. You will need to assemble, load, and save each >3000-based file, separately. If you have 10 overlays, that is 30 separate operations! Then, at program run time, you must deal with loading 10 separate binary files in your main program.

 

You have loads less work with my proposal, all of the source code is placed in a single file and assembled only once to binaries. One COPY command puts all of the binaries in a single file. One TI99Dir operation converts the file for loading on real iron or emulator. That is a total of only 3 operations, all 3 of which can be packed into a single operation in a batch file! Then, at program run time, you load everything from a single binary file.

 

...lee

[GDMike]

4 hours ago, Lee Stewart said:

 

That involves a lot more work than what I proposed. You will need to assemble, load, and save each >3000-based file, separately. If you have 10 overlays, that is 30 separate operations! Then, at program run time, you must deal with loading 10 separate binary files in your main program.

 

You have loads less work with my proposal, all of the source code is placed in a single file and assembled only once to binaries. One COPY command puts all of the binaries in a single file. One TI99Dir operation converts the file for loading on real iron or emulator. That is a total of only 3 operations, all 3 of which can be packed into a single operation in a batch file! Then, at program run time, you load everything from a single binary file.

 

...lee

Right. I see. And of course if I only had 12K of code or less then I can easily do that with help from my supercart, but my plan was moving code that was larger(if I had it).. 

But anyway, I don't have a large code set at the moment, but I'm always thinking.. and if I did have that much code then I'd have to consider the amount of time spent on reading it and executing it.

And depending on whether it was just lookup data from a search then that kinda time needed might not be justified, example,  like a spell checker would need. That sort of data could easily hit 64K and more.

But if  absolute pages are known for something, like pages for a game, then I suppose the time needed would work out. Anyway... just a thought.

Thx lee 

 

 

 

 

Edited November 17, 2022 by GDMike

[HOME AUTOMATION]

...Perhaps there is something to be said for the long and arduous approach.

[+FarmerPotato]

On 11/16/2022 at 1:43 PM, GDMike said:

I think the super saver by FP, (Farmer Potato), could do that..I'll have to check again because It'll have to be compiled as absolute code. Right? Because all my code will be AORG'd to >3000.

And then I can just use the PAB that @home automation supplied me back when. I think I've got this right..I think 

 

No, SuperSave only saves RORG code, no AORG. Unlike SAVE which captures memory between SLOAD and SLAST, it checks the first free addr before and after LOADER. 
 

To make the overlays, you’re better off using AORG, and the SAVE utility. 

DEF SLOAD,SFIRST,SLAST

AORG >3000
SFIRST EQU $
SLOAD EQU $

… code and data 

SLAST EQU $
   END

 

Assemble, load, load SAVE, run SAVE. It’s been a long time, I might be wrong about a detail or two. 
 

Result of SAVE is a PROGRAM file with a 6 byte header:

DATA 0000  ; flag, continues in  another file? NO 
DATA >3000 ; from SLOAD
DATA SLAST-SFIRST ; not sure here…is this where it is?? 

followed by Your bytes from >3000 to SLAST 

 

RUN PROGRAM FILE decodes this , first using the LOAD opcode in a PAB to get it into VDP RAM. Then it looks at the SLOAD and size from the header. It moves it into RAM  using VMBR.  You would need to write your own code that does this. 
 

Edited November 17, 2022 by FarmerPotato

[GDMike]

1 hour ago, FarmerPotato said:

No, SuperSave only saves RORG code, no AORG. Unlike SAVE which captures memory between SLOAD and SLAST, it checks the first free addr before and after LOADER. 
 

To make the overlays, you’re better off using AORG, and the SAVE utility. 

 

DEF SLOAD,SFIRST,SLAST

AORG >3000

SFIRST EQU $

SLOAD EQU $

 

… code and data 

 

SLAST EQU $

   END

 

Assemble, load, load SAVE, run SAVE. It’s been a long time, I might be wrong about a detail or two. 
 

Result of SAVE is a PROGRAM file with a 6 byte header:

 

DATA 0000  ; flag, continues in  another file? NO 

DATA >3000 ; from SLOAD

DATA SLAST-SFIRST ; not sure here…is this where it is?? 

 

followed by Your bytes from >3000 to SLAST 

 

RUN PROGRAM FILE decodes this , first using the LOAD opcode in a PAB to get it into VDP RAM. Then it looks at the SLOAD and size from the header. It moves it into RAM  using VMBR. 
 

Ahh.  Ok.ty

[GDMike]

Happy Thanksgiving everyone! Unfortunately I'm under the weather this week and last, but I'm getting into the TI spirit next week for sure.

Have a safe holiday.

[HOME AUTOMATION]

It's Thanksgiving, already? You think you've got-it-bad...
Here, where I'm located, Mallomars', prices, haven't dropped below $4.50, once yet.😞

Paying that much, goes against my constitution.💸
With no-hope-in-sight, a condition of Mallomartremia, is beginning to set-in!💃
My hands are shaking so badly now, I don't even have to stir my drinks.🍸

 

Good-luck, to you, Sir!😷

 

  HT!🍠

[+TheBF]

4 hours ago, GDMike said:

Happy Thanksgiving everyone! Unfortunately I'm under the weather this week and last, but I'm getting into the TI spirit next week for sure.

Have a safe holiday.

You know the drill. Drink lots of fluids, get lots of rest and take your favourite off the shelf medication for a fever. (That doesn't mean Jim Beam ) 

Hope you get well soon.

Up here we have Flu, Covid and kids are getting RSV. Hospitals are overflowing.

 

[GDMike]

40 minutes ago, TheBF said:

You know the drill. Drink lots of fluids, get lots of rest and take your favourite off the shelf medication for a fever. (That doesn't mean Jim Beam ) 

Hope you get well soon.

Up here we have Flu, Covid and kids are getting RSV. Hospitals are overflowing.

 

Right. Bugs are going around and around. If I drank but I don't, and no smoking since 2000.

But my son (22yo) brought some bug home from his work and now I'm sick.

Hex was sick for a week before me. Yuk.. but my other son is just healthy. They can't afford to move so I'm stuck with them.. 😂😂😆 just kidding, maybe there stuck with me.  

Either way, we have plenty of room. 

Happy TG!

 

[GDMike]

Yes..I'm better now as I've been dealing with some back problems, some kinda cough, and the general crud BUT I'm feeling better and I started playing with SNP today and this is what I accomplished:

 

Fixed a bug in the Function 3, delete line routine.

   ( Prior, if you pressed F3 anywhere on a line with or without data on the line or on the screen, a flash of sporadic characters showed near the bottom of the screen).

 

My next fix was to increase the available user screen pages from, (whatever it was, like? 293 or something, I can't remember, but it was shorter than 400 pages).

So yeah, it's 400 pages like it's supposed to be now. The pages don't quite reach the highest SAMs bank so as not to crash into my HELP menu that I discuss below.

 

Adding more user pages had created an error in my on-screen HELP routine.

 

I ended up moving that routine to the highest SAMs Bank where it's safely sitting above the user pages.

All tested fine.

 

I did find an issue where if you press  Function "V", paste previously copied line, 

that I get sporadic characters near the end of line.. but this just needs a variable buffer clearing at program start..I'll take care of that tomorrow.. since it's 3am...yuk

 

Ill just go through the program and shorten code and update the documents this week.

 

I do have a plan to add  "insert page" and "delete page"  to the program.

This will rely on moving each page up/down through SAMS and adjusting.

-nuff 4Tday

 

 

 

 

 

 

 

Edited December 11, 2022 by GDMike
Typo

[+TheBF]

6 hours ago, GDMike said:

Yes..I'm better now as I've been dealing with some back problems, some kinda cough, and the general crud

If you have persistent cough , with fatigue, after a viral infection you might have a "secondary" infection. (other germs take advantage of your weakened state)

If you can get to the doc and let them listen to your lungs that would be a good thing.

I developed pneumonia last month after flu or Covid, don't know which one. 5 days on antibiotic and I am back to my normal nerdy self.

[GDMike]

It's just a nagging dry cough flareup that is happening like every 4 hours, otherwise no hint of cough. But I've got indication it's subsiding today.

Thanks.. feeling better!!