ThomH

As a follow-up thought, two screenshots are below. One is from an 8-bit machine, the other is from a 16-bit machine. Arbitrary bit counts mean nothing.

See clean room design. Your design is not a clean room design. It is therefore not clean in the software sense. Hence its redistribution is of questionable legality — see Sony v Connectix, which I think is exactly applicable here as it covers a situation where the original ROM was disassembled in order to reproduce its functionality without copying its code. The original court decided for Sony, the first appeal court decided for Connectix and then Sony bought Connectix before it could get out of the US district courts. Which sadly leaves us without a pronouncement from a reliably senior court. It means you write whatever code you want in the encrypted part of the cartridge (usually referred to as the boot loader, such as here or here) and then whatever code you want in the unencrypted part. Do whatever you want. Epyx's questionable decision to pretend there was a filing system is of no relevance. You could follow Harry Dodson's route and just load some data immediately after the encrypted portion and hop into it. You could use an Epyx-style filing system. You could use absolutely any other filing system, whether FAT16, ADFS, BetaDOS or whatever. You could encrypt your entire program code, if it's small. EDIT: I think my tone has become too negative, so I'm editing to repeat that it's fantastic that you expend your time and energy into Mednafen and into other Lynx emulation improvement tasks such as this one. From what I can see, you do good work and are a benefit to the community, and I'm sure I'm not the only one that wants to say thanks.

You have seen the original source code before reimplementing it. That's the legal test. There is no argument there. It's a question.

I'm another person who can't claim anything beyond Shadow of the Beast, sadly.

'Photographic' graphics are much less likely than 'cartoony' graphics to compress well with the RLE scheme used by the Lynx hardware. I also have to take issue with your 'it's' graphic; what about 'it has'? Like if I said "it's been fun!"

Fantastic work! So it's a new drop-in ROM replacement for any old emulator, that I could in theory use on original hardware? From a legal point of view, you're contaminated by having posted on this thread before producing your ROM, given that the original source code is listed right there at the top. Except that Hasbro's release of development rights into the public domain (which there are lots of second hand sources for, but I can't seem to find the original announcement) definitely means that nobody's ever actually going to sue. I'm on-and-off working on a new development environment, in which you write whatever code you want for the encrypted bootstrap. If you wanted to go with the serial media metaphor then that'd be your own business, as I certainly won't be going to any effort to support it. I'm probably still a few weeks away from having any working ROMs but would it be helpful to send some over with a variety of boot schemes when the moment comes?

The big difference between the early-90s battery munchers (the Game Gear, the PC Engine GT and the Lynx) and the Gameboy seems only to be the screens — and especially the backlight. I would imagine that once you've thrown a backlight in, everything else is pretty much just tinkering around the edges. Though CPU sleep that worked properly would have been nice... Anyway, I don't accept that Atari's big problem was hardware. Like in the dark, I think think it was software, though I'd be more likely to cite a failure to attract (and possibly even to court?) third parties. If you look at the international trajectory of the Mega Drive, it was initially the EA titles that supported it and then Sonic that launched it into the stratosphere. Given that Atari was owned by Tramiel at the time and the Lynx hardware follows a lot of the Amiga conventions, I think the smart thing would have been to do whatever it took to get the European Amiga-oriented houses on board. Competing with Nintendo for the Japanese console game houses probably wouldn't have worked and if you look at the work of Psygnosis (the only third party house outside of the US?) it's really very good. Of course, it's always easy to pick a strategy in retrospect. EDIT: I found this page, which clocks a Lynx 2 at drawing 280mA in total, of which 200mA is the backlight. So that's more than 70% of the power being drawn by the backlight. He makes an unsuccessful attempt to switch the original unit with more modern lower power white LEDs; presumably someone could manage this successfully?

It's a safe bet that any other CPU would have decreased battery life. I'm not sure about the SC02 but the original 6502 is notable for using just 3,510 transistors, just a shade more than the 8080 and less than half the 8,500 in the Z80. If all other factors remain constant then more transistors means more power usage. I think I also read that the 65SC02 was selected because it was available as an IP core — much like ARM processors are nowadays — allowing you to embed it within a chip alongside a bunch of further logic. In the Lynx it sits in Mikey, along with bits like the video repaint stuff (i.e., the systems that collect, encode and transmit bytes from memory to the LCD; Suzy does the hardware drawing), audio and timers. So a switch to any other CPU would have added an extra discrete chip to the board, at the very least. And if you want more RAM too then obviously you're going to have to pay for that — though if the address space were large enough then completely dumping the tape metaphor and just putting the ROM into normal address space would solve that problem. That all being said, the 65816 is in any case a horrid fudge. If you're allowed any '16bit' processor then the 68000 is the smart choice. If it needs to be 8bit then the 65SC02 is actually probably the smartest choice; for programmer convenience the 68008 would probably be the way to go.

