Jump to content
IGNORED

VCS code execution on Lynx - Need help for a POC


Nop90

Recommended Posts

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?

  • Like 2
Link to comment
Share on other sites

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

Edited by Nop90
  • Like 2
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

I can absolutely understand the desire to work on something like this. I, myself, spent a lot of work on a prototype that runs Atari 800's 6502 code on Jaguar. There's a lot of things that can be easily emulated at run-time, but a lot more that need manual adjustment. At which point it's questionable how far should one really go.


Generally, the first stage should be a software rasterizing - e.g. no DLIs. Not sure if that applies to 2600, since afaik it works by racing the beam...

 

But, from experience, it's easiest to port the generic 6502 code to host platform (in my case, the target was 68000, as GPU only has 4 KB of cache that would severely limit the games that could even be attempted) first - via some PC-based parser/converter.

 

 

Have you considered creating a PC-based analyzer that would first scan the whole 6502 code and try to automatically figure out all the base system's variables/addresses ?

Next step could be creating a simple 2600 VM (sort of an emu) that would literally run the code and thus figure out the configuration and behavior.

Final step would be copying the 6502 code that is for simple copy/paste plus the one that emulates the system's POKEs (detected within the VM).

 

Totally doable in around 100-200 hours.

Link to comment
Share on other sites

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?

 

 

Link to comment
Share on other sites

3 hours ago, Nop90 said:

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.

VVCS.zip 1.94 kB · 2 downloads

Do you need the card structure? If not would you mind posting the .o file. I'd like to check it with BLL.

Link to comment
Share on other sites

VladR's idea has the advantage, that you do not have to check every ZP access for a HW register.

IIRC it is how the Jaguar VCS emulator works.

 

The advantage of "converting" the VCS game off line is, that the 6502 code can run directly on the Lynx.

Link to comment
Share on other sites

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.

 

 

Link to comment
Share on other sites

7 hours ago, 42bs said:

VladR's idea has the advantage, that you do not have to check every ZP access for a HW register.

IIRC it is how the Jaguar VCS emulator works.

 

The advantage of "converting" the VCS game off line is, that the 6502 code can run directly on the Lynx.

Yeah, but let's first not forget that:

- Jaguar's GPU runs totally in parallel to 68000 and is clocked at 26.6 Mhz

- You can offload sound generation to yet another parallel processor : DSP @26.6 MHz which can easily reproduce the square waves of Atari, plus keep monitoring the Audio registers and prepare the payload before interrupt hits

 

On the other hand, you actually need that power to replicate the Antic's hardwired functionality, because each frame you must process up to 192 lines of Display List and via Blitter draw each scanline into Jaguar's Render Target.

 

Of course, any run-time code modification screws this approach, but there would still be thousands of titles that could run just fine.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 1 month later...
  • 4 months later...

Little update: now the emulator can handle (not perfectly) the basic elements of the playfield kernel of some commercial roms: Pitfall! is one of these (try the attached build).

 

pit.png.2a42abf9dbfe748dacfe3f30b0399558.png

 

At the moment the emuator can handle the VSYNC, the VBLANK (partially), the WSYNC, the T64, the P0 P1 and P2 playfield registers (but only with the BK and PF colors set at the beginning of every horizontal line), the Replicate/Reflect bit for the second half of the playfield and some of the inputs (BW/Color with OPT1, Difficulty with OPT2 and Reset with PAUSE).

 

The Joy is implemented but is buggy and doesn't work.

 

Try pressing OPT1 running Pitfall and you'll se the screen slowly turn grayscale.

 

To handle the colors I'm using the same line by line palette switching I used for the 256 color image test.

 

Of course the emulation is very slow  (3 seconds per frame): the code is not optimized because I change it very often and have to test it with the debugger easily. With optimization it probably can go 10 times faster, but considering it's emulating no ore than the 5% of the internals, it will be slower and slower adding other things.

 

At least I'm learning how a VCS works ?.

 

To make the testing faster I'm going to add the possibility to select different roms at start (and maybe the possbility to load other more from the RetroHQ SD card).

 

I already implemented more than I could think possible, but don't want to give up now. At the moment I'm going crazy trying to understand the HMOVE register, after implementing it I'll start implementing a basic handling of the the playera and balls sprites

 

 

VVCS.lnx

Edited by Nop90
  • Like 9
Link to comment
Share on other sites

  • 1 month later...

Yes, fixed the input handling, added a cycles counter and implemented a basic sprites renderer. But now have to rewrite the whole rendering code to be able to handle all the sprites parameters.

 

I'm also iplementing a palette update only when new colors are used. On most games less than 16 colors are used, so the emulator has to update the palette only every VBL, with a big speed gain. But the code is buggy yet.

 

At the moment I'm not working on this project, had to fix the last bugs for the release of the two new Songbird games, and I'm again busy with my Job. But when I have a big update I'll release a new build and all the sources.

 

 

  • Like 2
Link to comment
Share on other sites

  • 6 months later...
  • 1 year later...

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...