 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
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: BelgiumPosts: 255 |
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 KingdomPosts: 8585 |
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 KingdomPosts: 8585 |
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 KingdomPosts: 3846 |
And Welcome Tape examples confirmed working, thank you. Best wishes, Tom Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| epsilon Senior Member Joined: 30/07/2020 Location: BelgiumPosts: 255 |
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 KingdomPosts: 8585 |
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: BelgiumPosts: 255 |
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 KingdomPosts: 8585 |
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: CanadaPosts: 1082 |
Two little niggles with graphics: 1) IMAGE ROTATE and IMAGE ROTATE_FAST don't handle even sized regions gracefully: mode 1,8 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.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 2) Filled polygons can be slightly wrong when floats are involved. mode 1,8 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.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 Visit Vegipete's *Mite Library for cool programs. |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8585 |
Correct: you should always rotate from the original and not rotate a rotated image otherwise it will dissolve into rubbish It uses floats rather than doubles for performance reasons - use integers |
||||
| vegipete Guru Joined: 29/01/2013 Location: CanadaPosts: 1082 |
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. I'm using floats for scaling purposes. I just tested something along the lines of math add px(),offsetx,rx() where px() and py() are floats and rx() and ry() are integers.math add py(),offsety,ry() polygon 8,rx(),ry(),rgb(grey),rgb(black) This fixes the problem. Visit Vegipete's *Mite Library for cool programs. |
||||
| vegipete Guru Joined: 29/01/2013 Location: CanadaPosts: 1082 |
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 KingdomPosts: 8585 |
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 KingdomPosts: 8585 |
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: GermanyPosts: 501 |
wow Peter you pushing the Hardware to the Limit  thanks Plasma |
||||
| bar1010 Senior Member Joined: 10/08/2020 Location: United StatesPosts: 197 |
Thanks Peter for new mode 15. |
||||
| epsilon Senior Member Joined: 30/07/2020 Location: BelgiumPosts: 255 |
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 KingdomPosts: 8585 |
Perfect diagnosis - will fix in next beta |
||||
| epsilon Senior Member Joined: 30/07/2020 Location: BelgiumPosts: 255 |
Great! Thanks for the quick response! Epsilon CMM2 projects |
||||
| William Leue Guru Joined: 03/07/2020 Location: United StatesPosts: 382 |
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 |
