Leaderboard

My son-in-law made this shadowbox for me and gave it to me yesterday for my 2 month anniversary of being cancer free. He's a great kid and has a job most people can only dream of. He is a video game producer for Warner Brothers. His latest game was the released last month called Hogwarts Legacy. Mind you he is only one of many producers on the game. Enough said enjoy the pic.

My meager attempt at a game. A variation on the old Atari classic. I posted it in Camel Forth for the code curious, but here is the proper place for a game. Somebody might find it amusing. For me it's harder to play than I thought it would be but I suck at these things. Needs the E/A Cartridge, disk, Expansion memory and Joystick or joystick emulation. Place both files on your preferred disk. To start select E/A menu option 5 Program is: DSKx.BREAKOUT (don't tell anybody) There is a "feature" (wink wink) that lets the ball drift above the rainbow un-expectedly and it might descend the same way. If any users would like changes let me know. I still have a little hair left on my head to pull out. Edit May 12, Ver 3 Newest versions will be posted here: Changes 1. Better ball ricochet Ball. Ball does not get trapped in my test. 2. Restart bug did not re-occur. BREAKOUT BREAKOUU

Hi all - I wanted to share that I am working on an extension that brings debugging to @dmsc's excellent FastBasic Cross Compiler via Visual Studio Code (breakpoints, stepping through code, modifying variables). My goals: 1. To make FastBasic as accessible as possible to newer coders by providing a way to quickly get up and running with FastBasic on Windows (Altirra) and Mac (Atari800Macx). 2. Provide an great "code stepping" debugging experience on both Windows and Mac, so you can easily step through code to tackling bugs that are harder to track down via alternate methods (Altirra debugger, print statements, etc). 3. Shows memory location (e.g $A800) of variables for those that want to know where to look at memory in Altirra. Stretch goals: 1. Debug FastBasic running on real hardware over FujiNet 2. Leverage FastBasic's code formatter 3. Provide a code minifier, useful for 10 liner contests How it works It injects some FastBasic debugging code into the source code right before compiling. This handles the communication with VSCode, sending/updating memory contents, triggering breakpoints. It then reads the LBL and LST files the FastBasic compiler outputs to find the variable locations and types. It reads/writes from Host drive H (easy first pass that works in both emulators) for communication. Here is a quick video of me demonstrating its current state. Let me know if you are interested in trying out the extension once I get it to a sharable state. This is my first VSCode extension, so I still need to read up on packaging it, etc. I plan to put the source out on github.

Mostly on the modern side this week. Arcade: Bad Dudes vs DragonNinja - 35 minutes Rally Bike - 25 minutes Atari Lynx: 8 bit slicks - 95 minutes 50 minutes or so of which consisted of playing online matches with @Songbird and friends! Commodore 64: Marauder - 75 minutes Sinclair ZX Spectrum: Chuckie Egg - 20 minutes in honor of the coronation, of course. Kokotoni Wilf - 40 minutes Say that to my FACE, buddy. Roller Coaster - 10 minutes Saboteur - 5 minutes Thanatos - 10 minutes I really enjoyed these games, but I was playing on the official iOS emulator that has really messed up controls.

https://www.virtualdub.org/beta/Altirra-4.20-test12.zip https://www.virtualdub.org/beta/Altirra-4.20-test12-src.7z MidiMate device now exposes a serial port that can be connected to serial devices. Parallel port file writer generalized so it can also attach to and log data from serial ports. Added networked serial port device that connects to a serial port and transfers data over TCP/IP. Added serial port splitter to allow two different serial port devices to independently handle the input and output halves of a serial connection. If you're suspicious at this point of the specific devices added here, you're correct, this is for MIDImaze: A lot of this was work to write a new generalized socket service in the emulator to make it easier to implement network connected devices. Which means that there are now four socket worker classes in the emulator, but the plan is to get that eventually down to one to end the madness. For two nodes, the MidiMate device needs to have a networked serial port device attached, with one listening on a TCP port while the other connects to it. The connecting side will keep trying to reconnect every few seconds. For three or more nodes, the computers need to be linked in a loop from MIDI in to MIDI out line per the MIDImaze directions. This requires using the network splitter so the input and output directions use separate TCP connections. Input doesn't need to be listen and output doesn't need to be connect, but each connection between nodes needs connect on one side and listen on the other. A limitation of the current setup is that anything that pauses the emulator will cause the game to drop, because the emulation being paused will prevent MIDImaze from communicating and the game times out after a fraction of a second. As for MIDImaze's multiplayer protocol itself, it appears to be lockstep with transferring input, so its data transfer requirements are minimal (as would be needed at 300 baud).

