ThomH

No. It has BRA, P[L/H][X/Y], STZ and T[s/R]B. It does not have BB[R/S], [R/S]MB, STP or WAI. STP would have been useless, obviously, and there's an attempt to provide something a bit like WAI externally, in that you can request that the CPU sleep until the next interrupt, but it doesn't actually work properly on real hardware. So you'll just have to sit in a perpetual loop and accept a bit of extra unpredictable interrupt latency.

If I dare throw some speculation into the conversation: As usually described, the instruction set of the Lynx 1 matches that of the Synertek 65C02. It's just a core embedded into Mikey though, rather than an actual discrete part, so one can pretty easily imagine that's where the S comes from — to denote which of the three 65C02s it is like without actually naming a manufacturer. That in the Lynx 2 is like the Rockwell 65C02, which supersets the Synertek. Had there been a Lynx 3, perhaps it would have moved on to modeling the WDC, which supersets the Rockwell? (EDIT: corrected for a poor memory; I had WDC and Rockwell the wrong way around in terms of instruction set size)

Oh my gosh, amazing! Thanks infinitely! I was an Electron owner so my experience of Starship Command is likely to have been even more glacial than yours; on reflection I'm not sure the Lynx is the greatest platform for that game because you need it to be slow paced to give the appropriate heft, but unless you're going to render all the enemies at about two pixels wide you can't really do that. A rotating and zipping about shooter, more like this as far as it got, would work though I think.

Apologies; links above were broken, going merely to alt.games.lynx. They're fixed now, connecting to announcement posts including the original download URLs. I've also managed to get a couple of screenshots from archive.org; here's my Mined Out: And here's Command: Starship:

Being able to purchase a digital copy would be fantastic; no need to put any specific effort into worrying about Handy if it doesn't just work already though.

Fantastic, thanks! Knee-jerk reactions: it looks like an 8-byte buffer for video, and that enabling video disables the normal refresh mechanism. I'm not sure though, I'll play around with the numbers and try to make some more-educated guesses. This is the first step towards figuring out timings total; I thought I'd worry about Suzy once I have a concept of ordinary video activity and RAM access times as distinct from the speed at which the 65C02 can run. One other knee-jerk reaction though: at 64us for 15 iterations with the screen off, a real Lynx is only about 70% as fast as Handy. Or Handy's CPU is about 40% faster than a real Lynx.

It's really painful to read — akin to rediscovering your teenage poetry; but Elite and Starship: Command were announced via alt.games.lynx and, at the time, stored on my university hosting. Starship: Command Cobra Mk 3 The Mined Out clone appears to have been submitted to the 2000 Songbird games competition, but I can find no evidence it was otherwise released. So likely gone.

Actually, no, cancel any comments about necessarily being able to perform these tests anytime soon; my situation is that in my possession I have a cased SainT multicard but a Lynx 1. I ordered a McWill Lynx 2 from eBay, which just arrived, but it seems to be a lemon. Obviously I'm going to try a little harder with it, then see what I can do about a remedy if necessary, but regardless of my consumer rights it's something of a spanner in the works. I'm also queued up for the uncased SainT multicard that would fit my Lynx 1. So it'll happen at some point. Frustrating I also own two Lynx 2s and a Lynxman flash card, but all are in storage back in my native country. That was my venting. Thank you for putting up with it. In the meantime, attached is the first benchmark I was hoping to run. It's not in the slightest bit user friendly as it was just for me. But here's what should happen: It'll start up to a screen that says '00' in the top left. That doesn't mean anything, it's just letting you know that it loaded correctly. You can then press: A to test with the display off; B to test with the display on at 60Hz; Option 2 to test with the display on at 50Hz; Option 1 to test with the display on at 75Hz. It'll then do 222 iterations of a tight loop, which just grabs and stores a timer value, before printing 221 results to the display, in hexadecimal. You can run each test as many times as you want. What I want to know is the full sequence of 221 results. The loop being run is 13 cycles, of which at most seven could potentially be performed in page mode. You'll see in Mednafen that with the display off the results are three '03's followed by an '04'. Each count is in microseconds, the maximum timer precision, so from the whole pattern you can conclude that each 13 cycle iteration takes 3.25us. Which is from where I conclude that Mednafen gives you a full 4Mhz of processing power. A real Lynx should have bigger numbers and probably be less predictable. From those numbers we'll try to come up with a model of refresh and page mode timing. With the various display on options on Handy or Mednafen you'll see period 17s and 18s in there. By looking at the spacing of those numbers and their sizes, plus a model of the rules about refresh and page mode, it should be possible to derive video DMA interruption periods and lengths. Or, possibly the tests will be inconclusive. E.g. one thing to keep in mind is that the numbers with video DMA interruption are modulo 256us. There'll be additional clues as to buffer size in frequency, but tests with a less precise timer may be necessary. It's unlikely though, as 256us is 4096 ticks, which even at the processor's probably slightly languid 5 ticks per non-page mode access that's enough time for 819 bytes to be fetched. Anyway, fingers crossed I'll be able to start on some of this stuff for myself soon but until then, here's step one. EDIT: for the record, I took the documentation's warning that the first tick after you set a timer value may not be full length to imply that there's a common master divider to get to 1us and your first tick depends on phase with that. So probably you wouldn't get any more from trying to set off two out-of-phase timers; they probably can't actually be out-of-phase at 1us precision. benchmark1.lnx.zip

