| |
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: 11108 |
Quote:talking to VIC while it is reading data it requested from RAM, which afaik is not doable from the expansion port.
ofcourse it is - TC64 does it all the time :) As said before, something like this was actually in the initial "nice to have" feature list, but we dropped it later because we don't want to create a new platform. |
| |
laubzega
Account closed
Registered: Sep 2020
Posts: 5 |
Quote: Quote:talking to VIC while it is reading data it requested from RAM, which afaik is not doable from the expansion port.
ofcourse it is - TC64 does it all the time :) As said before, something like this was actually in the initial "nice to have" feature list, but we dropped it later because we don't want to create a new platform.
Just to be sure we're talking about the same thing - are you saying that you are talking to motherboard VIC at the same time that RAM is responding to VIC's memory fetches? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
Yes, except the RAM in the C64 is not involved, the data is feed through the expansion port. |
| |
laubzega
Account closed
Registered: Sep 2020
Posts: 5 |
Quote: Yes, except the RAM in the C64 is not involved, the data is feed through the expansion port.
According to http://zimmers.net/anonftp/pub/cbm/magazines/transactor/v6i5/p0.., 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. |
| |
Count Zero
Registered: Jan 2003
Posts: 1821 |
IMHO needs a killer app to justify the price.
When is the patch for GEOS planned? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
Quote: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.
No idea what you are talking about. Everything the real VICII displays comes from the TC64, no internal memory is involved. Again: Such a blitter thing was on the TODO list. And should this ever become a somewhat common thing, we can always add it to TC64 too. (The PLA mode used isn't in any common Table - as you usually don't use it). |
| |
laubzega
Account closed
Registered: Sep 2020
Posts: 5 |
Quote: Quote: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.
No idea what you are talking about. Everything the real VICII displays comes from the TC64, no internal memory is involved. Again: Such a blitter thing was on the TODO list. And should this ever become a somewhat common thing, we can always add it to TC64 too. (The PLA mode used isn't in any common Table - as you usually don't use it).
Indeed, I've just found the relevant info.
Thanks for the hint. |
| |
tlr
Registered: Sep 2003
Posts: 1714 |
Quoting laubzegaNow 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 ;)).
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. |
| |
Silver Dream !
Registered: Nov 2005
Posts: 107 |
> You obviously put a lot of effort into this
It's been a ride, indeed. And a bumpy one at times too :-) |
| |
wil
Registered: Jan 2019
Posts: 42 |
Quoting tlrQuoting laubzegaNow 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. Despite this I consider beamracer a great product, thanks for enriching the C64 world. |
| Previous - 1 | 2 | 3 | 4 - Next |
