JesperGravgaard Posted December 3, 2020 Share Posted December 3, 2020 12 hours ago, fenrock said: Oh and doing the AOC challenge now it's December I just had a go at https://adventofcode.com/ . That looks like a lot of fun! I solved the first challenges in KickC running on Atari 8bit 2 Quote Link to comment Share on other sites More sharing options...
fenrock Posted December 4, 2020 Share Posted December 4, 2020 9 hours ago, JesperGravgaard said: I just had a go at https://adventofcode.com/ . That looks like a lot of fun! I solved the first challenges in KickC running on Atari 8bit Nice!! I was tempted to do the same for the entire advent, but the puzzles get extremely hard, and I need my testing framework, and some solutions require very large numbers (last year's day 12 part 2 solution was "303070460651184", so would need 40 bit integers at least. Also we have a work leader board. There's 27 of us, and I'm currently 2nd, and want to get solutions fast I'm that competitive sadly. My code is at https://github.com/markjfisher/advent-of-code/tree/master/advents/src/main/kotlin/net/fish/y2020 if you fancy getting tempted by Kotlin over Java 2 Quote Link to comment Share on other sites More sharing options...
Dmitry Posted December 16, 2020 Author Share Posted December 16, 2020 A few questions or maybe comments, well, lets call them questions. 1. What's wrong with this code: if ((AF1 ==0 || AF1 > 56) && (AF2 ==0 || AF2 > 56) && (AF3 ==0 || AF3 > 56) && (AF4 ==0 || AF4 > 56)) { asm { handdown: ldx #$01 //throw down hand stx $6BCB stx $6BCC ldx #$0 stx $6BC9 stx $6BCA ldx #$60 stx $6FCD //draw balloon ldx #$F0 stx $6FCE stx $6FCF stx $6FD0 } } What that looks like in the asm file is: ldx.z AF1 ldy.z AF2 tya sta.z __261 txa cmp #0 bne !__b99+ jmp __b99 !__b99: cpx #$38+1 bcc !__b99+ jmp __b99 If that looks impossibly small, well it is. It just doesn't contain my asm section labelled handdown anywhere in the file and also the program is borked. However, if I, replace that whole if statement, with this, now entirely hand coded in assembler, it works fine: asm { //if no ballons af frame >0 and <56 then hand should go down, but doesn't check if hand already down. lda #0 sta FLAG AF1CHK: lda AF1 cmp #57 bcs AF2CHK cmp #0 beq AF2CHK inc FLAG AF2CHK: lda AF2 cmp #57 bcs AF3CHK cmp #0 beq AF3CHK inc FLAG AF3CHK: lda AF3 cmp #57 bcs AF4CHK cmp #0 beq AF4CHK inc FLAG AF4CHK: lda AF4 cmp #57 bcs CHKEX cmp #0 beq CHKEX inc FLAG CHKEX: lda FLAG cmp #0 beq handdown jmp HDWNEX handdown: ldx #$01 //throw down hand stx $6BCB stx $6BCC ldx #$0 stx $6BC9 stx $6BCA ldx #$60 stx $6FCD //draw balloon ldx #$F0 stx $6FCE stx $6FCF stx $6FD0 HDWNEX: } Next question. Rasterbars.c doesn't specify pragma cpu, so how does it prevent kickassembler or c from using its default behavior of using illegal opcodes? In another thread I talked about this line of code: BX1 = PLPOS+9; producing some kind of AXS command, that anyway when run on the real Atari, the program is borked. But when I add this : #pragma cpu(MOS6502) Well now the asm file doesn't contain the AXS opcode, and ultimately the program does run. I just want to check, if this is actually a requirement for running on Atarixl, why isn't it in the examples, like rasterbars.c? It seems to me I got pretty far without specifying the cpu, but eventually it caused me a problem, like a gotcha waiting to happen later. Just wondering if perhaps Atari projects should default to not using illegal opcodes? I'm no expert, I'm just sharing it failed until I made the change. Thanks Quote Link to comment Share on other sites More sharing options...
Dmitry Posted December 16, 2020 Author Share Posted December 16, 2020 p.s. just to let you know, the program always ran in the emulator. Apparently the emulators don't mind the illegal opcodes, but my Atari didn't want to use it. Quote Link to comment Share on other sites More sharing options...
ivop Posted December 16, 2020 Share Posted December 16, 2020 Just now, Dmitry said: p.s. just to let you know, the program always ran in the emulator. Apparently the emulators don't mind the illegal opcodes, but my Atari didn't want to use it. What CPU is in your Atari? ALL original unmodified Atari 400/800/XL/XE computers have no problems with undocumented opcodes. That's why it runs on the emulator. It should run! There's no such thing as "illegal" opcodes. Even Bill Mensch (one of the designers) said so. They just weren't documented. 1 Quote Link to comment Share on other sites More sharing options...
Dmitry Posted December 16, 2020 Author Share Posted December 16, 2020 13 minutes ago, ivop said: What CPU is in your Atari? ALL original unmodified Atari 400/800/XL/XE computers have no problems with undocumented opcodes. That's why it runs on the emulator. It should run! There's no such thing as "illegal" opcodes. Even Bill Mensch (one of the designers) said so. They just weren't documented. I am just copying terms I find on websites, I find that one website says illegal, one says undocumented, I inevitably use the wrong word - but it doesn't represent an opinion, just an attempt to use the word I found somewhere. OK it is slowly dawning on me, this is what xxl tried to communicate as well. Even if I think this Atari has a 6502C as one of its choices, there is no telling what it is using....it's pretty borked, I have another computer on order. Let's say it was thrown into 65c816, using compatibility mode, would that explain a problem with undoc'd opcodes? Quote Link to comment Share on other sites More sharing options...
+Stephen Posted December 16, 2020 Share Posted December 16, 2020 1 hour ago, ivop said: What CPU is in your Atari? ALL original unmodified Atari 400/800/XL/XE computers have no problems with undocumented opcodes. That's why it runs on the emulator. It should run! There's no such thing as "illegal" opcodes. Even Bill Mensch (one of the designers) said so. They just weren't documented. It has the "mother of all trouble makers" in it. Let's say, a rapid way of causing arguments amongst us certain folks Quote Link to comment Share on other sites More sharing options...
+Stephen Posted December 16, 2020 Share Posted December 16, 2020 1 hour ago, Dmitry said: Even if I think this Atari has a 6502C as one of its choices, there is no telling what it is using....it's pretty borked, I have another computer on order. It's not the computer that is borked, it's the "upgrade" in it. Quote Link to comment Share on other sites More sharing options...
zbyti Posted December 16, 2020 Share Posted December 16, 2020 1 hour ago, ivop said: There's no such thing as "illegal" opcodes. Even Bill Mensch (one of the designers) said so. They just weren't documented. I don't get it. What is the reason for not documenting the commands that work? Quote Link to comment Share on other sites More sharing options...
ivop Posted December 17, 2020 Share Posted December 17, 2020 (edited) 23 minutes ago, zbyti said: I don't get it. What is the reason for not documenting the commands that work? I cannot explain that in a few sentences. You need to know how the PLA (Programmable Logic Array) of the 6502 die works. http://www.visual6502.org/images/6502/index.html And the visual sim: http://www.visual6502.org/JSSim/index.html The PLA is the rectangle at the top. It looks a bit like book music Edited December 17, 2020 by ivop 1 Quote Link to comment Share on other sites More sharing options...
drac030 Posted December 17, 2020 Share Posted December 17, 2020 35 minutes ago, zbyti said: What is the reason for not documenting the commands that work? It is simple: they are not documented because, contrary to the legal ones, their operation is not intentional. The opcode decoder has "holes", opcodes which are not defined cause, well, undefined results. Compare in C the switch()/case construction which does not have the "default" section - whatever is not caught by defined cases, causes accidental actions. In his later designs Bill Mensch has improved the decoder. 1 1 Quote Link to comment Share on other sites More sharing options...
zbyti Posted December 17, 2020 Share Posted December 17, 2020 (edited) 7 minutes ago, drac030 said: The opcode decoder has "holes", opcodes which are not defined cause, well, undefined results. undefined but stable result? this logic fails Edited December 17, 2020 by zbyti Quote Link to comment Share on other sites More sharing options...
ivop Posted December 17, 2020 Share Posted December 17, 2020 (edited) Here is the source himself https://ataripodcast.libsyn.com/antic-interview-96-bill-mensch-6502-chip Among a lot of other things, he explains non-defined opcodes, unused opcodes, but not illegal. At one time he says, it's not illegal But the main reason is they just didn't care It's a fun podcast. Thanks ANTIC podcast! Edited December 17, 2020 by ivop 1 Quote Link to comment Share on other sites More sharing options...
drac030 Posted December 17, 2020 Share Posted December 17, 2020 (edited) undefined but stable result? this logic fails Not all are stable, but I do not see why "undefined results" may by logic not be stable in same circumstances. If a function returns the result of the calculation in register, for example, D0, and it is defined so, then whatever the rest of the registers contain, is exactly undefined, eventhough it will most probably be consistent (they depend on the method and are not a part of the API). Edited December 17, 2020 by drac030 Quote Link to comment Share on other sites More sharing options...
zbyti Posted December 17, 2020 Share Posted December 17, 2020 (edited) OK. I am interested in running my code on Rapidus, so I will not use them in any how. Edited December 17, 2020 by zbyti Quote Link to comment Share on other sites More sharing options...
drac030 Posted December 17, 2020 Share Posted December 17, 2020 22 minutes ago, ivop said: he explains non-defined opcodes, unused opcodes, but not illegal. At one time he says, it's not illegal It is not "illegal" in the sense that usiong this does not break the common law and you would not end up in jail. But it is illegal in the sense that using it breaks the rules of clean engineering: if you decide to go out of the specs, you do it at your own risk. Here the risk is that your program will not work. Quote Link to comment Share on other sites More sharing options...
xxl Posted December 17, 2020 Share Posted December 17, 2020 1 hour ago, drac030 said: if you decide to go out of the specs, you do it at your own risk. Here the risk is that your program will not work. will not work if your computer is out of spec (cpu replacmenet) ? on standard Atari will work perfecly ? similarly with other Atari chips, e.g. GTIA if you use its undocumented capabilities, such a program will only work on GTIA but not necessarily on its replacement ? illegal? I suggest calling it rape;) Quote Link to comment Share on other sites More sharing options...
zbyti Posted December 17, 2020 Share Posted December 17, 2020 13 hours ago, ivop said: Here is the source himself https://ataripodcast.libsyn.com/antic-interview-96-bill-mensch-6502-chip at 00:24:40 THX 1 Quote Link to comment Share on other sites More sharing options...
zbyti Posted December 18, 2020 Share Posted December 18, 2020 I was looking at https://xxl.atari.pl/sally-6502c/ and I don't understand Even if they didn't plan these opcodes some of them are stable and look useful, why not put them in the documentation? The only explanation I can think is that they were planning another processor and maintaining unplanned opcodes would make backward compatibility difficult. I see no reason not to use them on a 6502 CPU. I have a reason, I am interested that my code works on Rapidus Quote Link to comment Share on other sites More sharing options...
JesperGravgaard Posted December 18, 2020 Share Posted December 18, 2020 On 12/16/2020 at 10:53 PM, Dmitry said: 1. What's wrong with this code: @Dmitry From the ASM fragment you posted it seems the code continues at label __b99 (elsewhere in the ASM-file). Here I would expect the AF2-comparison. So to understand the problem you are experiencing I would need to se more of the resulting ASM-file. Also, the compiler can detect code that is never run - and remove it. For instance if your AF3 is constant !=0 and <=56 then the compiler will delete the body of the if(). So to understand your problem completely it would also be necessary to see more of the C-file. If you can share more details with me I would love to understand your problem, and if there is an error in the compiler I will of course fix it! /Jesper Quote Link to comment Share on other sites More sharing options...
Dmitry Posted December 18, 2020 Author Share Posted December 18, 2020 1 hour ago, JesperGravgaard said: @Dmitry From the ASM fragment you posted it seems the code continues at label __b99 (elsewhere in the ASM-file). Here I would expect the AF2-comparison. So to understand the problem you are experiencing I would need to se more of the resulting ASM-file. Also, the compiler can detect code that is never run - and remove it. For instance if your AF3 is constant !=0 and <=56 then the compiler will delete the body of the if(). So to understand your problem completely it would also be necessary to see more of the C-file. If you can share more details with me I would love to understand your problem, and if there is an error in the compiler I will of course fix it! /Jesper @JesperGravgaard, Thanks for your help. AF3 and AF4 were defined with export, to ensure the compiler included them. However, they weren't actually used. Still, this observation may be unimportant since I have made changes since my post, and can no longer test with that exact code again. Later I added AF3 and AF4 to the init, because I was on a task to zero memory that I was to use in my program. I suspect when I made my post I was relying on the observation that other inline ASM tended to be included in the created assembler output with comments included. Maybe...hard to say now. I put the C based code back in place, and I do see it in the assembler output now. The code does glitch big time with it in place, (by this i mean my player flashes) the player flashing is usually an interrupted DLI. I will probably eventually need to figure this out....but for now, I'll have to put it aside. It's too much to ask someone to look into it for me. I guess for me, I'll have to evaluate if C is helping. If I were an expert in atari hardware and asm, and didn't mind going to the asm to examine what the C was creating, this tool is really sweet. But for me, alas, I am learning the atari hardware, and the high level languages tend to hide what I need to be learning. When I put this "if" clause in now, it tends to work, except the man starts flashing. The man flashing, tends to occur when the dli that colors the man is interrupted. I know dli are non maskable interrupts. I mean another dli can interrupt and dli...who knows. There is no obvious relation to writing an if statement and having a dli glitch....I have no doubt there is a relation, but, I just mean, I may just find it more productive to stick to asm as I ponder these things...OK, but it is a great tool, love it...I'm torn. Thanks for the help, I'll try not to drag you into what turns out to be something else. Quote Link to comment Share on other sites More sharing options...
fenrock Posted December 22, 2020 Share Posted December 22, 2020 On 12/16/2020 at 9:53 PM, Dmitry said: Rasterbars.c doesn't specify pragma cpu, so how does it prevent kickassembler or c from using its default behavior of using illegal opcodes? In another thread I talked about this line of code: BX1 = PLPOS+9; producing some kind of AXS command, that anyway when run on the real Atari, the program is borked. The default target file for atarixl is defined as: { "description": "Atari XL/XE executable XEX file with a single segment.", "cpu": "MOS6502X", "link": "atarixl.ld", "start_address": "0x2000", "zp_reserve": [ "0x00..0x7f" ], "encoding": "atascii", "extension": "xex", "emulator": "atari800 -xl", "defines": { "__ATARIXL__": 1 } } That 6502 CPU definitions in kickc are: /** Vanilla MOS 6502 CPU - no illegal opcodes, allows self-modifying code. */ MOS6502("mos6502", CPU_6502NoIllegals.name, Cpu6502Official.INSTANCE, Arrays.asList(Feature.MOS6502_COMMON, Feature.MOS6502_SELFMOD)), /** MOS 6502 CPU - allows illegal instructions, allows self-modifying code. */ MOS6502X("mos6502x", CPU_6502WithIllegals.name, Cpu6502Illegal.INSTANCE, Arrays.asList(Feature.MOS6502_COMMON, Feature.MOS6502_UNODC, Feature.MOS6502_SELFMOD)), And the Cpu6502Illegal.INSTANCE defines axs addOpcode(0xcb, "axs", CpuAddressingMode.IMM, 2.0, "Xcnz"); as an available opcode. I haven't come across any scenarios myself where that is being used, maybe more by luck than anything. 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.