GDMike Posted September 10, 2020 Share Posted September 10, 2020 21 minutes ago, Lee Stewart said: Here is the same code, but easier to read, i.e., all commented-out lines are removed: Hide contents VSBW EQU >210C ***** turn off SAMS Mapping SAMOFF LI R12,>1E00 SBZ 1 RT ***** turn on SAMS Mapping (and set for >3000->3FFF???} SAMON LI R12,>1E00 SBO 1 RT **** set to BANK 16 *++ Trashes R1, R3. FIRSTB LI R12,>1E00 SBO 0 LI R3,>4006 LI R1,>1000 bank 16 MOVB R1,*R3 SBZ 0 RT ***** MAP A BANK *++ Bank# must be in R1 before calling this routine. *++ Trashes R3. MAPPG LI R12,>1E00 SBO 0 LI R3,>4006 MOV R1,*R3 SBZ 0 RT *************************** PROGRAM TEST BL @SAMON BL @FIRSTB * Map first bank (bank 16) CLR R5 CLR R4 LI R2,>4041 * initial value to copy into 10 banks (16-25) LI R5,>1000 * set opening SAMS page INC1 MOV R5,R1 *<--+ set SAMS page for MAPPG LI R4,>3000 * | starting RAM for copy to this bank BL @MAPPG * | map next bank *+++ Do this for each bank so we can actually see a change on screen AI R2,>0101 * | increment copy value to next pair of letters *+++ | *+++ The following code fills each successive bank with a new pair of letters INC2 MOV R2,*R4+ *<-+| "AB"(bank1),"BC"(bank2),... to next RAM address CI R4,>33C0 * || are we out of screen range? JLT INC2 *>-+| *+++ * | AI R5,>0100 * | increment to next bank CI R5,>1A00 * | only want to fill banks >10->19 (16-25) JLT INC1 *>--+ next bank if less than bank 26 LI R5,>1000 * opening SAMS page INC3 MOV R5,R1 *<--+ set SAMS page for MAPPG LI R4,>3000 * | starting RAM for reading from this bank BL @MAPPG | LI R0,0 * | set initial screen position LI R4,>3000 * | starting RAM for reading from this bank *+++ | INC4 MOVB *R4+,R1 *<-+| MOVB now..we are working with bytes, not words BLWP @VSBW || INC R0 * || increment screen position CI R0,960 * || done? JLT INC4 *>-+| *+++ | AI R5,>0100 * | increment to next bank CI R5,>1A00 * | only want to read banks >10->19 (16-25) JLT INC3 *>--+ next bank if less than bank 26 BL @SAMOFF * not necessary unless want powerup conditions B @STOP ********************** STOP LIMI 2 LIMI 0 JMP STOP END PROGRAM ...lee Thank you so much lee, yes, I thought,as I had some luck with adding 1 at that MSB @>4004. I think I've got a handle on it now. Thanks!! Quote Link to comment Share on other sites More sharing options...
GDMike Posted September 10, 2020 Share Posted September 10, 2020 (edited) *++ Bank# must be in R1 before calling this routine. *++ Trashes R3. MAPPG LI R12,>1E00 SBO 0 LI R3,>4006 MOV R1,*R3 SBZ 0 RT I didn't know that about Sam's register. Well that throws a wrench into everything!! No wonder I had so much trouble and why it wouldn't work. Can't read a SAMs register, manipulate it and put it back. That's my missing link...of knowledge Thank you!!! Edited September 10, 2020 by GDMike Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted September 11, 2020 Share Posted September 11, 2020 1 hour ago, Lee Stewart said: 1 hour ago, GDMike said: Is this valid? ADPG MOV R11,@SAVRTN *this does nothin' useful LI R12,>1E00 SBO 0 LI R3,>4006 MOV *R3,R1 AI R1,>0100 MOV R1,*R3 SBO 1 RT No. Sorry but, this DOES take >3000-3FFF address range to the next higher numbered SAMS page! 1 hour ago, Lee Stewart said: MOV *R3,R1 I do not think you can read a SAMS register, which is what this is trying to do. You must tell SAMS what to load. You can only run Au contraire mon frère. Yes, you can read SAMS' addressing registers, when CRU >1E00 is set to 1(SBO 0). Even when in TRANSPARENT MODE, they show either their default values, or whatever you have changed them to. What you can't read(ever) are the CRU bits(always return a 1, even when set to 0). 1 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted September 11, 2020 Share Posted September 11, 2020 47 minutes ago, GDMike said: And the code below. LI R3,>3000 Mov *R3 R1 LI R2,>0C00 A R2,R1 MOV R1,*R3 And will this give me bank 13 of (>3000->3FFF)? Almost certainly not. You cannot predict what is sitting at >3000. Also, you are not banking >3000 – >3FFF, You are banking SAMS memory pages to appear at CPU RAM space >3000 – >3FFF. You cannot do anything to those addresses. You can only read/write from/to them. If you want SAMS bank 13 to appear at >3000, assuming SAMS mapping is on (SBO 1) (and, while you are using mapping in your program, there is no good reason to turn it off except at initial setup time), you Enable writing the mapper registers ( SBO 0 ) Write >0D00 to one of your workspace (WS) registers. R1 is fine ( LI R1,>0D00 ) Put the relevant mapper register in another WS register. R3 is fine ( LI R3,>4006 ) Write the SAMS page # to the mapper register ( MOV R1,*R3 ) Disable writing to the mapper registers ( SBZ 0 ) You now can read/write from/to any address in CPU RAM >3000 – >3FFF to access SAMS memory >D000 – >DFFF (page 13). As long as you leave SAMS page 13 in that RAM window, that is all the CPU will see in that RAM space. ...lee 1 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted September 11, 2020 Share Posted September 11, 2020 8 minutes ago, HOME AUTOMATION said: Sorry but, this DOES take >3000-3FFF address range to the next higher numbered SAMS page! 15 minutes ago, HOME AUTOMATION said: Au contraire mon frère. Yes, you can read SAMS' addressing registers, when CRU >1E00 is set to 1(SBO 0). Even when in TRANSPARENT MODE, they show either their default values, or whatever you have changed them to. Good to know. I was not aware of that. I will correct that post. The code still will not work the way @GDMike thinks it will, with mapping turned off at the end. Writing the registers should be turned off ( SBZ 0 ), with mapping left on ( SBO 1 ) ...lee 1 Quote Link to comment Share on other sites More sharing options...
GDMike Posted September 11, 2020 Share Posted September 11, 2020 Gotcha! Thanks Lee and automation, I'll be adjusting things tommorow. Whohoo Quote Link to comment Share on other sites More sharing options...
+FALCOR4 Posted September 11, 2020 Share Posted September 11, 2020 On 9/10/2020 at 6:10 PM, Lee Stewart said: On 9/10/2020 at 5:53 PM, HOME AUTOMATION said: Au contraire mon frère. Yes, you can read SAMS' addressing registers, when CRU >1E00 is set to 1(SBO 0). Even when in TRANSPARENT MODE, they show either their default values, or whatever you have changed them to. Please do not depend on being able to read the SAMS registers in your software! Yes, you can read back the registers but only in 1M segments, the SAMS greater than 1M boards will not read back anything beyond 1M segments; i.e. if you have a 4M or 8M or 16M SAMS it will not give you any granularity beyond 1M. Just a caution to those who are writing software. And, currently there is only a 4M SAMS available but, the possibility for a 16M does exist and, in my opinion, should be accounted for in software development. Again, IMHO. 2 Quote Link to comment Share on other sites More sharing options...
GDMike Posted September 11, 2020 Share Posted September 11, 2020 5 minutes ago, FALCOR4 said: Please do not depend on being able to read the SAMS registers in your software! Yes, you can read back the registers but only in 1M segments, the SAMS greater than 1M boards will not not read back anything beyond 1M segments; i.e. if you have a 4M or 8M or 16M SAMS it will not give your any granularity beyond 1M. Just a caution to those who are writing software. And, currently there is only a 4M SAMS available but, the possibility for a 16M does exist and, in my opinion, should be accounted for in software development. Again, IMHO. Very good, I've made note of that and adjusted. Testing now Quote Link to comment Share on other sites More sharing options...
GDMike Posted September 11, 2020 Share Posted September 11, 2020 (edited) Yes, thanks to everyone for learning my head something new!! My test works! I had filled a 4K area at >3000 with "AB" For banks 16-17. Then Turned off mapper mode with the subroutine, "SAMOFF", I then called my subroutine, "SAMON", and subroutine, "SBH" to put bank# to a 1. And ran the test. Then I got a screen full of "AB" when I read >3000 through 960 bytes. I reran the test, Except I added an extra "1" in R8, a counter that gets added to >10 in ADPG and bumps the loop on how many banks I need skip before reading 960 bytes again. And here's my 2 test results. One min. I'll upload This is exactly how it should look for my test. I'll be using a variable anyway to track "BANK" so in the future I'll just be using BANK in the "ADPG" routine to look at and that way I'm always landing on the right bank#. Thanks to @ASMUSR, Lee, theBF and @automation! Job well explained and worked out. It's always good to get an explanation sometimes. Now, where's my car keys... Edited September 11, 2020 by GDMike 2 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted September 11, 2020 Share Posted September 11, 2020 20 minutes ago, FALCOR4 said: Please do not depend on being able to read the SAMS registers in your software! Yes, you can read back the registers but only in 1M segments, the SAMS greater than 1M boards will not not read back anything beyond 1M segments; i.e. if you have a 4M or 8M or 16M SAMS it will not give your any granularity beyond 1M. Just a caution to those who are writing software. And, currently there is only a 4M SAMS available but, the possibility for a 16M does exist and, in my opinion, should be accounted for in software development. Again, IMHO. Re accounting for higher SAMS memory, I initially changed fbForth 2.0 to check for 16 MiB SAMS because it seemed unlikely to go higher anytime soon, even though it could, I suppose, go as high as 256 MiB. I did finally settle on 32 MiB, mainly due to Classic99’s implementation, which can be read/written from/to in page >1FFF. The current build (13) under construction is already reporting whether SAMS is found and if so how much (see post #1568 of the main fbForth development thread for a screen shot). The startup code starts at SAMS page >1FFF, shifting right one bit at a time (halving) until writable SAMS is found or page >001F (128 KiB high page) fails, at which point the SAMS flag stores the highest page # or 0. ...lee 2 1 Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted September 11, 2020 Share Posted September 11, 2020 13 hours ago, FALCOR4 said: Yes, you can read back the registers but only in 1M segments, the SAMS greater than 1M boards will not not read back anything beyond 1M segments; i.e. if you have a 4M or 8M or 16M SAMS it will not give you any granularity beyond 1M. Just a caution to those who are writing software. So, in other words, each register will continue to show precisely which page it's block is set to. Are you saying the LSByte will not be displayed at all? If so what would be the delineator between segments? 1 Quote Link to comment Share on other sites More sharing options...
GDMike Posted September 11, 2020 Share Posted September 11, 2020 Nagging judith only has one thing to say! "See, I told you harold, you never listen to me, I told you harold!! Next time you better listen Harold! You been reading that register since the day we met!!!" 2 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted September 11, 2020 Share Posted September 11, 2020 (edited) 22 hours ago, TheBF said: So that last SBZ 0 turns off the SAMS card. It MUST be done because other cards occupy that same space at >4000. (DISK, RS232 etc.) In my project I choose to leave it on because I'm not going to access any DSRs. But what happens if you leave it on and then enable the disk DSR, for instance. Will a read to >4000 read the SAMS register or the disk ROM? Edited September 11, 2020 by Asmusr typos 1 Quote Link to comment Share on other sites More sharing options...
+TheBF Posted September 11, 2020 Share Posted September 11, 2020 31 minutes ago, Asmusr said: In my project I choose to leave it on because I'm not going to access any DSRs. But what happens if you leave it on and then enable the disk DSR, for instance. Will a read to >4000 read the SAMS register or the disk ROM? I have never tried. Sounds like an experiment will follow. 1 Quote Link to comment Share on other sites More sharing options...
+TheBF Posted September 11, 2020 Share Posted September 11, 2020 52 minutes ago, TheBF said: I have never tried. Sounds like an experiment will follow. Doesn't matter in Camel99 Forth. R12 gets changed, the disk card is enabled and the DSR proceeds. While the DSR is running of course you can't control the SAMS card until it completes whatever it is doing. So if you need disk buffers in SAMS memory better page them in first. 1 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted September 11, 2020 Share Posted September 11, 2020 42 minutes ago, TheBF said: Doesn't matter in Camel99 Forth. R12 gets changed, the disk card is enabled and the DSR proceeds. While the DSR is running of course you can't control the SAMS card until it completes whatever it is doing. So if you need disk buffers in SAMS memory better page them in first. I think I should be safe in fbForth, with >MAP issuing ( SBZ 0 ) before it returns. ...lee 1 Quote Link to comment Share on other sites More sharing options...
+FALCOR4 Posted September 11, 2020 Share Posted September 11, 2020 5 hours ago, HOME AUTOMATION said: So, in other words, each register will continue to show precisely which page it's block is set to. Are you saying the LSByte will not be displayed at all? If so what would be the delineator between segments? Correct. The SAMS circuitry is simplistic, and I don't mean to say that is a bad thing. It's not, it just means that not all possible functionality is implemented which would require more ICs and board space. It will put the same page number (repeats) for a 1M segment in both the LSByte and the MSByte from the LS612 when you do a register read (>00 to >FF). The LSByte that is latched (which gives you banks beyond the first 1M) is not connected in such a way that it can be read back. So, you'll only be able to see page numbers for any one particular 1M bank, you won't be able to read back what bank you're in which would be in the LSByte if it were implemented. If needed, the software will just have to keep track of banks. I just put together another 4M board and am doing a burn in right now that should run through the night. When it's done, I'll play with it to verify that what I'm telling you is true or not. I'll report back with what I find. 1 Quote Link to comment Share on other sites More sharing options...
GDMike Posted September 11, 2020 Share Posted September 11, 2020 Just monitoring, and taking notes..hehe... Guess I'll have to order a whole new board soon.. Quote Link to comment Share on other sites More sharing options...
GDMike Posted September 11, 2020 Share Posted September 11, 2020 (edited) I powered off the peb and console this morning to take another run of the code I showed pictures of running yesterday, while it ran as expected yesterday, it would not repeat the process today since powering everything down. So I've gone through the code over and over today with only the ability to write to bank 16 over and over, no matter what number I placed in MSB of the word at >4006. I wasn't surprised that it ran yesterday as I plugged in the code while we discussed what was going on. But I never did shut down the peb during my tests, until Today and yup . That's what's going on. Btw, im not trying to read the Sam's registers as we discussed. But I am manually plugging in >10 and writing to that page, and that is fine, then writing completely different data to >11 and then going back and reading >10 and I get the data from my last write, page 17. As if page 16,17 are now duplicated with page 17s data. But I'm pretty sure that for some reason I'm not getting a higher bank of >3000. I've tried so many combinations in my three subs that for source code I'd just refer back to what we had yesterday. Btw, my code, test from yesterday, is running isolated as my test, so I'm sure I don't have any contaminated code interfereing, but I've been trying what we talked about yesterday, that worked yesterday and I'm not getting higher banks of >3000->3FFF. Darn lol I'll try again for sure, but I'd just thought I'd let you know in case there's something amiss. Edited September 12, 2020 by GDMike Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted September 12, 2020 Share Posted September 12, 2020 2 minutes ago, GDMike said: But I'm pretty sure that for some reason I'm not getting a higher bank of >3000. ???? Not sure what this means. Are you trying to page in SAMS bank >3000? Or, are you just saying you cannot page higher SAMS banks than >11 to the >3000 RAM window? ...lee 1 Quote Link to comment Share on other sites More sharing options...
GDMike Posted September 12, 2020 Share Posted September 12, 2020 (edited) Yeah, can't page higher Sam's banks than >11 Edited September 12, 2020 by GDMike Quote Link to comment Share on other sites More sharing options...
GDMike Posted September 12, 2020 Share Posted September 12, 2020 (edited) I've screwed up all my test source for the day, I'd have to rebuild it from scratch, because I tried so, haha, many varied changes, that it's spaghetti code rt now. When I tried just the "SAMON" code just on it's own, my card went power off. So that led me to start trying different facets of code.. Edited September 12, 2020 by GDMike Quote Link to comment Share on other sites More sharing options...
GDMike Posted September 12, 2020 Share Posted September 12, 2020 (edited) I'm not even sure if I don't have a card issue? I talked with Gary opa who is having issues with his Tripple tech card, but only after he moved his 1mb Sam's card to another port slot. So that's another idea, maybe I should try another slot?. I only have the original ti controller, tipi, and sam's. I have a couple of consoles, maybe try another also. Edited September 12, 2020 by GDMike Quote Link to comment Share on other sites More sharing options...
GDMike Posted September 12, 2020 Share Posted September 12, 2020 Tommorow I'll move the SAMs card port, I'll change consoles, and I'll rebuild test code. Then I'll update my findings. Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted September 12, 2020 Share Posted September 12, 2020 I just had an epiphany! What @FALCOR4 said earlier about reading SAMS registers and a discussion among [member-'RXB'], [member-'tursi'] and me over in the Classic99 Updates thread led me to the conclusion that my method in fbForth 2.0 of determining the amount of SAMS memory available is flawed! See post #1870 for my thinking. What occurred to me is that checking any, putative “highest” bank of an actual SAMS card will succeed, even for the lowest SAMS (128 KiB, highest page = >001F) expected, leading my code to conclude there is 32 MiB of SAMS available. FYI, my method writes a test value to the mapping window (>E000) and starts paging in “highest” pages of SAMS beginning with 32 MiB’s highest page, >1FFF, to see whether the test value is still there. If it fails, the code checks for SAMS at half that value until it succeeds or fails at 128 KiB, My point is that mapping >1FFF will always map a writable SAMS page for any working SAMS, 128 KiB or higher. If the card only has 128 KiB, mapping page >1FFF will actually map page >001F because the unattached bits are ignored. I will need to get more clever so that I am mapping only pages that I expect or use a clever pattern that will lead me to the correct conclusion in the shortest amount of code—aye, there’s the rub! ( sorry, Will ) ...lee 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.