New Zealand Vintage Computer Forums

Afternoon all.

I stumbled upon these forums recently during my recent nostalgia binge, during which I picked up an original Apple ][ Europlus, which was the second computer I ever used (the first one being a TRS-80 Model 1). I remember being fascinated by this thing back in the early 80s during my few months of exposure to it.

This Apple ][ works, though as you can imagine it hasn't lived through 34 years without some injury. Because it didn't come with a Disk ][ expansion card (even though it came with a Disk ][ drive!), I decided to hook up the cassette ports to another computer to record and playback memory dumps so I can save any work I do on it. Thanks to the large complement of books that came with this thing (including Apple's own amazing Apple ][ Reference Manual which has schematics and ROM listings and detailed descriptions of the hardware), I quickly came to terms with how to use the tape dumping commands from the built-in monitor.

I managed to get recordings of the Apple ][ outputting its screech onto the computer, but I couldn't get the Apple ][ to recognise the played-back recording as valid data. I spent a good few hours experimenting with different volumes, and processing the sound to try and get it to work but to no avail. After reading some things online about how this hasn't been a problem for others I started to suspect a hardware issue.

I wrote a small machine code program (a pity they got rid of the assembler in the Pluses, because typing in instructions one byte at a time is not very fast) to output the signals the Apple ][ is detecting on its cassette port. It was definitely detecting pulses. But after reading up more on how the cassette interface worked I realised it was detecting the pulses badly.

Let me explain...

From a technical perspective, the Apple ][ writes out square waves to tape. Every time you access the write-bit it flips the output between phases, so writing it twice with a suitable delay gives you a square wave. A 1 is written as a 1000Hz square wave, and a 0 as a 2000Hz square wave. To read data the hardware detects phase transitions. There's a 741-based op-amp circuit that detects when the phase changes from positive to negative, or vice versa and sets a bit that can be read by the processor. You wait for two phase changes and based on how long it took you have a 1 or a 0.

That's all well and good. But by sending some square waves built up in Audacity to the Apple ][ it seems that every time the phase changes the read-bit would flip several times. The monitor code has no instructions for compensating for this, so it seems like this should not normally happen and that the op-amp is very good at detecting the phase transition only once.

So I've established that there's something not right with the cassette input hardware. I've tried modifying the monitor ROM code to compensate for these multiple flips, but wasn't successful. I suspect this will be a problem that won't get fixed, but I figure I'd throw this out there in case it's an easy fix and someone has an idea what would cause this - I'm hopeless with electronics so have no clue. At the end of the day it's no biggie, as I have a couple of Disk ][ interfaces on the way and I have a project in mind using a Raspberry Pi (also on it's way) to interface with the disk controller to simulate the disk hardware (I know of the CFFA3000, btb, but it seems there's a large wait for that, and I'm curious if I can pull it off doing it this way), but it seems a shame to have a broken cassette interface if it can be fixed.

This is the schematic for the cassette in hardware if it helps:



Anyone got any ideas what would cause the multiple phase crossing detection?

The only other hardware issues I encountered was bad RAM. Running a simple machine code memory tester highlighted there was a bad bit 3 in the second RAM bank, and a bad bit 0 in the third RAM bank (the first bank being fine was why the computer was usable). Looking on the board I discovered the reason for the bad bit on bank 3 immediately: a missing 16K x 1 DRAM. D'oh! The bad DRAM chip in the second bank I pulled out and cleaned but it was still faulty, so I've put it aside. I swapped some other chips from the third bank into the second bank and the bit 0 slot on the third bank to make sure the sockets worked and that was all good. I noticed there's some places in the States that still sell these chips but I've got a working bank 1 and 2 now, so not urgent. I guess I'm lucky this Apple ][ has only minor problems.

If you've made it thus far, thanks for your time. I have a few other computers (mostly all bought brand new over the years and kept), so I've got plenty of fuel for nostalgia!

Good stuff and welcome to the forums. Given what you've written the statement "I'm hopeless with electronics so have no clue" doesn't quite ring true though

I'm not sure what might be causing the tape issue, but I do know Apple cassette interfaces were very touchy when it comes to volume.

If you have got a disk drive already have you thought of simply trying to get hold of an Disk II card? They are quite common.

Thanks for the welcome. You got through that post which is something; didn't realise I'd written so much.

I've tried square waves at all sorts of volumes and every time the interface would toggle 4-5 times for every phase transition, which just isn't right. Never mind. I have a couple of Disk II cards on the way. I want to be able to store data on my PC and be able to send it back to the Apple II which the disk II interface won't fix without some extra hardware. The cassette interface would've been the easy way.

I am hopeless with electronics. I couldn't tell you what those resistors and capacitors do in that circuit diagram, or how the 741 detects phase crossings - though I understand it's an analogue comparator, so I guess it just compares the input voltage against zero. How the hell it does that is all black magic to me. Personally I think there's a little dude in there that sticks his tongue against the input and flips a switch when he gets shocked. He might have got old and gone senile.

Well I made an attempt to work this circuit out for myself. Thanks to a very handy little online circuit simulator (http://www.falstad.com/circuit/) I came to realise that all this talk by electronic techy types of it being a zero-crossing detector that toggles a bit when it detects a voltage switch, is actually way over complicating what this thing does. All it does is convert all positive values to +5V and all negative values to -5V. In other words it converts variable input into a steady 5V (logic 1) or -5V (logic 0) depending on the input phase. Or, in even simpler terms, it's a filter.

What's happening with my Apple II is it's oscillating when it changes phase. These op-amps shouldn't do that. So I think it's just an old chip that's getting a bit sad. I'll try replacing the chip and see if it makes a difference.

At this stage I'm just documenting my diagnostic steps for my own edification; feel free to ignore.

This sounds a fascinating discussion that I don't have time to fully pull apart right now, but I will pose this question. How are you seeing the multiple bit flip? Software? Or checking the circuit itself with a logic probe. The reason I suggest this is that it's not impossible for the culprit to be your PC.

If it's software only, it's worth checking your PC's soundcard to see what it's actually putting out. PC sound chips are not exactly precision devices and even less so now. If your PC sound module is a bit off and is putting out a DC bias, it might play silly beggars detecting that...Just a thought.

Hey there Gibsaw.

It's a point that I haven't ruled out the PC side of things. I do have a cassette deck on my old stereo so I guess I could always go retro to check it. Finding a cassette tape could be a problem though.

However, the Apple only cares when the bit flips indicating when the phase switches from positive to negative or vice versa, so I would expect the only thing to affect that would be oscillation from either the PC or the Apple's op-amp circuit. The PC may be doing that, but I tried through both an iMac and a PC laptop and both exhibited the oscillation.

I am checking the bit flip in software. I'm not fancy enough for logic probes. Possibly an oscilloscope would be better as we're talking analog signals, but I don't have one of those either, so software it is.

It would depend on the amount of DC bias. If it had enough, then the Apple II wouldn't be detecting the main zero crossings. Its would be detecting one peak of the (electrically skewed and probably not very square) waves as wobbly multiple crossings.

Yeah, an oscilloscope would be helpful. Then a logic probe.

Sadly I possess neither at the moment, but you would probably nail this down fairly quickly with someone else who is close to you. Where are you?

I didn't manage to resolve this issue in the end as the hardware for my disk-emulator experiment all turned up and so the incentive to fix the cassette interface has disappeared. So I thought I'd document my experiments with the disk stuff in case it interests anyone...

The goal is to emulate the physical floppy disk mechanism using a Raspberry Pi. To do this I plugged the Raspi's GPIO ports into the Disk II controller where the floppy drive ribbon cable would normally go, via a 3.3V <-> 5V level shifter.

I successfully read the controller's motor phasing (four pins that cycle in a forward or reverse direction depending on which direction the disk head should move), and the drive select outputs. But getting data to serialise into the controller's read input has been an exercise in frustration. I got reading mostly working by using the Raspi's SPI interface as a serialiser, but no matter what timing I used there would always be errors, enough that there is no way the Apple II can read a track correctly. Lots of time spent playing with various things just wouldn't produce a reliable stream.

Tests show it wasn't due to multitasking on the Raspi's Linux OS; the SPI interface uses a 16-word FIFO buffer which I was successful at keeping filled with data mostly, and the few times it bottomed out did not match up to the drop-outs on the Apple. However, I've started focussing on another area that I have been ignoring up to now as not important for the serialising, but may actually be having an effect after all.

The motor phasing and drive select inputs are fine normally, but when I sent bits to the read pin of the controller these inputs start randomly fluctuating. I figured I'd worry about that later, as I thought it could be a programming error. But thinking about it more - and testing with another controller - it seems to be more like a voltage issue. Cycling the controller's sequencer is somehow causing the logic levels being detected by the Raspi to be unreliable. And if it's affecting these pins randomly it's possible it's affecting the read pin randomly too.

That's where I've got up to so far. Next is to test that theory by seeing what logic levels I'm getting when the controller is going hard out. Not sure how I can fix that though; there's only the one chip between the Raspi and the Apple's controller, so I wouldn't have thought it would cause that much of a voltage drop.

Worst comes to worst, and I can't get it working I can plug the Raspi into the cassette interface circuitry so at least I can load/save data on the Apple. Going from the disk's 250KBps to the cassette's 1.5KBps should be easier, but will be painfully slow though!

For those of you at home watching this unfolding saga...

I finally got my disk emulator working. I just successfully booted a DOS 3.3 disk stored on a Raspberry Pi plugged into an Apple II's disk controller card. That was definitely a grin from ear-to-ear moment!

For the technically inclined, I was indeed on the right track using the Pi's SPI pins. The problem was I forgot that the SPI is clocked (which I ignore) and there was no way for the Apple to know when each bit stopped and started. So I figured that for every bit I send down the SPI output, I needed to send another three zero bits. This corresponds with the Apple's one microsecond pulses followed by three microseconds of silence. I'd tried this trick before to no avail, but this was under Linux which had other issues preventing it from working, and then I forgot about it when I moved OSes.

It turns out this was the right call, and once that was done, the Apple started reading disks and running programs perfectly! (Well, apart from a brief issue where I discovered I was using a DOS 3.2 formatted disk on a DOS 3.3 controller card - I'd assumed the card was old enough to be a 3.2 controller.)

So, in summary:

• The disk emulator runs under RISC OS, due to it being a single-tasking OS. Linux just does too much in the background to make it usable.
  
  
• Disk data is sent to the Apple using the Serial Peripheral Interface clocked at approximately 1 MHz, connected directly to the controller.
  
  
• The virtual disk head is moved by reading the Apple's disk motor phase pins connected through a level-shifter to the Pi's GPIO pins.
  
  
• The emulator is written in ARM assembly for speed, and hits the Pi's hardware registers directly (again, for speed).

So I'm feeling pretty good about my first hardware project (though Electronics is still largely a mystery to me). The next step: writing to disk. Yikes!

Mein Gott!! you're keen!! That's a good effort.

Surprised at the OS switch though... I would have thought it was possible to cut down Linux to almost a single task?

Well done. Impressive!

Gibsaw wrote:Mein Gott!! you're keen!! That's a good effort.

Surprised at the OS switch though... I would have thought it was possible to cut down Linux to almost a single task?

Thanks.

The problem with Linux - and any modern OS - is even when there's nothing running there's always something running. A lot of essential processes that keep the OS ticking along need to be run regularly. I guess I could've pared down Linux to the point that it wouldn't interfere with the loading of the serial FIFOs, but it was just easier installing RISC OS. It's not a bad little OS once you get used to its way of doing things.

Mind you, if I could implement this disk emulator as a driver under Linux that would be even better. But that might be just a little too ambitious for this project.