Re: [M100] hardware scrolling patch

[Stephen Adolph]

Created a page to host information on the patches used-

M100/T102 Hardware scrolling patch - Bitchin100 DocGarden


On Thu, Mar 10, 2022 at 11:31 PM Stephen Adolph 
wrote:

> Follow up on this-
> I found that my hardware scroll patch conflicts with TS-DOS!  TS-DOS uses
> HahasiH too, so I will need to move to a non conflicting hidey-hole.
> I don't think I wrote this up at Bitchin100 - I will do so, and post the
> fixed code.
>
> I am working on rolling this patch out on my M100s along with 5MHz upgrade
> too.
>
> Steve
>
> On Fri, Feb 25, 2022 at 6:23 PM Stephen Adolph 
> wrote:
>
>> So, I burned a ROM and tried it in my T102 (which is socketed).
>> Interesting results.
>> It works.
>> But, visually it is a bit off.  Due to the hardware scrolling, you get
>> wrap around of lines the moment you program the drivers to scroll.
>> Expected.
>> However, sometimes that means you get a flash of characters where there
>> should be none.
>> This is a bit annoying.
>>
>> So, I think I need to redo the patch to remove this artifact.
>> It wasn't the "same" on VT for some reason.
>>
>> Regardless, I'll work on an improved version.
>>
>>
>>

Re: [M100] hardware scrolling patch

[Stephen Adolph]

Follow up on this-
I found that my hardware scroll patch conflicts with TS-DOS!  TS-DOS uses
HahasiH too, so I will need to move to a non conflicting hidey-hole.
I don't think I wrote this up at Bitchin100 - I will do so, and post the
fixed code.

I am working on rolling this patch out on my M100s along with 5MHz upgrade
too.

Steve

On Fri, Feb 25, 2022 at 6:23 PM Stephen Adolph  wrote:

> So, I burned a ROM and tried it in my T102 (which is socketed).
> Interesting results.
> It works.
> But, visually it is a bit off.  Due to the hardware scrolling, you get
> wrap around of lines the moment you program the drivers to scroll.
> Expected.
> However, sometimes that means you get a flash of characters where there
> should be none.
> This is a bit annoying.
>
> So, I think I need to redo the patch to remove this artifact.
> It wasn't the "same" on VT for some reason.
>
> Regardless, I'll work on an improved version.
>
>
>

Re: [M100] hardware scrolling patch

[Philip Avery]

Good work Steve, and reducing it to 65 bytes - cool bananas.

I agree, M100 CP/M uses rst 4 to output text so this should work fine 
with the Page Register in hi RAM zeroed out.


Philip

On 24/02/2022 5:29 pm, Stephen Adolph wrote:

Hi Tom,

I was thinking about that.  It may well work with CP/m or if not 
exactly this patch then maybe a minor variant.  The m100 main rom 
provides all of these routines for cp/m.


Cp/m always powers up as an M100 but the upper ram image would need to 
have the one location that stores page state to be zeroed out.


That upper ram image is bundled into the cpm image that is loaded from 
disk.  So i think what is needed is to just poke a 0 into that spot in 
the file on disk, or run a little utility on start of cp/m.


Steve


On Wednesday, February 23, 2022, Tom Hoppe  wrote:

Could this work with CP/M?

On Wed, Feb 23, 2022 at 7:48 AM Joshua O'Keefe
 wrote:

> On Feb 23, 2022, at 7:17 AM, Stephen Adolph
 wrote:
> I did a write up on the two patches that are needed.

Steve, I remember seeing you mention this a while back and I'm
glad you were able to get back to it.  Your write-up was
clear, informative and interesting.  Thanks for sharing it.

I wonder why this controller feature was never exploited.  Was
there perhaps a similar, earlier part lacking the feature that
was swapped out late in the design cycle?  Simple time
constraints like every engineer in history has faced?  I can
imagine all kinds of scenarios and it's a shame we'll never
know the real story of why the ROM is the way it is.

Re: [M100] hardware scrolling patch

[Mike Stein]

Wow! How'd ya do it?

m

On Thu, Feb 24, 2022 at 12:52 AM Stephen Adolph 
wrote:

