Looking for some advice

sbk58

Looking for some advice;

I am designing a low cost CPM computer to replace my dead BigBoard CPM machine. My design is based on the Zilog EZ80F91 module (3.3v 50MHz pipelined Z80 with 24bit addressing, EN ET, SPI, I2C...). I have completed most of the project but must use Hyper Terminal on a Windows computer for my system display (my only ANSI terminal tops out at 38.4kbs). It's time to cut the cord so to speak and add a built in terminal and keyboard interface.

The PROP chip looks like it could fit the bill. But I have a few questions before I can make a decision.

I would like to have the EZ80 pass the startup code to the PROP chip with no serial EEPROM. This would allow me to load a different terminal program into the PROP chip for every resolution/feature set I want to support. Is the protocol for the PROP chip serial loader public information?
For me the best inter-CPU connection would be SPI. After the loader is done I would like to use pins 28..31 for the SPI buss. Is there a problem with using these pins after the loader has completed? Does the current SPI object support slave mode? Will multiple slave devices on the same buss be a problem (does SPI object properly use the SPI select signal as a slave)?

I would like the display to support 80X25 with 3bit or 4bit color (3-4 bits font color, 3-4 bits background color) the needs (80*25*2) 4K of main display ram. If 4Bit color was used I would need 256 color table entries or 1k bytes of ram for 3bit color 64 color entries or 256 bytes. Then there is the font memory. I would like to support VGA @ 640x480, 1024x768, and 1280x1024 if possible. For the 1280x1024 I can use the built in font. For the other two resolutions the font will have to live in main memory. The 640x480 will require an 8x16 font. The 1024x768 will require a 12x30 font. The 1024x768 font will require 15k bytes. All of this is the ideal. Anyone want to guess how feasible this is? I can write a windows program to produce the font data using the provided true type font.

Support code I would also require:

Most of the ANSI terminal emulation will be done by the EZ80. So the commands sent to the terminal would be limited to commands that must move large amounts of screen memory such as insert/delete line, clear/scroll screen...
PS2 support would transfer unencoded data and let the EZ80 do the keyboard translation.
Finally it would be nice to have a simple second terminal for TV out. It could be limited to the 2bit color TV text object. Will this all fit? I don't care if I use all the resources of the PROP chip to get the job done.

Any ideas are welcomed! The PROP chip architecture looks like it would be fun to learn. But one project at a time, so if the PROP chip will not do the job on to plan B. Once the display is done I will post the entire project on my Internet site.

I would like to thank all the people who posted to the tips and tricks. I learned a lot about the PROP chip from that section of the forms.

Mike Green

1) The protocol for downloading to the Prop is public. There's a Spin program in the Propeller Object Exchange to load Prop to Prop that is intended to be a model for other download programs.

2) Once the Prop is running, pins 28 to 31 are available for other uses. You have to be careful that the download process doesn't interfere with whatever else you're trying to do with these pins and you have to be prepared to switch back on a reset of the Prop.

3) I don't believe there's any code posted so far for use of a Prop as an SPI slave. Someone else was asking about that recently.

4) The built-in video hardware is limited to 4 colors (2 bits per color) per 16 pixel line segment. There are ways around that, but they involve using multiple synchronized cogs and you'd have to develop it yourself. Consider it a large challenge at best.

5) I know that you can have both a 1024 x 768 VGA text display and a TV text display (for debugging) at the same time with a modest size program. There are too many variations to say if this would work with other VGA drivers and other situations.

6) If you're not going to do the PS/2 scancode translation on the Prop, you'll have to modify the existing keyboard driver.

7) I strongly suggest you include the Prop boot EEPROM, preferably a 128K byte device. The incremental cost is minimal and that would allow you to use the Prop to debug the rest of the system. You could store 4 different versions of your I/O system in the Prop and select which to use via a switch or the keyboard for that matter. The CPM system could also reconfigure the Prop without having to reload it over the comm link. The PC boot connection takes priority over the EEPROM so the CPM system could reload the Prop anyway.

deSilva

What you request seems absolutely feasible

(Booting) The Prop uses a standard I2C protocol to load from the EEPROM; your processor has to emulate a slave I2C for this, I think this will work more stable than using the serial interface

(Connection) Could in fact use the same (Polling the Z80), but one could switch master and slave easily.

(Memory) not outside your requirements 80x 25 x 8 Bit = 2 kByte will work out nicely

(Character Set) You can "squeeze" the ROM characters to 8x16

(SuperVGA) Ambitious for more than 25 MHz in 4-color-mode but could use second COG, some projects discussed for that at the moment
But note: You are working at the borderline!

(Multicolor) Note you need 4-color mode, as at character width 8 there will be two bgcolors and 2 fgcolors to be displayed

(Scroll and Edit Logic) No problem: 4 COGs left to do it asynchroniously

