EricBall

Over Christmas we watched all of the Star Wars movies (in story order) before going to see Last Jedi. One of the things I liked about Last Jedi is how many of the plot points didn't take the easy & predictable ending. There were lots of times where I thought, "that isn't what I expected". Can someone explain why Vice Admiral Amilyn Holdo didn't reveal her escape plan to Poe? Not doing so makes it seem like she had no plan, which kicked off the whole Finn / Rose stoyline that ultimately resulted in the First Order learning of the plan. And while I could nit-pick the film to death, it was a decent addition to the Star Wars films - certainly better than it's immediate predecessor and in the top half of the list. It will be interesting to see where the story goes from here as the Rebel Alliance tries to recover from being effectively wiped out from a military perspective.

(See previous entries for more info on the game.) It's surprising what a little motivation and enthusiasm can accomplish. One big help was I reached out to YouTuber Torogadude and asked if I could use his compositions as background music and he agreed. Bonus! I've also added sound effects and knocked a lot of other items off my to-do list, which leaves really only three big ones: Revise the embedded HTML "About" pages and try to fix the back navigation so it goes to the previous page rather than the back to the main menu. Also update slidetiltroll.walkerville123.ca to match Review the Apple Guidelines to make sure there isn't anything I need to do before I submit it. Do a code walkthrough and tweak / fix as required

I'd disagree with that. Nearly all of my employer's corporate apps (e.g. the apps they tell me to use as part of my job) are browser based, or have browser versions. Yes, my corporate laptop runs Windows 10, but I could probably do my job just as well with a MacBook and possibly even with a tablet. Kinda like that iPad Pro commercial - is it a computer or something else and does it really matter?

I'm back to working on my iOS game "Slide Tilt Roll" in preparation to using it for a presentation to some computer students at my son's high school. I updated the MacBook to High Sierra, updated to XCode 9, installed XCode 8 to upgrade the code base from Swift 2.2 to Swift 3.0, then used XCode 9 to bring it up to Swift 4.0. That worked for 90% of the code, then I needed to go through and manually fix a few errors and warnings (mostly confined to sqlite and CGPath functions). I've also tweaked the launch and main page backgrounds to display better on the iPhone X - I wonder if I can use one of them at the Apple Store for a quick test The next big thing is to add sound effects and music. I've found a paper for some algorithmically generated music which will I will hopefully be able to use. I'm still looking for anyone willing to create levels to supplement the ones I have created programatically. Interested? You need an iPhone, iPad or iPod Touch running iOS 9 or later (configured to send email) and a willingness to create levels gratis for my 100% free application. In order to install my app I need the UDID for your device. This can be obtained from iTunes by clicking on the Serial Number on the device Summary panel, then right clicking on the hex digit string, selecting copy, and sending it to me via PM. (If you don't have iTunes, you can get it by plugging into a computer and looking at the USB device information. Ask, and I'll provide instructions. Any other methods (websites, apps) are either outdated or extremely suspect.) After I get your UDID I will update my Apple Developer account device list and send you the link to download and install. Muchas gracias Merci beaucoup Vielen Dank

Yep, I was about to give you that link, but you beat me to it. It really comes down to how much CPU time is available. While the 7800 GPU is capable of displaying more sprites (total and per line) than the NES PPU, each 7800 sprite requires a significant number of CPU cycles to move around the screen, whereas on the NES the CPU cycles are trivial. Then to make matters worse, because of the unified memory the 7800 CPU loses even more cycles for each sprite & tile displayed.

