A small Apple I emulator (was: Another 6502 emulator...)

[kc5tja]

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.

[happycube]

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...)

[GARTHWILSON]

Quote:

(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..

[kc5tja]

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.

[kc5tja]

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.

[GARTHWILSON]

Quote:

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.

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 )

[BigEd]

kc5tja wrote:

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.

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:

6502.org wrote:

Image no longer available: http://img193.imageshack.us/img193/3844/apple1video.th.png

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

[kc5tja]

GARTHWILSON wrote:

Quote:

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.

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 )

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.

[Arlet]

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.

[kc5tja]

BigEd wrote:

Looks like the shift registers are 1k long

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

[kc5tja]

Arlet wrote:

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.

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.

[BigEd]

kc5tja wrote:

BigEd wrote:

Looks like the shift registers are 1k long

I find this a bit unbelievable; the Signetics data sheet for the recirculating shift register indicates it's shift registers are only 40 bits wide.

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

Have a look instead at the datasheet for the 2504

Quote:

These Signetics 2500 Series 1024-bit multiplexed dynamic shift registers consist of enhancement mode P-channel MOS devices integrated on a single monolithic

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)

[Arlet]

Quote:

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.

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

[jesari]

happycube wrote:

I've been working on a logic-based emulator - with gcc -Os it compiles into less than 4K (not counting 'shell'), which means it'll be a good choice for running on an AVR or ARM Corrtex. In theory one could make a one-chip Apple I with this on a very cheap LPC 111x.

EDIT: I haven't commented it enough yet to make sense, but it's now an Apple I emulator and can run at least basic BASIC programs. The stripped -Os i386 a.out (including basic and woz mon) is ~14K.

Check it out here: http://code.google.com/p/chadslab/sourc ... nk%2Fm6502 (2-clause BSD licensed)

What I really want to do is make a tight Verilog version and see if I can make something smaller than even Arlet's core (EDIT: I doubt I can make one that's worth the effort, but I might look into optimizing Arlet's...)

While checking the emulator I found the following BASIC error:

Code: Select all

E000R

E000: 4C
>10 FOR I=0 TO 100
10 FOR I=0 TO 100
>20 PRINT I
20 PRINT I
>30 NEXT I
30 NEXT I
>LIST
LIST
   10 FOR I=0 TO 100
   20 PRINT I
   30 NEXT I

>RUN
RUN
0
*** >32767 ERR
STOPPED AT 30

>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 )

[happycube]

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...