Leaderboard

Can this thread be moved from the Intellivision forums to the modern consoles forum as it has absolutely nothing to do with the original Intellivision and is just a rehash of a bunch of stuff that we already know. Time to move on kids.

a7800 v5.2 has now been released at github. Whats new in this release: pokey poly9 sequence correction pokey init state corrected to match real hardware A big thanks to @rensoup for pointing out the poly9 bug. Heads up that the update to the pokey init state means that a good chunk of the 7800 pokey demos aren't functioning under the new release. Those demos aren't setting the b0 and b1 bits of SKCTL high, which takes pokey out of reset, and is a required pokey setup on real hardware. Some flash carts may take pokey out of reset during startup, but this doesn't happen on retail and homebrew pokey carts. Once again, @Trebor and I hope you enjoy it!

The TI BASIC interpreter extensively checks the validity of BASIC programs. These checks protect the programmer and make sure that the program stays inside the BASIC sandbox. This makes crashing the interpreter challenging, educational, and fun -- especially if it can lead to a jailbreak. Here are some known crashing techniques, plus a few techniques that are new, as far as I know. Does anyone know any other techniques? Buffer overflow building a PAB (explained by James Abbatiello) 10 OPEN #1: "....payload..." with the payload being more than >F2 bytes. The PAB building subroutine at G>4BA1 then has an overflow and allocates too small a buffer. The program overwrites itself in VDP memory, starting with the line number table. The interpreter generally crashes, but it doesn't seem easy to leverage it for a jailbreak that controls the CPU. Buffer overflow calling DSRLNK (explained by James Abbatiello) 10 OPEN #1: "...payload..." or even simpler if you can edit the bytes of the program in VDP memory or on disk: 10 CALL ...payload... with the payload being more than >7F bytes. The DSRLNK subroutine at G>03D9 incorrectly checks the length and overflows the FAC buffer starting at >834A in scratchpad RAM. With a carefully crafted payload you can escape the sandbox and gain control, as I've documented in my Breakout game. Incorrect number normalization with CALL KEY (explored by @pixelpedant) 10 CALL KEY(1,K,S) 20 K=K/2 If 'X' is pressed at that point, the code for CALL KEY at G>3724 incorrectly normalizes the Radix 100 value. The CPU gets into an infinite loop when computing K/2. Buffer overflow looking up a variable name with XML >13 (new!) The BASIC prescan should check the length and validity of all variable names, but there appear to be a few ways to bypass it: 10 LET "...payload..." or 10 NEXT "...payload..." or if you can edit the bytes of the program in VDP memory or on disk: 10 FOR I=1 TO 0x00...payload... or just 10 0x00...payload... where 0x00 stands for a 0-byte. At run-time, the variable lookup subroutine XML >13 at >176A unwittingly copies the characters of these bogus variable names from the program in VDP/GROM memory to the FAC buffer starting at >834A, until it encounters a negative byte. We can thus overflow the buffer. We can enable some random sprites by overwriting the number of sprites in motion at >837A. We can confuse the program editor by overwriting some flags at >8388. Unfortunately, having a payload with only strictly positive characters is pretty limiting. As soon as we write a non-0 value to >8389, the interpreter starts retrieving the program code (including the payload) from GROM and goes into an uncontrollable frenzy, with wildly flashing patterns on the screen. Any other techniques? More interestingly, can any of them be exploited for a new jailbreak?

Fair comment. Back then we were genuinely excited about the upcoming console and the ability to play the old Inty games and some new upgraded versions as well. We often talk about stuff we like on the podcast.

Cmart, that’s EXACTLY how I felt when you guys brought talk about this flimflam console into the Intellivisionaries podcast! Remember when you did 40 minutes on this brain fart in the intellivisionaries podcast? http://intellivisionaries.com/episode-37-amico-portland-and-baum-oh-my/ Or this one http://intellivisionaries.com/special-edition-7-a-new-console/

