Lamer Deluxe tm

Ah, then Atari Gamer got it wrong: "Once updated the Lynx should turn off, if it doesn't then turn it off and back on again. The agacart.bin file should have been deleted from the SD card upon a successful update." EDIT:I was just thinking, does it start loading the game from SD while you are selecting the number, or does that start when the display shows 'P'? If possible that might shave off a second or more off the loading time.

Thanks! That is good to know. What threw me off was that the description mentions the Lynx turning off after the update and the update file being deleted, but that didn't happen.

I used the V5 version, hadn't updated before at all, I hope that is okay. It didn't work with the included SD card. It also didn't work with the first non-HC card. With the second 2GB non-HC card I'm getting 'P' then 'EE', wat does that mean? How do I check the current firmware version?

I can totally understand that. Your Antix website is not working BTW.

Ah, that's a shame. I hope you'll get time to tinker again soon.

Yes, that is correct. The interesting thing would be to make game/demos for an overclocked Lynx. Or even just add an option that would improve visuals/audio. On the other had I was wondering how much work it would be to fix existing games for higher clock speeds, like adjusting audio and timer frequencies and framerates (maybe even the Comlynx baudrate, if possible). If you could achieve that, you could get games to run much more smoothly without unwanted side-effects.

That is a cool project! Did you ever get it to work? I guess it wouldn't fit inside the Lynx. Was just reading my own comments from eighteen years ago, because I was showing off my Lynxes, including the overclocked one (20Mhz) at an Atari event last weekend. Forgot that mine didn't work at 24Mhz. Maybe I should try to repair my dead Lynx, if possible, as that one apparently did go to 24Mhz. The internet is a handy place to store your memory.

I really enjoyed the event. Reading the recap I notice I missed some of the things on display (Scramble is one of my favorite games), there was just so much to see. Right before travelling to the event I was able to fix my VGA cable for my McWill modded Lynx II, it has an edge connector where the brightness wheel was, so no case modifications. The VGA output turned out to work very well. My Lynx I has an overclocking switch, but only to 20Mhz, still need to get a 24Mhz crystal for it. My original Lynx II is autographed by RJ Mical. I showed some demos from Silly Venture using the excellent AGA carts and we played some four player Slime World. Also brought my Portfolio, which has both a parallel and serial interface module and a 64KB (!) memory card. Sadly I didn't succeed in transferring any applications to it. As a small stunt some of us invaded the Commodore club wearing alien masks and kidnapped their leader, while shouting 'Atari!'. We returned him converted to an Alien and were now shouting 'Atari' as well as 'Commodore', 'Amiga', 'MSX' and 'Spectrum' ?

I'd be interested in one, hoping for the slim chance to receive it before the Atari Invasion event on February 15th.

I'd be interested in ordering the updated version for the Atari Invasion on February 15th, any estimations on the ETA?

The thing with the Lynx is also that it has a variable display frequency that can go beyond 60hz. If this handheld doesn't support that you get the same judder issues as with the McWill display.

I'll be there showing some Lynx stuff. Really enjoyed this event last year.

Came across there acrylic stands on Reddit, very nice for displaying as well: https://www.reddit.com/r/retrogaming/comments/ec9owr/bought_a_couple_of_these_acrylic_stands_to/

You're welcome! It was the first time I've seen this model in person, same goes for the SX-64 and some of the more rare Atari models, really enjoyed it.

And some mediocre quality phone photos.

I attached my 3D photos. They work as jpg images, but you can rename jpg to mpo and if they survived the upload, you can view them in 3D. The Lynx photo needs to be pushed back in 3D somewhat for comfortable viewing.

I really enjoyed it. The two Lynx II units I brought became part of the exposition. It was the first time seeing some of the exotic Atari and Commodore hardware. Had lots of interesting conversations with people there and really enjoyed the dinner afterwards. I made a few photo's, nothing really special, some in 3D, I will post them tomorrow.

This sounds interesting, thanks for the tip F#READY! I'm thinking about going, if so, I'll bring my Lynx signed by RJ Mical, my Lynx with new McWill display and a few (interestingly suitable for the event) demo's I wrote for them.

