hi all, I'm looking to mod 10+ PS1 consoles and to save money im planning to burn the chips myself. Is pic12c508 the correct IC to use for all types of PS1 consoles, Are there any variants that will work? Which Hex's do i use for what board? 1000x Ps1 PS1 slim?? Also I'm after a cheap programmer (just for these chips to start with), will this one do? http://www.ebay.com.au/itm/USB-PIC-...LH_DefaultDomain_0&hash=item1c39302e38&_uhb=1 It says it supports the chip, but has anyone ever used one of these? Thanks a bunch
I found an old thread with a link Bad_Ad84 posted and got the Hex Files, just to find out if the this is the correct programmer/IC combo...
Cheap Chinese programmers aren't the best, but worth a try - especially on a budget. You could always return it if it doesn't work and, at worst, you haven't lost much. Technically, if the manufacturer say it's supported, it should work.
cool thanks is $8.50 expensive for a pic12c508? thats on ebay... heres one i found in australia, never bought from them but its free post.. http://au.rs-online.com/web/p/microcontrollers/2340300/ will it work with the ps1?
You should buy PIC12C508A.. they are less than a euro a piece on eBay in China.. Alternatively you could get some PIC12F629.. They are cheaper and are reprogrammable. I bought this programmer last week or so.. still waiting for delivery: http://www.ebay.com/itm/310645139836 .. it should work with both those chips.. For PS1, use MM3.. for PS1 Slim use onechip.. For onechip you will need the PIC12C508A, but the MM3 has also been ported to PIC12F629 (just google for it)
If you're going the China route then might as well shop around for the best deal. 20 pieces for less than $12 USD: http://www.aliexpress.com/item/PIC1...-04-PIC12C508A-PIC12C508-DIP8/1796043162.html 50 pieces for $28 USD: http://www.aliexpress.com/item/PIC12C508A-04-P-8-DIP-12C508A-PIC12C508/1868257607.html
Nothing significant. The main difference is that there are 6 active bits in the OSCCAL register rather than 4 so the internal oscillator frequency can be adjusted more accurately. If you followed the Microchip recommendations and made sure not to clobber the instruction at the end of ROM and put a "MOVWF OSCCAL" as the first instruction of the program, this had no effect at all. The problem was that some badly behaved programmers clobbered the factory programmed instruction at the end of ROM, and this resulted in the calibration value being set to something undefined (but in practice often zero), which made the chip run at the wrong speed. The problem was more noticeable on the 'A' parts because they had a wider trim range, and this led to the erroneous conclusion that they were bad. If you are using a programmer that doesn't stomp on the cal value or are not using the IntRC osc there is no difference at all.
Now this has caught my interest, so do all the HEX and ASM files have these erroneous instructions? Or are the ones floating around the NET have this remedied or does it even matter in the end?
OK, I should start be explaining how the reset process works in these old PICs. When you reset them, they load the PC with all '1's, so the first instruction executed is the one at the end of memory - either 0x1ff or 0x3ff depending on the ROM size. When Microchip tested the device, they programmed this with a MOVLW instruction that loaded the correct cal value. So this is executed and then the PC rolls over to 0, and the user code starts with the cal value already in the W register. Microchip programmers are careful not to clobber this instruction - so if you select "chip erase" they will read it, erase the chip, and then program it back. Some of the third party ones are not so careful, and can end up erasing it. On top of this, some of the dumps include the last location, still holding the correct cal value from the chip it was dumped from. The Microchip programmers tend to ignore this, and use the one in the chip, but some others don't. The short answer is that the code should have a MOVWF OSCCAL at the start of the code or within the first few instrucitons (0x025) and should not have anything in location 0x1FF (for the 508) or 0x3FF (for the 509)
Hmm i see.. so what do you think on the programmer coolerking posted? I can't afford a pickit ATM, I don't mind having a programmer that is only good for one type of chip.
My guess is that it will probably be OK - because it's specifically designed for PICs. Most of the badly behaved programmers were the ones that supported multiple devices and didn't pay to much attention to highly PIC specific things like cal values. It's easy to check in any case - just get a new chip and read it, then look at the last location and make a note of what it is. Then program it and read it back again and see if it changed. If it did, you have a bad programmer and need to manually update the cal value for every chip you program - annoying, but not a big problem. The problem comes when you don't realize that's whats happening.