Electronics > Projects, Designs, and Technical Stuff
Cloning a Commodore PET-2001
Kleinstein:
The 6502 needs rather fast access time. There are no wait states and one memory transfer per clock cycle. So even with 1 MHz clock it needs something like 400 ns access time. With additional bus drivers it might need to be even faster - not a problem at 1 MHz, but possibly a problem at higher speed.
AFAIK the 6502 / 65C02 is only available up to 2 MHz clock speed. There is a faster 16 Bit version, used in the Apple 2G, that can run up to about 8 MHz.
A higher speed might be possible with an FPGA implementation - however this might need level translators for old SRAM.
GK:
--- Quote from: Kleinstein on June 10, 2017, 01:19:38 pm ---The 6502 needs rather fast access time. There are no wait states and one memory transfer per clock cycle. So even with 1 MHz clock it needs something like 400 ns access time. With additional bus drivers it might need to be even faster - not a problem at 1 MHz, but possibly a problem at higher speed.
AFAIK the 6502 / 65C02 is only available up to 2 MHz clock speed. There is a faster 16 Bit version, used in the Apple 2G, that can run up to about 8 MHz.
A higher speed might be possible with an FPGA implementation - however this might need level translators for old SRAM.
--- End quote ---
No, no, no, as already mentioned, I'm using the "6502" and associated PIA/VIA chips from Western Design Center. These are not the original NMOS parts, but current-production (yes, really), performance-enhanced CMOS versions. The 65C02 is fully specced to 14MHz. See here:
http://www.westerndesigncenter.com/wdc/
I'm using 15nS SRAM. The ROMs are 45nS. The high-speed bottleneck will be in the video RAM access. I quite significantly simplified the video generation circuitry by addressing 4kb of memory (not all allocations used) directly from the pixel and line counters. This allocates a character position in the screen RAM to every single character space, including the invisible ones during the retrace and screen-border blanking intervals. The original PET circuitry did not work this way as SRAM back then was not free to "waste". The PET video generator had an address counter for the screen memory that operated separately from the pixel and line counters, only incrementing for each displayed character. There was also an attendant temporary address data latch/memory/register, that was necessary as the 40 memory positions for each row of characters has to be cycled through eight times (a character space is eight video lines high), so the return address needed to be updated and temporarily stored every eight video lines.
However, without re-writing the operating system, in my simplified video generator logic, I have to map the 1000 (40x25) individual character positions addressed by the CPU to the correct ones in my video RAM. I'm doing this with a PROM address lookup table. So the 15nS screen RAM is addressed via a 45nS PROM. The address data selector, which grants the CPU screen RAM address access, adds another ~20nS delay, as does the bi-directional data bus transceiver. So I have 15nS+45nS+20nS+20nS = 100nS. Add another 20nS just for safety and maybe another again for setup times and good measure and we can safely handle a memory cycle of 8.3333 MHz. My pixel clock is 8 MHz and this is what I am currently planning to use as my "Turbo"-speed clock.
GK:
--- Quote from: GK on June 10, 2017, 02:05:49 pm --- So I have 15nS+45nS+20nS+20nS = 100nS. Add another 20nS just for safety and maybe another again for setup times and good measure and we can safely handle a memory cycle of 8.3333 MHz. My pixel clock is 8 MHz and this is what I am currently planning to use as my "Turbo"-speed clock.
--- End quote ---
Oops, Make that 7.1 MHz. 8MHz might be skating on the verge, but these are conservative estimates with about worst case 25 deg. C delays. Will just have to wait and see.
chickenHeadKnob:
--- Quote from: GK on June 05, 2017, 01:52:52 pm ---
--- Quote from: BrianHG on June 05, 2017, 05:26:58 am ---As for the ROMs, if you appropriately address all the files in one larger rom, and properly place them in a 27C128, (total 16kbx8), or 27C256 and properly set the output enable, and tie all the addressees, it will work. It will also be all to easy to add right in parallel a 1x or 2x 32k X 8bit static ram as your system memory instead of worrying about D-Ram ras/cas/refresh and ect. All the pins will be in parallel, except output enable and write-enable. Since the 8 bit static ram and eprom are both 28 pin 600 mil wide DIP devices and virtually pin-pin compatible, and dirt cheap today.
For 14Mhz with 1clk cycle transactions, not sure if 6502 waits 1 or 2 clocks on bus transactions, go with 70ns devices to get 14Mhz, 1 clock transactions.
--- End quote ---
No, definitely not going to bother with DRAM. SRAM was used in the PET 2001 too. The early serial numbers used MOS 6550 SRAM chips while later revisions used 2114s.
The DIP SRAM chips I ordered for the project have a 15nS specified read time spec. Should be fast enough!
--- End quote ---
I would go even further and completely dispense with all the old school eproms, just fill the 64k address space with static RAM and have a modern MCU you are comfortable with act as a system control/boot loader essentially turning the target system into a rom emulated one. Massive convenience for debugging.
james_s:
I never liked using a modern microcontroller in this sort of retro project. By the time you do that, you may as well just emulate the thing entirely in the microcontroller, or put the whole computer in an FPGA.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version