I'm working on some new boards - just sent them off to BatchPCB. Not very exciting at the moment while I'm waiting for them to come back, but in theory we should be able to draw a screen of text in any font in 30 milliseconds.
that would be HUGE. I'm sure more speed could be squeezed from my current code. A full screen in Rom font is about 30 seconds. Your font is takes about 45 seconds a screen. I need to re-write my low level screen driver to be more compatible and add some commands. I have noticed an issue.
This wastes a huge amount of time. I'm not sure why the bytes are out of order. Gotta be a faster way to do this.
I've been thinking about new hardware, and keep going back to the drawing board. The 32k chip would be cool if I had 2. The 8k chips I have seem small. Just room for 1 font. I have these pic 18f's laying around. I also have numerous z80s and 80c's.
*edit*
I did some "tuning" and have screen writes down to about 3 seconds a screen!
Yes, there are 32 of those dang things because I'm using 3.3v prop and display with 5v SRAMs. I have the eagle files, will edit the post with those in a sec.
This should be it..
Ok so the ram chips run at 5V. I have a feeling that some months ago there was a very long discussion thread about the best resistor for 3V to 5V translation and I think it was something around 2.7k. Something to do with the current value of the tiny diodes inside the chips running on 3V. Someone might chime in with a thought on that.
I see those are 32k chips and with two, that should be enough for a few fonts, or icons or both. Should be plenty, as a full screen redraw is going to come off the SD card so large ram isn't really needed for that.
Ok, I've been doing some work because I did not like the last layout, and I think I got the ENABLES backward.
Here's what I've come up with now. LCD_WR is connected to the Counter Clock.
LCD(_CS_RD_RST) are hooked up to control register, as well as,
BUS_DIR,
RAM address count INHIBIT, RAM (wr/RD)
RAM address LOAD, RAM CS
EEPROM SDA and SCK are stacked with pinheaders for expansion.
Most logic is 5v
I'm still using a `595 for control register. I hope to only update this a couple times per element. I'm still considering using a `373 from pins 0-7. Not sure how much this will hurt performance.
Thanks for the info on 3v-5v translation. I have read through a few threads about it, but that number never seems to stick.
I think 32k chips will be a good start. I have 1 bit left in the counters so in the future perhaps a second bank?
Any ideas?
You know, I think you might be really onto something with those counter chips. If you latch in an address then that gives you random access even if you only read or write one byte/word. Most data is going to be consecutive, albeit at a random start place.
And your counters could be the very fastest memory access possible on the propeller. Consider three memory chips in parallel with a data bus of 24 bits - you can read 3 bytes at once, then it is only one toggle of the counter and you can read the next 3 bytes.
The display naturally works with 2 bytes, but for fast memory access this opens up some intriguing possibilities with 1, 2 or 3 bytes. It might be getting close to hub access speed, so you could have an LMM program running from external ram instead of hub ram.
I always try to solve any major software limitations in hardware. Thinking about accessing ram as quickly, and with as little supervision from the software, is what made me think about this method. I keep wondering if the spi control register is going to be the weakest link. My counter idea could even be implemented in yo=ur system by replacing the memory address latches with counters, 2 4-bit counters per load/clock. You would need 5 counters?
The last 2 things for this evening... I'm building a stand-in for the propPlug using the 3232 from my proprpm. I'm almost done with that, then it's start the new board. If I'm using the 3232 offboard from the prop, should I put a large cap across the input for the power supply? I already have duplicated their caps and added a 10uf across vdd/vss. http://elmicro.com/files/elmicro/proprpmv10_schema.pdf Should I put a larger electrolytic cap on the small pcb?
Also. I will be working on the RAM driver shortly, adding DRAW and FILL in asm. I think something like
Draw(x1,x2,y1,y2)
Fill(Color,Count)
These will be passed into asm just like the other commands. Any thoughts for the letter name. Your using " A, B, C, D, E, F, I, R, W"
Starting asm work...
check command:
cmp cmd, #"G" wz ' SetDRAW X1,X2, Y1 Y2
'if_z jmp #DRAW ' and do it
cmp cmd, #"H" wz ' FILL COLOR, *if18bit?* COUNT
'if_z jmp #fill
This should provide access to data writes and command writes
setCSlowRSlow mov dira,latchdirection ' enable for output
mov outa,latch7command ' sets CS low, RS low (RS low is command output
andn outa,GateHigh ' set gate low
or outa,GateHigh ' set it high again
setCSlowRSlow_ret ret
setCSlowRShigh mov dira,latchdirection ' enable for output
mov outa,latch7data ' sets CS low, RS high (RS high is data output
andn outa,GateHigh ' set gate low
or outa,GateHigh ' set it high again
setCSlowRShigh_ret ret
This needs to be fixed
Latch7command long %00000000_00000000_00001111_00010111 ' latch7 address 111x and gate high, reset high,
cs low, read high, write high, rs low for comman output, combines rslow in spin into one line
I'm working off old code, sorry. Just trying to get a feel for it.
*edited again*
so I thought about it some more. ClearFontBG would be WAY faster if we stored BG @ RAM ADDRESS 12? ClearRAM-ADD, set LCD_WR. Draw is streamlined from RAM read...
1. LCD Command : set_V_ramPOS
2. LCD data : ($EF00?)
3. LCD Command : set_H_ramSTart
4. LCD data : 0
5. LCD Command : set_H_ramEND
6. LCD data : $013f
7. LCD Command : set xadd
8. LCD data : 0
9. LCD command :set yadd
10.LCD data : 0
11. LCD command ramWR
12. COLOR
Might be used to do fast draw set? Write draw commands from ram, and use prop's data?
My counter idea could even be implemented in yo=ur system by replacing the memory address latches with counters, 2 4-bit counters per load/clock. You would need 5 counters?
Yes - good idea. Latch in a 19 bit value then count it. I think that beats latches. This is a *very* interesting idea. I'd be interested in experiments at full speed pasm checking any ripple delays as each counter clocks the next one. HC is ? 18ns and if you have 5 cascaded then might need a NOP or two in there? Or use faster chips?
Max 3232 off board should be fine without a big cap - the max chip is only using milliamps at most.
My letter names are random. I'm thinking now of just going ABCDEF (leave out I as that is "initialise")
Another pasm command we could think about is multicolor fonts. At the moment, that demo screenshot that replicates the Proptool colors had a separate font file for each foreground and background. Maybe that could be done on the fly in pasm - get a bit, if 0 set to one color, if 1 set to another color. Probably only a couple more pasm commands. So you could have super fast black on white font, and then a little bit slower, anycolor font.
Your schematic is interesting. Kind of similar to the motherboard I have just sent off to get made
My design was largely based off of your design. From my understanding, if you make all the counter clock lines common, and use the RCO to control an enable *I think it's pin 10* there should be little delay. I have not cascaded these chips yet, but I will be playing around with this tonight. My thought is, how to make the Prop's counters control the 161 clock lines accurately. I will keep you updated.
I like the multi-color font idea. Before I started working on my next-gen hardware, I was thinking about storing font info separate from font color. This would be ?considerably? slower but should still work.
I have been thinking about your counters more and I think you are really onto something.
Ok - if you want fast memory to display transfers you need to directly connect the memory and the display with 16 data lines. In my design, you then need to isolate those links if you want to use 19 propeller pins to control the address. So - I need three 373 chips and two 245 chips = 5 chips.
Now - compare this with your design. Keep the display and the memory chip in HiZ by holding their read and write pins high. Load address into the 161 latches - for 2^14 to 2^19 depending on the chip. For two 512k ram chips that is 2^19. Then do one of three things:
1) Read from the memory chip into the propeller using the 16 data lines (two bytes per cycle)
2) Write from the propeller to the memory chip using the 16 data lines
3) Move the data from the ram chip to the display and the propeller just ignores the 16 data lines.
I think that you can replace my 5 chips above with 5 of your 161 chips. So the chip count is the same. But the chips are smaller - 16 pin instead of 20 pin.
Your design just keeps getting better!
I think there is a standard circuit for cascading 161 chips. The clocks are all joined. There are two inputs that I think are joined and go to the overflow from the previous chip. Clear won't be needed as you would just load in zero instead. Two control lines for the whole group - clock, and load.
Just an FYI, but SPI automatically increments the address on clock, so you can load an address and simply clock it.
Use 2 QSPI or 8 SPI chips to make an 8bit bus, then send 1 long for the read instruction, then hit it with a clock and it will stream the data out without any external counters.
This would be a way to really reduce the component count.
Also, flash SPI is pretty cheap, about $1 for 1MB, so 8MB of flash for $8. I'm sure it's a little more for q1, but reasonable.
I did a quick search of RAM SPI chips and came up with 32K being the biggest SRAM Digikey sells. I didn't see if it was qSPI, but I'm sure it can be had.
SDRAM does latched reads too. You send a command to read out a line, the address, then just strobe it to get the data off that line. They typically have 2 buffers so you can setup 1 line first, and read another, leapfrogging through the chip. Each line can be rather large and the bus width is dictated by the part purchased. In this case you could have a 1 chip solution for internally latched memory.
Might also consider that some of that memory could be EPROM. (not EEprom!)
Might be a nice place to stash a bunch of font, image, sound, video, etc files.
Sure, EEprom can handle the size, but would invoke a performance hit...
Hmm, I will have to investigate other ram chips, However... Since I just ordered parts, I'm kinda suck with these chips right now. From what I can see, the limiting factor for screen transfer is the write cycle time, on my chip 100ns. I believe my old logic connections to be faulty, I'm trying to fix that. The point is, to combine the LCD clock *on chip select instead of write* with ram count. My concern is the data hold time. Setup time should not be a problem if clocks are interleaved..
eg. clocks
0.PropBus = RamAddress, AddressLoad, RAM_cs, RAM_rd, LCD_cs, LCD_wr,
1.AddressCount, CountEnable
then clock data from ram to lcd by toggling clock.
my thought is rising edge of LCD_CS writes to display
falling edge *inverted LCD_CS* counts. Not sure what would work best logically. Finishing my propplug stand-in right now and off to breadboard test some things...
*edit*
@cavelamb
The eprom idea could be really smart. Not only could it handle a *stock* font, maybe we could stash a table of lcd commands in such a way as I described earlier.
eg....
set up draw by addressing table draw function, then send out the xPos from rom, data from prop,
clock rom, yStart from rom, data from prop
clock rom, yEnd from rom, data from prop,
clock rom, gdwrite from rom,
clock rom, color from rom,
clock * pixels...
I keep playing around with the schematic. What I have so far is not a huge change. The `590 control register is now a `374. Lines are a bit different. LCD RS, LCD CS, RAM CS and BUS enable are prop controlled. Everything else is in the control register. RAM_WR and RAM_RD are connected with inverters. I did lose 1 line for my SPI address decoding. MIDI in and out are still connected to the prop.
The lcd_cs and ram clock are still connected together, but this may change soon. Still fighting the *need more really fast pins* problem, LOL. After some thought, the weakest link seems to be the displays themselves. 100ns write cycle means 10mhz max clock... With the super fast ram, and some high speed counters, we could do things much quicker than the display will like. Now I'm stumped.
What you are talking about is basically old-fashioned DMA - Direct Memory Access.
Back in the early times this was necessary because the processors were so slow.
Hardware would pass data behind the processor's back.
Then the processors sped up and it was cheaper and faster to let the processor do it.
So now we come full circle...
Even 10 Mhz clock rate will be quicker than reading from SD or reading from Xmem and writing to display.
Take a look at 74HC259 for 8 single-bit output ports.
They will not be as fast as Prop pins, but could handles the slower stuff easily.
I haven't been able to see the revised schematic yet.
I just got DipTrace installed with a non-profit license.
So far it looks pretty nice. Easy to figure out.
I'm hoping that will handle the schematic files?
What you are talking about is basically old-fashioned DMA - Direct Memory Access.
Back in the early times this was necessary because the processors were so slow.
Hardware would pass data behind the processor's back.
Then the processors sped up and it was cheaper and faster to let the processor do it.
So now we come full circle...
Even 10 Mhz clock rate will be quicker than reading from SD or reading from Xmem and writing to display.
Take a look at 74HC259 for 8 single-bit output ports.
They will not be as fast as Prop pins, but could handles the slower stuff easily.
I haven't been able to see the revised schematic yet.
I just got DipTrace installed with a non-profit license.
So far it looks pretty nice. Easy to figure out.
I'm hoping that will handle the schematic files?
Yes, seems we have come full circle.
I've got a few of those 259's laying around, and while they are handy, pin-outs are almost as expensive as latches. I actually had one in there to begin with. Who knows what future revisions may bring. I think I'm over thinking a lot of this design I'm working on. Most of the "revisions" I've come up with would work perfectly fine, I'm just trying to do things as "fast" as possible, with the least amount of overhead *latching addresses, toggling cs's, etc*
I did a quick test with the ls161a's I have, and they ran the following just fine.
CON
_clkmode = xtal1 + pll16x ' use crystal x 16
_xinfreq = 5_000_000
Obj
wait : "timing"
var
pub start
outa[2..0] := 3
dira := $0007
do
pub do
repeat
wait.pause10us(1)
!outa[2]
Now I think the trick is setting the Propeller Counter up and supervising it properly. I've been over the application note about 3 dozen times over the last year, and I'm still waiting for that *lightbulb* moment. Oh well.. Off to play with some pllMode.. Before I forget, here's some pix..
If you are looking for a more standard looking 161 part in eagle search for *161* and at the top is a 4161N and rename it 74HC161.
Re counting, this would be in pasm but you could start with a spin version.
Preload start address. Clock is high.
repeat
LCD write low (logical and with 11111110111111) where that is your pin to toggle
possibly a NOP or two here in pasm
LCD write high (andn)
clock low (logical and)
clock high (logical andn)
At a minimum it is 4 pasm clock cycles. That will be faster than 30 screen refreshes per second.
The NOP may be needed for two reasons - for the ram chip and possibly, for the cascade delay as the carry goes through the 5 chips. I'm guessing one NOP.
Here is a new circuit idea based on your 161 counter concept.
Two memory chips, one 138 and five 161 counters.
There are 4 control states:
0) User is touching the screen, P0-P2 talk to the touchscreen. Other pins all free for any other use.
1) Load a 19 bit address into the counters
2) Memory transfer. 16 data bit bus. SD card enabled. Move data from SD to propeller, propeller to ram, ram to propeller, ram to display and propeller to audio output.
3) Reset the ILI display.
This would be able to run the Z80 emulation and external memory C as well as any other language that uses external memory.
This will be fast as it transfers data to and from memory 16 bits at a time.
See, that's why I kept working on the design. That's WAY more like it I still need to stare at it a bit longer, but I think I will be using this "variant."
I received my parts today, and after getting my prop breadboard platform working *took way longer than I thought it would* I'm ready to experiment a bit. First is hook up all the 161's and play with counting. I'm hoping to use the propeller's counters for clocking ram to display. Still untested but theoretically it should free the cog to get stuff from the hub or do other things? Or at least get a jump start?
Now an interesting thought, I will be sticking with my 16 bit addressing scheme for now. I still have one address line in the counters and I was thinking about what cavelamb suggested. Using some Eprom's to store tables could provide some default data. I know of a few places were I could free up a few longs with this. The question is what to put in here, other than fonts. What data would benefit from the sequential read cycle?
/STARTUP is the default condition when the propeller boots. All prop pins are HiZ and so with 10k pullups on the three pins going into the 138, that means that Y7 will be low. Or more to the point, all the other pins will be high.
I started with lots of latches and gradually got rid of them.
There are not many instances where you would be jumping around one memory location at a time. For a Z80 emulation, most of the time you are reading in a sequential program. Ditto for a C program. In fact it gets even better for a C program as these have caching where you read in blocks of data eg 128 or 256 or 512 bytes.
For a display, most thing are done in memory blocks, eg an icon or a picture. Even a line can be done as a block as you make either x1=x2 for a vertical line, or y1=y2 for a horizontal line.
I don't think you need many more pins. There are so many ways to get more pins - in theory each of the Y0-Y6 outputs of the 138 could select a group of 28 propeller pins and that is without even adding latches.
I don't know about the eprom thing. What is that trying to do that you can't do with the SD card and the ram?
The board looked a bit bare so I thought I would add TV, VGA, Keyboard, 8 generic latched outputs and 2 I/O pins. Easy to add more of these sorts of things. Also easy to leave out those parts. The 244 is possibly not necessary but I was worried about those low value resistors loading up the prop pins and slowing down the memory read/writes so I added that chip to isolate them. The VGA/TV display would blank during memory access which is not ideal, though you could be cunning and combine memory access with a VGA cog and do a few blocks of memory after a screen has been written.
On the other hand, with a touchscreen you may not need TV or VGA. It does give backwards compatibility to other designs though.
Kudos to averagejoe for persevering with this. It is a very clever design and it is the way it frees up propeller pins that is so clever. The reduction in part number and the decrease in complexity is amazing. ILI_RS, Mem_RD, Mem_WR, ILI_WR are now done directly from propeller pins.
I find myself wondering, what the minimal amount of hardware would be required to reasonably optimize a blit operation. Maybe a pair of address generating counters, one dedicated to read, and one for write? Maybe dual-port ram with both ports on the same bus. Can Synchronous SRAM be used? Looks like the address registers have built-in counters. CY7C09089V
Comments
I'm working on some new boards - just sent them off to BatchPCB. Not very exciting at the moment while I'm waiting for them to come back, but in theory we should be able to draw a screen of text in any font in 30 milliseconds.
PUB hub(address,l) | p, pl, ph repeat l / 2 pl := byte[address++] ph := byte[address++] p:= ph +(pl << 8) Lcd_Write_Asm((REG_RAMDATAWRITE << 16)+ p )This wastes a huge amount of time. I'm not sure why the bytes are out of order. Gotta be a faster way to do this.I've been thinking about new hardware, and keep going back to the drawing board. The 32k chip would be cool if I had 2. The 8k chips I have seem small. Just room for 1 font. I have these pic 18f's laying around. I also have numerous z80s and 80c's.
*edit*
I did some "tuning" and have screen writes down to about 3 seconds a screen!
Are the resistors for 3V to 5V translation?
This should be it..
Ok so the ram chips run at 5V. I have a feeling that some months ago there was a very long discussion thread about the best resistor for 3V to 5V translation and I think it was something around 2.7k. Something to do with the current value of the tiny diodes inside the chips running on 3V. Someone might chime in with a thought on that.
I see those are 32k chips and with two, that should be enough for a few fonts, or icons or both. Should be plenty, as a full screen redraw is going to come off the SD card so large ram isn't really needed for that.
Here's what I've come up with now. LCD_WR is connected to the Counter Clock.
LCD(_CS_RD_RST) are hooked up to control register, as well as,
BUS_DIR,
RAM address count INHIBIT, RAM (wr/RD)
RAM address LOAD, RAM CS
Prop gets
BUS_Enable, LCD_(WR,RS)
SPI_(CK_DI_DO), SPI (add0..2) SPI_enable
MIDI_In and MIDI_out
EEPROM SDA and SCK are stacked with pinheaders for expansion.
Most logic is 5v
I'm still using a `595 for control register. I hope to only update this a couple times per element. I'm still considering using a `373 from pins 0-7. Not sure how much this will hurt performance.
Thanks for the info on 3v-5v translation. I have read through a few threads about it, but that number never seems to stick.
I think 32k chips will be a good start. I have 1 bit left in the counters so in the future perhaps a second bank?
Any ideas?
And your counters could be the very fastest memory access possible on the propeller. Consider three memory chips in parallel with a data bus of 24 bits - you can read 3 bytes at once, then it is only one toggle of the counter and you can read the next 3 bytes.
The display naturally works with 2 bytes, but for fast memory access this opens up some intriguing possibilities with 1, 2 or 3 bytes. It might be getting close to hub access speed, so you could have an LMM program running from external ram instead of hub ram.
The last 2 things for this evening... I'm building a stand-in for the propPlug using the 3232 from my proprpm. I'm almost done with that, then it's start the new board. If I'm using the 3232 offboard from the prop, should I put a large cap across the input for the power supply? I already have duplicated their caps and added a 10uf across vdd/vss. http://elmicro.com/files/elmicro/proprpmv10_schema.pdf Should I put a larger electrolytic cap on the small pcb?
Also. I will be working on the RAM driver shortly, adding DRAW and FILL in asm. I think something like
Draw(x1,x2,y1,y2)
Fill(Color,Count)
These will be passed into asm just like the other commands. Any thoughts for the letter name. Your using " A, B, C, D, E, F, I, R, W"
Starting asm work...
check command:
cmp cmd, #"G" wz ' SetDRAW X1,X2, Y1 Y2 'if_z jmp #DRAW ' and do it cmp cmd, #"H" wz ' FILL COLOR, *if18bit?* COUNT 'if_z jmp #fillThis should provide access to data writes and command writes
setCSlowRSlow mov dira,latchdirection ' enable for output mov outa,latch7command ' sets CS low, RS low (RS low is command output andn outa,GateHigh ' set gate low or outa,GateHigh ' set it high again setCSlowRSlow_ret ret setCSlowRShigh mov dira,latchdirection ' enable for output mov outa,latch7data ' sets CS low, RS high (RS high is data output andn outa,GateHigh ' set gate low or outa,GateHigh ' set it high again setCSlowRShigh_ret retThis needs to be fixed
I'm working off old code, sorry. Just trying to get a feel for it.
*edited again*
so I thought about it some more. ClearFontBG would be WAY faster if we stored BG @ RAM ADDRESS 12? ClearRAM-ADD, set LCD_WR. Draw is streamlined from RAM read...
1. LCD Command : set_V_ramPOS
2. LCD data : ($EF00?)
3. LCD Command : set_H_ramSTart
4. LCD data : 0
5. LCD Command : set_H_ramEND
6. LCD data : $013f
7. LCD Command : set xadd
8. LCD data : 0
9. LCD command :set yadd
10.LCD data : 0
11. LCD command ramWR
12. COLOR
Might be used to do fast draw set? Write draw commands from ram, and use prop's data?
Yes - good idea. Latch in a 19 bit value then count it. I think that beats latches. This is a *very* interesting idea. I'd be interested in experiments at full speed pasm checking any ripple delays as each counter clocks the next one. HC is ? 18ns and if you have 5 cascaded then might need a NOP or two in there? Or use faster chips?
Max 3232 off board should be fine without a big cap - the max chip is only using milliamps at most.
My letter names are random. I'm thinking now of just going ABCDEF (leave out I as that is "initialise")
Another pasm command we could think about is multicolor fonts. At the moment, that demo screenshot that replicates the Proptool colors had a separate font file for each foreground and background. Maybe that could be done on the fly in pasm - get a bit, if 0 set to one color, if 1 set to another color. Probably only a couple more pasm commands. So you could have super fast black on white font, and then a little bit slower, anycolor font.
Your schematic is interesting. Kind of similar to the motherboard I have just sent off to get made
I like the multi-color font idea. Before I started working on my next-gen hardware, I was thinking about storing font info separate from font color. This would be ?considerably? slower but should still work.
Ok - if you want fast memory to display transfers you need to directly connect the memory and the display with 16 data lines. In my design, you then need to isolate those links if you want to use 19 propeller pins to control the address. So - I need three 373 chips and two 245 chips = 5 chips.
Now - compare this with your design. Keep the display and the memory chip in HiZ by holding their read and write pins high. Load address into the 161 latches - for 2^14 to 2^19 depending on the chip. For two 512k ram chips that is 2^19. Then do one of three things:
1) Read from the memory chip into the propeller using the 16 data lines (two bytes per cycle)
2) Write from the propeller to the memory chip using the 16 data lines
3) Move the data from the ram chip to the display and the propeller just ignores the 16 data lines.
I think that you can replace my 5 chips above with 5 of your 161 chips. So the chip count is the same. But the chips are smaller - 16 pin instead of 20 pin.
Your design just keeps getting better!
I think there is a standard circuit for cascading 161 chips. The clocks are all joined. There are two inputs that I think are joined and go to the overflow from the previous chip. Clear won't be needed as you would just load in zero instead. Two control lines for the whole group - clock, and load.
Use 2 QSPI or 8 SPI chips to make an 8bit bus, then send 1 long for the read instruction, then hit it with a clock and it will stream the data out without any external counters.
This would be a way to really reduce the component count.
Also, flash SPI is pretty cheap, about $1 for 1MB, so 8MB of flash for $8. I'm sure it's a little more for q1, but reasonable.
This wouldn't be flash though - it would be standard ram. Any suggestion as to QSPI sram chips?
At first glance - 5 161 chips and two 512kilobyte (4 megabit) sram chips = 7 chips. vs 4 QSPI sram chips. Interesting.
SDRAM does latched reads too. You send a command to read out a line, the address, then just strobe it to get the data off that line. They typically have 2 buffers so you can setup 1 line first, and read another, leapfrogging through the chip. Each line can be rather large and the bus width is dictated by the part purchased. In this case you could have a 1 chip solution for internally latched memory.
What would be the performance difference to read or write a 1 meg file?
Might be a nice place to stash a bunch of font, image, sound, video, etc files.
Sure, EEprom can handle the size, but would invoke a performance hit...
eg. clocks
0.PropBus = RamAddress, AddressLoad, RAM_cs, RAM_rd, LCD_cs, LCD_wr,
1.AddressCount, CountEnable
then clock data from ram to lcd by toggling clock.
my thought is rising edge of LCD_CS writes to display
falling edge *inverted LCD_CS* counts. Not sure what would work best logically. Finishing my propplug stand-in right now and off to breadboard test some things...
*edit*
@cavelamb
The eprom idea could be really smart. Not only could it handle a *stock* font, maybe we could stash a table of lcd commands in such a way as I described earlier.
eg....
set up draw by addressing table draw function, then send out the xPos from rom, data from prop,
clock rom, yStart from rom, data from prop
clock rom, yEnd from rom, data from prop,
clock rom, gdwrite from rom,
clock rom, color from rom,
clock * pixels...
I'm not sure of the exact figure, but my idea is to run the propCounters @ clock > 20mhz. Maybe?
That could be sweet!
The lcd_cs and ram clock are still connected together, but this may change soon. Still fighting the *need more really fast pins* problem, LOL. After some thought, the weakest link seems to be the displays themselves. 100ns write cycle means 10mhz max clock... With the super fast ram, and some high speed counters, we could do things much quicker than the display will like. Now I'm stumped.
Back in the early times this was necessary because the processors were so slow.
Hardware would pass data behind the processor's back.
Then the processors sped up and it was cheaper and faster to let the processor do it.
So now we come full circle...
Even 10 Mhz clock rate will be quicker than reading from SD or reading from Xmem and writing to display.
Take a look at 74HC259 for 8 single-bit output ports.
They will not be as fast as Prop pins, but could handles the slower stuff easily.
I haven't been able to see the revised schematic yet.
I just got DipTrace installed with a non-profit license.
So far it looks pretty nice. Easy to figure out.
I'm hoping that will handle the schematic files?
Yes, seems we have come full circle.
I've got a few of those 259's laying around, and while they are handy, pin-outs are almost as expensive as latches. I actually had one in there to begin with. Who knows what future revisions may bring. I think I'm over thinking a lot of this design I'm working on. Most of the "revisions" I've come up with would work perfectly fine, I'm just trying to do things as "fast" as possible, with the least amount of overhead *latching addresses, toggling cs's, etc*
I did a quick test with the ls161a's I have, and they ran the following just fine.
CON _clkmode = xtal1 + pll16x ' use crystal x 16 _xinfreq = 5_000_000 Obj wait : "timing" var pub start outa[2..0] := 3 dira := $0007 do pub do repeat wait.pause10us(1) !outa[2]Now I think the trick is setting the Propeller Counter up and supervising it properly. I've been over the application note about 3 dozen times over the last year, and I'm still waiting for that *lightbulb* moment. Oh well.. Off to play with some pllMode.. Before I forget, here's some pix..I doubt our schematic files are compatible. Cadsoft Eagle http://www.cadsoftusa.com/..
LCD_Controller.rar Here's the "LATEST" Display controller in eagle and hi-res*
Re counting, this would be in pasm but you could start with a spin version.
At a minimum it is 4 pasm clock cycles. That will be faster than 30 screen refreshes per second.
The NOP may be needed for two reasons - for the ram chip and possibly, for the cascade delay as the carry goes through the 5 chips. I'm guessing one NOP.
Drawing up a schematic at the moment...
Two memory chips, one 138 and five 161 counters.
There are 4 control states:
0) User is touching the screen, P0-P2 talk to the touchscreen. Other pins all free for any other use.
1) Load a 19 bit address into the counters
2) Memory transfer. 16 data bit bus. SD card enabled. Move data from SD to propeller, propeller to ram, ram to propeller, ram to display and propeller to audio output.
3) Reset the ILI display.
This would be able to run the Z80 emulation and external memory C as well as any other language that uses external memory.
This will be fast as it transfers data to and from memory 16 bits at a time.
There has to be a catch - this is too simple!
Very sweet, indeed!
Critique?
Setting up the external memory address is a once-in-a-while thing.
(compared to the transfer cycles, anyway)
One could trade off Prop pins for a few 8 bit latches and not even notice any performance degradation.
IF one ever needed more pins...
Four HC373s and the rest of that '138 should do it nicely.
.(I don't see /STARTUP used anywhere)
Build it!
I received my parts today, and after getting my prop breadboard platform working *took way longer than I thought it would* I'm ready to experiment a bit. First is hook up all the 161's and play with counting. I'm hoping to use the propeller's counters for clocking ram to display. Still untested but theoretically it should free the cog to get stuff from the hub or do other things? Or at least get a jump start?
Now an interesting thought, I will be sticking with my 16 bit addressing scheme for now. I still have one address line in the counters and I was thinking about what cavelamb suggested. Using some Eprom's to store tables could provide some default data. I know of a few places were I could free up a few longs with this. The question is what to put in here, other than fonts. What data would benefit from the sequential read cycle?
I started with lots of latches and gradually got rid of them.
There are not many instances where you would be jumping around one memory location at a time. For a Z80 emulation, most of the time you are reading in a sequential program. Ditto for a C program. In fact it gets even better for a C program as these have caching where you read in blocks of data eg 128 or 256 or 512 bytes.
For a display, most thing are done in memory blocks, eg an icon or a picture. Even a line can be done as a block as you make either x1=x2 for a vertical line, or y1=y2 for a horizontal line.
I don't think you need many more pins. There are so many ways to get more pins - in theory each of the Y0-Y6 outputs of the 138 could select a group of 28 propeller pins and that is without even adding latches.
I don't know about the eprom thing. What is that trying to do that you can't do with the SD card and the ram?
The board looked a bit bare so I thought I would add TV, VGA, Keyboard, 8 generic latched outputs and 2 I/O pins. Easy to add more of these sorts of things. Also easy to leave out those parts. The 244 is possibly not necessary but I was worried about those low value resistors loading up the prop pins and slowing down the memory read/writes so I added that chip to isolate them. The VGA/TV display would blank during memory access which is not ideal, though you could be cunning and combine memory access with a VGA cog and do a few blocks of memory after a screen has been written.
On the other hand, with a touchscreen you may not need TV or VGA. It does give backwards compatibility to other designs though.
Kudos to averagejoe for persevering with this. It is a very clever design and it is the way it frees up propeller pins that is so clever. The reduction in part number and the decrease in complexity is amazing. ILI_RS, Mem_RD, Mem_WR, ILI_WR are now done directly from propeller pins.
@circuitsoft - checking it out now...