SuperCart Construction

[GDMike]

Hmm..I think I'm still not resolving my ws I suppose since I'm not seeing any changes.

[+Lee Stewart]

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

[HOME AUTOMATION]

...

Edited December 12, 2019 by HOME AUTOMATION

[HOME AUTOMATION]

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

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.

[GDMike]

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

 

Edited December 12, 2019 by GDMike

[HOME AUTOMATION]

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 December 12, 2019 by HOME AUTOMATION

[GDMike]

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 December 12, 2019 by GDMike

[HOME AUTOMATION]

Still, they are needed, but unavailable... In the video... you cut power to the PBOX... effectively, erasing VMBW and WSBW.

[GDMike]

Oh? I thought all this time that those were resolved at compilation time? Omg of course that's a problem

[GDMike]

I need kscan, vwtr,vmbw,vmbr,vsbr,dsrllnk, gpllnk

[HOME AUTOMATION]

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 December 12, 2019 by HOME AUTOMATION

[GDMike]

Yup, but my goal was to have 7k available to the (actual program)

[GDMike]

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. 

[HOME AUTOMATION]

There are other versions of these utils available, you could include in your program!

 

I thought you had about 3 more 8K PAGES to use?

[GDMike]

Not for program space, nope. My program uses, not shown here) 7k

The other free Banks are supposed to be for user free space.

[HOME AUTOMATION]

I'm looking for the source code for the utils... it's been a while!

[+Lee Stewart]

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

[GDMike]

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.

[GDMike]

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 December 12, 2019 by GDMike

[HOME AUTOMATION]

I found this along the way...

 

ROM Command Module 2.0

 

5.1 AVAILABILITY

[GDMike]

Cool beans..I'm printing away..I'll study it.

Thank you!

[Tursi]

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.

 

[GDMike]

Good info

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

 

 

 

 

 

Edited December 12, 2019 by GDMike

[GDMike]

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 December 12, 2019 by GDMike

[+Lee Stewart]

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