Nop90

@42bsyou are right about your example of code for the IF THAN ELSE, I read again the specs and the triple NOP takes 3 bytes. I missed this part the first time I read the 65C02 specs. This is really interesting to know. but the same specs also reports the behaviour of all the other unused opcodes: On the 65C02, all unused opcodes are guaranteed to have no operation, and are documented as such. They differ from the standard NOP (opcode $EA) only in size (i.e. the number of bytes) and cycle count. (On the 65816, only opcode $42 is unused. It is documented as having no operation, but is reserved for future instruction set expansion.) The following table summarizes the unused opcodes of the 65C02. The first number is the size in bytes, and the second number is the number of cycles taken. After the second number, a lower case letter may be present; when it is present it indicates a footnote. 02 03 04 07 0B 0C 0F ----- ----- ----- ----- ----- ----- ----- 00 2 2 1 1 . . 1 1 a 1 1 . . 1 1 b 10 . . 1 1 . . 1 1 a 1 1 . . 1 1 b 20 2 2 1 1 . . 1 1 a 1 1 . . 1 1 b 30 . . 1 1 . . 1 1 a 1 1 . . 1 1 b 40 2 2 1 1 2 3 1 1 a 1 1 . . 1 1 b 50 . . 1 1 2 4 1 1 a 1 1 3 8 1 1 b 60 2 2 1 1 . . 1 1 a 1 1 . . 1 1 b 70 . . 1 1 . . 1 1 a 1 1 . . 1 1 b 80 2 2 1 1 . . 1 1 c 1 1 . . 1 1 d 90 . . 1 1 . . 1 1 c 1 1 . . 1 1 d A0 . . 1 1 . . 1 1 c 1 1 . . 1 1 d B0 . . 1 1 . . 1 1 c 1 1 . . 1 1 d C0 2 2 1 1 . . 1 1 c 1 1 e . . 1 1 d D0 . . 1 1 2 4 1 1 c 1 1 f 3 4 1 1 d E0 2 2 1 1 . . 1 1 c 1 1 . . 1 1 d F0 . . 1 1 2 4 1 1 c 1 1 3 4 1 1 d a) RMB instruction on Rockwell 65C02 and WDC 65C02 b) BBR instruction on Rockwell 65C02 and WDC 65C02 c) SMB instruction on Rockwell 65C02 and WDC 65C02 d) BBS instruction on Rockwell 65C02 and WDC 65C02 e) WAI instruction on WDC 65C02 f) STP instruction on WDC 65C02 These unused opcodes may prove useful in some situations. Note, however, that any code that makes use of them is limited to the 65C02. First, many opcodes behave as one byte, one cycle NOPs. This can more useful than the standard one byte, two cycle NOP (opcode $EA). If I can find the time I'll write some code to run on real HW to test which code is working, instruction lenghts and maybe the cycles taken too.

Why should it skip it? 3 cycles means only that it ìs the time the CPU takes to handle that special NOP, it will not affect the PC differently than a standard NOP. The use of this special opcodes should be to better sincronize the timing of the code with something very fast happening at specific time periods, without the need to use timers and interrupts (you can set a timer only to 1us, and if you take count of the timer activation and of the time to enter the interrupt, its a much more time than 3 cycle) For a three cycles delay I'm using a BIT M instruction at the moment, but there is no 1 cycle opcode other than some of this special NOPs

I'm reading you code on my mobile so can't analyse it deeply, but can say two things. If you care performances avoid structures with cc65 when you can. Since sprites are structures, defining arrays of structures that contain sprites is not a good idea IMHO. Second, if you draw sprites that reuse the palette, check if the first Sprite of the new frame has a palette, or nothing is going to be drawn.

As I wrote in another thread, Handy doesn't support unused 6502 instruction values. On a standard 65c02 they are guaranteed to act as Nop, but with different numbers of cycles (1, 2 or 3) depending the value. Does the custom lynx chip works the same? If yes I'd like to see them implemented.

There is a lot of work todo first. Now have to finish my entries for the coding copetition, but in August I'll work again on this. I'd like to have something that can run simple homebrews for eJagFest. But dont know if it will happen.

In my experience common cause for batteries not working is the power jack connector. I have three lynxes with this problem. I should replace the connectors, but first I want to try to carefully clean the inside of the connectors with alcohol to verify if they are stuck in external Power Supply position.

Try to clean the game cart contacts. If it is oxidated can't connect the two pins that make the lynx turn on, so it could be the cause for the three consoles not powering on.

