MichelS

From the software side you're not bothered with this too much. Suzy provides two registers for reading (and writing) data from cart. Reading from one of the registers will make Suzy strobe CE0, reading from other one strobes CE1. This way only one of both lines can go low at a time, and Suzy takes care of timing. After reading the data, the cart address is automatically incremented due to this diode circuitry going into the clk-input of the counter. This way you read data sequentially for (up to) a complete "page" i.e. until the counter wraps around (depends on the cartridge internal wiring, if it uses 9, 10 or 11 bits of the counter). The page is the upper 8 bits of the cartridge address and it's set with the shifter. Mikey provides another set of registers (or register bits) to set the databit and the clock-input of the shifter. Clocking data into the shift register has to be done in software, so this is a bit of work to be done by the coder. But each time a bit is shiftet in, the counter is reset automatically. You can see this in the schematics as the clk-input of the shift register is wired to the rst-input of the counter. Edit: the programmer doesn't even have to care for the shifting - there's a function in rom for that which you can call if you're lazy.

As i understand it, the diodes basically form a wired "AND". The inverter input is pulled high by the resistor. Any of the two CE/-lines going low will pull the inverter's input low via the corresponding diode. I'm not an expert in electronics though...

I'd say no - or at least very hard to tell. The IPS seems to operate at ~60Hz. Would make some sense since it can have VGA-output, and VGA is usually ~60Hz, right?

Cannot edit my post anymore, but just realized there can't be tearing on original screen. Data rate and display rate always match. For replacement screens, it's a different story: The tearing cannot be avoided unless the panel was driven at the same refresh rate as the original screen. But then you'd get terrible flickering with the new displays since they are much faster than the old screen. The new displays are usually operated well above 50Hz for this flickering reason. If pixel data are coming at a slower rate from the lynx, you get a tearing effect since one "lynx frame" is displayed over several "display frames" (not necessarily a whole number). On the other hand, if pixel data are coming at a faster rate, you essentially have to throw away data. This must give artifacts if the images are moving...

Hi, i just tested this on an original screen Lynx I and a BV IPS equipped Lynx II: On original screen, scrolling is smooth for all refresh rates. There are artifacts for the two highest refresh rates though. @78.06Hz there's color artifacts - some colored pixels arranged vertically along some of the stripes. @78.70Hz there are some flickering columns, even when not scrolling. These columns are evenly spaced - it's clearly an artifact from the video DMA. Something seems to go wrong with video timing here. On BV-IPS these artifacts at the two highest rates are also present. Additionally there's visible screen tearing when scrolling, especially at low refresh rates below 50Hz. It's not too bad though. I'm sure the tearing is present on the original screen as well. It just goes unnoticed due to the slow screen, which visually mixes (i.e washes out) several frames even at low refresh rates.

Mine was delivered yesterday - virtually. According to DHL online tracking, the parcel was sucessfully delivered. When i came home from work, i only found a note in my postbox saying my parcel was deposited "at the usual place". I searched everywhere but it's just not there. At my postoffice they say they can't do much - but they tell the postman who's doing this tour...

Is it this? Handy Specification, page 34, last paragraph: Timer 7 ("clocked" by timer 5) reaches zero and triggers interrupt on next borrow. Since it's not reloaded, it stays at zero. Now, everytime counter 5 reaches zero and clocks timers 7, the interrupt is triggered again. Or did i misinterpret your find?

Karri changed the rom directory structure of his CC65 in May - see: https://forums.atariage.com/topic/336279-my-cc65-version-of-the-compiler-directory-structure-has-changed/

256kb ROM... why not 512? Looking forward to this!

Yeah right - actually, i was just curious since there are all those download links for old firmware versions on the page. Well, they're all academic links then... Thanks again for the new firmware and your time!

Hm... That means - if say, now i have v1.06. I downgrade firmware for some reason (if that works) and later i want to upgrade again. I cannot use a firmware i saved now (while on 1.06) for upgrading again. I'll have to use the QR code while on downgraded firmware to obtain a new firmware file for upgrade? My head is spinning. Guess i'll take the advice and just enjoy playing old games...

