A blitter for the beeb?

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

Re: A blitter for the beeb?

Post by 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: 76
Joined: Fri Dec 20, 2013 6:39 pm
Location: Gloucestershire
Contact:

Re: A blitter for the beeb?

Post by 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
PiTubeDirect with Pi Zero

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

Re: A blitter for the beeb?

Post by 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: 587
Joined: Tue Apr 30, 2013 11:16 am
Contact:

Re: A blitter for the beeb?

Post by 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: 76
Joined: Fri Dec 20, 2013 6:39 pm
Location: Gloucestershire
Contact:

Re: A blitter for the beeb?

Post by 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
PiTubeDirect with Pi Zero

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

Re: A blitter for the beeb?

Post by 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: 2628
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: A blitter for the beeb?

Post by 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: 2224
Joined: Sat Sep 01, 2007 9:41 pm
Contact:

Re: A blitter for the beeb?

Post by 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: 465
Joined: Sat Dec 23, 2000 5:56 pm
Contact:

Re: A blitter for the beeb?

Post by 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: 587
Joined: Tue Apr 30, 2013 11:16 am
Contact:

Re: A blitter for the beeb?

Post by 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: 587
Joined: Tue Apr 30, 2013 11:16 am
Contact:

Re: A blitter for the beeb?

Post by 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: 76
Joined: Fri Dec 20, 2013 6:39 pm
Location: Gloucestershire
Contact:

Re: A blitter for the beeb?

Post by 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
PiTubeDirect with Pi Zero

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

Re: A blitter for the beeb?

Post by 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!

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

Re: A blitter for the beeb?

Post by dominicbeesley » Wed Dec 27, 2017 10:42 pm

I've spent some time making an assembler protracker player. It does more effects but is by no means complete. It looks to me like it would be possible to have something like this running off interrupts during a game without eating too many cycles....

Anyway, I'll get back to hardware designing now, I've got a load of half-finished designs I want to get sent off!


https://youtu.be/DBmmN1i573Y

[two modules were used for this video:
A fox in my box can be heard here: https://modarchive.org/index.php?reques ... ery=179074
And the second tune is used as the theme for these excellent tutorials https://www.youtube.com/watch?v=2iSy8HYwRVU
]

atcurtis
Posts: 45
Joined: Fri Apr 08, 2016 9:47 am
Contact:

Re: A blitter for the beeb?

Post by atcurtis » Wed Dec 27, 2017 10:49 pm

dominicbeesley wrote:I've spent some time making an assembler protracker player. It does more effects but is by no means complete. It looks to me like it would be possible to have something like this running off interrupts during a game without eating too many cycles....

Anyway, I'll get back to hardware designing now, I've got a load of half-finished designs I want to get sent off!

https://youtu.be/DBmmN1i573Y

[two modules were used for this video:
A fox in my box can be heard here: https://modarchive.org/index.php?reques ... ery=179074
And the second tune is used as the theme for these excellent tutorials https://www.youtube.com/watch?v=2iSy8HYwRVU
]
Awesome! 8 bit never sounded so good :D

I'm guessing that the blitter needs to sit in the CPU socket so... will there be much extra effort to accommodate the 65SC12 used in the BBC Master?

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

Re: A blitter for the beeb?

Post by jregel » Wed Dec 27, 2017 11:01 pm

Really good sound! I like it! How do you output the audio? Is it a separate audio output to the built-in Beeb sound chip?

In your original description, you mentioned that it would sit in the CPU socket. I'm just curious as to whether your approach would work in any other scenarios, such as:

- Could it connect as a 1Mhz bus device?
- Could it be implemented as part of a 6502 co-pro over the Tube?

If the latter were possible, I'm guessing it would also be possible to implement the functionality on something like the PiTubeDirect? A combined Blitter and 6502/65C102 co-processor. Would make the device accessible for a lot of users without requiring the CPU to be unsoldered.

I'm guessing the answer is "no" as the Tube isn't fast enough for what you want the Blitter to do?
BBC Master Turbo
Retroclinic External Datacentre
VideoNuLA
PiTubeDirect with Pi Zero

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

Re: A blitter for the beeb?

Post by dominicbeesley » Thu Dec 28, 2017 2:27 pm

Thanks lads,

atcurtis, I'm not sure what you mean do you mean will it handle the '12 in a master or enable putting a '12 in a model B? I'm looking at both possibilities (as well as other possibilities)

