Apple IIe Emulator Released For the Wii
fortapocalypse writes "Yohanes Nugroho just released WiiApple, an Apple IIe Emulator for Wii. While the sound doesn't work, some games are playable (he shows a screenshot of Epyx Winter Games as well the execution of a program he wrote in BASIC). He's also released the source code. Using WiiApple requires the Homebrew Channel, which we have discussed in the past."
That's great! I wrote a Wii emulator on the Apple //e back in 1983. Now I can run that again!
The Linapple port of AppleWin that this thing is based on is great. For the longest time there was no good option for the AppleII on linux. xapple2 only ran in 8 bits, blech. kegs was ok, but I could never get it to run Ultima II. AppleWin ran in wine, but it didn't like to be full screened. Mess worked ok, but there was a bug when swapping disks. When Linapple came around it was really nice. It was not perfect, iirc it won't take a disk image as an argument, you have to boot it through the GUI. But that's a small quibble.
In the end I just got a real IIgs. That's always the best way to go. BTW, have you seen the prices on DSDD media these days? One 25 pack of 5.25" media cost me just about as much as my IIgs did. But that's ok Wasteland is awesome!
Give me Classic Slashdot or give me death!
Some games supported the add in Mockingboard which provided more sophisticated synthesis. Ultima III, IV, and V all supported the Mockingboard. The Linapple emulator does support the mockingboard, so it should be possible on this Wii port, if they can get the sound working at all.
Give me Classic Slashdot or give me death!
This is great... Now, all you have to do is install the preventive multitasking OS I had written at the time then try to bootstrap Minix from it, and you'll have the best of the 80s.
So many memories, so little time. How many people on /. even have fond memories of the Apple II? Just showing my age I guess. Anyone below 30 who even knows what it was like at the time? I ran my first BBS on an Apple II. Kind of like slashdot, minus the traffic :-)
I don't think so. I exchanged a few messages with hin in the past, and asked if he had tried any of the AppleII emulators, or had contributed his unique expertise to any of them. He said he thought they were neat, but didn't have the time to spend on looking at them or contributing. Too bad!
iWii
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Looks like the article has just been demoted to "Games". Seriously though, this is just the most recent in a long line of emulator ports to the Wii. The chaps banging Linux onto the Wii are doing a lot more interesting work.
Now I can play Oregon Trail the way it was MEANT to be played: by throwing my controller at deer as they run by.
(btw, if anyone knows where I can get a good deal on a new flat-panel TV, lemme know)
Read my blog.
I'm no fan of Apple (I prefer Commodore when it comes to the 8-bit era), but a stock Apple II can do more than just beeps and clicks - it can do full digital audio using pulse width modulation. I'm not sure of the effective resolution (more than 1 bit, for sure, probably closer to 6-8 bits), but I've heard at least a couple of examples of this, including a multi-voice music player, and it actually didn't sound half bad for an otherwise rudimentary output.
Well, the good news is, the Woz already found a way for you: http://atariwiki.strotmann.de/xwiki/bin/view/Code/6502Relocator
ftp.apple.asimov.net
*RUNS*
-uso.
What you hear in the ear, preach from the rooftop Matthew 10.27b
And depending on how those clicks were timed, the technique was probably pulse width modulation. It's simply the easiest way to turn a 1 bit output into something greater. At present, PWM is used commonly in CD players, motor speed controllers, and probably your PC's power supply. Hell, even a Commodore mouse uses it [1]. There's not much limit to the applications this method can be applied to. Higher drive current and/or voltage, a faster pulse rate, and finer pulse width granularity are usually better, but the fundamentals are the same pretty much anywhere a variable voltage is needed if everything is otherwise sane.
Since I don't know the intimate details of the Apple II beyond the presence of that flip flop output, I'll speak from a generic perspective, to expand on the comments made by the AC below.
Suppose you have a basic computer with a 1 MHz system clock and one or more generic I/O chips with ordinary TTL outputs, among its various other hardware.
In your code, configure a main interrupt to trigger at a fairly decent clip, let's say 25000 times a second. Each time it triggers, have it set up a second interrupt, force an I/O line high, and exit. That second interrupt should fire a short time after it is enabled, and it should do nothing but set the I/O line low and exit when triggered.
Call the second interrupt's time delay "D", as it represents the pulse's duty cycle. Structure the primary interrupt's code so that, when D is zero, the secondary interrupt code can chime in (that is, before the main interrupt can even exit) and force the I/O line to low right after the main interrupt sets it high.
On the hardware side, couple that I/O line through the usual R/C circuit and attach to a speaker. As the AC below already said, this is what was done in every Apple II, and this is what will do most of the work to turn that train of pulses into a smooth voltage. With your 10 MHz system clock, a 25 kHz pulse train gives you 40 cycles between the pulses' leading edges, so your average voltage output will be about (100*(D/40)) percent of that of the high rail.
Do something simple that makes D the same amount at all times, and you've got a configurable voltage output. Change D every so often to follow a digital sample and you've got a 25 kHz output with about 5.32193 bits of resolution.
Since there will be some timing variation and latency in the interrupts, the available resolution will be slightly lower that this theoretical maximum (probably 5 bits even). Because of the large amount of CPU time consumed by the interrupt routines, this method works best if the I/O line is something like a timed shift register port. Then you only need a single interrupt that reads a sample value, sets the I/O line's timer accordingly, writes to the serial register any value that has only one bit set, and then exits.
The fact that this all requires good assembly language skills on the 8-bitters does not change the fact that it *is* full digital audio - you need good skills regardless of the type of audio output hardware you're working with.
*[1] I 'scoped it once years ago and was surprised to find that the 1351 mouse uses PWM to generate the analog signals that are sensed as voltage levels by the POTX/POTY lines in the controller port.