Commander X16

On 12/29/2021 at 9:28 AM, Ed Minchau said:

Like on the X16, VERA would have been a daughter board, in much the same way Soundblaster was. Those edge connectors can have lots of pins.

The original VERA looked much like a video chip in an odd package, containing only pins. The video ports were on the X16 board. Regardless that doesn't address the issue raised with regard to the necessary bus widths to meet VRAM latency requirements. I don't follow the relevance of the edge connector width.

On 12/30/2021 at 2:22 PM, Wavicle said:

The original VERA looked much like a video chip in an odd package, containing only pins. The video ports were on the X16 board. Regardless that doesn't address the issue raised with regard to the necessary bus widths to meet VRAM latency requirements. I don't follow the relevance of the edge connector width.

The idea of an edge connector is that you can have as many pins as you want. If you need 72 conductors for data/address/control, that's only 36 on each side of the edge connector, 3.6 inches long.

On 12/30/2021 at 8:48 PM, Ed Minchau said:

The idea of an edge connector is that you can have as many pins as you want. If you need 72 conductors for data/address/control, that's only 36 on each side of the edge connector, 3.6 inches long.

The problem is the number of pins needed by the component that ultimately composes the line buffer. It must be able to perform 32 bits worth of access to a 128K VRAM space every 40ns. Using 1980s era tech, one could only hope to do this by making the data and address paths wide. Making the data bus 32 bits and using a non-multiplexed 15 bit address bus might put the goal within reach, but that is 47 pins taken up just for the basic address and data bus. The chip will also need power, ground, clock, reset, data direction, video out signals, and some sort of interface to the host.  I'm not aware of any 8 bit system that had a DIP component larger than 40 pins; nor any DIP component larger than 64 before everything went SMT.

Compare this to the C128D (probably the Apex of real 8 bit systems) which used the 8563 VDC with an 8 bit wide data bus to DRAM chips with a multiplexed address bus. The best case transfer rate for those chips was 8 bits every 230ns (~0.035 bits per nanosecond). VERA requires a bandwidth of 0.8 bits per nanosecond, 23 times faster than what the 40 pin VDC could achieve.

That's the fundamental problem that would have to be solved to make a 1980s era VERA.

Incidentally, the largest package Commodore was capable of manufacturing was 84 pins. This is what constrained Fat Agnus on the Amiga line. They could make that a PGA or PLCC, not DIP.

On 12/30/2021 at 10:09 PM, Wavicle said:

I think that's going to require much more than a bit of enhancing. I don't want to discourage you, but I would encourage you to focus on crawling before flying. How will communication between your card's CPU and 6502 take place? The 6502 bus has strict timing constraints that are extremely difficult to meet via software implementation on a microcontroller. It's pretty much impossible to handle 6502 bus IO using interrupts on the 68K because that CPU has a 44 clock cycle minimum latency to service interrupts. An 8MHz 6502 bus read has an allowance of about 50ns from the rising edge of PHI2 until the data needs to be stable on the data bus to meet the data setup time constraint (tDSR in the datasheet, I think). If you're using all discrete logic, the fastest discrete 7400 series logic chips have a propagation delay of 4-8ns under ideal circumstances. The problem could probably be solved if you're sufficiently clever, but it would be quite the labor of love compared to just sticking a low cost FPGA in there for interfacing with the 6502 bus.

so, communitcation i guess could be done with a coupld of registers, so the 6502 writes the GPU command into the registers, and the 68K fetches the instruction from the register.

i have not thought out everything completely, but i am trying, and not really confident that it will work well.



just the idea and the proof of concept would be cool.

On 12/31/2021 at 9:30 AM, Mutz03 Zockt said:

so, communitcation i guess could be done with a coupld of registers, so the 6502 writes the GPU command into the registers, and the 68K fetches the instruction from the register. ...

Yes, you can use a register to buffer a write from the 65C02 bus and buffer the five address lines to know where the write is going.

The bottleneck is the read from the 65C02 bus. A Vera register is read in a single clock cycle, so you might need a register file for some of the Vera registers.

On 12/31/2021 at 5:32 PM, BruceMcF said:

Yes, you can use a register to buffer a write from the 65C02 bus and buffer the five address lines to know where the write is going.



The bottleneck is the read from the 65C02 bus. A Vera register is read in a single clock cycle, so you might need a register file for some of the Vera registers.

thats fine though, it doesnt have to be extremely fast and accurate, i just want to build something wich is not a FPGA

 

