Bastian Schick Interview: Opening the Atari Lynx and Jaguar

Before Bastian Schick and Lars Baumstark had official Lynx documentation, they had a damaged handheld, a dumped copy of Gauntlet, and a homemade SRAM cartridge. Changing the game usually left it frozen. Then one modification worked, and they had a clue: part of each cartridge sector was escaping the checksum.

Schick wrote a disassembler, then a small 65C02 simulator, while Baumstark worked on the hardware. Their experiments grew into a Lynx with a keyboard, development tools other programmers could use, and games such as T-Tris. The Jaguar brought another set of processors to explore, along with the BJL development system.

Carl Forhan of Songbird Productions introduced us and insisted that we ask about both machines. Schick is still writing Jaguar assembly today, working toward the Cybermorph-style 3D engine he has wanted for years. Here he shares the experiments, tools, and community memories behind that work, along with photographs of the hardware and handwritten notes that survive.

For more from the same Atari community, read our interview with Carl Forhan of Songbird Productions.

For the wider story of the console, read our Atari Jaguar history, from Atari’s hardware ambitions to the games and developers who kept working with it.

Still chasing a Cybermorph-style engine

Retro Replay: Before I drag you back more than 30 years, what are you actually working on today? Carl told me you are still tinkering with Jaguar code, and judging by your recent Lynx and Jaguar demos, he was definitely not exaggerating.

Bastian Schick: For the 10th time I think, I am working again on a 3D engine. I always wanted to have my own Cybermorph like engine and it makes some progress. Lynx is currently set aside.

Retro Replay: After all this time, what is it about the Lynx and Jaguar that still makes you want to sit down and write code for them instead of simply moving on to newer hardware?

Bastian Schick: I like to write assembly and Lynx and Jaguar are machines which are powerful and not to complicated to program which offer graphics and sound. Plus there are decent emulators to help me program and test on my Mac so I can code everywhere. And, I am lazy. I know (kinda) these machines.

Getting their own code onto the Lynx

Retro Replay: Let’s go back to the beginning. What originally made you look at the Atari Lynx and think, “I want to get my own code running on this thing”?

Bastian Schick: It wasn’t actually me. Lars came an said, hey, why not code for this machine. I was a Z80 and 68k guy, therefore the Lynx was not on my list.

Retro Replay: You and Lars Baumstark initially did not have an official Lynx development kit. How do you even begin reverse engineering a closed game system in that situation? What were the first clues that made you think you could break into it? You have mentioned that Atari made a mistake in the encryption of Gauntlet that helped you get your own software running. What exactly was the mistake, and what did discovering it unlock for you?