***UPDATE*** A7800 v5.2 What's new? pokey poly9 sequence correction pokey init state corrected to match real hardware For all supported OS's (Linux, macOS and Windows) there is a 64-bit (x64) build. Additional Notes: A big thanks to @rensoup for pointing out the poly9 bug. Heads up that the update to the pokey init state means that a good chunk of the 7800 pokey demos aren't functioning under the new release. Those demos aren't setting the b0 and b1 bits of SKCTL high, which takes pokey out of reset, and is a required pokey setup on real hardware. Some flash carts may take pokey out of reset during startup, but this doesn't happen on retail and homebrew pokey carts. As @RevEng stated, we hope you enjoy it! Quick and easy portable install for Windows: 1. Download A7800, unzip to a new/clean preferred location [I.E. C:\A7800]. 2. Download A7800_Optional_Files_20220331 *Edit 6/28: Download A7800_Optional_Files_20220628, contains the aforementioned pokey demos fixed, and unzip to the same location as A7800. Starting Console: Selecting ROM: Default Mappings: Changing Controllers: ***See the included illustrative manual in the download archive for more details and options***

To be clear, many pokey demos still work perfectly fine as they already present the proper 'take the pokey out of reset' function. The impacted demos can be updated to behave accordingly. As emulator accuracy improves, if a developer chooses to update a demo to reflect that accuracy, it is an option to do so. For those that have been around the scene for a long time, some may recall when NESticle was the 'go to' NES emulator. Many, nearly all hacks at the time, were built according to NESticle behavior and results. As NES emulation improved, most NESticle created hacks failed to run properly, if at all, under anything else but an outdated NES emulator, as those hacks were relying on behaviors and results that were not present under the actual console or emulators closer to hardware accuracy. A better fix to ensure posterity is for the hacks (or demos) to be updated to reflect typical hardware behavior. Otherwise, the hacks or demos will work under only a specific multicart or emulator behavior. For the record, the same impacted pokey demos do not run properly under the Atari7800_MiSTer FPGA core due to the aforementioned inaccuracy. Not stating a future kludge is entirely out of the cards, but far from an ideal solution.

This is kind of funny to me, cause of the name of the seller.

Test output now: ,_, (O,O) ( ) -"-"---dwb- Geneve 2020 ----------- Memtest 0C00 3FFE 4000 7FFE X 8100 FFFE Fail Bank test ROM >4000 RAM >C000 REG! REG@ RAM@ ROM@ 1000 F700 F000 FFFF X 2000 F700 F000 FFFF X 3000 F700 F000 FFFF X 4000 F700 F000 FFFF X 5000 F700 F000 FFFF X 6000 F700 F000 FFFF X 7000 F700 F000 FFFF X 8000 F700 F000 FFFF X 9000 F700 F000 FFFF X A000 F700 F000 FFFF X B000 F700 F000 FFFF X C000 F700 F000 FFFF X D000 F700 F000 FFFF X E000 F700 F000 FFFF X F000 F700 F000 FFFF X Fail XOP test: 1234 XOP0 Pass NMI test: NMI entry. Pass MID test INT2: WP 8020 ERR 2000 R13 8000 R14 01A8 R15 D002 Illegal instruction 01A6 0C0C RSET: WP 8020 ERR 0000 R13 8000 R14 01A8 R15 D002 Pass AF test INT2: WP 8020 ERR 0010 R13 8000 R14 024C R15 8822 Arithmetic fault LDCR: WP 8020 ERR 0000 R13 8000 R14 024C R15 8022 RSET: WP 8020 ERR 0000 R13 8000 R14 024C R15 8022 Pass PRIVOP test INT2: WP 8020 ERR 4000 R13 8000 R14 026A R15 D102 PRIVOP: 0268 03A0 LDCR: WP 8020 ERR 0000 R13 8000 R14 026A R15 D002 RSET: WP 8020 ERR 0000 R13 8000 R14 026A R15 D002 Pass Macrorom floating point test: 7000.0 * 31416.0 / 10000.0 55E7 Pass Blink test forever

