PDA

View Full Version : Hydra sram card comming soon...



AndreL
02-04-2007, 11:49 AM
The original HYDRA was going to have SRAM built in, but we decided to leave it out since Parallax wanted to show off the propeller as much as possible without any extra hardware. Anyway, I designed the memory expansion about 15 months ago, but only recently had time to start playing with it again a couple months ago, and pricing the whole thing. In any event, its all done now, so I will start the manufacturing phase very soon.

Any last minute requests, I can still probably get in if they are reasonable, so I am all ears. But, more or less its a byte wide system with a 3 pin control and clock, so there are only so many things you can do with that. A number of others have been working with memory expansion designs for the propeller and they all more or less look alike at the end other than the implementation and some of the features.

Thus,·what I am talking about are "easter eggs" on the card, I am planning on the SRAM itself, the controller, and of course the EEPROM, so this will be a "super cart" of sorts.

Also, I am open for suggestions for other add on cards people would like to see, if I get enough suggestions, I might take the top #1 suggestion and do it. I probably can imagine what people will say, but I want to see before I say anything, so I don't sway anyone's ideas --

Andre'
·

kelvin james
02-04-2007, 01:29 PM
A flash from the past, i see no one has looked at these lately, whether it is useful or not, i just thought i would remind people that they do exsist.


SAMSUNG Electronics to Produce Industry's Highest-density Smart Card IC with Embedded NOR Flash

CARTES 2004, Paris, France - November 2, 2004 : Samsung Electronics Co., Ltd., a leader in advanced semiconductor technology, announced today that it is preparing to mass produce a smart card IC with 1-megabyte (MB) of embedded NOR Flash memory (S3FJ9SK) the highest density available today.

The IC's higher data storage will enable the first widespread use of multimedia message service (MMS), as well as improved Internet access, increased phone book storage, more online games and other applications for 3G mobile handsets.

The new 1MB embedded NOR Flash smart card IC will be demonstrated in Booth Hall 3 no.3 C 29 at the CARTES 2004 exhibition held at Paris, France from November 2 through 4.

The embedded1MB NOR Flash memory smart card IC utilizes an ARM-based 32bit SC200 secure core, a 3-DES encryption standard and a crypto processor, enabling enhanced reliability, faster subscriber identification and more security for preventing the leakage of information.

Samsung also has an embedded 16Kilobytes (KB) SRAM to enable code designers to apply diverse programs, while simultaneously attaining significant performance enhancements. A built-in JAVA accelerator facilitates a JAVA-based platform, improving the speed up to 8 times.

The high-density embedded NOR Flash memory smart card IC supports operating voltages from 1.62V to 5.5V. The low power feature fully complies with the power consumption levels of the GSM standard. Moreover, memory management has been optimized because data programming and updating processes operate independently of one another.
With the introduction of this highly efficient smart card IC, Samsung now supports a full line of embedded NOR Flash memory smart card ICs from 192KB to 1MB.
The S3FJ9SK is available for sales in Europe.

