Palettemate / enhanced video ULA with 4096 colours

[jgharston]

For instance, flashing colours can easily be done by writing the pallete on every x VSync events. Somewhere I've got code that does this to allow non-completementary flashing on the Beeb (eg Red/Blue, Red/White, Black/Yellow) instead of the built-in complementary flashing (eg Red/Cyan, Black/White, Blue/Yellow).

Found it!

Code: Select all

   10 REM > Flash
   20 REM Non-complementary flashing
   30 REM Only works 16-colour MODE
   40 :
   50 MODE &82
   60 DIM mcode% 256
   70 eventv=&220
   80 palette=&36F
   90 FOR P=0 TO 1
  100   P%=mcode%
  110   [OPT P*2
  120   .event
  130   CMP #4:BEQ vsync
  140   .oldevent
  150   JMP 0
  160   .vsync
  170   LDA &251:CMP #1:BNE oldvsync  :\ flash counter
  180   TXA:PHA:LDX #15
  190   .loop
  200   LDA palette,X
  210   LSR A:LSR A:LSR A:LSR A       :\ Flip colours
  220   EOR palette,X:STA palette,X
  230   AND #&0F:EOR #&07:STA temp    :\ A=physical colour
  240   TXA:ASL A:ASL A:ASL A:ASL A   :\ A=%llll0000
  250   ORA temp:STA &FE21            :\ A=%llllpppp
  260   DEX:BPL loop
  270   PLA:TAX
  280   .oldvsync
  290   LDA #4:JMP oldevent
  300   .temp :EQUB 0
  310   ]NEXT
  320 :
  330 IF eventv?1<&80:END
  340 oldevent?1=eventv?0
  350 oldevent?2=eventv?1
  360 eventv?0=event AND 255
  370 eventv?1=event DIV 255
  380 *FX14,4

Run it. Then do ?&36F=&10. Flashing black and red!

The top nybble of each palette entry at &36F-&37E is EOR'd with the bottom nybble on each flash timeout, so you can do ?(&36F+logical)=colour1 + 16*(colour1 EOR colour2) to flash between any two physical colours.

Edit: demo!

[tom_seddon]

Those screenshots look amazing :D

Random ideas: (N.B., this is all idle rambling... it could all be stupid, and I have no idea how easy any of this would be to implement!)

- fix the nasty effects so they do something actually useful. Like, at the moment, the ULA behaves the same in every mode, always looking up from bits 7/5/3/1 and shifting the value as it goes - but ideally it should work differently, by masking off irrelevant lower bits before looking up in its palette, and using the original bit indexes. So in Mode 0/3/4/6, bit N should select between palette entries N and N|8; in Mode 1/5, bits 7/4 should ideally select between palette entries 3/7/11/15, bits 6/4 select 2/6/10/14, and so on. This gives you 16 colours on screen in any mode, like the current ULA, but (unlike the current ULA) it's in a vaguely useful fashion.

- if you've got 4096 colours, and you don't mind it taking up to 3 writes to set 1 colour, you could make it quicker to initialize the palette. Suppose the system were like this:

You write %1100iiii to select index I for writing.