I guess I should give my feedback, since one of the main issues is that we're not receiving much ourselves. First of all, I appreciate the thanks and support from everyone that commented. Certainly gives me something to think about. My main issues have been lack of feedback (as mentioned my @Thomas Jentzsch and @DirtyHairy). As @DirtyHairy said, there is personal interest, and interest from the outside. The latter is somewhat lacking over these past few years, and some of it has been non-constructive and even aggressive. This has mostly applied to the R77 port, and I guess wasn't totally unexpected when Stella moved outside our circle of users more into the 'mainstream'. This type of thing really saps my energy and interest in the process. Stella has had many 'firsts' for 2600 emulation, but isn't always recognized as such. Regarding my own interest, it comes and goes. I have a lot going on personally, in work, and also some medical issues. Personally, I don't remember the last time I sat down and actually played a game in Stella or on a real console. Of course I do all kinds of testing or ROMs, etc, but actually using the system, not so much lately. So honestly, it's starting to become more like work than like play. There are also issues with how long I've been working on Stella. 20+ years is a long time to be doing anything. Sometimes it gets tiring, and a break is needed. Related to this, there's the issue of the codebase being 26 years old. While I've tried to keep the codebase clean and upgradable (and I think I've done a reasonable job), some features are getting harder to add. Basically, we've mostly picked the low-hanging fruit, and some new stuff is getting harder to add. For example, for the technical-minded people here: a lot of the things in Stella are custom-made. Stella doesn't use a UI toolkit, so whenever we want a new 'widget', we have to code it ourselves. So when we needed a textbox, we need to code everything about it; how to draw it (lines, background/foreground colours, event handling, copy/paste), where to place it onscreen, etc. In a normal UI toolkit, this would be a few lines of code. For Stella, we have to implement the entire thing. Similarly for networking, filesystem, etc stuff. A lot of it is not built into C++, and we either have to write it ourselves, or find external C++ libraries. So there is a lot of maintenance. Anyway, sorry for sounding so down. As a developer, and perhaps many here can agree, when you work on something, all you see are the flaws. While others can praise the product, all you see are what you left out, what could work better, etc. That's sort of my mindset at the moment; hopefully it can improve for the future. Thanks again for the support we have received.

Another take on the PEB Box lid:

Shouldn't be long now, methinks. Surprised it lasted 5 pages anyway, since it really is...

Here is a zip file of hi res .TIF images, scanned from the User Group magazine: TIMES UK No39 Winter 1992/93 Part Two of Two 80 pages, A5 size, white cover, white paper inside. For you to read, print, ocr, pdf, or add to an archive of your choice (eg wht or archive.org) Also a PDF with a detailed contents list - it has embedded text and is searchable. An interesting highlight: Accessing the 9902 UART in Assembly, by Mack McCormick. times uk No39 Winter92_pt2.zip times uk No 39_Winter92_93_contents.pdf

But in truth, on 7800 you already find many excellent high-resolution games, here are just a couple:

Absolutely, the 320C mode isn't useless, in fact it really has the potential to take the 7800 high resolution graphics to the next level, with 9 colors per zone and 4-5 colors per sprite - tile. Furthermore, the 320C mode can be used in conjunction with the 320A mode if you need monochrome tiles and this is an added benefit as it saves many cycles. A while ago I made a mockup just to show its potential:

Had a great time at the Vancouver Retro Gaming Expo! Was fortunate to meet up with @Lathe26 and got to join him for poutine lunch (I think his Montreal Smoked Meat poutine was better than my Jambalaya poutine) and then for the $4 donuts. A highlight was when someone (who @Lathe26 knows) saw me in my @Papa Pete shirt he started singing the intro tune. So, you were there in spirit, Pete! I didn't get any Intellivision stuff (there isn't too much left on my list) but I got 4 NES games (highlights: Mega Man 4, Journey to Silius), 4 Wii games (nothing special...Phantom Brave: We Meet Again) and a stack of 10 very clean PS3 games from the "all games are $2" table. We also had a nice chat with @swlovinist about keeping things positive in the Intellivision community. My feet hurt, but it was nice to get out to an expo again. Has me looking forward to the insanity of PRGE. EDIT: Pic includes an Inty game that was planned for a trade for someone who wasn't able to make it.