> ...and found some more savings.  *now down to 85 bytes*!  Leaving 65
> bytes for more patch fun.
>
>
> On Wed, Feb 23, 2022 at 1:24 PM Stephen Adolph 
> wrote:
>
>> In T200, the video subsystem was really reworked to take advantage of
>> hardware scrolling.
>> From a quick scan, it seems like the basic operation is the same for M100
>> and T200 (upper and lower portions of the LCD), so the same "organization"
>> should be applicable to the M100.
>>
>> Could T200 video subsystem be back ported to M100?  Perhaps a much deeper
>> dive into the code could make the M100 truly work as well as the T200 from
>> this perspective, but I would worry that the end result would be so
>> substantially different that software compatibility may become an issue.
>>
>> I guess they got away with software scroll on M100, but T200 would have
>> been completely unacceptable with such a slow scroll across 16 lines rather
>> than 8.
>>
>> Anyhow, I have streamlined the patch now to only 95 bytes, leaving 55
>> bytes for more stuff.  I may try to augment what is there with coverage for
>> some of the additional scroll corner cases.
>>
>> Steve
>>
>> On Wed, Feb 23, 2022 at 10:48 AM Joshua O'Keefe 
>> wrote:
>>
>>> > On Feb 23, 2022, at 7:17 AM, Stephen Adolph 
>>> wrote:
>>> > I did a write up on the two patches that are needed.
>>>
>>> Steve, I remember seeing you mention this a while back and I'm glad you
>>> were able to get back to it.  Your write-up was clear, informative and
>>> interesting.  Thanks for sharing it.
>>>
>>> I wonder why this controller feature was never exploited.  Was there
>>> perhaps a similar, earlier part lacking the feature that was swapped out
>>> late in the design cycle?  Simple time constraints like every engineer in
>>> history has faced?  I can imagine all kinds of scenarios and it's a shame
>>> we'll never know the real story of why the ROM is the way it is.
>>
>>

Re: [M100] hardware scrolling patch

[Brian White]

incredible!

bkw

On Thu, Feb 24, 2022, 12:52 AM Stephen Adolph  wrote:

> ...and found some more savings.  *now down to 85 bytes*!  Leaving 65
> bytes for more patch fun.
>
>
> On Wed, Feb 23, 2022 at 1:24 PM Stephen Adolph 
> wrote:
>
>> In T200, the video subsystem was really reworked to take advantage of
>> hardware scrolling.
>> From a quick scan, it seems like the basic operation is the same for M100
>> and T200 (upper and lower portions of the LCD), so the same "organization"
>> should be applicable to the M100.
>>
>> Could T200 video subsystem be back ported to M100?  Perhaps a much deeper
>> dive into the code could make the M100 truly work as well as the T200 from
>> this perspective, but I would worry that the end result would be so
>> substantially different that software compatibility may become an issue.
>>
>> I guess they got away with software scroll on M100, but T200 would have
>> been completely unacceptable with such a slow scroll across 16 lines rather
>> than 8.
>>
>> Anyhow, I have streamlined the patch now to only 95 bytes, leaving 55
>> bytes for more stuff.  I may try to augment what is there with coverage for
>> some of the additional scroll corner cases.
>>
>> Steve
>>
>> On Wed, Feb 23, 2022 at 10:48 AM Joshua O'Keefe 
>> wrote:
>>
>>> > On Feb 23, 2022, at 7:17 AM, Stephen Adolph 
>>> wrote:
>>> > I did a write up on the two patches that are needed.
>>>
>>> Steve, I remember seeing you mention this a while back and I'm glad you
>>> were able to get back to it.  Your write-up was clear, informative and
>>> interesting.  Thanks for sharing it.
>>>
>>> I wonder why this controller feature was never exploited.  Was there
>>> perhaps a similar, earlier part lacking the feature that was swapped out
>>> late in the design cycle?  Simple time constraints like every engineer in
>>> history has faced?  I can imagine all kinds of scenarios and it's a shame
>>> we'll never know the real story of why the ROM is the way it is.
>>
>>

Re: [M100] hardware scrolling patch

[Stephen Adolph]

Hi Tom,

I was thinking about that.  It may well work with CP/m or if not exactly
this patch then maybe a minor variant.  The m100 main rom provides all of
these routines for cp/m.