Honestly, I'm fairly impressed that Handy is making any effort whatsoever towards accounting for video DMA given its era and therefore its processing budget and the difficulty then of testing on real Lynx hardware. And, for the record, I'm also now tending towards thinking that maybe the processor is implemented at 4Mhz in pre-Mednafen Handy but timers are of questionable accuracy. Just a guess, based on how some of the commercial titles run. Anyway, the plan, such that there is one, is to use the test I currently have — which is just a tight read a timer, store a value loop, runnable in any of 50 Hz, 60 Hz, 75 Hz or screen off configurations — to try to come up with a model of refresh and video DMA timings plus some hints about CPU page mode. Then I can try to put some effort into figuring out exactly what the rules are around CPU page mode. Poking around Suzy can follow after that. The only real hint the documentation seems to offer via the palette bug is that SCB reading uses page mode to some extent. I'll make sure I keep everything in a Wiki somewhere, tests and results.

That'd be fantastic if you could. Surprisingly I think I'm on exactly the same path as you; I'm shortly to receive a modded Lynx II via eBay and I saw a bunch of people on there offering conversion services suitable for my existing Lynx I but I feel like there's a whole extra layer of trust issues with eBay when it's a question of sending something off as I don't think eBay really does much to police that sort of transaction. Correct me if I'm failing to understand basic electronics, again, but I think classic alkalines are at best 2200mAh but nowadays ordinary AA-sized rechargeables go up to 2850mAh (EDIT: 3100mAh) or higher. So those might eke out an extra hour or more again. Digression for McWill! The Lynx has a programmable refresh rate, and one thing the programmer must do after setting line length and lines per frame is set the "Magic 'P' count", calculated as INT((((line time - .5us) / 15) * 4) -1). It's mentioned immediately after a reference to not keeping any single line selected for too long so that it isn't obviously brighter than the others, but presented as a divergent thought. But either way, as the expert, does that calculation correlate to any obvious physical reality of driving an LCD? 4/15ths of a little less than a line's length?

I was putzing around with test cases to run on a real Lynx when I next have access to one (which should be soon) and I think I discovered the following about Handy and Mednafen: refresh is not emulated; page mode is not emulated — Mednafen seems to give you a constant 4Mhz CPU, which is already faster than I'd expect, and Handy runs even faster than that (EDIT: specifically, it seems to act as though the CPU were close to 4.25Mhz); there is an attempt at emulating video DMA pauses, but it raises questions. At 60Hz it seemed like approximately a 20us pause every 610us. Those numbers don't really make sense but it feels imprudent to speculate further without having built up more confidence in the test code. Re: 4Mhz as an unrealistic number; if only paged-mode fetches are 4 cycles, the majority will be 5 cycles. If all were five cycles that'd imply 3.2Mhz. In real life they won't all be, and there'll be refresh and video interceding. I hope to have access to real hardware next week so, subject to the many usual time pressures of being an employed grown-up, the plan is to run the same tests there, and follow whatever path the results dictate.