Any chance your loop resumes execution (following interrupt return) with the wrong bank of registers still active for a few clock cycles? Then you get unpredictable results, which might randomly seem predictable? I think the store below sets/clears bits to clear interrupt with side affect of returning to normal active bank of registers. irq_return jump (IRQ_RTS.a) store IRQ_FLAG.a,(IRQ_FLAGADDR.a) Page 53 of SoftRef_V10.pdf, @c Stephen Moss: "Values written to the G_FLAGS resister may not appear to have changed in the following two instructions due to pipe-lining effects. Consequently, writing a value to the flag bits and making use of those flag bits in the following instruction will not work properly. If it is necessary to use flags set by a STORE instruction, then ensure that at least two other instructions lie between the STORE and the flags dependent instruction. If it is necessary to use flags set by an indexed STORE instruction, then ensure that at least four other instructions lie between the STORE and the flags dependent instruction."

Behavior of ST ERR P. 28 of the 99000 data book describes the “error status register”. (I’m calling this ERR ST.) I verified the table on page 28. PRIVOP >4000 ILLOP >2000 AF >0010 coincidentally, the same bit used in the ST register. SBZ worked to reset bits, using the addresses in the table. But the text below it is full of address typos. I also tried the RSET instruction and it definitely clears ST ERR. (Also RSET requires supervisor mode.) The bit values I observe in ERR ST: An INT2 handler must clear the AF condition in ST ERR bit and also ST4 (AF occurred) —else the interrupt will repeat after RTWP (or any LIMI 2). Or you can disable AFIE. Macrostore Surprise my ILLOP test was to execute: DATA >0C0C undefined, MID Which jumps to Macrostore! It is the Macrostore program that gets a crack at the opcode. Without valid Macrostore ROM, I see bad stuff happen (random, but usually infinite loop.) if the Macrostore program (of the 99110) doesn’t want the opcode, (ie it’s not floating point or some other extension) THEN the program sets ILLOP and returns. Then INT2 occurs. Without Macrostore, there’s no ILLOP interrupt! So.. I have my CPU set to External Macrostore (conveniently mapped to my ROM, not a separate address space.) It was full of garbage test patterns — so lockup. Cured: I loaded @pnr’s excellent dump of the 99110 ROM. On the first try, ILLOP worked perfectly. (and now I can try all the 99110 instructions!) At last, I’ve got INT2 printing messages for all the cases, and clearing them.

Were you wearing the headband when you posted this?

UPDATE: I have received confirmation that I will be able to film the panel discussion and post it online after! - James

Hard to believe it's been almost 30 years since the Jaguar was released, and a year later we got Kasumi Ninja. Messing around with the Habaki and Senzo (the twin ninjas from Kasumi Ninja, of course) models I made, I wanted to see them in action. Here are a couple demo images. As always, there are more images on Jag64.com. Be interesting to see some Jaguar properties get new life on the VCS - depending on licensing, etc.

The 800 can't use the 6502 clocks because during DMA all CPU clocks are stopped.

Fest West!

I guess I didn't do much here this time. Arcade Fighting Hawk - 10 Thunder Dragon 2 - 16

TImes (UK) #39 Winter 1992 - (Complete) Ready to print. TImes (UK) #39 Winter 1992 (Complete).pdf

No, I did not yet include the SNUG speech cards in MAME.