They use standard RJ-45 network cables to carry the SIO signals. Basically, you plug a network cable into both ends and connect to devices. I've tested with my little original drive emulator up to 32 ft. (Also uses RJ-45) and it worked well. With these you can have any length SIO cable you need by just swapping out the common RJ-45 cable between the plugs.

Consdiering the games they produced for the Jaguar, I'll let them have a few crazy predictions. Thank you Imagitec for I-War, Dino Dudes, Raiden, and Bubsy!

Demo units on the way soon... . At some point in the near future, I'll open up official pre-orders, likely with down-payment to at least cover the cost of the Teensy module.

https://github.com/wavemotion-dave/A8DSV3.1 : 08-May-2023 by wavemotion-dave Added CAR and ROM support for the more popular cartridge types up to 1MB. For now use the XEX icon on the main screen which allows you to pick XEX, ROM or CAR files. Added Real-Time Clock support (using the DS Time/Date) for things like SpartaDOS X Added new D-Pad options to support joystick 2 (for games like Wizard of Wor) and diagonals (Q-Bert like games) as well as cursor keys. Improved keyboard handling so CTRL key is now sticky. Improved menu transitions to reduce audio 'pops' as much as possible (there's still one left when loading new games that I'm working on). Auto-rename of XEGS-DS.DAT to A8DS.DAT to match new branding. Squeezed as much into the fast NDS instruction cache (ITCM_CODE) as possible with almost no bytes left to spare. Other cleanups and minor bug fixes as time allowed. Thanks to the Atarians here who have provided kind and meaningful feedback!

I made these 4 boxes many years ago and still use them. The last one is made from a 10 ream paper box. It has a lid also.

Here is a "proof of concept" demo to show that a compiled XB program can run another compiled program from a cartridge, without messing up the graphics. To the XB program 256DEMO, I added lines 4120 and 4121, and saved it as 256DEMOA. After printing 256 characters with unique patterns and 28 sprites on the screen, the extra lines show screen1, then a message, and then wait for a key press. Screen2 is still thee, just not displayed. Pressing a key will run 256DEMOB, the second program in the chain. This prints the program name and that we are using screen1. Then some squares and square roots are printed just to show that XB is working. Then press a key and screen2 is displayed, just as it was in line 4115 in 256DEMOA. This can be tested running in XB. Then the 2 programs were compiled and converted to cartridges. The 2 cartridges were combined into a single cart using a new utility I wrote. This will make it possible to combine large XB programs spanning multiple files contained in a single cart. **256DEMOA** 4115 CALL LINK("PLAY",SCALE) 4120 CALL LINK("SCRN1"):: PRINT "We are now using screen1 but screen2 is unchanged press any key to run part B" 4121 CALL KEY(0,K,S):: IF S<1 THEN 4121 ELSE RUN "DSK4.256DEMOB" **256DEMOB** 10 PRINT "We are now running 256DEMOB The program uses screen 1" 20 FOR I=1 TO 15 :: PRINT I;I*I;SQR(I):: NEXT I 30 PRINT "Press any key to return to screen2" 40 CALL KEY(0,K,S):: IF S<1 THEN 40 50 CALL LINK("SCRN2") 60 GOTO 60

