DanBoris

I have been writing some blog posts about the Crystal Castles source code. First post is here: https://dansdigitalarchaeology.blogspot.com/2022/03/crystal-castles-source-code.html In this post: https://dansdigitalarchaeology.blogspot.com/2022/08/hll65fmac.html I discuss the high level language macros that the code uses. This is a pretty cool macro library that lets you do run time nested if/then statements. I have figured out enough of the assembler to reproduce the binary ROMs, but there is some odd syntax in these macros that relate to the listing output. I wrote a post about this and would be interested if anyone has an ideas on this. https://dansdigitalarchaeology.blogspot.com/2022/08/hll65f-indenunden.html

Most of those games used the Yamaha YM2151 and the Genesis used a Yamaha YM2612 which might be why there were some similarities in the sound.

Do you remember which pins were out of the socket? That might provide a clue to what is wrong.

While digging through the source code I noticed a reference to a game state called "flashy display". It looks like this is activated if you have a high enough score at the end of the game. It fills the display with random cubes. I am not sure exactly what the score is, I modified the code so it always showed up. I played this game a lot in the arcades and don't know if I ever saw this.

Yeah, as the inventor of this header I wanted to keep it under control back then. It's no longer a battle I wish to fight.

I recently ran across a bunch of Atari arcade source code that was added to the Historical Source Github site, including source for one of my favorite games, Crystal Castles. https://github.com/historicalsource/crystal-castles I thought it would be cool to be able to re-assemble this back into the original ROMs. I started by trying to find an existing assembler that could do this, but the assembler used for this source had a lot of syntactical differences and features I couldn't find in any other 6502 assembler. I assume Atari used a VAX based assembler and I did even find documentation for a VAX assembler with similar features, but still not an exact match. I then thought about manually modifying the source to work with an existing assembler. I quickly realized that this wasn't feasible due to some of the odd syntax in this assembler. For example the Atari assembler has an different syntax for addressing modes. You can write Zero Page X like this: "LDA ZX,$PSTSL", you couldn't fix this with a simple search and replace. This would also have to be done for every game I wanted to re-assemble. So I decided the best option was to build my own assembler that could handle these files with little changes to the original source. The assembler I build is now able to reassemble the main source from the historical source repository and reproduce the MAME ccastles1 ROM set. I have setup a GitHub repository to hold the C# source code for my assembler as well as tool to split the output into separate ROMs and handle the checksum process. There is also a folder there with the files and instructions needed to rebuild the source. There are some small changes needed to the source which I have documented in the instructions, and there was one file missing from the Historical Source archive which I re-created from the original ROMs. https://github.com/danlb2000/AT6502

I will probably be at VCF East this year, would be cool to meet. I was thinking the other day it would be cool to do a MAMEdev "reunion". I have never met anyone else from the dev team in person.

I was a member of the MAME dev team for a couple years back in the 90's working on games like Cloak and Dagger, I-Robot, Return of the Jedi, Starfire and a few others. It still doesn't register with me that I worked on a piece of software that is used by so many people. I remember the days before I joined the team when I would anxiously await each new release to see what new games were added. For a lot of people, myself included, this was the first time getting to play these games again since they had played them in the arcades. Once I joined the team I was privy to what was coming in each release but had to keep it a secret.

I am trying out this extension for the first time and am having a problem compiling a .asm file. When I click Compile I get the message: Starting build of code.asm... The system cannot find the path specified. Exit code: 1 I am running on Windows.

No, since I was running it as a cartridge image on an emulator it wouldn't be able to write to the cartridge ROM.

While looking for this bug I also ran across this interesting piece of code in the display list interrupt handler: B830: AD 0A D2 LDA RANDOM ;Get a random number B833: A8 TAY ; B834: 99 0F B8 STA $B80F,Y ;Try to write to the cart rom area. This code gets random number and tries to write it to a random location in the cartridge memory space. I can only assume they were doing this to intentionally crash the game if it is running in RAM instead of on a cartridge.

John Hardie posted this on the Atari 8-Bit Computer Facebook group, so I thought it would be interested to see why this happens. I downloaded the ROM from Atarimania and was able to reproduce this bug. If you pause the game and wait for it to go into attract mode, when you press the space bar it will un-pause the game, but you will no longer have any control of the your player, and there will be no collision detection. As it says you have to restart the game to fix this. I disassembled the ROM and the cause was pretty each to find. Memory location $CC is used to keep track of the color cycling during the title page. The title page and gameplay use the same game loop, but if $CC is non-zero the game loop assumes you are on the title screen and skips the player handling code. When you start the game $CC is cleared and the game loop handles the player. The problem comes in when the game goes into attract mode. $CC is once again used for the color cycling, but when you un-pause it never clears this byte, so the game loop now think you are back on the title page and the player handling is skipped.

There is English documentation now: http://mads.atari8.info/mads_eng.html

.. and you get can a one year protection plan on them from on $24.99!

The Sinclair ZX80.

The article doesn't give any details on accuracy, but the article does say that the shipping versions of the unit will have a software update to compensate for temperature differences since the speed of sound changes with temperature. That change is pretty small for all reasonable temperatures so that indicates to me this this is pretty accurate. I did some searches but haven't been able to find any information online for this device with the exception of an E-Bay auction for the main unit. I would love to see the manual since the article says it contains the schematics.

I ran across an article about this interesting digitizer in the February 1984 issue of Microcomputing magazine. It is the Grafbar GP-7 and it's kind of cool how it works. When the pen is pressed it emits a brief ultra-sonic tone. The control box has an ultra-sonic receiver on each side that picks up the tone. The unit times how long it takes each receiver to pick up the tone and from that can triangulate the position of the pen. The results are then transmitted out a serial port to the host computer. The labels Origin, Line, Metric, Stream and Cancel are commands that can be issued by tapping the pen close to the box in front of the label.

Here is an HTML5 version of Zombo.com.. https://html5zombo.com/

This lead me down the rabbit hole of where the "80" in Z80 came from. Looks like it started with the Intel 4-bit 4004 which then lead to the 8008, 8080 and finally the Zilog Z80.

I will admit to doing this when I first got my Atari 800.

It might be a nice idea to do a Zoom call with the Atari community in a few weeks where we can all share our memories.

I mentioned in my last post that I had only met Curt a couple times, and had some interaction with him outside of those times, but when I saw him at VCF East last year he had a way of making it feel like we had been long time friends. He knew I was a hardware guy and I remember him excitedly showing me an interesting hardware feature of one of his Atari 800's. His excitement for Atari was infectious!

Very sad. I only got to meet Curt a few times but I enjoyed the little time I got to spend with him. Last time I saw him was at last year's VCF East. He brought a fantastic Atari display.

I managed to find it in my old disk images. My father worked for the Franklin Mint which at the time was also owned by Warner Communications, the main reason I ended up getting an Atari. The program demonstrates the Damascene process for etching copper patterns, which is often used in electronics manufacturing. This may have been one of the reasons Warner bought the Mint. The program runs on normal Atari Basic. The first two screens will advance on their, but takes a little bit, especially the first screen. I was using the time to load some things in the background. You can go through the rest of the presentation my pressing a key on the keyboard. DAMA.BAS