WIP: FAST-40

Basic and Machine Language

Moderator: Moderators

FD22
Vic 20 Hobbyist
Posts: 148
Joined: Mon Feb 15, 2010 12:31 pm

Re: WIP: FAST-40

Post by FD22 »

Um, nope. The mechanics of scrolling happen against the text buffer, not the bitmap. I guess I'm not explaining this properly, but then again I have the whole thing in my head and can see how it all hangs together very clearly. ;)

Example: the screen scrolls by one line - the text buffer is updated, including the work necessary to move all lines up one row and clear or populate the last line with new data. This has no effect on the renderer until the very last moment, when all the dirty row bits are set. A 5th of a second later, the entire screen has been refreshed, reflecting the scroll.

Example: the screen scrolls by several lines - the text buffer is updated for the first line scroll, and all dirty bits set so the renderer starts to refresh lines (3 in PAL if running at top speed). That IRQ finishes, and the text buffer is then hit again by the user-level app (which might be LIST if in direct mode) and further changes are made, another scroll event occurs, and all the dirty row bits set again. However, the renderer remembers where it got to last time, so the redraw continues from where it stopped on the previous frame. It refreshes a complete line at a time, working bottom-to-top, but keeping a pointer to which dirty row bit to check next and not restarting from the bottom until all bits have been tested. During 'long' scroll operations there may be transient periods where a line moves far enough up the screen to appear twice in one complete render cycle, but this would be fixed no later than a 5th of a second later when the next cycle catches-up with the new state of the text buffer. If scrolling is paused or stops, the entire screen will be redrawn within 200ms which is probably quick enough not to be noticable, or if it is then not to be too irritating. And it's much, much faster than the other 40-column products, which is kinda the whole point. ;)
User avatar
Mike
Herr VC
Posts: 4816
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Re: WIP: FAST-40

Post by Mike »

FD22 wrote:Um, nope. The mechanics of scrolling happen against the text buffer, not the bitmap. I guess I'm not explaining this properly, [...]
Rest assured, I actually got it already as I wrote my previous posting.
[...] but then again I have the whole thing in my head and can see how it all hangs together very clearly.
I'll refer to that at the end of this posting.
Example: [...]
Nothing more than a round-robin scheduling on which dirty lines to render next, up to a given maximum number of lines per interrupt. As short as that.
During 'long' scroll operations there may be transient periods where a line moves far enough up the screen to appear twice in one complete render cycle, but this would be fixed no later than a 5th of a second later when the next cycle catches-up with the new state of the text buffer. If scrolling is paused or stops, the entire screen will be redrawn within 200ms which is probably quick enough not to be noticable, or if it is then not to be too irritating. And it's much, much faster than the other 40-column products, which is kinda the whole point. ;)
So, you finally came to the same conclusions as I did what is going to happen, just you still think the resulting screen tear won't irritate or annoy the user. Obviously we don't share the same judgement here.

Mark,

within this thread you already got *more* feedback for a WIP from others and me, than what I most often get for my projects. The postings by tokra and me pointed out some implementation issues, and probable pitfalls which should be avoided. You seem to have difficulties to step back a bit and view your projects in the light of these criticisms.

Anyhow, it's up to you: release something that works, and then it is always possible to talk about the result in an objective manner. Talking about something which is "in [your] head and [you] can see how it all hangs together very clearly", is - well - cheap.

Michael
User avatar
tokra
Vic 20 Scientist
Posts: 1120
Joined: Tue Apr 27, 2010 5:32 pm
Location: Scheessel, Germany

Re: WIP: FAST-40

Post by tokra »

Let's see how the alpha will actually look. I realize from my own experience that sometimes when programming you are absolutely sure one thing will work in a certain way you thought long and hard about and you will actually need to see it fail to convince yourself otherwise. In any case it will be interesting to see how bad/noticeable or not the tearing will actually be.
the entire screen will be redrawn within 200ms which is probably quick enough not to be noticable
1/5th of second is a lot longer than you think. In that I must agree with Mike. But maybe we are wrong :)

I saw some of the other 40-column-programs "cheating" by only scrolling at 4 or 5 line-blocks. If there is a way to get fast and smooth scrolling without that cheat, this will be the opportunity to find it. I am sure that by releasing the source there will be optimizations possible, just like with Kweepa's Doom that got some speed-up tips from forum-members.
User avatar
darkatx
Vic 20 Afficionado
Posts: 470
Joined: Wed Feb 04, 2009 2:17 pm
Location: Canada

Re: WIP: FAST-40

Post by darkatx »

A fifth of a second would be noticeable but to the point of irritation?

That issue is truly subjective.

So typing more than 5 characters a second (holding down a key?) and long scrolls and possibly a series of successive screen clears would become an issue more along the lines of aesthetics over function - correct?

For me, I much prefer function and probably wouldn't mind all the tearing but I can't speak for others. I honestly, think that's the real issue.

Hey, if any optimizations can be given (from other forum members) then yeah why not take it?

- 'ain't too proud to beg' ;)

Still, this is a pretty cool attempt and by all means should be encouraged. Love to see its further development. :)
Learning all the time... :)
FD22
Vic 20 Hobbyist
Posts: 148
Joined: Mon Feb 15, 2010 12:31 pm

Re: WIP: FAST-40

Post by FD22 »

I'm appreciative of all feedback, good or bad. I encourage discussion, and enjoy the cut and thrust of debate. I don't like being called cheap.

I'm going to let the product speak for itself, which is what I do in my day job - the blog is where I post updates, but when I hit Alpha I'll drop a link in here.