Almost two years ago there was a webmeeting organized by AtariOnline.pl. At the meeting, I shared my experience of working with the RastaConverter application. I showed how to get started with the program and provided some examples of my failed and successful conversions. We also were trying to convert one photo during the meeting. I know that most of you are very familiar with RastaConverter because your conversions are really good. But maybe some of you would like to start your adventure with RastaConverter. That's why I decided to post a link to the recording of the meeting here. The whole discussion is in Polish, but guys from AtariOnline.pl added Polish subtitles generated by AI. Therefore you can turn on the on the fly translation into English or other language directly in Youtube player. The translation is not perfect, but it should be enough to get the point. The actual presentation of RastaConverter starts at about 21st minute. In addition, I am attaching the presentation I showed during the meeting. I have also prepared an English version. RastaConverter-warsztaty.pdf RastaConverter-workshops.pdf

Atari 2600 Joust 37 HSC Solar Fix 19

Atari 2600 Defender - 5 minutes Gyruss - 10 minutes Joust - 90 minutes Kaboom! - 78 minutes Solar Fox - 29 minutes

Well, they definitely lied about the console being done. There is a scenario where the hardware would have been finished and ready for manufacturing and then they'd wait until the last minute to flash the newest firmware of the firmware/OS, but considering there have been so few, if any, "true" public demos of the thing, it was clearly never at a satisfactory point for manufacture. This seems further likely considering how many times they've said that they're getting "close" over the past few years or so. In any case, it's clear there was a LOT of smoke of mirrors (and willful lies), far more than is typical for a product like this. So we really don't know what's true or not other than it's years overdue with no end in sight and the company (or whatever is left of it) hasn't made a public statement in about a year. While there are super die-hards who will say that they're too busy working to make a public statement, the rest of us know it's trivial to provide the occasional official post on social media. That I think says it all.

On the closet floor. In a mangled mess.

WARNING: CAT BURGLAR! If you missed tonight's ZeroPage Homebrew After Dark there was a mysterious Cat Burglar who stole our Susuwatari / Soot Sprite while we were distracted playing Oozy the Goo Maze Quest. The item is usually behind us on the couch but it could now be anywhere! Bernie also was lost in the kerfuffle but was later recovered. The Cat Burglar was dressed all in black, has yellow eyes, a fluffy tail, goes by the alias Sprite and is very food motivated. He is not very dangerous but is armed with 20 claws so be careful out there! Posted below is the only known image of the suspect, retrieved off of the badly damaged security camera hard drives. Once the show is posted on YouTube you may be able to catch a glimpse of the crime if you watch from If you watch from the 1h25m mark! - James DAMNING VIDEO EVIDENCE (WATCH FROM 1H25MIN):

Shipped 110 orders yesterday, have shipped another 50 today so far, and expect to be well over 200 by the end of the day. After that, smaller batches of orders will go out each day until I get through them all. ..Al

