[quote pid='110' dateline='1604272188']
Hi!

After testing the examples using Kernal64, I noticed a big difference when running the sequencer example.
Of course, Kernal64 doesn't try to mimic my old monitor (Sony PVM-14N5U monitor, PAL/NTSC) but I found the vertical lines quite weird (check the M and H, and the BASIC lines), like some kind of interlaced display.
I never noticed that with "normal" C64 graphics. I check a few demos, nothing like that. Do I imagine things ?



Monitor specs: https://www.broadcaststore.com/pdf/model.../17906.pdf
[/quote]

Next batch of BeamRacer boards was cleared through customs and arrived today. We still need to thoroughly test every single board but we expect to start notifying everyone who reserved his unit really soon now 

Update, new demos.

reflections:


hirestext:

Hi guys,
So as I received the Beamracer (nice packaging!), I wanted to install it on my PAL C64C.

I followed the instructions (for the narrow boards, mine is a 250469 rev A), I was able to bend the C36 capacitor (enough I guess, else I'll re-solder it).
But I'm totally unable to set the beamracer in the socket, each time it pops up like it was on springs.

To test I also tried on the riser socket, the socket fits perfectly well on the VIC socket but same result, the BeamRacer pops up even when "well" inserted (meaning as much as it can).

I guess this is due to the pin shapes.

Any advice? I'd like to avoid breaking anything.

Thanks!

Hello,

Just a quick heads-up - over the last few days two new chapters were added to the documentation - on the subject of VASYL interrupts, on coordinating activities between VASYL and 6510, and finally about caveats waiting for BeamRacer programmers (which also includes details of the board's low-level operation, for those interested).

More documentation is coming still this week.

The others...

seq3:


seq4:

Hi all,
below the first images of Kernal64 with BeamRacer installed (gif: 100 ms between frames).

demorb1:


demorb2:
 

demorb3:


fld:


fli:


irq:


logo:


selfmod:


seq:


seq2:


Other images on the next post due to forum message limitations.

Hi,
I would like to understand how VAYSL behaves when accessing the system bus (for example when it executes a MOV towards a VIC register) and how it can "halt" the CPU as mentioned in the FAQ.

Another point: according to the Instruction's doc., MOV will be delayed in case VIC is fetching data (e.g. badline or sprite). Is it the same for XFER (in the documentation is not mentioned)?

Thanks.

Hi all,
I'm refining the Kernal64's emulation of BeamRacer and I would like to have more details about the S_UPDATE register of PBS.
I read the Programmable Bitmap Sequencer manual but I didn't see any reference to this register.

Soon I will publish some snapshots taken from the emulator (already shared with silverdr that I want to thank for his precious support).

Thanks.

Hi!

I did not received my beamracer yet but this is a good time to train myself!
So I started to look in details at the demo_seq example which looks simple.. only displaying an imagine using Display List and the sequenc

But only looks simple

A few questions,

1. S_BASE

From the docs, S_BASE is the memory location where to fetch bitmap data from.
So, it should point to the start of the logo data right ?

But in the code I see:

MOV    VREG_PBS_BASEL, <(mhl_logo - dl_start)
MOV    VREG_PBS_BASEH, >(mhl_logo - dl_start)

Why dl_start address should be subtracted to the logo address ?


2. S_PADDING

From the docs, S_PADDING contains a 16bits value added to the bitmap sequencer's internal memory pointer at the end of every line.

What does it mean? At each rasterline, the sequencer skip n bytes. Is 1 byte representing a 8 pixels block ? Starting from the border ?
In the code it says:

; - when end-of-line reached, continue to the next byte (no padding),
MOV    VREG_PBS_PADDINGL, 0
MOV    VREG_PBS_PADDINGH, 0

Continue to the next byte, which byte ? In the logo data ? is it to create a window in the logo's data?


3. S_STEP

From the docs, S_STEP contains a 16bits value added to the bitmap sequencer's internal memory pointer after every fetch.

In the code, I understand it increments the pointer of 1 byte, so I guess it means logo's data will be written sequentially except if the step is different than 1 ? Right ?

; - fetch bytes from successive memory addresses,
MOV    VREG_PBS_STEPL, 1
MOV    VREG_PBS_STEPH, 0

So, same guess? Is it to write the logo's data in a non contiguous manner (as I guess the step is not used while reading the logo's data, only for writing)


4. PBS_CONTROL

I guess this register trigger the sequencer but I did not find in the docs how it works. Where can I find the role of each bit?

In the code:

; - apart from turning on the sequencer, we also request mirroring,
;  because the logo is in .xbm format, which for some reason stores pixels
;  in a byte using right-to-left order,
MOV    VREG_PBS_CONTROL, 1 << PBS_CONTROL_ACTIVE_BIT | PBS_CONTROL_SWIZZLE_MIRROR

In only found the values but not the meaning (I can guess some but)
PBS_CONTROL_ACTIVE_BIT = 3
PBS_CONTROL_RAMBANK_BIT = 0 ; bits 0-2
PBS_CONTROL_RAMBANK_MASK = (%111 << PBS_CONTROL_RAMBANK_BIT)
PBS_CONTROL_UPDATE_BIT = 4 ; bits 4-5
PBS_CONTROL_UPDATE_MASK = (%11 << PBS_CONTROL_UPDATE_BIT)
PBS_CONTROL_UPDATE_NONE = (%00 << PBS_CONTROL_UPDATE_BIT)
PBS_CONTROL_UPDATE_EOL = (%01 << PBS_CONTROL_UPDATE_BIT)
PBS_CONTROL_UPDATE_ALWAYS = (%10 << PBS_CONTROL_UPDATE_BIT)
PBS_CONTROL_SWIZZLE_BIT = 6 ; bits 6-7
PBS_CONTROL_SWIZZLE_MASK = (%11 << PBS_CONTROL_SWIZZLE_BIT)
PBS_CONTROL_SWIZZLE_NONE = (%00 << PBS_CONTROL_SWIZZLE_BIT)
PBS_CONTROL_SWIZZLE_MIRROR = (%01 << PBS_CONTROL_SWIZZLE_BIT)
PBS_CONTROL_SWIZZLE_MULTIMIRROR = (%10 << PBS_CONTROL_SWIZZLE_BIT)

Sorry for the dumb questions...