Yes - used the QR code that is shown on my Lynx. I updated to v1.06 yesterday. The page that is shown now says: Updating Your Cartridge You currently have the latest version of the firmware available for the Lynx Game Drive installed! There is nothing for you to do except enjoy playing old games. ... Below are the download links for 1.06, 1.04, ... down to 0.92. When downloading e.g. 1.06 now, i get a file that isn't the same as the .upd from yesterday (which i downloaded through the large button on the top of the page) - but the same as the .ovr from yesterday i.e. different content. Also - i saved the firmware.upd for 1.04 when i did the update from 1.03 to 1.04. Downloaded 1.04 now is different from the old one as well...

Just came home from work and had to try this... So i downloaded the 1.04 firmware again. Indeed, it saves as "firmware.upd"... ...But the file content is identical to the 1.04 "firmware.ovr" i downloaded yesterday (byte-compared in hexeditor) and the LynxGD doesn't accept it, i.e. it does nothing except displaying the QR code.

I see... so the .ovr files are not usable unless this upgrade/downgrade feature is activated or added to the LynxGD firmware.

Thanks for the update! I wonder: how are the .ovr files supposed to be used? Since old versions of the firmware are offered as .ovr for download, i guess they can also be used for downgrading/upgrading firmware? But how to install an .ovr file on a gamedrive?

Most likely this has already been reported, but nevertheless... Carl, there's a small bug in MicroVaders PE which you may want to iron out for the final version: Screen flipping (pause+option2) works for the image and controls, but not for collision detection. If you flip screen, both your ship and enemies become invincible. Flipping the screen back to "standard" orientation doesn't restore collision detection - you have to restart the game (pause+option1) or console. Apart from this: what an incredibly cool game! Please put a warning sticker on the final packaging: "caution - highly addictive material". Can't help but i need to play this again and again, even though i totally suck at this game...

Yes - Thank you both @MacRorie and @Igor for making these protos available! Nice pieces of Lynx mystery/history - often heard about but never seen before...

Yes - Same here. Would love to get this. But Hotdog is impossible to find. And the people who sold it years ago seem to have disappeared, so no new production runs, i guess. If (at least) it was available on flashcart with 3d-printed shell or as (paid) rom download... .

Sounds like a superb Idea to me. A perfect match for this kind of game. I'll buy one for sure, if it's affordable. So count me in - i'm a big fan of adventure games!

A Cabriolet cartridge - cool ?

Thanks Karri, this Unlock Bypass would be so cool! The Lynx should be fast enough to do the two writes while the next byte is coming in over serial. So no package requesting, buffering, etc. needed, which simplifies the downloader code. Maybe some break handling when passing block boundaries... Speed is only limited by the serial connection then, but we're talking about 3-4s for a 256K rom @ 1Mbaud here. MRAM wouldn't give much benefit over this, except for writing data to cart that is already in Lynx ram.

Really? Which ones - Am29F040B? I haven't found anything on bypassing the JEDEC write protection in the datasheets. Am i missing something? I've seen chips using addresses 0x55 and 0x2A, others with 0x555 and 0x2AA and the ones built into in Karri's flashcard that use 0x5555 and 0x2AAA for the byte-program sequence, though. The 0x55, 0x2A ones would be pretty close to the minimum number of shifts/counts required for setting a random access address, i'd think. You can get faster only with sequential access, i.e. if no command is required at all and you can simply write out data, (auto-) incrementing the address on each strobe... Is there a 29F type that can be put into a "global programming" mode?

