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

A blitter for the beeb?

Postby dominicbeesley » Tue Nov 28, 2017 1:14 am

Evening all,

I started work a while back on a basic DMA controller and basic sound chip for my mk.2 6809 project which over the past month has morphed into a blitter chip for the BBC Micro. (For those who haven't heard of a blitter it is a chip that can copy memory from one place to another very quickly and optionally perform graphics operations). This is all based loosely on the Amiga's blitter chip: http://amigadev.elowar.com/read/ADCD_2. ... e0119.html

I didn't want to discuss this until I'd proved to myself that it was possible. It is!

In the (hastily thrown together) demo video it is:

copying a block of graphics 320x48 pixels from a save area (for the scroller background)
plotting 8 or 9 32x48 pixel sprites, with masks to the shadow RAM
copying the whole mode 2 screen from shadow RAM to screen RAM

It manages this in 19ms and runs at 50fps. [The colours are courtesy of RobC's excellent VideoNULA.]

I've kept this simple enough to hopefully fit on a Max II CPLD, I'm not sure how "authentic" it is (i.e. how realistic would it have been in the 1980s) but I can't see why it wouldn't squeeze onto a custom ASIC or maybe a pair of ULA's...the memory is nothing particularly special (other than the size) it runs at 4MHz.



I'm not sure how much interest there would be in such a thing. I will probably make a handful of boards up in the next couple of months for testing if anyone is interested. I'm sure in the hands of a decent 6502 games programmer some really spectacular stuff could be achieved.

The PoC setup is a de0nano sitting on a xeropage level shifter board. The 6502 cpu is a soft-core at the moment but my aim is to interface a real cpu. The blitter chip itself has taken some debugging but the most difficult part was getting the SDRAM on the DE0 nano to work nicely.

The machine is a model B with MMFS, VideoNULA and this prototype, all the mad connectors, wires etc are my test equipment.

The idea would be a small board that sits in the CPU socket (on a model B) the 6502 would then plug back into the board. The daughter board would carry a couple of level shifters and a CPLD and some (128 or maybe 512k of SRAM).

There's a number of things not yet finished for the blitter:
- reverse blitting (for copying overlapping regions) *
- rearrange registers (there are 30 bytes of registers) for more convenient/fast changes where only a couple of values change *
- interleave CPU / blitter operations (currently the CPU is halted during a blit) *
- rearrange register access to index/value (like 6845) to pollute FRED less?
- load registers using DMA from memory? for small sprites loading the registers take longer than the actual blit!
- special effect registers to control X/Y single/multi pixel stepping
- reads to / from ROM and hardware addresses [timing issues, not tested]
- optionally expose memory in JIM [was working but I broke it, not sure its worth keeping]
- execute code from the blitter RAM (could be used to run cpu at 4MHz when not blitting?)
- write thru/fifo to system/screen RAM when CPU executing in blitter RAM (Elk/myelin?) this would require a bit of extra work to wait for the Elk to catch up in "big" modes?
- sound samples 4x channels?
- take over/respond to NMI line for fast/background disk/econet/tube transfers?
- multiple CPUs? (CMOS, NMOS, 6809) - probably a step too far.
- support rom, API, documentation, etc
- use blitter ram as SWRAM
- sprite collision detection (Z flag, write inhibit) *
- address wrapping (this needed when hardware scrolling has made the screen boundaries odd) at the moment one has to split the plots up over the screen address wrap. *
- final address adjust - at present the blitter always exits with screen pointers pointing at the screen address to the left and below the last thing plotted. It would be nice to be able to pick to exit with addresses ready for plotting to the top right.

* features are "must haves" rest maybe not that important?

This works much like the Amiga blitter except there are several extra challenges introduced by the BBC's screen memory layout. On the Amiga everything is in nice bit planes, the beeb is in character cells so moving down a line is either +1 or +640 depending on the line. That adds a fair amount of complexity to the address generators

I also wanted to keep the mask as 1 bit per pixel for space reasons and to be able to render bitmap fonts in all modes. This has led to a few extras to "explode" the mask data and only load a mask on n transition where (n=1 for mode 0, 2 for mode 1, 4 for mode 2, 8 for mode X - mode X doesn't exist on the beeb but will on the 6809 with 256 colours). This requires an extra shift register and an exploder mux for the mask channel. If this proves to use up too much space in the final design I may have to look at pipelining the shift operations somehow...

To keep things moving a full speed when plotting to system RAM (which can only be accessed at 2MHz as opposed to 4MHz) the mask is read first then the existing screen data, then the sprite data, then the screen data is written out. This allows blits to the screen at approaching 2M pixels per second in mode2 or copies from blitter ram to screen at 4M pixels per second by interleaving the blitter ram accesses into phi1 and the system memory accesses into phi2

So any thoughts or questions? Any interest in making this for a wider audience?

D
Last edited by dominicbeesley on Tue Nov 28, 2017 11:08 am, edited 1 time in total.

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

Re: A blitter for the beeb?

Postby tricky » Tue Nov 28, 2017 7:24 am

That's a great piece of work. =D>

Do you know if there was much use of the GXR made in the beeb or even the version built in to the master?
If there was, then an accelerated version included with the board may give a little backwards compatibility.

When I suggested sprites for the NULA, the first thing someone asked about was sprite collision, I guess if you have spare memory and "CPU", that might be an option given that you have bit masks.

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

Re: A blitter for the beeb?

Postby RobC » Tue Nov 28, 2017 7:56 am

This is excellent - it's amazing seeing hardware sprites on a Beeb =D>

I'll definitely be interested in some boards!

As for suggestions, I'd also go for collision detection if possible. And is it possible to cope with custom modes e.g 256 pixels wide rather than 320 etc. ?

User avatar
vanpeebles
Posts: 398
Joined: Wed Nov 28, 2012 10:01 am
Location: UK
Contact:

Re: A blitter for the beeb?

Postby vanpeebles » Tue Nov 28, 2017 10:26 am

:shock: :shock: :shock: :shock:

User avatar
Lardo Boffin
Posts: 673
Joined: Thu Aug 06, 2015 6:47 am

Re: A blitter for the beeb?

Postby Lardo Boffin » Tue Nov 28, 2017 11:03 am

Blimey - that is impressive! =D>
BBC model B 32k issue 4, 16k sideways RAM, Watford 12 ROM board, Retroclinic Datacentre + HDD, matchbox co-proc, Viglen twin 40/80 5.25" discs, acorn cassette
BBC model B 32k issue 7, turboMMC, Opus Challenger 3 512k, Pi 3 coproc, Acorn 6502 coproc

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

Re: A blitter for the beeb?

Postby dominicbeesley » Tue Nov 28, 2017 11:08 am

Thanks everyone,

I'd forgotten the GXR - I used it brielfy at school for some project or other but wasn't impressed as it moved PAGE and stopped my games working! I'll have a look when/if I get round to a support rom at least supporting the sprite PLOT codes if they fit in easily with the blitter's world-view.

Any graphics mode should be possible so long as each "cell" starts on an 8 byte boundary. The "stride" (i.e. 640 for mode 2) can be changed to any value.

Sprite collision will be possible, it's not finished now (I need to decide which register to use) but there will be a single bit that is set if any non-zero data is output (output can also be inhibited). So it will be possible to either detect a collision with existing screen data or between two masks. Using the function generator it should also be possible to ignore certain bits in existing screen data so make "baddies" colours 8-15 and ignore background.

I need to add the following to the TODO list at the top:
- sprite collision detection (Z flag, write inhibit)
- address wrapping (this needed when hardware scrolling has made the screen boundaries odd) at the moment one has to split the plots up over the screen address wrap.
- final address adjust - at present the blitter always exits with screen pointers pointing at the screen address to the left and below the last thing plotted. It would be nice to be able to pick to exit with addresses ready for plotting to the top right.

paulb
Posts: 784
Joined: Mon Jan 20, 2014 9:02 pm

Re: A blitter for the beeb?

Postby paulb » Tue Nov 28, 2017 12:20 pm

dominicbeesley wrote:I started work a while back on a basic DMA controller and basic sound chip for my mk.2 6809 project which over the past month has morphed into a blitter chip for the BBC Micro. (For those who haven't heard of a blitter it is a chip that can copy memory from one place to another very quickly and optionally perform graphics operations). This is all based loosely on the Amiga's blitter chip: http://amigadev.elowar.com/read/ADCD_2. ... e0119.html


This looks rather nice. I've never looked at the Amiga's hardware in any depth, but I did look at the extra hardware used by the NES for this kind of thing, mostly to confirm some ideas about various 6502 mechanisms. I did have vague plans about doing DMA on the Electron, but just haven't got round to it yet. (Such plans were going to be very simple at first because they would be using 7400-series logic, not programmable logic arrays.)

My approach on the Electron would be to connect some hardware to the expansion connector (the cartridge port not exposing all the address lines appropriately) and then schedule transfers using RDY#. Is this what you are doing? On the Electron, you'd probably want to detect periods where the ULA isn't wanting to access RAM itself, and this might be easier in modes 0 to 3 because the CPU clock would actually be suspended and thus the test for ULA activity would be much easier.

Anyway, some thoughts about the details...

dominicbeesley wrote:- load registers using DMA from memory? for small sprites loading the registers take longer than the actual blit!


My plan was to use descriptors, perhaps even in zero page for simplicity, so that the DMA controller may actually load the descriptor data into its own registers itself. So, one would write an address to an exposed register (write &70 to &FCxx, say) and then the controller would transfer the descriptor (from &70-&76, perhaps, providing source address, target address, length, and so on), then actually do the transfer (using the descriptor's addresses). This would be a lot more efficient than having to do CPU-led writes (and reads of the values, and loading of the instructions, of course) because the controller would just get to work performing back-to-back loads from descriptor addresses.

Also, on the Electron, an efficient DMA controller could access RAM at 2MHz, like the ULA, whereas the CPU can only manage 1MHz access to RAM via the ULA. So, getting data into the controller would be massively faster this way, albeit complicating the implementation somewhat. And even if the sprite data were in RAM, which is what I had in mind, this copying would be massively faster than any CPU-driven blitting due to eliminating instruction traffic and being able to access RAM at the faster rate.

dominicbeesley wrote:- special effect registers to control X/Y single/multi pixel stepping


As you mention with regard to the screen layout, I'd envisaged stepping by 1 (vertical) or 8 (horizontal), with some complications necessary if supporting the vertical traversal of character line boundaries.

dominicbeesley wrote:- take over/respond to NMI line for fast/background disk/econet/tube transfers?


The clock detection I noted above would also observe NMI and IRQ conditions.

I hadn't thought about sprites too much, given that such things become the preserve of programmable logic, but I would envisage a similar transfer mechanism for "uploading" sprite data as that used to transfer descriptor details.

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

Re: A blitter for the beeb?

Postby dominicbeesley » Tue Nov 28, 2017 12:59 pm

paulb wrote:This looks rather nice.... I did look at the extra hardware used by the NES


Thanks!

I didn't look at the NES, I may this afternoon...

paulb wrote:My approach on the Electron would be to connect some hardware to the expansion connector (the cartridge port not exposing all the address lines appropriately) and then schedule transfers using RDY#. Is this what you are doing? On the Electron, you'd probably want to detect periods where the ULA isn't wanting to access RAM itself, and this might be easier in modes 0 to 3 because the CPU clock would actually be suspended and thus the test for ULA activity would be much easier.


I do use /RDY and /SYNC to hold the CPU. However, I also need to detach the CPU's address lines when blitting to/from system RAM as there is no way to tell an NMOS cpu to leave go the address and RnW lines. That's why at the moment it lives in the CPU socket. So unless there is some way of taking over the address lines from the expansion port I think that that is ruled out.

paulb wrote:My plan was to use descriptors, perhaps even in zero page for simplicity, so that the DMA controller may actually load the descriptor data into its own registers itself...

That's the idea, though I'd make it any address in RAM rather than zero page. I've got to do a lot of driving next week so will have a think about it but at the moment writing register 0 sets of a blit.

If I make an index/value register pair, and make the index auto-decrement then it should be possible to point a DMA channel at the in memory block and the destination as the single value reg. Putting the most frequently updated registers at the base of the range would make for a quicker setup...

paulb wrote:Also, on the Electron, an efficient DMA controller could access RAM at 2MHz, like the ULA, whereas the CPU can only manage 1MHz access to RAM via the ULA.


I'm not sure how that would work. I need to have a proper look at the Elk but I'm not sure how anything could access memory without going through the ULA and hence have same restrictions?

paulb wrote:As you mention with regard to the screen layout, I'd envisaged stepping by 1 (vertical) or 8 (horizontal), with some complications necessary if supporting the vertical traversal of character line boundaries.

There are signed "stride" registers used at the end of each line (in linear mode) or the end of each row of character cells in cell mode. To get special effects I need to add signed "step" (to allow flip order of bytes horizontally) and a special "cell" stride register but that might just be over-egging the pudding to get some little used effects. (i.e. copy but skip rows, copy reversing bytes, block copy same order but starting at end). I'll probably just stick with a "reverse" bit which will reverse all address and shift operations to allow overlapping blocks to be copied.

paulb wrote:I hadn't thought about sprites too much, given that such things become the preserve of programmable logic, but I would envisage a similar transfer mechanism for "uploading" sprite data as that used to transfer descriptor details.


This was what I was messing around with JIM transfers for. However, that is discounted now on compatibility issues and also speed OSGBPB is too slow to transfer large graphics.

How I'm loading data up to blit RAM is to copy it to main RAM and blit from main to blit ram in linear mode. For instance the demo font is a 256x192 bitmap (24k) which is loaded to main ram at &2000 then copied up to blit RAM. Mask is 6k which is loaded separately...etc slightly laborious but fastish.

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

Re: A blitter for the beeb?

Postby dominicbeesley » Tue Nov 28, 2017 1:16 pm

A quick question for Elk/Master experts:

On the beeb the design of this is somewhat simplified (in timing terms) by the fact that I can perform writes to main RAM not registered on phi2 i.e. RnW goes high a little early / late depending on clock jitter.

Will this work on the Elk/Master or will I need to hold RnW (and D, A) after phi2 goes low...that would require some extra registers to latch A,D,RnW during phi2 and hold until some time during phi1.

D

paulb
Posts: 784
Joined: Mon Jan 20, 2014 9:02 pm

Re: A blitter for the beeb?

Postby paulb » Tue Nov 28, 2017 1:53 pm

paulb wrote:On the Electron, you'd probably want to detect periods where the ULA isn't wanting to access RAM itself, and this might be easier in modes 0 to 3 because the CPU clock would actually be suspended and thus the test for ULA activity would be much easier.


I just remembered that since the DMA controller could just steal cycles from the CPU, it wouldn't be necessary to do clock detection in a simple arrangement: the controller just suspends the CPU and uses the cycles generated by the ULA. But for non-CPU cycles, where the ULA is idle, you'd need more sophisticated techniques, and there might also need to be some way of getting a 2MHz clock generated. So, on the Electron, perhaps only 1MHz transfers would be realistic.

User avatar
marcusjambler
Posts: 131
Joined: Mon May 22, 2017 11:20 am
Location: Bradford
Contact:

Re: A blitter for the beeb?

Postby marcusjambler » Tue Nov 28, 2017 1:58 pm

:shock: =D> =D>
This is great!!

paulb
Posts: 784
Joined: Mon Jan 20, 2014 9:02 pm

Re: A blitter for the beeb?

Postby paulb » Tue Nov 28, 2017 3:40 pm

dominicbeesley wrote:I do use /RDY and /SYNC to hold the CPU. However, I also need to detach the CPU's address lines when blitting to/from system RAM as there is no way to tell an NMOS cpu to leave go the address and RnW lines. That's why at the moment it lives in the CPU socket. So unless there is some way of taking over the address lines from the expansion port I think that that is ruled out.


Is this NMOS limitation documented somewhere? I've read remarks about RDY# (/RDY, whatever) not being usable on the Electron due to the CPU only being suspended when bringing the signal low on read cycles, with write cycles presumably occurring regardless and the CPU eventually stalling when wanting to read an instruction, but the Synertek manual has a description of DMA using RDY# and I'm pretty sure the address lines can be de-asserted.

Obviously, if you've tested this then that settles the matter, but previous information has been vague. The read versus write distinction is a separate matter, and it wouldn't impact DMA anyway.

dominicbeesley wrote:That's the idea, though I'd make it any address in RAM rather than zero page. I've got to do a lot of driving next week so will have a think about it but at the moment writing register 0 sets of a blit.


It doesn't have to be zero page, but that was a simplification to reduce the amount of ICs in the discrete logic implementation, and it also has the positive feedback of reducing the number of setup cycles even further (both in terms of writing the address to DMA locations and in terms of setting up the descriptor before the DMA mechanism gets told about it).

dominicbeesley wrote:
paulb wrote:Also, on the Electron, an efficient DMA controller could access RAM at 2MHz, like the ULA, whereas the CPU can only manage 1MHz access to RAM via the ULA.


I'm not sure how that would work. I need to have a proper look at the Elk but I'm not sure how anything could access memory without going through the ULA and hence have same restrictions?


The ULA does the two 4-bit reads quickly enough to achieve an effective 8-bit read within a 2MHz cycle. However, there's no time left for the CPU to actually take the result within that cycle. So the CPU has to be operating at 1MHz so that it can be presented with the data at a tempo it can handle. (Some kind of read pipeline might mitigate this, but I guess it would need a modified CPU.)

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

Re: A blitter for the beeb?

Postby dominicbeesley » Tue Nov 28, 2017 4:32 pm

The paragraph that seems to cause confusion is, I have not tested this on a real processor

6502-dma.png


It seems clear to me that the address lines are _not_ released but _held_ (otherwise the slow ROM thing wouldn't work). Later processors in the series, I'm not sure when but certainly some WDC, have a BE input that when (de)asserted releases all the relevant lines. Whereas it is my understanding that the 6502 just has a DBE (databus enable).

The diagram on page 4 of the datasheet only shows the data lines being buffered.

I'm happy to be proved wrong though. I will confirm this when I prototype this in the hopefully near future.

I'll allow but not _require_ zero page descriptors. I wouldn't want to mandate it as zp is a limited resource and this has to play nice with other software.

I need to dig my Elk out of the basement, dust it off and get it working...the last time it was fired up (ca.2001) it lasted about 5 minutes before the ULA overheated!

I think I get what you're saying with the 4bit=>cpu accesses i.e. the read won't be ready in time during a 2MHz phi2, for write to system RAM this might be avoidable?

D

paulb
Posts: 784
Joined: Mon Jan 20, 2014 9:02 pm

Re: A blitter for the beeb?

Postby paulb » Tue Nov 28, 2017 4:51 pm

dominicbeesley wrote:It seems clear to me that the address lines are _not_ released but _held_ (otherwise the slow ROM thing wouldn't work). Later processors in the series, I'm not sure when but certainly some WDC, have a BE input that when (de)asserted releases all the relevant lines. Whereas it is my understanding that the 6502 just has a DBE (databus enable).


Interesting. Certainly, the slow ROM thing was a major feature, particularly at the time the CPU was introduced.

dominicbeesley wrote:I think I get what you're saying with the 4bit=>cpu accesses i.e. the read won't be ready in time during a 2MHz phi2, for write to system RAM this might be avoidable?


See the simple diagram here.

If the read operation were 8-bit, the data would be ready within the second half of the 2MHz cycle, but since the ULA has to go back for another 4-bit read (given as "S"), it probably doesn't get the result of that read fast enough to beat the end of the cycle, which is long past the time it needed to be available.

I haven't thought too hard about CPU writes. My concern would be that the data would need to be asserted for the entire duration of the two 4-bit operations, and that this might be too long for the CPU. Then again, the ULA could potentially buffer the data, although I don't know whether it actually does. It might then have been easier to just use 1MHz for this as well, even if the ULA can dispatch all the data within a single 2MHz cycle (just as it does for reading).

crj
Posts: 328
Joined: Thu May 02, 2013 4:58 pm

Re: A blitter for the beeb?

Postby crj » Tue Nov 28, 2017 6:18 pm

Heh. A fun bit of work!

In terms of where to go next, I guess my question would be what the purpose of the exercise is.

If it's a "what might have been" exercise in mimicking an expansion that could have been made back in the day, that looks like it's pushing the upper bounds of what would have been achievable in the mid eighties.

If it's for messing about with blitters for the sake of messing about with blitters you're clearly doing fine. (-8

If, however, the intention is to use modern hardware to up the BBC Micro's game graphics-wise as effectively as possible without aspiring to authenticity, I'd be tempted to suggest sticking down an STM32 with a bus arbitrator including the Beeb in its address space. A multi-hundred-megahertz 32-bit RISC chip should have no trouble doing, well, anything!

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

Re: A blitter for the beeb?

Postby dominicbeesley » Tue Nov 28, 2017 9:10 pm

The original point of the exercise was originally to have a way of copying blocks of memory quickly between 64k banks on my 6809 board...it's morphed into this. Which is I, personally, think authentic. It might not seem much but it's taken me quite a lot of effort...

Acorn could have, and in my opinion probably should have, done something a bit more to compete graphics wise. RobC's VideoNULA addresses the palette/scrolling deficiencies in the ULA and this (or something similar) would have been achievable also to beef up the graphics capabilities. I remember the day we took delivery of our first Master 128 at school and being rather disappointed at the same 8 gaudy colours and lack of graphical improvements.

I don't think it is really pushing the bounds of what was achievable in the 80's:
- it _should_ fit on an Elk sized ULA (not that I've fully tested this assertion :?: )
- there were plenty of people around in Cambridge who could have knocked something like this out (though after the Electron ULA debacle possibly not)
- it was done on the Amiga in 1985, ST in 1987, Xerox Alto 1973 so certainly contemporaneous.

So, I'd say, to my mind, it meets the authenticity criteria, or at least my set of authenticity criteria. I could have gone really mad and added in 16Mhz ram and even more processing / special effects but I've tried to keep it believable.

I've no idea what the patent situation would have been though.

Yes, we could poke a modern arm into the cpu socket but I fear that would be not meet the authenticity criteria, be stimulating to design and not really that much fun to program.

I'm hoping there will be people who will find this interesting, as they have RobC's VideoNULA. Unlike Rob's creation this won't do that much out of the box i.e. enhance existing games but maybe somebody will be interested enough to play with it and create something.

If you're not interested though that is of course your choice 8)

D

User avatar
trixster
Posts: 527
Joined: Wed May 06, 2015 11:45 am
Location: York

Re: A blitter for the beeb?

Postby trixster » Tue Nov 28, 2017 10:01 pm

What a fantastic project! I'd definitely be up for testing and having a play with it, although actually programming something to use it is somewhat beyond my abilities!

Amazing work. The Beeb just keeps getting better =D> :shock:
A3020 | A3000 | BBC B + 128K RAM/ROM + 20K Shadow + Pi0 + VideoNuLA
BBC Master Turbo + DC | Atom | A1200 060 | A500 | Jaguar | A420/1
A4000/040 060 | Atari Falcon 060 | Saturn | PS1 | SNES | CPC6128 | C64 | 3DO | MD

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

Re: A blitter for the beeb?

Postby RobC » Tue Nov 28, 2017 10:13 pm

dominicbeesley wrote:maybe somebody will be interested enough to play with it and create something.

I've no doubt there'll be lots of takers. With a suitable library, this would allow people to develop brilliant games just using BASIC :D

You could presumably even write the game logic in BASIC, C or whatever you like on the Pi copro and have the blitter/sprite engine do the graphics on the host. The possibilities are incredible!

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

Re: A blitter for the beeb?

Postby dominicbeesley » Tue Nov 28, 2017 10:44 pm

Thanks trixter, there's not much to test at this point other than programming as other than the demo in the video and a couple or test suites there's not much else available.

Good point Rob about the TUBE...I'll have to have a think about that. If I (or someone else) take up trickie's idea of something akin to GXR then it should be easy

I'm not sure how magic a bullet it would be from BASIC but it will be worth finding out. I'll try and concentrate on the hardware side for now....I'm having to stop myself from trying to write a game for it which will never get finished!

D

paulb
Posts: 784
Joined: Mon Jan 20, 2014 9:02 pm

Re: A blitter for the beeb?

Postby paulb » Tue Nov 28, 2017 11:14 pm

dominicbeesley wrote:I remember the day we took delivery of our first Master 128 at school and being rather disappointed at the same 8 gaudy colours and lack of graphical improvements.


Acorn's development focus was elsewhere, but at the time, the way the classic Beeb range was being stretched out was justifiably criticised. The Amstrad CPC series showed what could have been done with some evolution of the designs, and the VideoNULA could also have been done at the time, as far as I can tell.

dominicbeesley wrote:I don't think it is really pushing the bounds of what was achievable in the 80's:
- it _should_ fit on an Elk sized ULA (not that I've fully tested this assertion :?: )


I haven't looked properly at everything you're doing, but I think a basic DMA mechanism is within the realms of discrete logic, although it might end up looking like a Music 500 board in terms of component count. It would be a lot less complexity than the Electron ULA, though.

Add in lots of my ULA suggestions, however, and it would be a bit more complicated. :wink:

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

Re: A blitter for the beeb?

Postby tricky » Tue Nov 28, 2017 11:25 pm

I'm pretty sure that the NES 1983 had DMA and I seem to remember a thread around here about, I think DMA ideas for the elk.

User avatar
grobda
Posts: 102
Joined: Tue Apr 23, 2013 1:46 pm
Location: Glasgow

Re: A blitter for the beeb?

Postby grobda » Wed Nov 29, 2017 9:57 am

Nice work =D>

Early williams arcade games such as joust and robotron also used a blitter, well 2 customs that handle 4 bits each. There's a few pages with info on it. Not sure if that's any help :lol:

Oh and the Atari st could use one too (just fitted one to mine), I assume that's similar to the amiga one.

paulb
Posts: 784
Joined: Mon Jan 20, 2014 9:02 pm

Re: A blitter for the beeb?

Postby paulb » Wed Nov 29, 2017 12:40 pm

tricky wrote:I'm pretty sure that the NES 1983 had DMA and I seem to remember a thread around here about, I think DMA ideas for the elk.


DMA on the Electron

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

Re: A blitter for the beeb?

Postby jregel » Wed Nov 29, 2017 1:34 pm

This is very impressive!

If the functionality of the blitter could be used by the GXR VDU extensions, it could enhance existing programs (in the same way that VideoNULA does) and still "feel like a Beeb". It would also provide a very easy way into utilising its capabilities (through BASIC).

Of the following GXR functions, which could the blitter utilise?

Software sprites - presume this is a given?
Copying/moving rectangular areas of screen memory - seems like a natural fit for the blitter?
Extended pattern drawing (GCOL 16,32,48 and 64)? - presume this is just another blitter-type copy operation?
Flood fills?
Line drawing? I believe the Amiga blitter supports this, but not sure if that's out-of-scope for your project...
Triangle drawing?
Other GXR shapes (Rectangles, squares, parallelograms, circles, ellipse, arcs, sectors, segments)? Possibly too niche (and most can be built using triangles)?

Please make it compatible with the Master :-)
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 » Wed Nov 29, 2017 2:42 pm

Thanks jregel,

I'll look at these. Line drawing is probably out for now, though I may be able to squeeze some speed out of PLOT 85 and some basic shapes...if I can get my head round the algorithms and hack GXR.
Pattern drawing should be doable as a number of repeated sprite plots. I will look at some kind of modulo on one of the channels so that it can repeat multiple times...

It may be some time before I get as far as a GXR upgrade though as that is quite a chunk of code!

Do you have examples of programs that use it, it's not something I'm too familiar with.

I started looking at sprites and it should be doable.

I can see that the hardware side is only the start of this...I may need some help on the software front.

I will be looking at the master soon, though it will probably involve desoldering the CPU which is a shame!

D

User avatar
1024MAK
Posts: 6799
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...

Re: A blitter for the beeb?

Postby 1024MAK » Fri Dec 01, 2017 2:09 pm

Zilog developed and introduced their Z8410 DIRECT MEMORY ACCESS CONTROLLLER in the 1980s. I think in 1983 but can't find a date with my internet search.

http://www.zilog.com/force_download.php ... G5Ca1pnPT0

Z80 Family Product Specifications Handbook Feb84

Mark
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk NOW!
BeebWiki‬ - for answers to many questions...

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

Re: A blitter for the beeb?

Postby dominicbeesley » Fri Dec 01, 2017 4:57 pm

Thanks Mark,

I remember playing with one of those a few years ago but forget the details, I'm not sure if one of those could have been re-purposed as a blitter.

Here's a quick sketch of how it works, it is slightly different to the Amiga's blitter but on similar lines. There's the added complexity of the mask data channel (A) being in a different number of bits per pixel than the current screen mode. Also, the 6845 cellular memory layout means that behind the scenes channels C and D have to do a little more work, channel B is always "linear" though.


20171201_165240-s.jpg

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

Re: A blitter for the beeb?

Postby dominicbeesley » Sun Dec 03, 2017 12:56 pm

Can you hear me mother?



I thought, as I've got DMA sort of working, I'd have a quick bash at sound. This is dead simple, single channel, no volume control, 8 bits per sample signed, variable sample rate and it already needs a lot of gates.

If I did it properly I'd got for 4 variable rate channels (like the amiga) but probably mono. The variable rate channels are good for producing simple short samples to make instruments without the processor having to do any heavy lifting.

The sample is a couple of seconds of the theme to Making the Most of the Micro at 8000 samples per second, roughly converted with a decimator from 48000 samples per second so its a bit hashy and aliassy and played through the beebs tinny speaker it's surprising that it is recognisable at all!

As for authenticity this was certainly achievable in mid 80's (Paula chip, from MOS with 4 channels) though I'm not sure how much of that was analogue. For example each channel had a 6 bit volume and there was an overall 6 bit volume which would have required a lot of mixing. I've not found any info on the internals of the Paula. The analogue mixing and multiplying would require a good acre or two of chip...

Anyway - would there be interest in this or should I just concentrate on blitting?

D

User avatar
BigEd
Posts: 1500
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: A blitter for the beeb?

Postby BigEd » Sun Dec 03, 2017 1:05 pm


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

Re: A blitter for the beeb?

Postby tricky » Sun Dec 03, 2017 11:13 pm

If your blitter can target a single destination address, then you already have single channel support when combined with a parallel port D2A.
http://stardot.org.uk/forums/viewtopic.php?f=3&t=13468


Return to “hardware”

Who is online

Users browsing this forum: Bing [Bot] and 10 guests