Jump to content

walker7

Members
  • Posts

    41
  • Joined

  • Last visited

walker7's Achievements

Space Invader

Space Invader (2/9)

4

Reputation

  1. This is how the data is stored in files on this type of computer. NOTE: This is a work in progress. I will be updating this post as I think of stuff to put on here. Bytes $20-$7F represent the standard ASCII character set. Character $7F represents the cursor symbol. Bytes $00-$1F are control codes. $00 - ROM Section Header $01 - Palette $02 - Graphics $03 - Mappings $04 - $05 - $06 - $07 - $08 - Set Tab Width $09 - Tab $0A - Line Feed $0B - Comment Tab $0C - $0D - Carriage Return (same as $0A) $0E - $0F - $10 - $11 - $12 - $13 - $14 - $15 - $16 - $17 - $18 - $19 - $1A - $1B - $1C - $1D - Change Label Line Color $1E - Change Label Line Toggle $1F - Toggle Show/Hide Labels Characters $80-$FF are more control codes. When the file is saved, it is compressed using LZSS.
  2. walker7

    The Best Assembly Computer

    These are all the components of a really good assembler.
  3. Creating data structures is an important part of programming. By pressing a certain key combo (such as CTRL+D), you could enter a screen that will let you make data structures for your program. Take a look at this screen. This is where you enter data structures. The cursor starts in the prefix field. You might want to type a prefix for all the elements in the structure. Whenever you enter a new element of the structure, the name field will start with this prefix already in it. If you don't want to enter a prefix, just press Enter to go straight to the data fields. For each element, type its name in the black box, the size in the red box, and the quantity in the blue box. For the size, you can type "B," "W," or "L." You can also use "1," "2," or "4." These correspond to 1-byte, 2-byte, or 4-byte elements, respectively. The structure is a 3-character field. If you want only one of this data field, type "1." If you want more, just type however many you want. If you type a quantity greater than 999, it will show an ASCII character in the hundreds digit. For example, entering 1024 will make it show ":24", but it still represents an array of 1,024 elements. As you input bigger numbers, the hundreds digit cycles through all the ASCII characters, then repeating with different colors. Here's an example. Say you want to make a structure for a music header. Assuming you're programming for the Sega Genesis, you know that there are 6 FM channels and 4 PSG channels. First, you might want to put the song's tempo. It is a 2-byte value. With the "mus_" already in the prefix box, you just need to type "Tempo" in the black box to complete the element name. Press Enter, and the cursor moves to the red box on the same line. Now, type "W" or "2" in the red box so the data field will be 2 bytes. A "2" will appear in the box, and the cursor moves to the blue box. Finally, type "1" in the blue box to indicate you only want one field for tempo. The entire line looks like this: After that, press Enter to add a second line. Repeat this procedure for as many fields as you need in your data structure. The remaining fields for the music header are: After tempo is a pointer to each FM channel's data. There should be 6 of these, one for each FM channel. Each is two bytes. A pointer for each PSG channel's data. There are 4 of them, each are two bytes. Volumes for each FM channel. Since the YM2612 has 7-bit volume levels, these could be represented in one byte. A packed 16-bit field for the PSG volumes. This could be thought of as four 4-bit fields packed into a single value. Indices for each FM channel's instrument. These could be one byte each. After entering all those data fields, the screen would look like this: After the data structure is entered, just press CTRL+Enter to exit the screen. The data structure appears at the point where your cursor was when you entered this screen. If you entered this screen by mistake, you could press ESC and go back to programming. Any data entered here will then be discarded. This post just mentions how you would declare data structures for a program. In a later post, I will mention how to actually enter the data.
  4. walker7

    Computer Food Coloring

    This album contains colors from various computer systems rendered in food coloring.
  5. This is the second installment in computer food coloring. This time, it's the MSX palette. It's also used on the ColecoVision, and the TI 99/4A. Therefore, it could be called the TI palette. It consists of 15 colors and a transparent color. Color 0 is Transparent. Black: 8 parts Black Medium Green: 9 parts Green Light Green: 5 parts Green Dark Blue: 7 parts Blue, 5 parts Neon Blue, 5 parts Neon Purple Light Blue: 2 parts Neon Blue, 2 parts Neon Purple Dark Red: 30 parts Red, 1 part Blue, 1 part Green Cyan: 3 parts Neon Blue Medium Red: 13 parts Red Light Red: 5 parts Red Dark Yellow: 8 parts Yellow, 3 parts Red, 2 parts Green Light Yellow: 3 parts Yellow Dark Green: 24 parts Green, 1 part Blue Magenta: 7 parts Neon Purple, 2 parts Green Gray: 2 parts Black White: None The transparent color was achieved by using plain water. The medium used was Sargent Art Art-Time white tempera paint, which is opaque. And here's how it turned out: That certainly looks cool! It's pretty accurate.
  6. This next section is a big one. Wouldn't it be great if you could test code as you programmed it? Well that's where Code-As-You-Go comes into play. The mode can be accessed with a dedicated button on a keyboard. It's labeled "CAYG." Take a look at this: That's the code as you go screen. On the panel at the right, you can enter the data you want to test. On the upper right of the screen is the address that the code will assemble to. In this example, the written code will compile at address $001404. You could instead have it display which line of the source code the code will go in. First, give the subroutine a name. In this example, we have a routine called "TetrisLFSR." This will be a Motorola 68000 version of the NES Tetris RNG routine. The NES version of Tetris iterates its RNG (a 16-bit LFSR) in the following manner: Set the output bit to the XOR of bits 1 and 9, and right-shift that input into the RNG. We will replicate this routine as we enter the code. For this test, enter the input in d0. We need to enter a 16-bit value. Using a mouse, click on the fourth-to-last digit of the d0 register, then type "7259." The digit highlighted in green is the cursor. Note that the register values are displayed in hexadecimal. If you enter an invalid hexadecimal digit, nothing happens. When you enter the last digit, the cursor stays there. (If it were an A-register, the cursor would be red.) Now, time for the first instruction. Type "move.b", tab, then "d0,d2", and hit Enter (if you hit Space, it will tab for you). When you press Enter, the last line of code you wrote is automatically executed in the CAYG window, and its machine language code appears in the window as well. In M68K assembly, the instruction "move.b d0,d2" is represented by $1400. The screen looks like this: Note that after you typed the code line, that instruction automatically executed. The last byte of d0 is $59, so the last byte of d2 is now also $59. The next two instructions are "move.w d0,d1" and "lsr.w #8,d1". These are necessary to retrieve the upper byte of a 16-bit value in d1. After the second line was typed, d1 became $7259. After the third line, it became $0072. In the machine code box is E049, which is the code for "lsr.w #8,d1." Remember, only the compiled code for the last line you typed appears in the machine code box. Next, we want to take the XOR of bits 1 and 9 of the bytes in d1 and d2. Since 1 and 9 differ by exactly 8, no shifting of either byte is needed. Just XOR the bytes by typing "eor.b d2,d1", then pressing Enter. Register d1 is now equal to $2B, which is the XOR of $72 and $59. It is bit 1 from this value we need to extract and get into the X (extend) flag. To do this, type "lsr.b #2,d1", and press Enter. The value in d1 became $0A. But more importantly, look at the X and C flags. They lit up, so their value is 1. Any flag that is clear appears as white-on-black, while a set flag is indicated by the opposite color scheme. Since the XOR of bits 1 and 9 of our 16-bit value was 1, a 1 will be right-shifted in to get the new RNG value. Here is the last piece of the puzzle. Now that we have our output bit in X (and C), we can use a "roxr" instruction to shift it in. Type "roxr.w #1,d0", and hit Enter. And there you have it. The new RNG value is $B92C. With the ability to see the code execute as you type it, coding will become as easy as pie. You could also toggle register updating off/on, and you could also move your cursor to any line in the code, and press a certain button to step through the code and see the results. After finishing the code, press the CAYG button again. All the code you wrote in the CAYG screen will be placed at the place in the source code you were at when you went to this screen. You can then edit it, delete it, or change it as normal. All in all, the code-as-you-go feature could be a breakthrough for future assemblers. No matter whether it's 6502, M68K, Z80, or anything else, it's the next innovation in coding.
  7. When assembling, there are several different screen enhancements that could use to make the experience more enjoyable. One way is to change the background and foreground colors. This is the shot from the previous installment: By pressing a certain key (or key combo) on the keyboard, it will bring up a screen saying what color you want to use. That screen might look something like this: As indicated on the screen, press 0-9 or A-F to choose the appropriate color. When you press one of these buttons, the color beside the "current" heading changes to the selected color. For example, if you press "3," while in the palette shown above, you will choose purple. You can also toggle between foreground/background color choice by pressing the "/" key. To change palettes, press up/down. There are seven different palettes, plus one palette you can customize. The chart below shows the seven fixed palettes: Each row is one palette, and each palette has a different theme. They are based on palettes from older gaming and computer systems. Palette 0 - Apple ][ Palette 1 - Commodore 64 Palette 2 - Mattel Aquarius Palette 3 - Commodore VIC-20 Palette 4 - MSX Palette 5 - CGA Palette 6 - ZX Spectrum Palette 7 can be defined using your own colors. Each color in every palette is stored as a 24-bit RGB value. I will get to palette 7 editing in another post. Using the Apple ][ palette, let's say you decide to change the background to dark blue and the foreground to aquamarine. This is the result: If you don't want to change the colors, hit the ESC key. This causes any changes to be cancelled, leaving the background/foreground colors as they are. ----------------------------------------------------------------------------------------------- Another thing you could do is have some picture to look at while programming. To change the background to a picture, press a certain key combination. Pictures can be uploaded from flash drives. If you have a flash drive installed, it will list all the picture files on it. The screen would look like this: Press the appropriate button (0-9 or A-Z, depending on the number of pictures) to choose the picture. If there are too many picture files to fit on one page, press left or right to move to another page. For example, let's say you want to use the following image. It's the back of an old McCormick food coloring box from 1975. This picture was taken from Etsy: When pictures are loaded into memory, they are stored as 24-bit RGB values for simplicity of decoding. The picture is also scaled to a size of 480*360 so it can fit on the screen. The picture replaces the background color. Here's how the screenshot at the top of the page would look with this picture as the background: You can change the picture by going back to the picture menu. Plus, you can choose to go back to a solid color background by going to the background color change menu. The foreground color change menu works the same. ----------------------------------------------------------------------------------------------- In addition to pictures, you could also use a video for the background. The video loops forever. Like with pictures, you could upload videos from a flash drive. They can be in any format, but each frame is converted to 24-bit RGB format before being displayed. Frames are buffered. You could also choose to play two or more videos in a continuous loop. After one video ends, the next one starts. After the last video, it wraps back to the first one and the cycle repeats forever. Next, I'll mention code-as-you-go, one of the most important aspects of this type of computer.
  8. The interface for a good assembler is just like a text editor, with extra features added to make assembly easier. Take a look at this simulated screenshot, inspired by the Apple ][. This is a multiply routine for the Motorola 68000: There are several things that would make this more of an assembler than a word processor: Under the label "Multiply," there is a blue line stretching across the screen. You could toggle this on or off. Under this line can be shown information about the subroutine (e.g. input/output). Each line of code is indented automatically. The local labels have a period before them, and are not indented. There is a red "+" before the label. Clicking it changes it to a "-" and makes the code disappear. You could click the "-" to make the code reappear. Whether the code is folded or not, it's compiled when requested. When compiled, the branches with the ".s" extension will resolve to a ".b" (8-bit) or ".w" (16-bit) displacement, whichever is the shortest possible. If the extension is left off, assume it to be ".s". That way, you don't have to figure it out yourself. In this example, the screen is 480x360 pixels. Characters are 7 pixels across and 8 pixels down, just like on the Apple ][. In system RAM, this could be handled with one table telling which ASCII character to show (one byte per character), and another table to tell the background/foreground colors for each cell (in each byte, there are 4 bits for background color and 4 bits for background color). By default, the line under labels is enabled, tab width is 8 characters, lines after labels and code automatically indent, and code is not folded. When a mouse is used, the character that the mouse is pointing to is shown in a different color (for example, in the above screen, it would be shown as a white cell with a blue character). Characters would be stored as ASCII. The blue underline is toggled on/off with a control byte, and the tab width is also controlled using a certain byte. You could use any programming language you want, be it 6502, 68K, Z80, BASIC, etc. Regarding the keyboard, there could be additional keys based on what programming language you use. In addition to a regular ASCII keyboard, there could be attachments you could just snap on. For example, a 6502 keyboard attachment might have buttons labeled "LDA," "STA," "CLC," "SEC," "ADC," and "SBC." Next, I'll mention some enhancements you could make to the screen.
  9. A good assembler has ROM section headings. These are a way to cleanly divide the source code into settings, so you can definitely figure out at which address each section starts. Think of an assembler as if were like Microsoft Word. Section headings could appear as solid-colored bars with text on them. The user should have control over what color to make the bar. They also might have control over the font. For example, your main program header might look like this (note that all images are simulated): Notice I used the Roco font. Anyone familiar with Sonic The Hedgehog 2 will recognize this, but it's the actual font, not the Sonic 2-rendered one. Every computer program needs a vertical blank (or "V-Blank") routine. Its header might look like: One common thing to have in any program are math routines. So, you might include a section like this: For a hardware/software implementation, fonts could use a bitmap. Up to 96 different character glyphs can be stored. In addition, the numbers could be made a little bit bigger if the user chose to. Each character's bitmap can be stored using 1, 2, or 4 bits per pixel. For each character, the size needs to be specified, as well as where its glyph data can be found. For file storage, section headers could use this format (each pair of letters represents a byte): hh ff rr gg bb ll tt tt ... hh = Token for a section header (a fixed value). ff = Flags. If bit 7 is set, restart the numbering at 1. If bit 6 set, toggle whether the number is shown for this and later sections. rr gg bb = Section header color, a 24-bit RGB value. ll = Length of text. tt = The text shown. It doesn't include "Section #". It's in ASCII. Let's say that the section header token is $00, and I'll use the vertical blank section header as an example. The byte stream in the source file would look like this: 00 C0 00 60 20 0F 56 42 4C 41 4E 4B 20 52 4F 55 54 49 4E 45 53 The 00 signals the start of the section header. C0 means to make this section #1, and turn on section numbering (by default, it's off). 00 60 20 is the RGB value. It produces a dark green color. The 0F determines how many characters there will be in the section's name. The rest is the text, in ASCII. The text says "VBLANK ROUTINES". Section headers are not taken into account when compiling a ROM. They are there to cleanly divide source code. When the file is opened, the number of headers is counted, and section numbers are assigned accordingly.
  10. I have used a lot of assemblers to program games. I have used Learn to Program BASIC, BasiEgaXorz, and EASy68K. I have also used Apple ][ Basic, C++, and others. There are many different assemblers out there, but what if there was a computer (or maybe an application) with a really sophisticated assembler that could be used for programming games, and other things? The goal is to make programming easier, faster, and more enjoyable. First, I'd like to mention all the essential things that any good assembler needs. Fast interface, as well as fast assembling. The ability to cleanly divide a ROM into sections. Code/data folding. The ability to test code as you write it. Storing colors, but showing them visually, rather than as numbers. Storing graphics for a game as data, and making it show like it would in the program. Compress graphics if necessary. If it's for a system that uses tiles for graphics, computing the mappings for them. Compress data in some way. Test code for length. Being able to make short/long branches automatically according to smallest possible file size. Making sure VBlank code starts and ends properly. For any routine, sort the local labels alphabetically or numerically. Add a number of labels to a ROM that follow a certain character pattern. Add/manage data structures. Lets you pick labels/variables from a list. Calculates a ROM checksum and/or adds code. Pads a ROM to a number of bytes that is a power of 2. I might add more of these. Over time, I will be adding blog posts regarding one or more of these elements. Keep in mind that any images posted in this blog are simulated. The Apple ][ is my inspiration for their look, since it was one of the first computers I grew up with.
  11. Did you ever enjoy playing with food coloring? I did, many times. And that, plus my lifetime fascination with computers inspired me to come up with this blog. These are the 16 colors from the Intellivision, rendered in McCormick Food Coloring. It uses the standard red/yellow/green/blue, plus the neon purple/green/pink/blue, and black. Black: 8 parts Black Blue: 7 parts Blue, 1 part Red Red: 7 parts Red Tan: 2 parts Yellow, 1 part Red, 1 part Green Dark Green: 10 parts Green, 1 part Blue, 2 parts Black Green: 6 parts Green, 3 parts Yellow Yellow: 7 parts Yellow White: None Gray: 3 parts Black, 1 part Neon Purple Cyan: 3 parts Blue, 1 part Green Orange: 3 parts Yellow, 3 parts Red Brown: 7 parts Yellow, 6 parts Red, 6 parts Green Pink: 2 part Red, 1 part Neon Pink Light Blue: 1 part Neon Blue, 1 part Neon Purple Yellow-Green: 3 parts Yellow, 1 part Green Purple: 7 parts Red, 3 parts Blue And here's what they look like. Notice that they look kind of pastel, but that's because I used an opaque white paint as my medium. That does it for this segment. Next time, I'm going to render MSX colors using food coloring.
  12. Can someone clearly explain the bit pattern for TIA audio distortions 2 and 3? This is what I know so far: Distortion 2: 001010000111011->0100000000000000000100000000000 (465 bits long) Distortion 3: 001010000111011->0010110011111000110111010100001 (465 bits long) These are named "DIV31_POLY4" and "POLY5_POLY4" in the tiasound.c document. <http://web.archive.org/web/20120705120940/http://mamedev.org/source/src/emu/sound/tiasound.c> What exactly is going on here? Also, I noticed that distortion 11 is called "POLY5_POLY5", even though it makes no sound (same as distortion 0). Any reason that name was chosen? The only reason I can think of is that it matches up with distortions 2, 3, and 10: 2 = "DIV31_POLY4" 3 = "POLY5_POLY4" 10 = "DIV31_POLY5" 11 = "POLY5_POLY5"
  13. Does anyone know how the RNG works on Bomb Squad? It would be interesting to know the RNG iteration algorithm, as well as how it generates 1-digit, 2-digit, and 3-digit codes for the game.
×
×
  • Create New...