The Errorfree program library is still available in Germany, so the program may be preserved there. Not many of the Speech cards from Winfried Winkler exist (I think he only made a single batch of 22 of them, of which one is in my set). The SNUG SPVMC is a further development of this card (software-wise), so the program may work on the 50 or so SPVMC cards in circulation too. Both of these cards have a DSR that integrates the Text-to-Speech routines from the Text-to-Speech disk, so any emulation you choose will have to be able to emulate one of these cards for the program to work properly. I suspect MAME may be the only emulator to address either of them--and then it would most likely be the SPVMC.

Metallica Skid Row? Megadeath? Iron Maiden? Def Leppard

Demo 3... Double the GOO! Not making it beyond Floor 2 just yet, but this title keeps you coming back for more OOZY adventure! VHZC putting out addictively awesome games, and here is no exception. Cosmetically, I just absolutely love it when I witness the first take on something like the timer area and think, "That's great as is", but here comes the polish and it's even better than before. The changes to the walls and the aforementioned timer made me feel like I went from a futuristic alien race prison, to a sort of alternate medieval or ancient period of time, dungeon setting. Really a fantastical change, though I enjoy both environments, the current one, since Demo 2, seems more fitting for the type of deaths and overall layout. Love the bugged out eye expression in the square when poor OOZY becomes splattered. The mine cart ride is a blast and gives off a little bit of a Bagman meets Indy TOD vibe. I'm a bit sloppy and rushed, but the challenge still comes across as very well balanced. The puzzles, action, and adventure are combined in such a great mix here. My only gripe may be not having enough time, but I'm putting that on me for now, as I carelessly die way too often.

Some nearby food, including ... POUTINE!!!

Here's my look at the game, nice to have a VCS exclusive for now:

I've spent the better part of a year and a half developing a replacement controller for the Atari 5200 in my (infrequent) spare time, and I hope that this will be a reasonable place to discuss both my personal progress, future prospects, and what I should be thinking about in further development of the controller. Now for some preliminaries: Does it work (what state is the controller in)? As of now, although exact wiring types, routes, and shielding, etc. are not finalized, I have made several prototype revisions whose buttons work. This has been proven using various games and both 2-port and 4-port consoles (not that the particular console revision should have any affect on performance). Original overlays have also been tested and work with the cavity provided for them. My controller has a few more curves than the original, which makes holding it a better experience in my opinion, but only a larger test sample will determine ultimately how reasonable it is to use. As the highest resistance commercially available joysticks of an approximately correct form factor are 10kΩ, I've had to take the route of previous joystick attempts and use a digital potentiometer, a microcontroller, and some capacitors to simulate the correct resistance. I am currently waiting on some perfboards and such in order to internally test this method, results should be in within several weeks on whether what I have will work for the given purpose. In short, the buttons work, the joystick does not (yet). Future (pre?-'production') goals? - Wireless connectivity --> using an Arduino: will require a battery and a secondary microcontroller: costs will go up - Some supply for made-to-order purchase (probably using eBay) - wire routing improvement and trigger button stiffening - Simplification and cost-reduction: due to long manufacture time and limited material availability, if I were to sell a controller, it would cost upwards of $100 to a buyer before shipping would be factored in. With a little help from economies of scale and an easier production process, this could be lessened. Are you willing to go 'open source' (make 3D files, code, and production documents entirely available)? Although I've considered it several times now, the time investment that has been poured into this single project is too great to be immediately given away. I can make no promises, but if I never get to a point where I can sell the controllers, I may make enough of the project available so that it can at least positively impact the community in that way. In the mean time, look out in several months for a method of purchase. Opening the Floor - What do people that have been waiting on a controller replacement want out of a controller? I've tried to make all of the buttons more tactile, the joystick self-centers, the triggers use microswitches, the controller was made specifically so that most major components can be replaced with screws alone: what other things should I consider including or altering? - Is this even something that anyone wants? Thank You, ~ Lucas Lac124.

Glad you had a good time. I'm jealous. Nice pickups! Rev had an underpriced copy of Secret Files: Tunguska in his booth at PRGE a few years back. I should have bought it. I'll be on the hunt for some Wii games at PRGE. I'm still looking for a few big hitters for my Wii collection.

