EricBall

To blank the beam you set the intensity to zero - which is probably impossible for an O-scope if it doesn't have that as an input. Although if you move the beam really, really fast it might not show up as much.

What you could do is have one of the bits select between two sample & hold circuits. So while X is passing through the DAC output, Y is holding the previous value & vice-versa. Then you would have 128 levels. Or instead of having the DAC drive the channels directly, you put them through an integrator. Then instead of X, Y you're generating dX/dY and potentially much higher resolution. dX/dY also requires some way of generating negative input to the integrator and it also helps to have a way to zero the integrators. If you're interested, try and find a document titled something like "the secret life of vector generators", or have a look at the Vectrex for how it generated a display.

Other quirks: 1. Some settings require a clean shutdown to save and/or take effect. 2. Lakka uses circle for OK and cross for cancel - there's a option in Settings to reverse this. 3. The default core for SNES is snes9x-2002, which might be better for performance, but is bad for compatibility (graphics glitches with Super Mario RPG, controls don't work with Donkey Kong Country), changing to snes9x-2010 resolves them. 4. I'm still trying to get bluemsx working. A kind soul provided the files which bluemsx reuqires so I now have MSX & MSX2 working. I need to do some testing then update the Lakka wiki with a better how-to. Colecovision ROMs aren't being recognized.

