Jump to content







Photo

Take 3

Posted by SpiceWare, in Medieval Mayhem 06 March 2007 · 128 views

I ran the lst file thru batari's ZP/immediate load auditor and found a few ZP accesses that were supposed to be immediate mode.

One of the issues was with the lda ATTRACT_DELAY instead of lda #ATTRACT_DELAY, which probably explains jetset's issue on his 7800.

The other was cmp SoundKingTest which should have been cmp #SoundKingTest. This compare only determines weither or not to start a new sound effect, so I don't see it causing the problems Nathan or my cart had.

I'd appreciate any feedback before I send them to Al so I can make sure the fix didn't screw something else up.

Attached Files






The previous final build worked fine on my Krok Cart, so I don't know what I'd be looking for here. The problem I had, I would assume, was specific to that particular cart.
  • Report
Too bad about the bugs, but regardless it's good to hear that my utility did its job...

Nathan Strum, on Tue Mar 6, 2007 8:50 PM, said:

The previous final build worked fine on my Krok Cart, so I don't know what I'd be looking for here. The problem I had, I would assume, was specific to that particular cart.
It could be specific to the cart, but it could be due to the bugs as well, i.e. the electrical characteristics of that particular EPROM could pull a data line low or high just enough to alter the values with a zero page load when an immediate was intended.
  • Report

Nathan Strum, on Tue Mar 6, 2007 7:50 PM, said:

The previous final build worked fine on my Krok Cart, so I don't know what I'd be looking for here. The problem I had, I would assume, was specific to that particular cart.

Possibly specific to the EEPROM - I tested 9 other Medieval Mayhem carts from Al in my 2600, and they all worked OK(well, 4 of them had the "jitter bug", but no weird crashes). I just wanted some people to test it to make sure my fix didn't break something - I've had that happen before :)

batari, on Tue Mar 6, 2007 8:24 PM, said:

Too bad about the bugs, but regardless it's good to hear that my utility did its job...

Great utility, just a month too late for my release :) What's your utility written it? I'd like to recompile for OS X if possible. I transferred the LST file from my iMac G5 to my MacBook to check under XP(via Parallels).
  • Report
EDIT: code modified to remove some false positives.

SpiceWare, on Tue Mar 6, 2007 10:06 PM, said:

Nathan Strum, on Tue Mar 6, 2007 7:50 PM, said:

The previous final build worked fine on my Krok Cart, so I don't know what I'd be looking for here. The problem I had, I would assume, was specific to that particular cart.

Possibly specific to the EEPROM - I tested 9 other Medieval Mayhem carts from Al in my 2600, and they all worked OK(well, 4 of them had the "jitter bug", but no weird crashes). I just wanted some people to test it to make sure my fix didn't break something - I've had that happen before :)

batari, on Tue Mar 6, 2007 8:24 PM, said:

Too bad about the bugs, but regardless it's good to hear that my utility did its job...

Great utility, just a month too late for my release :) What's your utility written it? I'd like to recompile for OS X if possible. I transferred the LST file from my iMac G5 to my MacBook to check under XP(via Parallels).
Written in C, so you should have no trouble compiling. Here's the source - don't laugh, it's messy but it works.
#include <stdlib.h>
#include <stdio.h>
#include <string.h>

int hextoi(char a, char b)
{
  int val1,val2;
  if (!((a>='0' && a<='9') || (a>='a' && a<='f') || (a>='A' && a<='F'))) return 255;
  if (!((b>='0' && b<='9') || (b>='a' && b<='f') || (b>='A' && b<='F'))) return 255;
  val1=(int)a-48;
  if (val1>30) val1=val1-32;
  if (val1>9) val1=val1-7;
  val2=(int)b-48;
  if (val2>30) val2=val2-32;
  if (val2>9) b=val2-7;
  return val1*16+val2;
}

