Denial

Hi, great work as ever Victragic!

I've noticed then you cannot switch case but there is a small screen glitch if you try CBM+Shift, this POKE could be useful.
*0291 657 Shift mode switch (0 = enabled, 128 = locked)

nbla000 wrote: ↑Wed Feb 17, 2021 2:54 pm Hi, great work as ever Victragic!

I've noticed then you cannot switch case but there is a small screen glitch if you try CBM+Shift, this POKE could be useful.

Code: Select all

;Disable switching case using CBM+Shift
	LDA #$80          ; (#0 Enabled, #128 Disabled)
	STA $0291         ; lock CBM+shift key

*0291 657 Shift mode switch (0 = enabled, 128 = locked)

Thanks Nbla,

That's a good idea - will update tonight when I get the chance.

Mike wrote: ↑Wed Feb 17, 2021 12:44 pm

tokra wrote:Any idea what might cause this?

I can reproduce this error also on my setup. That seems to be a race condition, where the screen update is 'caught' during a scroll and when the new line has been opened but not yet been written fully.

The algorithm takes the original screen data of the editor and compares it with a shadow copy; where the shadow copy differs, the character position in the graphics bitmap is updated and the shadow copy also assumes the new value.

The original screen data is still 'there' and can be recovered (i.e. made visible again) by hovering over the blank positions with the cursor.

I'll roll it back tonight and have a look. I had thought this was fixed, as my 'faster scroll' included new steps to
1. pause the screen polling (through the IRQ)
2. Force 'write' the bottom two lines of the screen
3. Shift the bitmap up by however many rows it needs to scroll, and copy the screen to the shadow.
4 recommence polling

I had tested it with listing programs and directories without issues.. quite possible I've uploaded an incorrect version.

Edit.. I only tested it on NTSC.. surely it's not a timing difference between Pal and NTSC..?

Victragic wrote: ↑Wed Feb 17, 2021 3:38 pm Edit.. I only tested it on NTSC.. surely it's not a timing difference between Pal and NTSC..?

Can only reproduce it on PAL. But I can always reproduce it on PAL if I list the directory while on the 10th line of the display from top. Maybe that helps.

Thanks - it does help. Will fix later, cheers.

Updated, extending the 'reach' of the redraw before scroll appears to have rectified the problem. Also have disabled Shift/Commodore combination rather than continually forcing the value back in $9005. If a user really wants to change the display, who am I to stop them

I promise I'll stop bumping my own thread, however have added a few items to the disk.

Speedscript 3.2. I'm sure no-one in their right mind would use a Vic for word-processing in 2021, however I couldn't resist seeing what Compute!'s killer app would look like in 32 columns. The conversion was fairly easy, apart from one problem, which seems to be around a call to $DDCD to produce listing style output. I suspect this is why the Directory function doesn't work. I also have no idea whether it would work with a printer -- however again this is probably a moot point in 2021.

Alternate fonts, which I created with a very roughly constructed font editor (which I also include). When saving a font, it will add the '@0:' for replace at the start of the filename, so you don't need to include this. Be very careful when copying a range of characters, as there is no error checking. (I have only used this to copy an 'inverse range' of characters from 0-127, to character 128, in order to auto-generate the inverse characters).
Load a font in with ',8,1' and it will load to $AC00. You will notice it will not replace the text already on the screen. Also, you'll need to reset memory pointers after the load ('NEW' is easiest way) or you'll get 'out of memory' errors.

I intend to add some basic programs, most likely adventures from either TRS-80 or VZ-200/300, if I can find some that are actually worthy of typing in! I will continue to add to the disk over time.

Victragic wrote:When saving a font, it will add the '@0:' for replace at the start of the filename, so you don't need to include this.

You know the implementation of 'save-and-replace' is bugged on many CBM disk drives and can corrupt the disk's contents?

That is not something you want to include in a program, an editor in particular. You rather use the Scratch command of CBM DOS so an existing file with the same name is deleted beforehand, and then do the actual save (without prepending '@0:').

More details found here: Reason of Save-and-Replace bug? [...].

Speedscript 3.2. I'm sure no-one in their right mind would use a Vic for word-processing in 2021, however I couldn't resist seeing what Compute!'s killer app would look like in 32 columns.

Wow, I do use Speedscript from time to time - also managed to find a copy of the original manual published by Compute! back then.

Will test it in all its 32 column glory ASAP.

Thank for this

orion70 wrote: ↑Sun Mar 07, 2021 10:17 am Wow, I do use Speedscript from time to time - also managed to find a copy of the original manual published by Compute! back then.

Will test it in all its 32 column glory ASAP.

Thank for this

OK, some people in their right mind might use it! I found various articles for Speedscript, was there a definitive manual for it? Would be useful to test it completely.

Mike wrote: ↑Sun Mar 07, 2021 3:42 am

Victragic wrote:When saving a font, it will add the '@0:' for replace at the start of the filename, so you don't need to include this.

You know the implementation of 'save-and-replace' is bugged on many CBM disk drives and can corrupt the disk's contents?

That is not something you want to include in a program, an editor in particular. You rather use the Scratch command of CBM DOS so an existing file with the same name is deleted beforehand, and then do the actual save (without prepending '@0:').

More details found here: Reason of Save-and-Replace bug? [...].

I was aware there was a bug, however like many others I had never personally encountered it and mistakenly believed that by adding the 0: the problem was fixed.
Will fix this - I think I will add some proper error trapping to the editor as well, to make it a little more robust.

Here we are: https://archive.org/details/Computes_Speedscript

orion70 wrote: ↑Sun Mar 07, 2021 11:38 pm Here we are: https://archive.org/details/Computes_Speedscript

Many thanks. Face-palm moment as I now realise the source code was available the whole time

Hey, Speedscript in 32 columns works like a charm.. very usable and readable, well-balanced characters

..and in original CRT glory too..!