I've been a homebrew Lynx developer on and off for about a decade, am the author of this and the other Lynx (and the Freescape, Acorn Electron and Sam Coupe projects also shown on that YouTube account) and have three years of professional experience as a writer/editor. Is there anything I can do to help? I'm completely financially stable so I'm not fishing for a commission.

If I could make a feature request: is there any way the emulator could expose the debugger (and maybe simple additional functionality, like transmitting a cartridge image) via an HTTP service? I'm a Mac user, so another person that falls broadly into the 'not Windows' camp, and primarily working on development tools at the minute. It'd be great if I could control the emulator from within my own tool (such as for step debugging through source code) and an HTTP approach has the advantage that it can work across a network — whether a real one or, more probably, the emulator in a virtual machine underneath whatever other OS. Also as a Mac user, and someone admittedly quite ignorant about the exact limits placed on browser Silverlight, if you could get a working build there then it'd be really useful for me. I appreciate that Silverlight is being killed off as a plug-in though, so I completely understand if it's not worth expending the effort on.

The available evidence seems to be that LX.NET's emulator is a conversion of the Handy sources into Microsoft CLR managed code — so that's not going to become portable any time soon — and mednafen is just a direct lift of the Handy code. I think I'm right to say that Microsoft still support C++/CLI, which is a very close relative of standard C++ that works in Microsoft's virtual machine but I'm not sure how well catered for it is in terms of tools or whether it has the correct bindings to work in places like Windows Phone 7 and on the XBox. Incidentally, I've checked the scans of the original Epyx documentation provided on this site and the 4 Khz lowpass filter figure is given in quite a few places, meaning that it's definitely not an OCR or transcription error and probably not a typo. To put things in perspective, per Nyquist that's the same as saying not to bother recording (or, with an emulator, outputting) Lynx audio at anything above an 8 Khz sampling rate because the higher frequencies just aren't there. I guess they had an eye firmly on the quality of the internal speaker. It's a yucky mediafire link, but a sample of pure 4 Khz tone is here to put things in perspective. It sounds quite high, but normal human range across all age groups is considered to go up to about 20 Khz and even as someone who was the right age to be in the target audience when the Lynx came out I'm still able to discern a little above 13 Khz.

You know the Sam Coupé version works fine with the mouse though, don't you? Even though the only Sam emulator I'm aware of, Sim Coupe, has the mouse interface switched off by default?

This is exactly how I've written my emulators in the past. Audio events coming from the real hardware are timestamped and queued; they're dequeued at exactly the right moment in the stream when the audio output is being generated, and audio is generated when the OS requests another audio buffer. With some simple logic to dash ahead quickly through the queued events if the output falls too far behind the input and to pause if it gets too close to catching up and suitably small buffers the latency is kept within a sufficiently reasonable range not to be noticeable. I'm no expert on the Lynx sound hardware specifically but in order accurately to reproduce the source data you should technically construct the source wave at its original sampling rate and then apply a filter to reduce it to the 44.1Khz or whatever you have for output. It's DSP stuff that tends to sound complicated but one way or another you end up conceptually doing a weighted average on a sliding window and then point sampling (except that as an obvious optimisation you actually just need to work out the weighted average at the points you intend to sample). I can offer a not particularly optimised implementation of a Kaiser Bessel filter from my current emulation project if it's helpful. What that'll effectively do is what the analogue filter inside the real Lynx does — albeit that the '4 Khz' cutoff given in the public documentation is almost certainly a typo. If there's anything I can do to help, I'd be more than willing.

Why even bother with that? Just reimplement the algorithm as given above, giving compatibility with every existing ROM, every prototype yet to be rediscovered and every homebrew yet to be written.

I would imagine that a lynxboot.img replacement could be written but more likely the functionality will just be built directly into the relevant emulators?

I'm a huge fan of BLL and am actually quite happy you posted, since I spent quite a few hours the other day trying and failing to locate the source code — just following the link in your signature got me there instantly! The final link I found is to an Amiga-related archive that Google pointed me to, but expands to a whole bunch of stuff including a buildchk.c that starts with: /* *** buildchk.c *********************************************************** * * Build the Security code -- Handy ROM security code builder * * Copyright (C) 1989, Epyx, Inc. * All Rights Reserved * * CONFIDENTIAL and PROPRIETARY * * HISTORY NAME DESCRIPTION * ----------- --------------- -------------------------------------------- * 5 Apr 1990 Stephen Landrum Created this file. * * *********************************************************************** */ Is that the one? If so then it's quite possibly now free and legal to distribute per Hasbro's release of Lynx development tools into the public domain?