One of the trickier parts of programming the 7800 is working through the 7800 graphics modes and how to map colors to sprite data, particularly for the 320 modes. Although I've given this info before (except for 320D), I'm hoping that the following will be useful to anyone wanting to program the 7800 or hack existing games. 2019-05-29 I have attached a spreadsheet which breaks down this data into a (hopefully) more usable form. 160A (WM=0,RM1=0,RM0=0) 2 bits per pixel, 3 colors + background/transparent from 8 palettes D7531 D6420 palette = P2 P1 P0 0 0 BG / transparent 0 1 C1 1 0 C2 1 1 C3 160B (WM=1,RM1=0,RM0=0) 4 bits per pixel, 12 colors + background/transparent from 2 palettes D75 D64 D31 D20 P2=0 : palette 0-3, P2=1 : palette 4 -7 0 0 0 0 BG / transparent 0 1 0 0 P04 C1 1 0 0 0 P04 C2 1 1 0 0 P04 C3 0 0 0 1 BG / transparent 0 1 0 1 P15 C1 1 0 0 1 P15 C2 1 1 0 1 P15 C3 0 0 1 0 BG / transparent 0 1 1 0 P26 C1 1 0 1 0 P26 C2 1 1 1 0 P26 C3 0 0 1 1 BG / transparent 0 1 1 1 P37 C1 1 0 1 1 P37 C2 1 1 1 1 P37 C3 320A (WM=0,RM1=1,RM0=1) 1 bit per pixel, 1 color + background & transparent from 8 palettes D7531 D6420 palette = P2 P1 P0 0 0 BG + BG / transparent 0 1 BG + C2 1 0 C2 + BG 1 1 C2 + C2 320B (WM=1,RM1=1,RM0=0) 2 bits per pixel, 3 colors + background & transparent from 2 palettes D75 D64 D31 D20 P2=0 : palette 0 P2=1 : palette 4 0 0 0 0 BG + BG / transparent 0 0 0 1 BG + C1 / transparent 0 1 0 0 BG + C2 0 1 0 1 BG + C3 0 0 1 0 C1 + BG / transparent 0 0 1 1 C1 + C1 / transparent 0 1 1 0 C1 + C2 0 1 1 1 C1 + C3 1 0 0 0 C2 + BG 1 0 0 1 C2 + C1 1 1 0 0 C2 + C2 1 1 0 1 C2 + C3 1 0 1 0 C3 + BG 1 0 1 1 C3 + C1 1 1 1 0 C3 + C2 1 1 1 1 C3 + C3 320C (WM=1,RM1=1,RM0=1) 2 bits per pixel, 4 colors + background & transparent from 2 palettes D75 D64 D31 D20 P2=0 : palette 0-3, P2=1 : palette 4 -7 0 0 0 0 BG + BG / transparent 0 1 0 0 P04 BG + C2 1 0 0 0 P04 C2 + BG 1 1 0 0 P04 C2 + C2 0 0 0 1 BG + BG / transparent 0 1 0 1 P15 BG + C2 1 0 0 1 P15 C2 + BG 1 1 0 1 P15 C2 + C2 0 0 1 0 BG + BG / transparent 0 1 1 0 P26 BG + C2 1 0 1 0 P26 C2 + BG 1 1 1 0 P26 C2 + C2 0 0 1 1 BG + BG / transparent 0 1 1 1 P37 BG + C2 1 0 1 1 P37 C2 + BG 1 1 1 1 P37 C2 + C2 320D (WM=0,RM1=1,RM0=0) 1 bit per pixel, 3 colors + background & transparent from 2 palettes P1 P0 D7531 D6420 P2=0 : palette 0 P2=1 : palette 4 0 0 0 0 BG + BG / transparent 0 0 1 0 C2 + BG 0 0 0 1 BG + C2 0 0 1 1 C2 + C2 0 1 0 0 BG + C1 / transparent 0 1 0 1 BG + C3 0 1 1 0 C2 + C1 0 1 1 1 C2 + C3 1 0 0 0 C1 + BG / transparent 1 0 0 1 C1 + C2 1 0 1 0 C3 + BG 1 0 1 1 C3 + C2 1 1 0 0 C1 + C1 / transparent 1 1 0 1 C1 + C3 1 1 1 0 C3 + C1 1 1 1 1 C3 + C3 MARIA.zip

Just a suggestion - don't put the cart (graphics) before the horse (code). In addition to the size of the sprites, the artist is going to need to know the graphics mode / palette. And for anything other than static sprites, they are going to want to know something about how the sprites move and need to be animated. ROM space might also be a factor. You can do a lot of coding with temporary sprites and be in a much better position to know what you need the artist to provide and the limitations they must work inside.

Awesome Video Game Data 2017 Based on the data, I'd say console still has life for a couple more years. As long as there's money to be made, consoles will still exist.