Just a small overview of some of the logic behind creating Lynx games/demos, from the top of my head: All graphics on the Lynx are sprites. Even the backgrounds. Sprites can be upto 511 pixels wide at a height only limited by memory. You could write directly to the display buffer using the CPU (at four bits per pixel for sixteen colors), but this will be much slower for most purposes. Your sprites can be anywhere in memory. Sprites have a small header of data telling them where they should be positioned within a 32K x 32K pixel area. This header also contains the settings for x/y scaling, tapering, sheering, collision settings, x/y mirroring, positioning from top-left or another position, transparent color, RLE compression* and color remapping. In this header you also set a pointer to the next sprite to be drawn, creating a linked list of sprites only limited by memory. In this header you also set a pointer to the actual pixel image of your sprite. Then you tell the graphics chip where the top-left position of your display in this 32K x 32K 'world' currently is (by setting an x and y position hardware register). By changing this position each frame, you can scroll the display in all directions. After that you tell the graphics chip to start drawing your sprites (after you have pointed it to the first sprite in your list). It will start with the first sprite and then draw all the other sprites in the order your list is in. So it will draw your sprites back to front, each next sprite in the list on top of the previous (which you will only notice if they are at overlapping positions ofcourse). A way to make sure everything moves fluidly is to use the vertical blanking interrupt. This will call the function you point it to every time the display has finished displaying one frame. If you change all your sprite positions and anything else you want to animate in that function and then draw your sprites, things will move smoothly (if it is able to handle all that in 1/60th of a second for a single frame). To support lower or unstable framerates, have more time to draw your frames and avoid flickering, you can use double buffering. This means you have one display buffer that is currently being shown on the display, while your sprites are being drawn to another display buffer that isn't visible yet. Then when the vertical blank interrupt calls your function and your sprites have all been drawn, you can swap both buffers, showing your newly drawn buffer on the display. Apart from the vertical blank interrupt, there is also a horizontal blank interrupt. This is called every time a horizontal line (scanline) on the display has been displayed. The time you have here to do something before the next is displayed is much shorter than with the vertical blank interrupt. A common function to use with this interrupt is to change the color of the background for each scanline, this way you can make smooth gradients for a sky or ground (like in Shadow of the Beast and Roadblasters). Changing the whole palette (or any amount of it) at a certain scanline (vertical position) is also possible, but there is not enough time to do this. A solution is to show one or two empty lines while you are updating your palette. The graphics below those lines can then be displayed using this different palette. IIRC Roadblasters does this. Drawing vector lines and filled polygons on the Lynx is all done by scaling, tapering and sheering one or two single pixel sprites. There is some math involved in converting the vector coordinates to these scale, taper and sheer settings. *RLE compression stands for Run Lenght Encoding. A very simple way of making your sprite data smaller in memory. The way this works is you set how many pixels of the following color the sprite engine should draw horizontally. So for instance you would tell it to draw 64 red pixels, followed by 32 blue pixels, followed by 50 green pixels. Which would be much smaller than telling it which pixel color to draw 146 times. This only works well for sprites that have large areas of the same color, like cartoony looking sprites for instance. If your sprite has lots of small detail, meaning the color changes almost every pixel horizontally, RLE compression will actually make the data larger than when not using it. In this case you would be saying: Draw an orange pixel one time, then draw a white pixel two times, draw a blue pixel one time, which would be really inefficient. I hope this information will be useful to someone. I only programmed the Lynx in assembly, which is really close to the hardware. Programming it in C will probably have some different logic here and there.

Wow, fantastic video, great editing! Makes the whole procedure really clear. I like your username

Seconded, I haven't seen this topic before and I'm very interested in checking these songs out.

You can turn the retro effect on and off, so you don't have to use it.

Okay, that is understandable. Cool trick with the backlight button. On the Lynx I by using the backlight wheel, wow, so the position of the wheel sets the display mode? That is really awesome.

Wow, that is some cool news, I wasn't expecting that. Is it at all possible to update the firmware yourself? I have a USB to TTL converter. The Lynx has a vertical scanline effect, because the RGB subpixels are arranged in vertical lines. It makes the pixels look less blocky.

Will the Lynx display receive a scanline option at some point? Is the firmware upgradable at all?