Interfacing the Propeller with the Z80 + My first cart design

nick112147

··· In my system I am interested in interfacing the Prop with a ·Z80 for use as an audio controller. Using a cheap external audio controller will allow the Prop to focus on other more important things besides controlling audio. I like the Z80 for this job because the Z80 has been used over and over for over 25 years as an audio controller in home and arcade systems. It is a solid design and I want to use it in my own. The problem is, I am not sure how·to·interface it to the Prop. I·understand that the·Propeller doesnt need to·actually·understand the Z80 code,·but how·do·I get the·Z80 program data to the Z80.·I thought about using an·eZ80 microcontroller so I can have a serial interface·between the two, but I am unsure how to send the program data. Any information would be helpful because I will be using the same prinicples to transfer data to the second·Prop.·Would it be sending one byte·at a time? I learned alot about serial protocols from designing my cartridge with serial eeproms. Should I use the same protocol? Is there anything I should consider or·put into my design?

Anyway,·here is my cart design. It·can hold·a total of·4 Megabits, using·4· 1 megabit chips (I forgot to update the chip model names, it should be 24C1025, sorry). The·chip selection·uses the internal·2-to-4·decoder inside the actual eeprom.·Using a control byte (as described in the data-sheet) the·chip selection is confirmed and the memory·address is selected. Output is then sent to a dedicated serial channel. I thought about adding extra circuitry for a custom chip designed by the user. Something like a CPLDs, FPGAs·or an·SX programmed to do the job of a custom IC. I just want to get a basic design first. Here is a link to the·schematic image:

http://i73.photobucket.com/albums/i214/nick112147/GamePack.jpg

It is a large image so please be patient. Let me know of any errors (I am sure there are numerous).


Nick

Post Edited (nick112147) : 3/28/2008 1:20:53 AM GMT

LoopyByteloose

Much of this is up to you. It seems a bit too general at this stage to say how to impliment communications between the two. Is the Z80 going to independently produce sounds from a series of files or do you want the Propeller to decide parameters like pitch, attack, fade and duration. Obviously, these are two very different approaches that would decide much of the communications scheme between the two.

In the first instance, the Propeller would merely be telling the Z80 to jump to a memory area and produce sound from that data; in the second instance, parameters would have to be assimilated, compiled·and processed.· So a packet format would be useful.

Take a look at Andre' LaMothe's XGS Micro game system for sound synthesis in an actual context.· He has several books that can point you in the right direction.· Personally, I would use like two use a two Propeller system and have the sounds supported by an SDcard for a huge data bank. 32bits at 160MIPs is faster than the Z80 can ever get.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PLEASE CONSIDER the following:

Do you want a quickly operational black box solution or the knowledge included therein?······

···················· Tropically,····· G. Herzog [noparse][[/noparse]·黃鶴 ]·in Taiwan

Post Edited (Kramer) : 3/28/2008 6:21:27 PM GMT

nick112147

I will be using two Props, but one is for main program code and the other is going to handle graphical routines as a coprocessor. The method I am looking for is to point the Z80 to a location and it programs a PSG according to the program code. My problem is, how do you point another CPU using a totaly different instruction set to a location in memory? I talked to Andre' about it, and he said his books are too general for this kind of situation. I tried looking at open source Sega Genesis code, as that console uses a Z80 for sound operations, but the general distaste of begginers in the Genesis development community has left me trying to analyze uncommented M68K·assembley·code. Where I have the option to use SPIN, sending a command to the Z80 might not be as hard, but some general help from those here who have done this kind of thing would be greatly appriciated! Thank you,





Nick

Gadgetman

One way of doing this could be by using the Z80's interrupt modes...

One of the modes is very special...
When the Z80 receives an interrupt, it'll wait for the interrupting unti to leave a Byte of data on the Data-bus.
This Byte is combined with the 'interrupt register' and is used as a 16bit pointer.
(The I-register is used as the top 8bits of the address)
The 16bit value at the address is read and used as the destination of a CALL-type jump.

This means that you set aside a 256Byte segment of memory(pointed to by the I-register) and use the Byte from the interrupting device to decide which of up to 128 different routines is to be called.

Doing the interrupt should be easy enough by setting side a Propeller I/O-pin, and the Byte can be clocked out on a shift-register to save pins.

Another, simpler way could be to just use the shift-register and hook it up so that the Z80 can read it with an IN instruction.
(Read up on how Z80 does I/O first)
Of course, then you'd have to have the Z80 poll that shift-register periodically...

Of course, the easiest solution is to set aside another Propeller for the task instead of using a Z80...
Don't take me wrong, I LIKE the Z80, but I can't see the reason for mixing CPUs in your design.
And with the Z80 maxing out at 8MHz( if you get hold of the right chip) a Propeller will run circles around it.
The only real advantage the Z80 has is that it can easily run assembly-programs that are longer than a COG in a Propeller can.
(Not taking LMM into consideration. Then all bets are off)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...

LoopyByteloose

And one can actually adapt a Propeller to run .wav files from a lot of sources. So you can have your choice of a lot of existing audio special effects. Put them on an SDcard and have the dedicated audio Propeller select and play them.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PLEASE CONSIDER the following:

Do you want a quickly operational black box solution or the knowledge included therein?······

