>>> I am fairly sure that R/W and the address lines will be asserted. >>> I vaguely remember that the data lines are left floating. >> >> That is correct. We don't have die pictures of a 6510 yet, but >> it seems like the 00/01 thing forces the DBE signal low, and >> that is all it does (and the actual register stuff of course). > > Now, thinking harder, reads from 0 and 1 should be shown on the > address and data bus too. (The data bus would be driven by the > memory chips, as usual.) Of course :-) >>> One more tidbit: on the 128, you can programmatically enable >>> UltiMax mode on the MMU (GAME=0, EXROM=1, enter 64 mode) and let >>> the VIC-IIe fetch its data from an unconnected address. In the >>> mid-1990s, I played a bit with this, trying to write a test >>> program that would display the data fetched by the processor. It >>> did not occur to me back then to research whether you can disable >>> memory refresh and corrupt the RAM in this mode. >> >> The row address gets delivered to the RAM no matter what, so there >> is no problem there? > > The row address is the low-order 6 bits, right? Low eight on the VIC-II in the C64 (there is a mask option to make it low seven, to work with 16k DRAM chips). > The VIC-II will do 5 memory refresh cycles per raster line, reading > from $3fxx using a 8-bit counter. But, will $3fxx always be visible > to the VIC-II in the UltiMax mode? It doesn't matter, the row addresses are always delivered to the RAM, whether the VIC is reading from ROM or open bus or whatever. The PLA selectively switches off #CAS only, not #RAS. > Does this change if you make VA14 or VA15 nonzero? IIRC, in > UltiMax mode, the VIC-II should see data from ROML or ROMH, and > only the first $1000 bytes should be fetched from RAM. Here's my PLA decode for Ultimax mode: not exrom and game: =================== 0000..0fff, cpu: ram 8000..9fff, cpu: cartridge low d000..dfff, (cpu read and ba) or cpu write: i/o d000..dfff, cpu read and not ba: ram e000..ffff, x1x, cpu: cartridge high e000..ffff, x0x, cpu: ram 3000..3fff, 7000..7fff, b000..bfff, f000..ffff, vic: cartridge high 0000..0fff, vic: ram 8000..9fff, vic: ram d000..efff, vic: ram rest open bus As you see, the CPU can read from dxxx (well, not really -- it will drop the result on the ground, not RDY), and read/write to [ef]xxx as well. (The "x0x" etc. are the P2..P0 bits). The VIC sees more, and it sees the cartridge ROM at various places. The PLA does nothing with VA14 except for the character ROM, and VA15 isn't even connected :-) Let me know if you want the decodes for the other modes. Btw, this is from the original actual PLA; it could be that the later NMOS and CMOS decoders do something different for the (undocumented) edge cases. Segher Message was sent through the cbm-hackers mailing listReceived on 2011-12-07 23:00:28
Archive generated by hypermail 2.2.0.