GDMike Posted March 5, 2020 Share Posted March 5, 2020 (edited) Let's try something.. I'll try to explain again... lol..oh, and I understand you all completely... typing this up on a phone isn't ideal... Anyway, here goes.. Forget that previous handwritten code. I'll tell ya what is and isn't working. I'm able to turn the card(meaning, AMS card) on and off. And that is completely understood I've set up a page as page 1 in SAMS To use address >3000. So no code needed to show. Because it's understood. My program is just a test It writes a 1 to address >3000 It also echos that to the display at the top left corner,(0). Next I turned on the mapper That's already understood. I write a "2" to address >3000 this is mapped>3000 and not the unmapped. I echo that to the screen at position 40 This is a 40 column mode screen. This next part is my problem. I thought that turning off the card would revert and I should be able to show that Address>3000 to be my original"1" But it doesn't. It still shows a "2". My battery is dying..I'll try to throw up code, but hopefully this clears some of the mess.. and trust me it's just as hard typing it as explaining it. But I'm trying to alleviate too many screen shots, by explaining what is already understood. Edited March 5, 2020 by GDMike 1 Quote Link to comment Share on other sites More sharing options...
GDMike Posted March 5, 2020 Share Posted March 5, 2020 Turning SAMs on/off Setup page 1 BL routines Quote Link to comment Share on other sites More sharing options...
GDMike Posted March 5, 2020 Share Posted March 5, 2020 Here I have the EQU.. And a BL routine to initialize my pages The complete init list isn't showing because, it's exactly like the first init page, just different address.. And it's not important to this since I'm not using it at this point.. but I included a shot of it. Quote Link to comment Share on other sites More sharing options...
GDMike Posted March 5, 2020 Share Posted March 5, 2020 (edited) The top line is my original data in address >3000 BEFORE mapping anything. The second line,ignore the words, that is just left over garb. Were just concerned about the number. This is data I placed at >3000 After turning on the mapper. The third line is after I turned off the mapper and I read >3000 and put those 2 bytes on the screen but it contains a number 2. So it either didn't revert, OR when I mapped it copied what I already had in >3000 ?? I didn't think that would happen.. Edited March 5, 2020 by GDMike Quote Link to comment Share on other sites More sharing options...
Asmusr Posted March 5, 2020 Share Posted March 5, 2020 (edited) Did you set up SAMS register 3 (at >4006, controlling the >3000 region) to map another page than page 3 into that region? Otherwise, when you turn on the SAMS mapper, you are accessing the same RAM as without the mapper turned on. Edit: it looks like you are correctly setting the register to >0100, mapping page 1 into the >3000 region. Edit2: Do you use SBO 0 before setting up the register and SBZ 0 after setting it up? Edited March 5, 2020 by Asmusr 1 Quote Link to comment Share on other sites More sharing options...
GDMike Posted March 5, 2020 Share Posted March 5, 2020 (edited) Yes to everything EXCEPT I set SAMs R3, to >4003 Can you provide me a list of how these addresses map? I was assuming >4000 was addrr 0 >4001 for >1000 >4002 for >2000 >4003 for >3000 >4004 for>4000 I couldn't find a map Maybe, and probably this is my issue I'm recompiling with the change of my SAMs R3 address from what I had>4003 to your suggestion of >4006 Edited March 5, 2020 by GDMike Quote Link to comment Share on other sites More sharing options...
GDMike Posted March 5, 2020 Share Posted March 5, 2020 (edited) I am so happy to report, that yes! I had the wrong Sam's R3 loaded.. Looky here.. Well, I don't see anywhere of how to address R3 in this thread. Unless I missed it somehow. I'm sorry to those who couldn't understand what I was asking, or my explanation of my problem. But Thanks to Mr. ASMUSR, he read between the lines and kinda saw my R3 problem. I usually don't screen shoot items that are generally known already, and that confused everyone I guess. Because I don't think it's worth going over something that can be written by others 5 different ways, which in the long run just confuses things more. I can change spark plugs in a VW, but you may do it differently. An example, I put up a screen shot of my BL routine, and someone said, you don't need the mov R11 etc... Whereas I do because it's a BL routine,or else the mov R11@savrtn wouldn't be there. So I didn't Know what everyone wanted or how they wanted it, as that led me to be confused.. I put up my main code originally that showed All my BLs..then I posted those BL routines..so I don't know what else yall wanted. I'll try harder next time, I've been trying to do a better job at explaining on each of my episodes of "why does this do that" and I seem to be getting worse at it...ml Edited March 5, 2020 by GDMike 1 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted March 5, 2020 Share Posted March 5, 2020 2 hours ago, GDMike said: Yes to everything EXCEPT I set SAMs R3, to >4003 Can you provide me a list of how these addresses map? I was assuming >4000 was addrr 0 >4001 for >1000 >4002 for >2000 >4003 for >3000 >4004 for>4000 I couldn't find a map Maybe, and probably this is my issue I'm recompiling with the change of my SAMs R3 address from what I had>4003 to your suggestion of >4006 The SAMS registers (SRxx) are addressed on even byte boundaries, i.e., incrementing by 2 for the next higher register: >4000 (SR00), >4002 (SR01), >4004 (SR02) , >4006 (SR03), etc. ...lee 1 Quote Link to comment Share on other sites More sharing options...
GDMike Posted March 5, 2020 Share Posted March 5, 2020 Of course when it's explained it makes sense, I was trying to figure out what that address could calculate to and I was all over the place.. I apologise for my stupidity, but it's my first time working this through... Quote Link to comment Share on other sites More sharing options...
GDMike Posted March 5, 2020 Share Posted March 5, 2020 I added another verification step, this Time I did not write to the screen. I wanted to actually turn on the mapper, and just put whatever was in >3000 on the screen, and it's this. Wow..I'm relieved! 1 Quote Link to comment Share on other sites More sharing options...
+9640News Posted March 5, 2020 Share Posted March 5, 2020 1 hour ago, GDMike said: So I didn't Know what everyone wanted or how they wanted it, as that led me to be confused.. I put up my main code originally that showed All my BLs..then I posted those BL routines..so I don't know what else yall wanted. I'll try harder next time, I've been trying to do a better job at explaining on each of my episodes of "why does this do that" and I seem to be getting worse at it...ml Don't feel bad. I've been beating my head on an issue for weeks, chasing an issue for what I thought was a self-imposed coding issue when tweaking someone else's assembly code. It wasn't until much head scratching later, I embedded some additional code elsewhere and discovered some routines I was calling upon were more restrictive than I thought. I would not call the issue a bug in the routines I was calling, rather their scope of use was more limited than I anticipated. Beery 1 Quote Link to comment Share on other sites More sharing options...
GDMike Posted March 5, 2020 Share Posted March 5, 2020 (edited) But you now have experience.. I've still gotta cross that threshold.. I can't even accidentally get things right.. oh, it's not supposed to work that way is it .. I know people get frustrated, either with the messenger or the message, and im just thrilled that in the end things come together, someone somewhere sees my mistake, or mentions a probable miss.. And that happens to me a lot Edited March 5, 2020 by GDMike Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted March 5, 2020 Share Posted March 5, 2020 37 minutes ago, GDMike said: An example, I put up a screen shot of my BL routine, and someone said, you don't need the mov R11 etc... Whereas I do because it's a BL routine,or else the mov R11@savrtn wouldn't be there. This says to me that you misunderstand why you might need to save/restore R11. If you save/restore R11 when it is unnecessary, you waste a lot of time and memory. To recap, execution of BL puts the return address in R11 and the RT directive, which is replaced by the Assembler with “B *R11”, causes a branch back to the address in R11, thus returning to the calling routine. If you change R11 before returning, your program will go off into the weeds. As long as you avoid R11 yourself, the only reason that R11 would get changed is if you called another routine with BL. Here is an example of two subroutines. the first calls the second, but the second does not call another subroutine: * We must save/restore R11 in this subroutine because we trash it with BL @SUBR2 SUBR1 MOV R11,@SAVRTN save return address to avoid trashing it with another call * ... BL @SUBR2 this will trash R11 and is the reason to save it above * ... MOV @SAVRTN,R11 restore return address trashed by above call RT Assembler replaces with B *R11 * There is no change to R11 in this subroutine, so no need to save/restore it SUBR2 LI R0,>0100 * ... B *R11 alternative to RT (see above) If we had, indeed, called a third subroutine (SUBR3, say) from SUBR2, we would have needed a second address (SAVRT2, say) for saving SUBR2’s return address to avoid trashing SUBR1’s return address. If you get to this point, it would be better to implement @TheBF’s suggestion of a small return stack. By the way, here is an alternative to SUBR1 that saves a MOV instruction: * We must save the return address, R11, in this subroutine because we trash it with BL @SUBR2 SUBR1 MOV R11,R7 save return address to unused register to avoid trashing it with another call * ... BL @SUBR2 this will trash R11 and is the reason to save it above * ... B *R7 return to saved address ...lee 1 1 Quote Link to comment Share on other sites More sharing options...
GDMike Posted March 5, 2020 Share Posted March 5, 2020 True. Understood. I'm good on BL..I may have just been confused about something else and mixed the two into the same conversation.. bad thing to do.. Thank you Lee. I'm having as much fun with my car restoration, it's now become a fix it rather than restore.. I'm running between these two projects lately. This one is the easiest vs the car. Quote Link to comment Share on other sites More sharing options...
+9640News Posted March 5, 2020 Share Posted March 5, 2020 As mentioned above, there are lots of ways to accomplish the same task. Sometimes, one is working within memory constraints and needs to memory every byte possible. Other times, it is speed issues and someone may use successive MOV(b) instructions rather than a loop counter. And then other times, neither is critical as you have lots of memory and things aren't speed critical. Beery 1 1 Quote Link to comment Share on other sites More sharing options...
GDMike Posted March 5, 2020 Share Posted March 5, 2020 Yup..been to each of those... I prefer lots of ram.. but with good coding techniques it is possible. I'm doing good here in my code. But as stated, I gotta go check my memory too, hoping I still have some left..lol Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted March 5, 2020 Share Posted March 5, 2020 (edited) I see where you can save 24 Bytes! 8 hours ago, GDMike said: and someone said, "Someone" at your service... Didn't mean to turn you away from the progress you're making! However, the issue of how/why and when to save/restore whilst switching to different parts of your program, seemed germane, perhaps even prerequisite to your issue of switching pages as well. ...Perhaps not. When considering a problem with unfamiliar code, one tries to recognize the "purposes" intended. Things that look particularly out of place tend to fixate attention during this process. We've often all found ourselves falling into the same holes, again and again, since there are so many idiosyncrasies to coding. You're SAMON(mmm, Salmon)/SAMOFF subs, remind me very much of my own ON/OFF subs, used to send 1s 'n 0s, to my shift registers. When developing this process, I wanted to control the speed, in order to check accuracy, so I BL'd out of ON/OFF to my DLY1... but doing this overwrote the address ON/OFF needed in order to return to the subroutine from which, itself was called, replacing R11 instead with the address DLY1 needed in order to return to ON/OFF. Thus, when ON/OFF tries to return to the subroutine from which, itself was called, by using RT, execution instead goes again to the line following the BL to DLY1. This is when I relearned... to save R11 before I BL from one sub to another. Also that different save locations are needed for each deeper level of sub called. So here is an example of a more proper usage of "RT address saves". ...DISCLAIMER: Almost all else herein; is wrong! * CALL DIAL R0=DIALING STRING * AORG >7200 DEF DIAL SAVE DATA 0 DTAB BYTE 0,1,2,3,4,5,6,7,8,9 BYTE >A,>B,>C,>D,>E,>F,>FF DS BSS 768 DIAL MOV R11,@SAVE CLR R12 LI R10,2 PRESS LI R1,DTAB LI R2,JTAB CLR R3 COMP INCT R3 CB *R0,*R1+ JNE COMP DECT R3 A R3,R2 MOV *R2,R2 BL *R2 INC R0 JMP PRESS JTAB DATA D0,D1,D2,D3,D4,D5,D6 DATA D7,D8,D9,DA,DB,DC,DD DATA DE,DF,FF D0 LI R6,4 LI R5,2 JMP SS D1 LI R6,1 LI R5,1 JMP SS D2 LI R6,1 LI R5,2 JMP SS D3 LI R6,1 LI R5,3 JMP SS D4 LI R6,2 LI R5,1 JMP SS D5 LI R6,2 LI R5,2 JMP SS D6 LI R6,2 LI R5,3 JMP SS D7 LI R6,3 LI R5,1 JMP SS D8 LI R6,3 LI R5,2 JMP SS D9 LI R6,3 LI R5,3 JMP SS DA LI R6,1 LI R5,4 JMP SS DB LI R6,2 LI R5,4 JMP SS DC LI R6,3 LI R5,4 JMP SS DD LI R6,4 LI R5,4 JMP SS DE LI R6,4 LI R5,1 JMP SS DF LI R6,4 LI R5,3 JMP SS FF MOV @SAVE,R11 RT * SET SS MOV R11,R13 SE LI R15,4 ROW C R15,R6 JNE LENR BL @OFF DEC R15 JMP ROW LENR CI R15,0 JEQ SHIFTC BL @ON DEC R15 JMP ROW SHIFTC LI R15,4 COL C R15,R5 JNE LENC BL @OFF DEC R15 JMP COL LENC CI R15,0 JEQ STEP2 BL @ON DEC R15 JMP COL STEP2 NOP * RESET CONTROLER LI R4,2 REPEAT LI R7,8 BON BL @OFF DEC R7 JNE BON LI R7,8 BOFF BL @ON DEC R7 JNE BOFF DEC R4 JNE REPEAT BL @LATCH LI R5,9 LI R6,9 BL @DLY1 DEC R10 JNE SE LI R10,2 MOV R13,R11 RT * DIGIT DONE OFF SBZ 16 MOV R11,R14 BL @DLY1 SBO 24 BL @DLY1 SBZ 24 BL @DLY1 MOV R14,R11 RT ON SBO 16 MOV R11,R14 BL @DLY1 SBO 24 BL @DLY1 SBZ 24 BL @DLY1 MOV R14,R11 RT LATCH SBO 25 MOV R11,R14 BL @DLY1 SBZ 25 BL @DLY1 MOV R14,R11 RT DLY1 LI R8,1 DLYR LI R9,>44 DLY DEC R9 JNE DLY DEC R8 JNE DLYR RT RUN CLR R12 LI R10,2 LI R0,DS BL @DIAL RT END (The RUN entry point was only used for testing) Notice that there is no save of R11 before the first level BL, or restore before the final RT. DLY1 being at the deepest level, requires no save/restore. If I were to remove the BLs to DLY1, from the ON/OFF subs, I could also remove the... MOV R11,R14 MOV R14,R11 ...from both of those subs as well! BTW... This test program sends 2 of 8 codes to a 74595 shift reg. driving a 5089 DTMF encoder. P.S. The next version is where I started using page switching, for the first time! Edited March 5, 2020 by HOME AUTOMATION couldn't get <code> 'n [spoiler] to cooperate(???)... I for Invisible(Italics) 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted March 5, 2020 Share Posted March 5, 2020 I think assembly for the SAMS is fast but sucks to change pages. My entire code of Assembly for SAMS in RXB: [1802] *********************************************************** [1803] * CPU PROGRAM FOR >8300 SCATCH PAD SUBROUTINE AMSCRU * [1804] *********************************************************** [1805] * * AORG >8300 [1806] C96B 83,02 AMSCRU DATA >8302 * AMSCRU DATA >8302 * First address. [1807] C96D C0,4C DATA >C04C * MOV R12,R1 * Save R12 [1808] C96F 02,0C DATA >020C * LI R12,>1E00 * Load CRU bits [1809] C971 1E,00 DATA >1E00 * [1810] C973 1D,00 DATA >1D00 * SBO 0 * Set bits ones [1811] C975 C3,01 DATA >C301 * MOV R1,R12 * Restore R12 [1812] C977 04,E0 DATA >04E0 * CLR @>837C * Clear for GPL [1813] C979 83,7C DATA >837C * [1814] C97B 04,5B DATA >045B * RT * Return to GPL. [1815] * END [1816] *********************************************************** [1817] * CPU PROGRAM FOR >8300 SCRATCH PAD CPU ISR HOOK ON * [1818] *********************************************************** [1819] * * AORG >8300 [1820] C97D 83,02 GISRON DATA >8302 * DATA >8302 [1821] C97F C8,20 DATA >C820 * MOV @>834A,@>83C4 [1822] C981 83,4A DATA >834A * [1823] C983 83,C4 DATA >83C4 * [1824] C985 04,E0 DATA >04E0 * EXIT CLR @>837C [1825] C987 83,7C DATA >837C * [1826] C989 04,5B DATA >045B * RT [1827] * * END [1828] *********************************************************** [1829] * CPU PROGRAM FOR >8300 SCRATCH PAD CPU ISR HOOK OFF * [1830] *********************************************************** [1831] C98B 83,02 GISROF DATA >8302 * DATA >8302 [1832] C98D C8,20 DATA >C820 * ISROFF MOV @>83C4,@>83C4 [1833] C98F 83,C4 DATA >83C4 * [1834] C991 83,C4 DATA >83C4 * [1835] C993 13,05 DATA >1305 * JEQ NHOOK [1836] C995 C8,20 DATA >C820 * MOV @>83C4,@>834A [1837] C997 83,C4 DATA >83C4 * [1838] C999 83,4A DATA >834A * [1839] C99B 04,E0 DATA >04E0 * NHOOK CLR @>83C4 [1840] C99D 83,C4 DATA >83C4 * [1841] C99F 04,E0 DATA >04E0 * CLR @>837C [1842] C9A1 83,7C DATA >837C * [1843] C9A3 04,5B DATA >045B * RT [1844] * * END [1845] *********************************************************** 99/4 GPL-ASSEMBLER (Pass 3) correct PAGE 0033 EQUATES ALCS-359 [1846] * CPU PROGRAM FOR >8300 SCATCH PAD SUBROUTINE EXECUTE * [1847] *********************************************************** [1848] * AORG >8300 * [1849] C9A5 83,02 CPUPGM DATA >8302 * CPUPGM DATA >8302 First address. * [1850] C9A7 04,20 DATA >0420 * BLWP @>834A Switch contex * [1851] C9A9 83,4A DATA >834A * FAC not used * [1852] C9AB 04,E0 DATA >04E0 * CLR @>837C Clear for GPL * [1853] C9AD 83,7C DATA >837C * * [1854] C9AF 04,5B DATA >045B * RT Return to GPL. * [1855] * END * [1856] ******************************************************* This code handles CPU programs/CRU/ISRhook/DSR SAMS and is total of 68 bytes. Also only runs from Scratch pad RAM only. It swaps out the same area in scratch pad RAM thus never has any affect on RAM in 32K, this means swapping pages instantly faster. 1 Quote Link to comment Share on other sites More sharing options...
GDMike Posted March 5, 2020 Share Posted March 5, 2020 (edited) I've gotten my pages working and since I never need to return, and I might have to think about this but I'm going to put it out here, I don't have to turn off my SAMs card, so far, because all my pages are running in and out of >C000 as I only need 4K until the user changes the 4Th screen page, then I have to load Sam's page2 for another 4K to be divided up amongst 4 more screen pages. And on and on. So as long as the user is moving pages, there's no need for me to turn off SAMs. But once that changes I will have to.. I think.. probably.. Haven't gotten that far yet ...but yeah.. But even though it's a bit of a pain, what a couple 3 steps, it's powerful. Edited March 5, 2020 by GDMike Quote Link to comment Share on other sites More sharing options...
GDMike Posted March 6, 2020 Share Posted March 6, 2020 4 hours ago, HOME AUTOMATION said: I see where you can save 24 Bytes! "Someone" at your service... Didn't mean to turn you away from the progress you're making! However, the issue of how/why and when to save/restore whilst switching to different parts of your program, seemed germane, perhaps even prerequisite to your issue of switching pages as well. ...Perhaps not. When considering a problem with unfamiliar code, one tries to recognize the "purposes" intended. Things that look particularly out of place tend to fixate attention during this process. We've often all found ourselves falling into the same holes, again and again, since there are so many idiosyncrasies to coding. You're SAMON(mmm, Salmon)/SAMOFF subs, remind me very much of my own ON/OFF subs, used to send 1s 'n 0s, to my shift registers. When developing this process, I wanted to control the speed, in order to check accuracy, so I BL'd out of ON/OFF to my DLY1... but doing this overwrote the address ON/OFF needed in order to return to the subroutine from which, itself was called, replacing R11 instead with the address DLY1 needed in order to return to ON/OFF. Thus, when ON/OFF tries to return to the subroutine from which, itself was called, by using RT, execution instead goes again to the line following the BL to DLY1. This is when I relearned... to save R11 before I BL from one sub to another. Also that different save locations are needed for each deeper level of sub called. So here is an example of a more proper usage of "RT address saves". ...DISCLAIMER: Almost all else herein; is wrong! * CALL DIAL R0=DIALING STRING * AORG >7200 DEF DIAL SAVE DATA 0 DTAB BYTE 0,1,2,3,4,5,6,7,8,9 BYTE >A,>B,>C,>D,>E,>F,>FF DS BSS 768 DIAL MOV R11,@SAVE CLR R12 LI R10,2 PRESS LI R1,DTAB LI R2,JTAB CLR R3 COMP INCT R3 CB *R0,*R1+ JNE COMP DECT R3 A R3,R2 MOV *R2,R2 BL *R2 INC R0 JMP PRESS JTAB DATA D0,D1,D2,D3,D4,D5,D6 DATA D7,D8,D9,DA,DB,DC,DD DATA DE,DF,FF D0 LI R6,4 LI R5,2 JMP SS D1 LI R6,1 LI R5,1 JMP SS D2 LI R6,1 LI R5,2 JMP SS D3 LI R6,1 LI R5,3 JMP SS D4 LI R6,2 LI R5,1 JMP SS D5 LI R6,2 LI R5,2 JMP SS D6 LI R6,2 LI R5,3 JMP SS D7 LI R6,3 LI R5,1 JMP SS D8 LI R6,3 LI R5,2 JMP SS D9 LI R6,3 LI R5,3 JMP SS DA LI R6,1 LI R5,4 JMP SS DB LI R6,2 LI R5,4 JMP SS DC LI R6,3 LI R5,4 JMP SS DD LI R6,4 LI R5,4 JMP SS DE LI R6,4 LI R5,1 JMP SS DF LI R6,4 LI R5,3 JMP SS FF MOV @SAVE,R11 RT * SET SS MOV R11,R13 SE LI R15,4 ROW C R15,R6 JNE LENR BL @OFF DEC R15 JMP ROW LENR CI R15,0 JEQ SHIFTC BL @ON DEC R15 JMP ROW SHIFTC LI R15,4 COL C R15,R5 JNE LENC BL @OFF DEC R15 JMP COL LENC CI R15,0 JEQ STEP2 BL @ON DEC R15 JMP COL STEP2 NOP * RESET CONTROLER LI R4,2 REPEAT LI R7,8 BON BL @OFF DEC R7 JNE BON LI R7,8 BOFF BL @ON DEC R7 JNE BOFF DEC R4 JNE REPEAT BL @LATCH LI R5,9 LI R6,9 BL @DLY1 DEC R10 JNE SE LI R10,2 MOV R13,R11 RT * DIGIT DONE OFF SBZ 16 MOV R11,R14 BL @DLY1 SBO 24 BL @DLY1 SBZ 24 BL @DLY1 MOV R14,R11 RT ON SBO 16 MOV R11,R14 BL @DLY1 SBO 24 BL @DLY1 SBZ 24 BL @DLY1 MOV R14,R11 RT LATCH SBO 25 MOV R11,R14 BL @DLY1 SBZ 25 BL @DLY1 MOV R14,R11 RT DLY1 LI R8,1 DLYR LI R9,>44 DLY DEC R9 JNE DLY DEC R8 JNE DLYR RT RUN CLR R12 LI R10,2 LI R0,DS BL @DIAL RT END (The RUN entry point was only used for testing) Notice that there is no save of R11 before the first level BL, or restore before the final RT. DLY1 being at the deepest level, requires no save/restore. If I were to remove the BLs to DLY1, from the ON/OFF subs, I could also remove the... MOV R11,R14 MOV R14,R11 ...from both of those subs as well! BTW... This test program sends 2 of 8 codes to a 74595 shift reg. driving a 5089 DTMF encoder. P.S. The next version is where I started using page switching, for the first time! My code is a little fishy....hmmm 1 Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted March 6, 2020 Share Posted March 6, 2020 Mine goes a little overboard at times, so... they should get along well together! I could probably eliminate the overly flexible jump table, and increment R3 by 12 using D0's addr. as a base instead, just for starters. Seems like every time I take a look at my old code, I see that it could be leaner. 2 Quote Link to comment Share on other sites More sharing options...
+TheBF Posted August 12, 2020 Share Posted August 12, 2020 I have SAMS card usage working well under Camel99 Forth now. It can access selectable 64K segments as contiguous memory for data and I have a simple way to compile code to discrete 4K pages. For my own amusement, I am working on how I could make a multi-user Forth system for the TI. This is in the tradition of an old system from the 70s called PolyForth. It will consist of a TI-99 console Forth running with along with an RS232 terminal running as the second user. The plan is for the kernel code to run in Super Cart with some extensions in memory >A000..AFFF. The memory from >B000.. >FFFF will be swapped for each user's local Forth system. My question therefore is what is the fastest code that could swap all RAM pages simultaneously? ( >B000,>C000,>D000,>E000,>F000) Here is my first attempt in RPN Forth Assembler. (instructions on the right). I take a SAMS page# from the Forth R4 (tos cache) and increment that value to get pages for each 4K page of RAM. I have this working swapping memory in a task but I am curious if there is any way to map multiple sequential pages faster? Note: ** is indirect addressing. *+ is indirect/auto-increment addressing. CODE HIMAPPER ( SAMSpage# --) \ Maps B000..FFFF into SAMS TOS SWPB, R12 1E00 LI, 0 SBO, \ card on R1 4016 LI, \ HI ram SAMS register for B000 R4 R1 *+ MOV, \ MAP B000, BUMP R1 to next register R4 0100 AI, \ next page R4 R1 *+ MOV, \ MAP C000, BUMP R1 to next register R4 0100 AI, \ next page R4 R1 *+ MOV, \ MAP RD000, BUMP R1 to next register R4 0100 AI, \ next page R4 R1 *+ MOV, \ MAP E000, BUMP R1 to next register R4 0100 AI, \ next page R4 R1 ** MOV, \ MAP F000, BUMP R1 to next register 0 SBZ, \ card off R4 POP, \ refill Forth top of stack register NEXT, ENDCODE 1 Quote Link to comment Share on other sites More sharing options...
GDMike Posted August 12, 2020 Share Posted August 12, 2020 Are you saving a Meg or almost near a Meg of data out to a disk? If so, what output format are you using. Df128? Quote Link to comment Share on other sites More sharing options...
+TheBF Posted August 12, 2020 Share Posted August 12, 2020 Not saving out to disk. Everything stays in the SAMS card. But I have multiple copies of UPPER RAM from B000..FFFF for different Forth tasks running on the machine. 1 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted August 13, 2020 Share Posted August 13, 2020 8 hours ago, TheBF said: I have this working swapping memory in a task but I am curious if there is any way to map multiple sequential pages faster? The only thing faster would be INC, , but that, of course, cannot be done to the left byte of a word without time-consuming manipulation. Presuming the registers are in Scratchpad RAM, it looks like you hit upon the most efficient code right out of the gate! ...lee Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
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.