AVR Based Apple II Emulator

[cbscpe]

Hi,

many of my last projects were AVR based projects. But I like the 6502 processors very much, and previously many projects where 6502 based. I still have plenty of old 6502 chips even A and B versions. Later I mixed AVR and 6502 processors, for example one of the projects was a PS/2 keyboard interface for may Apple IIplus using a ATMega8 chip. But then I stepped over the AVR Based 6502 Emulator of Daryl. I was really impressed, especially because in another forum I regularly visited long ago I was once reading a thread in which many people were convinced that an AVR was not fast enough to emulate a reasonably fast 6502. Although the AVR in Daryls project is (moderately) over-clocked it had more than enough speed (>2MHz 6502). And there is also the 6502 Emulator of Klaus with the external RAM, so you can have more than is available in a AVR processor. (Read those threads as well, there is much information in them that let you better understand what I did).

So I thought that it must be possible to Emulate an Apple IIplus on a AVR using external RAM, and that's what I did. I took an ATMega1284P with a 128kbyte SRAM and a 8-bit Latch so I had a AVR with enough external RAM. Schematic is included in the archive (as Eagle-File and as PDF) I took the same processor as Daryl in order to be able to use his project as a starting point and to incrementally modify his project into an Apple IIplus emulator. I have no web-page so I just make my project available on Dropbox

https://dl.dropboxusercontent.com/u/320 ... ppleii.zip

The emulator runs first the bootloader code of Daryl, so you could overwrite the "6502 ROM" Image with your own, don't do that for the moment, it's not adjusted to my emulator. Just press return to jump right into the Apple II Emulator. The current status implements a redirection of video output (COUT) to the UART. So you will not see the "Apple ][" Message, as the autostart ROM writes directly to the Text RAM but all further input and output are received/sent via the AVR UART0 (the emulator contains an emulation of KBD input that links the the RX side of the UART0). So you can start to play around with the ""Apple II""

It's working but not finished yet, as I want to add several functions. Especially Video and Disk (using SD-Cards) is on the agenda.


Regards

Peter

[cbscpe]

Just updated the code, especially changed the 6502 IO Routine for Video and Keyboard. With UART0 connected to a VT100 (Emulator) it implements now all AppleII Output and Input Features except for Windows other than the full screen. The zip file now also contains the complete ROM include file.

Regards

Peter

[fachat]

Nice. Why don't you put the code on a public code repository?

[cbscpe]

Hi Andre,

I probably will as soon I have decided where and how. Before I will do so I first would like to finish some steps of the projects which are important to make the whole think really usable. Most important the bootloader needs a re-write, the C8-ROM Protocol needs to be implemented and an SD-Card interface so I can really exchange code and diskimages.

[stians]

Looks like we had the same idea, even about the same time.
http://jmp.no/blog/apple-iie-on-avr-with-video

I started with porting my 6502 emulator to the ATmega128, which worked fine. I pushed it a little further and tried to emulate the video simultaneously, but that was a bit too much. Emulating the video takes 80%+ of the processing power, leaving very little left for the Apple IIe emulation.

[cbscpe]

Hi stians,

very nice. I still have not decided on how do the Apple Video. At the moment I have just a serial interface that covers pretty much normal 40-col Text. Doing VGA signal creation on the same AVR is definitively affecting performance too much. I thought about throwing in a IDT7007 and creating the VGA signal on a dedicated AVR or have the AVR running the emulator send all Video write's via a serial (SPI, UART) interface to a second AVR (I found many projects of VGA terminals built with an AVR). Currently I'm finishing the Apple IIe Emulation, especially the softswitches for RAM and ROM mapping, that's my first priority. I have now the logic to create A16 of the 128kb RAM built with standard 74xxx instead of the GAL I planned to program first. In parallel I'm migrating the IDE interface code from an Apple IDE Card to the SPI interface attached to a SD-Card as I want to boot PRODOS.

[stians]

Actually, I was thinking of creating another version featuring a real 6502 with RAM and ROM, and a separate AVR doing nothing but video signals on the side. This can be done using dual-port RAM for the video chunks of the memory, allowing the AVR do its magic without worrying about the computer's buses.

