11 replies to this topic

[GadgetUK]

I've had an idea that I've been mulling over for a few weeks now... I am thinking of attempting to write a re-complier for C64 or NES (possibly NES first) to Lynx. I wrote a NES emulator way back in 2001 ish, and so I've got a reasonable (although rusty) understanding of how the NES worked. Basically you've got a 6502 CPU, with all other chips memory mapped. If I used my knowledge of the NES, and to start with the default mapper (mappers were a simple bank switching technology used to expand ROMS over the default size, in theory I could decompile the code (the tricky bit where code is self modifying, but should be easier for code that isnt), work out where its using calls to other interfaces - eg. APU (sound registers), controller registers, and graphics hardware, and in theory I could substitute sections of that code with Lynx code, and with a bit of analysis of working out where to put some initialisation code etc then in theory we might be able to have something like a HLE recompiler that recompiles some NES code for the Lynx. I think the biggest problem is the screen size difference, and obviously the sound hardware, but from what ive seen the Lynx audio is more sophisticated than the NES audio, so it should be possible to simulate. The screen resolution difference could in theory be handled by an inititialisation wrapper that possibly rescales the display raster using suzie - but that assumes the aspect ratio is the same. Of course it would be difficult, I am not saying it would be easy, and theres the overhead of any additional routine code - ie. code to init everything and code to replace graphics and sound routines that arent quite the same.

Still, I am fascinated by the idea of this... I would LOVE to be able to play some of the classic NES games on the Lynx. C64 would be trickier as the SID audio would be hard to match I imagine as the SID is a lot more complex than the pAPU built into the NES. With the C64 I guess theres the advantage of basic, but there are character roms and the basic rom code itself etc which I am not sure about memory wise - ie. it could be near impossible to make most things run due to the fact the C64 uses so much of the 64Kb, and there will likely be not much free space in RAM for and graphics and audio translated code.

Has anyone attempted this, or given it any serious thought?

In theory we could start off small, use one of the really simple NES demo roms - they just init everything, display a bitmap built of tile sprites, and some have music. I would imagine something like that to be relatively easy to work with, and assuming its say 32k or 48k of the RAM used, there's likely to be room for additional controller, audio, video code etc. Spy vs Spy on the Lynx , or maybe Mario Bros, Metroid etc.

[GadgetUK]

Just been digging out the documents I used for the NES emulation, a document by Yoshi:-

It uses 8Kb of RAM, the rest of the address space is used for pAPU (audio), controllers, save RAM graphics, and the upper 32Kb is where the program is loaded from cartridge. In theory all of the addressing could be handled (self modifying code aside). I need to do more reading about the Lynx address space first, and to understand interupts on the Lynx, and differences between the 6502 and 65C02, hopefully most if not all of the opcodes were retained.

I do know for a fact that most of the ROM images I tested worked without an audio implementation, so getting up and running with initialisation, converting addresses to accommodate memory space in the lynx memory map, and assuming I can make the interupts work in a similar way to the NES, then code should run with minimal change. I need to understand the Lynx graphics capabilities next I guess.

B. Memory Map
-------------
+---------+-------+-------+-----------------------+
| Address | Size | Flags | Description |
+---------+-------+-------+-----------------------+
| $0000 | $800 | | RAM |
| $0800 | $800 | M | RAM |
| $1000 | $800 | M | RAM |
| $1800 | $800 | M | RAM |
| $2000 | 8 | | Registers |
| $2008 | $1FF8 | R | Registers |
| $4000 | $20 | | Registers |
| $4020 | $1FDF | | Expansion ROM |
| $6000 | $2000 | | SRAM |
| $8000 | $4000 | | PRG-ROM |
| $C000 | $4000 | | PRG-ROM |
+---------+-------+-------+-----------------------+
Flag Legend: M = Mirror of $0000
R = Mirror of $2000-2008 every 8 bytes
(e.g. $2008=$2000, $2018=$2000, etc.)

EDIT: Something I had forgotten about is that it uses a lot of mirroring of addresses. There's actually only 2Kb of RAM lol, it mirrors it 3 more times.

Edited by GadgetUK, Thu Apr 26, 2012 4:00 PM.

[obschan]

Won't help you a lot, but it sounds like a very interesting and exciting project, best of luck !

[GadgetUK]

Thanks, not sure if its going to be possible yet, I am trying to work out how I would do this. I was a bit concerned about not having enough memory available in the 64kb to accommodate routines to handle Lynx sound and graphics, it might be a squeeze but ive realised that I could claw back 6kb for the mirrored addresses that the NES uses for RAM, as it only has 2kb of actual RAM. I reckon I could squeeze routines for gfx, sound and controls into that 6kb but some of the 6kb will likely be used by the increase in code size to accommodate jumps to the new routines.

Other things ive been thinking:-

Sprite tile data and palettes would be converted before output to the Lynx format, so any prog code refs can work with the lynx format.

Screen resolution is the biggest issue as far as I can see. Lynx is 160 x 102, NES is 256 x 240. This could be the stumbling block... In an ideal world we could draw all nes gfx output to RAM or lynx sprite (VRAM) and downscale the whole image per frame...

[GadgetUK]

Ive scrapped this idea. It probably would work but only for 32Kb ROMS. The real issue from what I understand is that the Lynx has around 48kb of 'useable RAM' only, if you use double buffering for video. I also understand that you cant easily run code directly from ROM and code has to be copied in and out byte by byte. The plus side from what ive read is that suzie can read gfx straight from the cart. It would be a lot of work, and since theres hardly anyone interested its probably not worth the time.

[obschan]

GadgetUK, on Wed May 2, 2012 4:49 AM, said:

It would be a lot of work, and since theres hardly anyone interested its probably not worth the time.

I think you don't get much answer because much of us have no knowledge at all on NES dev, however I believe everybody will be thrilled to have a part of the NES soft. library on Lynx.

GadgetUK, on Wed May 2, 2012 4:49 AM, said:

It probably would work but only for 32Kb ROMS. The real issue from what I understand is that the Lynx has around 48kb of 'useable RAM' only, if you use double buffering for video. I also understand that you cant easily run code directly from ROM and code has to be copied in and out byte by byte.

I am not sure how you see your recompiler but from the previous messages I understand you see it real-time ?!

[GadgetUK]

obschan, on Wed May 2, 2012 7:48 AM, said:

GadgetUK, on Wed May 2, 2012 4:49 AM, said:

It would be a lot of work, and since theres hardly anyone interested its probably not worth the time.

I think you don't get much answer because much of us have no knowledge at all on NES dev, however I believe everybody will be thrilled to have a part of the NES soft. library on Lynx.

GadgetUK, on Wed May 2, 2012 4:49 AM, said:

It probably would work but only for 32Kb ROMS. The real issue from what I understand is that the Lynx has around 48kb of 'useable RAM' only, if you use double buffering for video. I also understand that you cant easily run code directly from ROM and code has to be copied in and out byte by byte.

I am not sure how you see your recompiler but from the previous messages I understand you see it real-time ?!

Yes, it would be real-time - ie. already re-compiled to run on the Lynx, I guess it wouldnt be as easy as I first thought though. If the Lynx ROMS were just mapped straight into the 6502 address space it would be far easier. The big problem is understanding the Lynx really. I might come back to this idea once i've played around with the Lynx dev kit.

[obschan]

GadgetUK, on Thu May 3, 2012 3:24 PM, said:

Yes, it would be real-time - ie. already re-compiled to run on the Lynx, I guess it wouldnt be as easy as I first thought though. If the Lynx ROMS were just mapped straight into the 6502 address space it would be far easier. The big problem is understanding the Lynx really. I might come back to this idea once i've played around with the Lynx dev kit.

An emulator will certainly give you lots of hurdles. You'll have to keep all your emulator code and both hardware specifics into memory, then not sure you can get enough CPU ...
In my opinion the best solution will really be a recompiler than an emulator, using your already existing NES emulator to write Lynx asm, there you can do all the memory and video resizing work.

[GadgetUK]

Sorry I think Ive missunderstood the question about real time. The idea is for win32 based code to decompile the nes code, add jumps in place of routines that read and write to sound, controls, and gfx and have suitable routines that map lynx bits to results nes code is expecting, eg read of certain address to check vblank, or read bits at address to check button status etc. the win32 code would also convert nes tilesets from rom to lynx suitable format and create a palette mapping from nes to lynx. The output would be a lynx rom that inits the lynx hardware, starts execution of the nes code - which should have been modified by the win32 code to alter any relative, direct and indirect jumps etc. then when any calls to gfx, sound, controlls are made the cpu would use the stack to pass any variable related to the original opcode to a new lynx routine, passing back (if required) the result. Any lynx gfx routines could work with the tileset already in lynx format from the rom directly which would already be in lynx format (but may need scaling down).

[karri]

Hey. This sounds as a cross-compiler. I have used the portable Southampton compiler for this purpose. I needed to do automatic translation from parallel Occam to C. It took me around 6 months to fine-tune the cross compile to produce maintainable C-code.

This is not so complicated as it sounds. You parse the entire NES object code and create an object tree in memory of the entire program with graphics, sounds etc. Then you just edit the object tree to replace the NES hardware dependencies to Lynx hardware. The final step is to output Lynx asm code that can then be fed to a lynx compiler for producing a cart.

My guess is it takes a year to get it done.

Once the cross-compiler is ready you can toss any NES games to it and enjoy the Lynx games it produces.

--
Karri

[obschan]

Sounds like a good plan, hopefully you'll find motivation to work on it.

[philippe]

With a resolution of 160x96 and 16 colors, the Intellivision was a really good machine at its time.

http://knox.ac.free.fr/index.php/inty

Edited by philippe, Today, 2:48 PM.