Jump to content

Search the Community

Showing results for tags '16-bit'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Atari Systems
    • Atari 2600
    • Atari 5200
    • Atari 7800
    • Atari Lynx
    • Atari Jaguar
    • Dedicated Systems
    • Atari 8-Bit Computers
    • Atari ST/TT/Falcon Computers
  • Gaming General
  • Marketplace
  • Community
  • Game Programming
  • Site
  • Classic Gaming News
  • The Club of Clubs's Discussion
  • I Hate Sauron's Topics
  • 1088 XEL/XLD Owners and Builders's Topics
  • Atari BBS Gurus's Community Chat
  • Atari BBS Gurus's BBS Callers
  • Atari BBS Gurus's BBS SysOps
  • Atari BBS Gurus's Resources
  • Atari Lynx Programmer Club's CC65
  • Atari Lynx Programmer Club's ASM
  • Atari Lynx Programmer Club's Lynx Programming
  • Atari Lynx Programmer Club's Music/Sound
  • Atari Lynx Programmer Club's Graphics
  • The Official AtariAge Shitpost Club's Shitty meme repository
  • The Official AtariAge Shitpost Club's Read this before you enter too deep
  • Arcade Gaming's Discussion
  • Tesla's Vehicles
  • Tesla's Solar
  • Tesla's PowerWall
  • Tesla's General
  • Harmony/Melody's CDFJ
  • Harmony/Melody's DPC+
  • Harmony/Melody's BUS
  • Harmony/Melody's General
  • ZeroPage Homebrew's Discussion
  • Furry Club's Chat/RP
  • PSPMinis.com's General PSP Minis Discussion and Questions
  • PSPMinis.com's Reviews
  • Atari Lynx 30th Birthday's 30th Birthday Programming Competition Games
  • 3D Printing Club's Chat
  • Drivers' Club's Members' Vehicles
  • Drivers' Club's Drives & Events
  • Drivers' Club's Wrenching
  • Drivers' Club's Found in the Wild
  • Drivers' Club's General Discussion
  • Dirtarians's General Discussion
  • Dirtarians's Members' Rigs
  • Dirtarians's Trail Runs & Reports
  • Dirtarians's Wrenching
  • The Green Herb's Discussions
  • Robin Gravel's new blog's My blog
  • Atari Video Club's Harmony Games
  • Atari Video Club's The Atari Gamer
  • Atari Video Club's Video Game Summit
  • Atari Video Club's Discsuuions
  • Star Wars - The Original Trilogy's Star Wars Talk
  • DMGD Club's Incoming!
  • DASM's General
  • AtariVox's Topics
  • Gran Turismo's Gran Turismo
  • Gran Turismo's Misc.
  • Gran Turismo's Announcements
  • The Food Club's Food
  • The Food Club's Drinks
  • The Food Club's Read me first!
  • The (Not So) Official Arcade Archives Club's Rules (READ FIRST)
  • The (Not So) Official Arcade Archives Club's Feedback
  • The (Not So) Official Arcade Archives Club's Rumor Mill
  • The (Not So) Official Arcade Archives Club's Coming Soon
  • The (Not So) Official Arcade Archives Club's General Talk
  • The (Not So) Official Arcade Archives Club's High Score Arena
  • Adelaide South Australia Atari Chat's General Chat & Welcome
  • Adelaide South Australia Atari Chat's Meets
  • Adelaide South Australia Atari Chat's Trades & Swaps
  • KC-ACE Reboot's KC-ACE Reboot Forum
  • The Official Lost Gaming Club's Lost Gaming
  • The Official Lost Gaming Club's Undumped Games
  • The Official Lost Gaming Club's Tip Of My Tounge
  • The Official Lost Gaming Club's Lost Gaming Vault
  • The Official Lost Gaming Club's Club Info
  • GIMP Users's Discussion


There are no results to display.

There are no results to display.


  • AtariAge Calendar
  • The Club of Clubs's Events
  • Atari BBS Gurus's Calendar
  • ZeroPage Homebrew's Schedule

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start










Custom Status



Currently Playing

Playing Next