Thanks to the generosity of John Hardie @cx2k I'm happy to release several new Atari 5200 prototypes. All of these roms are slightly earlier versions, but I haven't been able to determine exactly what's different about most of them. Many of them are dated only a few days earlier so the differences are most likely very small (cope optimizations, obscure bug fixes, etc.). If anyone can tell what's different about these protos please let me know! Choplifter 1-13-84 - Seems to be very close to the known 1-4-84 proto. The only real differences I saw were the copyright on the splash screen says 1983 and there is no demo. I also found out that the unknown Choplifter prototype I had that I assumed was the final is actually slightly different. I'll attach it here as well. Gremlins 5-15-84 - Dated only two days before the final (5-17-84), but has some different bytes here and there Millipede 1-4-84 - An early version of Milllipede, but has some byte differences from the documented 1-5-84 version (http://www.atariprotos.com/5200/software/millipede/1584.htm) Stargate 1-13-84 - This is an interesting proto. It's very close to the known 'final version' (1-5-84), but despite being dated over a week later it seems to actually be an earlier proto. It has some differences on the options screen and is missing the copyright and demo. (http://www.atariprotos.com/5200/software/stargate/11384.htm) I'm also attaching some of my prototypes which I believe have already been released, but are very close in date to the new protos. Maybe they'll help people find some differences? Gremlins 5-15-84.bin Millipede 1-4-84.bin Choplifter 1-13-84.bin Choplifter (Unknown).bin Stargate 1-13-84.bin Stargate 1-5-84.bin Choplifter 1-4-84.bin

OK folks. @InsaneMultitasker and myself, along with @hloberg with involvement with Abasic, are releasing a software suite including Version 7.40 of MDOS, as well as a suite of other programs with various enhancements. Some of the extra included programs have been released separately, however they are all included in this package to make sure everyone is using the most up to date versions. This is a big caution! If you are using a TIPI, you ABSOLUTELY need to update to the latest 3.16 image. If you do not, and you manually use the MDOS Command Line Interpreter COPY command to copy files to the TIPI rather than using DM or GDM2K, you risk file corruption following updates to both TIPI and MDOS source code. Myart with TIPI mouse support, GenREF document updates for most of the XOP's as well as the TIPI XOP driver and ANSI optional XOP driver are included as well. CYA has been updated, and barring any future feature updates, this version of CYA will not require updating for future MDOS releases. For those that did not know, this could be a painstaking task to locate all the locations in the MDOS file. Now, a table is built into MDOS with auto-update properties for us whenever MDOS is updated. Updates were made to Clint Pulley's Disk Manger and Peter Muy's Editor. Bruce Hellstrom's Mouse Driver Package has been updated to also include a TIPI Mouse driver so the Geneve user can use either a Geneve Bus Mouse, RS232 mouse, or a TIPI mouse drive for mouse driver enabled programs. GPL 7.40 is part of the package, along with EXEC V2.7, ABasic 4.09, PFM, and TSTAT. TSTAT can be added to an AUTOEXEC file with the ability to test the TIPI status for updates if desired. I will repeat this again! This is a big caution! If you are using a TIPI, you ABSOLUTELY need to update to the latest 3.16 image. If you do not, and you manually use the MDOS Command Line Interpreter COPY command to copy files to the TIPI rather than using DM or GDM2K, you risk file corruption following updates to both TIPI and MDOS source code. We hope you enjoy! Beery This message has been updated. The 20230514 MDOS and Utilities.zip file contains @InsaneMultitasker's updated PFM software released January 16, 2022 and MEMTEST V2.70 versus the initial release of 20230504 MDOS and Utilities.zip. The MEMTEST program has a minor update with the added MEMEX splash screen from work I was doing trying to capture Ron Walter's animated graphic screens in his original MEMEX test program. 20230504 MDOS and Utilities.zip 20230514 MDOS and Utillities.zip MEMTEST-V270.zip 20220116 PFM Release 2.zip

Just wondering how others store their carts. I like to play the games so I try not to put them back in the boxes once I remove them. However, loose carts do not stack nicely like Atari carts. I had smaller stackable trays that fit carts fairly well that I had purchased at The Container Store. I was pleased with that solution for awhile but my carts now take more space than the trays permit and I can no longer find trays so I started searching for a better solution. I found these ink stamp holders which are almost the perfect size for carts (and overlays if you wanted to store them with the carts). I'm pretty pleased with these so I thought I'd share. Here's the 125 loose. The open spots are Championship Tennis, Super Cobra, and Tutankham. Championship Tennis was in my Intellivision when I took this picture (sorry) and my Super Cobra and Tutankham carts are both sealed. I have a loose Super Cobra coming. If anyone has a Tutankham (loose or complete but open) they want to sell, I'd be very interested since I'm not planning on opening mine. Would love to see pictures of your storage. I'm going to do the same for my homebrews but haven't decided on how to sort them yet. I like alphabetically but that would require a bunch of shuffling every time I add a new cart, especially if it's early in the alphabet. Suggestions?

I generally keep my carts in the original boxes. I still play them but I have extra carts for the more common games so I don't have to keep messing with their boxes and putting extra wear on them. Otherwise, they live in an old china cabinet I restored: The drawers in the lower center are felt lined and have dividers that fit loose carts nicely. I believe these were originally for silverware: My current solution for the games I am playing through are the amazing cart holders Caleb Garner makes. I have 2 racks of 10, one for homebrews and another for the calssic games I play regularly: I seriously love the racks you found though, cvga. That's an awesome way to display the 125 in cart form and still has easy access for gameplay.

After playing a few games of it, I can't fathom even scoring save by accident. If by some miracle I ever finished it, my thread would be titled, "I just beat White Men Can't Jump for the last time."

I have replaced the JED file on my website with the one uploaded by Candle on 3 October 2021.

As I already pointed out, there is nothing stopping anyone from producing a modern reproduction of any of the Atari computer enclosures, so long as they don't include any of the trademarked aspects (e.g., Atari name and Fuji logo). And if I want to slap a Fuji logo sticker on a reproduction case that I purchased, that is also ok so long as I'm not selling these cases with it already applied (personal use only exception -- end user can do whatever they want to their own stuff).

Yeah, the slow loading is due to the massive bank swaps that are occurring when that game starts. Maybe I could at least add some kind of indication that it's loading Ideally the way to 'fix' that is to not move 8K chunks of memory but to just swap a pointer. But that requires that I check on every memory access if I'm in the swap area and that kills performance across the board. The emulator is optimized to handle XE/PortB memory swaps and not cart banking. So XEX and ATR are still the preferred medium. I'll work on enhancing CAR/ROM support.

I think everything TT and his minions said was and continues to be a lie.

Week 1 is done! Great Start with lots of players... ... I would suggest for new players to get some sort of emulation or harmony cart or Retrocade... All the games we play are not common carts.

Here's the Italian version of WORDLE - WORDIT. No video for this one, pretty much the same as WORDLE but in Italian. All files can be downloaded on GitHub here: https://github.com/CheungChang7/TI99_HOMEBREW/tree/main/WORDIT Cartridge image attached for convenience. WORDIT.bin

Hi: I am late on this, but, just had to throw my 2 cents in. To say that MAME is better than Classic99 is not entirely accurate, considering Classic99's strengths. Classic99 is, by far, the easiest way for someone to jump in and really experience the TI 99/4A on their own system. Just start it up, and boom! it works. A determined user can, certainly, set up MAME, but, it takes far more of a learning curve, and, the effort required to obtain ROMs and such can be tricky. As for downloading the program to obtain ROMs, that thought never crossed my mind. But, I'm preaching to the choir here. Just had to say that. Thanks for all the work you put into Classic99!

Here are my times for this past week (May 1st through 7th, 2023)... Arcade: Pepper II - 133 min. in 4 sessions Pooyan - 84 min. in 6 sessions Turtles - 9 min. This week I played 3 arcade games, mainly Pooyan and Pepper II. In Pepper II, I made over 200,000 points and cleared the mazed twice in one game, but then the enemies get really fast. In Pooyan, surprisingly, I cleared the 3rd level (don't know which round number it is really) and went into the 1st round of the 4th level. It helps to use the meat in the 3rd round where the wolves start at the bottom, even if it means you have to shoot the blinking wolf with arrows. Finally I also played Turtles, but only for one game where I didn't finish the building... I think I got to the 5th floor there.

Love the cranberry color on the DSi XL - sharp looking! The main problem is that the memory fetcher is called about a quarter-million times per second. Right now it looks like this: Adding even one additional index/multiply/lookup/test does two bad things: It causes this function to expand by a few bytes and that causes the CPU/ANTIC routines to bloat by almost 2K which causes the entire CPU engine to no longer fit in the DS Tightly Coupled Memory (fast Instruction Cache... or ITCM which is only 16K in size). It causes the routine to execute a tiny bit more slowly but when accessed a couple hundred thousand times per second, causes games to start to fall below the required 50/60fps. The DS is roughly equivalent to an old 386 PC from the mid 90s. It has some amazing features - but CPU power and memory are not among them. As such, I've had to carefully craft a routine that handles the XE/Port B memory switch in as few cycles as possible to stay above the threshold for the CPU to keep up. Although I can rework this code, I'm far more likely to end up with games running in "slide show" mode Such is life with emulating a system on a system which itself is already well emulated on more modern hardware!

I don't think it's a wild guess to think they were in scramble mode over the tech not working. Almost every time (if not all) the console and games were shown, there was something not right. Be it some form of lag, or connectivity issues. Farkle chugged for Farkles's sake! Tommy did use an Aurdino board to show off the lights of the console. It would make sense they used another linux/android type board. If you check out the Banana Pi M3 specs they almost match up perfectly.

At the moment on my phone I have just Space Taxi and The Lady.

XOne Catastronauts 70 Forza Horizon 5 1103 Onsen Master 58 Out of Space 162 Think of the Children 44 Wasteland 2 164 Wo Long Fallen Dynasty 22 So, Forza Horizon 5 . . . I have never played a single game in this series ever. I generally stay away from ultra-realistic car simulation games as I don't really enjoy the idea of "tuning" a 2017 Ford Focus, but hey, I played this one. I'm not sure that I'm playing it right, but there sure is a lot of it to play anyway. I might up the difficulty this week, or I might quit all together.

Some of your ROM images are overdumps. I've stripped the ROMs from unnecessary data and I'm attaching them below. Stargate 1-13-84 is a two-chip 16KB cartridge. Millipede 1-4-84 is a one-chip 16KB cartridge. Choplifter 1-4-84 is a two-chip 16KB cartridge. Choplifter 1-13-84 is a one-chip 16KB cartridge. Some differences I've noticed: Comparing Choplifter 1-4-84 and Choplifter 1-13-84, most of the binary differences amount to switching from two-chip to one-chip cartridge during development. Basically, all ROM accesses to the $6000-$9FFF area needed to be changed to point to $8000-$BFFF instead. Other than that, there are only two other differences between the two: When pressing Reset, 1-4-84 goes to the BIOS splash screen, while 1-13-84 goes to the title screen like the final version. The CHOPLIFTER! title on the splash screen is off-center in 1-4-84, in 1-13-84 it is centered like in the final version. (Update your screenshot on the 1-13-84 page, please!) And, as you noticed, there is leftover source code garbage in 1-13-84. Comparing the "unknown" Choplifter prototype and the final version, there are two differences I have noticed: In the proto there is a little glitch on the top white bar above the points display - part of its left side is miscoloured. (Again, please fix your screenshots.) The demo mode in the "unknown" contains a custom attract mode that cycles background colours (wait a minute or so), presumably for screen-saving. The final version does not implement any custom attract mode and just uses the standard one as implemented in the BIOS, which kicks in after about 9 minutes. Note that the "unknown" prototype does not disable the standard attract mode, so after 9 minutes it kicks in and starts colour-cycling the top frame of the screen independently. The prototype (and the two earlier prototypes too) does not work with the two-port 5200 BIOS. They fixed compatibility in the final version. On Stargate 1-13-84, the game's title shows up for me on the splash screen, both in Altirra and in Atari800, same as the 1-5-84 prototype. Are you sure there wasn't some kind of a mixup? Choplifter! (1984-01-04)(Atari)(proto).bin Choplifter! (1984-01-13)(Atari)(proto).bin Millipede (1984-01-04)(Atari)(proto).bin Stargate (1984-01-13)(Atari)(proto).bin

The fumes have been strong since day one, that's for sure.

I use hockey card boxes to store loose cartridges. If the cartridge has a gatefold box, the cartridge goes back there.

If you cannot produce remakes of the 800XL cases/housings, maybe you can "simply" produce remakes of a) the 1200XL or b) the 1400XL or c) the 1450XLD or d) the 1600XL or e) the 1650XLD cases/housings or something similar, e.g. (prototype?) 1200XL with cartridge port on top. Luckily, the XL computer line features more than just one type... and I guess RGL does not have the rights for all of these.

