A blitter for the beeb?

for bbc micro/electron hardware, peripherals & programming issues (NOT emulators!)
dominicbeesley
Posts: 466
Joined: Tue Apr 30, 2013 11:16 am

Re: A blitter for the beeb?

Postby dominicbeesley » Mon Dec 04, 2017 10:23 am

Yes. That's one way of doing it...4 channels multiplexed might work also. The DAC is the easy bit in a cpld... an 8 bit plus overflow adder makes a 1 bit sad or similar for pwm. The bit that takes the room are the multipliers for volume I need to do some experimenting once I've got the DMA prioritiser working. At the moment it's all a bit thrown together and if you have sound and blit at the same time they crash each other.

jregel
Posts: 66
Joined: Fri Dec 20, 2013 6:39 pm
Location: Gloucestershire

Re: A blitter for the beeb?

Postby jregel » Mon Dec 04, 2017 8:06 pm

Just out of interest, do you have any idea how many software sprites the blitter could handle, e.g. 16x16 sprites in mode 1 or mode 2 at 50Hz?
BBC Master Turbo
Retroclinic External Datacentre
VideoNuLA

ThomasHarte
Posts: 367
Joined: Sat Dec 23, 2000 5:56 pm

Re: A blitter for the beeb?

Postby ThomasHarte » Mon Dec 04, 2017 8:38 pm

I'm late on this, but the video system of the Atari Lynx — ready for market in 1987 by many of the same designers as the Amiga, but 8-bit — is just a frame buffer and a stretching blitter. Each thing to be drawn is described by a sprite control block, and contains a link to the next sprite control block. So standard behaviour is to compose the complete list of sprite control blocks for the next frame as a single linked list, post the address to the blitter and surrender the bus.

If memory serves, a slight complexity is that the blitter is built to be interruptible. Any interrupt event will pause it and reawaken the 65SC02, which then needs actively to hand control back to the blitter when it has done whatever it wants to do.

Possibly worth investigating from the same idea pool: source sprites are optionally RLE encoded, because that tends to work well at 4bpp and so can substantially reduce the amount of memory bandwidth consumed just by reading data.

For whatever reason, the Lynx considers any address on the zero page to terminate its linked list of sprite control blocks — it tests the top byte only. So that's the one place you can't put them.

Other observations from the Lynx use case:
  • sprite position is a fixed point number, and allows a fixed point number to be added to position every row;
  • because it's a scaling blitter and also reads blitting width as a fixed point number, with a fixed point adder, it also does the complete job of line rendering (via DDA) and solid polygon filling at the cost of [usually] two control blocks per triangle, if your source image is a single block colour;
  • a blitter that didn't stretch but had a single colour output mode could therefore also provide hardware acceleration of lines and polygons just by making those two things fixed point and doing two extra additions per scan line.

If you wanted go to full Lynx you'd also need a simple maths coprocessor, to divide the BBC's screen resolution in two and to double the speed of the 6502.

Of the other 8-bit machines I'm aware of, the MSX2 also has a blitter and line drawer, but that's a bit of a weird one because the video memory is on a completely separate bus from the CPU, with only a fairly awkward bridge between the two.

dominicbeesley
Posts: 466
Joined: Tue Apr 30, 2013 11:16 am

Re: A blitter for the beeb?

Postby dominicbeesley » Fri Dec 08, 2017 12:07 pm

Thanks for the info Thomas,

I'd not considered the Lynx, I didn't know it used a blitter, I thought they were sprites.

Interesting stuff about interrupts, at the moment my blitter isn't interruptible but will be I was going to restart the blit on the first RTI but not sure that that will work as I suspect the first RTI is not the last RTI when exiting the interrupt system!

I'd thought about stretching and ruled it out due to complexity but I may give it a second look, time allowing. I like the RLE idea!

I'll have a dig for further Lynx information to see if I can find anything that helps me work this out as there seems to be interest in accelerating the GXR anything that helps with lines/triangles/polygons would help!

D

jregel
Posts: 66
Joined: Fri Dec 20, 2013 6:39 pm
Location: Gloucestershire

Re: A blitter for the beeb?

Postby jregel » Fri Dec 08, 2017 10:49 pm

To pick up on some of the points made in recent comments:

While four sound channels would be very nice, another computer to look at might be the Atari STe. The base ST model only had a Yamaha YM2149 chip (not a million miles from the Beeb), but the STe added a stereo DMA channel. It still wasn't as good as an Amiga, but a single DMA sound channel might be an easier target and still give an improved sound output.

