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 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?
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.
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.
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.
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?
I know, it hurts me too not to be able to get to the upper data [noparse]:)[/noparse] 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 [noparse]:)[/noparse] 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.
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.
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?
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 ?
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 ][noparse][[/noparse], 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,
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.
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.
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:
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.
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.
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.
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).
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 [noparse]:)[/noparse]
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 [noparse]:)[/noparse].
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.
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-ESDwith mini-wave tip (about $100).
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
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.
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
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.
Comments
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
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.
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
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'
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.
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'
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.
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'
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
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 ][noparse][[/noparse], 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
Andre'
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
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
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'
Anyway, the new boards came today, I will see how they work, we are getting very close now.
Andr'e
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
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 [noparse]:)[/noparse]
Andre'
Andre'
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
Post Edited (Paul Baker (Parallax)) : 3/13/2007 12:47:02 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
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
Low power SD Data Logger www.sddatalogger.com
SX-Video Display Modules www.sxvm.com
Coming soon! Propeller based OSD module www.hittconsulting.com
·
Andre'
www.solderconnection.com/visioneng_mantis_fxuni.php?PHPSESSID=e894899480a2e0ba8c16c2cef5fb0099
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
Mahjongg
www.heinc.com/xytronic/379.html
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.