Additional useful tools to do mass renaming and organising gamelist.xml with images and videos in Batocera * Explanation https://www.digimoot.com/retropie-generate-xml-mass-rename-media-roms/ * Fat Match file renamer (to map roms with images or videos), run the tool 2x (for images and videos) https://emumovies.com/files/file/227-fatmatch-file-renamer/ * Gengal.zip - Gengal (very difficult to find it online) to generate the gamelist.xml with images and videos * Use ESGME to load the gamelist.xml to validate. If it gives errors then probably filenames have the "&" (ampersand) character in the filename (change it to "+" (plus)), * Use the Bulk Rename Utility to rename the files (include the subdirectories !) EmulationStation Gamelist Metadata Editor · https://www.jeffersoftware.com/esgme/index.php · To edit in /roms/ti99/gamelist.xml o Use SAVE o Edit the names of games o Edit the link to images (preview) o Edit the link to video files (preview) Bulk Rename Utility (to rename files, like filaabc_x264.mp4 to file.mp4 (play around with the filters) https://www.bulkrenameutility.co.uk/

Ah, sorry to make you do that extra work - my fault for saying earlier that I wasn't working on it. I saw that we had a number of fixes queued up since the last release, and figured I might as well push through the ennui and put out a release. Correct - there shouldn't be a need to avoid variables or labels ending in _data or any other statement, with the latest release.

I watched Red Sonja for the first time in 30+ years. It held up surprisingly well. It's not a great film by any stretch, but it does have its charms. Some of the sets are cool, Brigitte Nielson does a good job, and the comic relief is amusing without ruining the movie.

... an amusing T-shirt to follow-up the food images.

Yep, that was outdated text... the EPROM is all in the first 6k-ish of the 32k. The cru based bank switching is not used. crubit 0 ( dsr-on ) crubit 1 ( TipiService reset ) crubit 2 & 3 control address lines of the 32K rom... but everything beyond the first 6k ish of the ROM is zerooooo... crubit 2 & 3 should always be 'sbz' 0 / clear / unset

Wow. She must really care about how they did if she's gonna do all that to you just for communicating with her.

Spotted in the vendor hall.

Update 2.4 - June 25th, 2022. I fixed the 32K mode command recall ( to be clear, this is a single previous command in a VDP buffer, where SAMS mode provides an aging out 4k list ) Added Myarc EXP-1 support commands ( requires 128KOS version of ROM ) - RDPART <ram> <disk> <spool> - partition the card for either 32 or 128 kilobytes of memory expansion, and some portion of ramdisk, plus spool size ( total must equal 128 or 512 ) - RDEMDK <drive> - set the emulation drive number for the ramdisk... 0 turns off emulation, 1 - 5 for DSK1-DSK5. - RDVOL <name> - set the volume name of the ramdisk These are all non-destructive, except RDPART if the parameters are different from the previous call.. so they should be safe to unconditionally include in an AUTOCMD script. Of course, ForceCommand only runs the AUTOCMD script from the first device listed by DRIVES ( DSR declaration order ), so for initial power on, it'll never find one, but subsequent reboots of the console with the PEB still powered can find an AUTOCMD in the ramdisk... To partition in support of 128KOS with 352k ramdisk and 32k of print spool: [1000.DSK1.] $ RDPART 128 352 32 To assign to DSK1: [1000.DSK1.] $ RDEMDK 1 To give it a volume name: [1000.DSK1.] $ RDVOL ZIPPY "RD." device shows up in drives now, but LVL2 IO routines do not operate against RD, and must be used with a disk number emulation enabled. There is no logic in the DSR to translate "RD." to a unit number that I could find. You can cd to "RD." and TYPE or ED record based files, or LOAD EA5 files, but direct-input operations like COPY, CHECKSUM, or ForceCommand executables need LVL2 IO...

