How much money are you willing to spend (in USD) to buy parts/tools for starting electronics?
Nothing; I am a cheap a.
 8%  [ 1 ]
$15+
 16%  [ 2 ]
$30+
 25%  [ 3 ]
$45+
 33%  [ 4 ]
$60+
 0%  [ 0 ]
$75+
 0%  [ 0 ]
$90+
 0%  [ 0 ]
Money is no object to me
 16%  [ 2 ]
Total Votes : 12

Because the jumper wire kit is $5 whereas a spool of wire and a wire stripper cost more than $5.
Ah, that's cheap, then. I usually see prices of about £4 for a pack of 20 wires, which is hardly economical!
Ultimate Dev'r wrote:
Because the jumper wire kit is $5 whereas a spool of wire and a wire stripper cost more than $5.
It would still be way cheaper to strip and cut all the wire in the spool than buy the equivalent number of jumper kits, though.
KermMartian wrote:
Ultimate Dev'r wrote:
Because the jumper wire kit is $5 whereas a spool of wire and a wire stripper cost more than $5.
It would still be way cheaper to strip and cut all the wire in the spool than buy the equivalent number of jumper kits, though.


But the upfront cost for the kit is still too high; remember, this is a beginner's kit, if you will, so I'm going for the most bang for buck here Smile

