Jump to content
Opry99er

SuperCart Construction

Recommended Posts

First off, why do you DEFine START? You are not using it in another program or as the operand for the END directive. Secondly, both ENTRY and START must resolve to executable statements. They do not—at least, that is surely not your intention. EVEN and DATA are both Assembler directives, not executable statements. WS in the DATA list is the first non-zero item, which, if I counted correctly has a value of >601A (the address of WS), which would be interpreted by the CPU as 

       S    *R10,R0

$+2 has the address of the LIMI instruction, which is >603E. Again, the CPU interprets this as

       S    *R14+,R0

 

I do not think either of these will do any harm—but, again, this is surely not what you intend. In addition, you have not set your workspace as you thought, so it is set to whatever it was when your program was started.

 

...lee

Share this post


Link to post
Share on other sites
3 hours ago, GDMike said:

I did change a couple things.

I did the 'start data,ws+2" which points to limit 0. AND I added a chardef to my notes program. I compiled,ran and again it works without shutdown, but after shutdown I get a blank screen, as I had been getting prior. Note; the chardef is not within this program, but in the eanote program.

The listing Below "ends" at the next line, thank you.

 

 

I'm

IMG_20191212_084903531.jpg

I'm unsure about the "entry" issue.

 

I do see you are setting the workspace to >7FFE vs. WS???

We can't see the main program...

The >7FFE workspace overlaps the CPU workspace at >8300 (>8000=>8300)

Perhaps the main program or it's subs use this workspace? It would be initialized differently from a menu start.

  • Like 1

Share this post


Link to post
Share on other sites

Naa .I was trying so many ws as that was my last attempt.  Here, I'll show you my change that I was hoping would work. The first screen ends with end, not pictured. The last two screens are the note program I push down into the cart.

. Ty

 

IMG_20191212_121642665.jpg

IMG_20191212_121749462.jpg

IMG_20191212_121755734.jpg

Edited by GDMike

Share this post


Link to post
Share on other sites

It looks like you haven't made provision for the dependencies VMBW and VSBW. The E/A loader places them down in LOWMEM(>2000) and resolves their references within your program... When you reset the 32k those utilities are lost!

 

Easy to copy manually though.:)

Edited by HOME AUTOMATION
  • Like 1

Share this post


Link to post
Share on other sites

Those are in the second program, not the cartridge code. What is going on is I'm loading that second program separately and in high mem, as it runs it pushes itself into the cartridge. The header Program then when called pushes that code back to high mem and branches to it, or supposed to. But for reasons I can't figure I don't see it doing that.

Edited by GDMike

Share this post


Link to post
Share on other sites

This was covered, somewhat, in the recent topic... Converting EA3 to SSS cart

 

Tursi's video shows some of the addresses involved.

 

You can copy all or most of >2000 thru >4000, to your SuperCart, after E/A loads them, than have your first program copy them back again before executing the second program.

Edited by HOME AUTOMATION
  • Like 1

Share this post


Link to post
Share on other sites

Oh my. It's looking more and more like I'll end up reading from dsk. Which was my "not to" goal.i was thinking the compiled program would have everything in it to run in high mem. 

Share this post


Link to post
Share on other sites

Thierry’s site has the E/A ALC for those routines, their workspaces and the REF/DEF table. The REF/DEF table would be unnecessary if you use EQUates in any program that needs the references.

 

...lee

  • Thanks 1

Share this post


Link to post
Share on other sites

Thank you. I'll see what I can do regarding chopping my code. I'm sure I'd have to replace my BLWPs with BLs but does my kscan have to be completely rebuilt And my GPLLNKs? You will ha 😂 have to educate me on using them. Sorry for opening that can.

Share this post


Link to post
Share on other sites
1 minute ago, Lee Stewart said:

Thierry’s site has the E/A ALC for those routines, their workspaces and the REF/DEF table. The REF/DEF table would be unnecessary if you use EQUates in any program that needs the references.

 