Another sound possibility is to see what Amstrad did with the CPC+ ASIC when it added a DMA driven mechanism for feeding the existing CPC sound chip (basically the same chip as found in the ST). It looks like it can also do some sample playback. Some specs on the CPC+ ASIC here: http://www.cpcwiki.eu/index.php/Arnold_V_Specs_Revised

In terms of Lynx-like capabilities, IMHO, I think it would feel like a whole different computer vs adding little tweaks here and there to accelerate existing MOS functions (such as block copies, line drawing and filling) to enhance the original Beeb.

Final thought: One of the original requests in the original VideoNULA discussion was for the ability to generate a per-scanline interrupt (hsync). This wasn't possible on the VideoNULA based on where it is positioned in the graphics "pipeline". Would the blitter be able to generate a programmable hsync interrupt?

Just some random thoughts on a Friday evening... :-)
BBC Master Turbo
Retroclinic External Datacentre
VideoNuLA

dominicbeesley
Posts: 466
Joined: Tue Apr 30, 2013 11:16 am

Re: A blitter for the beeb?

Postby dominicbeesley » Sat Dec 09, 2017 12:23 pm

The reason for four independent channels with their own sample rate is that polyphonic sample playing then becomes pretty simple i.e. it should be possible on the beeb to play simple tracker/mods. A couple of fixed rate channels however would require a lot of processing power to do anything like that, just simple mixing/decimation/filtering that these days seems pretty basic would on a 6502 just not be on.

I get what you're saying about originality, though for me that makes a beeb a beeb is quite difficult to define but probably in reverse order of importance
- BBC BASIC
- the MOS / *commands
- buuuuuurp-beep
- the filing systems
- physical feel (heavy, solid)
- physical look
- the startup screen

The naff palette and slow processor and graphics don't really define it for me, a beeb still feels like a beeb when its running a fast copro.

I'll look at the hsync idea, I like it. It might be better though to go with an "end of DISEN" interrupt. This is what I did on my 6809 project and then you can easily count active lines...it would require a clip on probe to either DISEN or HS. The advantages of end of disen are some things become easier i.e. it only fires on active lines; it gives you a few more cycles to (say) change the palette before the next active line starts. Disadvantage is that it doesn't fire during border time, but if you want that there's always the VIA timers.

The way I set the DISEN up on the 6809 is to make it drive timer2 then palette effects / split screens etc are fairly easy, bung the number of lines to wait in TMR2 and get interrupted at that point. I'll see if that is possible in the blitter then look at maybe DMAing to the VideoNULA for quick palette changes between lines?

D

User avatar
tricky
Posts: 1920
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: A blitter for the beeb?

Postby tricky » Sat Dec 09, 2017 2:33 pm

I'm not sure how much use there is for an hsync interrupt, as it can easily be re-produced with a timer (at least non-interlaced), the problem with them is that unless you have a RAM expansion that lets you replace the OS, handling them take 30+cycles.

Knowing which line you are on without a timer might be a "nice to have" or triggering a DMA on a specific line might be better (maybe even some sort of DMA chain with waits).

Since I have only touched a few lines of code in the last few months though, it probably won't be me making use of it :(

RobC
Posts: 1823
Joined: Sat Sep 01, 2007 9:41 pm

Re: A blitter for the beeb?

Postby RobC » Sun Dec 10, 2017 9:53 pm

I think the suggestion of a hsync interrupt with VideoNuLA was to be able to trigger things at a certain point on the line (I guess to allow things like horizontal mode splits).

Having a decrementing counter based off DISEN was doable but I didn't really have the space to store any useful operations that could be triggered!

ThomasHarte
Posts: 367
Joined: Sat Dec 23, 2000 5:56 pm

Re: A blitter for the beeb?

Postby ThomasHarte » Mon Dec 11, 2017 2:44 pm

jregel wrote:To pick up on some of the points made in recent comments:

While four sound channels would be very nice, another computer to look at might be the Atari STe. The base ST model only had a Yamaha YM2149 chip (not a million miles from the Beeb), but the STe added a stereo DMA channel. It still wasn't as good as an Amiga, but a single DMA sound channel might be an easier target and still give an improved sound output.

Another sound possibility is to see what Amstrad did with the CPC+ ASIC when it added a DMA driven mechanism for feeding the existing CPC sound chip (basically the same chip as found in the ST). It looks like it can also do some sample playback. Some specs on the CPC+ ASIC here: http://www.cpcwiki.eu/index.php/Arnold_V_Specs_Revised

If memory serves, the original 1984 Macintosh also utilised its video fetching DMA for audio, but provided only a single channel, by fetching a single sample in each horizontal retrace. I recall reading that the team had to work quite hard to generate multichannel sound even on their ~8Mhz 68000. (EDIT: after some quick searching, as per this story)

