As a derivative of my previous curiosity question I had a followup curiosity. Is there a future and/or an application for the 6502, the VIC and the SID chips ? I know they are still produced, and used. For example, I remember the 6502 makes a perfect controller chip for small appliances. the SID for sure is still present in some "retro" sound synthesizer, although my guess is that it's just emulated. What about the VIC ?
Community wiki question as there's no correct answer.
I would look at 6502.org, including its list of commercial support and list of projects.
For example, I remember the 6502 makes a perfect controller chip for small appliances.
I dunno about the VIC and SID chips (special purpose video / audio chips are different than a CPU), but I don't see any reason to use a 6502. There are tons of cheap low-power microcontrollers (e.g. Microchip PIC, Atmel, TI MSP430, etc) that are readily available, have more CPU horsepower than a 6502, have useful peripherals (ADCs, UARTs, built-in oscillator, etc), and have real-time debugging features. Why use a 30-year-old microcontroller?
I would think their future is limited. I don't know what kind of quantities are still being produced but you have to figure even the 486 is probably being produced in far greater quantities than the 6502. So even though the 486 might be overkill for some applications its availability determines its price thus making it more attractive to device manufacturers.
Then, as you say, the functionality of the 6502, VIC, and SID chips are easily emulated these days--even in software. So that might drive the demand for those chips down since its probably cheaper to emulate.
Cost means it still sells millions of units each year. 6502 is cheapest 8 bit CPU; doesn't have 6 month lead time like Stm8, braindead memory model like pic or 8051 or overpriced like avr, pic, msp430. To go cheaper you have to go 4 bit which is very limited. Admitedly arm chips like stm32f030 are only a few cents more but there is a company called Walmart that asks for products to be as cheap as possible so manufacturers cut cents of costs.
Related
I am a mathematician and not a programmer, I have a notion on the basics of programming and am a quite advanced power-user both in linux and windows.
I know some C and some python but nothing much.
I would like to make an overlay so that when I start a game it can get info about amd and nvidia GPUs like frame time and FPS because I am quite certain the current system benchmarks use to compare two GPUs is flawed because small instances and scenes that bump up the FPS momentarily (but are totally irrelevant in terms of user experience) result in a higher average FPS number and mislead the market either unintentionally or intentionally (for example, I cant remember the name of the game probably COD there was a highly tessellated entity on the map that wasnt even visible to the player which lead AMD GPUs to seemingly under perform when roaming though that area leading to lower average FPS count)
I have an idea on how to calculate GPU performance in theory but I dont know how to harvest the data from the GPU, Could you refer me to api manuals or references to help me making such an overlay possible?
I would like to study as little as possible (by that I mean I would like to learn what I absolutely have to learn in order to get the job done I dont intent to become a coder).
I thank you in advance.
It is generally what the Vulkan Layer system is for, which allows to intercept API commands and inject your own. But it is nontrivial to code it yourself. Here are some pre-existing open-source options for you:
To get to timing info and draw your custom overlay you can use (and modify) a tool like OCAT. It supports Direct3D 11, Direct3D 12, and Vulkan apps.
To just get the timing (and other interesting info) as CSV you can use a command-line tool like PresentMon. Should work in D3D, and I have been using it with Vulkan apps too and it seems to accept them.
I'm going to deploy new paid app to appstore. This app will connect to our server and download some data (pretty big sometimes).
I'd like to know, is there any way I can check (on server side), that request is going from app, which was really paid (not stolen).
I know that anybody can buy app once and then distribute it (and guys with jailbreaked phones/pads can install it easily). It may cause extra traffic from our servers, and we want to protect us from it.
Or may be I can somehow figure out, that request comes from one sold copy of app? In this case, I can restrict numbers of downloads from one copy, so if it will be widely distributed, it just stops works one day.
Any ideas?
I am copying this verbatim from an email I sent to the cocoa-dev mailing list a while back to someone who had your concerns. The numbers have probably changed, but my rationale still applies as to why I think it's a waste of time to even think about this sort of stuff.
Setting aside all the technical issues, do you have evidence that
jailbreak piracy is a large enough problem to justify you doing all this?
For one, while I don't have a percentage I'm quite certain that it is a
minority of phones that are jailbroken. I run with a pretty tech savvy
crowd and I know only one person who has jailbroken their phone, and I
am fairly confident that techies are more likely to go through the
trouble. (How many average users have the faintest idea of what it
means to "jailbreak" a device?)
Jailbreaking is probably more prevalent in countries and cultures with
less of a tradition of paying for software. But this leads to the
second point...
From your standpoint you (presumably) really care about converting
would-be software pirates into paying customers. If they can't use
your app on a jailbroken device yet don't buy it legitimately, you
haven't accomplished anything economically worthwhile. In fact, you may
be worse off because you lose the (admittedly small) possibility that
the would-be pirate will show off your app to others who might in turn
become paying customers.
So, your calculus ought to be something like:
(# users with compatible devices) * (% with jailbroken devices) * (%
interested in your app) * (% unable or unwilling to circumvent your
protection) * (% who will purchase your app when confronted with copy
protection) * ($ price per sale) > (increase in legitimate sales that
could be obtained by devoting development resources to product
enhancement, marketing, support, etc.)
Let's suppose that 250M compatible devices have been sold, with 150M
distinct users (assuming that there are many people who have replaced
devices or own iPad with an iPhone, etc.) Suppose 10% are jailbroken,
which is what some cursory Googling turns up. That gives us 15M
candidate users.
Now, unless you are writing Angry Birds, it seems unlikely that you will
appeal to any more than 1% of the user base. That leaves 150K users.
Maybe 80% are unwilling to circumvent your copy protection, leaving 120K
users. Now the kicker: how many are then going to want to actually buy
the app? Maybe 5%? That puts you at 6000 users.
So with these admittedly crude guesstimates, if you could gain even 6000
users (out of the 135M non-jailbroken user base postulated above) by
devoting your time and energy to anything else, you'd come out ahead.
Well there are many tries to detect, if a device is jailbroken. But most of them can be tricked out again. So there is no SAFE method of detecting a jailbroken device. But just search for "detect jailbreak".
Than you could send your result to your server (together with the data request) and decide, what to do. But think about the effort, as said by Conrad Shultz.
Anyway you can track, how many apps are sold and how many server requests there are. So you will have youre private statistic, how many copies of your app are stolen. You can upload an update for your app anytime, if it really will be a big problem in your case.
Do you know a SDR (Software Defined Radio) kit with a 2.4GHz ISM band (2400MHz - 2483.5MHz) transceiver?
I need to perform some software defined radio including customised modulation. Also the price for one kit should be at maximum $1000. I know there are some extremely expensive solutions out there, but that is unfortunately not an option.
Also a low delay from reception to transmission is necessary, thus the GNU Radio + USRP solution is not usable.
Update:
I have taken a closer look at the USRP solution. From previous experience with the USRP + GNU Radio software I initially completely dismissed it as a solution in this case. I did that because I need to implement a packet radio protocol, thus I need precise bit synchronisation between input and output, and I need low delay that would allow me to transmit the next symbol following a received symbol, with a rate of 1000 kBaud.
From experience I know that the GNU Radio framework as default uses streaming chains of blocks, with very little synchronisation between TX and RX. Thus I suspect that using the USRP I would probably have to work directly with libusrp, and avoid most of the GNU Radio software. Am I mistaken in this?
I would suggest taking a look at the GNU Radio (gnuradio.org) SDR toolkit. Several projects (such as this one) have successfully used it for Bluetooth research.
There also exists development hardware designed for use with GNU Radio called the Universal Software Radio Peripheral which, with a suitable daughterboard for 2.4GHz development, costs around $1000.
I'd like to second GNU Radio. Specifically you are looking for the USRP not the USRP2. The USRP2 is still in heavy development(and out of stock) while the USRP is a stable platform for GNU Radio. The USRP motherboard cost $700. The daughterboard transceiver you want is the RX2400(2.4-2.9GHz, TX=50mW). You can find both of these boards at Ettus Research
Update six years later: USRPs come in the sub-1000$ range (B200/B210), they have very strict synchronization (ADC-rate accurate timed commands can control sampling) and coherency. GNU Radio supports these features through the gr-uhd interface.
Describing latency is quite a bit more complex, because it depends much more on how you deal with the data coming from any SDR frontend -- really, frontend latency isn't usually the problem when you try to do your processing on a general purpose OS, which makes no hard real-time guarantees. However, many just "hide" the latencies elegantly by employing timed commands and letting the frontend get the data early enough.
I recommend HackRF One wich is a half-duplex tranceiver form 1MHz to 6GHz and also has huge comunity support but is half the price of USRP.
EDIT
You now also have LimeSDR. It has 2 Rx and 2 Tx MIMO full-duplex channels and it's cheaper than tje HackRF. The only drawback may be the shipping time because at this moment there's no stock so you will have to pre-order.
We have successfully been using a professional development platform from Sundance Multiprocessor Technology (www.sundance.com). They do have some very affordable 2.4GHz/5GHz RF front-end solutions with integrated ADC/DAC and multiple DSP/FPGA processors.
University offers: http://www.sundance.com/docs/mimo_lte_booklet.pdf
What sort of application can be considered to be the really business winner for automotive telematics applications related to image processing/computer vision ?
here are the criteria :
1. Innovative
2. Social
3. Fun.
Have you read the articles from the DARPA grand challenge winners?
DARPA site
Google Scholar
I believe the "DARPA Grand Challenge" style of automation meets your .1 requirement as there are plenty of innovation on that front.
But I still think that we are a good decade away from a fully autonomous vehicle, even though the technology is almost there. The main reason is that people are still very afraid of relenting control to the computer, even though it might be the safest choice.
The transition will be slow. More and more models will bring small chunks of automation, such as smarter cruise control systems (that's a big winner right now), autonomous parking (in the market for a while now) and anti collision systems.
Which brings us to your .2 and .3
The above mentioned systems are not fun, they are necessary [for increased safety]. Nowadays, Social Media and Fun don't really mix with driving because they distract the driver from its main task. In the future, when you're on the freeway in auto-pilot mode, you will be able to open your laptop and be free to do whatever you want, since computers will be always connected to the internet. So I don't believe the car itself needs to provide you that aspect of entertainment.
What I do believe it's a killer functionality for cars is the enhancement of intelligent comfort systems integrated with biometrics. Nowadays, cars already have things like personal keys that will make it adjust things like seat height and etc according to your preferences, but it would be much nicer if it could automatically identify who is the driver by some biometric feature (iris, etc) and adjust multiple parameters automatically. That's the end of the key. I'm not talking about seat and pedals adjustment, but transmission style (husband likes a more aggressive transmission), performance limiters (daughter cannot exceed 90% of posted limit... the car knows what the limit is according to where it is).
In my opinion, if you implement biometric recognition + autonomous navigation, the possibilities are endless.
Although none of the applications here use computer vision, they are probably the best once out there yet. They have received quite a bit of media hype.
Where would you recommend that I find a company to develop or buy a CD/DVD loading arm similar to: http://www.dextimus.com/
Preferably programmable via USB but if I only can get one with a serial interface that would be fine. Drivers dont matter - I can interface directly with the unit as my situation is very unique.
If you have some experience with electronics, you can give it a shot and build it yourself, like this or this.
I should add that the schematics and the source code are included, and in more details in the first project.
I suppose I might just shorten this by giving a list of resources first:
http://www.embedinc.com/ I trust this company to do good work. Expensive (actually, they are reasonably priced in the design community, but would be considered expensive by most hobbyists and individuals). Not great at people skills, but very very very good at what they do.
You should check out the various microcontroller communities and forums for hobbyists and professionals that can do this. Search for microchip, atmel, msp430, arm, powerpc, etc.
Sparkfun is a supplier to the electronics community - they have great forums where you can post your request, and you'll find people who might do it for fun with only the cost of materials. Might take longer, might not be as 'professional' or well packaged and delivered, but it might be your best low cost option.
There are many electronic design companies that could do this (for instance, I can do this sort of thing).
But there are many questions you haven't answered (and may not have researched) that could prevent success:
Is this patented?
What CD loading/unloading methods are not patented, are out of patent, or otherwise available?
What is your design goal - a one off just for you, or a device that can be built in the hundreds for industrial use, or a device meant for general office workers/consumers that is built in the millions?
Do you realize that this design qould surely cost mroe than simply buying one, if one is all you need?
As an example, assuming you don't need the nice enclosure and don't mind a 'prototype' look, just the mechanicals, electronics, and firmware design (no software on the PC) would likely be 100-250 billable hours for a design firm. At a cheap $90/hr, that's $9k to nearly $25k for one prototype. Add PC software and the nice enclosure, etc and you'll double that.
If you can find a local 'Make' group (techshop, GoTech, or similar) then you might be able to find a hobbyist that is willing to play with this idea for the cost of materials.
But if you define what your goal is, and give us an idea of your resources you may find a better answer.
-Adam
You can create a very nice simple solution using radio control servos. They come in many sizes, but even the small ones have enough torque to move a big arm to move a cd.
The real bonus with servos is that they normally have 180 degrees of rotation and internally have a variable resistor (rheostat) for positioning feedback. Positioning accuracy is normally within 1 degree of rotation which should be fine for a cd loader.
For picking up the CDs, nothing will beat a vacuum. I recommend a small battery powered vacuum cleaner. Funnel the suction into a 1/4 inch pipe. At the other end of the pipe a one inch diameter cup should provide more than enough lift from the small amount of suction.
As for the pile of blank CDs to be burnt, I would advise in moving the pile up rather than an arm down to it. probably having the top blank cd about 1/4 inch higher than the cd tray - By doing this, the arm only needs to rotate in one axis and the vacuum should be enough to suck the cd back out of the tray.
Now, for the electronics. For the servo control I suggest an rs232 serial servo controller. I've used the one from http://www.basicx.com/Products/servo/servo8t.htm as it also gives back torque information from the current draw.
For the low sample rate digital i/o, i suggest (for windows) inpout32.dll which is a dll to give you direct access to the bits of a parallel port. This will allow you to turn on the vacuum at the correct time and possibly sense when cd's have run out. Note that a parallel port can sink more current than it sources so for outputs you should connect to the 5v power line and set the output pin to 0 to turn on the output and 1 to turn it off.
The other nice option, which is very, very simple to interface and very cheap is to get hold of a picaxe from http://www.rev-ed.co.uk/picaxe/. These use a very simple programming language (a BASIC spin off) allowing you to read serial data in and control the servos and digital I/O on one chip. Last time I used one, the language was a bit simple - if statements had to jumped labels, else didn't exist.
If you do use a microcontroller and servos, it is best to use a dual voltage power supply as servos are noisy and can cause the microcontrollers to reset.
As for switching loads such as the vacuum on, you'll need to use a mosfet or (if money is no object) the simpler option, a solid state relay.
All digital inputs you use on the microcontroller should be pulled either to +V or ground with say a 5k resistor so they never float.
I cannot stress how simple and cheap the picaxes are. They have a built in interpreter so although code space is minimal on the small 8 pin units, they are programmable via a simple serial lead.
Good luck. Once you get into automation control, you'll never be able to stop. I'm in the middle of building a 3 axis CNC router so I can cut parts for other projects (I tell my girlfriend it's so she can cut out xmas decorations!).
You might want to contact Aaron Shephard about his Florian project.
I've found that a really easy board to control stepper motors or sorvos are produced by phidgets - the API is incredibly easy, and available for a vast array of platforms.