oehansen wrote:I can't understand why anyone would want a memory mapped graphics engine, where the CPU is used to draw the bloody graphics. In the case of a 68k it certainly doesn't make a heap of sense, really.
penguin wrote:It was done commercially with the ODIN graphics card which was an external solution and didn't require a Mega or VME bus: http://stcarchiv.de/stm1992/06/odin
ctirad wrote:penguin wrote:It was done commercially with the ODIN graphics card which was an external solution and didn't require a Mega or VME bus: http://stcarchiv.de/stm1992/06/odin
Ah, a ROM port solution. I have such an idea ony my mind for many years. A simple, cheap (a small FPGA + SRAM based) plug&play solution that would work on every Atari from the very first 260ST to the TT and F030. Even the driver could be loaded directly from the device at boot.
However, the hard part would be to create a clever way how to transfer data to ROM port as fast as possible and also to address a suitable amount of videoram (1MB at least) and, of course, to make the driver (probably fVDI based, becuase it is opensource).
penguin wrote:Would it be possible to replace the Shifter with a FPGA with additional features?
penguin wrote:ODIN didn't connect to the ROM port - it connected to the ST monitor port and the VGA monitor. I don't know whether later driver versions improved performance/compatibility.
Greenious wrote:ODIN looks like yet another ISA-port adapter using an ISA graphics card.
Greenious wrote:No, I can guarantee you it was not only connected to the monitor port. Likely the cartridge port aswell, if not the cpusocket inside via ribbon cable.
czietz wrote:... and from the (correct) picture you can in fact see that it was indeed only connected to the monitor port. It also explains how it is done: One high-res frame was stitched together from up to five frames output via the monitor port. Of course this seriously reduces the update rate of your screen in high-res mode.
Users browsing this forum: No registered users and 5 guests