One minor clarification to your comment, darkatx, about typing rate delay - that 5th of a second delay is the maximum time you would have to wait for the row you're typing on to be refreshed if the renderer had to redraw everything else on the screen before it got back to your line again. However, if the line you're typing on is the only line changing (as would be the common case) the refresh delay is 1/50th or 1/60th of a second (PAL/NTSC), the same as the 22-character KERNAL screen editor.
User avatar
tokra
Vic 20 Scientist
Posts: 1120
Joined: Tue Apr 27, 2010 5:32 pm
Location: Scheessel, Germany

Re: WIP: FAST-40

Post by tokra »

I agree that in normal use the delay will probably not be visible. Possibly only when listing a long program.

Should it be possible to find an even "better" drawing routine once the product is out there it would - as always - have to be weighed if it was "worth" it. Gladly this is not a product that has to be released commercially on a fixed date, but can improve over time, like good open source software should.

An idea that just popped into my head for a later release maybe: Support for inverse mode. To illustrate just tpye POKE36879,230 into your VIC. You should now have light-blue letters with each cell having a blue background. The rest of the screen will be white, which is due to the VIC setting all color-RAM to white if you clear the screen. With FAST-40 you could always set the color-RAM to the actual text-color (like the C64 does in later models). This way you could have light-blue on blue 40-column text nicely emulating a stock C64. Maybe redirect POKEs from 1024-2023 to your text-buffer in this mode as well. Sadly, you can only have one color for the text-color in this mode, but still.

Another idea which has really not that much to do with FAST-40: Different screen-sizes using the stock VIC-20 chars. On PAL you could set up a screen of up to 28x35 chars = 980 chars which would work with the existing color- and video-RAM. Just the KERNAL is fixed to 22 char-width. But the same logic you use in FAST-40 for supporting your own 40-column-mode could possibly be applied to a standard-text-mode screen. Being able to choose the screen-dimensions maybe freely even and then go to BASIC with that screen-mode would be a nice feat.
User avatar
darkatx
Vic 20 Afficionado
Posts: 470
Joined: Wed Feb 04, 2009 2:17 pm
Location: Canada

Re: WIP: FAST-40

Post by darkatx »

OK, I was wondering about that because after reading the blog I thought that normal type was keeping up with the screen refresh. So full screen updates would be expensive yeah. :wink:

If its only the scrolling then that's not a big deal at all...still would love to see its progress all the same. It's a ambitious attempt to do better than the others that came before it.
Learning all the time... :)
groepaz
Vic 20 Scientist
Posts: 1180
Joined: Wed Aug 25, 2010 5:30 pm

Re: WIP: FAST-40

Post by groepaz »

Just the KERNAL is fixed to 22 char-width.
iirc you can set up the screen editor/kernal for other sizes... the soft80 programs for c64 used to do this as well.
I'm just a Software Guy who has no Idea how the Hardware works. Don't listen to me.
User avatar
tokra
Vic 20 Scientist
Posts: 1120
Joined: Tue Apr 27, 2010 5:32 pm
Location: Scheessel, Germany

Re: WIP: FAST-40

Post by tokra »

groepaz wrote:
Just the KERNAL is fixed to 22 char-width.
iirc you can set up the screen editor/kernal for other sizes... the soft80 programs for c64 used to do this as well.
I didn't go into much detail researching this, but I found the 22 hardcoded into the screen editor/kernal. As you cannot copy the kernal to RAM on the VIC-20, you would have to reproduce the screen editor in your program. Or maybe I'm missing something...
FD22
Vic 20 Hobbyist
Posts: 148
Joined: Mon Feb 15, 2010 12:31 pm

Re: WIP: FAST-40

Post by FD22 »

tokra wrote:
groepaz wrote:
Just the KERNAL is fixed to 22 char-width.
iirc you can set up the screen editor/kernal for other sizes... the soft80 programs for c64 used to do this as well.
I didn't go into much detail researching this, but I found the 22 hardcoded into the screen editor/kernal. As you cannot copy the kernal to RAM on the VIC-20, you would have to reproduce the screen editor in your program. Or maybe I'm missing something...
No, you're dead right - that's why I've had to re-write _CHRIN and _CHROUT for FAST-40, because they both have hard-coded references to 22 columns. You don't have to replicate the entire screen editor code, but these two key functions do need to have their vectors adjusted to point to custom code that knows about different screen widths.
groepaz
Vic 20 Scientist
Posts: 1180
Joined: Wed Aug 25, 2010 5:30 pm

Re: WIP: FAST-40

Post by groepaz »

really? interesting... seems odd that they hardcoded it in the vic20, and didnt in the c64 (the other way around would have made a lot more sense afterall)
I'm just a Software Guy who has no Idea how the Hardware works. Don't listen to me.
pallas
Vic 20 Devotee
Posts: 212
Joined: Mon Dec 24, 2012 2:38 am

Re: WIP: FAST-40

Post by pallas »

maybe the problem is that "you cannot copy the kernal to RAM on the VIC-20"
groepaz
Vic 20 Scientist
Posts: 1180
Joined: Wed Aug 25, 2010 5:30 pm

Re: WIP: FAST-40

Post by groepaz »

mmmmh somehow i remembered this stuff being flexible enough to work with variables for screen size in lower memory... just checked kernal again, and it doesnt actually do that at all. so disregard, just a brainfart =P
I'm just a Software Guy who has no Idea how the Hardware works. Don't listen to me.
Post Reply