Paul Baker
02-08-2007, 03:32 AM
Andre, this post may be a little too late, but I have a suggestion. At one point I was designing something similar using a second Propeller instead of CPLD/FPGA (before other more pressing issues bumped it off the radar screen), and one feature I was going to implement was 8/16bit pointer mode where the contents of the SRAM were used·to update the address into the SRAM. This would make linked lists and other pointer type data structures streamlined on the architecture. The 8 bit pointer mode is easy to implement, the 16 bit pointer would require an 8 bit internal buffer to preserve the pointer's address to get both parts of the new address. I don't know how helpful the mode would be for game design, but generally it can speed up such data structure addressing by more than 100%.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker (mailto:pbaker@parallax.com)
Propeller Applications Engineer
[/url][url=http://www.parallax.com] (http://www.parallax.com)
Parallax, Inc. (http://www.parallax.com)

AndreL
02-09-2007, 07:19 AM
Right, the pointer idea is a good one, but in the end, I decided that as long as you can directly/ranomly address the 1st 64K of memory use can do all your dynamic linked lists, trees etc. there, then from 64 up, it will work in more of a block streaming mode with auto inc/dec.

We will see how people use the SRAM card, if they really like it then I will build more of a memory controller with these nice features like you suggested.

But, once its done, I will send one to you to check out. I am sure parallax will probably want to sell these as well as an accessory with the hydra.

Right now, I am just trying to layout this little monster on that miniature card :) For all the buses, etc. I had to use a 100 pin CPLD to do all the interfaces, that doesn't give you a lot of room to work with for routing (at least if you want it to look nice).

Andre'

Dennis Ferron
02-09-2007, 08:40 AM
Anyone ever do that 6502 Hydra card you mentioned wanting to see, Andre? It seems to me that any 6502 card would also work as an SRAM card, if you had shared access to the RAM.

AndreL
02-10-2007, 09:11 AM
No, there are no cards for the hydra yet other than the ones I developed. But, hopefully people will develop cards and put them for sale. However, on the 6502 card. One thing you could do is out a 6502 microcontroller on the card, then use the byte wide interface to act as a conduit to memory mapped space on either machine for comms thru a shared memory as you mentioned.

Andre'

Bill Henning
02-10-2007, 12:36 PM
Hmm...

I strongly suspect that a 6502 emulator could be written to fit in one cog and run at around at 1-1.5 6502 MHZ equivalent. I used to do a LOT of 6502 assembly coding over 20 years ago...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com (http://www.mikronauts.com) - a new blog about microcontrollers

Dennis Ferron
02-11-2007, 01:09 PM
Well then someone's got to make a 6502 card then!

This week I been working on a Hydra 6502 card prototype; it's on my breadboard right now. I just finished debugging the RAM access and control logic, and I'm about to try jamming the 6502 with NOP's to see if the address lines cycle. Instead of latching the address lines for the RAM, I'm using the 6502 to address RAM for me.

It'll be another month before I can afford a Hydra, so I'm running it on a PropStick until I get my Hydra.

Yeah, you could probably emulate a 6502 on the Prop and even run it faster than the real hardware, but -blah- I'm just not a big fan of simulations! They're not real!

lnielsen
02-12-2007, 10:38 PM
Andre'

Sorry for the late response. Sometimes work gets in the way. http://forums.parallax.com/images/smilies/mad.gif Is there any chance you could have the card work with Phil Pilgrim' PropCAM http://forums.parallax.com/forums/default.aspx?f=25&p=1&m=131097 When I recently asked him the same question he seemed to thing it would require a custom CPLD configuration. It would be real cool if we could reconfigure your memory board to act as a video image buffer from his camera. His limiting factor seems to be Propeller memory which your board fixes. I would like to see stereo RGB vision for my robot some day in the future.

Len

El Paisa
02-12-2007, 11:01 PM
Is the procam for sale yet?

Paul Baker
02-13-2007, 02:42 AM
Len, since André·doesn't have access to one and he's likely itching to get the SRAM card into the hands of customers as quickly as possible, it's doubtful he would be able to do anything at this point, and the PropCam is a B/W camera.

El Paisa, André has nothing to do with the PropCam so he can't answer your question, but no it's not for sale.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker (mailto:pbaker@parallax.com)
Propeller Applications Engineer
[/url][url=http://www.parallax.com] (http://www.parallax.com)
Parallax, Inc. (http://www.parallax.com)

Post Edited (Paul Baker (Parallax)) : 2/12/2007 7:47:29 PM GMT

Lawson
02-14-2007, 07:05 AM
AndreL, will the CPLD on this SRAM card be re-programmable? I wouldn't want anything fancy, but having the CPLD programming pins easy to access would let crazy people tweek the memory card if they needed to.

Marty

AndreL
02-14-2007, 09:34 AM
I am glad you asked :) Of course, I always like to slip some extra functionality in there for really creative people, so the CPLD is re-programmable, there is a header port on the board, you can plug right into. Once the board is done, I will release the specs, CPLD, etc. so if you want you basically have a CPLD that has nearly every single I/O pin from the expansion port going into it then the interface to the SRAM, thus you can do whatever you want with it internally and give it other behavior. For example, with the CPLD dealing with 512K sram, that takes up a lot of space, but if you back off to 16-32K, then that leaves some room for some cool image processing or bitblitting you might be able to get the CPLD to do. Also, the board then doubles as a CPLD dev kit, and there are 9 leds you can control, so with the board, you can also experiment with CPLD programming as well, and just blink lights etc., so its a cool like guy :)

My local PCB makers are making it right now, should have prototypes back in a week, then maybe 1-2 more iterations and then we will be ready to manufacture and sell it. Thinking $39-49.

Andre'

JT Cook
02-14-2007, 09:59 AM
That is cool that you can reprogram the CPLD, what hardware do you need to do that?

AndreL
02-14-2007, 10:48 AM
You would need a programmer for the CPLD, but like most in circuit programmers you can make one with a parallel cable and some parts, or just buy one for $39-79, whatever they cost from your respective distributor.

Andre'

dr hydra
02-16-2007, 12:58 AM
Andre

When is release the SRAM card be sure to include a kick butt demo program. A little eye candy is always good

AndreL
02-16-2007, 07:06 AM
I will try, but my new philosophy is to get product out then deploy software later. Rather than hold it until all the demos are done. But, when I get the cards back, I will send one to all my demo coders, see what they come up with. However, a good demo takes 2-4 weeks, I don't think we want to delay the deployment by another month on top of all the other delays that are incurred with manufacturing etc. but, if I can overlap the delay with the manufacturing cycle of the full one then of course we will have some demos.

If I get some time I will write a 3D engine that uses the memory, but doubtful that will deploy with the card. So we will see what happens, but first thing is to get the card out there and then we can always add more stuff to the CD that it comes with :)

Andre'

Jasper_M
02-17-2007, 06:31 PM
Is the EEPROM the same (size) as on the standard Hydra cards? And is how does the SRAM access speed compare to the speed of Prop's shared RAM?

AndreL
02-18-2007, 05:18 AM
The EEPROM is 128K, and to access the SRAM, basically, you have to control the r/w line, then pulse the latch, so its about 5 operations or 5 instructions, that's about it, thus at the end of the day, its 1.5x as slow as the hub memory, since you can get one hub access every 16 clocks or 4 instructions. Its more or less the amount of time it takes toggle a pin and then pull the data from the data bus. The SRAM can go 100Mhz if you could drive it that fast, so the bottle neck is just the control from the propeller. But, if you want random access then you have to write the low and high byte address, which each also take 4-5 instructions, but once you use the post increment/decrement modes for block moves then the work is just selecting read or write, and pulsing the sram and looking at the data on the bus, or putting the data on the bus to write, so its as fast as it can go.

Of course, if you are doing multiple reads or writes, or this or that, you can cut down on I/O settings, but the bottom line is you will want to access the memory usually in a loop of sorts, thus you will take an address counter and have to write it to the port, then put the data there, then pulse the write latch, things like that. So although you can cut instructions in certain cases, there is a minimum amount of work that has to be done to any sram to get things in and out of it.

Andre'

AndreL
02-21-2007, 09:21 AM
The SRAM cards are back from prototyping, they look pretty cool :) Green for now, the final ones will be yellow I think. Anyway, I am reviewing the circuit before soldering the parts down for test, its all 603 SMD, so I need to lower my stress level before doing this. I am pretty excited, this will really improve the HYDRAs abilities for emulation, games, graphics, and languages. Also, anyone can buy this card, so all you need is a 20 pin header and you can plug it into your propeller projects as well


Andre'

Jasper_M
02-22-2007, 02:01 AM
Sounds good enough :) . Maybe you could get even more speed with counters (if someone would require higher speed...)

AndreL
02-24-2007, 02:33 AM
The counters aren't the problem, the SRAM controller goes much faster than the propeller does, but its simply the fact that the propeller has no external bus interface, so you have to go thru the steps of accessing memory virtually by puttting down and address, performing a read or write, etc. and have all the steps. When you say:

move x,y

