luckybuck Posted September 24, 2019 Share Posted September 24, 2019 Just the cart, just for you... Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted September 24, 2019 Share Posted September 24, 2019 wonders how litedos will get on with the cart, probably not well... Quote Link to comment Share on other sites More sharing options...
luckybuck Posted September 24, 2019 Share Posted September 24, 2019 Even a few bytes more... MAC65-3.6on130XE Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted September 24, 2019 Share Posted September 24, 2019 Lots of free symbol space on a 130XE running SpartaDOS X as well: Advantage here is that you can actually save and load files. 1 Quote Link to comment Share on other sites More sharing options...
luckybuck Posted September 24, 2019 Share Posted September 24, 2019 (edited) ? 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 Quote Link to comment Share on other sites More sharing options...
sanny Posted September 24, 2019 Share Posted September 24, 2019 (edited) 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 Quote Link to comment Share on other sites More sharing options...
Alfred Posted September 25, 2019 Author Share Posted September 25, 2019 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. Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted September 25, 2019 Share Posted September 25, 2019 (edited) 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__ Quote Link to comment Share on other sites More sharing options...
Alfred Posted September 25, 2019 Author Share Posted September 25, 2019 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. 1 Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted September 25, 2019 Share Posted September 25, 2019 They probably wouldn't notice unless they read it in the documentation. Quote Link to comment Share on other sites More sharing options...
Alfred Posted September 25, 2019 Author Share Posted September 25, 2019 (edited) 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 1 Quote Link to comment Share on other sites More sharing options...
thorfdbg Posted September 25, 2019 Share Posted September 25, 2019 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. Quote Link to comment Share on other sites More sharing options...
phaeron Posted September 25, 2019 Share Posted September 25, 2019 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. 1 Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted September 25, 2019 Share Posted September 25, 2019 (edited) 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__ Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted September 25, 2019 Share Posted September 25, 2019 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. Quote Link to comment Share on other sites More sharing options...
Alfred Posted September 25, 2019 Author Share Posted September 25, 2019 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: 2 Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted September 25, 2019 Share Posted September 25, 2019 (edited) and it is best to treat it as such... even if you are given grief for it. Edited September 25, 2019 by _The Doctor__ Quote Link to comment Share on other sites More sharing options...
Alfred Posted September 25, 2019 Author Share Posted September 25, 2019 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. 2 Quote Link to comment Share on other sites More sharing options...
sanny Posted September 25, 2019 Share Posted September 25, 2019 Where can I get these WDC assemblers? Quote Link to comment Share on other sites More sharing options...
sanny Posted September 25, 2019 Share Posted September 25, 2019 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. 1 Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted September 25, 2019 Share Posted September 25, 2019 (edited) 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__ Quote Link to comment Share on other sites More sharing options...
luckybuck Posted September 25, 2019 Share Posted September 25, 2019 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. Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted September 25, 2019 Share Posted September 25, 2019 (edited) 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__ 1 Quote Link to comment Share on other sites More sharing options...
Alfred Posted September 25, 2019 Author Share Posted September 25, 2019 (edited) 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 1 Quote Link to comment Share on other sites More sharing options...
luckybuck Posted September 26, 2019 Share Posted September 26, 2019 Well, this link: http://westerndesigncenter.com/wdc/WDCTools/tide.exe worked for me... But thank you for: https://wdc65xx.com/WDCTools Incredible good! ? Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.