"the copper accesses would block the 6510."
no, you "feed" the VICII with data over the expansion port - TC64 does this all the time :)

Yeah, you need the CPU in the cartridge.... not a big deal though :)

i dont think that can work, thats why this addon sits between VIC and mobo

Looks very cool, but for me, I'd rather not add semi-permanent performance mods inside the machine itself.

i dont think that can work, thats why this addon sits between VIC and mobo

talking to VIC while it is reading data it requested from RAM, which afaik is not doable from the expansion port.

you can only do that in 1/4th of VIC's memory space. This is not a limitation we wanted to impose on the programmer.

Now that I have an account here, a few quick comments:

1. One of the primary design goals for the BeamRacer was to make more CPU time available for other things. Consequently, stopping the 6502 during VIC accesses was not an option, especially that once you get a hang of writing display lists, you find yourself talking to VIC quite frequently. Blocking the CPU would in a way create another badline-like phenomenon - definitely useful, but make too many and you're walking in molasses. Which was the opposite of what we were aiming for.

2. While you can do many interesting things from a cartridge, BeamRacer's programmable bitmap sequencer is not one of them. It's an important feature, which beyond obvious benefits of moving the bitmaps around with just a pointer write, also enables new synthetic modes (like 32x32 tiles). Implementing the sequencer in programmer-friendly, unconvoluted way requires talking to VIC while it is reading data it requested from RAM, which afaik is not doable from the expansion port.

3. Lumafix without blurriness is an often wished-for feature. Realizing it from the expansion port is not doable either.

4. Even if you would rather stick to a base C64, BeamRacer is a great tool for rapid prototyping on _real_ hardware. Instead of counting cycles and targeting VIC with clunky 6510, you can check what's possible even from BASIC, and optimize/fine-tune later. Is saving development time of demo coders a killer app? I wouldn't know, but it has to count for something. ;)

5. Last, but not least - the major part of effort that went into the board was not of "_how_ to do it" variety, but rather of "_what_ to do". Sure, working with tight tolerances imposed by the need to support multiple models of VICs and motherboards was challenging. But it was the design of the coprocessor (VASYL) and making it match both the C64's architecture and the limitations of an 8-bit system that consumed the better part of development time (and was the most fun ;)).

Quoting laubzega

Now that I have an account here, a few quick comments:

...

4. Even if you would rather stick to a base C64, BeamRacer is a great tool for rapid prototyping on _real_ hardware. Instead of counting cycles and targeting VIC with clunky 6510, you can check what's possible even from BASIC, and optimize/fine-tune later. Is saving development time of demo coders a killer app? I wouldn't know, but it has to count for something. ;)

...

Number 4 is an interesting point, I agree.

Let me also say that the product (both features and design) looks very professional. You obviously put a lot of effort into this.

I'm not sure about the majority, but I do rapid prototyping mostly using cross development tools including an emulator for quick testing. Only later I try out the alpha version on real hardware. As far as I understood, with beamracer I would to have to go back to "true" coding on the real hardware. Or is there some possibility to emulate the beamracer within an emulator?

Thus, I not sure if point 4 really applies to me.

Having this on real HW will let you find new VIC tricks and so on (if there are any left to find).