jregel, at the moment the sound comes from a 1-bit dac with a simple resistor / capacitor filter that is then attached to the 1MHz bus "analogue in" via an internal test-clip. The only "beefing up" for the sound is that I've plugged in an external speaker instead of the beebs keyboard mounted one - the one in this machine is torn and rattles. The replacement speaker is a 2"x4"ish elliptical from an old telly, also ripped but less rattly.

The only option for this is the CPU socket I think it needs to take over _all_ the address signals and remove the CPU from the sound/blit accesses. None of the other ports have access to all the address lines. On the NMOS 6502 there is no way to tell the 6502 to let go of the address lines but it may be possible on the master. I need to do some experimenting as I'd like to make this a "solder free" upgrade. However, I'd really recommend this along with RobC's NULA which on the master does require soldering.

The other option might be to 3D print some kind of piggy back connector for the 6502 but my 3D printing knowledge is a bit thin!

D

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

Re: A blitter for the beeb?

Post by dominicbeesley » Sun Jan 07, 2018 8:24 pm

A little progress on this. I've separated out the DMA controller, blitter and sound chip into 3 logical chips. In the 6809 version these will be 3 separate physical cplds, on the beeb plug in I may use a newer cpld and cheat with them all together in one max10.

I now have the dma controller working. It is dead simple with 4 channels each with two "bank" registers used to select a 64k bank of memory $FF being the bbc's on board memory space and two 16 bit address counters. The user can select whether source/destination count up/down/stay the same and a 16bit count when the dma controller is started it runs until the counter is exhausted. I will add a mode later that can be stepped by hardware but I'm not sure how best to do that, I may give two choices:
a) trap NMI's
b) poll a port - this would consume cycles though

In the first case I just wanted a way to quickly read/write registers and this has worked. Before setting up all 32 blitter registers from memory was taking approx 280uS, now setting up the dma controller and getting it to do the lifting has got it down to 30uS to set up the DMA and 32uS to run the DMA. I aim to do some shuffling of registers on the blitter to improve on this so it should be an over head <50uS. so ~50uS setup + 1uS per pixel for a masked blit...

I've not progressed to getting this into hardware yet. Work, life and holidays are getting in the way!

I need to try this with a more fully loaded beeb but I daren't move this one yet as it is loaded up with probes. I'd like to see if playing a sound and reading/writing a floppy can work. I suspect that injecting random wait states during NMI rountines may prove to be problematic! A possible solution might be to have to sound chip support rom claim the NMI vector and disable sound if anyone else claims it? It would still be possible to bypass this.

I'm not sure how best to setup API's for all this but I suspect in the first place I'll rig up some OSBYTE/WORDs.

I've not got much further with the GXR thing but it will come at some point!

D

User avatar
simonm
Posts: 191
Joined: Mon May 09, 2016 2:40 pm
Contact:

Re: A blitter for the beeb?

Post by simonm » Mon Jan 08, 2018 9:01 pm

All. Kinds. Of. Awesome.

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

Re: A blitter for the beeb?

Post by dominicbeesley » Tue Jan 09, 2018 12:52 am

Thanks Simon. Much appreciated

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

Re: A blitter for the beeb?

Post by dominicbeesley » Wed Apr 11, 2018 3:11 pm

A quick update.

A test board for this was fabricated a few weeks ago and I've built up two so far. The test board can take different CPU's but so far I've only got this working reliably with a 6809 real processor. I've had it working almost with a real 6502A and fairly well with a soft-core 6502A (but that is cheating!). There are sockets for 6502A/65C02/65816 and 6809/6309 processors. Unfortunately, due to my not thinking things through, I've not had the cmos 65* processors working (they don't like interfacing to the LVTTL voltages of the FPGA on the clock line). I'm hoping that I may be able to bodge this by dropping the voltage for the cpu to 3.3V but that will require track cutting.
20180228_161207-s.jpg
20180303_224509-s.jpg
I've been a bit slow in getting this together due to life getting in the way and a few hacks I've had to made to the board. I'll be sending out some of these this week but the current board is probably not of very wide interest as it is quite expensive to build up, requiring a MachXO2 breakout board and a load of connectors. When/If (if there's enough interest) I make a production board I'll maybe drop the cpu sockets idea and just have the fpga a cpu socket and ram.

This board also has battery backed ram though it doesn't seem to work reliably, I suspect that when the main board is off but power is supplied to the fpga it is picking up noise and writing to the ram, I need to look at this, hopefully it can be fixed in firmware.

