Canges applied.
Good to know you were able to fix the library, build it and fix it !
The video is cool
I like what I see, but if you think the game is too slow, you have three ways:
- To reduce the sprite size
- To reduce a little the presentation quality (removing the men and score) and to disable the sound
- To optimize the libraries (ok, this one is harder )
As soon as you think the demo programs run good enough, feel free to publish their port in your MC-1000 forum.
CCE MC-1000 tests
Stefano!
I believe I have fixed the low volume problem in click-generated sound. Below are the changes that must be done:
1) In libsrc/games/games.inc, sndbit_mask should be 15 istead of 8:
2) In libsrc/games/mc1000/bit_open.asm, snd_tick should be initialized with zero instead of 8 (include a XOR A command):
I will send you some sound samples by e-mail.
I believe I have fixed the low volume problem in click-generated sound. Below are the changes that must be done:
1) In libsrc/games/games.inc, sndbit_mask should be 15 istead of 8:
Code: Select all
[?]
IF FORmc1000
defc sndbit_port = 96 ; $60 = YM amplitude register
defc sndbit_bit = 3 ; More significant bit
defc sndbit_mask = 15
ENDIF
[?]
Code: Select all
[?]
ld a,8 ; Select amplitude register for channel A.
out ($20),a
xor a ; Clear tick tracker.
ld (snd_tick),a
[?]
Great !
Consider the changes committed.
The backspace issue: which is the key code for BS on the MC-1000 ? There are two ways to solve it, the easier one should be to re-map its declaration in the adv_a source itself.
I widely used ADV_A to test the target platform memory limits, and I think it can be used also in this case.
I hoped the full 'graphics' version could run on a 48K system: the graphics are actively paged in and out, so the same memory location can be used for graphics and code, assuming the stack is high enough. Is this a test you can try to do ?
Consider the changes committed.
The backspace issue: which is the key code for BS on the MC-1000 ? There are two ways to solve it, the easier one should be to re-map its declaration in the adv_a source itself.
I widely used ADV_A to test the target platform memory limits, and I think it can be used also in this case.
I hoped the full 'graphics' version could run on a 48K system: the graphics are actively paged in and out, so the same memory location can be used for graphics and code, assuming the stack is high enough. Is this a test you can try to do ?
The <RUBOUT> key produces 127 (ASCII control character "DEL") in "BASIC mode", and 93 ("]") in "game mode".stefano wrote:The backspace issue: which is the key code for BS on the MC-1000 ? There are two ways to solve it, the easier one should be to re-map its declaration in the adv_a source itself.
Yes, I ran adv_a the same day I ran micro man with the corrected joystick function. If you have Facebook, you can see a picture I made of it here:stefano wrote:I widely used ADV_A to test the target platform memory limits, and I think it can be used also in this case.
I hoped the full 'graphics' version could run on a 48K system: the graphics are actively paged in and out, so the same memory location can be used for graphics and code, assuming the stack is high enough. Is this a test you can try to do ?
http://www.facebook.com/photo.php?fbid= ... =1&theater
I made a little progress: GET FLINT? USE FLINT? GET ROPE? USE ROPE? :-)
Re: CCE MC-1000 tests
I have noticed that while being in graphics mode 1 on the MC-1000, every time you print something the entire screen turns green. The normal screen colour is restored the next time you use any graphics function, for example plot(), draw() or putsprite().
As a simple workaround, we can plot or unplot a pixel after each printing activity.
It would be nice to have such a workaround included in the graphics screen printing method on the MC-1000 (provided that it's easy to implement).
I have made a little test program to reproduce this, it shows the behaviour with and without the workaround.
As a simple workaround, we can plot or unplot a pixel after each printing activity.
It would be nice to have such a workaround included in the graphics screen printing method on the MC-1000 (provided that it's easy to implement).
I have made a little test program to reproduce this, it shows the behaviour with and without the workaround.
Code: Select all
/* mctest.c - Monochrome Graphics Test for the MC-1000 "Green Printing Problem"
RobertK, 2022-01-16
Compile with:
REM MC-1000
zcc +mc1000 -create-app -Cz--audio -pragma-redirect:fputc_cons=fputc_cons_generic -pragma-redirect:CRT_FONT=_font_8x8_bbc_system -o mctest_MC1000 mctest.c
REM MC-1000 with Workaround
zcc +mc1000 -create-app -Cz--audio -pragma-redirect:fputc_cons=fputc_cons_generic -pragma-redirect:CRT_FONT=_font_8x8_bbc_system -o mctest_MC1000_with_Workaround mctest.c -D__USE_WORKAROUND
REM Casio PV-2000 (for comparison)
REM zcc +pv2000 -create-app -pragma-redirect:fputc_cons=fputc_cons_generic -o mctest_PV2000 mctest.c
*/
#include <conio.h>
#include <sys/ioctl.h> // required for querying system capabilites and for switching screen modes
#include <graphics.h>
#pragma output CLIB_EXIT_STACK_SIZE = 0
#define SCREEN_MODE_STANDARD 0
#define SCREEN_MODE_GRAPHICS 1
void myCls() // clear the screen
{
#if defined(USE_NATIVE_CONSOLE)
printf("\032");
#elif defined(__LYNXSTANDARDCONSOLE__) // for the Camputers Lynx "rom printer" (when compiling without the generic console parameter)
printf("%c",4); // See page 62 of thy Lynx user manual
clg();
#else
printf("%c",12);
printf("\x0c"); // the "\x0c" (0x0c character) resets the cursor position to the top left corner
#endif
}
void main()
{
int xMax, yMax; // dimensions of the graphics screen
int x, y, m, i;
int mode;
#if defined(SCREEN_MODE_GRAPHICS)
// switch to hires mode
mode = SCREEN_MODE_GRAPHICS;
console_ioctl(IOCTL_GENCON_SET_MODE, &mode);
#endif
#if !defined(DO_NOT_USE_CLG)
clg(); // activate graphics mode
#endif
#if defined(__HAVE_COLOUR)
textcolor(WHITE);
textbackground(BLACK);
#endif
while (1==1) // do forever
{
myCls(); // clear the screen
printf("\n\n\n Graphics Test");
// Query graphics screen dimensions
xMax=getmaxx();
yMax=getmaxy();
printf("\n Screen: %dx%d",xMax+1,yMax+1);
drawb(0,0,xMax,yMax);
drawb(4,4,xMax-8,yMax-8);
for (x=10;x<=xMax-10;x=x+6)
{
draw(x,10,xMax-x,yMax-10);
}
msleep(3000); // Wait some time
printf("\n\nPrinting text...\n");
#if defined(__USE_WORKAROUND)
plot(0,0);
#endif
msleep(3000); // Wait some time
printf("\nDrawing again...\n");
#if defined(__USE_WORKAROUND)
plot(0,0);
#endif
msleep(3000); // Wait some time
for (y=30;y<=yMax-30;y=y+10)
{
draw(30,y,xMax-30,y);
}
msleep(3000); // Wait some time
printf("\nDone...\n");
#if defined(__USE_WORKAROUND)
plot(0,0);
#endif
msleep(3000); // Wait some time
}
printf("\n\n Press any key\n to clear screen...\n");
#if defined(__USE_WORKAROUND)
plot(0,0);
#endif
myCls(); // clear the screen
printf("Done.\n");
#if defined(__HAVE_FGETC_CONS)
fgetc_cons(); // wait for keypress
#else
msleep(3000);
#endif
// Switch back to the default text mode
#if defined(SCREEN_MODE_STANDARD)
mode = SCREEN_MODE_STANDARD;
console_ioctl(IOCTL_GENCON_SET_MODE, &mode);
#endif
myCls();
}
Re: CCE MC-1000 tests
So the difference is the "CSS" bit on the MC6847 - gencon isn't setting it, but graphics is.
I've now updated the graphics library to respect the CSS flag set by console_ioctl() so at least it no longer flickers.
The setting of the CSS flag is the same as the other MC6847 machines: add 32 to the mode number which will set the CSS bit and switch to the alternate colours.
I've now updated the graphics library to respect the CSS flag set by console_ioctl() so at least it no longer flickers.
The setting of the CSS flag is the same as the other MC6847 machines: add 32 to the mode number which will set the CSS bit and switch to the alternate colours.
Re: CCE MC-1000 tests
Off-topic here, but I wanted to try your changes with the latest nightly and noticed that the last autobuild is from 11 January 2022...
Re: CCE MC-1000 tests
Ah, thanks for the poke. The container wasn't set to auto-start and I had a wobbly power cable situation last week.
All sorted now, and I've pushed through a build.
All sorted now, and I've pushed through a build.
Re: CCE MC-1000 tests
Thanks Dom, I have now changed the screen mode from 1 to 33, and the workaround is no longer needed.
Developers (@Fabrizio?) who were using graphics mode 1 on the MC-1000 must now change it to 33, otherwise the screen will be green all the time and flickering while doing graphics output.
Developers (@Fabrizio?) who were using graphics mode 1 on the MC-1000 must now change it to 33, otherwise the screen will be green all the time and flickering while doing graphics output.
Re: CCE MC-1000 tests
I think you're the only person I know doing graphics on the MC1000 - Fabrizio's games are all UDG driven. Regardless, I think a consistent colour is better outcome!RobertK wrote: ↑Mon Jan 17, 2022 2:54 pm Thanks Dom, I have now changed the screen mode from 1 to 33, and the workaround is no longer needed.
Developers (@Fabrizio?) who were using graphics mode 1 on the MC-1000 must now change it to 33, otherwise the screen will be green all the time and flickering while doing graphics output.
I'm not sure what the flicker Is about to be honest: Mame indicates that graphic emulation isn't 100% complete, so it may be that.