jregel wrote:In terms of Lynx-like capabilities, IMHO, I think it would feel like a whole different computer vs adding little tweaks here and there to accelerate existing MOS functions (such as block copies, line drawing and filling) to enhance the original Beeb.

I don't see that any blitter implementation is inherently more like a BBC than any other.

dominicbeesley
Posts: 466
Joined: Tue Apr 30, 2013 11:16 am

Re: A blitter for the beeb?

Postby dominicbeesley » Tue Dec 12, 2017 1:15 pm

Thanks lads,

Got you Rob.

I've been ironing out bugs with the sound accesses causing pixels/bytes to drop out when copying which turned out, after about 12 hours of rewriting the state machines, testing, building probe circuits to be a "bodge" I'd put in to test something else and not removed properly :oops:

I'm going to have a quick go at getting the 4 channel sound working then next up "normal" DMA, mainly for loading the blitter's own registers but could be used for other hardware.

Later I want to have a go at getting the CPU to run from "chip ram" and just use the real BBC/Elk's memory for screen. This should give the ability to:
- 4Mhz cpu with right CPU
- run at full speed on an elk and then blit the screen data at end of a frame.
- possible full 64k(ish) RAM map with magical switch back to a regular BBC map when an interrupt or instruction fetch happens at >&FC00

It's going to be a bit of a slow burn I suspect from now on, I'm going to dig my Elk out and see if I can get that working well enough to try this out and solder a CPU socket into my M128 also....

One thing I have been pondering but not sure where to start looking is the issue of timing loops. The sound DMA can "steal" cycles from the CPU at random, up to 4 in a row. This could upset carefully constructed timing loops, what are good candidates for testing this? The current test machine is a very basic B with MMFS and has no problems so far but I suspect things like real floppy transfers might get upset if a 4 channels are playing at high sample rates?

D

dominicbeesley
Posts: 466
Joined: Tue Apr 30, 2013 11:16 am

Re: A blitter for the beeb?

Postby dominicbeesley » Fri Dec 15, 2017 7:28 pm


https://youtu.be/-EIi6XHRU0M

Apologies for the crap sound quality and bad sync, having phone problems

Thought I'd give it a go, a quick tracker player in BASIC with a small shim of assembler to quickly set registers. No effects or anything fancy...luckily my favourite tune from back in the day doesn't suffer the lack of effects.

jregel
Posts: 66
Joined: Fri Dec 20, 2013 6:39 pm
Location: Gloucestershire

Re: A blitter for the beeb?

Postby jregel » Sat Dec 16, 2017 12:46 pm

Wow - very impressive sound!

Just out of interest, how big are the samples that's playing and what rate is it playing back? Is it a proper MOD file?
BBC Master Turbo
Retroclinic External Datacentre
VideoNuLA

dominicbeesley
Posts: 466
Joined: Tue Apr 30, 2013 11:16 am

Re: A blitter for the beeb?

Postby dominicbeesley » Sat Dec 16, 2017 1:03 pm

Thanks, I'm quite surprised that it worked at all!

Each sound channel (there are 4) plays at an independent rate any from 53 samples per second to around 100000 samples per second. Each channel has a 16 bit divider (I may reduce this to 12 bits to save chip space) to set the sample "period". This means that the samples (like in .mod files and on amiga) can be played at different speeds on each channel without any cpu processing.

The tracker being played is a direct conversion of a protracker module "the frog mix". The conversion program does not much other than split the samples up into a separate set of 16k chunks for easy loading to the blitter memory and then loads the patterns and song list into main system memory. I've also renumbered the samples when doing this and there is a maximum of 16 samples but that was to make life easier for the BASIC player it is not a hardware limit.

At the moment each sample causes the cpu to skip a single 2MHz cycle while the sample is fetched. This means that the cpu slows a little when playing samples but even with all 4 channels going at 16kHz its about 3%. I need to have a look at this as it should be possible to fetch sample data from blit RAM transparently. It was just easier to halt the CPU and other blit operations altogether while I got it working!

I'm going to spend a little time messing with the play routine to see if there's anything that I need to add to the hardware other than what is listed below:

Things missing from the player:
- nearly everthing, it only plays notes with both a sample no and period at the mo, but I will look at a fuller assembler implementation

Things that are missing from the hardware:
- proper sample repeats like in a tracker
- overall volume
- "transparent" blit RAM accesses

I'll see if I get any time this side of Christmas and I'll try and make a better recording next time!


Return to “hardware”

Who is online

Users browsing this forum: ilcook and 13 guests