(This leaves values of the form %11xxyyyy where xx!=0, so you've got room for some control codes or what have you.)

You write %00RrGgBb to set index I's RGB to %RrRr,%GgGg,%BbBb, with post-increment of I (this lets you select one of 64 useful colours per write, and lets you write the entire palette with 16 writes)

You write %01rrggbb to set bits 2/3 of the RGB values to %rr,%gg,%bb.

You write %10rrggbb to set bits 0/1 of the RGB values to %rr,%gg,%bb.

So you can quickly reset the palette to something useful by writing %11000000 then repeated %00xxxxxx (1 write per entry), or get finer control over arbitrary palette indexes by writing %1100nnnn, then %01xxxxxx/%10xxxxxx. (Maybe one of those should auto-increment, too; perhaps %01xxxxxx should expand into the lower bits; etc.)

The choice of bits 7+6 is mostly arbitrary but it seemed like you might want them to be %00xxxxxx for the fast path as it'll save you an instruction if you've been calculating them or combining them from their individual components.

- a similar scheme could apply to (say) 4 palettes of 512 colours.

You write %11ppiiii to select index I of palette P for writing.

You write %00RrGgBb as above, this time writing %RrR,%GgG,%BbB to that index.

You write %01rrggbb to set bits 1/2

You write %10000rgb to set bits 0

This then leaves %10xxxyyy where x!=0 for control codes. So maybe you write %100010pp to select palette p or what have you.

I like the sound of multiple palettes.

- smooth horizontal scrolling - buffer 1 byte and delay its data by some number of pixels? You'd need to display 1 blank byte on each side of the screen though, I think... or maybe just at one side. Hmm... I need to think about this more.

--Tom

[RobC]

Thanks Tom - I'll need to read through this carefully to make sure I understand it! I would welcome more thoughts on horizontal scrolling as I can then get an idea of how much space it'll take up.

My concern with playing around with the "nasty effects" is that some existing software relies on the current behaviour. It would be possible to toggle between the original and new behaviour but that'll take up more logic and might possibly push out other features.

Once I've sorted out mode 7 (hopefully today), I'll know how much space is left and then can start to think about these additional features. However, I also need to start work on the PCB layout so it's a toss up as to which I start first...

[danielj]

Looking very good!

[sbadger]

The screenshots look unbeliveable! I brought my memory screaming back to a post I read years ago (2009).

I managed to find it !


BBC Micro Pallette Project http://pixelation.org/index.php?topic=8408.0


exile proposal



simcity

Being a lover of exile, I'm pretty excited of the potential of this project.

[Lardo Boffin]

This all looks awesome. I wish I understood 10% of it!

[1024MAK]

Once I've sorted out mode 7 (hopefully today), I'll know how much space is left and then can start to think about these additional features. However, I also need to start work on the PCB layout so it's a toss up as to which I start first...

Suggestion: Group into primary features and additional features. Once you have the primary features developed, start work on the PCB layout. Then you can devote most of your time to this. If an idea crops up that may help with an additional feature, make notes, then continue with the PCB layout. Once done, you can look again at what additional features are possible.

Otherwise feature creep will distract you too much. And as much as it would be nice to "have everything", that everything will keep expanding as people throw their ideas in....

Mark

[RobC]

Suggestion: Group into primary features and additional features. Once you have the primary features developed, start work on the PCB layout. Then you can devote most of your time to this. If an idea crops up that may help with an additional feature, make notes, then continue with the PCB layout. Once done, you can look again at what additional features are possible.

Thanks Mark - that's exactly what I'm doing. Sorting out mode 7 and the other minor bugs in the standard ULA implementation before moving on to the PCB.

None of the additional features suggested so far impact on the PCB design. (Apart possibly from palette size and that can be handled by incorporating 4-bit DACs and not using them if the final palette is smaller.)

[simonm]

Would it be possible with this system to use the colour interrupt technique to poke new palettes during the raster? Given all the recent innovations with 8-colour Mode1 trickery, having access to 4096 colours could pave the way for some truly amazing graphics.
This project is unbelievably exciting!

[guesser]

Is there still time to throw in feature suggestions before the feature creep window is closed off?

No idea if this is remotely feasible but since you're mentioning 12 bit colour palettes and Mode 7 graphics, is there any possibility of storing a pair of two bit values for each character cell somewhere and using those to remap the foreground and background colours for the corresponding cell in mode 7 from four colour look up tables?

That is the method used to address 4096 available colours for higher level teletext transmissions to allow more than 8 colours on screen simultaneously.

[kieranhj]

Would it be possible with this system to use the colour interrupt technique to poke new palettes during the raster? Given all the recent innovations with 8-colour Mode1 trickery, having access to 4096 colours could pave the way for some truly amazing graphics.
This project is unbelievably exciting!

If we're on the topic of wish-lists then having a hsync interrupt ala C64 would be immense.

[tricky]

With regard to horizontal scrolling, I think you are working from what is being output plus a delayed flash bit.
For the Frogger game I wrote, I use vertical rupture to have 32 "screens" per field so that I can hide part of each horizontal row, which allows me to draw sprites without having to clip them at the screen edges. This effect can be achieved as I have, but if it was small enough, it might be a nice to have feature as I guess it really *only* needs a counter.
To support horizontal scrolling, you need to be able to shift up to and including 1 byte (which in mode 8 is 1/20 the usual visible width - I think).
The finer the delay granularity, the smoother the scrolling, but sub mode 5/2 pixels would be good.

[RobC]

Would it be possible with this system to use the colour interrupt technique to poke new palettes during the raster? Given all the recent innovations with 8-colour Mode1 trickery, having access to 4096 colours could pave the way for some truly amazing graphics.
This project is unbelievably exciting!

Yes - this is possible with the hardware as it stands. In one of my earlier posts, I mentioned that it might be possible to redefine up to 10 colours per scanline but I haven't tried coding it yet.

I'll try to knock up a demo over the weekend. I was thinking of something like mode 2, 8 colours per scanline and redefining the whole palette over two scanlines to give 2048 colours on screen.

Is there still time to throw in feature suggestions before the feature creep window is closed off?

Yes - happy to receive suggestions but my initial focus is on fixing bugs in the current implementation and then designing the PCB.

No idea if this is remotely feasible but since you're mentioning 12 bit colour palettes and Mode 7 graphics, is there any possibility of storing a pair of two bit values for each character cell somewhere and using those to remap the foreground and background colours for the corresponding cell in mode 7 from four colour look up tables?

Unfortunately, there just isn't enough space for this in the current hardware. I'm only using a CPLD as I worked out that it was large enough to mimic the original Palettemate.

However, as mentioned above, you can remap colours in mode 7 and use interrupts to modify them as the display is rastered.

If we're on the topic of wish-lists then having a hsync interrupt ala C64 would be immense.

Hsync is generated by the 6845 and doesn't go to the video ULA but it would certainly be possible to output something based on DISEN. However, the issue would be where to map the signal map to - the video ULA is write only.

[RobC]

With regard to horizontal scrolling, I think you are working from what is being output plus a delayed flash bit.
For the Frogger game I wrote, I use vertical rupture to have 32 "screens" per field so that I can hide part of each horizontal row, which allows me to draw sprites without having to clip them at the screen edges. This effect can be achieved as I have, but if it was small enough, it might be a nice to have feature as I guess it really *only* needs a counter.
To support horizontal scrolling, you need to be able to shift up to and including 1 byte (which in mode 8 is 1/20 the usual visible width - I think).
The finer the delay granularity, the smoother the scrolling, but sub mode 5/2 pixels would be good.

I've got about 100 LEs still available in the EPM570 and so delaying pixel data for a few clocks should fit easily.

I'm already delaying DISEN a variable amount so that the border is displayed in the right place. I think that a simple expansion of this will allow blanking of columns/wider borders. I previously had a slight bug in this but I fixed it (and improved mode 7 reliability) today.

[jgharston]

If we're on the topic of wish-lists then having a hsync interrupt ala C64 would be immense.

There already is an HSync interupt- Event number 4. That's what my non-complementary flash code uses.

On the subject of the writing the colour data, would it be easier to use four writes with each colour component instead of two writes? Something like this:

Code: Select all

FE23                                   FE22
%00xxllll logical colour number        %00xxpppp physical border colour
%01xxrrrr red colour component         %01xxrrrr border red colour component
%10xxgggg green colour component       %10xxgggg border green colour component
%11xxbbbb blue colour component        %11xxbbbb border blue colour component

It would mean the hardware doesn't have to keep track of whether it's a first write or a second write, and makes software easier as all three colour component accesses are the same without having to merge the green and blue for the second write.

Code: Select all

  LDA &31F:AND #&0F:STA &FE23               :\ logical colour
  LDY #1                                    :\ 1=colour, 0=border
  LDX #3                                    :\ 3 colour components
  .loop
  TXA:ASL A:EOR &320,X:AND #&06:EOR &320,X  :\ A=%76543cc0
  ROR A:ROR A:ROR A:ROR A                   :\ A=%cc0-7654
  AND #&CF:EOR #&0F:STA &FE23,Y             :\ A=%cc007654
  DEX:BNE loop

[simonm]

Do you think there might be some way for a hardware mod like this to be detected in software somehow? So that any code that uses it can be enabled or disabled accordingly only if it is present?

[RobC]

There already is an HSync interupt- Event number 4. That's what my non-complementary flash code uses..

That's VSync which fires every frame. HSync fires every scanline so it can be used to trigger effects that change from line to line.

[RobC]

Do you think there might be some way for a hardware mod like this to be detected in software somehow? So that any code that uses it can be enabled or disabled accordingly only if it is present?

Not in hardware as the video ULA is write only so its registers can't be read. Supplying a ROM with the hardware would allow the detection of the relevant software though.

Also, if the hardware isn't there, the physical colours aren't mapped. So, you could just set the colours up appropriately for a standard Beeb and then map them in case the extra palette is available.

[jgharston]

There already is an HSync interupt- Event number 4. That's what my non-complementary flash code uses..

That's VSync which fires every frame. HSync fires every scanline so it can be used to trigger effects that change from line to line.

D'oh! Insufficient tea error.

There's a way to do it in software, though. On HSync set up a VIA timer to give an IRQ every 64us. That's 128 clocks, so load the countdown timer with -128. You'd also need to connect to IRQ1V to respond as fast as possible in the short time available.

[kieranhj]

D'oh! Insufficient tea error.

There's a way to do it in software, though. On HSync set up a VIA timer to give an IRQ every 64us. That's 128 clocks, so load the countdown timer with -128. You'd also need to connect to IRQ1V to respond as fast as possible in the short time available.

I just had my afternoon cup of Yorkshire.

Yeah, a 64us IRQ is possible with latched Timer 1 but painful as there is very little time to do anything in the callback. It also shifts quite a lot depending on which other interrupts are still enabled. The only way to get a truly stable raster would be to turn all interrupts off and use a pure cycle counting approach, which is what I believe many of the C64 demos do.

I was actually thinking about the Amiga hsync which enables interrupts to be fired when the raster hits an exact horizontal position on the screen but again with so few cycles available it's probably of limited use on the Beeb.

The other thing I realised is that that the 6845 + ULA run at 16Mhz but writes are made at 2Mhz therefore changes (e.g. to palette) can only take effect at 8 pixel intervals, which kind of defeats the goal of knowing exactly where in the horizontal the raster beam is.

Need to downgrade my expectations for how much I can squeeze out of the humble Beeb. (Although doesn't seem to stop Tricky )

[Rich Talbot-Watkins]

Even without an actual HSync interrupt on a given line number, it's possible to do this kind of thing with the timers, just a bit more complicated. Exile's a great example of using a palette switch on an exact screen line to render the water level. Sphere of Destiny even does it multiple times to animate the track.

[kieranhj]

Even without an actual HSync interrupt on a given line number, it's possible to do this kind of thing with the timers, just a bit more complicated. Exile's a great example of using a palette switch on an exact screen line to render the water level. Sphere of Destiny even does it multiple times to animate the track.

Yes, exact line palette switch is fun. I was hoping for exact mid-line palette switch, for what I'm not exactly sure yet! On reflection, I don't think this would be as useful as imagined, at least with the limitations of 8-bit video hardware.

Sorry, I've derailed Rob's thread a little.

[Rich Talbot-Watkins]

Ah right yeah! Didn't read your post properly! It's definitely possible, but very very tricky with the varying interrupt latency. I've definitely had stable mid-line raster effects working before, but it locks up the whole machine to do it, unsurprisingly!

After palette improvements, my number 2 request would be some kind of fractional horizontal offset feature - wouldn't have to be an "any pixel position" scroll offset, just something to offset pixels within the byte, which sounds like a more feasible function of a Video ULA replacement. Not 100% sure how it would work; it would need to delay the output by shifting the display more to the right. It would also have to have an option to mask the left and right columns. Combined with regular horizontal hardware scrolling with the CRTC, that'd be absolutely amazing for horizontally scrolling games.

Hardware sprites would be good too. Sod it, can't we just put a VIC-II in a Beeb?

[RobC]

I reckon that some sort of horizontal scrolling should be do-able with what's left (and possibly border colour control too).

I've already got something that controls the blanking by delaying DISEN and delaying the pixels/screen won't take up much room. The only thing to work out is how to control the whole thing.

As for sprites, I'd be tempted to say they belong in a re-implemented 6845!

[sydney]

I just want to say I'm loving this project. I was thinking about building a chameleon board but don't think I'll bother now. The graphics you posted earlier were amazing - especially Strykers run.

As for sprites, I'd be tempted to say they belong in a re-implemented 6845!

Glad to see your planning your next project already!

[jgharston]

I've already got something that controls the blanking by delaying DISEN and delaying the pixels/screen won't take up much room. The only thing to work out is how to control the whole thing.

As in, the CPU talking to it? How about, writes to &FE22/3:
%xx00xxxxxx - palette control
%xx01xxxxxx - something else
%xx10xxxxxx - something else
%xx11xxxxxx - something else
expanding from my previous post of
%0000llll - logical colour to program, %0100rrrr, %1000gggg, %1100bbbb - colour component to program.

Or drop the bits down and have:
%00xxxxxxxx - palette control
%01xxxxxxxx - something else
%10xxxxxxxx - something else
%11xxxxxxxx - something else
giving
%0000llll - logical colour to program, %0001rrrr, %0010gggg, %0011bbbb - colour component to program.

Hmmm. That second arrangement is looking very nice to program.

As for sprites, I'd be tempted to say they belong in a re-implemented 6845!

You'd almost end up implementing the HD63484 ACRTC from the Prisma.

[atcurtis]

As for sprites, I'd be tempted to say they belong in a re-implemented 6845!

You'd almost end up implementing the HD63484 ACRTC from the Prisma.

Looked at the datasheet for the ACRTC for the first time and wow, it's a pretty sophisticated beastie.

It would almost be tempting to reimplement the CRTC MUX to incorporate a DMAC in some way but would need to steal some additional IO space from somewhere for that. It would be nice to be able to have DMA for faster device IO.

[Rich Talbot-Watkins]

OK, I've just caught up with the thread properly. It's really super cool what you're doing Rob, really exciting bit of hardware

• Regarding the register interface, my preference would be to have it require the fewest writes necessary to reprogram a physical colour. As we already know, changing all the colours per scanline in Mode 1 isn't possible as it requires 16 writes and that just doesn't work within the horizontal border period, so doing it in 2 if possible would be great! jgh's idea is very tidy, but 4 writes to change a colour will leave us with the same problems as before.

• Border would also be a cool thing to be able to change, though slightly lower in the priority list for me. If something has to go, I'd say it ought to be that!

• For me, to not support horizontal pixel offset would be an absolute travesty of a missed opportunity! Having thought about it a little more, it'd need two features:
  1. the ability to specify a pixel delay 0-7. There are a couple of possibilities for the meaning of this - either the delay is in ticks as per the shift register rate (so different for different pixel depth modes, meaning that only 0-1 would be valid for 4bpp for example), or it's in 16MHz ticks and you could offset by sub-pixel amounts in more colourful modes. Whatever's simplest to implement I guess. Presumably you'd need to latch incoming CRTC data, maybe you'd need to impose an extra byte delay regardless, so there'd be something in the latch if the pixel delay were 0.
  2. the ability to blank the leftmost column, essentially an extra byte delay after DISEN goes high, so that the left hand border is steady. Not sure how you could tell that DISEN is from after the left border, perhaps there's a way, or perhaps you just always delay it on a rising edge. The right hand border would presumably be fixed by the CRTC setting DISEN low after the horizontal displayed counter is reached, regardless of the pixel delay set in the ULA.

• "Some nasty effects" - I like Tom's idea to rationalise this a bit! Essentially having it well defined so that each pixel column within the byte got looked up from a consistent palette index would be perhaps a little more exploitable. It's true that some games use this, but their graphics aren't designed around the results, they just do it to randomly add extra colour, so I don't think anything would be lost by doing it differently. Not sure how much logic it would need to achieve that.

In terms of the memory mapped register model, I'd keep &FE23 as it is (always two writes required, first specifies physical colour index + 4 bit red, second specifies 4 bit green + 4 bit blue, writes to &FE20/&FE21 reset the latch).

I'd implement &FE22 as a more general purpose thing as has been suggested, top nibble = function, bottom nibble = data. Some platforms from back in the day weren't able to specify a free-form border colour, instead they had to specify it as an index in the current palette. I'd suggest that this would work perfectly well here too, and would mean that &FE22 would just be a write once register, not requiring any additional queueing logic.

And yes, for the future, a 6845 replacement that could also handle hardware sprites - that's the stuff of dreams!

I would love to have some real hardware right now, just to be able to try this out. On an emulator, it's just not the same! And I've been waiting 30 years for this!!!!

[tricky]

It would be slightly neater to have the delay 1 to 8 so that the first column is completely hidden to hide updates.

[Rich Talbot-Watkins]

I wondered that myself, but concluded it'd be weird not to be able to set it to 'normal'. I'm not sure it really makes any difference anyway, you can do the same with range 0-7 as with 1-8.

Rob, are you going to publish the source code when it's completed?