···················· Tropically,····· G. Herzog [noparse][[/noparse]·黃鶴 ]·in Taiwan

nick112147

So basicaly I interrupt the Z80, put a byte of data on the data bus, it combines it with the interrupt register and it will execute the instruction at the address·derived from combining the byte from the data bus and the interrupt register. This would be simple if I were using two parallel bus based processors.

Honestly, I think the Prop just isn't compatible with the Z80 enough for me to do this without a month of headaches. Andre' pointed out that programming an SX to act like a PSG is easy, yeilds exceptional results and has been done, plus it would be easier to interface with a Propeller.·I think that might be a good alternative.

One of the·main reasons I would use the Z80 is, to be perfectly honest, just to do it and learn·from the process of doing it. Using a huge capacity SD card with bulky wav format sounds isn't much of a challenge. Andre' uses this design as well, because his console is designed for beginners rather than an expert (I am not saying I am an expert). My aim is to give people, and myself, the same challange programmers and artists faced when·creating·the games for systems like the NES. To have to work with those kinds of constraints forces you to think about what you are doing.·Doing something and then actually finding a wall in your way, then finding a way to conquer or work around the wall, in my opinion, provides a greater learning experience. With·virtually·(a 1Gig SD card could never be filled unless it had thousands of HYDRA games) unlimited space, there is room for sloppy and bulky code, uncompressed audio and graphics, but to have to·optimize your code·AND graphics to fit inside of a few megabits is a·real challange.

Now that I understand a little bit more about using 2 processors, I can use this knowlege in future designs, or this one lol, if I·feel·brave enough. Another thing I could do is use a Z80 MCU and program some serial ports for interfacing with the·Prop and ROM, since I am using serial·ROM throughout my·design. Using the same method gadgetman described, I interrupt the Z80,·I send·a serial byte·over a serial channel, it combines it with the I-register and it then reads the data at that address. Do I atleast have the process of the Z80 down?

·

Gadgetman

nick112147 said...
So basicaly I interrupt the Z80, put a byte of data on the data bus, it combines it with the interrupt register and it will execute the instruction at the address·derived from combining the byte from the data bus and the interrupt register. This would be simple if I were using two parallel bus based processors.

You got it ALMOST right...
A simplified timeline:
Prop clocks the Byte onto the shift-register
Prop Sets the IRQ line of the Z80
Z80 finishes executing current instruction.
Z80 sets a pin to show it acknowledges the IRQ. This can be used to enable the output of the shift-register.
Z80 reads Byte. Probably does something with the Acknowledge pin, too...
Z80 places the I-register + Byte on the Adress bus, then reads in the Byte there.
Z80 Places I-register + (Byte+1) on Address, and reads that Byte, too.
Z80 PUSHes PC onto Stack. (for use with a later RETI )
Z80 copies the loaded Bytes onto PC, effectively jumping to that address.
(Not certain when that PUSH happens in the sequence. Check a deatasheet)

So the I-register points to a table filled with JMP addresses. There are no executable instrutions in that table.

The way this functions the Propeller doesn't need a full Databus. It just needs some way of presenting a single Byte TO the Z80's Databus at the right moment, and a serial-in-parallel-out type shift-register is just fine for that.

I'd REALLY love to see anyone actually using this feature of the Z80 as I've never seen it in use in a commercial product...
(Not saying that it hasn't been used, only that I don't know of anyone using it)

Another strength of the Z80 is the 'DMA' instructions in it(Block copy and·compare, reading and writing blocks of data to/from an I/O-address. ), and the 'shadow registers' and the EXX instructions. Makes for pretty darn fast interrupt routines if done correctly.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...

nick112147

Gadgetman said...
Z80 places the I-register + Byte on the Adress bus, then reads in the Byte there.
Z80 Places I-register + (Byte+1) on Address, and reads that Byte, too.

So how many bytes does it read? It reads the bytes at THAT address right? Knowing this, the Z80 is going to need its own eeprom, or atleast a place to get code from right? Thanks so much for bearing with me.


Nick

Gadgetman

It reads the Byte the interupting device loaded onto the Data bus, then the two Bytes at the location pointed to.
After that it Pushes the PC(writes 2 Bytes) before it starts executing code at the new location.

And yes, the Z80 is going to need an EPROM or something of its own.
You could of course use the same shift-register as used during interrupt, and possibly another or a counter to 'download' a program by reading it from the SD-card(or whatever you have) and clocking it onto a RAM chip.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...

nick112147

So basically,·I am just providing·the lower·half of the address to jump to,·using another device rather than programming it using ASM. How the Z80 locates and·retrieves data from memory is basicaly how it would locate·retrieve data if I were to do it using ASM rather than feed·part of the address in using the Prop. So if I pump in $7F to the data bus, $7F plus the interrupt register is the address it is going to jump to as if I programmed it using ASM. I just have to make sure that the I-register is set correctly.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If truth does not exist, the statement "truth does not exist" is a truth, thereby proving itself incorrect.

Gadgetman

No.

You're providing the lower half of a pointer into a table of jump adresses.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...

nick112147

Oh okay, thats cool.·I understand jump addresses a little bit from programming with x86 assembley. Many thanks Gadgetman.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If truth does not exist, the statement "truth does not exist" is a truth, thereby proving itself incorrect.