Jump to content
IGNORED

Dmitry KickC Questions


Dmitry

Recommended Posts

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 :D

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 :D

 

 

  • Like 2
Link to comment
Share on other sites

  • 2 weeks later...

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

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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?

 

 

 

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by ivop
  • Thanks 1
Link to comment
Share on other sites

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.

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

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 by ivop
  • Thanks 1
Link to comment
Share on other sites

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 by drac030
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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 :D 

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

 

 

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...