Versus the Gameboy, I have to agree with those above re: the content. For me the Lynx is the endpoint of a certain lineage of game design which I can't quite coherently qualify — certainly it includes a particular sense of direct pixel control, and a focus on scores, on speedy reactions, on games seeking to overwhelm the player with action. I guess maybe I'm describing "arcade" games — but in any case something very Atari and mostly very American. Something that hasn't really survived to the modern day, unlike the Nintendo type of title. So it's just somehow a little more alien. But compared to other Atari machines? I don't know. For me it's the ideal Atari for the modern world: it's compact, there's no need to try to locate a CRT or figure out some way to coax a modern TV set into handling vintage video signals (and getting into that whole hornets nest of latency trade-offs), and it's even an easy target for hobby development.

With no small measure of vanity or large quantity of hope: during a period around 2000–2002 I put out a few small Lynx programs which I have long ago lost. I don't suppose anybody is so enthused about grabbing every demo from everywhere that these things have survived? Specifically: a file originally distributed as EliteLynx.zip which is the rotating Cobra Mk3 wireframe of Elite title screen fame; a complete Mined Out clone; an incomplete overhead shooter, Command: Starship, in which your ship has a fixed position and a battlefield of vector enemies and a starfield rotates around it. You could shoot, and the bullets would inherit your velocity and direction plus a bit. So you could then accelerate and catch up with them. Enemies were very dense indeed, pretty much just rotating to face you and then advancing; or a Repton clone — a bit like Boulderdash but emphasising puzzles over reactions. Likely to have been a single screen only. I don't really expect anybody else to have kept these; they're valueless. But it felt like asking wouldn't hurt.

Cool; work to do then. When I next get a flash card and Lynx together it might be smart to run some tests to try to poke at some of this stuff. Potentially interesting to measure versus a timer: Total time for a bunch of iterations of a tight loop with harmless LDAs of different addressing modes that is entirely within a page. To give a broad sense of general processor bandwidth without Suzy, and because how this scales with different addressing modes will provide some information for making guesses about the paged mode logic. Total time for a bunch of iterations of the same loop with the LDA straddling a page boundary to different extents, to help to confirm or deny paged mode guesses. A variation on one or the other of those that records successive timer values, to look for anything that might imply video DMA interruptions. Refine as necessary go get a sense of their regularity; try different screen refresh rates. Then there's a bunch of stuff one could rattle off for Suzy: looking for write versus read-modify-write optimisations, checking for page mode optimisations, comparing compressed and uncompressed inputs to get a sense of Suzy's bandwidth, comparing lots of small draws for more evidence on video DMA interrupts, etc. I wonder whether I'll still be curious enough when I'm next simultaneously in possession of a Lynx and a flash card.

In a classic simple 6502 system the setup is usually: the 6502 receives a symmetrical clock signal. It unfailingly tristates the bus during the first half of each cycle, then accesses memory during the second. Therefore RAM that is fast enough to keep up with the 6502 is used at only 50% of its bandwidth. So the other 50% is used for video fetching — the basic pattern is a video fetch during phase 1 (i.e. the first half of a cycle) and then a CPU access during phase 2 (i.e. the second half). If machines require more bandwidth for video than that implies, the CPU has limited stoppage periods. Of those I'm familiar with, the C64 is a famous example, the Acorn Electron a less-famous example. So... how much do we know about the Lynx's bus handling? These things I think are uncontroversial: Mikey both contains the CPU and is responsible for the video DMA; from the processor's point of view, a page mode memory access costs 4 cycles and a completely random one costs 5; Suzy has no bus access unless Mikey cedes it; Mikey will then interrupt Suzy as required for video fetch, with a maximum latency from initiating a request to getting access of 40 cycles; and a compromise was required "between bigger FIFOs in the Mikey video DMA and reduced performance in Suzy". From which I can conclude, or guess anyway: Mikey grabs data in bursts, implicitly filling itself with a quantity of memory much larger than that which can be fetched in 40 cycles; it is unlikely that Mikey interleaves video and processor accesses even when it has full access to the bus, as otherwise there'd be almost no point in spending time on a page mode optimisation for CPU access — it'd rarely be helpful; therefore memory bandwidth is probably something like an optimum of 3 cycles for a page mode read, 4 cycles for a random one, as it's hard to imagine the processor core eliminated the 6502's think-then-act rhythm; ... which, if true, would also imply that the CPU sees stoppages just like Suzy does, albeit without a 10-cycle request/grant delay. That being said, there is a mention of "the other pertinent states of the system" in deciding whether to permit something which otherwise definitely could be a paged mode processor access. Has anybody ever done something simple like run a fixed counting loop against a timer to get a simple estimate of actual processor speed when Suzy isn't involved? Or anything as extreme as hooking up an oscilloscope and trying to map the whole pattern out?

