TheBackShed.com

Forum Index : Microcontroller and PC projects : CMM2: V5.07.00b12 - Various fixes

Page 6 of 9

Author

Message

epsilon

Senior Member

Joined: 30/07/2020
Location: Belgium
Posts: 255

Posted: 04:57pm 23 Apr 2021

Copy link to clipboard

Print this post

It's a bit unfortunate that MM.INFO$(MODIFIED filename%)) does not return a valid datetime string, as accepted by EPOCH for instance:

> PRINT MM.INFO$(MODIFIED "settings.default.inc")
2021-04-23 17:44:08
> PRINT EPOCH(MM.INFO$(MODIFIED "settings.default.inc"))
Invalid date

I worked around the mismatch with the following function:

FUNCTION swapDateFieldsInStr$(dateTimeStr$)
LOCAL y$ = FIELD$(dateTimeStr$, 1, "- ")
LOCAL m$ = FIELD$(dateTimeStr$, 2, "- ")
LOCAL d$ = FIELD$(dateTimeStr$, 3, "- ")
LOCAL t$ = MID$(dateTimeStr$, INSTR(dateTimeStr$," "))

swapDateFieldsInStr$ = d$+"-"+m$+"-"+y$+t$
END FUNCTION

Epsilon CMM2 projects

matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 10067

Posted: 05:08pm 23 Apr 2021

Copy link to clipboard

Print this post

Quote It's a bit unfortunate that MM.INFO$(MODIFIED filename%)) does not return a valid datetime string, as accepted by EPOCH for instance

That is easily fixed by making epoch use the file format if the "day" is > 1000. Watch this space.

matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 10067

Posted: 08:58am 26 Apr 2021

Copy link to clipboard

Print this post

V5.07.00b29 now available

http://geoffg.net/Downloads/Maximite/CMM2_Beta.zip

Turtles restored

DAY$ and EPOCH functions now accept

"DD-MM-YY"
"DD-MM-YYYY"
and
"YYYY-MM-DD"

as the date part of the string
Edited 2021-04-26 19:00 by matherp

thwill

Guru

Joined: 16/09/2019
Location: United Kingdom
Posts: 4251

Posted: 09:07am 26 Apr 2021

Copy link to clipboard

Print this post

matherp said V5.07.00b29 now available

...

Turtles restored

And Welcome Tape examples confirmed working, thank you.

Best wishes,

Tom

MMBasic for Linux, Game*Mite, CMM2 Welcome Tape, Creaky old text adventures

epsilon

Senior Member

Joined: 30/07/2020
Location: Belgium
Posts: 255

Posted: 08:25am 27 Apr 2021

Copy link to clipboard

Print this post

matherp said
DAY$ and EPOCH functions now accept

"DD-MM-YY"
"DD-MM-YYYY"
and
"YYYY-MM-DD"

as the date part of the string

Confirmed. Thank you!
I'm still seeing the same issue with #COMMENT blocks in .INC files however.

Epsilon CMM2 projects

matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 10067

Posted: 08:39am 27 Apr 2021

Copy link to clipboard

Print this post

Quote 'm still seeing the same issue with #COMMENT blocks in .INC files however.

The firmware appears correct and it works for me so we need to identify what is different about your code. Please post a simple example that fails

epsilon

Senior Member

Joined: 30/07/2020
Location: Belgium
Posts: 255

Posted: 09:04am 27 Apr 2021

Copy link to clipboard

Print this post

I've got the feeling I'm making a silly mistake somewhere and by the time I finish writing this, I will have found it

. Here we go:

> list "test2.bas"
#INCLUDE "test.inc"

#COMMENT START
dffddgfd
#COMMENT END

bar

END

> list "test.inc"
SUB bar
PRINT "In bar"
#COMMENT START
PRINT "In bar comment"
#COMMENT END
END SUB

> *test2
In bar
Error in test.inc line 3: Invalid character: #

Epsilon CMM2 projects

matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 10067

Posted: 09:55am 27 Apr 2021

Copy link to clipboard

Print this post

Quote I'm still seeing the same issue with #COMMENT blocks in .INC files however.

OK now I understand. It is removing the commented lines but leaving the #commands. Will fix in next beta

