Jump to content
Dmitry

Emulator versus real Atari

Recommended Posts

I'd like to ask very generally about Emulators versus real Atari.

 

Essentially I've been merrily making progress on my game, but today I put it on a real Atari.  The xex loaded.  The man moves left and right on the screen.

 

The program makes extensive use of DLI and VBI, and multiplexing of players.  Obviously a lot of that is working, even to show the buildings which use players to add color, and the little man is colored by dli, and the update of the position is in the vbi.  But the player0 balloon doesn't show - not sure why, I might assign it to timing, but...probably isn't.  I mean it requires very tight timing to do the multiplexing, but not at all if you don't move left and right, in which case hpos0 isn't updated in the position table anyway.  No...it is something, but without delving into specifics, are is there any general advice?

 

Like what types of issues you program against an emulator versus the real Atari?  Honestly, I thought they were darn near perfect.  I guess that was naive on my part?

 

 

 

 

  • Like 1

Share this post


Link to post
Share on other sites
14 minutes ago, Dmitry said:

Like what types of issues you program against an emulator versus the real Atari?

The RAM contents. I guess that the emulator might start with everything zeroed while on a real Atari the memory contents may vary depending on what you used to load the binary.

Share this post


Link to post
Share on other sites

Are you using RAM which is available on the emulator but not on the real computer?

 

I.e. 64k emulator 16k computer?

Share this post


Link to post
Share on other sites

Thanks for the suggestions.  I find this interesting, and I shoudl have a workaround.

 

I finally tracked it down to the sprite was being drawn off screen, that is why it doesn't appear.

 

I'm using KickC.  The DLI and VBI are pure assembler, but I have some code in KickC.

 

This line always caused a 0:

 

BX1 = PLPOS+9;

 

Now, that is curious, so I went into the compiler generated asm.

 

    lax.z PLPOS
    axs #-[9]
    stx.z BX1
    lax.z PLPOS
    axs #-[9]

 

I don't recognize these opcodes, but I'm not that experienced in assembler, I just get by with what I need for now, it's curious the emulators all ran this, but the real Atari didn't respond.  I did a google search, and it is say AXS is an unofficial or extra opcode?

Wild stuff. Well I can add in assembler without using KickC, but I wasn't expecting it to do this....do you all think it is in error for using this opcode?

 

 

Share this post


Link to post
Share on other sites
17 minutes ago, Dmitry said:

 

 

    lax.z PLPOS
    axs #-[9]
    stx.z BX1
    lax.z PLPOS
    axs #-[9]

 

check what code and if it belongs to unstable (red) commands - the red ones may not work properly on real hardware.

 

https://xxl.atari.pl/sally-6502c/

 

---

unless you have an Atari CPU replaced?

 

 

---

 

ASX to SBX - stable ...