Found 11 results

  1. Hi All, Seriously, I have no idea what is happening here. I am working on a TURBO BASIC program that will let the user exercise their (relative) ear. It is planned to test intervals melodic and harmonic and probably a few other things. To come as close as possible to the wanted frequency (I have really a sensitive and precise ear) I use 16-bit pokey registers in stead of 8bit. Downside is that I only can play 2 tones together, but ok... Perhaps I might decide later to go to the 8bit 4# voice capabilities of pokey. Earlier today I found that DSOUND 0,4020,10,10 would produce a perfect 220Hz A and and DSOUND 0,2008,10,10 would produce a perfect 440Hz A. I was very happy with the results, I saved my program to disk and that was that. Now I fired up the Atari with Turbo Basic and I was playing again with the DSOUND command and I was not as satisfied as I was earlier today. I was like: hmm it is not right. So I started playing again with it and I found different values. After checking: DSOUND 0,4028,10,10 gives the perfect 220Hz A DSOUND 0,2017,10,10 gives the perfect 440Hz A DSOUND 0,1001,10,10 gives the perfect 880Hz A Ok it is not really a big difference, but still, I was not as close as I would have thought. So my 2 questions are: How stable is this anyway? Can I assume that pokey in 16bit modus produces a steady frequency or does it fluctuate (when colder/warmer) or is it a different part on the PCB that might have influence on the frequency? (Like the audio-out circuit)? I am using the speaker of my television set, so it is not directly what comes out of pokey. In the Turbo Basic Manual by Wil Braakman I read a formula: "de berekende frequentie in HERZ nu 1789790 / (2*freq+14) bedraagt. De frequentie bedraagt dan 16 bit (0 . . . . 65535)" (Braakman, 1988, p. 3-36). This means that the 16bit pokey value for 440Hz would be: 1789790 / (2*440+14) is approx. 2002 which is closer to my earlier find of 2008, and than my newer find of 2017. It seems that either this formula is wrong, or my ears/tuner-app. My personal findings using ear and tuner-app come way more close to 220Hz, 440Hz and 880hz than this formula. Is there a better formula somewhere? Or is there something else wrong? Or do I ask too much of a formula anyway? I am really interested in this stuff, I hope someone can help. Marius -- Braakman, W. (1988). TURBO BASIC XL 1.5 MANUAL. 's-Hertogenbosch, Netherlands: Stichting Atari Gebruikers.
  2. walker7


    From the album: The Best Assembly Computer

    A set of 7 different color palettes to use while programming.
  3. 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.
  4. Why do 16-bit light guns look so ridiculous? SNES Super Scope: Sega Menacer: Compared to these 8-bit offerings: Famicom Revolver: NES Gray Zapper: NES Orange Zapper: SMS Light Phaser: Atari XG-1: I mean, I can understand that in the 90s, video game and toy makers were pressured to make guns look unrealistic as possible, but come on, the Super Scope and Menacer just look absolutely ridiculous. Even later gen systems like the PS1 Namco Guncon look normal in comparison. What's worse, with all the modular detachable pieces that can get lost over the years, it's nearly impossible to find one complete.
  5. 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.
  6. 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.
  7. Hi everyone, Microzeit is a new German publisher on the digital era of home computing and pixel creativity. The Atari ST and the Creative People book vol.1 has been sold worldwide for a good quarter now. Due to the increasing request from North America, especially from Canada and the US, I decided to offer exclusive express delivery to North America. I have feedback from customers: Only 7-10 days and the book is there >>> >>> MICROZEIT is a new independent publisher focused on digital culture and computer history. We open up with a book series about digital creativity in the 80s. THE ATARI ST AND THE CREATIVE PEOPLE are narrative art books with a premier presentation of contemporary motion design. For the first time fast paced pixel movements are captured in a book. Our hearts are beating for digital art as well as good storytelling. Find our trademark design and view on the pixel era in the first volume BREAKIN’ THE BORDERS. Every part of this book is a journey and we work hard on transmitting this idea for you. It’s work-in-progress. Thanks to a solid crowdfunding it will be an attractive analogue conversion of screen art. As independent producers it’s our ambition to fill some pieces into the puzzle of “digital culture”. Be with us. www.microzeit.com
  8. 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.
  9. 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.
  10. I'm mainly looking to see what other systems are owned by those who own Atari 8-bit computer systems. But, if you're devoted to playing a lot of Atari 8-bit on emulation, or if you're a former dedicated Atari 8-bit computer owner, go ahead and vote too. Personally, I only own a 2600 at the moment, which was the system my family used when I was young (needs the TIA replaced). I wouldn't mind having a 7800, as it covers the 2600 and then all of its own. But I'm in no hurry to get one, as I don't find the 7800 library all that great. I'm yet to find a compelling reason to get a 5200 when I own all of its games, some converted, to play on the 8-bit computers. None of the other consoles interest me, although I see the Lynx as a much more attractive system, now that its video can be fed to a monitor (after being modded). I have little interest in the other Atari computers; for their era, I'd rather own a Mac -- which I do (Quadra 605, in need of a cap job).
  11. Since some of us collectors are now getting a chance to use computing platforms that we didn't really get much hands-on exposure to way back when, it would be nice if there were "top 20 commands" guides for the various retro-computers. These are great ways to distill the information you'd normally see in a book, down to a page or two. Examples include: http://www.blitter.com/~nebulous/coco.html http://www.blitter.com/~nebulous/amiga.html http://www.blitter.com/~nebulous/msdos.html http://www.oldsoftware.com/Commtips.html (a bit wordy, but still cool) Does anyone have or know of anything like this for other machines? Atari, Apple II, Vic 20, NEC PC-88, TI-99/4A, TRS-80 Model series, Commodore PET, Adam, MSX, etc...
  • Create New...