I think that explains the 5 min and 20 max on Mikey — presumably the options are exactly 5, 10, 15 or 20 depending on whether you have to wait 0, 1, 2 or 3 rotations for your channel to come around. Luckily, I discovered the answer elsewhere in the documentation, seconds ago! It's cartridge reading: RCART is at FCB2 and FCB3, so despite there being co-ownership of the actual task it's within Suzy's address space. So I think it counts as reading from Suzy.

This is embarrassing, but could I get onto the preorder list again, but for an uncased Lynx 1 version this time?

To quote the Epyx documentation, potential 16Mhz cycle counts for 65C02 actions are: Those all make sense to me, even if some are slightly vaguely documented, except Suzy reads potentially taking 15 cycles. It's been a very long time since I did any Lynx programming so please jump directly upon any of my logic faults. The CPU has the bus, so Suzy is not drawing. So we're not talking about 9–15 cycles spent trying to intersect with sprite activity. The only other thing Suzy does is maths, but that's asynchronous rather than blocking. One uses SPRSYS to check for completion if it can't just be assumed. There is some reference to Suzy having to cede the bus to Mikey for video DMA, but that feels like a distinct issue since Mikey obviously can get at the frame buffer while the CPU is happily doing its own work at 4 or 5 cycles per tick? I feel like I'm failing to make a necessary mental connection.

Will do as soon as I get to my own computer! I'm surreptitiously misusing workplace resources to post this message. That said, I don't actually have anything immediately to assemble, so appropriate feedback may be delayed. I was a heavy Lyxass user a decade or more ago but all my work is lost to time, at least in its original form. Thanks again! But does this mean we're the last people left alive using this assembler?

Cool! I considered trying to fix it myself, but I've no familiarity with the code whatsoever so the startup cost would have been high. I can't immediately find any evidence that you're maintaining a repository so I shall await what I assume will be Lyxass v50? Thanks for keeping this alive!

On the Mac, I'm much more inclined to recommend OpenEmu, which now includes the Lynx, than anything by Richard Bannister. OpenEmu is just yet another umbrella collection of other emulators under a common interface stuck in the miasma of "cores". So far, so generic. But since there's really only the one common ancestor of all current Lynx emulations, that's really just an observation that you'll get pretty much the same code whatever you download. Unlike Bannister's efforts though, there's no upsell. No additional shareware 'Emulator Enhancer' to install if you want fullscreen and joystick support.

Line 53 of macro.c stores a 32-bit portion of the pointer to the location in the source code where a macro was defined. Line 150 treats that 32-bit portion as though it were the whole thing, and then attempts to parse from there. Nothing about the code shows any connection to hashing. Are you sure you're talking about the same thing?

Massively late revival, but presumably the assumption of long being 32-bit was broken because you compiled for a 64-bit target? If so then there still seems to be a bug in your use of the LABEL struct for defining macros — you're stuffing a runtime address into a 32-bit field. Specifically you're storing it at line 53 of macro.c, and using it at line 150. That's undefined behaviour for the obvious reason. Do you really need to reuse that field? Would an extra char * in that struct not be acceptable?

Same question from me; I've my first American Lynx, and my first Lynx I on the way, but it'd be great to be able to improve the screen but alas I can't solder in the slightest, and installation looks to be relatively involved.

Supposing the issue was overly-strict file size validation, that should now be fixed. The new rule is: if file size is in the range 32–32.5 kb, truncate to 32kb; otherwise, round up to the next multiple of 8kb. Then if the cartridge is greater than 32kb in size it's treated as a MegaROM. This logic seemed to be more appropriate for the various homebrew titles I found on these forums. Downloads here.