Cp/m always powers up as an M100 but the upper ram image would need to have
the one location that stores page state to be zeroed out.

That upper ram image is bundled into the cpm image that is loaded from
disk.  So i think what is needed is to just poke a 0 into that spot in the
file on disk, or run a little utility on start of cp/m.

Steve


On Wednesday, February 23, 2022, Tom Hoppe  wrote:

> Could this work with CP/M?
>
> On Wed, Feb 23, 2022 at 7:48 AM Joshua O'Keefe 
> wrote:
>
>> > On Feb 23, 2022, at 7:17 AM, Stephen Adolph 
>> wrote:
>> > I did a write up on the two patches that are needed.
>>
>> Steve, I remember seeing you mention this a while back and I'm glad you
>> were able to get back to it.  Your write-up was clear, informative and
>> interesting.  Thanks for sharing it.
>>
>> I wonder why this controller feature was never exploited.  Was there
>> perhaps a similar, earlier part lacking the feature that was swapped out
>> late in the design cycle?  Simple time constraints like every engineer in
>> history has faced?  I can imagine all kinds of scenarios and it's a shame
>> we'll never know the real story of why the ROM is the way it is.
>
>

Re: [M100] hardware scrolling patch

[Stephen Adolph]

Hi Mike,
It is the M102 rom, but I use it in my M100.
This image might have y2k patch applied also.

Anyhow it should work in M100.  Let me know if it doesnt!

I personally have only tested in virtualT.

Steve

On Wednesday, February 23, 2022, Mike Stein  wrote:

> Looks good;is this only for the 102 or also the M100?
>
>
> On Wed, Feb 23, 2022 at 5:10 PM Stephen Adolph 
> wrote:
>
>> I'm trying to attach a patched rom to play with.  Will this get through?
>> thx
>> Steve
>>
>> On Wed, Feb 23, 2022 at 3:57 PM Peter Vollan 
>> wrote:
>>
>>> Maybe Bill was in a hurry.
>>>
>>> On Wed, 23 Feb 2022 at 11:53, John R. Hogerhuis 
>>> wrote:
>>>
 Very cool. The slow scroll is one of the noticeable issues of the
 M100/T102.

 Missed opportunity for Bill G. Similar to not implementing the higher
 baud rates and hardware flow control for the UART.

 But it's all about cost versus benefit, time to market.

 "Premature optimization is the root of all evil" - Donald Knuth

 And the three rules of optimization (the way I heard it):

 Rule #1: Don't.
 Rule #2: No, really. Don't.
 Rule #3, only for experts: Not yet!

 The rules aside, I think it's time :-)

 -- John.

 On Tue, Feb 22, 2022 at 9:45 PM Stephen Adolph 
 wrote:

> Well, I started this little activity in 2006.
>
> I have a pretty good working "hardware scroll patch" now running in
> virtual T!
>
> Recall-
> * the M100 LCD drivers have a hardware scroll mode
> * M100 does not take advantage of it to speed things up.
> * I previously made a patch to the M100 rom that frees up 150 bytes.
> * I've used most of that free space now to implement a patch that uses
> hardware scroll.
>
> The only condition that this patch corrects is the condition when an
> entire 8 lines of screen is being scrolled either up or down.
>
> Other speed ups are imaginable but are much more complex to implement.
>
> I have one last bug that I know of to fix, and when I get that done I
> will share it so others can give it a try!
>
> Steve
>

Re: [M100] hardware scrolling patch

[Mike Stein]

Looks good;is this only for the 102 or also the M100?


On Wed, Feb 23, 2022 at 5:10 PM Stephen Adolph  wrote:

> I'm trying to attach a patched rom to play with.  Will this get through?
> thx
> Steve
>
> On Wed, Feb 23, 2022 at 3:57 PM Peter Vollan  wrote:
>
>> Maybe Bill was in a hurry.
>>
>> On Wed, 23 Feb 2022 at 11:53, John R. Hogerhuis  wrote:
>>
>>> Very cool. The slow scroll is one of the noticeable issues of the
>>> M100/T102.
>>>
>>> Missed opportunity for Bill G. Similar to not implementing the higher
>>> baud rates and hardware flow control for the UART.
>>>
>>> But it's all about cost versus benefit, time to market.
>>>
>>> "Premature optimization is the root of all evil" - Donald Knuth
>>>
>>> And the three rules of optimization (the way I heard it):
>>>
>>> Rule #1: Don't.
>>> Rule #2: No, really. Don't.
>>> Rule #3, only for experts: Not yet!
>>>
>>> The rules aside, I think it's time :-)
>>>
>>> -- John.
>>>
>>> On Tue, Feb 22, 2022 at 9:45 PM Stephen Adolph 
>>> wrote:
>>>
 Well, I started this little activity in 2006.

 I have a pretty good working "hardware scroll patch" now running in
 virtual T!

 Recall-
 * the M100 LCD drivers have a hardware scroll mode
 * M100 does not take advantage of it to speed things up.
 * I previously made a patch to the M100 rom that frees up 150 bytes.
 * I've used most of that free space now to implement a patch that uses
 hardware scroll.

 The only condition that this patch corrects is the condition when an
 entire 8 lines of screen is being scrolled either up or down.

 Other speed ups are imaginable but are much more complex to implement.

 I have one last bug that I know of to fix, and when I get that done I
 will share it so others can give it a try!

 Steve

>>>

Re: [M100] hardware scrolling patch

[Stephen Adolph]

I'm trying to attach a patched rom to play with.  Will this get through?
thx
Steve

On Wed, Feb 23, 2022 at 3:57 PM Peter Vollan  wrote:

> Maybe Bill was in a hurry.
>
> On Wed, 23 Feb 2022 at 11:53, John R. Hogerhuis  wrote:
>
>> Very cool. The slow scroll is one of the noticeable issues of the
>> M100/T102.
>>
>> Missed opportunity for Bill G. Similar to not implementing the higher
>> baud rates and hardware flow control for the UART.
>>
>> But it's all about cost versus benefit, time to market.
>>
>> "Premature optimization is the root of all evil" - Donald Knuth
>>
>> And the three rules of optimization (the way I heard it):
>>
>> Rule #1: Don't.
>> Rule #2: No, really. Don't.
>> Rule #3, only for experts: Not yet!
>>
>> The rules aside, I think it's time :-)
>>
>> -- John.
>>
>> On Tue, Feb 22, 2022 at 9:45 PM Stephen Adolph 
>> wrote:
>>
>>> Well, I started this little activity in 2006.
>>>
>>> I have a pretty good working "hardware scroll patch" now running in
>>> virtual T!
>>>
>>> Recall-
>>> * the M100 LCD drivers have a hardware scroll mode
>>> * M100 does not take advantage of it to speed things up.
>>> * I previously made a patch to the M100 rom that frees up 150 bytes.
>>> * I've used most of that free space now to implement a patch that uses
>>> hardware scroll.
>>>
>>> The only condition that this patch corrects is the condition when an
>>> entire 8 lines of screen is being scrolled either up or down.
>>>
>>> Other speed ups are imaginable but are much more complex to implement.
>>>
>>> I have one last bug that I know of to fix, and when I get that done I
>>> will share it so others can give it a try!
>>>
>>> Steve
>>>
>>
<>

Re: [M100] hardware scrolling patch

[Peter Vollan]

Maybe Bill was in a hurry.

On Wed, 23 Feb 2022 at 11:53, John R. Hogerhuis  wrote:

> Very cool. The slow scroll is one of the noticeable issues of the
> M100/T102.
>
> Missed opportunity for Bill G. Similar to not implementing the higher baud
> rates and hardware flow control for the UART.
>
> But it's all about cost versus benefit, time to market.
>
> "Premature optimization is the root of all evil" - Donald Knuth
>
> And the three rules of optimization (the way I heard it):
>
> Rule #1: Don't.
> Rule #2: No, really. Don't.
> Rule #3, only for experts: Not yet!
>
> The rules aside, I think it's time :-)
>
> -- John.
>
> On Tue, Feb 22, 2022 at 9:45 PM Stephen Adolph 
> wrote:
>
>> Well, I started this little activity in 2006.
>>
>> I have a pretty good working "hardware scroll patch" now running in
>> virtual T!
>>
>> Recall-
>> * the M100 LCD drivers have a hardware scroll mode
>> * M100 does not take advantage of it to speed things up.
>> * I previously made a patch to the M100 rom that frees up 150 bytes.
>> * I've used most of that free space now to implement a patch that uses
>> hardware scroll.
>>
>> The only condition that this patch corrects is the condition when an
>> entire 8 lines of screen is being scrolled either up or down.
>>
>> Other speed ups are imaginable but are much more complex to implement.
>>
>> I have one last bug that I know of to fix, and when I get that done I
>> will share it so others can give it a try!
>>
>> Steve
>>
>