I've started writing a quick graphics demo (not much to it at the moment but one day it may progress to being a real game) and ported the tracker module player to the 6809. The game looks quite pretty (I got the graphics from here: https://opengameart.org/content/zelda-l ... nd-sprites and with RobC's VideoNULA providing a nice palette it looks better than I'd expected)


https://youtu.be/mXCgZPtc4jU

The board fits ok in the Model B, I've not tried it yet in a master but it will require an umbilical to fit. The lid goes on ok in a Model B which is a relief
20180411_142646-s.jpg
RobC, myelin, as promised I'll post you bare boards (with hacks applied), I didn't want to send anything until I'd got them working!

For those who are interested in the details see below. One of the things that has been a challenge (still is) has been to try and decode the CPU's address and decide whether the local chipset/ram should intercept it. If it should then the CPU's address, data and control lines need to be detached from the mainboard, this all has to happen quite quickly otherwise the motherboard will try to process the request and if it is a sheila/fred/jim address will try and start a 1MHz stretched cycle.

Normally the CPU address, R/W, data lines are connected (via buffers) to the system bus. For each access the FPGA:
- detects what the CPU wants to access
- check registers etc to see if the board should intercept for local
SWRAM/SWROM/hardware
- if it should then it needs to:
- momentarily disconnect the CPU from the local on board bus
- pull the bus high - this sets the main board address to $FFFF
- disconnect the system bus (the address is then held high by pull up
resistors)
- release the local bus
- reconnect the CPU
this all needs to happen early on during the system phi1 cycle otherwise
if the local hardware address is in sheila/jim/fred the cycle stretch
circuits get upset and try to stretch the clock. Where my addresses overlap
with mainboard hardare addresses I need to also make sure they don't both
activate.
- do whatever local stuff needs to happen and read/write to the cpu

Fitting all this in during the 150 or so ns after the fall of phi2 to allow for slow propagation through all the system on-board decoding to the cycle stretcher is proving to be a bit difficult.

The 6309 is pretty quick at getting its address set up after the E clock cycle is finished so I've managed all this reliably. But the 6502A is pretty slow to get started and every time I think I've cracked it, it gets warmer and slower!

The thing I'd not really appreciated was the extra step of having to force the bus high, the pull up resistors on the address lines are just too slow to do this, I'd also not appreciated just how slow all the adress decoding logic is on the main board making timings quite tight. I will get there with the 6502 but it might mean rearranging the ordering of the events above.

Here's a very basic overview of how the hardware works (excluding the blitter which I've not written up yet). At some point I need to sort all the code and VHDL into "releasable" form but I need to do a quick audit of licenced material...the 6809 MOS is pretty closely based on the 6502 mos so I'm not sure I can just slap a GPL licence on it, or not until I've removed the old 6502 code...

Code: Select all

Known issues
------------

* Sound accesses to system memory can cause crashes
* Sound accesses from chip ram during accesses to 
  SRAM/EEPROM cause noise in samples
* dmac accesses to system hardware untested
* contention between blitter/dma/sound and local and
  system busses incomplete
* occassional random crashes - not sure if this is my 
  test machine though
* occassional failure to boot - have to press CTRL-BREAK
  multiple times to clear. Suspect bugs in MOS startup 
  code.


===============================================================================
BEEB 6809 Hardware Overview
===============================================================================

The Dossytronics CPU development board includes a MachXO2 mezzanine board, 
1MB of SRAM, 512K of FlashEEPROM, a crystal oscillator, optional cpu sockets.
A super-capacitor and charging circuit are provided which will back up the 
top 512K of SRAM.

The board plugs into a BBC micro CPU socket and is powered by a USB lead 
connected to the mezzanine board.

Simplified Diagram
==================

                                                                            
+-----------+    +------------+   +------------+          +----------------+
|           |    |            |   |Onboard CPU |          |                |
|   CHIP    |    |  FPGA      |   |65xx,6x09   |          |   BBC Micro    |
|   RAM     |    |            |   |65816       |          |  motherboard   |
|           |    | +--------+ |   +------------+          |                |
+-----------+    | |DMAC    | |        \ /                |                |
   | |           | +--------+ |---------^ A               +--+             |
   | | mem bus   | |BLIT    | |        / \           B    | s|             |
   | +-----------| +--------+ |--------+ +----------\ /---|Co|             |
   | +-----------| |SOUND   | |---------------------/ \---|Pc|------...    |
   | |           | +--------+ |      local bus       |    |Uk|------...    |
   | |           | |MEM CTL | |----------------------+    | e| system bus  |