You should have an invitation

Opened a private Club to test the Retroguru game (alpha version). Who wants to join? @bhall408 do you still want to be invited?

Tuned the interrupt delay and fixed the Wsync count. Now the emulator runs steady. VVCS.zip

The card structure is because I'm planning to implement a simple menu to select a rom from a list. If you want I can share the code, but please don't complain my poor asm coding skills. I'll consider the VladR suggestion.

With 2600 it's much simpler, all the code is in ROM, no Interrupts, almost all the HW registers are in the first half of the zero page (but there are some location free that can be used for indexing arrays in memory) and there are only 128 bytes of ram shared with the stack because page 1 is shadowed to page 0. I already have a modified version of DISTELLA that converts all the addresses of the ROM to $1000 base, getting rid of a lot of memory shadow addresses, so the code can run almost unmodified. On the lynx the zero page and the stack pages live on their own, so I don't have to care about the more stack used by the interrupts handler and all the RW memory will work without any adjustment. The only things that will not work are some advanced time saving tricks that write on the boundary of RAM and Stack pushing values on the stack, but I can live without them. "Racing the beam" is going to be emulated "Racing the clock" and writing all the changes to the registers in a table that will be used to emulate the scanline during the Lynx Hblank. The idea is simple, making it work not. At the moment I'm using an interrupt triggered every 3us: it is started inside the interrupt handler so to leave the execution only of few cycles of the ROM code before be triggered again. Leaving it always on probably will decrease the performance but I have a backup plan to use my modified DISTELLA to change the VBLANK,VSYNK and WSYNK writes with BRK instrctions so to turn off the timer when not needed and turn it on only when the screen drawing starts. There are other things to disable using DISTELLA as a parser, first one is the SEI instruction (why use it as first instruction on VCS rom if the 6502 INT pin is not connected?) . I's the firt instruction of almost every (if not every) commercial rom and made me lost a lot of debugging time the first time I tryed one of this rom with my code. I think this should be enough to simulate all the basic functions of the VCS. What about it?

Yes, next thing to implement is to track the change of the COLUBK, COLUPF and the three playfield regisrs during the VCS scanlines, and try to reconstruct the image during the Lynx HBlanks. But at every thing that I add I have to rework something in the previous code. Are you interested in working on it. One thing that could be very easy to emulate is the sound generator. The two sound generators use almost the same polinomial algotithm, if we can define 16 instruments on lynx that sound like the 16 (less in reality) of the VCS, it's only a matter to setup the instruments and adjust frequency and volume at every Lynx VBLANK.

I'm going to simply draw half of the scanline. I know t's not the best ting but there are no other possibility I can see. And there are worst prolems to solve. Attached there is what I did in three days, the rom running is the basic kernel from https://www.randomterrain.com/atari-2600-memories-tutorial-andrew-davie-08.html Tested only on Handy, run on real HW at your own risk. At the moment I can keep track of VBLANK VSYNK and WSYNC, and implemented TIM64T and some keys emapping. Nothing else, but it's already something. In this simple code the VCS WSYNC only stores the COLUBK value in a table and the lynx HBLANK set the right value to the PEN0 palette value. The colors map is the PAL one. Some of the TIA register writes (WSYNK in this case) get lost because I have to tune the TIMER1 interrupt that triggers the registers handlers: have to try with a small delay using the 1 cycle NOP that the 65c02 uses for non mapped opcodes (the standard NOP is two cycles that is too much in my timing setup) but HANDY don't have them, and don't know yet if it's because they are not supported by the custom lynx CPU or simply because no one mapped them in the emulator. The garbage at the bottom of the screen is because my cleanscreen ASM function is buggy, so disabled it for now. I know I can use Suzy for blitting a stretched 1 pixel sprite to clean it, but learn to control Suzy in ASM is too much things at the moment. As I said, I really need help. VVCS.zip

When some month ago I read this 16 years old post I was fascinated by the teoretical possibility to run 2600 code on lynx, so started to sketch how it could be achieved. Now, after studying both Lynx and VCS archtecture, and refreshing my 35 years old 6502 ASM knowledge (not a deep knowledge) I think it's possible to make at least a minimal vcs simulator (not an emulator and not at full speed). But with my little time available and the knowledge of lynx and VCS needed I can't do it alone, so I'm looking for some people that want to work with me on this project. Don't know how far it can go (probably playing games will never be possible, only running simple code) but I think it's worth trying. Who wants to join?