Hi guys. First, hope ya'll don't mind my large amount of topics but well.. anyway, if you don't know by now, I am working on designing a "simple" processor which is a bit of a ramped up version of the 6502. So, as a bit of background, if any of you play minecraft and play with mods, you may have heard of a mod called RedPower2. This mod added its own custom processor called the 65EL02 which is a 6502 and a few other processors together. In the code for the emulator, there is a fairly simple system for the processor to communicate with hardware devices. In my emulator I could easily create something like this however as far as hardware goes I am a bit clueless. My main question is how would I go about implementing some sort of hardware communication system? Like I said, I could EASILY create a system in the emulator but as far as the hardware (real hardware not virtual) goes, I'm not sure at all...

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Garth's summary is useful, but not sure if it's helpful to you.

The 6502 family (among others) uses Memory Mapped I/O. That is, is treats I/O just like it does memory. If you want to determine the values of something (like switches), you read a byte. If you want to change the values (like LEDs), you write a byte.

In contrast, the Intel family of processor historically have specialized IN and OUT instructions, and control pins on the CPU to drive I/O devices.

So, on a 6502, if you wanted to read the value of a serial port, you'd just do something like LDA $1234, where $1234 is the address of the serial port. On an Intel device, you would do something like IN $12, which would read device mapped to $12.

The chips that Garth was referencing are the devices that turn those "memory" references in to real work. For assorted reasons, you don't want to just hang I/O things (like switches and LEDs) straight on the address and data bus, so there are other chips that make that much easier and simpler.

As far as implementing I/O in a simulator, it's quite simple. You have code in your low level memory read and write routines and then handle the I/O. You can do this simply, on my simulator, I have a byte mapped for reading the keyboard and one for displaying a character on the terminal. When the simulator does a STA $C001, my memory write routine checks for the special address and simply calls the internal "display character" routine, that handles the screen address, scrolling, etc.

Normally, a memory write is simply setting an array value: memory[address] = value. When the special address is encountered, it calls the appropriate routine. A downside of my technique is that from a clock time perspective, writes to the character output byte take "longer". The CPU increments the correct number of cycles, but actual, wall clock time, is much longer than setting an array value, it does a lot more actual work in the simulator.

This is fine for my purposes, I don't have strict timing, but you can see that if you did, you'd have to compensate for that somehow.

I also have Disk I/O in the same way. Put the start address in two special bytes of memory, set the disk block number in two other bytes (65536 total blocks), and then store a 1 or a 2 in to the control byte, and, magically a 512 byte block of memory is written to disk, or read from it. Super simple.

Here's the fragment from my Forth:

The CHAR_READY byte is set to 1 if there is an unread key, then CHAR_IN is called to read the key.

Here's the Forth using the Disk I/O

This was nice because my simulator does all the heavy lifting, stuffing numbers in to memory was easy to do in high level Forth.

Why did I pick this scheme for Disk I/O? Seemed like the thing to do at the time, it's not based on anything. Why did I map my I/O at $C000? Same reason.

Now you can make your simulator more accurate, do interrupt processing for I/O, etc. I haven't. My needs haven't been that strict. But you can certainly go there.

So now I need to try to understand how the mapping works... In my simulator, I have an (java stuff ahead) interface called IRAM which has ramRead, ramWrite and reset in it, this is the memory i use inside the processor, is this also where i would do the peripheral interface? If so then it shouldn't be named IRAM any more but more like IBus or something like that right?

And by the way, thanks for the responses, very informative!

On mine, I have a very simple interface:

Then I have a couple of implementations, one of which is TermMemory. Here is it's fetchByte routine:

Any time I want to make new memory mapped I/O, I can simply implement my Memory interface and plug something else in.

Okay, thats similar to mine I suppose. I think I got it... btw is your simulator OS? If so, gimme XD for reference.. also I am interested in playing with it. But I still have the question (which may be stupid of me at this point) of how you actually map the device to the processor.. how you tell the processor how to talk to the device.. The way it was done in the 65EL02 is basically each device has an ID and it used a MMU to map the id to the actual device and send commands to it.. is this a realistic way to implement it? If so i'll just do it that way..

On a typical 6502 system all devices, the processor is talking directly to, are memory mapped. All devices like the 6522 VIA or 651 ACIA or even a simple 74HC573 latch chip have at least one "chip-select" line that is responsible for activating the chip if the correct address is set to the address bus. Because this means, that the data on the databus is for exactly this device. What you need is some kind of address-decoding that generates the chip-select signal for your several support-chips.
Once you have a chip on the data- and address-bus you can use it to communicate to other hardware "indirectly" by using f.i a VIA I/O to drive a LCD Display.

One example: I'm playing currently with are 74HC574 octal D-flipflop chips. They can be easily used as input and output device for 8 I/O lines.
These chips have 8 input-lines that I connected directly to the data bus. The 8 output-lines are driving 8 LEDs for a visual effect. The 74HC574 has also a /OE line, which is called "Output Enable". The "/" before the name is important, because it tells you that this line is "low" active. This means if the line is pulled down to GND the chip is active, otherwise not. The chip has also a "LE" Input (Latch enable) that is high-active. If this input gets an LOW-to-HIGH change it takes the data from the 8 input lines and present it on the output lines (permanently as long as the /OE line is LOW).
To talk to my 74HC574 as device on the bus I use my address-decoding logic that generates the "LOW-HIGH-LOW" pulse for the LE input of my device, whenever the address $a000 is set to the address-bus.
So my 65C02 does not now about this special device, it only writes a byte to the specific address $a000 and the bit-pattern of the bytes shoes up on the output lines of the 74HC574, because the chip is activated by the address $a000.
For all other memory mapped chips its the same. You generate a Chip-enable signal for the peripheral chip to activate it for specific addresses. Then the chip itself is responsible for reading or writing data to the databus.
This is really simple and clever, because you do not need special I/O commands to hook almost any device that supports "chip-enable" to your MPU.

For your emulator you can create a "base class" the provides that simple mechanism. It could "register" itself on your address-bus and whenever a byte is read or written to a specific address an instance of this device has registered to, you can delegate this read/write to this instance. This follows the hardware concept straight forward. From the base-class you can then derive any I/O device you'd like to implement.

Mario.

_________________
How should I know what I think, until I hear what I've said.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Okay, I think I understand now. My next question is about the addresses of devices... are the addresses hardcoded? If so, don't some devices overlap?

Typically, you arrange for devices to not overlap, although there are some schemes where devices are... "incompletely decoded" (meaning that the device "doesn't care" what some of the address lines are), but each have a preferred base address, and specific combinations of "don't care" address bits can be used to select multiple devices at once... Though you'd only want to do this for writing, not for reading. Bus contention isn't fun.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

To be honest, I think it is a lot simpler than it seems. For some reason though, it seems confusing to me. IDK why.. but like I said, I think i got it now.

Sorry to bump, but I just realized something. I was being a total idiot. Not really sure why it took me until just now as I am testing the first version of my emulator to realize that you can do something like this:



to (in my case atm) write an A to the terminal. I feel stupid.

STA #8800 is not a valid instruction. STA has no immediate mode operand.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?