Ingredients: Bought: Raspberry Pi Zero W, Pro: cheap at C$13.50 (+tax & shipping, case C$6), tiny (65mmx30mm), low power (powered via USB on TV), WiFi & Bluetooth (for controllers). Con: can only handle 8 bit & 16 bit gen consoles, miniature connectors require special cables (C$6) On-Hand: 4GB micro-SD card, HDMI cable (dollar store), micro USB cable (for power), PS3 controller For initial set up: PC (downloads etc), USB keyboard (to set WiFi passphrase), mini USB cable (for PS3 controller pairing), I decided to use Lakka. The other popular option is RetroPie. However, both use RetroArch / libretro for the actual emulation (which is also used by a lot of other current non-PC emulator suites). Lakka is done by the same people as RetroArch and seems to have a minimalist ethos; which I tend to prefer. RetroPie can do more than just RetroArch, but I've read that makes configuraton more complex. Getting the system up and running was a little rocky because the battery on the PS3 controller was dead - which made me think it wasn't connecting via Bluetooth. Before I realized that I charged up my son's 8bitdo NES30 Pro controller and got it connected - although that required SSH-ing into the box. Then it was a simple matter of loading up some Vectrex ROMs (which are usable legally), clicking "Scan" and then playing some rasterized vector games. The scanning process uses the No-Intro ROM database and automatically determines which console each ROM is for then puts them into a single list by platform. While uber-simple it does cause some issues, IMHO. The No-Intro database limits itself to perfect images of the commercial releases. So while this does exclude the huge number of hacked ROM images which other ROM sets include, it also excludes homebrews. It may also cause frustration if the easiest to find ROMs for a game aren't in the database. It also lacks any kind of organization - a must when several consoles have over a thousand titles. I started by hauling out my external backup drive and started to search for the ROMs I snarfed from USENET 25 years ago. I then took the original yencoded messages, dumped them in almost 100 separate directories (to avoid possible name collison) and extracted the files. After clean-up, I had some 6000 archives with over 9000 files. Fortunately, I was able to use clrmamepro to load up the No-Intro database and use the Rebuild function to scan through those archives for any matching ROMs and re-archive them to files usable in Lakka. (Unfortunately this requires about an hour per platform.) Of course that still leaves me with several thousand ROMs (although I'm missing some notables as my collection is mostly pre-1993). My solution is to use Wikipedia's lists of best selling video games to pull out the most popular titles and do some additional pruning by language and to remove duplicates.

Personally, I'm going to pick up a RPi Zero W and put Lakka or RetroPie on it and sync it up to a Bluetooth controller. It should handle any 2600, NES or SMS game.

Unfortunately working on Tempest never seems to come to mind when I have free time. I have, however, hooked up a rotated LCD so it's easier to work with out the cabinet. I'm glad you enjoy Skeleton. It still ranks up there on my list of personal achievements.

https://arstechnica.com/gaming/2017/06/sega-forever-emulation-performance-problems/ For some reason I've never gotten into Sega's consoles. Sure I've played Sonic, but that's about it. However, when I heard about Sega Forever, I thought I might give it a try - watch a few ads, play a few games. But now I probably won't bother. The question for me is why Sega would release anything less than perfect. I have to conclude the decision makers at Sega don't care about their games, only about making money. Not to say that making money isn't important for a company, but I suspect Sega Forever will make less money than if they spent more money to release a better product. Instead of engaging players so they play more, and thus watch more ads, this poor product (with apparently heavy advertising) is more likely to turn players off - resulting in higher short term gains, but very little long term returns. I also suspect the difficulty of emulating consoles is not appreciated. The primitive CPUs and GPUs were tightly coupled and many games exploited this via cycle counting techniques. Reproducing this relationship, especially in devices which can vary considerably. Plus there's no easy way to "scale down" for lower performance devices.

I did some proof of concept work in the past which might be useful: http://atariage.com/forums/blog/7/entry-140-dli-sampling-proof-of-concept/ See also http://atariage.com/forums/topic/68937-7800-centipede-trak-ball-conversion

So, can the TIA generate speech just using normal AUDC waveforms (versus AUDF based PCM)? The initial results say no. Although you can hear some of the inflection. In the attachment is are two WAV files (one with just a simulated TIA output and one with a the input and output in stereo) along the code & executable I used. The code generates two frames worth of audio of each TIA AUDC+AUDF waveform (except AUDC 3 where the waveform is dependent on the initial state of the LFSRs). It then loads a frame worth of the input audio (8 bit signed PCM @ 31,500Hz) and does a brute force correlation to each of the waveforms at each sample offset (phase) to figure out which waveform best fits. It then writes out the best waveform at the average volume and loops back for the next frame of input. One thing I will try is to see if adding a second waveform improves the output at all. Update: wav2tia2.zip adds the second waveform and the result is more promising. A few of the letters are almost intelligible. However, I have a feeling getting better is going to be more experimentation and tweaking than following the correlation path.

In the comments for http://atariage.com/forums/blog/148/entry-13844-blast-off/there was some discussion on whether the TIA could be used to generate speech. Previously I'd done some programming which tried to brute-force fit the TIA waveforms to music. The results were less than impressive, but speech might be simple enough to achieve better results. The waveforms were based on what I'd learned about the TIA Audio Noise Generator circuit, and documented in several blog posts (sorry about the formatting), from working thought the logic in the TIA schematics. But doing back through those blogs, I wasn't 100% confident in my analysis of the AUDC logic. So I decided to start from scratch. The first step was figuring out the wired logic. Was it an AND, OR, or NOR? My Google-fu wasn't able to find anything solid, although the Wikipedia article on wired logic showed wired ANDs had the resistor tied to Vcc while the wired ORs were tied to ground. Other parts of the schematic clearly used wired AND logic, with the connection to +5 clearly indicated and no arrow. Given these differences, they probably weren't wired ANDs. If I assumed the AUDC[0] output is positive logic, then they are wired NORs as this means any high (1) will force the output low (0), so only AUDC = %0000 will cause the leftmost vertical wired NOR to be high, which then force the input to the 4 stage LFSR (after the inverter) to be high. This would match the AUDC = 0 result of "always high". Wired NOR also makes sense for the connections which prevent the LFSR from getting locked into the "don't change state'. (Although this could have been eliminated by using AUDC = 0 as a reset.) That then let's me determine the following (where c? is the AUDC bits, x[] is the 5 stage LFSR and y[] is the 4 stage LSFR, both clocked on a rising edge): x[t] = NOR1 + !( x[t-5] ^ L1 ) + NOR7y[t] = NOR1 + NOR2 + NOR3 + NOR4 + NOR5yclk = !xclk + !( NOR6 + !c1 + !( !c1 + !c0 + !x[t-5] ) )NOR1 = !( c3 + c2 + c1 + c0 )NOR2 = !( c3 + c2 + !( NOR8 + ( y[t-3] ^ y[t-4] ) ) )NOR3 = !(!c3 +!c2 + !( NOR9 + !y[t-3] )NOR4 = !( c3 +!c2 + y[t-1] )NOR5 = !(!c3 + c2 + !x[t-5] )NOR6 = !(!c1 + c0 + x[t-1] + x[t-2] + x[t-3] + !x[t-4] )NOR7 = !( !(c1 + c0 + NOR8) + x[t-1] + x[t-2] + x[t-3] + x[t-4] + x[t-5] )NOR8 = !( y[t-1] + y[t-2] + y[t-3] + y[t-4] )NOR9 = !(!y[t-1] + y[t-2] +!y[t-3])L1 = !( !( !(c1 + c0) + !x[t-3] ) + ( !(c1 + c0) * y[t-4] ) ) Reducing for the various AUDC values: AUDC = 0 = %0000x[t] = 1y[t] = 1yclk = !xclkAUDC = 1 = %0001x[t] = ( x[t-5] ^ x[t-3] ) + !( x[t-1] + x[t-2] + x[t-3] + x[t-4] + x[t-5] )y[t] = ( y[t-3] ^ y[t-4] ) + !( y[t-1] + y[t-2] + y[t-3] + y[t-4] )yclk = !xclkAUDC = 2 = %0010x[t] = ( x[t-5] ^ x[t-3] ) + !( x[t-1] + x[t-2] + x[t-3] + x[t-4] + x[t-5] )y[t] = ( y[t-3] ^ y[t-4] ) + !( y[t-1] + y[t-2] + y[t-3] + y[t-4] )yclk = !xclk + x[t-1] + x[t-2] + x[t-3] + !x[t-4]AUDC = 3 = %0011x[t] = ( x[t-5] ^ x[t-3] ) + !( x[t-1] + x[t-2] + x[t-3] + x[t-4] + x[t-5] )y[t] = ( y[t-3] ^ y[t-4] ) + !( y[t-1] + y[t-2] + y[t-3] + y[t-4] )yclk = !xclk + !x[t-5]AUDC = 4 = %0100x[t] = ( x[t-5] ^ y[t-4] ) + !( y[t-1] + y[t-2] + y[t-3] + y[t-4] + x[t-1] + x[t-2] + x[t-3] + x[t-4] + x[t-5] )y[t] = !y[t-1] yclk = !xclkAUDC = 5 = %0101x[t] = ( x[t-5] ^ x[t-3] ) + !( x[t-1] + x[t-2] + x[t-3] + x[t-4] + x[t-5] )y[t] = !y[t-1]yclk = !xclk AUDC = 6 = %0110x[t] = ( x[t-5] ^ x[t-3] ) + !( x[t-1] + x[t-2] + x[t-3] + x[t-4] + x[t-5] )y[t] = !y[t-1]yclk = !xclk + x[t-1] + x[t-2] + x[t-3] + !x[t-4]AUDC = 7 = %0111x[t] = ( x[t-5] ^ x[t-3] ) + !( x[t-1] + x[t-2] + x[t-3] + x[t-4] + x[t-5] )y[t] = !y[t-1]yclk = !xclk + !x[t-5]AUDC = 8 = %1000x[t] = ( x[t-5] ^ y[t-4] ) + !( y[t-1] + y[t-2] + y[t-3] + y[t-4] + x[t-1] + x[t-2] + x[t-3] + x[t-4] + x[t-5] )y[t] = x[t-5]yclk = !xclk AUDC = 9 = %1001x[t] = ( x[t-5] ^ x[t-3] ) + !( x[t-1] + x[t-2] + x[t-3] + x[t-4] + x[t-5] )y[t] = x[t-5]yclk = !xclk AUDC = 10 = %1010x[t] = ( x[t-5] ^ x[t-3] ) + !( + x[t-1] + x[t-2] + x[t-3] + x[t-4] + x[t-5] )y[t] = x[t-5]yclk = !xclk + x[t-1] + x[t-2] + x[t-3] + !x[t-4]AUDC = 11 = %1011x[t] = ( x[t-5] ^ x[t-3] ) + !( x[t-1] + x[t-2] + x[t-3] + x[t-4] + x[t-5] )y[t] = x[t-5]yclk = !xclk + !x[t-5]AUDC = 12 = %1100x[t] = ( x[t-5] ^ y[t-4] ) + !( y[t-1] + y[t-2] + y[t-3] + y[t-4] + x[t-1] + x[t-2] + x[t-3] + x[t-4] + x[t-5] )y[t] = !(!y[t-1] + y[t-2] +!y[t-3]) + !y[t-3]yclk = !xclk AUDC = 13 = %1101x[t] = ( x[t-5] ^ x[t-3] ) + !( x[t-1] + x[t-2] + x[t-3] + x[t-4] + x[t-5] )y[t] = !(!y[t-1] + y[t-2] +!y[t-3]) + !y[t-3]yclk = !xclk AUDC = 14 = %1110x[t] = ( x[t-5] ^ x[t-3] ) + !( x[t-1] + x[t-2] + x[t-3] + x[t-4] + x[t-5] )y[t] = !(!y[t-1] + y[t-2] +!y[t-3]) + !y[t-3]yclk = !xclk + x[t-1] + x[t-2] + x[t-3] + !x[t-4]AUDC = 15 = %1111x[t] = ( x[t-5] ^ x[t-3] ) + !( x[t-1] + x[t-2] + x[t-3] + x[t-4] + x[t-5] )y[t] = !(!y[t-1] + y[t-2] +!y[t-3]) + !y[t-3]yclk = !xclk + !x[t-5] Now to rewrite the programs to generate the waveforms and do the brute-force companding.

While part of me would love to have the physical hardware, the rational part of me points out I have a CoCo sitting in a box in the basement which my parents went to great lengths to get for me. Emulators, while not perfect, are typically much more reliable than real hardware. (One of these days I'll buy an N64 which actually works to play my collection.) Plus, no matter how much I want to play old games I don't seem to have enough free time.

The patent for the Voder shows it's done by passing a pitched buzz or white noise through a set of ten dynamically weighted band pass filters. Not the same as AUDC / AUDF / AUDV. However, it would be interesting to see whether AUDC / AUDF / AUDV could be used to generate phonemes.

I tried the AUDC / AUDF route : http://atariage.com/forums/blog/7/entry-1897-are-you-ready-for-this-pt-2/and it kinda-sorta worked (not really) although it would be interesting to try to see whether pure voice (versus music) would sound any better.

The 7800 GPU uses several data structures to generate graphics. The screen is first broken into zones which are 1-16 lines high. The graphics for each zone are generated based on a display list (which is very different from the A8 display list). The display list contains a series of entries which describe either a sprite or a series of characters (i.e. tiles). Each display list entry contains the following: 1. horizontal position of the leftmost pixel (-96 to 159) 2. 16 bit address of either a list of characters or the graphics data for the last row in the zone 3. 3 palette bits 4. number of bytes of graphics or characters 5. an optional bit to change the bits per pixel For indirect (character/tile) mode, the characters are used as the LSB of the address of one or two bytes of graphics data for the last row in the zone. So on the 7800 scrolling the background or a sprite horizontally is relatively easy - just update the horizontal position of the appropriate display list entries. Vertical scrolling backgrounds are trickier as you need to fiddle with the height of the first and last zone and the CHARBASE register for the last zone. For sprites, vertical motion means adding the sprite to multiple zones and updating the MSB of the address. (See https://sites.google.com/site/atari7800wiki/graphics-programming/vertical-motion)

Yep, I'm with you on that one. I have Win10 on my work laptop and it's not bad - at least with the interface I use. In fact, I've grown to like the search for installed apps rather than hunting through the start menu. Upgrading also means you'll get a more powerful computer, which is probably quieter! It's also a good time to review your needs list and check out your options rather than just doing a like for like replacement. e.g. laptop vs desktop and Chromebooks are great if all you need is a browser.

Turns out the guy doesn't want it enough to make an 8 hour journey. But maybe I'll see if I can at least find the time to make up a home stretch checklist for it.

As my wife often reminds me, I have a habit of not finishing projects once I've started them. (Usually while pointing at one of them.) I have to say that I've gotten better at managing this habit (although not necessarily at finishing projects). I try not to start projects, or at least start spending money instead of just time, unless I have a relatively clear understanding of what it's going to take to finish the project (and why I'm bothering). But i still have quite a few projects hanging around, most with little hope of ever being finished. One of those is the Tempest MAME project which started in 2004 when I rescued a Tempest cabinet from the curb. It's actually far closer to completion than many of my projects, i.e. requires more time and effort than money to finish. But now there's a guy who might be interested in buying it. While my wife would probably be willing to give it away just to get it out of the (unfinished) basement, I'd probably want to get more than "Twenty-eight dollars and fifteen cents." (obscure song reference), I'm not sure how much it's actually worth (or worth to me). Hell, just the control panel is probably worth a couple hundred dollars on eBay (although I suspect that's 90+% of the value of the whole shebang). Real life ain't like American Pickers - more like those LetItGo commercials. But there ain't no way I'm going to haul it out of my basement and deliver it. You want it, you gotta come and take it - and bring your own crew and equipment.

Some suggestions master[MAXSIZE], working[WORKSIZE]; // declare as global or use malloc so they use the heap rather than the stack Replace for (i = 0; (a = fgetc(fp)) != EOF; i++) master = a; with fread Or, make the code line based & use fgets rather than trying to load the entire file into memory at once. All of those hexcode comparisons are ugly. Better to use the actual characters so you don't make errors remembering ASCII codes. You should probably also look at the ctype.h functions. Looks like you're doing a tokenizer. Wouldn't hurt to see if you could use strtok rather than brute forcing it yourself. (Although strtok isn't the easiest function to understand & use.) I'd also use pointers rather than array indexes - more efficient code. That all being said - sometimes being told you can't do something is enough to motivate you to prove them wrong. And there's nothing wrong with brute force code to get you over the initial challenges. But learn the libraries and leverage those functions - you don't have to re-invent the wheel (why write your own quick sort routine when qsort exists), there's less risk of introducing your own bugs and they are typically faster because the library can be in native code.

The 7800 GPU uses several data structures to generate graphics. The screen is first broken into zones which are 1-16 lines high. The graphics for each zone are generated based on a display list (which is very different from the A8 display list). The display list contains a series of entries which describe either a sprite or a series of characters (i.e. tiles). So, to generate your 40x24 character screen (NTSC) you need the following (assuming a static background): 1. 8x8 4 color character graphics, stored in 7800 order 2. A 960 byte character map in raster order (character is the LSB of the character graphics) 3. 24 display lists, each containing two 5 byte entries pointing to the left & right halves of the character map, followed by a 2 byte list terminator 4. 28 display list list entries - 4 for the vertical overscan (13 lines each), 24 for each of the 8 line high zones The graphics can be in ROM, the rest needs to be in RAM (either copied from ROM or generated programatically). The real difficulty comes with the sprites. You first need to determine which zone(s) to add the display list entry to. Then you add the entry to the end of the display list(s), adjusting the MSB of the sprite graphics for any vertical offset.

Null-modem - a serial cable with the transmit & receive wires crossed. I think I used this: http://www.pcxt-micro.com/dos-interlink.html

Yeah. Before I junked my last 5 1/4 equipped tower PC I went through my stash of floppies and copied them to an external hard drive. Butt that was easy in comparison to recovering the files from a proprietary format backup CD. In that case I lucked out 'cause I still had the original software, the parallel port CD burner, and an old laptop which could support both. I also managed to do some backups using a laplink null-modem cable with a PC to PC copy program.

Black is easy - the absence of light energy coming from an object. Of course, black might just be very little light energy, or the colors the object reflects aren't those being generated by the local light sources, or the colors aren't those which can be detected by the observer. White is much more difficult. For humans it's when the signals generated by the three adjacent "RGB" cones are high and relatively equal. Then our brains say "that's white". Black is primarily a function of light energy, white is primarily a function of the observer.

I few years ago I went through my stash of (legal) PC software (games), seeing what would still run. Stuff which ran on DOS was basically no problem, and I'm sure a bit of fiddling with DOSBox would handle any exceptions. Anything which needed Windows 3.1 was a write-off, mostly because of stuff like Win-G and obsolete video codecs. Windows 9x software had a better chance of working, although some still had "wrong version" install issues.

I know what you mean. But at the same time, sometimes playing a game stops being fun. So while I want to complete the game, I don't want to keep playing the game. However, I do remember completing several N64 games like Super Mario 64 (100%), both Zeldas, both Banjos and Diddy Kong Racing.

Yeah, that was the game which got me to thinking about making my own - mostly because I wanted to experiment with a different play and goal mechanics.