you have a modified computer :(

 

Edited by xxl

Share this post


Link to post
Share on other sites

I just replaced the code just now with 

 

asm {
clc
lda PLPOS
adc #9
sta BX1
}

 

Now it works.

 

I just found it interesting that I issued such a basic C command and KickC used an unstable opcode that doesn't work on the Atari.

I guess it is some optimization leftover from its Commodore roots, as a guess.  I definitely wasn't looking for this result, not sure if it is changeable in a config somewhere.

 

Oh well, problem solved, the test now works on my Atari.

Edited by Dmitry

Share this post


Link to post
Share on other sites

and i am back from reading the docs.

 

#pragma cpu(MOS6502)

 

looks like that turns off support for illegal opcodes
 

It's not used in the examples for Atarixl platform (e.g. rasterbars.c) , but if the compiler defaults to using illegal opcodes for some basic C statements I think this platform should probably not use the defaults. 

 

Anyway, leaving here in case it helps someone, but, seems like this was mostly a detour.

Edited by Dmitry
  • Like 1

Share this post


Link to post
Share on other sites

maybe it just has optimization turned on, subtracting (adding) using SBX is just faster.

Share this post


Link to post
Share on other sites

It might be that KickC generated wrong code, or its assembler? What KickC calls axs is SBX ($CB) (xxl already said that), and SBX is stable across all NMOS 65xx implementations I'm aware of.

 

Share this post


Link to post
Share on other sites

yes, but Dmitry probably runs it with a 16bit cpu (65816)

Share this post


Link to post
Share on other sites

@xxl

 

Yes, probably - although I didn't realize it at first.  My computer is borked. Even if I put it in 6502c mode, it may throw itself into 65c816.

 

So, that's not good.  Too many variables and not enough experience with what works and what doesn't....but even still this is good, I would want my program to run with 65c816.   But now I get why it wasn't important to default away from using these undoc'd opcodes.


The mystery slowly unravels....

Share this post


Link to post
Share on other sites
47 minutes ago, Dmitry said:

@xxl

 

Yes, probably - although I didn't realize it at first.  My computer is borked. Even if I put it in 6502c mode, it may throw itself into 65c816.

 

So, that's not good.  Too many variables and not enough experience with what works and what doesn't....but even still this is good, I would want my program to run with 65c816.   But now I get why it wasn't important to default away from using these undoc'd opcodes.


The mystery slowly unravels....

Well, I was going to say remove the damn Rapidus and you'll have a 100% reliable and usable machine, but you said you want code running on 65816 so I won't say that.

Share this post


Link to post
Share on other sites
31 minutes ago, Stephen said:

Well, I was going to say remove the damn Rapidus and you'll have a 100% reliable and usable machine, but you said you want code running on 65816 so I won't say that.

 

Oh man, you don't know how much I want to unbork this machine.

 

Back in 2016, when I had a technician put together this 'ultimate 1200xl'  it wasn't known this combination doesn't work (u1mb/rapidus), but it is super frustrating to me now...

 

The price to get it all repaired is high, like well over $300.  I have no skill at it, and to remove the u1mb, I'd need to flash 1200xl roms, replace I think the mmu...something like that, plus maybe solder some jumpers...

 

Anyway, yes, even if I gather the consensus is the Rapidus isn't playing well with others, the u1mb is what I want removed, based on the logic that the combination of the two is the issue.  I totally agree that the U1MB is not at fault, but unfortunately it'll someday be the victim of this failure to play together.

 

Right now this this machine is random, it tells me what its goign to do, I don't tell it anything....

 

lol

 

Anyway I have a 130XE with no mods on the way...I'll use that and enjoy the break from the madness.

 

 

 

Share this post


Link to post
Share on other sites

but p.s. my comment about 65c816 wasn't about the rapidus... a while back I bought an Antonia 4mb, and was recently trying to get that going in an Atari 800XL. 

 

The thought occurred to me, that the super fans tend to buy hardware upgrades...if it's just a matter of losing a few cycles to not using sbc , I'd just go ahead and see if my game can go ahead and support Antonia users.  I rather hope most Rapidus users can switch into 6502c mode and don't have my problems.  But Antonia is a cpu replacement.

 

 

Share this post


Link to post
Share on other sites

if you want your program to run on 65816 - then do not use the original CPU-specific capabilities, see also the differences in operation (but they are not large).

Share this post


Link to post
Share on other sites

Just picked up this thread about the Illegal opcodes being used in kickc generated code, I commented over there why it's happening.

 

The opcode generated should be $cb, which according to the Polish page for sally should work fine as "SBX #n".

So it's odd the code is crashing.

 

However, for other codes I've just looked at all the kickc instructions marked as illegal but usable in the MOS6502X CPU.

 

The following are the only ones it uses that the Sally page above says are Unstable (work as described only on 6502C processors from some manufacturers) are:

 

KickC       sally       opcode  comments
-----------------------------------------
xaa #n      ane #n      0x8b    no fragments in kickc use this instruction
ahx (z),y   sha (z),y   0x93    no fragments in kickc use this instruction
tas M,y     shs q,y     0x9b    no fragments in kickc use this instruction
ahx M,y     sha q,y     0x9f    no fragments in kickc use this instruction
lax #n      anx #n      0xab    2 fragments use this instruction
las M,y     las q,y     0xbb    no fragments in kickc use this instruction

It doesn't explain why you're getting errors running AXS, but does highlight some potential issues with other instructions.

 

For AXS there are 14 fragments that use that instruction in KickC.

 

@JesperGravgaard this might be one for the backlog to mark the atari 6502C instructions differently to the MOS6502X ones?

 

EDIT: Hadn't realised the conversation was about 65C02, not 6502C.

 

Edited by fenrock
added tas, and comments about being odd
  • Like 1

Share this post


Link to post
Share on other sites
22 minutes ago, fenrock said:

So it's odd the code is crashing.

No, it's not. He runs his code on a 65C816 in 65C02 mode, which does not have these undefined opcodes.

 

65C02 (CMOS) != 6502C Sally (NMOS)

 

 

Edited by ivop
  • Like 2

Share this post


Link to post
Share on other sites
34 minutes ago, fenrock said:

However, for other codes I've just looked at all the kickc instructions marked as illegal but usable in the MOS6502X CPU.

 

The following are the only ones it uses that the Sally page above says are Unstable (work as described only on 6502C processors from some manufacturers) are:

KickC       sally       opcode  comments
-----------------------------------------
xaa #n      ane #n      0x8b    no fragments in kickc use this instruction
ahx (z),y   sha (z),y   0x93    no fragments in kickc use this instruction
ahx M,y     sha q,y     0x9f    no fragments in kickc use this instruction
lax #n      anx #n      0xab    2 fragments use this instruction
las M,y     las q,y     0xbb    no fragments in kickc use this instruction

 

The page you referred to shows six unstable undefined opcodes, your list only five. You missed 0x9b SHS Q,Y ;)

 

