Re: BeamRacer is coming… request for comments

> On 2020-05-30, at 00:29, tokafondo <tokafondo_at_gmail.com> 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!