Supernotes

[GDMike]

post #929 has been updated with the NEW file 03/21/22 7:25pm CST

Edited March 23, 2022 by GDMike

[GDMike]

Testing my import option..

It workies again.

I'm just trying to get all the bugs out before starting with the database option

[GDMike]

Well well well. Raspberry pi wouldn't boot today after I worked with it last night. I thought I lost my work but remember I sent a copy to my laptop, except for the docs. So only lost docs for SNP. 

Swhooooo..

Reimaged raspberry and I'm good again...

[GDMike]

A small issue on the IMPORT from Classic99. So I just fixed. If you want the new update...it's here

 

The problem was that IF by chance you were on the FIRST page and NEVER paged up or down prior to import from classic99 clipboard andand attempt from classic 99 clipboard import was selected then the program would BLACKEN the screen.

The import succeeded BUT a user may not know to page up to page 2 and back to page 1 again to see that it was successful and then the screen straightened out. But its ok now...

 

 

SNP

Edited March 23, 2022 by GDMike

[GDMike]

SNP Ver 2.0 is complete. Here it is. and the Help docs.

Ill be working on SNP 3.0 (Database  version)

to load the help, Start SNP (editor assembler option 3, DSK#.SNP  SNP FOR PROGRAM NAME

Once in SNP, press F5, command line. Enter LOAD DSK#.SNPDOCS

 

FIXED the DATE issue

SNPDOCS.rar

 

Edited April 20, 2022 by GDMike

[GDMike]

Now I've opened up the space of >6000->7FFF

For the database I've been wanting.

 

I did this because, SNP already has everything needed for the user to create a screen layout, like, where the fields can be placed and the labels for those Fields.

 

Another reason is because the way SNP does it's filing, by grabbing all of left over banks and saves it.

So basically I can leave my filing alone too.

 

The supercart space is what I needed for program space, around 8K, so surely I can squeeze it in, right?

Edited March 24, 2022 by GDMike

[GDMike]

Handy board

[GDMike]

I did find another error or 2 .. nothing major..

 

The window isn't large enough when you press F5 and call color because you can't see the message, do you want this to be global? Unless the screen is almost empty already, but not good if you have a full screen of data. 

I'll work on fixing that.

I also found an error that if you press ctrl q for date time display active.

Seems that once you turn off the time/date by toggle ctrl q again, the screen saver<SS> status message on the upper part of the screen doesn't get placement again.

I'll work on these. As my test computer has not been able to receive Internet, but once I tried it at home I saw it..

Edited March 24, 2022 by GDMike

[GDMike]

The call color prompt message window is corrected..

The ctrl Q enable/disable click and date is corrected by not wiping out the SS messages

Edited March 25, 2022 by GDMike

[GDMike]

Found a problem where if you first load the program then hit ctrl X to exit the program, and you answer N to exit, meaning you don't want to exit, The screen blanks to black,(unless you immediately press page up or down).

 

This has been fixed. 

 

 

[GDMike]

FYI - I'll be selling  supercarts when I finish building a few.

 

 

 

Edited March 26, 2022 by GDMike

[GDMike]

I've lost the screen blank out in SNP. 

I'm looking at the debugger in classic 99 and I see the address>83D6 suspends counting as soon as SNP boots. Other programs seem to continue counting at this address, per debugger.

Im not seeing anything that's writing to it so I'm stumped as to what's going on, but the screen never blanks out.

I do have a routine that counts cursor blinks that I can use to create my own blank out (screen saver with text that moves around the screen), if I want. 

I always thought that the only way that the screen blanker resets was by a key press OR changing a value at that address.

I also tried pushing a 02 to that address in hoping to force a count, but I'm thinking that's not the right approach, being that, according to the text below, a value at >83D4 is retrieved.

Additional information..

 

Blanking the screen

The ISR increments by two the word at >83D6. If it becomes zero, the ISR uses a copy of VDP register 1 stored in byte >83D4, sets the INT bit (>20) to ensure that further VDP interupts will be generated, clears the SCR bit (>40) and writes that byte to VDP register 1, which results in turning the screen off.

Note that the word at >83D6 is incremented by two, therefore if it contains an odd value it will never reach zero and the screen will never be blanked. Placing >0000 it that word ensures the longer delay before blanking the screen (it requires 32768 calls to the ISR, which takes about 9 minutes), whereas >FFFE turns the screen off at the next interrupt.

 

 

Edited March 26, 2022 by GDMike

[Willsy]

You have probably turned interrupts off in your code.

The standard technique is to have interrupts off most of the time (because the TI ISR may try to write to VDP "at the same time' as your code) and briefly enable them before disabling them again.

 

A good place to do this is in your keyboard scanning logic where you scan for a key and then work out what to do with that keypress (if any).

 

Just add :

 

LIMI 2

LIMI 0

 

into the loop, and that should fix it.

[HOME AUTOMATION]

That would also enable the QUIT routine.  A bit of a conflict of interests.

...Besides, it's fun to do it for yourself.

[GDMike]

1 hour ago, Willsy said:

You have probably turned interrupts off in your code.

The standard technique is to have interrupts off most of the time (because the TI ISR may try to write to VDP "at the same time' as your code) and briefly enable them before disabling them again.

 

A good place to do this is in your keyboard scanning logic where you scan for a key and then work out what to do with that keypress (if any).

 

Just add :

 

LIMI 2

LIMI 0

 

into the loop, and that should fix it.

At certain kscans I do indeed have limi 2, limi 0, but in areas I don't want a user to exit on accident, I don't. So I'm glad you cleared that up for me.

I'll just go ahead and make my own screen saver then, I'm already counting cursor blinks for my auto save routine and actually, I don't need the auto save doing a screen save for the user anyway, as that was a carry over from the SNE program, I'll remove that, but add a screen save. Note, that when a user fowards a screen Page or goes back a page, or does a GOTO, a screen Page is saved. So I won't miss the auto saver 

 

I couldn't figure out what the heck was happening with that screen blanker. Gees, ok, well I really need to attend a class on 9901 interrupts. I forgot when the next class was again??.....

 

Edited March 26, 2022 by GDMike

[+Lee Stewart]

1 hour ago, HOME AUTOMATION said:

That would also enable the QUIT routine.  A bit of a conflict of interests.

...Besides, it's fun to do it for yourself.

 

The QUIT routine can be disabled by ORing >1000 with >83C2 (ISR's R1). ORing >8000 at that location turns off QUIT as well as sprite motion and auto sound.

 

...lee

[GDMike]

3 minutes ago, Lee Stewart said:

 

The QUIT routine can be disabled by ORing >1000 with >83C2 (ISR's R1). ORing >8000 at that location turns off QUIT as well as sprite motion and auto sound.

 

...lee

That's fine. Good to know.

but looks like I'll just do some cleaning and come up with a screensaver in exchange of the deleted routines space.

[GDMike]

My screen saver routine now works again. Kicking in at 9:07 on my last few tests, but I'll test on real HW this next week.

I'm using my cursor counter routine since I can't find the limi 2 anywhere that maybe stopping my actual screen blanker. I've looked Everywhere , all my kscans are always followed by limi 2, limi 0 now.

This is after making those changes that didn't include limi 0 on a couple of kscans, but not anymore.

But even with making sure limi 2 limi 0 throughout the program after each kscan, the normal blanker still didn't work for me.

So, I just used the code that I had.

I've had to tell a few routines to clear my counter on any key press. And that's a simple thing.

 

9:07 again, on my 5th independent test.

 

 

 

Edited March 27, 2022 by GDMike

[HOME AUTOMATION]

"My screen saver routine now works again..." vs. "...stopping my actual screen blanker."(My vs. actual) ...Are these not actually one-and-the-same?

 

2 hours ago, GDMike said:

I can't find the limi 2 anywhere that maybe stopping my actual screen blanker.

 

LIMI 2, allows interrupts to occur.
LIMI 0, prohibits interrupts.

 

Thus, it is actually a LIMI 0, that would prevent said counter from running freely.

Edited March 27, 2022 by HOME AUTOMATION

[GDMike]

Oh....I was backwards again. I bet if I reversed all of them, then it might work.., 

So, they should read

BLWP@KSCAN

Limi 0

Limi 2

Edited March 27, 2022 by GDMike

[HOME AUTOMATION]

Perhaps!

[Willsy]

No! That would leave interrupts on, which is not what you want. It can lead to unpredictable results/effects that are very hard to track down.

 

Recall that (for example) reading from VDP requires two distinct operations:

 

* Set the VDP read address

* Read from the VDP read register

 

Now, imagine VDP interrupts are enabled. Your code loads the VDP read register, and then, just before you perform a read from the VDP read register, an interrupt occurs. Some code in the console interrupt service routine decides to read something from VDP. It loads the VDP read register and performs it's read. Then returns to your code. You now perform your VDP read, but the VDP read address was changed by the console ISR and you get garbage back! 

 

These subtle bugs are a nightmare to find, so we avoid them by closely controlling when interrupts can happen. 

[+TheBF]

1 hour ago, Willsy said:

No! That would leave interrupts on, which is not what you want. It can lead to unpredictable results/effects that are very hard to track down.

 

Recall that (for example) reading from VDP requires two distinct operations:

 

* Set the VDP read address

* Read from the VDP read register

 

Now, imagine VDP interrupts are enabled. Your code loads the VDP read register, and then, just before you perform a read from the VDP read register, an interrupt occurs. Some code in the console interrupt service routine decides to read something from VDP. It loads the VDP read register and performs it's read. Then returns to your code. You now perform your VDP read, but the VDP read address was changed by the console ISR and you get garbage back! 

 

These subtle bugs are a nightmare to find, so we avoid them by closely controlling when interrupts can happen. 

I will never stop being amazed at the concept of "polled" interrupts.     What a weird machine we have.

When you think about the different interrupt levels that the hardware provides it's a bit sad. 

 

My solution to the VDP & interrupts was to use a common sub-routine for setting the VDP address that always masks interrupts and all the VDP routines enable interrupts when they exit.

It was a sh*t show until I learned about this.  

[+Lee Stewart]

4 hours ago, GDMike said:

My screen saver routine now works again. Kicking in at 9:07 on my last few tests, but I'll test on real HW this next week.

I'm using my cursor counter routine since I can't find the limi 2 anywhere that maybe stopping my actual screen blanker. I've looked Everywhere , all my kscans are always followed by limi 2, limi 0 now.

This is after making those changes that didn't include limi 0 on a couple of kscans, but not anymore.

But even with making sure limi 2 limi 0 throughout the program after each kscan, the normal blanker still didn't work for me.

So, I just used the code that I had.

I've had to tell a few routines to clear my counter on any key press. And that's a simple thing.

 

9:07 again, on my 5th independent test.

 

The screen timeout timer reset has little to do with interrupts. I say, “little”, because it is the console ISR that increments the timer, which is effectively reset when it rolls over to 0. It does not ever, however, explicitly reset the timer.

 

In non-Basic environments, the screen timeout timer is explicitly reset only by KSCAN. Every call to KSCAN that detects a key-press resets the timer. The only key-press that does not require KSCAN is <quit>, which is the only key checked for by the console ISR. This is done without explicitly resetting the timer. It does, of course, execute a console reset.

 

...lee

 

 

[+mizapf]

In earlier times I wondered how this LIMI 2; LIMI 0 was supposed to work at all, because the window of enabled interrupts seems too small - only a few microseconds.

 

Later I learned that in our machine, we have level-triggered interrupts; that is, not the edge but the (persisting) level is relevant for the interrupt. Second, the video processor has an outgoing INT line which stays active until you read its VDP status register.

 

Thus, the theory behind this is: The VDP raises the interrupt line, and keeps it active; the LIMI 0 masks away this event until there is a LIMI 2, in which case the still active INT line finally gets through. The interrupt handler in the console then masks the interrupts again and (important!) reads the VDP status register, so releasing the interrupt.