Post Edited (deSilva) : 8/19/2007 6:00:44 PM GMT

Ariba

I'm a little bit confused about your questions.
Why different resolutions with different fonts that ends always in a 80x25 character display?
Do you expect to have this resolutions also for graphics? This is not possible because of the to little memory of the Propeller !

Now you have connected your system to a PC with Hyperterminal thru a serial link. Why not make the same with a Propeller ?
The Propeller can easy do a terminal with 80x25 characters and with a Serial-object (FullDuplexSerial) you have no problems with Master/Slave.
You can also download new code via serial connection, the protocol is available.

It's much easier to do the terminal emulation in the propeller. See the TV/VGA_Text objects, they emulate simple commands in the out-methode.
I see, you want to make as much as possible in the EZ80 because you know this system. But you will have to learn Spin anyway to make also the simplest version of a terminal, and then, if you know Spin and the propeller, it can happen that you totaly forget your CPM computer... [noparse];)[/noparse]

Andy

sbk58

Mike thank's for the reply.

It is not possible to add all the small details of a project to a form post.

1) Glad to here the loader protocol is public. One problem solved.

2) All EZ80 pins can be used as GPIO including the pins used by it's SPI controler. During the loader phase I can use the pins to perform as a serial interface. Once the PROP is running I can assign the same pins to the SPI controller. This gives me maximum use of the PROP and EZ80 IO pins. As no devices on the SPI will be selected any activity will be ignored by the other devices.

3) That's to bad, have to look at the master SPI code and modifiy it. Compared to the video driver should be simple if I give it ir's own cog.

4) Its a given that I will be writing the video driver myself. My understanding of the video hardware (VGA mode) is that you must pass a 4 color (32 bit) value to the video shift register along with the 32 bit font data. So the only mode I could have 4bit color is 1280x1024. I should have thought about that before posting.

6) This should not be a problem with the source provided as I would be removing functionality and not adding features.

7) The only reason in my case for the EEPROM would be to fit a program larger then 32k. I have tought myself to never over design a project. So if I do not need the EEPROM and its 3 or 4 support parts no need to have it. Also if I do not have an EEPROM I save two pins.
I will use a parallax demo board to develope the brunt of the code. Once the terminal portion is working I will change the code to use SPI on the correct pins. I have already written a TFTP client for the CPM system so transfering files from my PC to the CPM system is simple. The hardware debuging on the EZ80 should make the CPU inter-connect code simple to debug.

You make a good case for the EEPROM. This way I would not need to write the PROP loader. I also have the option of using the EEPROM and connecting it to the EZ80 I2C port. This way I just load the eeprom and clear the PROP reset. I was hoping to use the EZ80 I2C port with 4 I2C register file ICs. If the EEPROM could exist with the 8 bit register IC's on the same I2C buss this would also be a vialbe option. Never tried that have to check the data sheets to see if the addressing will be a problem. If the chips can all exist on the I2C buss I would need to create an I2C slave object. The only down side is in general I have found SPI a more reliable transport then I2C.

Thanks for the ideas and info.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Programing is a team sport.

deSilva

.. said...
... My understanding of the video hardware (VGA mode) is that you must pass a 4 color (32 bit) value to the video shift register along with the 32 bit font data. So the only mode I could have 4bit color is 1280x1024.

Your understanding is not absolutely correct. Maybe you will profit from a look at Chapter 7 of my Assembly Tutorial. The Chapter 8 is still missing, but I think it will be available when you start your project

Ariba's question about your many screen formats is viable!

You can feed a pixel clock of 25 MHz in 4-color-mode in one COG but not very much more; the limiting factor is the memory interface.

When you use 8x8 characters = 2 long you can keep the maps of 128 characters in the COG... this opens a new dimension

Mike Green

EEPROMs can exist on the same I2C bus as other devices. I've used PCA9554 I/O Expanders on the EEPROM bus before. The only requirement is that a 32K byte address space exist at ID $A0. The other issue is that the EEPROM boot routines in the Prop ROM assume that there's no pullup resistor on the I2C clock line and actively drive the line high and low where the I2C bus protocol requires pullups on both the clock and data lines. This means that the Prop could drive the clock line high when some other bus master is driving the line low ... a short. You can always put a pullup on the clock line and make sure that the Prop is either in reset or has started the "user" program when some other bus master is active.

Part of the problem with the color tiling is that there are very high data rates involved and you really need the assistance of the video shift registers. The color capability is really better for text than the 4-color mode that you might think. Colors are actually chosen from a large palette, but any given multiple of 16 pixels can only have 4 of them. If you use a 16 wide character cell, you actually have 4 separate 8-bit colors for each character ... one for background and 3 for different shadings of foreground. The existing drivers that use the built-in font table use 16 bits for the characters (tiles) and can reference up to 128 colors for each character, one long with 4 color bytes for each color. Most programs use only a portion of this palette table, maybe 32 entries.

deSilva

Mike Green said...
....that the Prop could drive the clock line high when some other bus master is driving the line low ... a short.

Good to know.. things that drive you crazy when debugging and you don't know ... I always thought "they" had "forgotten" it on some boards. But luckily I used always different pins for local I2C...

Mike Green said...
....and can reference up to 128 colors for each character, one long with 4 color bytes for each color. Most programs use only a portion ...

The limiting factor is the DAC, 6 pins = 60 colours + black + white + 2 greys
You can do much better with more Cogs -> Baggers: Great project!

sbk58

deSilva;

After reading Mike's post I realized that 4 colors is all I can have. I think the direct to ram loading of the PROP chip is actually the most reliable mode. This way I do not need to connect the EZ80 I2C buss to the PROP chip EEPROM and the final design will have fewer parts.

Ariba;

LCD displays look best when run at there native resolution. By matching the driver to the display resolution I get the best image. As the display resolution increases so does the font size/resolution, again a better display image (at the same character size of 80x25).

The EZ80 has 2 asyn uarts. One is used as an RS232 port in my design. The second UART port can also function as an 8 bit IO port so I would like to leave it free for future expansion. Since I already have SPI devices (2Meg data flash, FTDI USB master) connecting the PROP chip to the SPI bus would use the least amount of pins on the EZ80 and keep my PC board layout the smallest.

My choice of using the EZ80 for the terminal emulation is based on resources and not on programing choice. The EZ80 has has mega bytes of ram and flash memory. Given the EZ80 speed is as fast at byte oriented code as a single cog in the PROP chip, and I can more easily load a terminal module (based on the program running) I belive the emulation should be done at the EZ80. Remember the PROP will have a command set mostly composed of the commands all terminal profiles use. While ANSI is all I will use for any new software many old CPM programs require other terminal types to run. I want to devote all the resources of the PROP to providing as many features on my wish list as I can so any functionality I can off to the EZ80 leaves more features that the PROP can handle.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Programing is a team sport.

deSilva

sbk58 said...
... after reading Mike's post I realized that 4 colors is all I can have.

I feel that there is still some misunderstanding, but never mind. But you have to use "4-color-mode" , which is just a trade term...

sbk58 said...
...This way I do not need to connect the EZ80 I2C bus to the PROP chip EEPROM and the final design will have fewer parts.

This was NOT my proposal: I suggested to connect the EZ in place of the EEPROM. The Prop will expect to read a 32 k image the EZ80 can easily provide.

sbk58

Mike

Thanks for the info on the PCA9554 with EEPROM. The I2C bus master problem (good catch) you poiinted out will not be a problem in my design. As the PROP chip will only use the I2C bus after a reset to load the program. If I keep the EZ80 from using the I2C bus until the PROP has loaoded I should be OK. After that the only master on the bus will be the EZ80 the PROP chip would become a slave.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Programing is a team sport.

sbk58

deSilva

Sorry did not understand. Yes that would be possible. The EZ80 can be both a master and a slave device. At rest of the PROP the EZ80 would be an I2C slave and the PROP an I2C master, after the prop is loaded it could send a message on the I2C bus and switch into I2C slave mode. Good point need to think about what problems that will cause.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Programing is a team sport.

Ariba

Thank you for clarification. That make sense.

If you connect the EZ80 to the I2C lines of Prop/EEPROM and another wire from EZ80 to the Prop-Reset input, the EZ80 can write a new code directly in the EEPROM while holding the Propeller in the Reset state. When you release Reset, the Propeller loads the new written code from the EEPROM and execute it. This can be easier then emulate a EEPROM as deSilva suggested (not timing critical).

With a small serial Resistor (100 Ohm) in the SCL line, there will be never a short circuit, also if two devices want be masters at the same time.

Andy

deSilva

Ariba said...
easier then emulate an EEPROM as deSilva suggested (not timing critical)

I think the EZ80 driver will know clock-stretching
But maybe the EZ80 will be too fast for the Prop-Loader?

I am interested in this concept as I plan to load the Props in my multiProp-Project in the same way.

sbk58

deSilva

The EZ80 has a baud rate gen for the I2C device, speed should not be a problem. Designing the state machine code to emulate the EEPROM will be the complex part.

If the emulation also allowed the PROP chip to write to the emulated EEPROM I could have a poor mans dual port memory. Commands could be sent by writing to a specific EEPROM location (page) with the command and using a pin on the EZ80 signal the PROP that a command needs to execute. The prop would read the EEPROM page and execute the command. The PROP would write back the result status/data to the EEPROM. Since the emulated EEPROM would realy live in EZ80 ram reads and writes would take the same amount of time. Not the way I started out but that's why I posted to the fourm.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Programing is a team sport.