Re: [M100] hardware scrolling patch

[John R. Hogerhuis]

Very cool. The slow scroll is one of the noticeable issues of the M100/T102.

Missed opportunity for Bill G. Similar to not implementing the higher baud
rates and hardware flow control for the UART.

But it's all about cost versus benefit, time to market.

"Premature optimization is the root of all evil" - Donald Knuth

And the three rules of optimization (the way I heard it):

Rule #1: Don't.
Rule #2: No, really. Don't.
Rule #3, only for experts: Not yet!

The rules aside, I think it's time :-)

-- John.

On Tue, Feb 22, 2022 at 9:45 PM Stephen Adolph  wrote:

> Well, I started this little activity in 2006.
>
> I have a pretty good working "hardware scroll patch" now running in
> virtual T!
>
> Recall-
> * the M100 LCD drivers have a hardware scroll mode
> * M100 does not take advantage of it to speed things up.
> * I previously made a patch to the M100 rom that frees up 150 bytes.
> * I've used most of that free space now to implement a patch that uses
> hardware scroll.
>
> The only condition that this patch corrects is the condition when an
> entire 8 lines of screen is being scrolled either up or down.
>
> Other speed ups are imaginable but are much more complex to implement.
>
> I have one last bug that I know of to fix, and when I get that done I will
> share it so others can give it a try!
>
> Steve
>

Re: [M100] hardware scrolling patch

[Stephen Adolph]

...and found some more savings.  *now down to 85 bytes*!  Leaving 65 bytes
for more patch fun.


On Wed, Feb 23, 2022 at 1:24 PM Stephen Adolph  wrote:

> In T200, the video subsystem was really reworked to take advantage of
> hardware scrolling.
> From a quick scan, it seems like the basic operation is the same for M100
> and T200 (upper and lower portions of the LCD), so the same "organization"
> should be applicable to the M100.
>
> Could T200 video subsystem be back ported to M100?  Perhaps a much deeper
> dive into the code could make the M100 truly work as well as the T200 from
> this perspective, but I would worry that the end result would be so
> substantially different that software compatibility may become an issue.
>
> I guess they got away with software scroll on M100, but T200 would have
> been completely unacceptable with such a slow scroll across 16 lines rather
> than 8.
>
> Anyhow, I have streamlined the patch now to only 95 bytes, leaving 55
> bytes for more stuff.  I may try to augment what is there with coverage for
> some of the additional scroll corner cases.
>
> Steve
>
> On Wed, Feb 23, 2022 at 10:48 AM Joshua O'Keefe 
> wrote:
>
>> > On Feb 23, 2022, at 7:17 AM, Stephen Adolph 
>> wrote:
>> > I did a write up on the two patches that are needed.
>>
>> Steve, I remember seeing you mention this a while back and I'm glad you
>> were able to get back to it.  Your write-up was clear, informative and
>> interesting.  Thanks for sharing it.
>>
>> I wonder why this controller feature was never exploited.  Was there
>> perhaps a similar, earlier part lacking the feature that was swapped out
>> late in the design cycle?  Simple time constraints like every engineer in
>> history has faced?  I can imagine all kinds of scenarios and it's a shame
>> we'll never know the real story of why the ROM is the way it is.
>
>

Re: [M100] hardware scrolling patch

[Stephen Adolph]

In T200, the video subsystem was really reworked to take advantage of
hardware scrolling.
>From a quick scan, it seems like the basic operation is the same for M100
and T200 (upper and lower portions of the LCD), so the same "organization"
should be applicable to the M100.

