Hi there,

here's some information on my Ultra-PET Commodore PET clone.

- 65816 running up to 12.5 MHz
- Commodore PET compatible (when running at 1MHz)
- USB, RTC, SD-Card
- Boot from SPI-Flash

- Colour-VGA! (using RGBI output)

- based on a 64 pin CS/A bus design, to allow the use of many existing I/O boards

The Ultra-PET CPU board is here on github https://github.com/fachat/csa_ultracpu
You can find the PETIO board here http://www.6502.org/users/andre/csa/petio/index.html

https://www.youtube.com/watch?v=iMmVOPfir1c

Note, that the actual CPU board is agnostic to the type of machine it simulates. Only with the right CPLD programming and the PETIO board does it make a Commodore PET.
In other words, using a different mapping in the CPLD, other types of 6502 computers could be emulated.

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

so you're using the 25MHz pixel clock to also generate the 12.5MHz clock for the CPU. in that case why not have a software controlled switch in the CPLD to allow it to run at the full 25MHz as well?
the CPU should easily be able to run at that speed if the rest of the system is able to handle it.

The rest of the system is, in my opinion a challenge. Access to video RAM runs through the CPLD with its delay for example. Address mapping takes its time. RAM access time is 25ns, which is above the phi2 time at 25MHz. Maybe there are faster chips. Maybe my CPLD programming skills are not up to par with this.

The design is open source. I invite you to show how this would run at 25MHz, I'm happy to learn!

André

Edit: this is an honest question. I don't see right now how it would work, but if I can learn I can make it faster the next time!

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

oh i thought the speed was just picked because it's still within spec of the CPU, not because you already considered something faster but couldn't do it due to hardware limitations.
hmm, sorry on the spot i can't help much, the video circuit alone is already way more complex than everything i've made so far (though i only ever had 128 Macrocells to play with)

the fastest 5V SRAM i could find is this 10ns 512kB one: https://www.mouser.com/ProductDetail/87 ... 28AL-10KLI
it's pretty cheap right now, though the price is slightly higher than when i bought a bunch of them like half a year ago.

If i'm reading the documentation correctly, accessing VRAM is done via a small memory window through the CPLD.
if your Video Circuit always fetches data at 25MHz (and in the opposite half-cycle to the CPU), then bumping the CPU up to 25MHz shouldn't cause any issues when accessing VRAM at the same time.
technically that would also mean you could throw away the whole "trhough the CPLD" thing and have the CPLD and CPU share the same data bus to the VRAM chip via a simple buffer between the CPU bus and CPLD bus.

but that wouldn't work that well since the CPLD is also responsible for loading the boot code into the CPU's RAM. (unless you use 74x245's for both the data bus and the address bus so the CPLD can take over the CPU bus for a short amount of time through the buffers)

on a side note i'm a bit confused by your comment "parallel ROMs are getting harder to come by", Parallel FLASH chips are the modern versions of EEPROMs, they are still being made and are pretty cheap. the SST39SF0x0 series of FLASH chips are a great example. though the speed is still lacking, with an access time of 70ns my 20MHz 65C02 needs 1 wait state to properly access the chip.
but i can still understand the reasoning for using an SPI flash, it's more compact on the PCB and allows the boot code to run in RAM with no wait states or extra address decoding.

overall it's a very nice looking project you got and i wish you luck with any overhauls of the system that you might do (if any)

Thanks Proxy.

The SRAM (both the "fast" and the "video" RAM) are driven at 12.5 MHz. No opposite phase bus sharing is used - but could potentially be used with faster chips on the video RAM.

Each are 512k in size, with the fast RAM mapped to the lowest 512k, and video RAM just above it. So, not a window, but the full area (in the 65816 address space). In the lowest bank I can map in indeed a video memory window if you mean this, it is required for PET compatibility.

As the CPLD can only write to VRAM (thinking about it now, I'm not actually sure why. Maybe because /BE is missing on the CPLD to decouple the CPU from the bus, or the number of additional bus drivers/registers required to actually use the CPU address lines also as output, or I just didn't try, ... I don't remember), on reset the two chips are swapped in address space, SPI boot is written in VRAM, where the CPU starts, then swaps the memory mapping again via configuration register.

Your diagram is about right, only that both the VGA and the buffer resides inside the CPLD. In the Micro-PET with the monochrome output the pixel shift register is in the CPLD as well, but in the Ultra-PET this is pulled out due to space reasons.

For colour video display, I need 3 video RAM accesses per 8 pixels: 1st character, 2nd character generator, 3rd colour byte. That leaves a single access left for the CPU during that 8 pixel time (25 MHz pixel clock). So, for VRAM, the CPU is waitstated down to about 3 MHz. Fast RAM is just that - unrestricted 12.5 MHz. That reminds me I still need to check the benchmark for the Ultra-PET.

I thought about splitting up diverse parts of the CPLD to be able to use smaller (and maybe less costly) CPLDs and make the whole thing more modular, but in the end I always ended up with so many connections between the different parts, it was easier to put it all into a single CPLD.

The Micro-PET originally started (in 1.0) with a parallel ROM. But as you noted, these are slow compared to SRAM. So, I experimented with SPI boot, which gave me the speed of SRAM, and the low board area needed for the cost of a small SPI boot code in the CPLD.

Somehow I was probably looking for the wrong types of chips maybe (EEPROM vs FLASH), so it's fine that they are still available, but I would not use them anymore in such a setup.

I was actually glad that the design worked at 12.5 MHz. I didn't even consider it being faster, due to the mentioned considerations about SRAM speed, and signal delays in the CPLD etc.

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

Btw, here is the screenshot from the benchmark. You can see that running the code in the video memory gets slowed down due to video fetch. Although maybe not by the expected amount - as CPU cycles where VDA/VPA indicate they don't use memory are run in parallel to video fetches of course.

Also note that the system clock is not at all hampered - it stays at 1 MHz. This is a difference from the Micro-PET where the I/O chips are also clocked at the higher speeds. In the Ultra-PET the bus is not "rated" for that, so it stays slow.

Edit: and of course I forgot to change the copyright to 2022

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

The next board rev is going to production, now with an FPGA instead of a CPLD (actually the second FPGA rev, but the first did not autoconfigure the FPGA and other woes.) Also, the color hardware is pulled into the FPGA as it has way more space.

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/