Just my 2 cents... Essentially copyright only applies to documentation in the form of authorship of such. So for instance schematics, CAD drawings, written words, sheet music, code, ect. is protected from being copied by anyone other than the author. So in other words only the author has the right to copy his own written work. So even if someone has documented the original 800XL enclosure (e.g., CAD drawings, blueprints), that doesn't actually protect it from being copied physically. Same thing goes for a circuit design. It's my understanding that only the design and/or PCB layout drawings are copyrighted. But that doesn't stop me or someone else from recreating the enclosure or circuit board from scratch and selling it. Basically copyright doesn't cover hardware. For that you need a patent, and those are only good for about 20 years at most, and are nonrenewable. We're way past the patent expiration date for anything that Atari made BITD. Here's a good article describing all the various types of IP protections: http://www.muzique.com/clones.htm

My personal best is 200ks... in 2020 Joust. Hmmm... 204750 - SkippyBCoyote (+46) 203000 - JacobZu7Zu7 (+45) I'm also just behind the Coyote again this season, *meep meep!* 134800 - SkippyBCoyote 131300 - Absalon 128050 - JacobZu7Zu7 why is it so difficult in 2023... 😮 It's either me, or the joystick is different... or Joust felt like being hell this time around for us all

29229

At least we got another person to repair rather then replace the equipment, and it saved time as well as money.

