Nop90

I read only now you would have pay money for it. ? I hope you'll enjoy your patched rom. I don't think it's so funny using infinite tools, but it was funny for me applying this simple patch and finding a way to pass the code hash check in the stage 1 loader.

Thank you, I confirm it works fine for me too.

I have no luck. The version you posted crashes when the event happnes. I also tried a different approach with this script ram.r[0xc5] = function (value,address) local file = io.open( "trace.txt", "a" ); file:write( "Read 0xc5 at " ); file:write(address); file:write( "\n" ); file:close() return value; end this works fine, but address is not the the PC value, but the read addrees, so at the moment it's of no use. Is there a way to access the PC value from lua? What I'm trying to do is to patch the Lemmings rom to add cheat codes: a user on the forum asked me to modify the rom to have infinite tools in every levels (I have the addresses in ZP to change from a mednafen cheat file). The funny thing is that with Felix it's very easy to add these cheats using a lua script: ram.r[0xc5] = function () return 10; end ram.r[0xc6] = function () return 10; end ram.r[0xc7] = function () return 10; end ram.r[0xc8] = function () return 10; end ram.r[0xc9] = function () return 10; end ram.r[0xca] = function () return 10; end ram.r[0xcb] = function () return 10; end ram.r[0xcc] = function () return 10; end

I'm trying to test the debugger, but with this lua script log = "trace.log"; ram.r[0xc5] = function( value ) traceCurrent(); return value; end I receive the error: global 'traceCurrent' is not callable (a nil value) I'm doing something wrong?

Is Felix already able to use comlynx emulation?

I don't know if I could complete something this time but, I'm in.

The walking animation is much better now. I completed the two player mode but there are problems in sicronizing pause/reset/music changes I already did it in Biniax 2 but it always take a ot of time. Aother thing that I have to implement is an alternate control mode with moves actvates by a sequance of keys (like defending pressing back twice) butI'm not good at defneing such things, I'll need an help.

After 9 months of pause I'm back to coding for the Lynx and completing Starblader is my priority at the moment. Just now I'm fixing the two players mode, while the single player mode is under test by the other members of the team. Don't know if we can finish everything for 'xmas but we'll try because everything is ready to start the production of the phisical carts. PS: @Igor the old rom on Atarigamer doesn't load (gives an error) but it was working previously. Can you check why please?

I can be programmed in whatever language that has a compiler for the 6502 CPU. At the moment C and ASM are the main options. Some knowledge of ASM can help to do tricky things on the system and most of the high level compiler can handle part of code written in ASM. Of course, everything can be rewritten as long as the game can fit the small screen of the lynx and the resources can be adapted to stay in the small memory of the Lynx and in the relatively small capacity of a lynx cart This can be true talking of porting existing sources, but porting games from other systems to the lynx usually requires much more effort than writing it from scratch. Rewriting a game from scratch is a creative process, often it require some "demake" like happens more and more often these days on pico-8

I don't know how much serious is the OP but I'm answering seriously because this section is for coders (that use to be serious people as long as they stay away from beer). From wikipedia (bold is mine): Lynx has almost the same CPU power of the SNES in 8 bit mode, but has a completly different architecture. Both Lynx and SNES haven't enough CPU power to emulate the HW of the NES. Thanks to 3 years of work of a talented coder the SNES can use its custom hardware to behave like the HW of the SNES, but the graphic chip of the Lynx (Suzy) can't reproduce the features of the NES GPU (e.g. the NES GPU has internal RAM and can handle sprites). It's not a matter of mapping register position to different locations, they work in a completly different way. Not to say that they use different CPU. Yes both are derived from the 6502, but both are customized, have additional hardware and probably their illegal opcodes works in different ways (and we know that game coder love to use the illegal opcodes to create nice tricks ?). I learned how hard can be adding retrocompatibility to old HW trying to run VCS code on the Lynx, obviusly in the end I failed (but... ?). So there is no hope to emulate the NES on the Lynx. If someone can prove I'm wrong, I'll be really ... really ... really happy!

Yes, but ther is no ETA. the coder is very lazy this year. Probably it's the Covid isolation.

Does retroarch need the lynx firmware file? Try adding it if you don't have it.

Sorry for the dalay, only now that I started my vacation I have some free time. Attached there is a working example. In a zip there are the sources, in the other a compiled test rom with the data file to be put in a folder names Saves in the root of the SD. You can't create a new file but you can open and read/write an existing one. testrom.zip testGD4.zip

Let me check my old code (summer 2020), I f I remember well I was able to read the SD if the EEPROM emulation was not enabled. I asked a firmware revision enabling to use SD and EEPROM at the same time, but there was no answer.

