Dmitry Posted December 16, 2020 Share Posted December 16, 2020 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? 1 Quote Link to comment Share on other sites More sharing options...
drac030 Posted December 16, 2020 Share Posted December 16, 2020 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. Quote Link to comment Share on other sites More sharing options...
snicklin Posted December 16, 2020 Share Posted December 16, 2020 Are you using RAM which is available on the emulator but not on the real computer? I.e. 64k emulator 16k computer? Quote Link to comment Share on other sites More sharing options...
Dmitry Posted December 16, 2020 Author Share Posted December 16, 2020 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? Quote Link to comment Share on other sites More sharing options...
xxl Posted December 16, 2020 Share Posted December 16, 2020 (edited) 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 December 16, 2020 by xxl Quote Link to comment Share on other sites More sharing options...
Dmitry Posted December 16, 2020 Author Share Posted December 16, 2020 (edited) 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 December 16, 2020 by Dmitry Quote Link to comment Share on other sites More sharing options...
Dmitry Posted December 16, 2020 Author Share Posted December 16, 2020 (edited) 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 December 16, 2020 by Dmitry 1 Quote Link to comment Share on other sites More sharing options...
xxl Posted December 16, 2020 Share Posted December 16, 2020 maybe it just has optimization turned on, subtracting (adding) using SBX is just faster. Quote Link to comment Share on other sites More sharing options...
ivop Posted December 16, 2020 Share Posted December 16, 2020 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. Quote Link to comment Share on other sites More sharing options...
xxl Posted December 16, 2020 Share Posted December 16, 2020 yes, but Dmitry probably runs it with a 16bit cpu (65816) Quote Link to comment Share on other sites More sharing options...
Dmitry Posted December 16, 2020 Author Share Posted December 16, 2020 @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.... Quote Link to comment Share on other sites More sharing options...
+Stephen Posted December 16, 2020 Share Posted December 16, 2020 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. Quote Link to comment Share on other sites More sharing options...
Dmitry Posted December 16, 2020 Author Share Posted December 16, 2020 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. Quote Link to comment Share on other sites More sharing options...
Dmitry Posted December 17, 2020 Author Share Posted December 17, 2020 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. Quote Link to comment Share on other sites More sharing options...
xxl Posted December 17, 2020 Share Posted December 17, 2020 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). Quote Link to comment Share on other sites More sharing options...
fenrock Posted December 22, 2020 Share Posted December 22, 2020 (edited) 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 December 22, 2020 by fenrock added tas, and comments about being odd 1 Quote Link to comment Share on other sites More sharing options...
ivop Posted December 22, 2020 Share Posted December 22, 2020 (edited) 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 December 22, 2020 by ivop 2 Quote Link to comment Share on other sites More sharing options...
ivop Posted December 22, 2020 Share Posted December 22, 2020 (edited) 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 December 22, 2020 by ivop Quote Link to comment Share on other sites More sharing options...
fenrock Posted December 22, 2020 Share Posted December 22, 2020 (edited) 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 December 22, 2020 by fenrock 1 Quote Link to comment Share on other sites More sharing options...
xxl Posted December 22, 2020 Share Posted December 22, 2020 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. Quote Link to comment Share on other sites More sharing options...
JesperGravgaard Posted January 4, 2021 Share Posted January 4, 2021 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 Quote Link to comment Share on other sites More sharing options...
fenrock Posted January 4, 2021 Share Posted January 4, 2021 (edited) 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 January 4, 2021 by fenrock novice 1 Quote Link to comment Share on other sites More sharing options...
JesperGravgaard Posted January 4, 2021 Share Posted January 4, 2021 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 1 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.