With a processor with an external bus interface, it does all the work at the atomic level with the bus, but when you have to simulate a an external bus with data, address, and control, you have to control those signals state by state, this is why things are limited by the propeller not by the external hardware, it goes 400Mhz, and the memory 100+Mhz, the prop is going 20 mips, but the prop needs to do 3-5 things to "talk" to the memory that's where the bottleneck happens.

Jasper_M
02-24-2007, 04:08 AM
Actually I didn't mean the counters on the CPLD, but the ones on Propeller (CTRA/B). Maybe they could be used to request data automatically from SRAM, so you could skip one or two steps in ASM (if reading in a loop).

AndreL
02-24-2007, 06:15 AM
Yes, that's possible, we could set up a counter to pulse the read line over and over, each time the memory would put the data on the bus, you read it, increment your local pointer, then by the next 4 cycles and you come to read again the counter pulsed the read line again. The trick would be to make sure to set the stuff up perfectly, but "should" be possible. This is why I have a single clock line to the sram for "do it", this way if we can work out to control it with a counter out put, we set teh counter to pulse every 4 cycles then sync it to the read, so that he read happens in the middle of the pulses and we should be able to remove the

pin out = low
pin out = high
pin out = high

Sequence to pulse the clock line on the memory.

Andre

Jasper_M
02-24-2007, 03:29 PM
Okay, thanks for your replies : ). I can't wait to get my hands on the card... even though I have very little free time in my hands now... By the way, are you going to release the card along with a bitmapped video driver? Or will the code be released later or do we have to code all ourselves?

AndreL
02-25-2007, 09:55 AM
Maybe, its just a matter of time, I would rather put the card for sale ASAP, then add more software to the CD as I develop it.

Andre'

AndreL
03-02-2007, 07:13 AM
Status report, the SRAM cards came back and with a couple noise issues resolved seem to work 100%, we are going to continue to test them, running billions of iterations, forward, backward, random access, etc. to see if we can get a single bad bit, but so far, with billions of memory accesses, looks good. So sending out another prototype with a little better layout, and fingers crossed this next iteration should be ready to go. Usually it takes 4-5 iterations to get it perfect, but looks like this one will only take 2 iterations.

End of next week, the next PCBs should be back and we will know more then.

Now, just need to decide on the color :) I think yellow PCB with black lettering would look slick.

Andre'

mahjongg
03-02-2007, 08:24 AM
Andre'

Exciting stuff!

Could you say something about the programmer interface and it's capabilities yet?
I am very curious about them.

Also, do you think your memory expander is flexible/fast enough so that a COG can use it directly as a frame-buffer for generating a high resolution and high color mode video signal? That would be fantastic!

For example a completely unencumbered (no color limitations) 256x192 by 96 color PAL/NTSC composite signal driver, and a 1024x768 by 64 color VGA signal driver should both be possible if the COG can get data from the memory expander fast enough. That is, unless there is something in the video shifter logic, or the COG's execution speed, that prevents these modes. I am not aware of all the limitations or the Propeller yet.

One trick you could use is to use two COG's. One that does the even, and another that does the odd pixels. of course the COG's must be extremely well synchronized to pull this off.
But I thought of one way to do this. Lets say we have two COG's, a "master" and a "slave". Both are loaded with a (each slightly modified) copy of the new TV driver, and each routine would have a slightly different "prelude" routine, that is used to synchronise (start at exactly the same time) the TV drivers. The "master" COG routine must read the system counter, and add a reasonable value to it, and then "publish" this "future time" value for the slave cog through the 32k main RAM, along with a "flag" to tell the "future time" value in RAM is valid. The slave COG, in the mean time, could wait for this flag to become 'true', and then read the "future time" value. Then, both master and slave should wait for this "future time", and at that exact time continue execution. The result is that both COG's continue with their copy of the TV driver at exactly the same time!

I understand the video hardware supports 96 colors without too much trouble in composite video mode (and a bit more with some trickery), and can generate a 6-bit color RGB signal in VGA mode.

Also, it's a pity the SPIN interpreter can't be re-written to read it's byte data directly from your external memory, that would truly be a great improvement.

P.S.
My Hydra is working fine, and your book is great... I think I am in the market for your memory expansion soon.

Martin (Mahjongg)

Dennis Ferron
03-02-2007, 11:48 AM
mahjongg, having just completed some (unrelated) hacking on the tv.spin driver, I'd like to propose a different solution to using an SRAM card as video buffer. Instead of having two video cogs and trying to synchronize those, still use 2 cogs, but have one video cog and one memory fetch cog. The video cog would have two line-buffers in hub RAM. One line would contain the pixels currently being scanned onto the TV or VGA monitor. The other line would be filled by the memory-fetch cog. Every time the video cog completes a line, it would change over to the line buffer recently filled by the memory fetch cog, and the memory-fetch cog would take the line buffer discarded by the video cog and fill it as fast as it possibly can from the SRAM card. I don't know the exact speed specs on the Hydra SRAM card, but I am 90% certain it'd be fast enough to do this for VGA, and 100% certain it would be fast enough for TV.

I think having a video cog and a memory fetch cog would be easier to synchronize because the tv.spin driver could remain mostly as it is now, and the memory fetch cog would be very simple to implement and would require only h-sync and v-sync messages.

Actually the Spin interpreter COULD be re-written to get it's data out of external memory. If you can write a Propeller emulator (on the PC) that interprets Spin code, then you could also roll your own Spin interpreter Propeller assembly. But I'm sure it's no simple task.

AndreL
03-02-2007, 01:39 PM
If you look at our demos, we use n cogs to fetch memory and fill a raster line then one cog to render the cog, so make sure to take a look at our drivers that already do this massively parallel rendering. And yes, the whole idea of this is to use it as a frame buffer, it can go much faster than the cog can, so the cog will be the bottleneck, not the memory.

And the programming interface is just a couple control lines and a clock line to "do it", 0-64k random access, 64K-512K linear increment/decrement access.

- Load low 8-bits of 19-bit address
- Load high 8-bits, clear upper address lines of 19-bit address
- read mem (optional post increment/decrement), parallel byte read at current address
- write mem (optional post increment/decrement) parallel byte write at current address