Thanks for the example

vegipete

Guru

Joined: 29/01/2013
Location: Canada
Posts: 1122

Posted: 07:02pm 29 Apr 2021

Copy link to clipboard

Print this post

Two little niggles with graphics:

1) IMAGE ROTATE and IMAGE ROTATE_FAST don't handle even sized regions gracefully:

mode 1,8
cls
box 100,50,400,400
text 101,51,"A"

do
do : loop until inkey$ <> ""
image rotate_fast 100,50,400,400,100,50,90
loop

Obviously there is no 'center' pixel in an even sized rectangle, so a slightly altered region is rotated. Odd sized regions seem fine. Change the rotate region width and height to 401 to see a difference.

2) Filled polygons can be slightly wrong when floats are involved.

mode 1,8
cls rgb(red)

dim px(7),py(7)
dim float x(7) = ( 3,3,1.5, 1.5, 3, 5,5,3)
dim float y(7) = (-3,3,1.5,-1.5,-3,-3,3,3)

for i = 1 to 10

math scale x(),-(i^2),px()
math scale y(),-(i^2),py()
math add px(),MM.HRES/2 + 2*i,px()
math add py(),MM.VRES/2,py()
? i
polygon 8,px(),py(),rgb(grey),rgb(black)

do : loop until inkey$ <> ""
next i
pixel fill 500,500,0
end

Note the little slivers of red at the end. These are inside the polygons and should have been filled as black. This suggests the polygon outline code is using different float rounding/truncating than the polygon fill code.

Visit Vegipete's *Mite Library for cool programs.

matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 10067

Posted: 09:51pm 29 Apr 2021

Copy link to clipboard

Print this post

Quote MAGE ROTATE and IMAGE ROTATE_FAST don't handle even sized regions gracefully:

Correct: you should always rotate from the original and not rotate a rotated image otherwise it will dissolve into rubbish

Quote This suggests the polygon outline code is using different float rounding/truncating than the polygon fill code.

It uses floats rather than doubles for performance reasons - use integers

vegipete

Guru

Joined: 29/01/2013
Location: Canada
Posts: 1122

Posted: 10:36pm 29 Apr 2021

Copy link to clipboard

Print this post

matherp said

Quote IMAGE ROTATE and IMAGE ROTATE_FAST don't handle even sized regions gracefully:

Correct: you should always rotate from the original and not rotate a rotated image otherwise it will dissolve into rubbish.

Repeated IMAGE ROTATE certainly will fuzz an image to noise. However, IMAGE ROTATE_FAST appears to be clean with 90 degree rotations. My first example program demonstrates that you can ROTATE_FAST (in 90 degree steps) indefinitely and maintain the original image. It's just that the region has to be an odd number of pixels high and wide that is a slight pain. The sample demonstrates that the entire region requested for rotate is not done if the region has even length sides.

Quote It uses floats rather than doubles for performance reasons - use integers

I'm using floats for scaling purposes.
I just tested something along the lines of

math add px(),offsetx,rx()
math add py(),offsety,ry()
polygon 8,rx(),ry(),rgb(grey),rgb(black)

where px() and py() are floats and rx() and ry() are integers.
This fixes the problem.

Visit Vegipete's *Mite Library for cool programs.

vegipete

Guru

Joined: 29/01/2013
Location: Canada
Posts: 1122

Posted: 12:56am 04 May 2021

Copy link to clipboard

Print this post

Screen tearing and BLIT:

mode 1,12
cls

circle MM.VRES/2,MM.VRES/2,MM.VRES/2,5,1,rgb(yellow),rgb(red)

page copy 0,2

page write 2
do
blit 0,0,50,0,MM.VRES,MM.VRES
pause 500
loop

The above shows hideous tearing, even though the blit is being performed on a non-visible page. Yes, I know the blit is moving a tremendous amount of memory, but why is that affecting the video output? Shouldn't the video generation take priority over the blit memory move? Or is this an inevitable side-effect of the crazy tricks required to increase the memory move bandwidth?

Visit Vegipete's *Mite Library for cool programs.

matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 10067

Posted: 07:04am 04 May 2021