+-----------+    | +--------+ |                           | t|             |
|           |    | |BUS CTL | |                           +--+             |
| Flash     |    | +--------+ |                           |                |
| EEPROM    |    |            |                           |                |
|           |    |            |                           |                |
+-----------+    +------------+                           +----------------+
                                                                            

[This description is based around how the current firmware accesses hardware
you may of course replace the firmware and completely replace the contents
of the FPGA. For instance the CPU buffer could be left disconnected and a
soft-core cpu implemented in the FPGA.]
                                                                            
The CPU board contains three level shifting biderectional buffers. Two of these
buffers (A,B) can be used to isolate the CPU or the SYS (main board) from the 
local bus. 

The CPU can be disconnected from the local bus, this is mainly used where the 
CPU is halted and the DMAC/BLIT/SOUND hardware wish to directly address the 
SYStem memory/hardware.

The SYS socket can be disconnected, when the CPU wishes to directly address
the local DMAC/BLIT/SOUND etc hardware, or when the CPU is accessing the local
"chip ram", either through the JIM interface or as sideways RAM.

All other signals to/from the CPU and SYS to the FPGA pass through a third
buffer (not shown for simplicity) which is always enabled and merely translates
the 5V TTL signals of the SYS/CPU to the LVTTL signals required by the FPGA.

Prior to the SYS buffer being disconnected the BUS CTL circuit will "blip" the
local bus (by briefly disconnecting the CPU buffer and pulling all address
lines high) after which point pull-up resistors on the address bus hold the 
system bus at $FFFF.

===============================================================================
JUMPERS
===============================================================================

This information is accurate as of 4/4/2018.
All jumpers marked nc should be left unconnected as they may be debug outputs

J1 VPB/Gnd
----------

[located W of cpu sockets]

This link should be fitted for 6502A processors and left off for all others



J2 SYS CPU Gnd
--------------

[located above system cpu header area]

This link should be fitted on the BBC ModelB it connects
Pin 1 of the cpu header to ground


J3 Sound output
---------------

  +---+
  | # | sound out (filtered)
  | o | sound ground
  +---+

The south pin 2 should normally be connected to the 
east end of R29 on a Model B

The north pin 1 should normall be connected to the 
north end of R172 on a Model B

Alternatively the output can be connected to the line
in of an amplifer.

J4 local audio ground
---------------------

The audio output filter is normally grounded via the 
flying leads to whatever amplifier is connected however
it is possible to ground the filter locally by adding 
this link, however this tends to be more noisy.

J5 System config
----------------

[located on north-east corner above Mezzanine board]

A set of headers are supplied on J5 for general IO or to be used for 
configuration. On the current firmware they have the following uses:

<--- W (system)

     |
<---(N)- as marked on breakout board
     |

          G G G G G G G G G G G G 3 3
          n n n n n n n n n n n n . .
          d d d d d d d d d d d d 3 3
        +-----------------------------+
     J5 | o o o o o o o o o o o o o o |
        | # o o o o o o o o o o o o o |
        +-----------------------------+
          S c n n n n n n n n m A n n
          n p c c c c c c c c e 1 c c
          d u                 m 1
            0                 i 

snd = Sound 1 bit dac / pwm output unfiltered
cpu0  = fit jumper to ground for 6x09 cpu, open for
    6502
memi  = fit jumper to inhibit on-board SWROM/RAM in 
    which case SYStem sockets appear repeated as
    usual for BBC (useful if a bad ROM needs to
    be expunged)
A11 = local A11 with translation (used internally
    for 6x09/65816 vector address translation)
    * do not add jumper!

J6 CPU test pins
----------------

[Located N of cpu sockets]

Various marked CPU test pins

J7 Sound pull up down
---------------------

[located W to E above sound output]

This header should be left unlinked, it may be set to 
either middle to E or middle to W if sound quality
problems are encountered.


Memory Map Overview
===================

 +--------------------------+-----------------------+ 
 |  logical/physical addr   | hardware item         |
 +--------------------------+-----------------------+
 |  $00 0000 - $07 FFFF     | SRAM 0                |
 +--------------------------+-----------------------+
 |  $08 0000 - $0F FFFF     | SRAM 1 (battery back) |
 +--------------------------+-----------------------+
 |  $10 0000 - $17 FFFF     | EEPROM                |
 +--------------------------+-----------------------+
 |  $18 0000 - $1F FFFF     | - blank -             |
 +--------------------------+-----------------------+
 | ...                                              |
 | above  ..... repeats until system ...............|
 | ...                                              |
 +--------------------------+-----------------------+
 |  "system" (except for SWRAM/SWMOS)               |
 | $FF 0000 - $FF 7FFF      | SYS RAM               |
 | $FF 8000 - $FF BFFF      | SYS ROM / SWRAM       |
 | $FF C000 - $FF FBFF      | SYS MOS / SWMOS       |
 | $FF FC00 - $FF FEFF      | SYS HARDWARE          |
 | $FF FF00 - $FF FFFF      | SYS MOS / SWMOS       |
 +--------------------------------------------------+

The addresses above are not valid in all situations:
- JIM accesses will just access the memory $00 0000 to
  $1F FFFF 
- CPU directly accesses the "system area only" i.e 
  bank $FF
- BLIT/SOUND/DMAC can access all addresses, i.e. to
  blit to / from SYStem memory address as $FF xxxx

Onboard Memory
==============

The onboard SRAM and Flash EEPROM can be addressed by the CPU either through 
the JIM interface or as sideways ROM/RAM.

The JIM interace
----------------

The onboard memory $00 0000 to $1F 0000 can be accessed as a set of 8192 256
byte pages of memory mapped into a single memory window at $FF FD00 and 
accessible to the CPU (not DMAC/BLIT/SOUND via JIM)

To enable the local JIM interface the SWMOS control register bit 1 should be 
set (See SWMOS reg below). If this bit is not set the paging registers and JIM
are passed on to the 1MHz bus as usual to allow memory mapped hardware to be
accessed.

Sideways RAM
------------

Sideways RAM at $FF 8000 - $FF BFFF can be mapped into local chip RAM/EEPROM
by using the following registers

SWROM reg
---------
$FE30 - this is a shadow copy of the BBC micro's own ROM select register, if 
the value is in the range 4-7 then accesses to the memory at $FF 8000 to 
$FF BFFF will access the SYS ROM sockets. Otherwise (if the memory inhibit 
jumper is not fitted) even numbered values will map to chip SRAM (in the 
battery backed portion) and odd numbered values will map to the EEPROM

Sideways ROM/RAM 
Map to the following addresses
 0  EEPROM         $ 16 0000 - 16 3FFF
 1  BB RAM         $ 0E 0000 - 0E 3FFF
 2  EEPROM         $ 16 4000 - 16 7FFF
 3  BB RAM         $ 0E 4000 - 0E 7FFF
 4  SYS IC 52
 5  SYS IC 88
 6  SYS IC 100
 7  SYS IC 101
 8  EEPROM         $ 17 0000 - 17 3FFF
 9  BB RAM         $ 0F 0000 - 0F 3FFF  NB: this slot is also used as the SWMOS
 A  EEPROM         $ 17 4000 - 17 7FFF
 B  BB RAM         $ 0F 4000 - 0F 7FFF
 C  EEPROM         $ 17 8000 - 17 BFFF
 D  BB RAM         $ 0F 8000 - 0F BFFF
 E  EEPROM         $ 17 C000 - 17 FFFF
 F  BB RAM         $ 0F C000 - 0F FFFF

Sideways MOS
------------

