GDMike Posted September 2, 2020 Author Share Posted September 2, 2020 Yeah, I had some issues I have 4 stages for setting up my SAMs. Pages. The first is SAMON, which turns on the card, I found lots of sources on how this is done and is the simplest of all my call instructions. Then I made "ADPG", I found three or four different sources on how this is accomplished and I really got so turned around on getting this right. This is just an ADD BANK routine. It just increments the previous bank number without going past a predefined bank. And then I made "SBZ" this just makes the current bank - bank 2, I call home bank. I can quickly reset my bank to this number. And lastly, "SAMOFF" this was as easy as turning on the card, but there were variations on getting this accomplished. So now I can get to any bank within my >E000 - >EFFF address range. I'm finally getting somewhere, I think.. Hehe... Quote Link to comment Share on other sites More sharing options...
+TheBF Posted September 2, 2020 Share Posted September 2, 2020 What do you keep in low RAM for your editor? Just asking, but sometimes it's better to use 3000..3FFF for SAMS data and keep hi RAM for more features in your CODE. 1 Quote Link to comment Share on other sites More sharing options...
GDMike Posted September 2, 2020 Author Share Posted September 2, 2020 (edited) I'm pulling supercart data, I have an import function that pulls in 9 SNE (supernotes express) pages, which are still 840 bytes of user data per user screen. And then I have my library for CALLS, such as call color, call char, call beep, etc.., all located in FE00-hmm like 40 bytes or so. So I think I'm safe there for that since I'm not loading ANYTHING around that area. But originally, when SNP wasn't using SAMs, I was using that >3000 area for pages too. I've release some ram in that area though and since I've been so focused on just getting Sam's to work, I may have to revisit that LRam area again. And I've still gotta get DSR disk save/load invoked. My calculations say SNP user pages = 1000 bytes, that's 840 bytes for individual screen pages and a 160 byte area for hypertext user data per screen page, just one per SNP page allowed. So maybe that's an area I can use for my pab buffer. Edited September 2, 2020 by GDMike Quote Link to comment Share on other sites More sharing options...
+TheBF Posted September 2, 2020 Share Posted September 2, 2020 It's probably worth doing to give you a straight run of memory in upper RAM for all your code. To change your SAMS code you just change the address you use to put your bank number in. To use >3000 as your swap page write the SAMS page number data to >4006. Right now for >E000 you are using >401C as the SAMS register. 1 Quote Link to comment Share on other sites More sharing options...
GDMike Posted September 2, 2020 Author Share Posted September 2, 2020 (edited) Double edit: I meant>3000 geeeees Edit: Ok, I think I see your point and I think you're concerned about program space running into >E000.. ok, that does make more sense now that I thought about that. So I'll be moving Sam's page to>3000 It's only a block, so no big deal. And my program can grow. ----------- Original message below I chose E000 because I knew at the time that nothing was going on there and was good for my "SNP pages" since I'm only looking at 1ea 840 byte area at any given time. And possibly another 160 byte for hypertext that sits at the top of each SNP page, basically the last 160 bytes. But I see what you're saying, and luckily, I've learned real well how to manipulate that Sam's address, so yes, easy to move it to another from>E000(401C). That's kinda why I've not continued yet on my page up/down and SAVE page,(referring to SNP screen pages), on an exact route with addressing until I get it thought out more, like with what your suggesting. I'm also thinking on the lines of expansion, as if an 80 column card becomes available to the masses, how to handle that data, so I thought I didn't want to be stuck in the middle of low ram for that, or what about larger supercarts, as I'm using a four bank now for my test, but what if... this, that.. I kinda probably want to keep things higher. And as far as time and data access, Sam's isn't slow to me, it initialized 235 banks in like, snap of a finger. That's like a second or less. In my scientific world. A snap back is quick. I thought my init was cheating but I went back and pulled random addresses between>E000->EFFF and found my test word was in fact true. So I don't have issues, at this time in speed for read/write. I can't wait to get back at it! I'm just not so fast.. Edited September 2, 2020 by GDMike 2 Quote Link to comment Share on other sites More sharing options...
GDMike Posted September 3, 2020 Author Share Posted September 3, 2020 (edited) How cool is AORG >6000!!!! ... program BL routines ... ... RT When you have an extra 8K sitting there in a supercart and you have 8K of code to push to it. Im having a blast rt now with trying to make decisions on how the SNP and SNE 32K, (4X banks of 8K), can be effective and still retain user data but using 1 bank for either the SNP or SNE programs. This doesn't change the way that SNE currently works, BUT it would mean that SNE would need it's program reloaded prior to use AND will not alter the user data in the other 3 banks. This way I can use that 1st bank, currently SNE program for program space for SNP. uh yeah! Like 8K contiguous. I mean yes I have SAMs but I don't have 8K without bank switching. I could get a lot of BL routines in that 8K space. Does it mean that the supercart would have to be part of the whole deal, well yeah, but SNP is related to SNE and SNE uses the 4 banks in the cartridge. So why not extend this out to SNP as a MUST have, SAMs is already a must have item. SNP is already using A000-D840 for program space. SNP doesn't allow writing to any banks in the supercart, but SNE writes to 3 of them so I wouldn't have to worry about user corruption occuring by accident, unless someone pulled the cartridge out. It's just an idea for now. Edited September 3, 2020 by GDMike Updated Last sentence 1 Quote Link to comment Share on other sites More sharing options...
GDMike Posted September 3, 2020 Author Share Posted September 3, 2020 (edited) There is an UPDATE to SNE to 1.2.1 EA df80 files, option 3, load(not run) MENU, then F9 and load SNE, and run program name: SNE Both cartridge switches down and press CTRL 1, this pushes the SNE program utils into the cartridge Reboot, follow on screen instructions. This latest update just correctly instructs the user during install that both bank switches must be down. MENU SNE Edited September 4, 2020 by GDMike 1 Quote Link to comment Share on other sites More sharing options...
+TheBF Posted September 3, 2020 Share Posted September 3, 2020 16 hours ago, GDMike said: How cool is AORG >6000!!!! ... program BL routines ... ... RT When you have an extra 8K sitting there in a supercart and you have 8K of code to push to it. Im having a blast rt now with trying to make decisions on how the SNP and SNE 32K, (4X banks of 8K), can be effective and still retain user data but using 1 bank for either the SNP or SNE programs. This doesn't change the way that SNE currently works, BUT it would mean that SNE would need it's program reloaded prior to use AND will not alter the user data in the other 3 banks. This way I can use that 1st bank, currently SNE program for program space for SNP. uh yeah! Like 8K contiguous. I mean yes I have SAMs but I don't have 8K without bank switching. I could get a lot of BL routines in that 8K space. Does it mean that the supercart would have to be part of the whole deal, well yeah, but SNP is related to SNE and SNE uses the 4 banks in the cartridge. So why not extend this out to SNP as a MUST have, SAMs is already a must have item. SNP is already using A000-D840 for program space. SNP doesn't allow writing to any banks in the supercart, but SNE writes to 3 of them so I wouldn't have to worry about user corruption occuring by accident, unless someone pulled the cartridge out. It's just an idea for now. You can also put the primary program at >6000 and load different sub-routine overlays into A000 and Page A000 into SAMS pages. Maybe a list of sub-routine addresses could go into a table at that top of A000 on each page. You could then pull in a SAMS page and call the sub-routines with indexed addressing. The main program would have to remember the bank and subroutine numbers for each bank. (forgive my poor knowledge of Assembly language syntax. Not sure what it would take to keep something like this straight.) SUBTAB DATA SUB0,SUB1,SUB2,SUB3,SUB4,SUB5,SUB6 LI R1,3 * select sub-routine 3 BL SUBTAB@(R1) * call the sub-routine You are the architect. It is pretty cool to have that extra memory in the cartridge for sure. 2 Quote Link to comment Share on other sites More sharing options...
GDMike Posted September 4, 2020 Author Share Posted September 4, 2020 I'm just using a set bank to home Then rolling a loop for the bank number I need. Since nothing special Except getting to the bank has to happen. But it's an interesting concept there. Thx Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted September 4, 2020 Share Posted September 4, 2020 17 hours ago, TheBF said: (forgive my poor knowledge of Assembly language syntax. Not sure what it would take to keep something like this straight.) SUBTAB DATA SUB0,SUB1,SUB2,SUB3,SUB4,SUB5,SUB6 LI R1,3 * select sub-routine 3 BL SUBTAB@(R1) * call the sub-routine DATA operands are words (2 bytes), so you need to double the selection number to get the proper index into the table. Also, your BL will try to execute that word. You need to load that word into a register: SUBTAB DATA SUB0,SUB1,SUB2,SUB3,SUB4,SUB5,SUB6 LI R1,3 * select sub-routine 3 SLA R1,1 * double R1 to get proper index MOV SUBTAB@(R1),R1 * load the sub-routine address BL *R1 * branch to it ...lee 1 1 Quote Link to comment Share on other sites More sharing options...
GDMike Posted September 4, 2020 Author Share Posted September 4, 2020 Always a great day when Lee is clarifying Of course the idea is brilliant, and so is the clarification. Thanks you guys for this idea 1 Quote Link to comment Share on other sites More sharing options...
apersson850 Posted September 4, 2020 Share Posted September 4, 2020 (edited) The correct syntax is like this: SUBTAB DATA SUB0,SUB1,SUB2,SUB3,SUB4,SUB5,SUB6 LI R1,3 * select sub-routine 3 SLA R1,1 * double R1 to get proper index MOV @SUBTAB(R1),R1 * load the sub-routine address BL *R1 * branch to it As I first wrote in another thread, if the index is known, and not passed like a parameter, then you write like this: SUBTAB DATA SUB0,SUB1,SUB2,SUB3,SUB4,SUB5,SUB6 MOV @SUBTAB+(3*2),R1 * load the sub-routine address BL *R1 * branch to it Here you let the assembler do the math at assembly time, instead of the CPU doing it at runtime. Edited September 4, 2020 by apersson850 2 Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted September 4, 2020 Share Posted September 4, 2020 (edited) This Jump Table idea definitely works, as long as its not too long! I cribbed it from somewhere! Edited September 4, 2020 by HOME AUTOMATION too 1 Quote Link to comment Share on other sites More sharing options...
GDMike Posted September 4, 2020 Author Share Posted September 4, 2020 Yup. Got it 1 Quote Link to comment Share on other sites More sharing options...
GDMike Posted September 7, 2020 Author Share Posted September 7, 2020 (edited) Updated information regarding SNP. I've decided to NOT create an area in SAMs prior to import SNE pages 1-27. Instead, I'll let the user understand that they need to move any pages that contain data on pages 1-27 to another area, pages that are blank somewhere in the 900 something SNP pages (840 byte) space. Because moving 900 something pages 27 page steps/235 banks of 4K in memory just to make room for 27 import pages is a lot of code and the time it takes to process the move is not timely. So with that, the user will be prompted to move switches on the cart, and cautioned about overwriting etc.. , something that happens anyway, then SNE pages can be quickly imported. SNP will have the ability to move pages. So, my last 3 days of SAMs work is just going in the trash. My program was growing too far too fast so I had to come up with this alternative. But I think it is better anyway. Edited September 7, 2020 by GDMike Quote Link to comment Share on other sites More sharing options...
+TheBF Posted September 9, 2020 Share Posted September 9, 2020 I don't fully understand your trials and tribulations of course, but once you get it working the way you want it would be possible to retry SAMS. Maybe even to have multiple files in memory that can be selected. Just page out the blocks where the text is located with some other pages. Keep at it. 1 Quote Link to comment Share on other sites More sharing options...
GDMike Posted September 9, 2020 Author Share Posted September 9, 2020 (edited) I hear ya, Well I've got to get the basics done first. I've solved the Sam's problems I had earlier. I've got three variables that will help track. "BANK" tracks the bank number And "PAGE" tracks the actual real SNE page. And "PB", (not peanut butter), is a value between 1-4. If page down happens, then we increment "PAGE" and check if "PB" is greater than 4, if so add 1 to "BANK" And select the first of 4 addresses in the bank And so on... I have a routine that updates the current screen with the right data from BANK and PAGE. It's all coming along, thanks for good advice Edited September 9, 2020 by GDMike 2 Quote Link to comment Share on other sites More sharing options...
GDMike Posted September 15, 2020 Author Share Posted September 15, 2020 (edited) Update on SNP, The program MUST have a SAMS card in order to use. It's dedicated now. As SNP now loads, the user is given a message that it's checking for SAMS and initializes, so far, 240 SAMs pages with a 30 second wait time. You are messaged if no card is found. Edited September 16, 2020 by GDMike Clarify 3 Quote Link to comment Share on other sites More sharing options...
GDMike Posted October 5, 2020 Author Share Posted October 5, 2020 (edited) This is a utility for erasing the supercart. It's a DF 80 file, program name is SC Program start name is START Here's a video on explanation of how and why I needed this program. VID_20201004_211412047.mp4 DSKA0065.dsk Edited October 5, 2020 by GDMike 2 Quote Link to comment Share on other sites More sharing options...
GDMike Posted October 5, 2020 Author Share Posted October 5, 2020 I've noticed on occasion that I couldn't even get to option 2, the editor assembler menu to run the SC program. If you encounter that, you can do as I do and select 1 for basic and CALL LOAD("DSK#.SC) and then CALL LINK("START") And the program will launch but you won't be able to read anything on the menu, but just press 1 and spacebar and you'll Clear the Cartridge that way. Reboot and your e/a menu will appear. Quote Link to comment Share on other sites More sharing options...
+TheBF Posted October 5, 2020 Share Posted October 5, 2020 11 hours ago, GDMike said: This is a utility for erasing the supercart. It's a DF 80 file, program name is SC Program start name is START Here's a video on explanation of how and why I needed this program. VID_20201004_211412047.mp4 DSKA0065.dsk 180 kB · 3 downloads Remember how you would do that in Forth? HEX 6000 2000 0 FILL 1 Quote Link to comment Share on other sites More sharing options...
GDMike Posted October 5, 2020 Author Share Posted October 5, 2020 (edited) I actually grabbed the TI Forth disk last night and said, whoa, there hauss! I don't have time rt now. But I'd love to try.. Edited October 5, 2020 by GDMike Quote Link to comment Share on other sites More sharing options...
GDMike Posted October 5, 2020 Author Share Posted October 5, 2020 Ahhhh. Forth..mmmmm Quote Link to comment Share on other sites More sharing options...
GDMike Posted October 5, 2020 Author Share Posted October 5, 2020 1 hour ago, TheBF said: Remember how you would do that in Forth? HEX 6000 2000 0 FILL Ti forth doesn't have fill. I think TF has V! Though. Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted October 5, 2020 Share Posted October 5, 2020 26 minutes ago, GDMike said: Ti forth doesn't have fill. I think TF has V! , though. TI Forth does, indeed, have FILL (fills RAM). The same goes for fbForth. TurboForth’s V! stores only one byte and that to VRAM, not RAM. ...lee 1 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.