...lee

I'm sure I'd just do equates. Thank you lee

Edited by GDMike

Share this post


Link to post
Share on other sites

I'm still having trouble following this, but it looks like it's made clear that there ARE REFs to the E/A utilities involved. Now, the code that you are copying to high memory needs to be pre-linked (ie: an EA#5 style program) for the copy to work at all, but if the utility code is not ALSO copied to low memory, then your program will crash. You might be working the first time because you used Editor/Assembler before testing the cart, so the data was still there.

 

So if so, you need two copies and two blocks of data - the high memory program, and the low memory routines. The ref/def table should not be needed as you aren't doing any lookups - that's used by the linker. You don't need the entire 8k, just save off from >2000 to >2705 - that will cover everything, and is less than 2k.

 

Alternately, and it will take less memory, do away with the EA routines and implement them yourself, in the code. ;) Then you'll have no external dependencies, which appears to be what you're fighting.

 

I'm not sure if you're doing this on hardware as a specific exercise, but Classic99 will build this cartridge for you. ;)

 

  • Thanks 1

Share this post


Link to post
Share on other sites

IMG_20191212_162906268.thumb.jpg.e2879cf31f7c9f36ea113e92d353aade.jpgGood info

I think my book may already have the changes, but I'll double check. 

 

 

 

 

 

IMG_20191212_162914694.jpg

IMG_20191212_162923313.jpg

Edited by GDMike

Share this post


Link to post
Share on other sites

Mr. Tursi thanks for that, as I believe saving >2000 - >2705 is a route that I just was made aware of earlier, but my intention was to push a 7K program into the cartridge and at boot up and selecting, in this case #4 for e/a notes would have pushed that 7K program up to>A000 - but I learned that I cannot have REFs EVEN if that program as there getting smashed at power down, (which leads us here), BUT when I started this project I was only educated to NOT have REFs in my cart program, which I considered was the header program. So I thought assembling a regular REFd program would suffice.  Ughhhh, I've been enlightened. So I'm at a deciding factor: either build a dsk ver. of my e/a notes and let the user have bank switch 8k free space, or press fwd with somehow pushing my e/a notes WITH ext utils into that 8k spot and telling the user to switch. (Look, there gonna have to switch anyway), BUT what's involved in getting REFs to function, as I've never done that. But if it's just BL to an address I'm probably ok, but if it's more, well a learning curve, of course for the better, but it puts me way behind AND in not even sure how large the program will end up now and if it will even fit after the REFs? But basically, yes, I was thinking REFs in my e/a would be ok. But, now I see that a table is being held in lower ram, well maybe table isn't the term, more like state.

Edited by GDMike

Share this post


Link to post
Share on other sites
1 hour ago, GDMike said:

BUT what's involved in getting REFs to function, as I've never done that. But if it's just BL to an address I'm probably ok, but if it's more, well a learning curve, of course for the better, but it puts me way behind AND in not even sure how large the program will end up now and if it will even fit after the REFs? But basically, yes, I was thinking REFs in my e/a would be ok. But, now I see that a table is being held in lower ram, well maybe table isn't the term, more like state.

 

There is, indeed, a table of REFerences maintained at the high end of low expansion RAM by the E/A linking loader (E/A-LL) invoked by choosing E/A option 3. It consists of the name and address of the entry point of each function currently in memory. Any DEFs found in an object file being linked and loaded are added to this table for other object files to use. When the E/A-LL finds a REF in an object file it is processing, it searches the REFerence table for the symbol’s name and, if found, uses its corresponding entry-point address to update all REFerences to that symbol in the currently loading file.

 

When you select the E/A cartridge, a library of the utility functions we all know and love (KSCAN, VMBW, GPLLNK, ...) is copied to low memory along with the symbol REFerence table to link to them. If you use any of those functions, the library must be present anytime your program is run. The same goes for all object files linked and loaded with REFerences to each other’s routines.

 

...lee

  • Thanks 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...