Edit: oh, I misread. You listed only the ones that kickc uses. Sorry 😊

Edited by ivop

Share this post


Link to post
Share on other sites
29 minutes ago, ivop said:

The page you referred to shows six unstable undefined opcodes, your list only five. You missed 0x9b SHS Q,Y ;)

 

Edit: oh, I misread. You listed only the ones that kickc uses. Sorry 😊

You're actually correct, I wrote it down on my list, then not in the table. I've edit my original post. Thanks for checking!

Edited by fenrock
  • Like 1

Share this post


Link to post
Share on other sites
1 hour ago, fenrock said:

lax #n anx #n 0xab 2 fragments use this instruction

very deceptive, among unstable ANX is stable in one case: ANX #$00

As far as I know, GILP uses this code with a nonzero argument and may not work on some atari.

Share this post


Link to post
Share on other sites
On 12/22/2020 at 6:05 PM, fenrock said:

 

The following are the only ones it uses that the Sally page above says are Unstable (work as described only on 6502C processors from some manufacturers) are:

KickC       sally       opcode  comments
-----------------------------------------
xaa #n      ane #n      0x8b    no fragments in kickc use this instruction
ahx (z),y   sha (z),y   0x93    no fragments in kickc use this instruction
tas M,y     shs q,y     0x9b    no fragments in kickc use this instruction
ahx M,y     sha q,y     0x9f    no fragments in kickc use this instruction
lax #n      anx #n      0xab    2 fragments use this instruction
las M,y     las q,y     0xbb    no fragments in kickc use this instruction

 

@JesperGravgaard this might be one for the backlog to mark the atari 6502C instructions differently to the MOS6502X ones?

@fenrock Very nice table! 

 

However, I have looked through all the compiler fragments, and I cannot find any fragments in the compiler using LAX #n. Could you point me towards the 2 fragments you have found?

 

I have looked through several articles on the illegal opcodes. There are several (old) articles that have contradictory information about how they work. Some of the best sources I could find are http://visual6502.org/wiki/index.php?title=6502_Unsupported_Opcodes and http://www.oxyron.de/html/opcodes02.html

 

I have so far never seen well-documented examples of undocumented opcodes that work differently on different CPU's. Are you certain that any of the codes on SALLY actually works differently from an original MOS 6502? If anyone has confirmed this I would love a link to more information!

 

My understanding so far is that all the CPU's where the undocumented opcodes work actually contain an almost exact copy of the original MOS 6502 core (transistor by transistor). See for instance this die shot of a NES RP2A, where you can see the 6502 core in the lower right corner http://www.visual6502.org/images/pages/Nintendo_RP2A_die_shots.html. Here is an original 6502 die shot to compare with http://www.visual6502.org/images/6502/index.html. A die shot of SALLY is on their TODO-list - so when that arrives we can check it out :)


 

 

 

Share this post


Link to post
Share on other sites
55 minutes ago, JesperGravgaard said:

@fenrock Very nice table! 

Thanks :)

 

Quote

However, I have looked through all the compiler fragments, and I cannot find any fragments in the compiler using LAX #n. Could you point me towards the 2 fragments you have found?

 

 

src/main/fragment/mos6502-undoc/vbuxx=vbum1_minus_vbuc1.asm:

lax {m1}
axs #{c1}

src/main/fragment/mos6502-undoc/vbuxx=vbum1_plus_vbuc1.asm

lax {m1}
axs #-[{c1}]

I can't comment on Sally differences, I'm a mere novice here!

 

Edited by fenrock
novice
  • Like 1

Share this post


Link to post
Share on other sites
15 minutes ago, fenrock said:

 

src/main/fragment/mos6502-undoc/vbuxx=vbum1_minus_vbuc1.asm:

lax {m1}
axs #{c1}

src/main/fragment/mos6502-undoc/vbuxx=vbum1_plus_vbuc1.asm

lax {m1}
axs #-[{c1}]

 

None of those LAXes are opcode $AB LAX #IMM. They will become $A7 LAX ZP  or $AF LAX ABS. The AXS #IMM will become a $CB SBX #IMM.

Neither of these are marked as unstable in https://xxl.atari.pl/sally-6502c/, so these fragments should not present any problem :)

  • Like 1

Share this post


Link to post
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...