On 12/31/2021 at 1:20 PM, Mutz03 Zockt said:

thats fine though, it doesnt have to be extremely fast and accurate, i just want to build something wich is not a FPGA

If you are just building something which isn't an FPGA, then a mix of the way the 80-column chip from the C128 and the way the Vera interfaces could be used.

Two registers, one is the address register for the other. The "address" register is just a register, which allows for up to 256 register addresses for the second, which is a normal 65C02 register. But if you limit it to 128 register addresses, the top bit can specify whether it is going to be a read or a write, and if a read, it can pre-fetch the value for the data register location.

And VRAM data port, and two address registers, with the bottom two or three bits implied $00 when the low address register is set, and incrementing after a read or write of the data port. Then a counter provides the bottom bits, with the reset for the counter set to the write of the bottom address register. That allows for 256K or 512K of VRAM.

That whole approach is quite different from the strategy that was used for the VIC-20, C64, C128 etc., with an FPGA being the closest feasible hobbyist equivalent to the CBM approach of building a dedicated ASIC video chip. But there's obviously no rule about sticking closely to that approach ... building the display from discrete electronic components is more like the Apple I approach, though I take it that you are aiming at a substantially more capable display.

On 12/31/2021 at 6:30 AM, Mutz03 Zockt said:

so, communitcation i guess could be done with a coupld of registers, so the 6502 writes the GPU command into the registers, and the 68K fetches the instruction from the register.

i have not thought out everything completely, but i am trying, and not really confident that it will work well.



just the idea and the proof of concept would be cool.

There are (or were) logic chips specifically for mailbox registers. E.g. 74xx172 (which I cannot find a source for) provides multi-ported access to eight 2-bit registers or 74xx670 (which has a long 45ns propagation delay) has four 4-bit registers @ $2/each. You could create your own using discrete components; if you do so and meet the bus timing constraints, then my hat's off to you.

On 12/31/2021 at 3:38 PM, Wavicle said:

There are (or were) logic chips specifically for mailbox registers. E.g. 74xx172 (which I cannot find a source for) provides multi-ported access to eight 2-bit registers or 74xx670 (which has a long 45ns propagation delay) has four 4-bit registers @ $2/each. You could create your own using discrete components; if you do so and meet the bus timing constraints, then my hat's off to you.

If you want a mailbox, and have active processing on both sides, you can use dual ported SRAM, though that might not be period specific enough.

On 12/25/2021 at 5:23 PM, Ed Minchau said:

Look at it this way: in the 1980s, Commodore had their own chip fabrication plant.  That's how they produced things like the VIC chip and VIA chips for audio and video for the VIC-20.



The VERA daughterboard is definitely something Commodore could have done in the 80s, though it would be a much bigger board.  And of course we're already using 512kb RAM ICs, which for Commodore would have been an enormous PCB flooded with 2kb RAM chips.  Point is, Commodore could have produced VERA, and all the rest of the Commander X16.  Their only real obstacle would be the RAM, and SD storage was just a dream back then.  An FPGA like VERA would have been a factory-programmed gate array rather than field programmable, or several such ICs.



The ATtiny used for Reset and power on wouldn't have been present on Commodores because of the external power box feeding a single voltage to the computer, but if they had needed something like that it would have probably been done with a special-purpose chip that they fabricated themselves as well.  It isn't doing a whole bunch of 16 bit or higher math, and might have been implemented with a bunch of TTL logic gates instead.  If they were putting 2Mb of banked RAM in a machine, the case would already be big and would contain lots of PCBs, so what's one more?

Then again, there are a few "crochet hook" ideas that in hindsight, should have been dope slap obvious, but back in the day no one ever thought of.

Take stacked RAM.  The idea of stacking four to eight DRAM dies using through-silicon vias, plus DRAM refresh logic and possibly a DMA and/or MMU on a package no larger than a then-typical DIP should have been blindingly obvious, but it didn't happen.  Done right, a 64K Pseudo-SRAM version should have drawn no more power and/or generated no more heat than an 8K SRAM on the same package, and massively reduced the chip count of, say, the Commodore 64 and subsequent follow-up motherboards.

Unity Semiconductor, creators of CMOx Flash, was poised to turn the nonvolatile RAM market upside-down, but then they were bought out by Rambus, which scared all possible potential licensees off, due to Rambus' reputation as sharks.  They had white papers that it could have been produced on conventional CMOS tools, and tested the concept at a five micron node.