| Electronics > Projects, Designs, and Technical Stuff |
| Cloning a Commodore PET-2001 |
| << < (9/33) > >> |
| CJay:
--- Quote from: GK on June 11, 2017, 06:07:39 am ---But something miraculous happened when I removed the blob of Blu-tak covering the glass window, allowing in light - all of the data magically uncorrupted itself! It's completely reliable too. So long as there is a certain amount of light shining on the chip all is fine, but if I progressively block out the light by lowering my thumb towards the window at a certain threshold the data goes whoopie. --- End quote --- Overburn it, I.E. if you have a programmer that will allow you to write data to a non blank device, write a copy of the original data to the chip. |
| MK14:
--- Quote from: GK on June 11, 2017, 02:52:29 pm --- --- Quote from: MK14 on June 11, 2017, 07:32:49 am ---The first thing that struck me about it was the 8 MHz crystal. Usually I'm use to it being some weird/complicated frequency, such as 3.579545 MHz or 4.43361875 MHz (yes, I know those are for transmission to TV's for NTSC/PAL), but usually I see funny numbers, such as 12.13643636797 MHz (hypothetical number), because it divides up to eventually make 60/50 Hz with the required number of scan lines and pixels, etc. --- End quote --- The PET used a combination of PAL horizontal timing and NTSC (60Hz) vertical timing. In reality, the horizontal (line scan) frequency difference between PAL and NTSC is so small it makes no difference. The major timing difference between the two standards is in the number of lines and the resultant frame rate. NTSC has a lower vertical resolution, so the frame rate is faster. The PAL line rate of 15625Hz is evenly divisible into 8M, while the NTSC rate of 15750Hz would have required an odd-ball crystal frequency of 8.064MHz. The 1MHz clock for the 6502 was derived from this 8MHz clock, and there are probably good reasons for wanting a round figure of exactly 1MHz here (simplified serial baud rate calculations, etc), so a standard 8MHz crystal master clock just makes sense. 8MHz was the pixel clock; a period of 125nS, giving 512 pixels for each complete 64uS (1/15625) line period. The characters themselves consist of an 8x8 pixel grid and for the 40 column display 320 (40x8) pixels (40uS) of those 512 total form the visible portion of each line period. The vertical resolution thus required for the 25 rows of characters is 200 lines. The display is non-interlaced, with ~260 lines total, of which all but the 200 are blanked, for a frame rate very close to 60Hz. The PET-2001 was provided a video and sync breakout for connection to an eternal 60Hz monitor, but I've not found any evidence that a 50Hz (PAL-timing compatible) version of the motherboard was ever made. Since most users probably would have never used anything but the internal monitor, I guess it's not surprising that CBM never bothered with a 50Hz version. Maybe if you lived in a PAL/50Hz region/country and wanted to connect to an external screen CBM may have offered to internationally ship you a 60Hz one! Living in a 50Hz land, I've designed my video generator board to operate at a 50Hz (actually 50.08Hz to be precise) frame rate, with 312 vertical lines. This just results in the vertical height of the 200-line visible portion of the display on a 50Hz monitor/TV being a bit less than the original 60Hz one as displayed on a 60Hz monitor/TV. In the final build I will provide line count and vertical synchronization decode logic for both 50Hz and 60Hz field rates, jumper-selectable on board. One thing to keep in mind though, is that in the 50Hz display mode, the PET will actually run proportionately slower in some operations. The vertical video blanking interval signal interrupts the CPU via one of the two PIA chips and clocks the internal timing module in the single VIA chip. When updating masses of characters on the screen in the "slow" update mode (such as scrolling a screen of text, which requires reading almost all locations of screen memory and writing back to row-shifted positions), the CPU does only what it can fit in during the vertical blanking periods. Also programs using the internal "real time clock" module of the VIA (actually just a presettable counter that overflows after accumulating 24 hours worth of 60Hz cycles) won't keep accurate time with the display in 50Hz mode, as they would have originally been written assuming a 60Hz clock. I'm not 100% certain yet, but it looks to me like the frame rate processor interrupt is handled by PIA#1 totally independently of the RTC of the VIA. For video RAM writing to operate as it should the processor interrupt must remain locked to the video generator regardless of the frame rate, but I currently cannot see a reason why I cannot simply get around the RTC issue by providing a separate (always) 60Hz clock source for the timer input of the VIA. --- End quote --- Thanks, that's amazing! (sorry for my slow response) I wondered if the 8 MHz signal was used to make the 1 MHz for the main 6502 system, and it was, so you answered my question, even before I asked it :) So 8 MHz = 8,000,000 / 15625Hz (PAL) = 512 = A nice binary dividable number, and a reasonable number of scan lines (including BLANK ones) to make a picture with. Nice/neat, and 8MHz crystals were probably cheaper (as it presumably was a mass market, popular frequency). The fact you are aiming for the Commodore Pet, is probably helped because it has few or no (I think), exotic or custom chips in it. Whereas the Commodore C64 (I think), has got a number of custom/exotic chips in it. Such as the graphics and nice sound generators, onboard. I think they must have been "cracked" to an extent, because there are many software emulators available for the C64 and similar computers. So I guess the information is out there, if you wanted to go to the trouble of reproducing them in an FPGA or something. But the Pet doesn't need such hard work, making it a much more sensible choice. Looking back, I'm amazed that something so slow (1 MHz 6502), relatively speaking and with so little memory, can be so powerful. E.g. We are at a few GHz rather than 1 MHz, 32/64 bit instead of 8 bits, many instructions per clock cycle instead of one or more cycles per instruction, and many cores rather than a single core etc. Also 8K (typically) of ram, instead of many gigabytes of Ram. Yet the space invaders and Chess were nice games, and fairly powerful programs could be run on it. Anyway good luck with your project :) |
| MK14:
--- Quote from: GK on June 11, 2017, 03:24:00 pm --- --- Quote from: MK14 on June 11, 2017, 07:08:42 am ---I see. Yes, long term (decades) uncovered UV windowed EPROM's, are suppose to be in significant risk of dataloss, I agree! --- End quote --- The funky UV-EPROM behaviour has now been solved! When an EPROM is erased all bytes attain a value of $FF. It appears that all those years of storage in almost complete darkness without the window covered brought my EPROM to the very precipice of total erasure. What I was seeing on the screen (and you are literally seeing the individual bits of whole bytes here), with those bytes randomly alternating between $FF and the programed values were bytes that couldn't make their mind up if they were erased or not! It's curious to note that there was a hysteresis-like effect, where, initially, the application of light through the window for a short time actually restored the unstable data, but guess what? I went out for dinner this evening neglecting to stick that blob of Blu-Tack back over the window and now my EPROM is giving me nothing but $FFs! Well F me, now I'm screwed until my programmer turns up. --- End quote --- I would imagine the "Cells" of the EPROM are like tiny capacitors, which have (unfortunately) lost most of their charge, over the decades and maybe because of the uncovered window. So the (part) analogue circuitry that reads them, deciding if it is a logic 1 or 0, is probably having a very hard time, as they are extremely marginal by now, it seems. So (as other(s) in this thread have said, anyway), the slightest change in temperature, voltage, light level while the UV window is unobstructed and perhaps other things, such as if it is raining or not in Spain and the moon phase of Jupiter's, sixty third moon. All take their toll. https://simple.wikipedia.org/wiki/List_of_Jupiter%27s_moons I always hoped that the 10 year data lifetime of EPROMS was a very severe/safe specification. So that in practice they would last considerably longer than this. Otherwise all sorts of older stuff (non-mask ones), would potentially break, and (if the original ROM code data is unavailable), become permanently flummoxed. E.g. A favourite piece of test gear, losing its calibration and/or programs. Hence becoming a useless unfixable piece of ex-favourite gear, sadly. I have seen millions of arguments, as to if EPROMS can be erased by allowing "normal" light into its uncovered window. Some people say they left an EPROM outside, for weeks on end, in an attempt to erase it, without an expensive UV eraser. With NO luck, it remains programmed. While others, say that an uncovered UV window, under florescent lighting, managed to erase itself (unintentionally), after a few weeks of such abuse. So I don't know who to believe. There are also rumours (or theories), that poor quality, cheap, EPROM programmers can too weakly or poorly program EPROMS, so that the program/data prematurely erases/corrupts itself. Apparently expensive ones use complicated techniques to both very quickly and yet very reliably program them. E.g. extended voltage ranges to ensure it is done right (as already mentioned in this thread by someone else). |
| daybyter:
There is currently a discussion on the jmp (adr) opcode, which is buggy on the 6502, but fixed in the 65c02 series, it seems. So it might happen, that some software is not 100% compatible with your machine. |
| CJay:
--- Quote from: MK14 on June 12, 2017, 11:57:50 pm ---I have seen millions of arguments, as to if EPROMS can be erased by allowing "normal" light into its uncovered window. Some people say they left an EPROM outside, for weeks on end, in an attempt to erase it, without an expensive UV eraser. With NO luck, it remains programmed. While others, say that an uncovered UV window, under florescent lighting, managed to erase itself (unintentionally), after a few weeks of such abuse. --- End quote --- There's a note from one manufacturer that discusses the same scenarios you mention above and gives estimated erasure times for them so I'd be inclined to believe them, I linked it in another thread here. It takes time and you don't get *good* erasure so you often end up with a corrupt bit here and there first, lots of types of window glass do a good job of blocking UV as well so are more/less effective depending where you got your windows from. Direct sunlight does a better job of corrupting EPROMS. Fluorescents emit a non zero amount of UV so they'll eventually corrupt an EPROM too. I saw many years ago an erase timer that constantly read the EPROM until all it got back was $FF, I think it may have been a project in Elektor summer circuits? --- Quote from: MK14 on June 12, 2017, 11:57:50 pm --- So I don't know who to believe. There are also rumours (or theories), that poor quality, cheap, EPROM programmers can too weakly or poorly program EPROMS, so that the program/data prematurely erases/corrupts itself. Apparently expensive ones use complicated techniques to both very quickly and yet very reliably program them. E.g. extended voltage ranges to ensure it is done right (as already mentioned in this thread by someone else). --- End quote --- Poor programming I believe is related to the algorithm used (fast programming was 'secret sauce' from some manufacturers and algorithms were often under NDA) and possibly limitations of the programming hardware, the tip about reading at different voltages is pertinent, for a chip to be considered production reliable some manufacturers suggest it has to be programmed and verified at a range of voltages. Microchip publish data about the difference between Production and Development programmers for PICs, I *think* unless proven wrong, that they would probably be applicable to data EPROMs too. |
| Navigation |
| Message Index |
| Next page |
| Previous page |