There's no problem using a POKEY (or any other chip which drives the cartridge audio pin) and the TIA at the same time. The problem is updating the TIA at a high enough frequency to make any sampled audio worth it. Updating the TIA once per frame (60Hz) is trivial, but after that it gets considerably harder. You could use the DLL NMI to update it once per zone, i.e. every 8 lines = 1967Hz or every 16 lines = 983Hz, but you will have to adjust for 23 lines of VBLANK. Similarly, you could bang on WSYNC and update the TIA every line (15,734 Hz), but that will waste a lot of CPU time and you'll still have to handle VBLANK (unless you're only playing music). Note: 2 or 4 bit won't make any difference except for how much ROM space the samples use. You will also need to consider how much CPU the update routine will require. I'd recommend seeing if the native TIA waveforms can provide any of the sound effects and update the TIA once per frame.

Whether a games platform lives or dies depends on whether it can build and maintain what I call the "virtuous cycle". Developers want to create games for platforms where there are a large number of consumers who are likley to buy the game. Consumers buy game platforms which have games they want to buy and play. The more people who have the platform, the more developers are likely to create games for that platform and the more games for the platform, the more consumers are likely to buy into the platform. However, the mobile platforms, cross platform development and freemium pricing models has broken this idea. People no longer have to buy into a gaming platform because they already bought into it for other reasons. Freemium pricing models also drop the cost to consumers to play games, although developers suffer because more people playing doesn't mean more people paying. Consoles largely can't compete in this space. Why pay hundreds of dollars for a console instead of using the mobile device you already have? Why pay $60 for a game when there's a huge library of "free to play" games? Consoles can only compete by offering complex, big-screen games which mobile can't, i.e. competing with PC gaming. And as HoshiChiri notes, the one advantage consoles have over PCs is uniformity. Consumers can buy games knowing they will work and developers can develop for a single target. Developers also like that consoles are more locked down than PCs, which helps prevent privacy and cheating. Unfortunately, developing those complex, big-screen games has a very high up-front cost, which puts it out of reach of a lot of developers and increases the downside if a game doesn't sell well. Without enough developers creating possible system sellers, consumers aren't going to buy the consoles, and the "virtuous circle" collapses. Maybe consoles will become like iPhones - periodically Sony and Microsoft will release the next generation of the Playstation and XBox, like the PS4Pro and XBox One S&X, which maintains backwards & forwards software compatibility while providing more CPU & GPU power for games to tap into and graphics improvements like 4K & HDR. Or maybe consoles will move to the cloud, e.g. OnLive style gaming.

And as someone who has programmed for both the 2600 & 7800, I agree with Kosmic Stardust - start from scratch. Have a look at your A8 code - how much of it is concerned with setting up the ANTIC display lists? Throw that out; MARIA display lists are radically different from ANTIC display lists. Next, how much of the remaining code is designed to make the code you just threw out easier / better? Throw that out too, you'll need to redo that code to make the code to set up the MARIA display lists easier . Sound? Throw it out, you only have a TIA (2 channels & half the frequency resolution). Controllers? Throw it out - different controllers and digital instead of analog. Graphics data? Throw it out; MARIA does 4+ colors per pixel. Collision detection? Throw it out, the 7800 doesn't have collision detection registers. Now, take a look, how much code is left? Is any of it worth saving or are you better off starting off with a clean page (and maybe even using 7800 Basic). At one point I did a write-up on the 7800 versus the 5200 : https://sites.google.com/site/atari7800wiki/atari-5200 which might help you as a starting point.

You'd think at some point the lenders would start to question whether they were ever going to get paid and stop throwing good money after bad.

Define "higher quality". The TIA (and POKEY for that matter) are simple LFSR based waveform generators. From a programming perspective there are three inputs for each of the two channels: AUDF, a 5 bit divisor of 2 * the horizontal retrace frequency AUDC, a 4 bit LFSR selector, which controls the AUDF frequency to waveform AUDV, is a 4 bit volume control of the waveform output The problem is these values are hard coded into the game ROM. So even if you added an extra bit into one of the registers, the games wouldn't be able to use it. What you could do is tap the output TIA audio output pins (12 & 13) and put them through a high quality amplifier / filter. This will also expose some "stereo" effects in some games.

Two controllers work fine. My son and I played some 2 player Joust and Super Mario Kart (slow). As for it being underpowered, it really depends upon your expectations. Will it play a lot of games from the 8 & 16 bit generations - YES. Will it play every game perfectly - NO. Also, while Lakka tries to be easy to use, there are areas where it's not there yet. So expect to have to do some forum/doc/Google research and stuff from the command line.

I now have MAME (2003 - 0.78) up and running, woot! I've loaded up "the best of" from pre-1986, now I need to figure out how to set the controls beyond the defaults. This also means I can play the originals rather than the console ports. I'm also working on getting Colecovision running. I've created a script which creates a playlist from a directory of zip'd ROMs, as Lakka doesn't seem to auto recognize them. Unfortunately, the CV emulator is also the MSX emulator, so I need to figure out how to put it into CV mode while not impacting the MSX ROMS. Hopefully I can use symbolic links to create a separate configuration. I've also discovered some additional ROM collections on the MAME DVD sets I have from back in the day. Lakka also includes a bunch of emulators which I haven't tried out yet, including SCUMM VM for playing various point & click adventure games. I wonder if I have Leisure Suit Larry on my historical backup drive.

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.