Could T200 video subsystem be back ported to M100?  Perhaps a much deeper
dive into the code could make the M100 truly work as well as the T200 from
this perspective, but I would worry that the end result would be so
substantially different that software compatibility may become an issue.

I guess they got away with software scroll on M100, but T200 would have
been completely unacceptable with such a slow scroll across 16 lines rather
than 8.

Anyhow, I have streamlined the patch now to only 95 bytes, leaving 55 bytes
for more stuff.  I may try to augment what is there with coverage for some
of the additional scroll corner cases.

Steve

On Wed, Feb 23, 2022 at 10:48 AM Joshua O'Keefe 
wrote:

> > On Feb 23, 2022, at 7:17 AM, Stephen Adolph 
> wrote:
> > I did a write up on the two patches that are needed.
>
> Steve, I remember seeing you mention this a while back and I'm glad you
> were able to get back to it.  Your write-up was clear, informative and
> interesting.  Thanks for sharing it.
>
> I wonder why this controller feature was never exploited.  Was there
> perhaps a similar, earlier part lacking the feature that was swapped out
> late in the design cycle?  Simple time constraints like every engineer in
> history has faced?  I can imagine all kinds of scenarios and it's a shame
> we'll never know the real story of why the ROM is the way it is.

Re: [M100] hardware scrolling patch

[Tom Hoppe]

Could this work with CP/M?

On Wed, Feb 23, 2022 at 7:48 AM Joshua O'Keefe 
wrote:

> > On Feb 23, 2022, at 7:17 AM, Stephen Adolph 
> wrote:
> > I did a write up on the two patches that are needed.
>
> Steve, I remember seeing you mention this a while back and I'm glad you
> were able to get back to it.  Your write-up was clear, informative and
> interesting.  Thanks for sharing it.
>
> I wonder why this controller feature was never exploited.  Was there
> perhaps a similar, earlier part lacking the feature that was swapped out
> late in the design cycle?  Simple time constraints like every engineer in
> history has faced?  I can imagine all kinds of scenarios and it's a shame
> we'll never know the real story of why the ROM is the way it is.

Re: [M100] hardware scrolling patch

