| |
lemming
Registered: Oct 2009
Posts: 44 |
Beamracer ... who's in?
I saw that Beamracer is finally available to buy (see https://beamracer.net/) and I'm thinking about ordering two of these but it's not a cheap piece of hardware for sure.
I certainly think it's an exciting expansion.
So, who else is in for a ride, eh? |
|
... 22 posts hidden. Click here to view all posts....
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11111 |
Implementing this is actually totally doable using a cartridge like 1541u or TC64. In fact, both Gideon and Ourselves had similar things on our "nice to have" lists, but dropped it at some point because of various reasons (for us mostly: we don't want to create a new platform).
"the copper accesses would block the 6510."
no, you "feed" the VICII with data over the expansion port - TC64 does this all the time :) |
| |
tlr
Registered: Sep 2003
Posts: 1714 |
Quoting Groepaz"the copper accesses would block the 6510."
no, you "feed" the VICII with data over the expansion port - TC64 does this all the time :)
It would block the 6510 in the C64, no? But ofcourse you can add an arbitrary CPU (e.g cloned 6510) in the cartridge. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11111 |
Yeah, you need the CPU in the cartridge.... not a big deal though :) |
| |
tlr
Registered: Sep 2003
Posts: 1714 |
Quoting GroepazYeah, you need the CPU in the cartridge.... not a big deal though :)
Sure, but what I ment I wouldn't mind trying out was an addon with _just_ copper in the cartridge. That should be less complex to fiddle with implementing variants of. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11111 |
i dont think that can work, thats why this addon sits between VIC and mobo |
| |
tlr
Registered: Sep 2003
Posts: 1714 |
Quoting Groepazi dont think that can work, thats why this addon sits between VIC and mobo
It should be possible, it's just that the 6510 halts during transfers. Like a REU if you will.
Anyway, this thread was about the Beamracer so let's let that continue, sorry... |
| |
chatGPZ
Registered: Dec 2001
Posts: 11111 |
yes, sure, like REU can work. and yes :) |
| |
Silver Dream !
Registered: Nov 2005
Posts: 107 |
Quoting tlrLooks very cool, but for me, I'd rather not add semi-permanent performance mods inside the machine itself.
If you don't use it at any given moment - it remains "invisible" – there is no need to remove it when not in use. And since there aren't many expansions requiring VIC socket access (VideoMod is directly supported), chances that you find yourself in need for removing it are rather slim. The same can't really be said about the cartridge port :-) |
| |
Silver Dream !
Registered: Nov 2005
Posts: 107 |
Quoting Groepazi dont think that can work, thats why this addon sits between VIC and mobo
Confirmed. |
| |
laubzega
Account closed
Registered: Sep 2020
Posts: 5 |
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 ;)). |
| Previous - 1 | 2 | 3 | 4 - Next |