After the annoying blue hummingbird in Buzz Bombers, the spider in Centipede grabs a close 2nd second in ANNOYANCE!!!!! I can't stand that thing..... 🤬

97950

It's been a few years since I've played in the HSC, and now I remember why - pterodactyls make me nervous. Joust - Game 1: 42100

Thanks to the help from tebe I have now setup a branch of the docs and work on the translation and restructuring. The worked in progress can be found here and will be merged back to the main branch whenever something is finished. English: https://www.wudsn.com/tmp/projects/mads/en/ Polish: https://www.wudsn.com/tmp/projects/mads/pl/ Done: - Index with change history from 2.1.5 down to 2.0.5 - Introduction Next: Complete change history for 2.0.4 and below If you find something that's not right in the already completed parts, please create an issue via https://github.com/peterdell/mad-assembler-mkdocs/issues

Weekly update! I experienced some more very weird problems with real hardware getting some letters in the status box blittered with a "color from nowhere", while everything working just perfect with Altirra. It seems yet again I fixed those, but the source or the mechanics of these problems are still a mistery to me, but then my 130XE had a long history of hardware problems, perhaps there are still some instabilities somewhere. In any case, attached new WIP binaries. I am still one step behind my own schedule, but now with 'C' you can score items (each now 500 points), and the game will go through all rounds once all items are collected. All still highres graphics are now also displayed in all rounds. And the rounds now have placeholders for intros, in round 1 and 3 you can see the fractions of it. Otherwise, the keys and the functionality is like before. You can walk around on rounds 2+, but only following round/level 1 geometry, this is my very next item on the todo list, including the trampoline jump in round 2 and the moving pad in round 3 (the former I know how to do, with the latter I still have some doubts if all my current code design will take this Popeye movement addition lightly...). Some screens for the eye too, can't be bothered to make videos, sorry... popeye.atr popeye.xex

There arn't many visible differences in today's v0.22.0 but there are some important bug fixes. Change log on the release page https://github.com/JetSetIlly/Gopher2600/releases/tag/v0.22.0 ARM disassembly is improved in this release. Thumb-2 disassembly is in the process of being improved and 32bit functions in particular are given their canonical mnemonic. Also, a snapshot of the ARM registers is preserved on every ARM step. This is much needed work to help debug the emulation of the more advanced ARM CPU found in the Uno/PlusCart. Previously, debugging of the emulation was laborious and unappealing. The macro system requested by @Gemintronic is in this version. It's very rudimentary but may be useful to some people. Documentation here: https://github.com/JetSetIlly/Gopher2600-Docs/wiki/Macro-System I've also done some work on the "audio tracker". Currently, this is just a way of viewing audio information, rather than a tracker through which you can edit (although that remains the goal). But added in this version is a way of replaying a section of audio. This is useful for isolating a sound effect and being able to see exactly what the changes to the audio registers are. I went back to this after reading about the work done in the following thread. It inspired me to look for a way of saving data from a ROM such that it can be added to source code for another game. I've experimented with that feature but I've nothing satisfactory so far. If anyone wants to help/advise me on standard representation of audio data it would be very helpful.