Perhaps the NMI handler, upon detecting a '1' for the B bit, can take steps to invoke the BRK handler after it's done with its NMI duties, knowing definitively that a BRK has occurred as well.

Debugged mine a bit more and it's now a basic and small Apple I emulator. Thanks for the help with debugging the interrupt flag!

The next trick is to get it running on an LPC1343 board... [Apple] 1-chip anybody? (initially USB serial, and then when I have access to my TV again I'll wire up an NTSC interface - with SPI it shouldn't eat up too much CPU even...)

happycube, since you're new (and BTW, welcome!), let me point you to the external peripheral bus we at 6502.org have devised to extend the usefulness of SPI (and similar interfaces) and to make it easier to share designs and perhaps even hardware in the future. We call it 65SIB, for 6502.org Serial Interface Bus. You'll find the current spec here. Nothing about it requires 6502-related hardware-- the "65" just credits this forum and website. The linked post is the result of 8 pages of development discussion, and it summarizes the design goals, benefits, connectors, pinouts, auto-addressing, optional intelligence and autoconfiguration, etc..

I think he means to use SPI as the video interface, where MOSI is used (through a resistor network) to drive the NTSC analog signal.

What I don't understand is how the Apple I's video output worked. From what I can see, they used a 40-bit by 6 recirculating shift register to house one line of text on the screen. This means that the CPU would have to reload the shift register every 8 scan-lines to get a full 40x25 display. Yet, no interrupts for the purposes of synchronization exist (per the Replica 1 details, at least), and as far as I can see, the sole interface to the display hardware is a 7-bit parallel port.

What am I missing? I just don't see how it's possible without racing the electron beam.

Anything like using the VIA's SR, shifting out free-running at the T2 rate and following it with an RC for a 9-level D/A converter (slightly better than 3-bit resolution)? (Tip of the Day, #5, at viewtopic.php?t=342 )

Looks like the shift registers are 1k long (and 1 bit wide, but there are seven of them) - the whole screen of text fits in them (as characters not as pixels.) For writing into the shift registers, best to consult San Bergmans' page about the video circuit operation.

Here's the circuit, found on page 10 (or a supplementary page) in the apple 1 manual:

RD1 to RD7 are inputs, from the B port of the PIA. The 8th bit of the B port is an input, connected to DA, which is the inverse of the PIA's CB2, used to ensure a written character has been accepted into the shift register before the next one is presented. Component D2 is the character generation ROM, with 6 bits of address input, either from 6 of the 2504 shift registers or from the B port.

I haven't yet digested this!

Cheers
Ed

If you want 1/9th the horizontal resolution, sure. If all you care about is monochrome, then you can just use a voltage divider to bring +Vcc down to 0.7V at a 75-ohm impedance, and that'll drive a VGA monitor or NTSC input fine.

The easiest way to digest the video circuitry may be to instantiate all the components in a HDL, and run it on a simulator.

Plus, you can then put it in an FPGA and try it out.

I thought the 2519 was the recirculating shift register used. I wasn't even aware the 2504 chips were the main frame buffer.

See http://www.applefritter.com/node/8752

This assumes you know what all the components actually do. I was completely unaware that the 2504 was a 1024-bit shift register, which was my missing piece of the puzzle.

Have a look instead at the datasheet for the 2504


Edit: Ah, Samuel saw his mistake and already corrected his post. For my part, I'd missed that the 2519 is also a shift register. The 40-bit depth is presumably a line of characters (character addresses for the character generator ROM)

Correct. The old datasheets may be hard to find.

ETA: There's a .zip file with the datasheets of the 2504, 2513 and 2519 on the sb-projects download link: http://www.sbprojects.com/projects/apple1/download.htm

While checking the emulator I found the following BASIC error:

>32767 ERR means a BASIC overflow. Probably something is wrong with emulation (maybe V flag...). It seems to happen with every NEXT instruction.
BTW, the emulator was cross-compiled for ARM and ran on an x86 Linux box using qemu-arm (today we got so many MIPS to waste )

Fixed it (I think - it's hard to figure out how to handle V ) - the for/next loop runs now.

And yeah - we've got such an amazing amount of CPU power these days...