Bastian Schick: Lars (and I), we always wanted to know the inner details. No matter what. So Lars opened up his first Lynx and somehow damaged it. So he got a connector for the Lynx cards. He is a good not to say brilliant electronics guy, so he discovered the method how the Lynx carts are read and dumped bundled game: Gauntlet. We knew a bit about the inner workings by the FAQ by Robert Jung (https://www.consoledatabase.com/faq/atari-lynx-faq-robert-jung/) which was floating around. So we knew it is an 6502, so I wrote a small disassembler to check what was in these 128K. Meanwhile, Lars developed an SRAM card and I wrote a small tool for the ST to write the image back. And it worked. Then we started modifying the ROM. Mostly we got a freezing title because the checksum was wrong. But then, all of a sudden, the game worked with the modification! We new, the Lynx cart is made up of “sectors”, 256 in total. So Gauntlet had 512b per sector. And, 🙂 , the second 256 bytes could be modified without freeze. => The first bug Atari made: The checksum did only check 256b!

Now, we searched for code sequences and register accesses and placed our own code, first an endless loop there. We found a place and found out where the screen memory is and made a small program to read out the boot ROM in binary. See attach IMG_2149.jpeg, which is this dump. In order to understand what the ROM does, I wrote a small 65C02 simulator and learned about the boot process: – 5 chunks of 51bytes are decoded and stored at $200 – the ROM jumps to $200 – the title screen is loaded using some kind of directory – the title screen is displayed – the complete cart is checksummed – if ok, the game is started

Here the second bug Atari made: The directory is not part of the encrypted header and the checksum is made _after_ loading.

So what I did is, I changed the directory entries destination address to the pointer _after_ loading and the contents of the image with my code => Tadaaa!

From this point on, we could write our own stuff.

Attached also an image of the RAM card in the writer.

Retro Replay: Lars eventually built hardware while you worked on the software side, including your own SRAM cartridge and even a keyboard-equipped Lynx. What did that homemade development setup actually look like on a desk in the early days?

Bastian Schick: Attached also picture with the keyboard attached via SRAM cart to the Lynx.

A keyboard, a debugger, and unexpected documentation

Retro Replay: You wrote a small operating system for the Lynx as part of those experiments. What could it do, and how far were you trying to push the idea of treating the Lynx almost like a tiny general-purpose computer?

Bastian Schick: One could load programs via ComLynx, disassemble or assemble them. Step through them. Together with the monlynx ( 😉 ) running on ST, you could fully debug Lynx code.

Retro Replay: Before internet documentation and mature emulators, how did you figure out what undocumented hardware actually did? Was it mostly experimentation, logic analyzers, crashes, test programs, or simply changing one thing at a time until the machine revealed itself?

Bastian Schick: Some infos where floating around. We analyzed the code and found interesting looking sequences and modified these to see what happens and slowly got some idea.

But we had luck: We showed the Lynx with keyboard at the Atari Fair in Duesseldorf and a guy saw us. He had engaged two developers to write for him a driving school program for the Lynx but after 1 year, they did not have any progress. So he asked us, we said yes and all of the sudden we had the real documentation at hand. You could guess, how many “Ah”s and “Oh”s came out of our mounds while reading the docs.

Retro Replay: What ever happened to that driving-school project that unexpectedly gave you access to the official Lynx documentation? Did you and Lars actually finish it, and does any version of it still exist today?

Bastian Schick: Yes, it was even sold. But was no success. The idea was to much ahead in time. Today they all use cell-phones to learn. But 25 years ago the driving schools did not accept it.

https://atarilynxvault.com/lynx/game/PITSDrivingSchool/22260396

Retro Replay: When you finally had Atari’s real documentation in front of you after reverse-engineering so much yourselves, was there anything you discovered where you realized, “Wow, we had this completely wrong,” or something the hardware could do that you never would have figured out otherwise?

Bastian Schick: Can’t remember specific things. But yes we had this moments.

The biggest “ah”s came from the sprite engine (Suzy). The fact that the Lynx can draw arbitrary triangles (single color) with just two sprites was a big surprise.

Retro Replay: You later helped put the Lynx technical specifications into HTML. Looking back, how important was simply making that information available to other programmers?

Bastian Schick: The Lynx is such a powerful machine, without this documentation, one cannot really understand how to use it efficiently. For example the sprite engine.

Retro Replay: Did you realize at the time that sharing tools and documentation might be just as important to the future Lynx scene as releasing games?

Bastian Schick: Realize? No. We were hoping to open it to all hackers. And actually, I must have built about 20 or more BLL-cables.

T-Tris, eight players, and a cartridge worth releasing

Retro Replay: T-Tris started because your cousin said she would buy a Lynx if there were a Tetris game for it. Did you have any idea that something you initially wrote essentially for fun would become one of the earliest independent Lynx releases?

Bastian Schick: No. And actually, Lars pushed me to publish it. Only years after we realized that we were among the first “homebrewers” for any console.

Retro Replay: T-Tris also included a save feature, which was unusual for Lynx cartridges at the time. What did implementing persistent storage require when there was no established homebrew cartridge ecosystem to build upon?

Bastian Schick: We already analyzed the Jaguar cart and saw the EEPROM. From my apprenticeship I knew how to program them, so we tried if the simple protocol could be done on the Lynx. Since we had our own carts, there was no problem to add the EEPROM on it.

Retro Replay: Is there something inside T-Tris technically that players probably never notice but that you are still particularly happy with?

Bastian Schick: The 8 player mode 🙂 Many do not know that up to 8 players can play together. And when you empty 4 row at once, the others get a penalty row. The ComLynx code cost me many nights.

Retro Replay: You have described yourself more as a “tools guy” than a game designer. Do you get more satisfaction from making the machine do something new than from actually designing the game built on top of it?

Bastian Schick: Writing a game is fun the first 80%. The remaining 20% are painful: Debugging, music, quirks. I don’t have the stamina to go through this. And making a tool, only coders complain not gamers.

Retro Replay: S.I.M.I.S. grew out of experiments such as your Space Invaders-style game and Isolation. What do you remember about the thought process of turning those experiments into an actual physical release?

Bastian Schick: I was happy with the state of Invaders but thought it is not worth the price we had to ask for. I mean, look how people complain these days for paying 70USD for perfect games!

So I was checking what else to put on a multi-game cart and luckily Matthias Domin provided Snakes. Isolation was a BASIC game I saw in an ST magazine.

Three CPUs and a different way to program

Retro Replay: You were doing this at a strange moment when Atari had essentially abandoned the Lynx commercially, yet people like you were just beginning to discover what independent developers could do with it. Did it feel like the machine was dying, or did it almost feel as if it had finally become yours?

Bastian Schick: Atari’s death (really, today’s Atari is not Atari) came at the time when I started my first job. I had to learn PowerPC, ARM and C166 assembly and to write an RTOS, so my Lynx/Jaguar coding more or less stopped.

Retro Replay: Carl Forhan told me to make sure I asked you about the Jaguar as well. What initially attracted you to that machine from a programmer’s point of view?

Bastian Schick: Three CPUs! And a blazing speed of 26MHz.

Retro Replay: The Jaguar has a reputation for being notoriously difficult to program. Is that reputation deserved, or is the real problem that developers approached its architecture incorrectly?

Bastian Schick: Pff. It has it quirks,yes. And sometimes these bugs get you up the wall. But it can be handled by following simple rules. The Jaguars problem was (IMHO) that it came out at a time where game developers already embraced C and did not want to write Assembly anymore.

Retro Replay: You have said that to get the most from the Jaguar you really need to move away from relying on the 68000 and think in terms of the GPU, DSP and Blitter. How different is that mindset from conventional console programming of the era?

Bastian Schick: That’s it. The 68k was to slow and blocking the bus, but GPU and DSP could not be programmed well in C due to its small RAM.

But I never coded any other console besides Lynx and Jaguar.

Retro Replay: One of the strangest Jaguar limitations is the tiny amount of fast internal GPU memory. How much of high-performance Jaguar programming becomes an exercise in constantly deciding what code and data should be moved in and out at exactly the right moment?

Bastian Schick: Sure, you need to be careful and maybe twist code and data. But actually, programmers in the late 90s on PCs who needed good performance tuned functions to fit into the x86’s cache. Jaguar coders only had the burden to load the code into the “cache” themselves.

With JagTris I showed very early that it is possible to write GPU/DSP only programs.

Retro Replay: Are there famous Jaguar games where, from a programmer’s perspective, you can immediately tell that the developers were fighting the hardware rather than working with it?

Bastian Schick: I was thinking about this question long time, but nothing jumps into my mind directly. I saw some game sources, and most are well optimized. But often it seems the fight was not against the hardware but the release date.

BJL and the developers finding their way in

Retro Replay: You and Lars created the BJL development system as a much cheaper alternative to official Jaguar development hardware. What was the original goal behind BJL, and when did you realize other people might actually start using it?

Bastian Schick: We wanted to allow any demo coder to write code for the Jaguar. A friend even founded a company (Phobyx) to get the hardware docu which was under NDA. I added JRISC to the Lynx assembler (lyxass, I know it sounds weird spoke loud in English, but I was young and School-English was my only source) and made a debugger (debjag) to help developing.

Retro Replay: Do you remember the first time somebody you did not personally know told you they had successfully gotten their own Jaguar code running because of BJL?

Bastian Schick: The German Atari ST scene quickly used it and started. We even had meetings with Atari officials and showed impressive demos some hackers made, but then Atari died 🙁

Retro Replay: You mentioned meeting with Atari officials and showing them impressive demos created by hackers using the development tools. Do you remember who from Atari attended, what you showed them, and how they reacted? Was there ever any serious discussion about Atari formally supporting or encouraging this new wave of independent Jaguar developers before the company effectively disappeared?

Bastian Schick: I have no names of the Atari staff we met at the fair in Duesseldorf.

Norman Kowalewski (hope I get the name correct) even met us at my home to discuss Jaguar development. He was from Atari Germany.

Retro Replay: Looking back now, how important do you think inexpensive tools such as BJL were to the survival of Jaguar development after Atari itself had moved on?

Bastian Schick: Maybe something else would have poped up. But I think, it showed others that it is possible to hack this machine. I want to think SKUNK and JagGD were inspired by us.

Sharing the work, and calling it third-party development

Retro Replay: Carl’s own history overlaps with yours because developers were sharing tools, documentation, discoveries and code with one another. How small was that early post-Atari community? Did essentially everyone experimenting with these machines know everyone else?

Bastian Schick: Actually I think it was rather spread. The problem was that the Lynx and Jaguar died to quick. We had some mailing lists but since we all grew older got kids and jobs it kind of faded out.

Retro Replay: Was that early community collaborative, or were people sometimes protective of technical discoveries they had made?

Bastian Schick: Oh, in the beginning we were quiet open and shared our stuff and not like the “demo-scene” which was very jealous not to share anything. I still live this spirit so I am bit frustrated when new folks enter the scene which use our knowledge in one or the other way and hide there sources for demos.

Retro Replay: You mentioned being frustrated today when newer developers benefit from decades of shared knowledge but then keep their own demo source closed. Do you think the openness of that original Lynx/Jaguar community was essential to keeping the machines alive? Is there a particular discovery, tool, or piece of source code that only exists because someone chose to share rather than keep it private?

Bastian Schick: Nothing special. Programmers learn by reading others code. This can be small pieces that someone solved in a specific way and you think, wow, that approach would help me.

Retro Replay: Today we use the word “homebrew” very casually, but when you were doing this in the mid-1990s there was barely an established commercial model for independently releasing new games on discontinued consoles. Did you even think of yourselves as “homebrew developers” at the time?

Bastian Schick: No, we were 3rd party developers!

Retro Replay: Your answer that you considered yourselves “3rd party developers,” not homebrew developers, really caught my attention. At what point did you first hear people begin calling this kind of work “homebrew,” and do you think that term actually understates how seriously you and others approached development at the time?

Bastian Schick: I can’t really remember, but must have been after 2000.

Retro Replay: Were there moments when you worried Atari or another rights holder might object to people modifying machines, replacing ROMs, publishing documentation, or creating unofficial development hardware?

Bastian Schick: Atari was very open from the beginning. At Duesseldorf Atari fair we showed the Lynx with keyboard to Atari folks.

With BJL, they thought it would be a good multiplier.

Some told me, I will get in trouble with T-Tris with Nintendo or CBS (Star Trek sample). But we did not care.

Retro Replay: One thing I find fascinating is how much influence tools can have indirectly. Duranik, for example, credited receiving your BLL kit as part of what led them into Lynx development. Are there projects that exist today where you occasionally think, “That might never have happened if we hadn’t shared that tool”?

Bastian Schick: I think the Jaguar SKUNK only could be developed with a BJLed Jaguar. I think we made it happen just a bit earlier.

Tiny demos and a very long project list

Retro Replay: You are also active in the demo scene and continue producing extremely tiny Lynx and Jaguar intros. What is appealing about deliberately limiting yourself to something absurd like 128, 256, or 512 bytes?

Bastian Schick: At first: It is a project with a clear dead line. Writing a large demo or game is complicated. You need to coordinate artists and coders. Second it is like a puzzle where you have to think often unconventional.

Retro Replay: Does writing a 256-byte Lynx or Jaguar demo teach you things about the hardware that writing a conventional game sometimes does not?

Bastian Schick: It is a different approach to solve problems when the limit is size and not FPS (frames per second) and sometimes the tricks you apply in size-codeing work as well for conventional code. And yes, you learn some stuff about the hardware because you need to exploit stuff to the the one or the other byte.

Retro Replay: After more than three decades of programmers studying these machines, are there still Lynx or Jaguar behaviors that surprise you or remain poorly understood?

Bastian Schick: The Lynx is very well understood. It is an impressively error-free system. But the Jaguar sometime make me wonder when certain code simply does not work.

Retro Replay: If Atari’s original Lynx or Jaguar hardware engineers sat down with you tomorrow, what is the first technical question you would finally want answered?

Bastian Schick: To the Lynx II designers: Why did you remove the NMI pin? To the Jaguar designers: What did you think when you designed the case?

Retro Replay: You once experimented with attaching much more powerful external hardware to the Lynx. Do you still like the idea of treating the cartridge port as a way to radically extend what the machine can do, rather than simply storing a conventional ROM?

Bastian Schick: Every now and then, yes. Brian Peek made an EPROM emulator and I always wanted to pimp it to act as GFX chip. But this is on my very long “list of things I always wanted to do”.

Retro Replay: If you had unlimited time today, is there one Lynx or Jaguar programming experiment you have always wanted to finish purely because you want to know whether it can be done?

Bastian Schick: Yes, the above. Running some ARM board attached to the Lynx port.

Retro Replay: Looking back at the early Lynx and Jaguar scene, is there a person, tool, website, mailing list, discovery, or project that modern histories tend to overlook but that deserves much more credit?

Bastian Schick: I think Harry Dodgson was the first to finally crack the Lynx decryption. Just before Atari made it public.

Thanky you Bastian!

Thank you, Bastian, for sharing your memories, photographs, and the stories behind your Lynx and Jaguar work. Take care, and we look forward to seeing where your next experiments lead!

Explore Bastian’s Lynx and Jaguar work

Browse his Lynx development pages and BJL Jaguar development pages.

Visit Bastian Schick’s website for his Lynx and Jaguar pages, tools, and downloads. His answer about the driving-school project points to the PITS Driving School archive entry.

Our thanks to Bastian Schick for sharing his memories and archival photographs, and to Carl Forhan for connecting us.