Additionally the memory area at $FF C000 to $FF FBFF and $FF FF00 to $FF FFFF
can be mapped to a sideways RAM bank (#9) with the use of the SWMOS reg

SWMOS reg
---------

[Note: this is likely to change in the near future to make it more compatible
with Master/BBC B+]

$FE31 - this register controls whether the MOS ROM is in a system slot or 
alternatively mapped into sideways ram slot #9. Also this register enables or
disables the on-board JIM registers.

Bit     Purpose
===     =======
0       when set to 1 the MOS will execute from sideways bank #9 this bit is
        not reset when the break key is pressed a full power down is needed to
        return to executing from the SYS socket should the #9 socket become 
        corrupted.
1       When set to 1 the local JIM paging registers (below) will become active
        and cpu accesses to the page $FF FD00 will be intercepted to read chip
        memory

JIM Paging registers
--------------------

$FCFE - JIM paging register (hi)
$FCFF - JIM paging register (lo)

When local JIM is enabled (using the SWMOS register above) these registers 
become active. Writing values to these registers will set the page that is 
mapped in to appear in the JIM page at $FF FD00

Data can then be read/written to RAM via JIM.

Data can also be written to the FlashEEPROM. However valid programming 
sequences must be sent before a write is attempted. See the source code for the
UTILS ROM for an example.

===============================================================================
DMAC - the dma controller
===============================================================================

BEEB Base address: $FF FC90 
[subject to change - may be relocated to sheila]

The DMAC or DMA controller is a simple device for reading/writing bytes to/from
hardware registers or devices.

There are four DMA channels, however currently only one can be used at a time.

For user applications it is recommended only to use channel 0 and to always
set FC9F=0 before any operation. 

The source and destination registers are programmed with starting addresses,
a count register is set to indicate the number of bytes to transfer the control 
register set to increment or decrement the source/destination after each
cycle. 

  Address       Purpose
  -------       -------
  BASE + 0      Control register - this should be set last, setting this register
                with bit 7 set will start the transfer.
  BASE + 1/2/3  Source address (big endian 24 bit address)
  BASE + 4/5/6  Destination address (big endian 24 bit address)
  BASE + 7/8    Count - 1
  BASE + 9      Data (may be read after a transfer)
  ...
  BASE + F      Channel select, setting this register maps in the lower 0-9 
                registers for the selected channel. When setting this register
                unused bits (2-7) should be 0, when reading this register
                future firmwares may set other bits.

  Control register bits
  ---------------------

  7   -   ACT : (set this bit to 1 to initiate/test for completion)
  6   -   IF  : Interrupt flag, set this to 0 to clear interrupt
  5   -   IE  : Interrupt enable, when set the IF flag is set on completion
  4   -   HLT : If set the CPU is halted whilst the transfer proceeds
  3   \
  2   _\  SS  : source step (up/down/none)
  1   \
  0   _\  DS  : Dest step (up/down/none)

[Note: The current firmware does not support polled or background transfers. 
All transfers should have the HLT flag set]

  Step values
  -----------
  "00" - none : The address will not be incremented (to write repeatedly to a
                single register)
  "01" -   up : The address will be incremented
  "10" - down : The address will be decremented
  "11" - resv : Reserved - do not use

For example to transfer the entire screen memory to the chip ram at $00 0000
reversing all bytes:
  
  
  clr   $FC9F     ; set channel 0  
  lda   #$FF
  sta   $FC91     ; src system bank
  ldx   #$3000    ; screen base
  stx   $FC92     ; src addr
  clr   $FC94     ; dest bank = 0
  ldx   #$4FFF
  stx   $FC95     ; dest addr
  stx   $FC97     ; count - 1
  lda   #$96      ; Act, HLT, SS=up, DS=down

This should transfer the whole 20K screen to chip ram in just over 10ms i.e.
2 system cycles per byte.

Chip ram to chip ram transfers can operate faster (currently at 4MHz so 2MB/s).

If sound samples are playing then these will steal cycles from the DMAC and 
will slow down the transfer accordingly. 

It is intended that in future these may be improved to run at 8MHz except where
accessing SYStem resources.

===============================================================================
the SOUND chip
===============================================================================

BEEB Base address: $FF FC80
[subject to change - may be relocated to sheila]

The sound processor appears as a 4 channel PCM + mixer device, loosely modelled
on the Amiga's Paula chip.

Each channel can be set to output a static value by setting its data register
(complex generated sounds can be generated by setting this register in a tight
loop) or can be programmed to play a sound sample from memory using DMA 
techniques

  Address       Purpose
  -------       -------
  BASE + 0      Sound data read/write current sample
  BASE + 1/2/3  Source base address (big endian 24 bit address)
  BASE + 4/5    Sample "period" - see below
  BASE + 6/7    Length - 1
  BASE + 8      Status/Control
  BASE + 9      Data (may be read after a transfer)
  BASE + 10/11  Repeat offset
  ...
  BASE + F      Channel select, setting this register maps in the lower 0-9 
                registers for the selected channel. When setting this register
                unused bits (2-7) should be 0, when reading this register
                future firmwares may set other bits.

  Control register bits
  ---------------------

  7   -   ACT : (set this bit to 1 to initiate/test for completion)
  6   -   n/a
  5   -   n/a
  4   -   n/a
  3   -   n/a
  2   -   n/a
  1   -   n/a
  0   -   RPT  : Repeat

  [All n/a bits should be set to 0 on write, expect non-zero on read back]

  ACT, setting this bit will initiate playing a sample using DMA
  RPT, setting this bit will cause the sample to repeat, the sample will
       be repeated beginning at the offset in BASE+10/11

The clock for playing samples is a nominal 3,546,895Hz (as on a PAL Amiga). 
The "period" describes the number of PAL clocks that should pass between each
sample being loaded (via DMA)

For example, this program sets up a sample of 32 bytes length in chip RAM
and sets channel 0 to repeatedly play the sound

    5 REM BLIT SOUND
   10 snd%=&FC80
   20 SL%=32:SR%=1000:SP%=3546895/(SR%*SL%):REM calculate period
   30 BUF%=&FD00:?&FE31=(?&FE31)OR2:?&FCFE=0:?&FCFF=0:REM enable JIM, set addr=0
   40 FORI%=0TOSL%-1:BUF%?I%=127*SIN(2*PI*I%/SL%):NEXT
   50 snd%?&F=0:snd%?&E=255:REM cha=0,master vol=255
   60 snd%?&1=0:snd%?&2=0:snd%?&3=0:REM sample address
   70 snd%?&4=SP%DIV256:snd%?&5=SP%:REM sound "period"
   80 snd%?&6=(SL%-1)/256:snd%?&7=SL%-1:REM sample len-1
   90 snd%?&9=255:REM channel vol max
  100 snd%?&A=0:snd%?&B=0:REM repeat from start of sample
  100 snd%?&8=&81:REM play, repeat
  ...
Line 20   : Set parameters and calulate the note "period" i.e. 1KHz with 32 
            samples divided into the clock, i.e. 110
            [Note this is quite a fast sample rate > 32KHz a shorter sample 
            length is recommended to reduce system overhead]
Line 30   : Enable JIM and point the paging registers at the base of chip RAM
Line 40   : Write a 32 byte sample to JIM
Line 50   : Set channel number and master volume
Line 60   : Set up sample base address at $00 0000
Line 70   : Set sound "period" calculated above
Line 80   : Set length of sample (subtract 1)
Line 90   : Set Channel volume to max
Line 100  : Set repeat offset to 0
Line 110  : Set ACT and RPT, play sound indefinitely

To stop a sound playing it is a simple of matter of selecting the channel and
setting the control register to 0

  200 REM stop sound
  210 snd%?&F=0:REM select channel 0
  100 snd%?&8=0:REM stop


Known issues
------------
 - the master volume control does not work, it is recommended to set it to 255
 - there is no provision for interrupt drive sound, this may be included in
   future


User avatar
Elminster
Posts: 2589
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK
Contact:

Re: A blitter for the beeb?

Post by Elminster » Thu Apr 12, 2018 9:18 am

Amazing. I disappear for a few months and I count 8 new hardware projects (don’t tell anyone but this looks the best). If this had been done in the 80's I might never have defected to an Amiga! I don’t have the skills to help in the prototyping but definitely interested in the board if/when it looks like ready for production.

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

Re: A blitter for the beeb?

Post by 1024MAK » Thu Apr 12, 2018 10:13 am

Yes, amazing work 8) :D =D>

