Hi, I am currently working on the same with TED. I have already put together my proof of concept and works fine. I have implemented all TED input/outputs but the analog parts (Chroma, Luma) need some external components (not much). I am using FPGA and currently the biggest challenge is the PCB planning to fit it in the plus4's metal shield. I could easily do it with a small BGA chip but that requires special PCB design and might be expensive. So what you need is an FPGA core with the analog parts implemented. I am sure someone is already working on it. Istvan On Fri, Jul 24, 2020 at 8:48 PM Claudio Sánchez <tokafondo_at_gmail.com> wrote: > Well... I'm starting this as a discussion about what would be needed to > replace the VIC-II with hardware that would emulate it and > expand/enhance it. > > For a start, I'm a reader. I read, ideas comes to my mind and then I > ask, so I can learn from people that actually know. > > So... > > AFAIK (and I'm telling this for people to know what is what I do know, > accepting corrections of course) , the VIC-II do cares about > > - Display text and graphics. > - DRAM refresh. > - System clock generation. > > --For the first, it reads from the CHAR ROM for text, or from RAM when > instructed to do so, mostly by KERNAL but also by custom routines. For > graphics, it reads from RAM, and is the task of the CPU how and what to > put in RAM for the VIC-II to render it as graphics (actually the text > does also works this way). > > - For the second, the VIC do read data from the RAM chips just for them > to force their contents not to be lost. > > - For the third, the VIC do send a clock pulse from one of its pins to > one of the pins of the CPU, that then outputs this signal to the rest of > the system. > > So its inputs are power, of course, the clocks generated from the 8701 > or equivalent circuit, and the address and data bus. > > And its outputs are the video signals, the DRAM refresh lines, the IRQ > lines, the BA line to control the CPU and stop it when needed. > > Then, there is the read/write pin and the chip select pin as control pins. > > So: what would be needed to emulate first of all for a C64 to believe > that the VIC-II is still there? > > For me: > > - The clock output. The CPU, and the rest of the system, won't work > without it. > - The DRAM refresh lines. DRAM contents won't last without it. > - The raster line register. There are things the CPU does when the > raster line is in certain locations, like triggering IRQs. > - The missing thing I am not aware of and that you are telling me. > > With an FPGA or a PIC fast enough, maybe there would be a way to > implement this **as a first measure** to make a C64 *think* there is at > a logical level a VIC-II there, because at an analog level, the system > doesn't care about if there is a video signal coming from it or not, or > if the graphics are actually rendered: the CPU just read or write > registers, gets controlled by the BA line or IRQ, and gets ticked in by > the clock pin. > > The next step would be reading from the proper places (ROM, RAM or COLOR > RAM), and render the bitmap image taking care of the effects supposedly > to be applied by the raster line tinkering that the demos do (of course > sprites also have to be rendered). > > And finally, get that bitmap converted to an output signal that would be > in a format that could be converted to *real* HDMI (digital) or > component / svideo (analog) video. It could be even encoded inside > network packets to have a VIC that could be remotely viewed through a > network connection. This final stage could get rid, maybe, of the > PAL/NTSC (and SECAM) limitations, because digitally it could be upscaled > and up-frame-rated to modern standards, applying filtering - or just > having a 4K version of the classic VIC graphics with the pixels upscaled > to the size of actual bricks. ;) > > NOW is your turn (that I would actually appreciate as I love to learn) > > - What do you think? > - Is it doable? > - Does it worth the work to do it? > > Thanks all. > > -- > > Saludos y cerveza. > >Received on 2020-07-27 12:00:03
Archive generated by hypermail 2.3.0.