Lastly, the spin interpreter is already so tight , nothing more would fit probably, so a better thing would be to KILL a few functions that no one cares about, use the code space to implement external SRAM memory access functions OR use the code space to augment the normal memory addressing, so anything over 32K maps to the external RAM --

Andre'

Jasper_M
03-02-2007, 04:40 PM
So loading a 19-bit address is impossible, meaning that the upper memory can't be accessed randomly? If that part of the memory is used as a frame buffer, that'd mean that the whole frame would have to be re-painted on a VBLANK or alternatively do some very inefficient read-looping to be used to get the pointer where it should be (here the prop counters would be useful to increment the counter as fast as possible)?

mahjongg
03-02-2007, 08:18 PM
Dennis,

yes using one COG as a "data reader", and another as the "video renderer" is a good idea, and would simplify the code significantly.
I also considered such an approach, but concluded it had one significant drawback.
All the video data has to pass the video data from the "data reading COG" to main memory, and then from the main memory to the "video rendering COG". So all the video data data has to go through the HUB, twice!
Because you need to wait for HUB access for each word transferred this is a significant bottleneck.

If you want to create a video signal with a very high resolution, and six (or seven for a TV signal) bits per pixel, you need a very high data troughput. Actually, its probable you can't use only six bit per pixel, because it's probably too time consuming (in assembler instructions), and impractical (for line drawing routines etc) to "pack" the six bits, four at a time in three bytes. So you will propably need to just put the six bits in a byte, and "trow away" the opper two bits. So you end up with one byte per pixel.

This means that if you want to display a picture in 64 colors (using a byte per pixel) and using a resolution of 1024 x 768 and a refresh rate of 60 Hz, you need to transport 47.185.920 bytes (47 megabyte!) per second!
Actually, the burst throughput is even more because of the fact that this simple calculation does not account for the the time periods during which blanking and sync pulses take place.

By using the two COG for video rendering (each COG reading video data directly) we gain two things:

a) The pixel bandwidth for each COG is halved (to "only" 23.5 Megabyte per second).
b) data can be transfered without going through the HUB bottleneck at all.

Then again, maybe trying to use a 768 Kilobyte video buffer is a folly in itself, and perhaps the COG's assembler instructions simply can't handle such transfer rates.

Perhaps it would be more resonable to try to write a 256x192 64 color per pixel TV driver, which would need 48K RAM. For that you might be able to use the "data read" "render video" two COG approach.


Regarding rewriting the SPIN interpreter, I thought the SPIN interpreter was a closely guarded secret. As I understand at least one person painstakingly tried to reverse-engineer the byte-code so he could write his own compiler, because he did not have access to the source code of SPIN to see how it worked.


Andre'

Sorry, I have not had the time to look at most (source codes of) demo's. Although I was planning to have a look at the code of the shooter demo that seemed to use sprites over a scrolling background. I assume that a second COG is used to generate the sprites.
Also, I assume that two different video rendering cogs would be nice to create a parallax http://forums.parallax.com/images/smilies/smile.gif scrolling playfield, but I am not aware of any of your demo's doing that.


There are still a few things I do not understand about your programming interface, let me see if I have this correct:

You use two I/O bits for control lines to select one out of four functions, and a third I/O line for a "go do it" clock pulse.

The four functions selected by the two bits are as listed in your last post.

1 - Load low 8-bits of 19-bit address
2 - Load high 8-bits, clear upper address lines of 19-bit address
3 - read mem (optional post increment/decrement), parallel byte read at current address
4 - write mem (optional post increment/decrement) parallel byte write at current address

What I do not understand is how you can select between reading (or writing) with or without auto increment/decrement, and how you can discriminate between auto increment and auto decrement. It seems you need another access mechanism for that.

Also, are you really implying that only the lower sixteen bits of the 19 bit address are directly settable?
It implies that to reach the last byte of the memory you need to generate 524.288-65.536 = 458.752 (dummy) read actions?

Well... You could use the memory above 64K for a (linear) video frame buffer, and the 64K memory below for all other things, but not having direct access to 87% of the available memory (448K of the possible 512K) is a very big restriction.

Please tell me that I'm wrong about that, if you can set the increment/decrement/neutral mode somehow, why not the ability to set the three upper address bits?

Martin.

AndreL
03-08-2007, 12:31 PM
You load a program into the CPLD at boot that describes the behavior, and other than using sequencial states to load all 19 bits, there aren't enough i/o lines to do it. The lower 16-bits needs to be wicked fast and the ability to load only the low or only the high byte not in sequence, there is no way to select the last 3 bits with only 2 lines. Its load low, load high, read or write. Unless you want to sequence the writes you are stuck with that. But, it isn't a limitation, the first 64K is very fast, the remainder is just as fast as long as you are doing block reads or writes and you can use the counters to advance the memory pointer if you wish very quickly.

Andre'

mahjongg
03-08-2007, 11:11 PM
Dear Andre'

Please do not interprete my remarks as trying to criticise your design decisions, I can clearly see why you chose to do it this way.

Do I understand correctly that when loading the CPLD (at boot time) you choose whether you want to auto increment, auto decrement, or do nothing with the address counter after a read or write cycle?
I presume normally auto increment would be the most wanted option, so probably the CPLD would be booted with that option.
But it's a pity that this behaviour cannot be changed quickly (without re-loading the CPLD), because it means (among other things) that not all variations of blockmoves can make use of the auto increment/auto decrement feature. For example in the cause the CPLD is programmed to auto increment, this would happen if you try to move a block of memory downwards (to a lower address) while source and destination of the blocks overlap.
In that case you need to set the whole address again for each read, and each write cycle.

The re-programming feature of your memory card is a great feature, it means there are many ways to improve the design afterwards, just by changing the CPLD software.

I have an suggestion for an alternative memory access protocol, and hopefully the CPLD is flexible enough to implement it.

at the moment you have the following implementation of the CPLD logic:

