Supernotes

[GDMike]

Very good. Thanks. I'll try Everything this afternoon.

 

[GDMike]

I was hoping, but I got the same results from yesterday.

But since you found that error on my part, I'll go back into my code and look around for any odd Stuff, I should have already done that... sorry

[GDMike]

Well Lee, I went through the code again and I didn't see any MORE typos.

I'll try the order of things, like turning the card on first, turning on later, etc...in other words, I'll fiddle.

[+Lee Stewart]

4 hours ago, GDMike said:

I was hoping, but I got the same results from yesterday.

But since you found that error on my part, I'll go back into my code and look around for any odd Stuff, I should have already done that... sorry

2 hours ago, GDMike said:

Well Lee, I went through the code again and I didn't see any MORE typos.

I'll try the order of things, like turning the card on first, turning on later, etc...in other words, I'll fiddle.

 

Well, what your results tell me is that, at least, one of the following is happening:

1. SAMS? has the wrong value. When you type SAMS? , what value do you get? It should be FF₁₆ or 255₁₀.
2. SAMS is not working while you are doing all of this.

It works fine for me on Classic99 (of course, SAMS? is 1FFF₁₆ for Classic99). If I put SAMS-OFF in place of SAMS-ON in the code above, I get the results you got. Unfortunately, I do not yet have a SAMS card to check it on the real iron.

 

...lee

[+Lee Stewart]

There is one other thing you can try and that is to see what CRU bit is really being set in SAMS-ON by running the following code after you have the SAMS words loaded:

HEX ' SAMS-ON 2+ @ U.

If the value printed is not F01, SAMS-ON is still set wrong.

 

...lee

[GDMike]

1 hour ago, Lee Stewart said:

SAMS? , what value do you get? It should be FF₁₆ or 255₁₀.

Correct, it is 255 (FF) as it's created with the Constant word. Tested correctly >FF

----

I received >F01 on that SAMS-ON test

Edited October 12, 2020 by GDMike

[GDMike]

Lee, btw. I did cold starts on these tests, not just reboot

 

Also, TF runs ok and SAMs works fine.

I'm not sure if I have an FB in my flash ROM.. I don't have a finalgrom anymore.

Edited October 12, 2020 by GDMike

[+Lee Stewart]

TurboForth initializes SAMS differently from the SAMS power-up default. I don’t know whether that would interfere, but I will try to get my SAMS initializing code done soon. The only problem with running it in fbForth 1.0 is it could send it off into the weeds unless it is run from scratchpad RAM because there is the potential of swapping out banks with running code in them. That is an advantage of a cartridge.

 

The only other thing I can think of is examining a dump of the relevant SAMS words. 

 

...lee

[GDMike]

I have another idea.

You say this works on classic99, so ill paste this into CL99 and try it.

Will be tommorow, though.

Thx

[+Lee Stewart]

I am grasping at straws here, but, the SAMS initializing routines of TurboForth and fbForth 2.0 turn on bit 0 (also enables the mapper registers) before turning on bit 1 (mapping/transparent modes) and then exit after turning off bit 0, leaving mapping permanently enabled. So. on the chance that the card actually needs to be “turned on” before any attempts to change other bits on the board will be effective, you might try the following definition for SAMS-ON :

HEX
: SAMS-ON   ( -- )
   0F00 SBO       ( turn on SAMS card..also enables mapper registers)
   0F01 SBO       ( enable SAMS mapping )
   0F00 SBZ       ( turn off SAMS card..also disables mapper registers)
;

 

...lee

[GDMike]

Just waking up here, as I haven't had time to try this previous code in CL99.

-------

Also, off topic plug, I'll be helping victor with writing a PC program to read bytes in the headers if .BIN files to disguish if it's a finalgrom file or not. If so, he wants a more descriptive view and organization of files for his library, something like color coding the differences.

Because the names alone aren't descriptive enough.

------

I'll try the new definition you provided soon. Thx for helping me.

Edited October 12, 2020 by GDMike

[GDMike]

No sir, no change in the results.

I even went back to the original SAMS-ON word and tried everything after going through the init, (new SAMS-ON).

I'll now see if the code works on cl99

[GDMike]

Hmm. I got the same results,(giving me the same value no matter what bank I stored the number in), on cl99 with the original sams-on code. 

 

[+Lee Stewart]

4 minutes ago, GDMike said:

Hmm. I got the same results,(giving me the same value no matter what bank I stored the number in), on cl99 with the original sams-on code. 

 

Clearly, we are not running the same code. I will see what I can discover from the FBLOCKS file you sent me earlier.

 

...lee

[GDMike]

