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.

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

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

I highly recommend it

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.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

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.

_________________
Regards, KM
https://github.com/floobydust

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

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

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.)

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

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.

_________________
Regards, KM
https://github.com/floobydust

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

_________________
Please visit my website -> https://sbc.rictor.org/

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

_________________
Please visit my website -> https://sbc.rictor.org/

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.

_________________
Regards, KM
https://github.com/floobydust

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!