>> - Can the VASYL memory replace the C64 memory so the VIC-II uses the former >> instead of the later? >Yes and no. The programmable sequencer (which is my favourite feature) reads non-sprite data from >VASYL memory. Sprite data needs to come still from C64 memory though. I thought VASYL could provide the VIC-II with a 16KB framework of memory to read the data from, freeing the system memory for code, music, map data... >> - Who's refreshing the DRAM once the beamracer is installed? >VIC - just as before. I thought beamracer could provide that DRAM refresh, emulating the VIC-II well docummented refreshing system. >> - Can the VASYL isolate the VIC-II from the system so the C64 can run as >> if >> it wouldn't have a VIC-II installed? >Well - it wouldn't make much sense to run the machine w/o VIC installed. For once the RAM needs refresh, >for twice we still need to see things. Theoretically it would be possible but I see no use for this. I though that by only passing the IRQ line to the 6510, it (the 6510) could run free of interruptions, *every* low clock phase instead of when the VIC-II is not fetching data or refreshing DRAM, as it usually happens. >> - Can the VASYL make the VIC-II switch between different color modes in a >> *single* raster line? >Even 40 times :-) So the first byte could be Hires, the second one Multicolor, the third Hires again... So I imagine that a screen with its left half could be hires, and its right half, multicolor... split in vertical, instead of horizontal. Is it like that? > - Can the VASYL be used to expand the borders so a resolution higher than > 320 or 200 can be achieved? All the "classic" VIC programming techniques still apply. You can open both side and upper/lower borders at will. Now even with a few lines of BASIC code though ;-) >> and finally... >> >> - Could a kernel mod, or a new kernel, make the VASYL make the VIC-II >> work >> in 400x200 resolution, by expanding for 40 pixels or 5 char columns each >> side, so it would enable an 80 column mode with a custom charset of 5x8 >> fonts? >VASYL does not change any of the VIC characteristics, does not overclock it, nor does any other non- >kosher stuff ;-) Side borders remain available only for sprites as before so that you still can have some fun >placing them there, but making custom and custom-sized fonts with VASYL's sequencer allows completely >new possibilities where poking single value into "screen" memory can control much larger pixelcount. Think >2x2 font where each character is controlled with one byte as normally. Ok, I think I misunderstood the use of the MOV instructions in the "Introduction to programming" document. I tought that you could make the VIC-II draw pixels in the border as if it were reading bitmap or fonts data, but now I get it: every write outside the usual screen area changes the color in 8 pixel wide lines, just because the VIC-II do it that way internally, but with VASYL you can change it every char line easily. I think that if an FPGA'd version of the VIC-II could be developed, that would emulate the usual VIC-II behaviour, but could be modified to allow the horizontal screen area to start be drawn earlier, but the it wouldn't be a VIC-II, would it? > More questions welcome! A new one: Could the VASYL be able to manage a different chip by changing the firmware? I'm thinking that it could be possible to replace the VIC-II with one of the famouse MSX2 chips, or with an EPSON display chip that they manufacture nodaways, compatible with 8 bit direct addressing. Of course, at least DRAM refreshing and system clocking should then made by an alternate system... -- SD! -- Sent from: http://cbm-hackers.2304266.n4.nabble.com/Received on 2020-05-30 01:59:05
Archive generated by hypermail 2.3.0.