1 minute ago, Lee Stewart said:

 

Clearly, we are not running the same code. I will see what I can discover from the FBLOCKS file you sent me earlier.

 

...le

Hold on..I see my change didn't take affect on my reverting sams-on..

Working on it

[GDMike]

Lee, this is going to take awhile.

It looks like it works in the laptop, CL99 when I used hex D000 d0&tib!

But I'm not sure because twice cl99 rebooted because I keep hitting the wrong tiny key on the keyboard.my fault.

I'll update in a while... but I've got to slave in another keyboard to my laptop, this is why things are so cumbersome here I have a small desk I don't have a bigger desk and I got everything on one desk I got the tip I got a towered t i p e b as well with a monitor on top of that and then I got the laptop below that and the ti keyboard below all that. Lol

This is why I hate using the laptop.

And then of course I use my phone right here cuz it's off my desk.

Anyway it's going to take some time

Edited October 12, 2020 by GDMike

[GDMike]

Ok Lee, verified on the laptop, cl99.

It does work after I reverted my sams-on code.

So it's definitely real iron issue here as the blocks I'm working on are mapped to those on tipi im using on real steel.

Edited October 12, 2020 by GDMike

[GDMike]

Now when I try it on real ti, when I call Sams-on, the machine locks up..

Investigating...

Edited October 12, 2020 by GDMike

[GDMike]

As soon as I do:

Hex E000 S0&TIB! 

And then Sams-on 

Machine locks up

Using original, just tested on cl99 blocks file, Sams-on)

Lunch break ?

Before going to lunch, I ran the blocks file on cl99 again and it worked.

So yeah using original sams-on works only on cl99, that's where we stand.

 

 

Edited October 12, 2020 by GDMike

[GDMike]

2 hours ago, Lee Stewart said:

 

Lee, I just went ahead and confirmed again, that running Sams-on on my console does in fact lock me up.

I actually wanted to make sure anyway. So yes, this is definitely the original SAMS-ON code. Btw I did try the modified Sams-on that you said to try last. and on the original machine it turned off all peb lights.

That's what led me to reverting and trying on cl99.

Edited October 12, 2020 by GDMike

[GDMike]

Should I try another console? Hmmm..

Naaa.  It works on my Turboforth..

But I know it doesn't work on my assembly program that I was trying to make work last month, btw, which is the reason I moved to FB 1.0

I guess I'll go back to my assembly program again and figure out what is going on with Sam's.

 

 

Edited October 12, 2020 by GDMike

[+Lee Stewart]

One thing I can tell you about TurboForth is that it starts up by unconditionally

• Turning SAMS mapper registers (and card) on (bit 0)
• Then mapping off (bit 1) so bank mappings will not take effect yet
• Remapping banks to expansion memory so that the top 8 SAMS pages (>F8, >F9, >FA – >FF) of a presumed 1 MiB SAMS are mapped to >2000,>3000, >A000 – >F000, respectively
• Turning mapping on (bit 1) so that the remappings take effect all at once
• Turning mapper registers (and card) off

From that point on mapping is never turned off. I do not know enough about the SAMS card to know under what conditions SAMS might retain its settings. I wonder whether the TurboForth settings might be getting in the way.

 

The problem with starting up fbForth 1.0 and then initializing SAMS is the risk of mapping all or part of the Forth system right out of the expansion RAM where it was running and thus locking things up. This is not a problem when doing all of this from cartridge space before copying parts of the system to expansion RAM, but I must proceed carefully when attempting to do this from expansion RAM. 

 

...lee

[HOME AUTOMATION]

Forth would make a good language to pass secret-notes by me.

 

Come-back to ASSY, because...

 

 

...There's noplace  like home.

[GDMike]

I should of explained that better. When I say it works in turbof, I mean as a past tense. It's not like I'm running turbo forth in the middle of doing all this stuff. That would really complicate things.

It's just a mere statement, that turbo Forth sees my Sam's card. That's what I really meant.

Other than that I do cold reboots while playing with this card cuz I know this card likes to save settings. So I always make sure I reboot the card by powering It off and waiting a bit.

 

Edited October 12, 2020 by GDMike

[GDMike]

6 minutes ago, HOME AUTOMATION said:

Forth would make a good language to pass secret-notes by me.

 

Come-back to ASSY, because...

 

 

...There's noplace  like home.

Uncle em' is that you. 

Well I love Forth, I love it a lot. But I seem to get further along with assembly but these days,  because my Sam's isn't working in my program in assembly I'm looking for options that I can still access the supercart with AND Sam's. 

Edited October 12, 2020 by GDMike