Copy link to clipboard

Print this post

Mode 1,12 is at the absolute limit of what the H/W will support

40MHz x 4 bytes per pixel = 160Mbytes/second from the SDRAM. Anything else contending for access to the SDRAM is likely to cause issues. Note that 12-bit mode isn't allowed at all on any of the higher resolutions. I could block it on mode 1 as well but it has uses if you can live with the limitations.

Blitting within a page overlapping areas is also a worst case Blit as you are constantly changing from read to write mode in the same area of SDRAM and that also
has an overhead
Edited 2021-05-04 17:09 by matherp

matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 10067

Posted: 07:02pm 05 May 2021

Copy link to clipboard

Print this post

V5.07.00b30 now available

http://geoffg.net/Downloads/Maximite/CMM2_Beta.zip

Should fix #comment in include files

Implements new mode 15 1280x1024 as requested. This is only available in 8-bit colour depth due to memory bandwidth limitations - running at 108MHz

Plasmamac

Guru

Joined: 31/01/2019
Location: Germany
Posts: 572

Posted: 07:37pm 05 May 2021

Copy link to clipboard

Print this post

wow Peter you pushing the Hardware to the Limit

thanks

Plasma

bar1010
Senior Member

Joined: 10/08/2020
Location: United States
Posts: 197

Posted: 02:53am 06 May 2021

Copy link to clipboard

Print this post

matherp said V5.07.00b30 now available

http://geoffg.net/Downloads/Maximite/CMM2_Beta.zip

Should fix #comment in include files

Implements new mode 15 1280x1024 as requested. This is only available in 8-bit colour depth due to memory bandwidth limitations - running at 108MHz

Thanks Peter for new mode 15.

epsilon

Senior Member

Joined: 30/07/2020
Location: Belgium
Posts: 255

Posted: 08:08am 12 May 2021

Copy link to clipboard

Print this post

Comment blocks inside .INC files are OK now. Thanks!

In the meantime I ran into another issue: I was experimenting with palette animation and noticed some flickering artifacts at the bottom of the screen:

Those evenly spaced dots at the bottom of the screen shouldn't be there, and they're flickering.

Here's some sample code to recreate the issue:

OPTION EXPLICIT
OPTION DEFAULT NONE
OPTION BASE 0

MODE 7,8

DIM ii%, jj%

DO
FOR ii%=0 TO 255
FOR jj%=0 TO 255
MAP(jj%) = RGB(ii%,ii%,ii%)
NEXT jj%

MAP SET
NEXT ii%
LOOP

END

This is 320x240 but I'm also seeing it with other screen resolutions.

The flickering dots appear on the last scanline, i.e. MM.VRES-1.

The manual says MAP SET takes effect during the frame blanking interval. Is it possible it starts one scan line too soon?

Epsilon CMM2 projects

matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 10067

Posted: 08:26am 12 May 2021

Copy link to clipboard

Print this post

Quote The manual says MAP SET takes effect during the frame blanking interval. Is it possible it starts one scan line too soon?

Perfect diagnosis - will fix in next beta

epsilon

Senior Member

Joined: 30/07/2020
Location: Belgium
Posts: 255

Posted: 08:51am 12 May 2021

Copy link to clipboard

Print this post

matherp said

Quote The manual says MAP SET takes effect during the frame blanking interval. Is it possible it starts one scan line too soon?

Perfect diagnosis - will fix in next beta

Great! Thanks for the quick response!

Epsilon CMM2 projects

William Leue
Guru

Joined: 03/07/2020
Location: United States
Posts: 405

Posted: 02:59pm 12 May 2021

Copy link to clipboard

Print this post

Peter, I did notice one possible bug in 5.6.00; don't know if it has been fixed in 5.7.xx.

Basic generates a syntax error when I try to pass expressions as arguments to a function, e.g.

foo(2*x+7, 22-9*y)

fails, but

a = 2*x+7
b = 22-9*y
foo(a, b)

works.

Back in the olde days of compiled code, we used to call this "failure to compile a thunk". Maybe MMBasic doesn't really want to handle this kind of complexity, which is ok, since it is so easy to work around.

-Bill

Page 6 of 9

Print this page