Hello everyone, just thought I drop by to share my MVS collection, I didn't really have any intention to collect MVS since I already had an AES but I couldn't say no when I got a good deal on a bunch of loose carts. After that I really got the itch to buy another handful and even build an MVS cabinet all by hand. Everything was built only using a jigsaw and drill, bits/spade bits for the button holes on the dash, no special router tools or anything and I even hand wired the entire thing too, joysticks and all. I'm really happy with how it turned out, hopefully one day I'll be able to add a coin mechanism, I left the option to do so, just need to find a good looking one at a reasonable price lol.

Yup the price is a killer. The wife scoffed when I said the price had reached $250. I didn't talk to her about therecent price hike because our Switch now has all the casual games she could want. I don't know why people think the price will go down. It won't. It was older tech that was over engineered. The controllers are weak and they drove up the price. If anything the parts will reach EOY and they'd have to use something newer. But all of that is irrelevant because they, 1) have no money to launch. 2) if they scrounge up enough to make the 6000ish that is only 600,000ish of revenue (preorder money is spent and gone -600,000. They will get $200 per person roughly which will be more like $100 per person when you take out Sudesh's cut. Not perfect Math but gets close.) 3) that money will not be enough to make a mass market run. 4) even if they wanted to make a mass market run they still have no money for marketing 5) still no FCC certs because... no money. That's assuming they've passed. 6) console life expectancy? With no money and no physical media as promised, not long. Lots of suspension of disbelief. They totally lose revenue money to Sudesh. They are out of money and assuming IF they can make them that revenue is cut due to Sudesh. It was a horrible loan that they were so dumb to take considering they didn't immediately get the thing out. There comes a point that you have to admit the retro crowd is the market and it even failed to do as good as the VCS there. The retro market seems to be supporting Evercade. What happened is people got star struck and just accepted the word of someone trying to get everyone to open their pocketbooks to him. The truth is they were floundering and inept the entire way through this project. The project didn't mature. It was mismanaged and/or they lied about things. It comes a point that when someone continually says things that aren't true you have to go with they either have no clue or they are a habitual liar. Either option is not good. If I communicated with my wife how the CEO and company did, I'd be sleeping in the car under a pier waiting for her to deliver me divorce papers. ?

Finally made it. I have short blonde hair, a dark grey/maroon shirt, shorts and tattoos.

That 32x blocks the opening of the cd tray Back to 'saving saturn,' I'd thought that Segata Sanshiro died doing exactly that.

A buddy of mine recently picked up a lot of 2600 games, and he's not into the system, but knew I was, so he hooked me up. It was mostly common stuff I already had, but then there were these two. First time I've ever seen Chuck Wagon in the flesh actually.

Today I got a better appreciation for the mechanical engineering that went in to those little pbox clips. I ended up disconnecting everything and using bubble wrap to set the pbox on it's face with the bottom and back pointing towards me, so I could get a really good view of the clip/lid interaction. I was able to adjust the geometry on the "bad" clip to the same as the good clip and yes @atrax27407 it was perfect when both clips clicked in to place. It really is a nicely done design. Thanks to everyone for suggestions

We were having regular issues with settings on the R77 that were corrupted because the device was switched off while a write to the settings file was still being flushed to disk. The same problem existed on other platforms, but less dramatic (as people usually don't switch them off while Stella is still running). That's why we introduced sqlite: it is designed to deal gracefully with incomplete writes.

Neither of the two Montgomery Ward stores I worked at had 7800's on display per se. We left them in the box, bulk stacked in the middle of Electric Avenue's computer and video game section. Didn't even take one out of the box to put under glass like we did with most other systems. By the very early 90's when the price dropped to $59, they sold out quick! Seemed everyone wanted one, and Galaga was mostly the reason why.

Thanks for all the hard work! I think it's safe to say that Stella will always be my go-to emulator for the 2600. And thanks for making/keeping it open-source... Hopefully, I'll be able to make a feature contribution in the near future.