I think you're saying that morally, in the specific circumstances, the sale of ROMs is okay because it does no actual harm to anyone? The counter arguments would be: the conclusion that it does no harm is an inference, not a fact. For all we know someone somewhere has legal ownership of the relevant titles, and e.g. the Wii's Virtual Console is a demonstrable surviving market for otherwise archaic video games; in any case application of the law shouldn't be subjective. Copyright as a whole protects the ability of an author to make a profit, thereby motivating further creative works to the benefit of society. Even if there are exemptions to the general rules that you think would be beneficial (such as a shorter copyright period for ephemeral products or a rule under which properties lapse into the public domain if not exploited for a certain number of years), the point of a democracy is that laws are decided by a body that is elected to weigh up a variety of differing opinions. So ignoring the illegality of something just because you think it is moral is itself ethically questionable.

Dumb question, probably, but supposing someone wanted to set themselves up with a BLL development environment based on this script... lyxass is the assembler provided with BLL and for which the source code is available from your site (from where people will presumably want to fetch the related libraries too) make_lnx comes from Handy and is available as source from github the only lynxenc I can find seems to be for 68000 machines only? buildchk seems to be for Amigas only? I'm assuming I'm wrong on at least the final two bullet points — would it be possible to expand on the tools this script calls?

Think yourself lucky — here on OS X there's a completely functional driver for the FTDI serial driver but not a single terminal program I've yet found that's willing to transmit a file in a suitable fashion. I have to hop into a Windows 2000 virtual machine.

I think EOTB is Eye of the Beholder, which only escaped Atari as a prototype but has been put onto real cartridges since.

Taking away Lemmings and valuing it at $40, that's 15 titles for $160 or $12/title, which is within range of how much the cheapest titles seem to get on eBay nowadays (taking it to be about £8 for us GBP types). Given that at least Jimmy Connors and Battlewheels seem to ascend into the next tier up where eBay types charge more like £10 (which is a little over $15), I think you're looking good. On vaguely the same topic, you're a stronger willed person than I am if you're willing to break the original shrinkwrap. I'm not sure what's happened in the least two or three years but — anecdotally — somebody seems to have found a massive warehouse full of unsold Lynx titles or something as they seem to turn up as frequently and not much more expensively than bare cartridges all of a sudden. With a renewed desire to complete my collection I've acquired quite a few in recent weeks but so far haven't been able to persuade myself to open any of them, even for titles like Battlezone that I've not otherwise played and which people say are good. It's not that I think there's any monetary value to keeping them wrapped, it's a question of untainted aesthetics.

The Wikipedia article seems to link back to information on this site, which includes screenshots. So it's probably true, and likely that somebody has a ROM image or the original source code since the screenshots clearly aren't camera-pointed-at-the-screen stuff.

Well, not the world's most interesting pictures but here they are. The pictured cartridge contains Scrapyard Dog. At the lower left corner you can see where I've peaked to check there's not another label underneath, and there isn't.

I don't think there are any that look like real Lynx carts, but I've seen a few copies of Lemmings, Desert Strike and the other rare ones on eBay that are big fat ROMs on exposed PCBs, making me quite suspicious. Anyway, I'll photograph my Cyberball-that-isn't when I get an opportunity so there'll be no need to take my word for it. Quite apart from looking completely genuine, I can't think of any reason anyone would deliberately have converted one quite common game into a different but very common game, and gone out of their way to obtain the correct instructions poster but not bothered to find a box.

Oh, yes, I recall that my actual transform stuff was for 'small' objects in a much larger space — I can imagine that getting planets in there would have been some effort. It's a shame that you can't step debug your original source with the current free/public tools. I did briefly work on exposing debug functionality in one of my emulators via an HTTP RESTful interface, which would mean that an external tool could remotely control the emulator so as to provide that sort of functionality but that's the sort of thing that's very difficult to organise. Definitely put my name down on the list if you build it. I'm trying to set up suitable development tools to get back into Lynx work, as I continue to think I can do better than Lucien's fantastic work on a first-person dungeon thing as the Wolfenstein ray casting algorithm just isn't that efficient if you think about it. I've also no ideological opposition to doing it as a portrait game, which would obviously be a huge saving from Suzy's point of view, but even failing that I think you could be a lot smarter with texture storage so as to be able to make a much more varied map. All just plans though. I'll prototype it but I accept that I have possibly the world's worst record on follow-through.