- Load low 8-bits of 19-bit address
- Load high 8-bits, clear upper address lines of 19-bit address
- read mem (optional post increment/decrement), parallel byte read at current address
- write mem (optional post increment/decrement) parallel byte write at current address


My suggestion is to change this to the following:

- Write command/configuration nibble (lower four bits of I/O port) to two two-bit latches inside the CPLD
- Execute the command as set by the two-bit acommand latches, then reset the command latches to '0'.
- Read from memory with optional post increment/decrement (as set by the configuration bits), parallel byte read at current address
- Write mem with optional post increment/decrement (as set by the configuration bits), parallel byte write at current address

The command/configuration nibble would have the following data structure:

The lower two bits (D0 and D1) are stored in the 2-bit "command latches" and describe the "command" as one of three options:
00 = Load low 8-bits (bit A0 to A6) of 19-bit address
01 = Load middle 8-bits (bits A7 to A15) of 19-bit address
10 = Load high 3-bits (bits A16 to A18) of 19-bit address
11 = not used

The upper two bits of the nibble (D2 and D3) are stored in the 2-bit "configuration latches" and describe the "auto increment/decrement configuration":
00 = Do not auto increment or decrement after a memory access cycle
01 = Auto increment after a memory access cycle
10 = Auto decrement after a memory access cycle
11 = not used

I understand that purely for 64K access there is a small price to pay for this flexibility in that you need more I/O commands to set the upper 8 bits of an absolute address, but for memory above the 64K limit access is now (almost) just as fast as that for memory below the 64K limit.
I suggest to write the software so that address latches will only be set when their contents change.
because the command bits are set to zero after the command is executed the command does not have to be set when only changing the lower b-bits of the address.
And because this will normally be most often the case this will mean that setting the address with my protocol is most often just as fast as with your original protocol.
Also the auto increment/decrement method can now be changed on the fly.

Perhaps you like my idea, in that case please feel free to implement it, you have my permission to do so.
Consider my idea gratis advice.
Then you can give the user the option to boot the CPLD with either of these two access protocols.

Mahjongg

AndreL
03-09-2007, 01:43 AM
Already thought of that exact model and 100 others a year ago, there are only so many ways to do this, so its just a matter of picking one, prioritizing the goals and doing it. But, I want the faster access and page mode memory access to be blistering fast. I don't want to load then execute a command this literally slows things downs 25-30% which all I care about is speed here in the first 64k. The software is where the brains will go, that is, you know where your memory blocks are and you manage them as fast as possible above 64k. Its a tough decision, but speed is the most important, 64K is more than 99% of all computers from the 80's, so I think the first step is to get some decent memory on the propeller/hydra, see where that goes. But, since graphics are what I want to do fast, I need to get to things as quickly as possible, the act of loading the command can slow things down too much if you keep having to move around in data structures for example.

Bottom line is when it comes to graphics SPEED is all that matters, one cycle can be the difference between somehting working and not. So I choose speed.

But, as you mentioned the CPLD can be re-programmed and other behaviors can be programmed in, but its pretty tight and not "easy" to fit programs into it.

Andre'

mahjongg
03-09-2007, 05:09 AM
Okay, fair enough I suppose.
I am only trying to be of assistance.

You are right, there are a thousand ways to do this.

Perhaps it would be a slight optimization if the memory driver did test whether the upper address byte has really changed before trying to set it. Of course it depends on how the memory will be used whether doing this will be beneficial for the access speed I suppose. But if it's chugging through the memory mostly executing instructions within the same 256 byte region, or reading video data from within the same 256 byte region, then the extra test instruction(s) might be worth not having to do several instructions to set the upper byte. Just an idea.

Anyway even after the board is out, there will be people who want to try to experiment with it, and I only wanted to point out an alternative command system might be possible, and more efficient in some cases. So the user can choose himself which one to use.

You are right 99% of the very first old home computers did not have more memory than their 64K address space allowed, so for these your design is optimal, and I cannot think of an obvious improvement on it that does not carry a small speed penalty for accessing the first 64K.

It just hurts me that accessing the bulk of the rest of the ram is so inefficient, and only somewhat useful as a block based external storage device. Even with the counter clocking the counter in the CPLD interface to "fast forward" to the needed address, it might be many hundred thousands of clock cycles. But of course it will still be faster than, for example, a hard-disk, let alone for emulating a floppy disk with it.

But let me re-state, i think there is one purpose for which the memory above the 64K border is great, namely for a linear video frame-buffer.
Not so much for the current tile based TV device perhaps, too many non sequential memory accesses are needed. but I can imagine a very high resolution VGA driver that can display the contents of this very big buffer simply by outputting the sequential bytes from the memory above the 64K border to display a complete frame. Because the COG can directly access this memory without going through the HUB bottleneck it might be that the external memory is just as quickly accessible as main RAM. The Video driver simply reads sequential bytes as needed and resets the 19-bit address to the start of the upper memory before each frame.

Yeah, I know designing with a CPLD can be a pretty daunting task. Can you tell me what the exact type of CPLD is, maybe I can have a look at it to estimate if fitting my command system in it is remotely possible?

Mahjongg.

AndreL
03-09-2007, 06:41 AM
I know, it hurts me too not to be able to get to the upper data :) Just a few more lines and it would be perfect. Anyway, this is just the first version and the point is to GET IT DONE :) Engineers are GREAT at talking and theorizing, but not very good at shipping product. So I have to be able to ship product and right now I just want to get this done, there are a billion steps from "concept" and "prototype" to selling products on the website, so let's see how this one goes. Then we can always do another, plus the CPLD is re-programmable, so you can do what you want if you can fit it in there, but that is no easy task due to floorplanning, etc. the act of adding "1" to large numbers in a CPLD kills realestate. If I got to a FPGA, then we have to redesign, is 300% more for the chip, then we push my price point I am shooting for.

But, point is 64K is more than enough to do a lot of damage. And everyone can always use the upper memory as linear frame buffers and read and write in a single stroke, there will be no penalty for this, so with the correct programming, everything will be VERY fast.

Andre'

mahjongg
03-09-2007, 08:41 AM
I agree Andre, better is the enemy of good enough.

