[Coco] VCC possible bug in 6309 & 6809 emulation and general Wally news!

Mon Jun 11 01:42:30 EDT 2018

I have some draft update code which works but as I mentioned it only appears to work as nothing exercises it (fully)!

I include it here:

Keep in mind in the 2.01B VCC the 6309 instructions all live in one large switch statement.  In my version all instructions live in their own function.  That said it will be easy to find the code to substitute:

Also this experimental fix does not take into consideration the situation when then 6309 is running in native mode (6809 mode) because the EXG instruction behaves differently again.

void Exg_M_OLD(void)
{ //1E

	postbyte=MemRead8(PC_REG++);
	Source= postbyte>>4;
	Dest=postbyte & 15;

	ccbits=getcc();
	if ( ((postbyte & 0x80)>>4)==(postbyte & 0x08)) //Verify like size registers
	{
		if (postbyte & 0x08) //8 bit EXG
		{
			temp8= (*ureg8[((postbyte & 0x70) >> 4)]); //
			(*ureg8[((postbyte & 0x70) >> 4)]) = (*ureg8[postbyte & 0x07]);
			(*ureg8[postbyte & 0x07])=temp8;
		}
		else // 16 bit EXG
		{
			temp16=(*xfreg16[((postbyte & 0x70) >> 4)]);
			(*xfreg16[((postbyte & 0x70) >> 4)])=(*xfreg16[postbyte & 0x07]);
			(*xfreg16[postbyte & 0x07])=temp16;
		}
	}
	setcc(ccbits);
	CycleCounter+=InsCycles[md[NATIVE6309]][M85];
}

void Exg_M(void)
{ //1E
	postbyte = MemRead8(PC_REG++);
	Source = postbyte >> 4;
	Dest = postbyte & 15;

	ccbits = getcc();
	if ((Source & 0x08) == (Dest & 0x08)) //Verify like size registers
	{
		if (Dest & 0x08) //8 bit EXG
		{
			Source &= 0x07;
			Dest &= 0x07;
			temp8 = (*ureg8[Source]);
			(*ureg8[Source]) = (*ureg8[Dest]);
			(*ureg8[Dest]) = temp8;
			O_REG = 0; //re-zero the zero register
		}
		else // 16 bit EXG
		{
			Source &= 0x07;
			Dest &= 0x07;
			temp16 = (*xfreg16[Source]);
			(*xfreg16[Source]) = (*xfreg16[Dest]);
			(*xfreg16[Dest]) = temp16;
		}
	}
	else
	{
		if (Dest & 0x08) // Swap 16 to 8 bit exchange to be 8 to 16 bit exchange (for convenience)
		{
			temp8 = Dest; Dest = Source; Source = temp8;
		}

		Source &= 0x07;
		Dest &= 0x07;

		switch (Source)
		{
		case 0x04: // Z
		case 0x05: // Z
			(*xfreg16[Dest]) = 0; // Source is Zero reg. Just zero the Destination.
			break;
		case 0x00: // A
		case 0x03: // DP
		case 0x06: // E
			temp8 = *ureg8[Source];
			temp16 = (temp8 << 8) | temp8;
			(*ureg8[Source]) = (*xfreg16[Dest]) >> 8; // A, DP, E get high byte of 16 bit Dest
			(*xfreg16[Dest]) = temp16; // Place 8 bit source in both halves of 16 bit Dest
			break;
		case 0x01: // B
		case 0x02: // CC
		case 0x07: // F
			temp8 = *ureg8[Source];
			temp16 = (temp8 << 8) | temp8;
			(*ureg8[Source]) = (*xfreg16[Dest]) & 0xFF; // B, CC, F get low byte of 16 bit Dest
			(*xfreg16[Dest]) = temp16; // Place 8 bit source in both halves of 16 bit Dest
			break;
		}
	}
	setcc(ccbits);
	CycleCounter += InsCycles[md[NATIVE6309]][M85];
}