I'm sorry for drifting off-topic here, and this is your thread, so I'll crawl back into my cave and experiment some more.

[VGEORGIEV]

Hi guys,

I am new here.
Just did AVR Atmega328 emulation of 6502.
I used SPI SRAM and EEPROM.
ATmega is running on 8MHz internal RC clock.

I guess this PC can be faster if I use parallel RAM/ROM.
Please, check below:
https://www.youtube.com/watch?v=z6S-nF0onO0

[Dr Jefyll]

Welcome, Vladimir!

Nice sine wave! Is that MS Basic you have running there? And I see you also have some other projects demonstrated on YouTube -- such as this automotive ECU reader. Pretty cool stuff!

Quote:

I guess this PC can be faster if I use parallel RAM/ROM.

True enough. But the serial parts use much simpler wiring, and that usually means fewer problems getting things working.

BTW, did you know your photos can be hosted with your post right here on 6502.org? You may find that more convenient (and more permanent) than using Imageshack.

cheers,
Jeff

[cbscpe]

Hi Vladimir,

indeed using serial memory makes the solution small and simple and with the least possible wiring as well. I like that approach. A really minimalistic SBC, good job.

However I think Jeff is overestimating the effort to put parallel RAM. A 8-bit Latch and a normal SRAM is all you need. It's just more wires and it does not matter which address pin on the AVR is put to which address pin on the SRAM. The data pins as well don't need to be wired in the order if PIN names. The RAM does not care. Of course you need more Pins and hence a larger ATMega in a 40-PDIP. There you have the choice of using a ATMega with external RAM interface. When you let the AVR run at the internal 8MHz clock, access time is not an issue. A latch with tpd=25ns or less and a RAM with tacc=100ns or less is all you need. Or you do as I did, you build your own parallel interface logic using the same 8-bit Latch and SRAM. And as an ATMega1284p has more than enough flash you can put the 6502 ROM in flash. This runs faster of course. The Basic program runs in less than a second for one full sine-wave. Here is my current setup. Even using the worst wiring technique for a SBC it runs flawless and it worked out-of-the box, i.e. I never had to debug the hardware setup.

What you see here is already the enhanced version with the external generation of A16 for the memory mapping to emulate Main/Aux RAM of an Apple IIe. Which are the two top IC (74HCT574 and 74HCT251). One serial interface is the Character IO to the "6502" and the other serial interface is TX-only for debugging purposes. Down right is the SD-Card interface I'm currently working on.

Peter

[VGEORGIEV]

Hi guys,

Thanks for positive feedback.
I got this Basic from here.
It states it is EhBasic 2.2. Not sure it is MS basic.
The reason I got this is because it is easy to deal with input and output.

Quote:

When it wants to write a character to the console, it writes the byte to memory location $F001.....
It keeps reading from memory location $F004, where you should have the next ASCII character value from the keyboard waiting to be read. If there is no more input to read, it should return a value of zero.

Yesterday I put first two pages in AVR RAM. In fact I did some kind of cache memory.
This change increased the speed by 33%.
Later I will put XTAL on AVR in order to run it at 16MHz.

My next project will be almost the same but using ATmega32 or ATmega1284.
I need 40 ping DIP AVR in order to have 3 ports available for address and data busses.

I did keyboard and video interface for my 6502 emulator.
This is a web link where I got all the information I need. http://searle.hostei.com/grant/MonitorK ... index.html

BTW. I tried to run real 6502 SBC on a proto board. No success as of now.
May be due to the spaghetti wiring I did.

[Dr Jefyll]

VGEORGIEV wrote:

It states it is EhBasic 2.2. Not sure it is MS basic.

EhBasic is the work of our own Lee Davidson. You'll find an entire 6502.org section devoted to EhBasic here.

Re. MS, you may be interested in this article on Pagetable: Create your own Version of Microsoft BASIC for 6502.

Quote:

I tried to run real 6502 SBC on a proto board. No success as of now. May be due to the spaghetti wiring I did.

Is that the project shown in the 2nd and 3rd photos? To me, that wiring looks perfectly workable.