[Joshua O'Keefe]

> On Feb 23, 2022, at 7:17 AM, Stephen Adolph  wrote:
> I did a write up on the two patches that are needed.

Steve, I remember seeing you mention this a while back and I'm glad you were 
able to get back to it.  Your write-up was clear, informative and interesting.  
Thanks for sharing it.

I wonder why this controller feature was never exploited.  Was there perhaps a 
similar, earlier part lacking the feature that was swapped out late in the 
design cycle?  Simple time constraints like every engineer in history has 
faced?  I can imagine all kinds of scenarios and it's a shame we'll never know 
the real story of why the ROM is the way it is.

Re: [M100] hardware scrolling patch

[Stephen Adolph]

Thanks Ken.
I did a write up on the two patches that are needed.
* base patch, to clear the hole for the subsequent patches
* hardware scroll patch, which overlays

Comments welcome.
Document is zipped and is word.

On Wed, Feb 23, 2022 at 10:00 AM Ken Pettit  wrote:

> Hey Steve,
>
> Great job!  72 seconds still isn't bad considering you still have to
> update the scroll value on 10 LCD controllers and copy one line from the
> bottom controller to the top controller, plus all the added logic to keep
> track of which line is which.
>
> And it is always satisfying to finish a project that was started years
> earlier.  This was the case with NADSBox ... I released it in 2009 but
> actually started in 2002 and then dropped it for several years.
>
> Ken
>
> On 2/22/22 10:23 PM, Stephen Adolph wrote:
>
> So, as a figure of merit, I decided to use A-DUEL.BA as a listing source.
> Under these conditions -  virtualT @ 2.5MHz
> Listing took 72 seconds with hardware scroll "on"
> Listing took 120 seconds with no hardware scroll.
> The speed up is pretty reasonable, but not like 10x faster or anything.
>
> (and I found my bug - fixed - and found another, but that can be a
> something for the next session)
>
> Steve
>
>
> On Wed, Feb 23, 2022 at 12:44 AM Stephen Adolph 
> wrote:
>
>> Well, I started this little activity in 2006.
>>
>> I have a pretty good working "hardware scroll patch" now running in
>> virtual T!
>>
>> Recall-
>> * the M100 LCD drivers have a hardware scroll mode
>> * M100 does not take advantage of it to speed things up.
>> * I previously made a patch to the M100 rom that frees up 150 bytes.
>> * I've used most of that free space now to implement a patch that uses
>> hardware scroll.
>>
>> The only condition that this patch corrects is the condition when an
>> entire 8 lines of screen is being scrolled either up or down.
>>
>> Other speed ups are imaginable but are much more complex to implement.
>>
>> I have one last bug that I know of to fix, and when I get that done I
>> will share it so others can give it a try!
>>
>> Steve
>>
>
>
<>

Re: [M100] hardware scrolling patch

[Ken Pettit]

Hey Steve,

Great job!  72 seconds still isn't bad considering you still have to 
update the scroll value on 10 LCD controllers and copy one line from the 
bottom controller to the top controller, plus all the added logic to 
keep track of which line is which.


And it is always satisfying to finish a project that was started years 
earlier.  This was the case with NADSBox ... I released it in 2009 but 
actually started in 2002 and then dropped it for several years.


Ken

On 2/22/22 10:23 PM, Stephen Adolph wrote:
So, as a figure of merit, I decided to use A-DUEL.BA 
 as a listing source.

Under these conditions -  virtualT @ 2.5MHz
Listing took 72 seconds with hardware scroll "on"
Listing took 120 seconds with no hardware scroll.
The speed up is pretty reasonable, but not like 10x faster or anything.

(and I found my bug - fixed - and found another, but that can be a 
something for the next session)


Steve


On Wed, Feb 23, 2022 at 12:44 AM Stephen Adolph > wrote:


Well, I started this little activity in 2006.

I have a pretty good working "hardware scroll patch" now running
in virtual T!

Recall-
* the M100 LCD drivers have a hardware scroll mode
* M100 does not take advantage of it to speed things up.
* I previously made a patch to the M100 rom that frees up 150 bytes.
* I've used most of that free space now to implement a patch that
uses hardware scroll.

The only condition that this patch corrects is the condition when
an entire 8 lines of screen is being scrolled either up or down.

Other speed ups are imaginable but are much more complex to implement.

I have one last bug that I know of to fix, and when I get that
done I will share it so others can give it a try!

Steve

Re: [M100] hardware scrolling patch

[Stephen Adolph]

So, as a figure of merit, I decided to use A-DUEL.BA as a listing source.
Under these conditions -  virtualT @ 2.5MHz
Listing took 72 seconds with hardware scroll "on"
Listing took 120 seconds with no hardware scroll.
The speed up is pretty reasonable, but not like 10x faster or anything.

(and I found my bug - fixed - and found another, but that can be a
something for the next session)

Steve


On Wed, Feb 23, 2022 at 12:44 AM Stephen Adolph 
wrote:

> Well, I started this little activity in 2006.
>
> I have a pretty good working "hardware scroll patch" now running in
> virtual T!
>
> Recall-
> * the M100 LCD drivers have a hardware scroll mode
> * M100 does not take advantage of it to speed things up.
> * I previously made a patch to the M100 rom that frees up 150 bytes.
> * I've used most of that free space now to implement a patch that uses
> hardware scroll.
>
> The only condition that this patch corrects is the condition when an
> entire 8 lines of screen is being scrolled either up or down.
>
> Other speed ups are imaginable but are much more complex to implement.
>
> I have one last bug that I know of to fix, and when I get that done I will
> share it so others can give it a try!
>
> Steve
>

[M100] hardware scrolling patch

[Stephen Adolph]

Well, I started this little activity in 2006.

I have a pretty good working "hardware scroll patch" now running in virtual
T!

Recall-
* the M100 LCD drivers have a hardware scroll mode
* M100 does not take advantage of it to speed things up.
* I previously made a patch to the M100 rom that frees up 150 bytes.
* I've used most of that free space now to implement a patch that uses
hardware scroll.

The only condition that this patch corrects is the condition when an entire
8 lines of screen is being scrolled either up or down.

Other speed ups are imaginable but are much more complex to implement.

I have one last bug that I know of to fix, and when I get that done I will
share it so others can give it a try!

Steve