>For Nick: >The only solution I see for the moment is replacing the 4164's by 41256's >which enables you to use at least 256 KB of RAM accessible to the VIC. >Additionally you can add as much as other DRAM-modules as you want using >CBR. I can dream up a scheme doing that if you (or anybody else) want to. There are solutions for the Z80 "out there" to have 16MB, so I'm not happy to leave it that our humble 6502/6510 machines cannot. I was inspired by separate discussion with an Acorn user who had added DRAMs to his SRAM machine. The inspiration was to perform a CBR and a read in the processor phase of the clock. With a 1MHz clock, 500ns is low and 500ns is high. There is a RAS and CAS event in each phase, I assume for 200ns each? I have no oscilliscope, but as some boards have 300ns RAMs, the signals should be long. The concept is to force a CAS-before-RAS refresh before the RAS signal is no longer available from the VIC/PLA. The idea is to block the RAS event from occuring normally, have a CAS-before-RAS refresh (actually just CAS, no RAS), then allow the normal RAS through in time for a RAS-CAS read cycle to be performed. As the resulting RAS event which is associated with the read is smaller, the memory I assume needs to be faster acting. In order to complete a CAS-before-RAS the memory needs to be faster. But 70ns SIMMS should be relatively easy to obtain. My guess is that the inserted CBR cycle needs to be over in 125ns so that the normal RAS is still available for the read and can be switched in. The TTL logic needs to be sorted out still, but does the idea sound feasible? If it could be done, all would be transparent to the CPU and the VIC. Comments and thoughts appreciated, I've never worked with DRAMs. - Nick PLEASE TAKE NOTE: The contents of this email (including any attachments) may be privileged and confidential. Any unauthorised use of the contents is expressly prohibited. If you have received this email in error, please advise us immediately (you can contact us by telephone on +61 8 9441 2311 by reverse charge) and then permanently delete this email together with any attachments. We appreciate your co-operation. Whilst Orbital endeavours to take reasonable care to ensure that this email and any attachments are free from viruses or other defects, Orbital does not represent or warrant that such is explicitly the case (C) 2000: Orbital Engine Company (Australia) PTY LTD and its affiliates - This message was sent through the cbm-hackers mailing list. To unsubscribe: echo unsubscribe | mail cbm-hackers-request@dot.tml.hut.fi.
Archive generated by hypermail 2.1.1.