When I design something I also sometimes have to stop adding features, and just force myself in "board layout mode" ( I design the schematics, as well as the PCB for the products I design) so the design will finally be done.

Good luck with it, hopefully you can place it on the market soon, I hope it has a big influence on what can be done with the Hydra.


By the way, it occurred to me that it should be relatively straightforward to create a PC joystick interface for the HYDRA, all that is really needed are four capacitors and a DB15 connector (and maybe a handful of pull-up and safety resistors). Using the 8-bit port, four input bits can be simply connected to four joystick buttons, with 220 Ohm safety resistors in-between, (so you can't blow up the output port by outputting a '1' on a port that has a closed button which shorts the output to ground), and maybe four 10K pull-ups if necessary.

For the four analog stick connections (one for each "axis"), which are simply pot-meters to the power supply, you need a timer circuit that can determine how fast a capacitor is loaded by the current coming from the variable pull-up pot-meter. So my idea is to have a I/O port connected to one of the joysticks variable pullups, and to a capacitor (say 100nF) with the other end connected to ground. The algorithm to determine the pot-meter setting is simple. The I/O port is set to output and to low, so the capacitor discharges (again, a 220 Ohm safety resistor might be useful to protect the port, and also it would be prudent to put a 1K resistor in series with the pot-meter) after the capacitor has been discharged the I/O port is set to input and read out in a timing loop. The moment the input is read as high the timer count is registered, and it's value is the joystick axis (pot-meter) setting.
Implement this circuit four times, one for each joysticks "axis", and adding four button inputs, and you can use any standard PC-joystick with four axis and four buttons. A four i/O port version is also possible, for a joystick with just two buttons, and only the standard two axis design (no tophat control etc).

Maybe it would be a nice supplement for the Hydra, if nobody thought of designing it before.

Also, I think a hard-disk (IDE) interface might also be possible, using the same 8-bit port and three control bits, I can see how I could design one, but I don't see much use for it on a hydra.

Mahjongg.

AndreL
03-09-2007, 02:58 PM
The problem is finding oldstyle PC joysticks, both PC joysticks and Apple II oldstyle use the simple RC time tracking with 470K pots internally if I recall. But, the problem with this approach is that literally you suck up a ton of CPU time waiting in a count loop, so you have to be careful. Piece of trivia from developing pc games in the past...did you know that reading the joystick literally slowed the PC down by 10% !!!!!

The hydra already has controllers that it comes with, thus not much of an motivation for customers to buy yet another joystick interface, so I think a plug in ethernet card would be the next best thing to add, so people can get the hydra online. I don't know if anyone would use the IDE interface, its cool, but how many people would want to connect disk drive?

Andre'

mahjongg
03-09-2007, 08:10 PM
Yeah, i know most joysticks today use the USB interface. You need to go to a second hand shop to find an oldstyle joystick today.

But the hydra controllers are simple digital devices, not really comparable to linear joysticks. Its like comparing the NES controller to a gamecube controller.
By the way, somebody has figured out how to interface the gamecube controller to the Propeller, only the connector is a real problem. And what about the WII controller http://forums.parallax.com/images/smilies/smile.gif ?

I know the PC needed enormous amounts of CPU time to poll for the joysticks, that is one reason why they were replaced by USB versions. The IBM engineers simply copied the 555 timer idea from the Apple ][, including a relatively large capacitor because of the slow CPU speed op the 6502, that was a bad decision in hindsight. It meant that even when CPU speeds rose the same amount of time was needed to ways for the joystick interface to "time out". The capacitor could not be made smaller, becuase it would be software incompatible.

For the prop, it would mean at worst you use a COG to poll the joystick, that should not be too hard, of course you poll all four inputs at the same time, and use the system counter for the timing. If you choose small capacitors, the polling can be done very quickly.

Yeah, i thought there would not be much use for a harddisk (or CD-ROM) interface for the hydra, maybe Ill post a question whether there is a need for an IDE interface on the regular propeller forum. I did several IDE interfaces for microcontrollers (68HC11, ARM etc) so I know I can design one.

An ethernet interface would be neat, perhaps one based on the RTL8019AS, a very cheap chip, and not too hard to interface to. Only, you need a ton of software for it to do anything usefull. maybe a better approch would be to use an existing ethernet module,

Mahjongg

AndreL
03-10-2007, 02:21 AM
Something that would probably be popular that you could make is a SD/CF multimedia card reader, you can fit the mechanicals for both interfaces on either side of an expansion card, then basically its a software interface and that's about it.

Andre'

mahjongg
03-10-2007, 07:51 AM
Actually, I just finished the schematics for a project that uses both a Secure Digital Card interface, and a Compact flash interface.

Secure Digital (Multimedia card etc) is simple, even implementing nibble mode (instead of the slower SPI interface) is not that hard, and the latest FemtoBasic already implements the Serial Protocol Interface (SPI), which is even simpler. But Compact flash is a whole other ball of wool ! It's basically PCMCIA (PC-CARD), and even with a simplified interface (only supporting 8-bit) and power supply (only supporting 3.3V), and abandoning "real-IDE" mode etc. its still not simple. You need to support eleven address lines, eight databits, and a dozen control signals, all to a fifty pins interface connector. Also, what is there to gain? support for 8-Gigabyte instead of 2? Interface speeds might be faster in principle, but through the complex interface and the bulk of software needed, I don't think much will be left of the speed advantage in practice. The SD-CARD is really the best bet at the time. I can design the hardware interface easy (there is not much to design really, just directly connect the I/O bits and the insertion and write protect outputs to propeller I/O pins), the tricky part is software. Not my forte, by the way, I have done some Z80 programming and C programming for MSX systems for a game software house for a short period, but I liked electronics better.

You can buy a USB to memory card interface for a few bucks, but as we know playing "USB Master" is not simple, not that the hardware is too complex, but you need so much software, it's just not worth it. Maybe sometime I will stumble across a simple to interface controller chip that does the trick...

A better way to interface to a whole lot of devices might be to use a bluetooth dongle. Most of them can interface to a serial port for simple tasks (or to a codex if you want to transfer audio, but thats not very useful for us), and the module implements the software for the protocol stack. With such a bluetooth dongle you can connect to a whole world of interfaces. Many wireless controllers for example. How does connecting a XBOX360 controller to the Hydra sound? In principle it should be possible. Even a WII controller might be possible. Printers etc are often also no problem.

One interesting thing might be to try to find out how a dualshock playstation 2 controller interfaces to the playstation. If you can find NES connectors (neat trick by the way, I would not know where to get them, well from Taiwan obviously, but I have never seen any being advertised) maybe you can find playstation interface connectors too.

Still reading your book, great stuff, I am now at the chapter where you are explaining the HEL engine, and I am curious how your sprite driver works. The TV.SPIN driver is great, but I am not that charmed by some of it's limitations, four colors per 16x16 tile is great for backgrounds, but animations across tile borders might be troublesome, so I am burning to find out how you do sprites. Unfortunately I only have maybe energy for half an hour every evening to read your book, I have so much else to do...

Perhaps I can find the time in the future to write my own video engine, or maybe a interpretive game engine that can load a "chapters" of game data from the EEPROM, so I can re-create my favorite game of all time Jet-Set Willy, I have plenty idea's, but first I need to learn a lot more.

Mahjongg

AndreL
03-10-2007, 11:16 AM
If you want playstation connector, try lynxmotion, the only place on the planet you can get them other than a manufacturer.

Andre'

mahjongg
03-12-2007, 06:27 AM
Andre'

Funny, it seems that several people had the same idea, and one has already written code for the propeller and today someone placed his code in the main propeller forum here:

http://forums.parallax.com/showthread.php?p=637274

It seems to be an idea which time has come.

Mahjongg

Damien Allen
03-12-2007, 06:52 AM
Any update Andre' on the SRAM card?

AndreL
03-12-2007, 07:33 AM
Just waiting for PCBs back for 2nd prototype. Other than that its been here running tests for 2 weeks straight writing and reading in all the modes. So not a bit flip in 2 weeks solid, so I think that makes it pretty reliable.

Better get the cards back tommorow or tues, then build, then test, then maybe one more iteration, maybe not, so add 2 weeks if that happens, else then I have to write the docs, put the package together with demo and drivers to play with it send it to manufacturing in china and that's that.

Andre'

Michael Popoloski
03-13-2007, 02:34 AM
What about releasing a sneak-peak schematic for the Do-It-Yourselfers out there (like me http://forums.parallax.com/images/smilies/smile.gif)

Paul Baker
03-13-2007, 03:03 AM
André was at Parallax last week and had the SRAM card with him. It's not really a do-it-yourself product, everything is SMT and the CPLD is a 100 pin 0.5 mm pitch device (I dont believe there is a through hole equivalent of the chip). To implement it you would have to recreate everything he's done (board design, mounting, testing)·and it would take much longer than the time between now and when his is availible.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker (mailto:pbaker@parallax.com)
Propeller Applications Engineer
[/url][url=http://www.parallax.com] (http://www.parallax.com)
Parallax, Inc. (http://www.parallax.com)

Post Edited (Paul Baker (Parallax)) : 3/12/2007 8:11:13 PM GMT

Michael Popoloski
03-13-2007, 03:12 AM
Oh, I see. 100 pins? That seems quite excessive. Guess I'll have to wait then.

AndreL
03-13-2007, 05:20 AM
You need 100 pins since we need the address bus out 19 lines, control in, control out, data bus, this and that, clocks, resets, etc. And the rule of thumb with CPLD/FPGA, you can use maybe 50% of the resources before you get routing bottlenecks on complex designs, so we needed 64 logic blocks, but more than 32 IOs, the 32 IO model is 48 pin, so we had to go to the next size which is 100 pin and 64 IOs.

Anyway, the new boards came today, I will see how they work, we are getting very close now.

Andr'e

Michael Popoloski
03-13-2007, 07:18 AM
Yea, that's a bummer because I am trying to make my own video game system that is similar to the HYDRA, but with everything designed and created by me. Seems like soldering a CPLD would be just too much work / impossible for hobbyists.

Paul Baker
03-13-2007, 07:36 AM
You can do it, if you are aware of what you are doing and proficient at soldering. My first SMT board had a 100 pin CPLD (also used for SRAM expansion) and it was easier to solder than the SX-52 was (thermal capacity of the larger pins on the SX ended up causing more bridging than on the CPLD). With a good solder station, good eyesight, a steady hand and enough patience most SMT devices can be hand soldered (QFN and BGA are notable exceptions).

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker (mailto:pbaker@parallax.com)
Propeller Applications Engineer
[/url][url=http://www.parallax.com] (http://www.parallax.com)
Parallax, Inc. (http://www.parallax.com)

AndreL
03-13-2007, 07:37 AM
Well, not really, but its not easy. The bottom line is you have to have a VERY steady hand and have a couple chips to try with. But, with practice its not a big deal I have hand soldered 240 pin QFPs where the leads are like wisps of hair. However, the best thing to do if you want to do a lot of this high density surface mount stuff is to make a PCB with a bunch of high density footprints on it 44, 48, 64, 100 pin and then just get some really cheap QFPs that are $2-5 each and just solder them on to get practice or you can buy prototyping stuff from http://www.beldynsys.com/.

Also, I suggest wearing a 30x magnification lens over your eyes or using a magnifying lens with that kind of magnification. What I have found is that if you look at your hands thru a magnified lens then your feedback loop adjusts and you can actually move your hands at a much higher resolution, its pretty cool.

Anyway, if you want to make a system yourself them you can still fit multiple 22V12 GALs on there as DIPs or even try a 44 or 48 pin QFP which aren't bad if you feel like you won't be able to do the 100 pin'ers and up.

But, yes, this is an issue for companies like us and parallax, after prototyping with our CAD tools, someone has to solder these things together. Sometimes parallax send them out to people to be hand assembled a few at a time, we did that as well with XGamestations since they had like 180 parts on them and just took too much time. But, bottom line is that once you start working with FPGAs and so forth there is no way around building them. Sure you can use the dev kits to play with the parts, but at some point you want to make a real PCB and design them in, fab the PCBs and put the part on them. Like right now, I just got the PCBs back for the 2nd test rev of the SRAMs and I am looking at the 100 pin QFPs thinking, "I hope I have a couple of these left, since I will probably kill one to get warmed up".

So lots of time, money, goes into making these things with any of the high density chips. For example, I would like to use BGAs for products, but there are VERY hard to prototype. There are "tricks" to mount them, but if you mess up, you will probably get the part off in one piece.

Anyway, just start simple, try and do a 100% surface mount design (except for mechanicals) using 0805 parts and a couple small QFP or SOIC, TSSOP type parts for your logic stuff, see what happens. Then you can move to the 603 when you get really psycho :)

Andre'


Andre'

Paul Baker
03-13-2007, 07:41 AM
Hehe, nothing like 402s, I made a LCD breakout board with 402s and I sneezed causing the entire pile (10 in all) of 402s to scatter into the carpeting. I only recovered 4 of them and had to wait for another cut strip of them to be delivered. Lesson learned, I'll never design a 402 into another board,·OTOH·603s·feel much easier after that :).

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker (mailto:pbaker@parallax.com)
Propeller Applications Engineer
[/url][url=http://www.parallax.com] (http://www.parallax.com)
Parallax, Inc. (http://www.parallax.com)

Post Edited (Paul Baker (Parallax)) : 3/13/2007 12:47:02 AM GMT

Michael Popoloski
03-13-2007, 07:51 AM
I keep hearing things about getting a good solder station, but what is the difference between the cheapo ones from Radio Shack and the higher end models? Time I have a plenty, but the same cannot be said about money. http://forums.parallax.com/images/smilies/smile.gif

Paul Baker
03-13-2007, 07:56 AM
All the difference in the world, seriously. There are quite a few that will do the job, my favorite for the price and quality is the Xytronic 137-ESD (http://www.heinc.com/xytronic/137ESD.html)with mini-wave tip (about $100).

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker (mailto:pbaker@parallax.com)
Propeller Applications Engineer
[/url][url=http://www.parallax.com] (http://www.parallax.com)
Parallax, Inc. (http://www.parallax.com)

Bean
03-13-2007, 09:05 AM
I've mentioned this before, but the assemblers where I work routinely hand solder 0201 resistors. This is due to the fact that they are too small for the automated pick-n-place machine.

They look like pepper flakes. You have to wonder how they get them to the correct value ???

I can do 0402 if I have to, but I prefer 0603 or 0805 if I have the room.

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheap used 4-digit LED display with driver IC·www.hc4led.com (http://www.hc4led.com)

Low power SD Data Logger www.sddatalogger.com (http://www.sddatalogger.com)
SX-Video Display Modules www.sxvm.com (http://www.sxvm.com)
Coming soon! Propeller based OSD module www.hittconsulting.com (http://www.hittconsulting.com)
·

AndreL
03-13-2007, 10:16 AM
201 is nuts, you need really small hands :)

Andre'

mahjongg
03-13-2007, 06:55 PM
A stero microscope like this one helps a lot:

www.solderconnection.com/visioneng_mantis_fxuni.php?PHPSESSID=e894899480a2e 0ba8c16c2cef5fb0099 (http://www.solderconnection.com/visioneng_mantis_fxuni.php?PHPSESSID=e894899480a2e 0ba8c16c2cef5fb0099)

Also, a hot air soldering iron (with as low an airflow as possible), and a normal one, but with solder points with a hollow tip, (to hold a tiny drop of molten solder) a syringe with solder flux and another one with solder paste, solder wick, the thinnest no clean solder you can get (0.5mm or less) and last but not least a nice and sharp set of pliers.

If you have these, then even 201 resistors and 0.5mm pich QFP's are do-able by hand.

And of course tiny hands help too http://forums.parallax.com/images/smilies/tongue.gif

Mahjongg

Michael Popoloski
03-14-2007, 01:58 AM
So what would be the difference between the soldering iron Paul Baker posted, and this one from the same company, which is 50$ cheaper?
www.heinc.com/xytronic/379.html (http://www.heinc.com/xytronic/379.html)

Paul Baker
03-14-2007, 02:58 AM
The main difference is the temperature reading is not included on the 379, which isn't a critical feature. One thing to ask is if the mini-wave (part #44-510637) will fit on the 379, it looks like it will but ask (I suggest placing orders by phone, they are extremely helpful and friendly). The mini-wave is very handy when soldering SMT devices.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker (mailto:pbaker@parallax.com)
Propeller Applications Engineer
[/url][url=http://www.parallax.com] (http://www.parallax.com)
Parallax, Inc. (http://www.parallax.com)

mahjongg
03-14-2007, 08:06 AM
Yes, the "mini wave" is the "hollow tip" solder point I was talking about also. A tip like that is ideal for soldering SMT IC's because the little pit of molten solder can be used to wet a whole range of pins in one stroke. Any superfluous solder that shortens two pins can then be removed with solder-wick.

The 379 also seems to come with a metal solder point cleaner instead of a sponge, which generally works better than a wet sponge and you do not need to have a supply of distilled water to wet the sponge with.

Mahjongg

AndreL
03-14-2007, 10:39 AM
I don't think I know a single EE on the planet that actually uses distilled water :) I have used my drink on the sponge before in a pinch, the sugar carmelizing from the drink smells nice :)

Andre'

mahjongg
03-14-2007, 06:29 PM
Well you know one now http://forums.parallax.com/images/smilies/smile.gif, at our show we used to use distilled water, something to do with the calcium in te water as I understand it. In due time the sponges would become hard because of it. We now only use the metal cleaners (made out of brass "wool" or something like it) to clean our tips, works much better than a wet sponge.

Most drinks I can imagine you drinking would be heavy acidic (and contain a lot of caffeine) , so perhaps that helps to clean the points. http://forums.parallax.com/images/smilies/smile.gif

Mahjongg