CCE MC-1000 tests

Discussion about other targets
stefano
Well known member
Posts: 2137
Joined: Mon Jul 16, 2007 7:39 pm

Post by stefano »

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 :D )

As soon as you think the demo programs run good enough, feel free to publish their port in your MC-1000 forum.
ensjo
Member
Posts: 15
Joined: Sat Mar 09, 2013 2:14 pm

Post by ensjo »

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:

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
[?]
2) In libsrc/games/mc1000/bit_open.asm, snd_tick should be initialized with zero instead of 8 (include a XOR A command):

Code: Select all

[?]
    ld    a,8 ; Select amplitude register for channel A.
    out    ($20),a
    xor    a ; Clear tick tracker.
    ld                (snd_tick),a
[?]
I will send you some sound samples by e-mail. :)
stefano
Well known member
Posts: 2137
Joined: Mon Jul 16, 2007 7:39 pm

Post by stefano »

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 ?
ensjo
Member
Posts: 15
Joined: Sat Mar 09, 2013 2:14 pm

Post by ensjo »

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.
The <RUBOUT> key produces 127 (ASCII control character "DEL") in "BASIC mode", and 93 ("]") in "game mode".
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 ?
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:
http://www.facebook.com/photo.php?fbid= ... =1&theater
I made a little progress: GET FLINT? USE FLINT? GET ROPE? USE ROPE? :-)
stefano
Well known member
Posts: 2137
Joined: Mon Jul 16, 2007 7:39 pm

Post by stefano »

Wow !
You went so far.. I'm impressed we got all this stuff working :)

This should mean that the graphics swap trick works perfectly.
I still have to fix bksave() and bkrestore(), then probably all the existing base graphics functions are covered.
User avatar
RobertK
Well known member
Posts: 347
Joined: Mon Feb 26, 2018 12:58 pm

Re: CCE MC-1000 tests

Post by RobertK »

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.

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();
}
User avatar
dom
Well known member
Posts: 2076
Joined: Sun Jul 15, 2007 10:01 pm

Re: CCE MC-1000 tests

Post by dom »

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.
User avatar
RobertK
Well known member
Posts: 347
Joined: Mon Feb 26, 2018 12:58 pm

Re: CCE MC-1000 tests

Post by RobertK »

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...
User avatar
dom
Well known member
Posts: 2076
Joined: Sun Jul 15, 2007 10:01 pm

Re: CCE MC-1000 tests

Post by dom »

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.
User avatar
RobertK
Well known member
Posts: 347
Joined: Mon Feb 26, 2018 12:58 pm

Re: CCE MC-1000 tests

Post by RobertK »

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.
User avatar
dom
Well known member
Posts: 2076
Joined: Sun Jul 15, 2007 10:01 pm

Re: CCE MC-1000 tests

Post by dom »

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 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!

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.
Post Reply