BTW, I'm intrigued with the approach of running ribbon cable on the component side as a means to implement a bunch of parallel connections. That hugely reduces the number of criss-crossed connections on the wiring side, making things a lot tidier than they'd be otherwise.

But there are problems, you say? I wonder if there might be some adjacent pads accidentally bridged together with solder. That would be an easy mistake to make, given the large, square pads on that board. (There'd be less risk of an undetected solder bridge with round pads that were a bit smaller.)

Other questions: are you using bypass capacitors on the supply and near the chips? I don't see any. Also, how long do those ribbon cables extend? Is there something else connected, not visible in the photo?

-- Jeff

[cbscpe]

Indeed the ribbon cable solution was also very appealing to me as well. I like that approach. On the other hand you need to be careful which signals you put on the same ribbon cable. Never put the clock or select signals side by side to the Data or Address bus. I really wonder what the problem is that this system is not working. Perhaps you need to shorten the ribbon cables on the bottom edge on the last photo, it's only a guess as you can't see the real length on the photographs.

[Dr Jefyll]

Quote:

you need to be careful which signals you put on the same ribbon cable

Be careful, I agree, since there's a risk of crosstalk. But if the conductors of the ribbon also include some grounds, the situation changes. The ribbon technique has potential to work in your favor, actually improving signal integrity.

• There'll be minimal crosstalk between two signals lines if a ground line lies between them. That's because (among other reasons) the ground line acts as a shield against capacitive coupling.
• For a less obvious effect, consider a two-conductor ribbon with just one signal and one ground. Crosstalk isn't an issue. But the nearby ground line lowers the inductance of the signal line, and thus tends to improve signal integrity. It's like the ground plane you'll find on an expertly-designed PCB. It works because the return current from the signal conductor "wants" to travel through a path that's close to the conductor. Catering to this reduces the loop area. But remember: you can't just use just a single connection to ground, and also not to just any old place on the board. The reason is simple. Since current is expected to flow, a single connection is insufficient. The ribbon ground needs to connect to local ground of the circuitry at the signal source and at the signal destination(s).

On a board like Vladimir's, we maybe don't need to worry about this stuff. But as a general topic it's worthwhile to talk about!

-- Jeff

[BigDumbDinosaur]

Dr Jefyll wrote:

• There'll be minimal crosstalk between two signals lines if a ground line lies between them. That's because (among other reasons) the ground line acts as a shield against capacitive coupling.

This is how a SCSI cable is arranged. The SASI specification from which SCSI (the 1986 standard) arose used a 50 conductor ribbon cable with a nominal characteristic impedance of 100 ohms and developed a synchronous transfer rate of 5 MB per second. Each signal lead is "surrounded" by two ground leads, and Thévenin termination is employed at both ends to suppress reflections. A total of eighteen signals are present: nine data signals (including parity) and nine control lines, and up to 48ma of bus drive is used. The standard permits the cable to be as much as three meters in length, which is something to consider, given the high data transfer rates that are possible. The 1990 revision to SCSI increased the maximum synchronous transfer rate to 10 MB/second with no changes to the cable's or bus drivers' electrical characteristics, other than recommending the use of active termination instead of Thévenin termination.

The 1994 SCSI-2 revision increased the maximum bus speed to 20 MB/second on the eight bit ("narrow") bus or 40 MB/second on the 16 bit ("wide") bus, which was accomplished by tightening some of the timing requirements, but with no change to cable length. Incidentally, the hardware I built for implementing SCSI on my POC V1.1 unit can support the 1994 narrow bus standard, but is impractical due to the 65C816's inability to keep up with the bus speed.

The development of double transition clocking c. 1997 boosted the wide bus speed to 80 MB/second, but also required the use of a twisted pair cable operating in low voltage differential mode to assure signal integrity over a long cable (maximum length of 25 meters if only two devices are connected, three meters otherwise).

So it is possible to use ribbon cable as a board-level high speed bus, provided one follows Jeff's suggestion about interspersing ground leads with the signals. Termination is also a good idea. See also this article by Fairchild.