Search the Community
Showing results for tags 'disassembly'.
-
DIS6502 is an interactive 6502 disassembler. It can disassemble handle plain binary files and support specific executable files of Atari 8-bit, C64 and Oric computers. This support also includes the labels and handling of the operating system vectors to make the disassembly better. It can output the assembly listing in different configurable formats and comes with preset profiles for popular assemblers like ASMED, CA64, LADS, MAC65, and MADS. There are currently two versions available: Latest 3.0 beta build: https://www.wudsn.com/productions/windows/dis6502/dis6502.zipwith resizable window and many new features Old but stable version 2.2 from 2006: https://sourceforge.net/projects/dis6502/files/latest/download Version 3.0 uses a new workspace format. You can open old workspaces in older formats but only save in the new format. Therefore you should make a backup of your old workspace, before using the new version. Version 3.0 is not yet officially released, but you are strongly encouraged to use it and send feedback.
-
Early this year, I learned that MAME, which has recently been combined with MESS into one single emulator, also emulates some handhelds now... among those are some I have or had myself, Coleco's Donkey Kong tabletop game, MB's Bigtrak and Nintendo's Mickey & Donald (Game & Watch). I decided to take a deeper look at Mickey & Donald (after nearly competing the Bigtrak code, but that's off topic here) because I was always curious how such games have been programmed... I started on it in February 2016, about 33 years after I got the actual game. Obviously, this is a low-power device powered by two button cells and having an LCD screen. It's using a Sharp SM510 mictrocontroller with a fixed ROM. There is a nice write-up on that CPU here: http://watchdev.blogspot.co.at/2013/06/sharp-sm510-innards.html This chip has got a built-in LCD driver, and the display is memory-mapped, that is, all memory locations from $60 on are visible (at least if they've got segments connected to it). Since the disassembler in MAME didn't work quite correctly (don't know if it has been fixed by now), I wrote my own disassembler for the code in VB.net, which is actually not so hard considering the CPU doesn't have that many commands. There are some quirks like 1-byte subroutine calls which are routed through an address table in the first page, though this still only enables certain jump destinations because those addresses still only have 8 bits, but the address range of the CPU is 12 bits. Well, as I said I was curious how such a game is programmed. Actually it's quite different to what you're used to on video based systems. Normally you would have sprites, which are objects with an X and an Y coordinate, and they move and interact in some fashion. Well, for the most part, it doesn't work this way here. How it actually works is closer to a shift register, actually several of them. As you may know, a shift register is a stack of bits which get shifted left or right in sync to each other. In this game, there are several lines of bits which work like a shift register. But they're not hardwired, all of this is done in software. There is a subroutine for each possible bit which swaps that bit in a memory location with the carry flag. The actual bits in a line often don't have a real logical position in memory, rather they were seemingly positioned so the lines in the LCD screen are best used. For instance, for an object that has 3 possible positions, one position might be displayed when bit 2 of memory location $62 is on, the second one is on bit 1 of memory location $6D and the third one on bit 2 of memory location $6B. The line is now shifted by starting at the first position, fetching its status to the carry flag. Then you set the memory location for the next bit (by one instruction) and call the respective subroutine to swap the bit you want to access. Now you've got that bit in the carry bit and go on to the next location... and so on until the line is through. For instance, Mickey on the left has three possible positions, on bottom, in the middle or on top. If the player presses the "up" button, the Mickey line gets shifted upwards, on pressing "down" it gets shifted downwards, only that the last bit in the line gets re-set if it's found to be on after the shifting. The game code generally doesn't "know" the coordinates of any object visible on screen, it's all done by checking if a certain bit in memory is set. And there are more shift "lines"... two for the hose (one for small and one for big blobs), six for drops and fires and one for Donald on top. The fire shifting routine checks for each position if the corresponding drop bit is set, if so, both are cleared, a point is scored and the routine terminates. The routine shifting down the drops does the same. As for game variables, there are only a few controlling if there's one of the possible leaks, which game or demo mode is on, if the alarm is set, and as far as I can tell two counters for keeping the correct speed. But maybe there are some more which I missed because I didn't examine the complete code. Since the objects don't have coordinates in memory, all checks that depend on a certain location to be set or clear, such as collision detections, check the actual bit in memory... for instance, the routine that creates new drops checks all three possible locations of Donald to find out where he is and place a drop there. That way, they also go around the limitation of the CPU that indexed writes are very hard to do... with this game architecture, none are required, the closest thing to it is actually the routine that converts score digits to the 7 segments that are displayed for each number. This one uses an indirect jump instruction which loads the data byte to the PC. Keep in mind that the PC is not linear, but a pseudo-random shift register, which means that the numbers 0-9 get converted to addresses which are actually all over the place in that page. Oh, the total ROM in that chip is 2772 bytes (44 pages with 63 bytes each). I guess it's similar for other Game & Watch games, though much later models like Pinball and Super Mario Bros. might use a different chip, as may much earlier models like the Silver Series Ball, Vermin, Fire and Judge... there are more advanced models SM-511 and SM-512 supporting independent sound generation, more segments and more ROM up to 4K while the SM-510 has to generate sound writing 0's and 1's for each wave "by hand". On the other hand, there's a simpler chip with only 2016 bytes of ROM that may have been used on the first games. But still I suppose most Game & Watch games will have been programmed in a similar way, because you see some kinds of shifted strings of segments in all of them, with some of them going only one way and others going both ways.
- 3 replies
-
- 1
-
- Game & Watch
- Architecture
-
(and 5 more)
Tagged with:
-
I started looking at a disassembly of Melody Blaster, after I became curious as to which ECS games supported tape expansions. My hope is to create virtual tape images for jzintv that can be used to allow extra music into the game. As an intermediate step, I'll try creating a ROM hack with new music in it. The ROM follows the standard memory map for 12K Mattel games: 8K in the $5000-6FFF range, and 4K in the $Dxxx range. Most of what's in $6xxx is the Help text, and it overflows a little into $D0xx. After that is the 11 tunes. There are a bunch of calls in the code to functions at $40xx and $41xx, so the ECS "Executive ROM" must be located there. The ECS does have onboard RAM, and I'm pretty sure tunes are loaded there and then parsed by the ECS EXEC. The list of pointers to the starting addresses of each tune starts at $57E7 (cartridge ROM), with the low-order byte listed first, and the starting address for the current tune is loaded into $354 (16-bit system RAM address). The game allows for one extra tune to be loaded into memory, either from a tape or by playing a tune (one channel only). I hope tape tunes aren't limited to a single channel, but I don't know yet. All the music data fits into 8-bit words, probably because that's the width of the ECS RAM. As for the tunes, the first 18 bytes comprise the title. I looked at the first 2 tunes so far, which both had a 9-byte signature starting with 0 1 1 9 6 6 9 4. After that was the data for each of the 4 channels used by the game (2 sprite-based notes per channel). The channels' lines are listed separately, in order from low to high, and not all of them are used. The music data consists of byte pairs: a note ($18 is Middle-C) or $80 for a rest, and then a duration in "ticks". In most cases, channel data is separated by the signatue 1 1 $80 1, but I found an exception in Tune 2 "ROW,ROW THE BOAT". That signature appears twice in a row in Tune 1 "BLASTER'S BLUES" because one channel is not used. In many cases, channels' music data is prefaced with a rest, because another channel has a starting pick-up. The first channel for BLASTER'S BLUES is the left-hand harmony line, which has a small pause to allow the pickup in the right hand melody line. Then the channel-separator signature appears twice, followed by the melody line. Strangely, the fourth channel has a series of rests which add up to 234 ticks, where it is then used to play a second note in the right hand at the tune's end. There are a total of 9 consecutive rests here, the first 8 of which are 25 ticks each ("$19"), and the last of which is 34 ticks ("$22"). There's a little more data here which I haven't yet deciphered. ROW,ROW THE BOAT is played as a round, with the harmony line picking up a measure behind the melody line. The same value $18 is used for the C note in their respective octaves, which leaves me to believe that the ninth byte in the signature following the title contains bits to tell us which channels have octave offsets (in other words, are meant to be played by the left hand or the right hand). The end-of-channel signature is also absent at one point, so maybe the header signature tells us which channels are not used at all? That's as far as I got so far. I'll take the time to study the other tunes later today. Another interesting point is that there will sometimes be tiny spaces between notes at what appear to be arbitrary points: a note played for 2 ticks followed by a 1-tick rest in one hand and for the full 3 ticks in the other hand. That indicates to me that the music data was created by a device that a MIDI keyboard was connected to, and that data was only moderately cleaned up afterwards to get a consistent tempo across all channels.
- 4 replies
-
- 8
-
- hacks
- disassembly
-
(and 6 more)
Tagged with:
-
Hi!, As promised, here is my own disassembly of TurboBasic XL v1.5 (the original published one). Assembling with MADS should generate the same binary as the original (byte for byte), if not, it is a bug and should be fixed. Many labels are still in the original "LXXXX" form, but should be self explanatory from the assembly source, all labels for statement and function execution are of the form "X_", all labels for the syntax tables are "LS*", the corresponding syntax codes are "_S*". Where it made sense, I used the labels from AtariBasic sources, but probably better names and more consistency for many labels is needed, as I only worked in this sporadically over a long time. Hope it's useful to interested people EDITED: Current version of the disassembled sources is at https://github.com/dmsc/turbo-dis turbo-mads.asm
- 41 replies
-
- 9
-
- TURBO-BASIC
- TURBO-BASIC XL
-
(and 2 more)
Tagged with:
-
The JU-253 floppy drive in my 1581 failed. It has a hard time starting the spindle motor even though it spins freely. It appears a small cap on the drive board as leaked, which is apparently a common failure for a similar model. The problem is I cannot get the bloody thing apart. It appears the retaining spikes inside the floppy guide and holding mechanism are pressure fit into the chassis. This drive is used in both Amiga computers and Commodore 1581 disk drive, so I am posting here rather than crossing in both the Commodore and Amiga subs. Does anyone know how to get this thing apart? It has been a very reliable (long-lived, anyway, until, well, you know, it failed) and QUIET drive and I would like to bring it back to life.
-
Good Morning, I used Distella to disassemble Chopper Command but the bin didn't run when recompiled with DASM. I found missing assembler instructions such as ORGs SEGs and the Processor spec. It runs now with issues. I'll continue fixing it up but I'm curious- Did I use Stella wrong? Is there a switch I should have added? I used -a only. I made notes of my changes in the attached asm- just search for semicolons to see them. The second attachment is my current .bin. The third attachment is the original .bin if someone wants to disassemble to compare results. Thanks! CPRCMD.asm CPRCMD.asm.bin Choprcmd.bin
-
One thing that has always bothered me about Super Breakout on the 2600 was the colors & sounds. I like the original game's much better and would love to be able to hack Super to use those. I know nothing about programming the 2600 (but I know the very basics of 6250 assembly). I have been playing around with running code at 8bitworkshop and was wondering if anyone had a disassembly of breakout and super breakout or could lend a hand in modding the game?
- 2 replies
-
- breakout
- superbreakout
-
(and 3 more)
Tagged with:
-
Donkey Kong ColecoVision Donkey Kong Disassembly
ColecoFan1981 posted a topic in ColecoVision Programming
I've just disassembled the 16K and 24K ROM versions of the ColecoVision Donkey Kong. The reason I did this is so that you fellows can be able to help me determine where I should look within these two disassembly files in regards to which instruction is relevant to the bonus timer being computed. I also intend to share these files with you for the purpose of correcting certain bugs in the 24K ROM version, such as Mario falling right through the up elevator from his starting point. ~Ben Donkey Kong ColecoVision 24K.txt Donkey Kong (1982).asm