this is how I'm going to implement bombs they work fine in the left side of the screen or in rows without fixed platform, but there is no time to switch to solid gray near the end of the scanline, so I'll have to design new levels considering this limits. The teleport platforms should be an easy element to add. Probably I will not implement the one-way tiles.

The sound, yes. At least I have It as a TTT export and will be played as soon as I complete to reorganize the code in banks so to have space to place the Tia tracker engine in the main bank. For the floating part I'll try. With a 48 px sprite not only I have to adjust the x pos of the first sprite every frame but I also have to adjust the timing of the drawing routine. I'll try.

Today coded the Retroguru splash screen and a mockup of the title screen (upper part will be also used for the menu). I'm not very good with graphics, but I'll ask some help to the gfx guys of the team to improve the overall look.

As promised here is a simple small video of what I coded so far: Level restarting/changing isn't in the game logic yet. I use the Reset/Select switches for the moment. The code already reached 4KB, so before the next update I have to select the best bank switching strategy to use. Meanwhile @miker made a nice conversions of a couple of Xump music tracks with Tia Tracker. Probably now I'll start coding the title screen and the menu screen with one of the tracks as background music.

The level logic for simple tiles is complete and also added a level timer. I have only to fix the position of the score numbers to have it in center (tried to do it but made a mess witht the timing, probably I'll write it from scratch instead of trying to adapt the code snippet I used). The level drawing is very tricky, so much that adding the bombs on the tiles seems impossible. But I don't give up. Don't know hot to make a video, does Stella has a video recording feature? I could record with my mobile the game on a TV, but I used NTSC colors and I have a PAL 2600JR so the game colors are really ugly on it.

Hello, I use to be active in the Atari Lynx section, but the 2600 was my very first console so last week end decided to try to code something for it, and since I'm one of the coder of the Retroguru Team, I started to port a game of ours that I already ported to other consoles, included the Atari Lynx. I'm not a 6502 ASM expert, but I code in ASM for the Lynx when I need to do things not possible in C, and I know the VCS achitecture because last year tried a crazy project to run 2600 code on the Lynx: obviusly I failed for lack of CPU speed - how I could hope to race a code that race the beam - but at least implemented a big part of the core of the system). What I did do for this new project far was to collect a lot of 2600 code snippets and assemble them to have basic rendering core and enough free ram to be able to complete game logic. This is what I did in a couple of days of work: I added 5 different levels that can be changed with the select switch. The level can be reloded with the Reset switch (losing a life in the final game). The player can run along all the level screen with 4 different sprites (for the 4 directions), now I have to add the logic to remove the tiles after stepping on them and check if xump goes out of the path. Should not be hard because the worst part was to draw the screen, the other things goes in the VBLANK. I should have a tech demo to show in a video in one or two weeks (I also have to work other lynx project so can't code on this every day), but at the moment really don't know how to add the missing elements of the game like the bombs and the one way tiles because I have only two cycles left in the scanline rendering routine of the level. I think the result so far is promising. The GFX guys of the Retroguru Team are complaining that they don't like too much the screen layout, but they grew up in the Amiga era and can't understand the lack of a framebuffer ?. Every hint to make the playfield look better is welcome. I really hope to make something playable from this. I like to solve coding issues on my own but If I really need help I'll ask here.

Competition Rom is already available as will be the updates when released. A cart release is planned, but the producer we contacted is new to the Lynx market so he needs time to setup everything. We are considering to produce it only for the Europe and find another producer for North America, this way the shipping cost should make the final price too high, but nothing is defined yet. Meanwhile I'm completing the game and adding more thing. But I'm late with my schedule, expecially for the comlynx mode that needs a lot of debugging.

Yes, Biniax2 has the old code that hangs on the new cart (can be considered a kind of copy protection ?). I already fixed it for my personal use, but the rom for the moment is not intended to be freely released. When I started this project my idea was to leave Carl publish the game on cart and release both rom and sources to the community. Then Carl asked me to not do it because puzzle games don't sell too much and he needs time to return on the investment. There isn't a formal agreement betwen Carl and me about this, but I respect his work and for the moment the rom image will not be shared. I kindly ask the community to do the same and not share digital copies of the game. There are many other games of mine released for free. If there are other games of mine not yet fixed let me know, and I'll do it.

This is possible, but when I experimented the comlynx protocol such configuration was affected by several problems to the sychrony of the game (especially music/sfx start, pause and reset events, other timed events). In the end I decided to have only 1 Lynx to apply the game logic to a game state struct. This is sent from 1 lynx to the others, while the others act only as controllers. Not efficient but much easier to code. I'm curious to know what is the strategy adopted by @sage.

Tunes are made by @miker with Chipper. He has a huge collection of instruments and a lot of experience of atari music composition.

Final boss fight almost completed