| Electronics > Projects, Designs, and Technical Stuff |
| Cloning a Commodore PET-2001 |
| << < (10/33) > >> |
| MK14:
EPROMS were at least "fun", in the past, when they were a lot more commonly used. I vaguely remember that the extended voltage range is for something like, that if it is programmed at the highest possible voltage, it will be fine at lower voltages. But if it were programmed at a lower voltage, it may be in trouble at higher voltages. Or maybe it's the other way round, I can't remember the exact details. Obviously (for non-RETRO projects) Flash is the modern day EPROM at the moment. Sooner or later (or now if you count FRAM, but it tends to be pricey, a bit fussy and relatively low capacity), I guess something more ideal, will turn up. Which is economically priced, high capacity, low power, fast, extremely long term data-retention, infinite or very high write/erase cycle lifetimes, and easy/straightforward to use. |
| CJay:
--- Quote from: MK14 on June 13, 2017, 07:15:46 am ---EPROMS were at least "fun", in the past, when they were a lot more commonly used. I vaguely remember that the extended voltage range is for something like, that if it is programmed at the highest possible voltage, it will be fine at lower voltages. But if it were programmed at a lower voltage, it may be in trouble at higher voltages. Or maybe it's the other way round, I can't remember the exact details. Obviously (for non-RETRO projects) Flash is the modern day EPROM at the moment. Sooner or later (or now if you count FRAM, but it tends to be pricey, a bit fussy and relatively low capacity), I guess something more ideal, will turn up. Which is economically priced, high capacity, low power, fast, extremely long term data-retention, infinite or very high write/erase cycle lifetimes, and easy/straightforward to use. --- End quote --- I dunno, I don't really have an issue with flash for retro, it's all data and the early DIP flash chips were pin compatible so it's not that much of a stretch in my mind. I still like EPROM and I've just got hold of a really nice, old EPROM programmer so I'm going to dig out all the old ROMs I've got kicking around and read them out, might be informative as to data retention as I've not taken great amounts of care to ensure they were stored well. A lot of them have checksums written on labels or chip bodies. |
| MK14:
--- Quote from: CJay on June 13, 2017, 10:08:39 am ---I dunno, I don't really have an issue with flash for retro, it's all data and the early DIP flash chips were pin compatible so it's not that much of a stretch in my mind. I still like EPROM and I've just got hold of a really nice, old EPROM programmer so I'm going to dig out all the old ROMs I've got kicking around and read them out, might be informative as to data retention as I've not taken great amounts of care to ensure they were stored well. A lot of them have checksums written on labels or chip bodies. --- End quote --- What's nice about the EPROMS is the way the work flow works with them, which is handy. E.g. You can have a set with the previous software and/or a known working version nicely labeled up, so that if the unit suddenly starts messing up, you can instantly go back by putting the previous (or an older) version in to see if the hardware has broken, or you have messed up with the software. The twenty minutes erase time (can be fifteen minutes, or longer than twenty), gives you time to think about what you are doing with the software, rather than rushing through with it and making mistakes. Although you can keep a tiny stock pile of erased EPROMS, ready. Flash (assuming there is at least a slight in circuit programming capability) can be corrupted, during bad power down, software crashes or even while it is being written (in circuit), and the power switches off too soon or a reset occurs in the middle of it performing writes. Strictly speaking that really shows poor circuit design and/or a lack of enough capacitance to hold the supply rails up, during an unexpected power disconnection or similar, but even so. Whereas EPROMS are more dependable in that sense. Which is nice. I think what I'm relatively pleased to see the back of, is the OTP's (One Time Programmable devices). I suppose they are fine for production, as long as the software/data never changes. But for development, they are a pain. Pressuring you to either have extremely few software versions, or seek out complicated ways of getting prototypes to have non-OTP capabilities, such as EPROMS or battery backed-up CMOS SRAM EPROM/OTP simulators or similar. |
| GK:
My programmer arrived today; just flashed the AT27C256 OT PROM with the original PET character ROM images, resurrecting the video generator. There were two OS versions for the PET-2001, the original, called BASIC#1, being rewritten (and thus dubbed BASIC#2) soon after the machines release to fix a number of bugs, mostly relating to serial I/O operations. The character ROM was slightly different for each version of basic also. Since a single 32 kb PROM will hold both versions of BASIC, I'm going to accommodate both OSs for the greatest software compatibility. The character PROM has been burnt with both BASIC #1 & #2 character sets. I'll have the MS address bit of both the character ROM and the OS ROM asserted by an "Operating system select" switch. Here is (just for now) a screen shot showing a random garble of characters from the PET BASIC#1 character set (this crappy TV has a rather poor composite video signal image quality compared to my 1084S). I've got all of the other bits (65C02, VIA, PIA, chips etc) now too. Hopefully by the end of the coming weekend I'll have the operating system booting. |
| GK:
Just plodding through my design/build................ I've been studying the operation of the 6502 in depth and after perusing lots of home brew systems posted on the internet have come to the conclusion that most constructors out there don't have a clue about properly interfacing a 6502 to non 65XX-family memory/peripherals. I finally stumbled upon this pertinent article (confirming my suspicions) detailing aspects of the 6502's write cycles and timing issues that anyone interested in actually implementing a 6502 system properly really needs to know: http://www.atarimagazines.com/computeii/issue1/page9.php Scroll down to "6502 Write timing" for the most important part. To properly implement (so as to not possibly impinge upon setup/hold times of a prior read cycle) the memory !write stobe for non 65XX-family parts you need to NAND a inverted version of R/W with the PH2 clock. With the super fast WDC65C02, the minimum spec for THW is only 10nS. Suppose you NAND !R/W and PH2 with a 74HC00. That will delay the rising edge of your write strobe (upon which the data is latched) by a gate delay of approx ~20nS - that's 10nS later than the minimum time that the data is guaranteed to remain on the bus! If, for example, you have your system RAM data lines connected directly to the 6502 data bus (that is not buffered by a bi-directional octal transceiver to impart a equal or greater amount of delay effectively adding to THW) then you can probably forget about seeing it working. These issues can be worked around for sure (I'm using fast 74AC logic to generate my universal write strobe, for minimal delay) and adding (otherwise superfluous) data line buffering for my system RAM just for the added delay to ensure that I meet minimum specs. for all read/write setup and hold times), but you really need to study and understand these specifications to ensure that you're not going to build something that is inherently unstable or occasionally flaky. |
| Navigation |
| Message Index |
| Next page |
| Previous page |