Although after watching the video, all I could think of was 'speaker in a cardboard box productions' :lol:

When you have ironed out the wrinkles, I would certainly like to get my hands on a board :wink:

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

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

Re: A blitter for the beeb?

Post by dominicbeesley » Thu Apr 12, 2018 10:43 am

Thanks lads,

I'll certainly look at options for building these, the current board is completely OTT with 1MB of RAM, 512k Flash and the connectors to the breakout board take ages to solder up and are expensive. With surface mount RAM and the FPGA stuck straight to the PCB I hope to get the price down. I'm also hoping to get the PCB fabricators to solder most of the parts down as it is quite time consuming soldering up all these bits. Setting up the PCB assembly looks tricky but not impossible and PCBWay, so far, have given excellent service...I would experiment more if DHL didn't then extort an extra 20+ quid each time I get a delivery - I don't mind paying VAT/duty but I think the handling fee is nothing short of scandalous.

Re the speaker, why does youtube always pick the most random point of a video as its thumbnail image! The sound card works well enough on the internal tinny speaker but sounds pretty ropey as you'd expect compared to a bigger speaker.

I have one of these on order along with one of these it should make for a decent sound. A cheaper solution is one of these - I tried one (stuck to the inside of the case). It was ok but could have been a bit louder, the sound quality was pretty good...until my daughter tried to unstick it for me and pulled the voice coil out!

I recently watched this video https://www.youtube.com/watch?v=zdkyGDqU7xA and thought it might be worth a try...

D

User avatar
kieranhj
Posts: 700
Joined: Sat Sep 19, 2015 10:11 pm
Location: Farnham, Surrey, UK
Contact:

Re: A blitter for the beeb?

Post by kieranhj » Thu Apr 12, 2018 5:49 pm

1024MAK wrote:Although after watching the video, all I could think of was 'speaker in a cardboard box productions' :lol:
I was admiring the Sony reference monitors - very nice! Careful though, you’ll be triggering sbadger’s CRT fetish. :lol:

But yes, great work Dominic, very interesting.
Bitshifters Collective | Retro Code & Demos for BBC Micro & Acorn computers | https://bitshifters.github.io/

User avatar
myelin
Posts: 430
Joined: Tue Apr 26, 2016 9:17 pm
Location: San Francisco, CA, USA
Contact:

Re: A blitter for the beeb?

Post by myelin » Thu Apr 12, 2018 9:05 pm

Nice work! It's really cool to see this project progressing... life has also gotten in the way for me and I haven't touched any of my projects for over a month. As such, no need to hurry getting boards to me; it's likely that it'd take me a while to get around to playing with it, and if I do find time, I should probably spend it on that second serial port project for you instead! :)
dominicbeesley wrote:I've been a bit slow in getting this together due to life getting in the way and a few hacks I've had to made to the board. I'll be sending out some of these this week but the current board is probably not of very wide interest as it is quite expensive to build up, requiring a MachXO2 breakout board and a load of connectors. When/If (if there's enough interest) I make a production board I'll maybe drop the cpu sockets idea and just have the fpga a cpu socket and ram.

RobC, myelin, as promised I'll post you bare boards (with hacks applied), I didn't want to send anything until I'd got them working!
SW/EE from New Zealand, now in Mountain View, CA, making BBC/Electron hardware projects for fun.
Most popular: fast serial port, FX2+PiTubeDirect Tube/Cartridge adapter, USB cart interface.

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

Re: A blitter for the beeb?

Post by dominicbeesley » Fri Apr 13, 2018 10:09 am

Fair enough Phil,

I'll maybe hang on to your board for a while before sending, I've not tried it in the Elk and it may need extra physical tweaks to get it to work...

The second / even faster serial port(s) on your board would be super-useful. I'm running HostFS on it for the 6809 and using the ACIA for my debug port, if I could have both on your port then I could debug the actual serial code in the 6809 MOS!

D

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

Re: A blitter for the beeb?

Post by dominicbeesley » Fri Apr 13, 2018 12:44 pm

kieranhj wrote:
1024MAK wrote:Although after watching the video, all I could think of was 'speaker in a cardboard box productions' :lol:
I was admiring the Sony reference monitors - very nice! Careful though, you’ll be triggering sbadger’s CRT fetish. :lol:

But yes, great work Dominic, very interesting.
I've had a bit of a Sony collecting spree recently, I needed more (well 2), smaller monitors. The large one I've been using is just too big. first I bought two 6" monitors (PVM-6041QM). I bought these as non-runners. I've made one good from 2 and tweaked the convergence but the resolution isn't really up to mode 0 standard (250 picture lines), then I went to 9" (BCM9045D) these are much better with 450 picture lines they give perfectly readable text in mode 0 with no flicker and really very good convergence (except for the very last line has a very slight red shift which I will attempt to tweak at some point). I'm dead happy with these, I've tweaked the width/height to better fill the screen with the beeb's standard modes and they are a pleasure.

If I had the cash and room and thought I could sneak another past the missus I'd get a BVM-20F1U

I got these all from this fella on ebay https://www.ebay.co.uk/itm/2x-sony-bvm9 ... Sw2gxYnyI8 (I'm not sure what the difference between 9044 and 9045 is) they're not cheap but come well packaged if a little grubby with a patina of honest use...

D

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

Re: A blitter for the beeb?

Post by dominicbeesley » Wed May 09, 2018 11:07 pm

Yay FLEX!
20180509_202739-s.jpg
This took a bit of work to get going: A 64K linear RAM mode which allows the CPU to address a straight 64K of RAM (switching in 0-8000 from the system when writing to the screen) and a hacked together "mini-MOS" built out of hacked together bits of the 6809 MOS.

Then the fun of porting Flex (using the Flex Adaptation Guide) to a new system: write disk and terminal drivers, then a formatter. Plus for the beeb a utility that copies a whole disk image across the wire (using hostfs) from the PC to a sector copier to write the system disk.

This isn't 100% functional (it needs the odd poke from the debugger to boot) but it is enough to run BASIC....I'm not sure why it sometimes reports a disc error but I think it's because I put a * at the end it tries to read from drive 1 which doesn't exist!

D

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

Re: A blitter for the beeb?

Post by RobC » Thu May 10, 2018 6:36 am

Well done :D =D> =D>

Disk error #26 has come up on here before - it's caused by the '*' as FLEX doesn't understand it.

Post Reply