Six Forks Assembler Upgrades

[luckybuck]

Just the cart, just for you...

[_The Doctor__]

wonders how litedos will get on with the cart, probably not well...

[luckybuck]

Even a few bytes more...

MAC65-3.6on130XE

 

 

[flashjazzcat]

Lots of free symbol space on a 130XE running SpartaDOS X as well:

 

 

Advantage here is that you can actually save and load files.

[luckybuck]

?

 

Just looked, whether, the 3.6 version took advantage of the additional RAM...

 

130XE Makro Assembler will be tested for this, too.

Edited September 24, 2019 by luckybuck

[sanny]

16 hours ago, flashjazzcat said:

Every Atari 6502 assembler treats BRK as a 1-byte instruction, AFAIK. There should be no need to test them all.

Even if the opcode sets "addr + 2" as return address from the interrupt, any system I know treats it as a 1-byte opcode. The IRQ handler returns to the address of the BRK + 1.

And, for a two-byte opcode, the correct syntax in the assembly source would be

 

   brk #num

 

instead of just

 

   brk

 

Wouldn't it?

 

regards,

chris

Edited September 24, 2019 by sanny

[Alfred]

1 hour ago, sanny said:

Even if the opcode sets "addr + 2" as return address from the interrupt, any system I know treats it as a 1-byte opcode. The IRQ handler returns to the address of the BRK + 1.

And, for a two-byte opcode, the correct syntax in the assembly source would be

 

   brk #num

 

instead of just

 

   brk

 

Wouldn't it?

 

regards,

chris

 

That might be why everybody treats it as a one byte instruction, if the OS IRQ handler does a return to BRK+1. I've never used BRK, never looked into what the OS does.

 

As for the syntax, it's not really clear. It could be #n, or it could just be BRK nn  the syntax options would be up to the assembler's author. WDC says the second byte is optional, so a proper implementation would allow you to just specify BRK with nothing, and would emit bytes as say $80$00. My guess was that was why everybody treats it as a one byte, because it complicates processing the instructions. No other mnemonic has an optional part like BRK on the 6502, (that I can think of anyway) and even on the 65816 COP is the only other one that has an optional second byte. So rather than special case handling BRK everyone just chose to treat it as a one byte instruction and let the programmers fix it themselves, thinking that hardly anyone was going to use BRK anyway, outside of debuggers.

 

MVN/MVP are a bit wonky too, WDC allows different syntax like MVN #2,#3 or just MVN 2,3. I don't think I'm going to allow use of the # it will just be MVP 4,0 style because the # will make the code check for ACC or IND widths, which means special casing MVN/MVP. So best just to treat it like an absolute zero page reference and then it doesn't need (much) special handling. It's a nuisance in Six Forks because it means there could be two possible virtual references, which means it needs it's own special relocatable opcode just for that one instruction along with special modifiers for both operands. They'll be the last 65816 codes I'll implement because it'll be such a headache.

 

 

 

[_The Doctor__]

but will it be wise to have the break handled as Alfred proposes in light of different upgrades likes 65816 etc and OS enhancements that roll down the pike... just because we can get away with a thing doesn't mean you should do so... it might make it easier to do rather than remembering what you did and how it will turn out... (that's my reasoning behind it).

Look at all the software that used illegal opcodes that didn't need to, the instructions were expanded to legal ones in the fix and the software ran anyway... but it sure makes it a pain to use and upgraded machine... same things with not using the registers outlined by Atari, later on it broke some of the simplest software because people accessed where they shouldn't have.

If it doesn't hurt and only helps going forward why not do it the way your sure it will be the most compatible...

*edit* I see Alfred has already weighed in.

Edited September 25, 2019 by _The Doctor__

[Alfred]

Just now, _The Doctor__ said:

but will it be wise to have the break handled as Alfred proposes in light of different upgrades likes 65816 etc and OS enhancements that roll down the pike... just because we can get away with a thing doesn't mean you should do so... it might make it easier to do rather than remembering what you did and how it will turn out... (that's my reasoning behind it)

The problem is (as the book points out) if someone implements an IRQ handler that just defaults to RTI, then any code that uses BRK (which is probably zero) generated by an Atari assembler would always crash. Chances of that situation occurring ? Probably zero with 6502 OSes. Down the road with some new 65816 thing ? Who knows, still probably close to zero, although COP might be a slightly bigger issue. Still, I guess if I change Six Forks to treat BRK and COP as two byte instructions, that'll give everybody a reason not to use it, haha.

[_The Doctor__]

They probably wouldn't notice unless they read it in the documentation.

[Alfred]

Just checked the DataQue T-816 OS source. In native mode, BRK and COP just RTI, so if you left off the option byte your code would crash. In 6502 mode, it looks like it exits via PLA RTI, so again your code would crash if you didn't pad the BRK instruction. Not a big deal in practical terms, but it still annoys me as an example of sloppy programming by the various assembler authors.

Edited September 25, 2019 by Alfred

[thorfdbg]

4 hours ago, Alfred said:

 

That might be why everybody treats it as a one byte instruction, if the OS IRQ handler does a return to BRK+1. I've never used BRK, never looked into what the OS does.

 

Actually, the Atari Os does not. If there is no dedicated handler for BRK, the code just runs into an RTI, and the RTI returns (of course) to the address of the BRK instruction + 2. No surprises at all.

 

The only reason why it is usually understood to be a 1-byte instruction is because the official 6502 docs document it as a 1-byte instruction, and assemblers just copied this convention. What a BRK handler does about it is of course completely of its own. It could use the byte, adjust the return address or do anything else it considers fit.

[phaeron]

Unlike BRK, COP is specified as a two byte instruction with a one byte argument in 65816 literature and in the recommended assembly syntax. The 65C816 XL OS uses it for system calls and interprets it as such in the default interrupt handler.

 

Besides being non-standard, treating BRK as a two byte instruction has an undesirable side effect on disassembly. It is extremely common to have code following blocks of $00 bytes, and a two-byte BRK gives a 50/50 chance of bad disassembly leading into the valid code. This of course doesn't directly affect the assembler, but normally you'd want the two to match.

 

[_The Doctor__]

The 6502 and the 65C02 do not have dedicated BRK vectors and reuse the IRQ vector for it. Sharing of the same vector is where issues with the NMOS 6502 occurs, an interrupt arriving at the right time can take over a BRK instruction sequence. This can cause the BRK to be lost or make it possibly more difficult to distinguish. The CMOS 65C02 version prevents the interrupt from overlapping the BRK instruction and the BRK is guaranteed to execute separately from interrupts. It's slightly less costly but still expensive to separate BRK cleanly on the CMOS 65C02 and is the reason why the 65C816 added an entirely separate BRK vector

 

as to the dis-assembler, perhaps that should be modified to handle things correctly... or and option to do so added. should be interesting to try since people pad it anyway... how will it be different...

Edited September 25, 2019 by _The Doctor__

[flashjazzcat]

11 hours ago, sanny said:

And, for a two-byte opcode, the correct syntax in the assembly source would be

 

   brk #num

 

instead of just

 

   brk

 

Wouldn't it?

Are you asking me, or telling me? I'm pointing out that every 6502 assembler I know of implements BRK as a 1-byte opcode, and that the fact it is handled as such in MAC/65 is not a bug: it's completely standard practice, for better or worse. I once attempted to use BRK as a system call mechanism and simply wrote a macro to place an argument in a .BYTE directive immediately after the BRK instruction. Native support for 'BRK #val' might be nice, but it's hardly essential. I eventually abandoned the idea of using BRK for kernel entry anyway, since there are two significant interrupt bugs on the 6502C which - although they can be coded around - make using BRK as a syscall pretty inefficient.

[Alfred]

So I went to the WDC site to see what they say. The 6502 datasheet says nothing, but the 65816 sheet says :

 

7.22
BRK Instruction
The BRK instruction for the NMOS  6502, 65C02 and 65C816  is actually  a 2 byte instruction.  The NMOS
device simply skips the second byte (i.e. doesn’t care about the second byte) by incrementing the program
counter twice.  The 65C02 and 65C816 does the same thing except the assembler is looking for the second
byte  as  a  “signature  byte”.    With  either  device  (NMOS  or  CMOS),  the  second  byte  is  not  used.    It  is
important  to  realize  that  if  a  return  from  interrupt  is  used  it  will  return  to  the  location  after  the  second  or
signature byte.

 

Well that's fine, but what does WDC do ? I ran a test through the WDC 65816 assembler, and lo, BRK is treated as a two byte instruction, where the second byte is optional, like COP:

 

 

 

 

 

[_The Doctor__]

and it is best to treat it as such... even if you are given grief for it.

Edited September 25, 2019 by _The Doctor__

[Alfred]

The WDC 6502 assembler also treats BRK as a two byte instruction. I thought to check it after I posted, thinking maybe it behaved differently than the 65816 version, but it does not.

[sanny]

Where can I get these WDC assemblers?

[sanny]

2 hours ago, flashjazzcat said:

Are you asking me, or telling me? I'm pointing out that every 6502 assembler I know of implements BRK as a 1-byte opcode, and that the fact it is handled as such in MAC/65 is not a bug: it's completely standard practice, for better or worse.

No to you specifically, just wanted to point that out.

And it appears the WDC assembler does it "correctly", but all other assemblers I know treat BRK as a 1-byte instruction.

[_The Doctor__]

just make a simple proggy with brk followed by a throw away byte other than 00  such as EA, so brk nop. see how that will fare... I think it will run just fine if done using wdc or six forks as you intend to support it. I wonder how many disassemblers will take issue with such.

 perhaps the assembler accepts BRK as either an implied instruction (no operands) or an immediate instruction with an 8-bit literal operand. giving the same results... by choosing something benign in the signature byte... if there were some interrupt issue perhaps that's a safe choice in that picking up what comes after a possible skipped brk will have no undesired outcome..

Edited September 25, 2019 by _The Doctor__

[luckybuck]

Well, I am not an expert, but Carsten wrote me:

https://en.wikipedia.org/wiki/SWEET16

Woz had this in 1977...

 

From 1978 Rodnay Zaks:

 

 

Just loud thinking:

 

the 6502 was from MOS, but the W65C02 from Western Design Center (WDC).

 

https://de.wikipedia.org/wiki/MOS_Technology_6502#Abgeleitete_Designs

sadly, not in English.

 

 

[_The Doctor__]

took a little searching...

 

http://forum.6502.org/viewtopic.php?t=1917

 

and

 

http://visual6502.org/wiki/index.php?title=6502_BRK_and_B_bit

 

mind you on the Atari we can turn things on and off that will affect how the BRK behaves...

 

between those two sites you will find what applies to this misunderstood instruction/ well sort of :)...

Edited September 25, 2019 by _The Doctor__

[Alfred]

8 hours ago, sanny said:

Where can I get these WDC assemblers?

 

https://wdc65xx.com/WDCTools

 

I see they removed TIDE which was a crap IDE that I never could get work. I had to sign an NDA many years ago to get the tools, but now that nobody uses them, they give them away, haha.

 

Edit: Also had to pay I think $40 for the tools back then.

Edited September 25, 2019 by Alfred

[luckybuck]

Well, this link:

http://westerndesigncenter.com/wdc/WDCTools/tide.exe

worked for me...

 

But thank you for:

https://wdc65xx.com/WDCTools

 

Incredible good! ?