-----Original Message-----
From: Coco [mailto:coco-bounces at maltedmedia.com] On Behalf Of Bill Pierce via Coco
Sent: Monday, 11 June 2018 11:28 AM
To: coco at maltedmedia.com
Cc: Bill Pierce <ooogalapasooo at aol.com>
Subject: Re: [Coco] VCC possible bug in 6309 & 6809 emulation and general Wally news!

Good catch Walter. I forwarded your post to the person working on the next release which will feature Windows, Mac and possibly Linux versions. It's still a work in progress, but coming along nicely.
Anything you find, please post it so it will be looked at :-)

Thanks again :-)

Bill Pierce
"Charlie stole the handle, and the train it won't stop going, no way to slow down!" - Ian Anderson - Jethro Tull

My Music from the Tandy/Radio Shack Color Computer 2 & 3 https://sites.google.com/site/dabarnstudio/
Co-Contributor, Co-Editor for CocoPedia
http://www.cocopedia.com/wiki/index.php/Main_Page

E-Mail: ooogalapasooo at aol.com

-----Original Message-----
From: Walter Zambotti <zambotti at iinet.net.au>
To: coco <coco at maltedmedia.com>
Sent: Sun, Jun 10, 2018 9:46 pm
Subject: [Coco] VCC possible bug in 6309 & 6809 emulation and general Wally news!

Hi guys (and any girls) I have been working on improving the performance of the VCC emulator andhave found a possible bug in the 6309 and 6809 implementation. The Exg_M instruction has two issues: 1.       According to the 6x09_instruction_sets manual (pdf) the EXG (6309)instruction allows exchanges of dissimilar sized registers (ie 8 to 16 bit).The current implementation only appears to support exchanges of similarsized registers and ignores all dissimilar size exchanges.2.       The current implementation allows exchanges with the Z (zero)register (which it should) but fails to zero the zero register afterwards.In other words it allows the zero register to contain values other thanzero. Similarly the 6809 also allows dissimilar exchanges which the currentimplementation does not perform. There is no zero register on the 6809 sothis is not an issue.This has probably not raised itself as an issue so far because of the rarityof doing such things. Testing any changes to the current implementation of EXG will requirespecific assembly code to test the dissimilar exchanges and zero registerexchanges as I don't believe any code out there to date has ever exercisedthis peculiar functionality. In case you are wondering what I've been doing. I have been rewriting the6309 emulator in x.86 assembler. The performance improvements of theinstructions I have so far converted are significant.  I have written (WIP)a cpu verification suite that runs two CPU emulators in parallel andcompares all results after each instruction. I have also revisited the mmu hardware acceleration modification that Ibegan looking at last year.  The last time I tested this on windows Idiscovered 2 limitations.  Windows either has a 64K page size or a 4k pagesize that does not allow sharing.  I have subsequently discovered that theintel mmu hardware is not the issue and the issue is restricted to theWindows OS as Linux does not suffer from this restriction.  I havesuccessfully created a test hardware accelerated CoCo MMU under linux.  Ofcourse porting the rest of VCC to native Linux is a major issue. Microsoft have announced .Net Core 3 will provide WPF so when this makes itacross to Visual Studio Code a port of VCC to VSC will be difficult butpossible. The other interesting thing I have discovered is the LEON FPGA CPU project.It provides state of the art CPU architecture mechanisms such as advancedpipelining and caching and SMP support for a SPARC CPU.  The interestingthing is some universities use it as a base for implementing the 68008 CPU.I would like to learn enough about FPGA programming to use the LEON base toimplement a 32 bit multicore 6309. I thought I would bring the LEON project to the other FPGA'rs attention. Keep on Coco'n Walter-- Coco mailing listCoco at maltedmedia.comhttps://pairlist5.pair.net/mailman/listinfo/coco

--
Coco mailing list
Coco at maltedmedia.com
https://pairlist5.pair.net/mailman/listinfo/coco