main(){
char opcode[2];
char operand[2];
int hexopcode;
int hexoperand;
char label[10];
char mnemonic[10];
char data[100];
int i;
// opcodes:
// 24,a4,c4,e4,05,25,45,65,a5,c5,e5,a6,a7
int list[13]={0x24,0xa4,0xc4,0xe4,0x05,0x25,0x45,0x65,0xa5,0xc5,0xe5,0xa6,0xa7};
	  while (1) {
		if (!fgets(data,100,stdin)){
		  fprintf(stderr,"Done.\n");
		  exit(0);
		}
	   if (data[28]>='0') continue;
	   opcode[0]=data[22];
	   opcode[1]=data[23];
	   operand[0]=data[25];
	   operand[1]=data[26];
	   hexopcode=hextoi(opcode[0],opcode[1]);
	   hexoperand=hextoi(operand[0],operand[1]);
	   if (!((hexoperand>=0) && (hexoperand < 128))) continue;
	   for (i=0;i<10;++i) {label[i]='\0';mnemonic[i]='\0';}
	   for (i=39;i<48;++i) label[i-39]=data[i];
	   for (i=36;i<40;++i) 
	   {
		  if (data[36]=='.') mnemonic[i-36]=data[i+1];
		  else if (data[35]=='b') mnemonic[i-36]=data[i-1];
		  else if (data[35]=='w') mnemonic[i-36]=data[i-1];
		  else mnemonic[i-36]=data[i];
	   }

  for (i=0;i<13;++i)
  {
	if (hexopcode == list[i])
	{
	   if (strncmp(label,"CX\0",2) && strncmp(label,"INPT\0",4) && strncmp(mnemonic,"wor\0",3) && strncmp(mnemonic,"byt\0",3))
		 printf("%s\n",data);
	}
  }

  }
}
  • Report
Fred, have you considered forwarding the tool to Andrew Davie, so he can add it to the DASM homepage? I'm sure it'd be interesting for every DASM developer to have :)
  • Report

Cybergoth, on Wed Mar 7, 2007 10:14 AM, said:

Fred, have you considered forwarding the tool to Andrew Davie, so he can add it to the DASM homepage? I'm sure it'd be interesting for every DASM developer to have :)
Except me. :)

I make a ton of mistakes while coding but never ever this one. I don't know why, maybe the pattern has been permanently burned into my subconscious? :)

Anyway, the tools sounds great.
  • Report

Cybergoth, on Wed Mar 7, 2007 4:14 AM, said:

Fred, have you considered forwarding the tool to Andrew Davie, so he can add it to the DASM homepage? I'm sure it'd be interesting for every DASM developer to have :)
I might do that. Also, I think I found a way to remove the false positives from the results. I'll build a new version and update my blog entry in a bit.
  • Report

batari, on Wed Mar 7, 2007 10:59 PM, said:

Also, I think I found a way to remove the false positives from the results.

It seems as if

1. Checking the values wether they're *really* a hexnumber
=> (a>='0' && a<='9') || (a>='a' && a<='z') || (a>='A' && a<='Z')

2. Excluding "word" and "byte" additionally to "CX" and "INPT"

should get rid of most false positives I've seen so far :)
  • Report

Cybergoth, on Wed Mar 7, 2007 5:17 PM, said:

batari, on Wed Mar 7, 2007 10:59 PM, said:

Also, I think I found a way to remove the false positives from the results.

It seems as if

1. Checking the values wether they're *really* a hexnumber
=> (a>='0' && a<='9') || (a>='a' && a<='z') || (a>='A' && a<='Z')

2. Excluding "word" and "byte" additionally to "CX" and "INPT"

should get rid of most false positives I've seen so far :)
Done.

Will update the blog entry in a moment.
  • Report

batari, on Thu Mar 8, 2007 12:43 AM, said:

Done.

Will update the blog entry in a moment.

Thanks, I'll try it tonight!

(BTW: The hexranges need only be A-F, not A-Z as I posted :))
  • Report
Uh... Oh... I know I'm a pest...

Maybe it should do the same hexchecks with 'b' as well and maybe it needs to be ".wor" and ".byt"?
  • Report

Cybergoth, on Thu Mar 8, 2007 4:01 AM, said:

Uh... Oh... I know I'm a pest...

Maybe it should do the same hexchecks with 'b' as well and maybe it needs to be ".wor" and ".byt"?
Since the dot is optional in dasm, it actually checks both. But I should modify the a-z thing. Source above updated, hopefully for the last time :)
  • Report

May 2012

S M T W T F S
  12345
6789101112
13141516171819
20 21 2223242526
2728293031  

Recent Entries

Recent Comments

0 user(s) viewing

0 members, 0 guests, 0 anonymous users

Search My Blog

Latest Visitors