WDC ProSDK via 65XX.com

[potatohead]

On Windows, many network cards will accept a user defined MAC address. Broadcom is one that often doesn't. If it were me, I would check for this. Look in the device properties for "network address" or "locally administered address" fields. They take a mac as 12 Hex digits. If yours will change, great! If not, buy something that will, then get your license and feel no worries about moving to another machine.

I think this is a pretty good deal BTW.

[pebmeister]

I use 64tass macro assembler for free and its open source

http://sourceforge.net/projects/tass64/

I highly recommend it

[White Flame]

64tass claims it's an "optimizing" assembler. That's a pretty strange claim; it seems to simply do straightforward 1-to-1 assembly like the rest.

[floobydust]

I seem to have found a bug in WDC's Pro-SDK 65C02 assembler. When using a BRK instruction, the assembler always generates two bytes of hex "00" instead of one. I've contacted WDC and sent them some sample code as well. I stumbled across this when taking Daryl's SBC2OS code and modifying it to assemble under WDC's ProSDK as an exercise. I noticed the code was larger and some fixed addresses were no longer in place. After going thru the listing file, I found the double byte BRK instructions. So far, no feedback from WDC... guess I'll send them a follow-up note and see if they have any insight on this.

[Dr Jefyll]

It's actually not a bug. BRK is a two-byte instruction -- check the data sheet. Although the chip itself disregards the 2nd byte, it may have significance for software (the BRK handler).

See That BRK instruction...

cheers.
Jeff

[GARTHWILSON]

Still, I would expect it to let you choose what the signature byte will be. If you have more than one BRK, does the signature byte automatically increment? (Actually that doesn't sound like a good solution either. It needs to be user-setable.)

[floobydust]

Yes, adds some level of confusion and makes some code work on some assemblers and not others (I've not found an option to allow me to change it). Oddly, the old Vic20 programmers guide states that the BRK instruction is 1 byte (no operand). Also, sample code listings in an old book (6502 applications by Rodney Zaks) shows a single "00" opcode and no operand. IIRC my old Commodore 64 Macro Assembler also generates a single "00" for the BRK instruction, hence my initial confusion.

[8BIT]

WDC posted this on Facebook yesterday,

"New Version of 65xxTools now available! We have noticed that many did not like our MAC address protected version so of 65xxTools so we have decided to eliminate this barrier. Enjoy!!"

[8BIT]

I went ahead and purchased this tool kit. It was quick and easy and no issues with MAC address or any other verification. There is a field on the order form for a MAC address but it is optional - just leave it blank. I will play around with it when I get time. I'm interested to see if the C compiler can make a smaller executable of the uIP code.

Daryl

[floobydust]

Daryl,

Just saw that as well... I'll probably send them an email asking if I can get the updated version. I'd also be interested in any feedback you have on their SDK. I worked with WDC earlier this year as I'm the guy running it under Fusion on OSX with Win7 X64. They had to do some changes on their license key, but it had to be a Win7 64-bit issue, not a Fusion issue. Thanks for the update.

[BigDumbDinosaur]

Dr Jefyll wrote:

It's actually not a bug. BRK is a two-byte instruction -- check the data sheet. Although the chip itself disregards the 2nd byte, it may have significance for software (the BRK handler).

See That BRK instruction...

"Tradition," however, has most assemblers treating BRK as not taking an operand. The very first 6502 assembler I used (some 35 years ago) did not allow an operand to be part of a BRK instruction. I use a macro to add an operand (signature byte) if I want one.

I may be repeating myself, but the 65C816's COP instruction, which is also a software interrupt like BRK, does require an operand.

Speaking of COP, during one of my more recent patches to POC V1.1's BIOS ROM, I rigged up the M/L monitor so that a COP instruction could be used as an alternative to BRK if so desired. It was a "strictly for grins" modification that would fetch the signature byte, change it to ASCII and display it as part of the diagnostic that indicated that a software interrupt had been executed. The current ROM no longer has that dubious feature, but COP will cause the same effect as BRK if the system vectors aren't disturbed.