I had some spare time recently to test an idea about programming Karri's 512K flashcard directly from the Lynx. It's known for some time now that it can be done, but it's also known to be so damn slooooow... With a (really) simple adapter cable, i.e. no electronics involved, programming time can be brought down significantly. For building a prototype cable like mine (see attached image), a spare cartridge connector from a broken Lynx is needed and a cartridge to donate part of a PCB to solder some wires to. A warning first: I initially wrote most of this for my own notes, so it's a really long post. Maybe i should start a blog instead... And to tell the truth - the PiHat programmer and the upcoming BennVenn JoeyLynx cart flasher are faster programmers than the Lynx ever will be, but hey - where's the fun? So, why is progamming the flashcard from the Lynx so slow? Reason is: the flash chip used and the Lynx cartridge interface do not fit together well when it comes to writing data to flash. For writing a single byte, a "byte program" command must be sent to flash first... for every byte... again and again. The byte program sequence is this: 1) write 0xAA to address 0x5555 2) write 0x55 to address 0x2AAA 3) write 0xA0 to address 0x5555 4) write data byte to its destination address Since the Lynx cartridge interface is designed for sequential access, this random access sequence hurts writing performance a lot. Even with optimisations like - skipping 0xFF bytes (no need to write 0xFF into an empty flash) - switching the display off (this not only saves ticks otherwise used for video DMA, but the "rest" bit in IODAT can be set to 0 when shifting bits into the address shift register, enabling very compact code) - advancing the address counter by 4 with a single instruction wherever possible, - doing the least possible number of shifts (see below), - using 1Mbaud serial transfer rate to get the data into the Lynx, - unrolling loops - etc. writing my 256K testrom image "Batman returns" to flashcard wouldn't get much faster than 18min 24s (=1104s). Key idea for speeding up the writing process and reason for the cable is to swap address lines as to minimize the usage of the address counter. To understand this, one needs to look at the default wiring of the address lines first: Address bits 0-10 are connected to the counter, bits 11-18 to the shifter. Step 1 of the sequence is writing to address 0x5555, which is shifter counter 1 1 1 1 1 1 1 1 1 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 --------------------------------------- x x x x 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 |_____| |___________________| =10 =1365 |_____________________________| =0x5555 When shifting bits into the shifter, previous content of the shifter is moved to the high order bits. Fortunately, the flash chip ignores address bits 15-18 (marked 'x') for the byte program sequence, so the content of the four high order bits doesn't matter. Thus, for step 1 of the byte program sequence it's enough to - shift '1010' into the shifter (4 shifts) - count to 1365 - write 0xAA Next, address 0x2AAA is shifter counter 1 1 1 1 1 1 1 1 1 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 --------------------------------------- x x x x 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 |_____| |___________________| =05 =682 |_____________________________| =0x2AAA It's an inverted bit pattern from the previous address 0x5555. With the contents of the shifter from the previous step, it's enough to - shift '1' into the shifter (the '1' previously at bit position 14 shifts to bit position 15 and is ignored) - count to 682 - write 0x55 And finally: writing to 0x5555 again is similar (inverted again) - shift '0' into the shifter - count to 1365 - write 0xA0 At last, the shifter and counter are set to the destination address and the byte is written to flash. For this, another 8 shifts are needed to set the page index, and an average of ~512 counts to set the page offset of the destination address. (For a 256K rom, the pagesize is 1024 bytes, i.e. the counter for the destination address can have any value between 0 and 1023 => ~512 on average) Doing the math, it's clear why programming the flash chip from the Lynx is slow: For writing a single byte of a 256K rom, 4+1+1+8 = 14 shifts and 1365+682+1365+512 = 3924 counts are required on average. And this needs to be repeated 262144 times (minus the number of 0xFF bytes)... Clearly, it's the counter that hits performance quite hard. The shifter behaves well since 0x5555 and 0x2AAA have this inverted bit pattern. Once the initial '1010' pattern is loaded into the shifter, a single bitshift is sufficient to toggle the entire (relevant) content for the next address of the sequence. So the idea to speed up the writing process is to swap address lines such, that for the byte program sequence: 1) counter usage is minimized 2) utilization of the shifter is maximized One possible pattern for address swapping is this: flash chip address bit 1 1 1 1 1 1 1 1 1 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 | | | | | | | | | | | | | | | | | | | 1 9 8 7 3 6 2 5 1 4 0 1 1 1 1 1 1 1 1 0 8 7 6 5 4 3 2 1 lynx cartridge connector address bit The lowest 8 address bits (#0 to #7) for the flash chip are taken from the shifter: 11-18. Four (remaining) address bits, which need to be '1' when setting address 0x5555 (#8, #10, #12, #14) are taken from the lowest counter bits 0-3. Three interleaved bits, which are '1' when setting address 0x2AAA (#9, #11, #13) are mapped to the next free counter bits 4-6. The remaining 4 bits, not used in the byte program command, are mapped in sequential order to counter bits 7-10. With this wiring scheme, address 0x5555 at the flash chip is set through: shifter counter 1 1 1 1 1 1 1 1 1 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 --------------------------------------- 0 1 0 1 0 1 0 1 0 0 0 0 0 0 0 1 1 1 1 Address 0x2AAA at the flash chip is set by: shifter counter 1 1 1 1 1 1 1 1 1 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 --------------------------------------- 1 0 1 0 1 0 1 0 0 0 0 0 1 1 1 0 0 0 0 And the byte program sequence thus becomes: - shift '01010101' into the shifter (8 shifts) - count to '1111' = 15 (flash address is 0x5555 now) - write 0xAA - shift in '0' - count to '1110000' = 112 (flash address is 0x2AAA now) - write 0x55 - shift in '1' - count to '1111' = 15 (flash address is 0x5555 now) - write 0xA0 - set destination address and write byte In total, this is 10 shifts and 142 counts for the byte program command. There's a downside also. Swapping address lines means: if the Lynx sets address X at the cartridge connector, the address at the flash chip is some Y. Unfortunately, this also applies to the destination address for the data to be written. Thus, if shifter and counter are set to address X and romdata[X] is written, it ends up in the wrong place Y. To account for this, either the destination address must be adjusted in software on the Lynx to revert the hardware address line swapping, or data needs to be rearranged. Rom rearrangement is the faster option: in the rearranged rom, romdata[Y] is simply located at address X (instead of Y). Therefore, when setting a destination address X via shifter and counter, romdata[Y] is written. The swapped address lines make romdata[Y] end up at its correct address Y. Since the Lynx cannot hold the entire rom content in ram, data is sent to the Lynx in packets to be written to flash. A program running on PC is needed to provide "data on demand" via serial connection. So, rom rearrangement can be done on the PC and on the fly. But there's one catch: The rearranged rom always covers the full 512K address space. This is due to the way the address lines are swapped. If the original rom is smaller, it must be expanded to 512K first (using 0xFF for unused space) before being reordered. Fortunately, expanding and reordering is just a few lines of code and takes only seconds on PC. Transferring the full 512K to the Lynx also takes less than 10s at 1Mbaud. And finally, the inserted bytes during expansion will be 0xFF and thus not be written but skipped. All this doesn't hurt much. What does, is the original data being spread over the full 512K address range. It means, the pagesize for writing to flash is always 2048 and the average number of counts for setting the destination address is always 1024, no matter what size the original rom had. So, the total balance for writing a single byte becomes: shifts: 8+1+1+8 = 18 (against 14 without address swapping) counts: 15+112+15+1024 = 1166 (against 3924 without address swapping) From these numbers, the programming time can be expected to decrease significantly. And indeed - the measured time for the 256K testrom "Batman returns" goes down from 18min 24s (=1104s) to 6min 44s (=404s). Usable already... at least when considering the time it would take to dig out the Pi and PiHat from the basement. Now the bottleneck is the count required to set the destination address, which takes 1024 of the 1166 counts on average. Thinking about it now, it should be easy to bring this down to 512 (or even 256?)... ... where's my soldering iron? Ok - that was simple. Now, flash address pin 18 is wired to AUDIN. Counter bit #10, to which it was previously connected, is unused now. This means the counter goes up to 1023 max. when setting the destination address, i.e. 512 on average. For page offsets greater than 1023, audin acts as "pseudo counter bit 10" and is set in software. Code isn't as clean as before, since audin has to be unset also whenever the shifter is triggered. (Shifting bits resets the counter in hardware, so pseudo counter bit audin needs to follow.) But the result is nice. The total balance for writing a single byte is finally: shifts: 8+1+1+8 = 18 (14 without address swapping) counts: 15+112+15+512 = 654 (3924 without address swapping) ... and the time to write "Batman returns" to flash comes down to: 4min 30s (=270s). I guess that's as far as i want to go for now. Maybe i'll wire SWVCC to flash address pin 17 one day. That would bring the counts further down to 398. Plotting my measured times vs. the average counts from above shows an almost perfectly linear relationship, so the extrapolated time for this would be 3min 26s then. Is yet another 1 minute improvement worth the effort? Code would definitely get ugly...

Wow cool - 2M - that's space for a lot of animations and sound... A flash chip that could also be programmed via Lynx would indeed be cool... Repeating the byte-program sequence over and over again is so damn slow. Since you need to pulse the ripple counter millions of times, even with lots of optimisation, programming a 256K rom still takes 18.5min. Btw. Karri, are you planning to sell your brand new 2M cartridges to ordinary mortals at some point, like you did with the 512K?

Sorry for replying late - preparing for Christmas... No replacement screens in my Lynxes. I do have a Benn Venn, but never got to install it. Also no problems with my adapter whatsoever. Power on, power off - sometimes i do this 3-4 times a minute. Power on with comlynx loader cart inside, compile (makefile sends compiled file automatically), test, switch off and repeat.