Thanks for your email and having the time and patience to answer my questions. As for the MOV instructions, I saw in the the "introduction to programming" document that what they do is to write to the border color register so fast, that every cycle the VIC draws the 8 pixels belonging to that screen area with the value of the register that the VASYL just has changed, so the VIC do draw the corresponding color as the register has been updated. What I had wrongly understood, and hence the 400x200 questions, is that you could also write a byte, that translated to pixels, would draw the desired bitmap instead of just changing the color in that area, at the left of the usual bitmap area. But that, as I said, is a mistake I did because of me misunderstanding the VASYL concept. The VIC will always draw pixels in the bitmap area, and as you said in the border you will be able to put sprites but not actual bitmaps or characters... unless they are also sprites themselves. Did I got it right now? Well. I think I have now a clear idea of what the beamracer is. The VASYL acts like a supercharged Atari 2600 like style of graphics but with the VIC-II and hence its name. And also, running at the same 8mhz clock speed (I assume, or even more?) that the VIC-II runs, it's being able to handle it with a granularity the 6510 just can't (and that's just a simple way to say, having seen all these years what people has been able to achieve). I imagine that the WAIT instructions are triggered by IRQs, aren't them? Or are they raster line independient and there is an internal counter that matches where the raster line is and acts accordingly? -- Saludos y cerveza. silverdr_at_wfmh.org.pl wrote >> On 2020-05-30, at 00:29, tokafondo < > tokafondo_at_ > > wrote: >> >> 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... > > In a sense it does even more than 16KiB. The sequencer can provide display > data from any location in VASYL memory. Due to bus timing constraints that > does not include sprite data. Imagine hugely over-sized, freely scrollable > hires gfx though. > >>> VIC - just as before. >> >> I thought beamracer could provide that DRAM refresh, emulating the VIC-II >> well docummented refreshing system. > > What would be the added value of duplicating this functionality? > > >>>> - 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. > > I see. No, we didn't alter the original characteristics, timings etc. > > >>>> - 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? > > Yes, even with only a few lines of BASIC :-) Generally that was possible > even before. Just not with such resolution. > > >> 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 am not sure if I understand you correctly but MOV a,b is a VASYL > instruction, a rough equivalent of LDA #$a, STA $b. As little and as much > as that. > > BUT! The clever use of the sequencer allows things previously not > possible. Non-sprite gfx on upper/lower borders among them. > > >> 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? > > Lots of things can be done but here (BeamRacer) no – from the very > beginning the undisputed objective was to fully preserve VIC as the sole > video signal source. > >> Could the VASYL be able to manage a different chip by changing the >> firmware? > > The chip we utilise - yes, but that wouldn't be VASYL (Vic ASsistance'n > Logic). Yeah I know about the "y" ;-) > >> 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... > > Many things are possible but we focus on augmenting and elevating the 64's > possibilities, not replacing them. > > -- > SD! -- Sent from: http://cbm-hackers.2304266.n4.nabble.com/Received on 2020-05-30 15:02:04
Archive generated by hypermail 2.3.0.