On another note the jumper wires came in just now (they were shipped from MCM electronics, Newark's sister company).
Sigh... I'm still waiting for the CS 210 professor to give us the electronics kits that we already paid for... And I still don't know what is included in them.

Dev'r, any hints of what sort of projects you might be showing us how to construct with your kit?
Some ideas I have for projects:

Building a PIC/AVR programmer
Pacman/Pong (can actually play on your tv)
Hooking up classic game controllers to your pc/other consoles
Temperature sensor
Random USB stuff
Possible TI-related stuff

Also you might want to check out my del.icio.us bookmarks here for possible project ideas.
Ah, so that's what the single RCA connector is for. I didn't even think of video output.

I remember Ben Ryves made a circuit to output video from the TI-83+. Maybe we could do something with that? I know it took a lot of CPU cycles to output in proper NTSC, so there wasn't much speed left for game logic, but maybe if we move some logic to the microprocessor, we could use it like dedicated graphics hardware. The calculator could just output a message saying to display sprite #1 at (x,y), and the microprocessor could retrieve that sprite from it's own connected memory, and display it. Or something along those lines.
magicdanw wrote:
I know it took a lot of CPU cycles to output in proper NTSC, so there wasn't much speed left for game logic, but maybe if we move some logic to the microprocessor, we could use it like dedicated graphics hardware.
That's mainly thanks to the Z80 not being very efficient if we're counting clock cycles. You can get much better results even using a primitive 16F84 running at 12MHz.
benryves wrote:
magicdanw wrote:
I know it took a lot of CPU cycles to output in proper NTSC, so there wasn't much speed left for game logic, but maybe if we move some logic to the microprocessor, we could use it like dedicated graphics hardware.
That's mainly thanks to the Z80 not being very efficient if we're counting clock cycles. You can get much better results even using a primitive 16F84 running at 12MHz.


I built one his color pong version using an SX 28 a few years ago; very interesting project.
benryves wrote:
magicdanw wrote:
I know it took a lot of CPU cycles to output in proper NTSC, so there wasn't much speed left for game logic, but maybe if we move some logic to the microprocessor, we could use it like dedicated graphics hardware.
That's mainly thanks to the Z80 not being very efficient if we're counting clock cycles. You can get much better results even using a primitive 16F84 running at 12MHz.
Are you referring to how the Z80 packs multiple microinstructions into large instructions taking multiple clock cycles? I've only programmed assembly for Z80, but I'm curious what it's like developing for other processors.
Most of these micros are real RISC machines- they execute just under 1 instruction per clock cycle (some are more than one, but most are only one), compared to the Z80's 3-8-ish. So a 10MHz PIC is at least 4-6x faster than the 6 MHz z80 we're used to around here.

You can have a look at, say, the ATMega8 (as included in our parts list) datasheet, to get a great idea of how the parts typically work.
For PICs, only the PIC24-30 series are RISC (1 instruction per clock cycle); everything below the PIC24 series are not pipelined, so it takes 4 clock cycles to complete 1 instruction.

As for the calculator generating an NTSC signal, I believe benryves is referring to controlling the link port via TI-OS, which isn't as fast/accurate enough as directly accessing the I/O pins.
Ultimate Dev'r wrote:
For PICs, only the PIC24-30 series are RISC (1 instruction per clock cycle); everything below the PIC24 series are not pipelined, so it takes 4 clock cycles to complete 1 instruction.

As for the calculator generating an NTSC signal, I believe benryves is referring to controlling the link port via TI-OS, which isn't as fast/accurate enough as directly accessing the I/O pins.
Not pipelined, really? Even poor old 5-stage MIPS with no lookahead and no collision detection can manage not too far above one IPC.
KermMartian wrote:
Not pipelined, really?


Nope; one of the main reasons why I switched away from PICs (along with the banking problem and a host of other quirks). The only thing they have going for them is superior market share.
Guess I've been spoiled by Atmel, then. From the ATMega168 datasheet:
Quote:
Advanced RISC Architecture
– 131 Powerful Instructions – Most Single Clock Cycle Execution
– 32 x 8 General Purpose Working Registers
– Fully Static Operation
– Up to 20 MIPS Throughput at 20 MHz
– On-chip 2-cycle Multiplier
Ultimate Dev'r wrote:
For PICs, only the PIC24-30 series are RISC (1 instruction per clock cycle); everything below the PIC24 series are not pipelined, so it takes 4 clock cycles to complete 1 instruction.
RISC does not mean "one instruction per clock cycle"; the low-end PICs are still RISC machines. RISC emphasises a small number of simple instructions, which allows for a more efficient implementation than an all-singing, all-dancing instruction set.
Quote:
As for the calculator generating an NTSC signal, I believe benryves is referring to controlling the link port via TI-OS, which isn't as fast/accurate enough as directly accessing the I/O pins.
Well, we use Perfect At Last as opposed to Never The Same Colour over here. Wink Outputting a register value to a port can be done in eleven clock cycles on a Z80, and from memory (via OUTI) in sixteen. A PIC16F84 can output to a port in four clock cycles, and reading from memory first would take another four clock cycles. (Nearly all instructions take one instruction cycle, ie four clock cycles; as the PIC fetches the next instruction whilst executing the current one changes in program flow, eg a goto, take two instruction cycles).

Ultimate Dev'r wrote:
Nope; one of the main reasons why I switched away from PICs (along with the banking problem and a host of other quirks). The only thing they have going for them is superior market share.
Ah yes, "Register in operand not in bank 0. Ensure that bank bits are correct." Rolling Eyes
benryves wrote:
Ultimate Dev'r wrote:
For PICs, only the PIC24-30 series are RISC (1 instruction per clock cycle); everything below the PIC24 series are not pipelined, so it takes 4 clock cycles to complete 1 instruction.
RISC does not mean "one instruction cycle per clock cycle"; the low-end PICs are still RISC machines. RISC emphasises a small number of simple instructions, which allows for a more efficient implementation than an all-singing, all-dancing instruction set.


I meant to say pipelined, not RISC
How does one determine whether a machine is "pipelined" or not? The low-end PICs have a simple two-stage pipeline which allows them to fetch the next instruction whilst executing the current one; hence branching instructions take two instruction cycles as they need to re-fetch the next instruction.

(I'm not saying you're wrong, here, I'm just curious as to how one defines a "pipelined" architecture).
Quote:
pipelining In computers, a pipeline is the continuous and somewhat overlapped movement of instruction to the processor or in the arithmetic steps taken by the processor to perform an instruction. Pipelining is the use of a pipeline. Without a pipeline, a computer processor gets the first instruction from memory, performs the operation it calls for, and then goes to get the next instruction from memory, and so forth. While fetching (getting) the instruction, the arithmetic part of the processor is idle. It must wait until it gets the next instruction. With pipelining, the computer architecture allows the next instructions to be fetched while the processor is performing arithmetic operations, holding them in a buffer close to the processor until each instruction operation can be performed. The staging of instruction fetching is continuous. The result is an increase in the number of instructions that can be performed during a given time period.


Basically I'm using pipelined to refer to how a microcontroller processes an instruction; a RISC-architecture microcontroller generally breaks down the instruction cycle into 4 steps: fetch, decode, execute, store. For a PIC it takes one clock cycle for each step, whereas on an AVR it completes all 4 steps in one clock cycle. As a PIC does these steps in more than one clock cycle I consider it "non-pipelined".

For further reading:
http://www.electro-tech-online.com/micro-controllers/28882-pic-clock-4-output-why.html#post210193
http://www.electro-tech-online.com/micro-controllers/8854-basic-timmer-error.html#post43474
Ultimate Dev'r wrote:
Basically I'm using pipelined to refer to how a microcontroller processes an instruction; a RISC-architecture microcontroller generally breaks down the instruction cycle into 4 steps: fetch, decode, execute, store. For a PIC it takes one clock cycle for each step, whereas on an AVR it completes all 4 steps in one clock cycle. As a PIC does these steps in more than one clock cycle I consider it "non-pipelined".


Not necessarily.If it takes multiple clock cycles for a complete instruction to execute, BUT multiple instructions are "in flight" at a time (eg, one is being fetched while one is being decoded while one is being executed, etc...), then it is pipelined. Indeed, all a pipelined architecture means is that multiple instructions are in different stages at once. The number completed per clock cycle (or number of clock cycles to complete an instruction) is irrelevant as far as whether or not the architecture is pipelined.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
» Goto page Previous  1, 2, 3, 4, 5, 6  Next
» View previous topic :: View next topic  
Page 4 of 6
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement