A blitter for the beeb?

discuss both original and modern hardware for the bbc micro/electron
User avatar
hoglet
Posts: 9438
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: A blitter for the beeb?

Post by hoglet » Tue Aug 27, 2019 5:01 pm

Hi Dominic,

I'm also following this with interest.

Are there any plans to upload the current work to your github space?
https://github.com/dominicbeesley

Dave

dominicbeesley
Posts: 1162
Joined: Tue Apr 30, 2013 12:16 pm
Contact:

Re: A blitter for the beeb?

Post by dominicbeesley » Tue Aug 27, 2019 5:10 pm

Thanks @cmorley, @hoglet,

The lack of replies can be a bit discouraging, but that aside I'm genuinely interested if people are interested in the Copper/Aeris idea. I find it difficult to judge what actually interests people - this is all a bit niche until somebody does something useful with it.

BITD I'd always thought that the Copper chip on the Amiga was a bit of a gimmick but seeing the goodness in the Twisted Brain demo and trying it out has started to convince me otherwise...but time is pressing and I'm trying to rein in my feature creep habits and I'm not sure that the copper thing is just a distraction or if I should concentrate on the line drawing and blitting...

@hoglet, I need to have a sort out of my sources and work out a decent structure. At the moment it's a bit of a rat's nest of inter-dependent SVN's and there's a few licence issues I'd like to chase down before I make the VHDL public. I've got a set of goals for "before we move house again" and one of these will be to try and get the vhdl and code public.

Thanks both,

D

User avatar
jbnbeeb
Posts: 592
Joined: Sat Apr 03, 2010 9:16 pm
Contact:

Re: A blitter for the beeb?

Post by jbnbeeb » Tue Aug 27, 2019 10:00 pm

Just to add brief 2 cents that I missed the latest posts but have been following thread with interest. I'm definitely interested in Atari/Amiga-like blitter capabilities for the Beeb (or even C64 sprites :) ) .. and would look forward to taking advantage of them (even if I have sloth-like progress) in coding games.

Jason
..I'll be at the Virtual Acorn meetup for Cambridge Computer Museum May 16th 2020

User avatar
simonm
Posts: 316
Joined: Mon May 09, 2016 3:40 pm
Contact:

Re: A blitter for the beeb?

Post by simonm » Wed Aug 28, 2019 12:10 am

Yes indeed, I'm following with great interest, but it is voodoo and magic to me, not sure I have much to contribute other than say that this is very cool stuff :lol:

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

Re: A blitter for the beeb?

Post by Elminster » Wed Aug 28, 2019 9:43 am

+1 for watching but nothing constructive to add

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

Re: A blitter for the beeb?

Post by jregel » Fri Aug 30, 2019 1:06 pm

Another +1 from me. I'm watching this project with interest.

Your plans are pretty ambitious in scope, so I've broken my comments into sections...

Blitter

For me, the most interesting part of the project is the ability to upgrade the Beeb's graphics capabilities, and the Blitter offers the possibility of fast software sprites and fast pattern drawing, line drawing and colour filling. There isn't anything else (that I'm aware of) that is looking at bringing these features to the Beeb.

Sound

The ability to have four channels of DMA driven sampled sound would be a very significant upgrade, and could integrate nicely with the existing system (as per my previous comments re: OSWORD 7 and 8) and could potentially do some very interesting new effects.

Copper

In a previous comment in this thread, I suggested some form of horizontal sync interrupt, similar to the C64 and Amstrad CPC+. Your addition of a Copper takes that idea to the next level. To be honest, if you're adding a Blitter, DMA driven sound and a Copper, you're basically creating an 8bit Amiga... :o But I imagine it would be a very useful addition.

Not sure if you're aware, but the Spectrum Next has added a Copper as well, so it seems like the idea lives on beyond the Amiga.

Extra CPUs

Personally, I'm less interested in the additional "foreign" CPU support (Z80, 68008), as we already have that capability via the Tube and there's no existing base of software, but this is your project, so obviously you're entitled to explore whatever interests you!

Having said that, the ability to have a host 6502 running at 4Mhz or 8Mhz would be useful, since I assume most existing code should work. Beyond that, a 65816 mode could be an interesting feature, given it could emulate existing 6502 code and presumably(?) do some interesting things in 16bit mode (unified memory between the Beeb's RAM and the Blitter RAM?). I suspect that the 65816 suggestion is a lot more complicated than just a faster 6502... :)

Just out of interest, in your post, you refer to the chipset as Aeris. Is this the name of your project and does it refer to the whole Blitter board, or just some functionality?
BBC Master Turbo, Retroclinic External Datacentre, VideoNuLA, PiTubeDirect with Pi Zero, Gotek USB Floppy Emulator

User avatar
tricky
Posts: 4667
Joined: Tue Jun 21, 2011 9:25 am
Contact:

Re: A blitter for the beeb?

Post by tricky » Fri Aug 30, 2019 3:06 pm

I don't follow every post, but do checking every now and again.
My first lobe is the model B and so I really only take advantage of things on the B, but do support master and compact joysticks.
I have added nula palette support to frogger, but not scrolling to anything as the palette can be used without knowing that it is there and enhances the game if it is.
I made my menu work on MMC and GOTEC to get the widest use.
I will force sideways ram if necessary (Warlords) and optionally for extra features (Astroblaster).
If the blitter added something for not too much work/memory/CPU I would consider it, but I don't think that I will target it directly.

dominicbeesley
Posts: 1162
Joined: Tue Apr 30, 2013 12:16 pm
Contact:

Re: A blitter for the beeb?

Post by dominicbeesley » Fri Aug 30, 2019 3:10 pm

Thanks Everyone for the encouragement.

Thanks Tricky, I understand. I suspect I need to think about getting emulator support for this before anyone will consider writing software for it. That's another steep learning curve. I tried hacking MAME but didn't get it to even work yet. I've not managed to compile b-em or beebem yet but playing with other peoples code is less fun than writing my own...

Jrgegel, thanks for these thoughts.

Re the Copper, I tried an interrupt at first but it was too slow to really get much useful done in the time available during horizontal blanking and I'd kind of given up on it..for vertical rupture etc the VIA timer does the job. However, the more I looked at the twisted brain and other demos the move I've become convinced by the copper idea. To really prove it to myself I need to write some code to see what it can/can't do.

I've not forgotten the OSWORD (for sound) or the GXR ideas though GXR is looking a bit of a stretch in terms of disassembling and tweaking to used the blitter - there's quite a lot there and it is fairly involved but I'm slowly getting my head round it. The GXR sprites thing might not be the best way forwards and I have a few ideas for a different API but easily used from BASIC or assembler.

Rough plans:
- build up another board but with a pig-tail instead of a stand off for the CPU plug and do some testing on the Elk, Master and Atom
- more work on Aeris to finish it off and write a demo
- another DMA co pro to set the blitter registers and do calculations from X/Y coordinates to screen coordinates and setting up the clipping registers - the blitter is fast but setting all the registers can be time consuming
- refactor hardware registers - now it has been moved to the page-wide jim addressing I can simplify some things by having more registers
- do something with SOUND / OSWORD 7
- get it into a state ready to release, including a new board without all the processor options but with the addition of an optional real time clock for model b

The hardware isn't too difficult but the software to do all this is very time consuming especially when wading through diassemblies of things like the GXR and working out what it is doing then going back and tweaking the hardware to better suit.

I've been doing a bit of regression testing this week to try and fix up some hardware bugs I introduced recently to the line-drawing part of the blitter - that took me about 10 hours to work out what I'd done and of course it proved to be something properly idiotic.

On the CPU front I know this is of little interest to most however I'm really interested in all these different CPU's - for any final "release" board it will probably only support 65(c)02 or 40pin 65816 processors to get the board size down. Or I may try and make mezzanine plug in converters for other cpu's for those who are interested.

It has proved quite difficult to get the timing to work for all the different CPUs: when accessing the beeb's main board hardware / memory the chipset needs to have time to work out what memory is being accessed and get that ready soon enough for the cycle stretching circuitry on the beeb. For this reason it has proved most difficult to get the original 6502A to work as it is fairly slow to set up its addresses. However, I think I've got it licked now - though it's a bit marginal as it has to not only work out what the CPU wants to access but what all the DMA devices might want to access and arbitrate between them and squeeze that into a couple of dozen nano-seconds! The newer/faster CMOS chips are a little easier as they output their address pretty promptly. The 65816 is a tad more complicated as it outputs multiplexes its 24 bit address - however I have had it working.

A lot of software works ok at faster clock speeds but some doesn't. For example: TUBE transfers break as they are cycle timed; MOS works ok at 4MHz but at 8MHz the keyboard access routines fail; some Disk code I was looking at was cycle sensitive. However a lot of ROMs don't seem to mind so in the utility ROM I shall add the ability to set which ROMs run at Normal/Fast/Turbo speed and the same for the MOS.

[As for "Aeris" it's Latin for copper - I couldn't think what to call the copper thing other than "copper" but then my notes were becoming confused as to what was the Amiga Copper and what was the Beeb Copper. I know it's a bit pseudish but it was the first thing I found when looking for alternatives for copper. I'll probably change the name as it's a bit meaningless (and should really be spelled with a ligature for "ae"). It's what I ended up calling the vhdl!]
Last edited by dominicbeesley on Fri Aug 30, 2019 3:11 pm, edited 1 time in total.

VectorEyes
Posts: 376
Joined: Fri Apr 13, 2018 2:48 pm
Contact:

Re: A blitter for the beeb?

Post by VectorEyes » Fri Aug 30, 2019 4:18 pm

Just a quick note to say that this sounds really interesting. And I quite like 'Aeris' for the name!

User avatar
tricky
Posts: 4667
Joined: Tue Jun 21, 2011 9:25 am
Contact:

Re: A blitter for the beeb?

Post by tricky » Fri Aug 30, 2019 4:59 pm

RichTW has been playing with the idea of a linear display mode for the beeb, but it looks like it needs two interrupts per scan line, or one long one. If someone was going to support your card, this would seem to be very cheap for your card to write the 4 or 8 6845 bytes required, potentially extending what could be done while using your board.

dominicbeesley
Posts: 1162
Joined: Tue Apr 30, 2013 12:16 pm
Contact:

Re: A blitter for the beeb?

Post by dominicbeesley » Sat Aug 31, 2019 9:46 am

That sounds interesting. It should be possible though maybe less useful with the blitter. What is the aim of three linear mode? (Make sprite plotting easier?)

D

dominicbeesley
Posts: 1162
Joined: Tue Apr 30, 2013 12:16 pm
Contact:

Re: A blitter for the beeb?

Post by dominicbeesley » Sat Aug 31, 2019 9:51 am

Thanks vectoreyes

User avatar
tricky
Posts: 4667
Joined: Tue Jun 21, 2011 9:25 am
Contact:

Re: A blitter for the beeb?

Post by tricky » Sat Aug 31, 2019 2:49 pm

Yes, sprite plotting and line drawing.
I was trying to think of something that could be done without your board that could be done better with :)

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

Re: A blitter for the beeb?

Post by jregel » Tue Sep 03, 2019 11:17 am

Hi Dominic

When you originally posted your plans for the Blitter, you identified some features as "must-haves" and other as optional. Since that original post, you've developed some additional/different features such as faster CPU support, Copper, a co-pro with support for mapping X/Y co-ordinates to screen coordinates etc.

If you get a moment, it would be really interesting to get an updated list of features implemented and planned.

Thanks
BBC Master Turbo, Retroclinic External Datacentre, VideoNuLA, PiTubeDirect with Pi Zero, Gotek USB Floppy Emulator

dominicbeesley
Posts: 1162
Joined: Tue Apr 30, 2013 12:16 pm
Contact:

Re: A blitter for the beeb?

Post by dominicbeesley » Mon Oct 21, 2019 12:16 pm

Sorry @jregel, I missed this post somehow. Here's a general update of progress.

Currently implemented or in alpha:
- cpu: 65c02, 65816*, z80, 68008, 6809, 6309 and ability to switch to a 6502A soft-core (t65)
- two sets of sideways ram/rom which can be switched easily (to allow one set of roms for real cpu and another for t65)
- 512KB Flash ROM
- 2MB battery backed RAM (part used for SWRAM, part used for either blitter or cpu)
- 65c02, t65, 65816 at 8MHz when running from chipset RAM
- Utility ROM
- 6x09 BASIC rom with 6809/6309 assembler - some functions not implemented yet
- 6x09 MOS
- Simple screen shadowing - no OS support
- Blitter - fast sprite** plotting with/without masks
- Blitter - fast save behind and restore - saves what was under a sprite before plotting
- Blitter - simple line plotting
- DMA*** - block moves between chipset RAM, system RAM, system hardware, chipset hardware
- DMA*** - 16 or 8 bit copies with optional copy direction and endianness swap
- Aeris/Copper* - this is working ok but I need to finalise the instruction set as it was getting a bit bloated
- Sound - stereo 4 channel Amiga like sound
- EEPROM* - configuration EEPROM this is a serial device for storing startup data - used by Utility ROM, will allow for access unused portions via OSWORD calls

* proof-of-concept only
** "sprites" aren't hardware sprites
*** not true dma but a block mover

Coming soon:

Wish list / later:
- Blitter - textured lines/fills
- Blitter - triangle fill
- Blitter - stretch sprites?
- OS support for screen shadowing on Model B/Elk - maybe something like instructions from C000-D000 draw to screen ram
- GXR rom (or similar) - GXR may need support porting..lots of work
- OSWORD/BYTE interfaces to blitter, plotter, sound - fairly easy

Current Problems / Testing
=======================

I've only just got round to testing in the Electron and Master Results are below.

Electron
=======

I spent a few hours this weekend. I've got a very hacked version more or less booting to a prompt but no keyboard for some reason. The Elk poses some problems for my original design. The clocks on the fpga and the clocks on the motherboard need to be kept in close synchronisation. On the Model B this is fairly easy as there will be a phi0 trailing edge at least once every 1.5 uS or so but the Elk during a "big" screen mode hold phi0 high for ~40uS and my simple clock synchroniser loses lock. To get it to boot I had to relax the lock range but this will need some work to get right.

The other problem is anticipating "long" cycles either 1M hardware or ram contention. On the Elk there seem to be quite odd rules in the ULA and I can't quite work out when a longer cycle will happen. Or how long it will be! On the Model B it has been possible to preempt cycles and so give early warning to the 68008 and z80 processors which need to know when a cycle is going to end, before it ends. For the 65x02 processors it is always possible to stretch the clock - I'm pretty sure this is not so for the 68008 which needs to have its clock keep running and need the DTACK signal early.

There is also the problem of physically locating the board within the crowded Elk case, at present a pig tail has been made and the board mounted upside down but there is no way of getting the keyboad back in place. I'm not sure how to cater for this - maybe a 3d printed case extender?
20191021_120010.jpg
Master
======

Initial testing on this seemed ok at first but memory accesses were spuriously going wrong. I suspect that this is due to the memory controller being a CMOS device and requiring CMOS logic levels whereas the blitter board is TTL. I will try and make a buffer board to test this theory over the coming weeks.

The other problem is a physical mounting one - the Master case allows more room but the 6502 is in a different orientation in the Master, I suspect a converter board may be the simplest solution.

I haven't checked whether the t65 core supports all the instruction set needed by the M128 - I could look at adding any missing ones

Compact/Model B+
================

I've not even looked at these I suspect the B+ may need an adaptor unless the 6502 is in the same orientation as the Model B. The compact will have the same in-case room problems as the Elk?

Solutions
========

If the Master test proves successful (this will have to wait until my house move is completed) I will look at a mk.3 board:

- in default trim no cpu sockets, the 65c02 being provided by t65 or maybe just the 6502 socket to make a smaller board
- optional plug in cpu expander board(s) for other processors as these are of secondary interest to most people
- mount the fpga direct on the board, this will probably require me acquainting myself with BGA techniques or finding a different FPGA
- look at using 74LVC4245 level shifters to motherboard (and possibly cpu) to allow for rail to rail output voltages.
- get the boards (part) assembled by the fabricators at least the smaller smd/bga parts

D

dominicbeesley
Posts: 1162
Joined: Tue Apr 30, 2013 12:16 pm
Contact:

Re: A blitter for the beeb?

Post by dominicbeesley » Fri Nov 15, 2019 1:00 pm

The Master test has now completed it's initial stage - getting Tricky's OS Tester ROM to run. There will be a lot more to do on the Master before it's finished:
- merge back changes for Elk (clock stretch handling)
- merge M128 RDY handling
- a lot of work will need to be done on register placement - at present there's a bunch of Sheila registers for handling the extended memory stuff that are ok for the beeb but will clash on the M128 as they're in the range FE3X I may move some of these out of sheila into JIM mapped registers or if not will try to find a set of addresses that are free in sheila on all machines
- the utility ROM will need tweaks for M128/Elk modes

Moving house this week so it will be a couple of weeks before any of this gets started in earnest but at least now I'm sure that this should be doable on the Model B, Elk and M128 - I will have to beg/borrow a B+, Compact for further testing later.

One thing that will be required will be some thought on the physical mounting of the board for the Elk as it really needs to go inside the case and there's not a lot of room. I was thinking of maybe making a 3-d printed insert to go between the bottom/top halves of the case? the other option is to try a ribbon cable and mount the board externally?

Physically for the M128 there will need to be an intermediate adaptor board between the cpu and the blitter board. I've made on and it seems to work but I will need to load up the M128 with an econet Nula, internal co-pro and make sure I can still get the lid on!

D

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

Re: A blitter for the beeb?

Post by jregel » Fri Nov 15, 2019 7:04 pm

Thanks for the big update (a couple of posts back) and great news regarding the Master!

Just out of interest, how are you planning on mapping the 2MB RAM? You mention two sets of sideways RAM/ROM, but how is that configured and what ROM slots would they map to on a machine like the Master which already accounts for all 16 slots?

You also mention that the CPU can run at 8Mhz when accessing chipset RAM, is that when accessing the RAM that’s mapped as sideways RAM (i.e., &8000-&BFFF), or are other parts of the memory map accessible to the CPU?

From a performance perspective, if the CPU core can run at 8Mhz, what clock speed is the Blitter running at and what’s the memory interface width/speed?

Thanks - keep up the good work. Loads of questions in my head, but don’t want to swamp you… :-) Following this with interest!
BBC Master Turbo, Retroclinic External Datacentre, VideoNuLA, PiTubeDirect with Pi Zero, Gotek USB Floppy Emulator

dominicbeesley
Posts: 1162
Joined: Tue Apr 30, 2013 12:16 pm
Contact:

Re: A blitter for the beeb?

Post by dominicbeesley » Sat Nov 16, 2019 12:40 pm

Thanks for the continuing interest - I know this has been going on for a long time now but real life has to take precedence...sometimes

Yes, the CPU when accessing chip RAM/Flash can run at up to 8MHz and that does include when accessing sideways RAM/ROMS. As you say on the Master the ROM slots are all doing something so I'm planning on making it configurable which slots are shadowed and whether they run at full speed or 2MHz - a lot of code will break if run too fast.

It's also possible to shadow main RAM from 0 to &7FFF with chip RAM making code/accesses there at 8MHz. This would be in addition to any shadowing on the B+/Master. At present there is a simple BLTURBO command which can be used to shadow main RAM in 8 slices i.e. BLTURBO L07 will shadow 0-&2FFF with fast RAM and leave the mode 0/1/2 screen in place. I've not worked out the exact details but I'm going to try and implement something like normal shadow RAM for the model B/Elk I need to try out whether this can be done without modifying or slowing down the MOS [i.e. on the master any code run from Cxxx will access shadow memory]

The Blitter when moving from chip ram to chip ram runs at 8MHz, the difficult bit is when copying to screen memory it really wants to run pipelined so that a read/write from 8MHz RAM is running at the same time as the access to 2MHz RAM. This is proving to add a lot of complexity but I think I will possibly relax that requirement so that write to 2MHz ram are in parallel but reads aren't. This will allow the Blitter to copy a whole mode2 screen in 10ms (i.e. half a screen refresh period) from chip ram to system ram quick enough but can hugely simplify the internal logic as the bus doesn't need to pipelined - it just sends a write to the SYStem component which releases the bus immediately and carries out the write when it can.

Keep the questions coming! It's a welcome distraction from tripping over boxes!

D

mr-macrisc
Posts: 485
Joined: Wed Feb 07, 2018 3:35 pm
Contact:

Re: A blitter for the beeb?

Post by mr-macrisc » Sat Nov 16, 2019 9:07 pm

So with nula and blitter would it potentially be possible to have a version of elite that looks like the Archimedes versions? Colour and filled in rather than wire frame? Or is that still just a step to far? Assume it makes a fairly good r-type game quite possible though?

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

Re: A blitter for the beeb?

Post by jregel » Sun Nov 17, 2019 5:16 pm

Hope your move goes well!

More questions, you say? I have more questions... :-)

I'm trying to get a deeper understanding of the memory map for the 6502 when the Blitter board is installed. Is the following broadly right?

Presume the top 16K (&C000-&FFFF) still maps to the MOS ROM? I did stumble on a discussion recently where you were asking about cmorley's OSRAM product for the BBC B which allows the MOS ROM to be paged out in favour of a 15K RAM bank for a no-MOS memory map. Did you plan to implement this in the Blitter board?

The sideways RAM/ROM (&8000-&BFFF) can be configured to access either existing sideways RAM/ROM, or a pair(?) of 16K banks which is chipset RAM. If it's literally 2x16K banks, is there a reason for this, instead of, say, providing 4x16K banks?

Edit: Ah, on re-reading an earlier post, I've just noticed a pasted block which probably answers some of these questions! It looks like the pair of banks is one for &8000-&BFFF and the other at &C000-&FFFF, which also means you've implemented (at least in part) the OSRAM functionality. Is that correct?

Is the intention that the 6502 will use the shadowed chipset RAM for the bottom 32K RAM (&0000-&7FFF) and that existing programs will run out of chipset RAM, optionally(?) at up to 8Mhz? Or would you intend for the bottom 32K to be the Beeb's system RAM by default, running at 2Mhz? Or, the third option of using some chipset RAM for program code, and some system RAM (e.g., for display) using the ability to slice the memory?

What's in the 512K ROM on the Blitter board?

Could the Blitter be used to draw one or more screen buffers in chipset RAM, which can then be fast copied to the Beeb's system RAM for the 6845/Video ULA/NULA to display?

On a Master, could the blitter make use of both main RAM and "LYNNE" shadow RAM, allowing the blitter to be doing all the copying to the non-visible bank while the other is being displayed?

Hope these questions aren't daft and make sense.

Thanks!
BBC Master Turbo, Retroclinic External Datacentre, VideoNuLA, PiTubeDirect with Pi Zero, Gotek USB Floppy Emulator

dominicbeesley
Posts: 1162
Joined: Tue Apr 30, 2013 12:16 pm
Contact:

Re: A blitter for the beeb?

Post by dominicbeesley » Mon Nov 18, 2019 10:51 am

@mr-macrisc, if I get the triangle plotting done something like that should be possible - though it would also maybe require textured triangle plotting to get enough shades to make it convincing. I looked at Elite but have to say the amount of code to wade through was a bit over-facing - I'd definitely need some help!

@jregel,

At present the MOS area (C000-FFFF) can be overlaid by the contents rom #8, this is mainly used for testing MOS tweaks and allowing me to have a soft-MOS to allow the NoICE debugger to step into the MOS (it needs to be able to replace instructions with a break point). I might look at adding something like the cmorley OSRAM that allows the switch depending on where code is running from if that interests people. The fact the ROM #8 is overlain is arbitrary and can easily be changed - I just used any ROM so I could load OS images with SRLOAD and then switch to them and reboot.

The OS1.20 MOS doesn't quite work at the moment from chip-ram as that always runs at 8MHz - most stuff seems to be ok but the keyboard handling stuff doesn't run right. I suspect that it's something to do with the "slow" bus not being given time to settle when scanning the keyboard. I need to add a switch to allow the shadowed MOS to run at 4MHz maybe as IIRC that did work

As to how the SWRxM mapping works is this - (it only works for the Model B so far).

There are two "maps" 0/1. Map 0 is the default when running a 6502 but a jumper/switch can be used to switch to map 1

Map 0 has SWRxM's 4-7 taken from the on-board slots, the rest are from chip RAM (even numbered slots) or the 512k ROM (odd numbered slots)
Map 1 all even SRRxM's are from chip RAM all odd from the 512K ROM

The alternate maps defaults are reversed if a non-6502 processor is used.

This allows two usage scenarios: quick switching between a real non-6502 processor and the emulated 6502 each with their own set of roms. Or if you just want 6502 having two sets of ROMS set up for different tasks.

This is relatively simple to tweak and has just evolved to where it is in support of the development I've been doing - I'm open to other suggestions.

By default when the machine boots the processor "sees" normal motherboard RAM and MOS at 2MHz - a lot of things don't work well at higher speeds and I wanted things to be as compatible as possible by default. [Some of the settings (such as MOS overlay) can survive a reboot and are either reset by a power-down boot or by holding the break key for 3 seconds to return the machine to original spec]. The *BLTURBO command mentioned earlier can be used to decide which parts of the bottom 32K are taken from CHIP ram - I intend to also implement something like the B+'s shadow RAM for the model B.

The 512K ROM is used as above (for sideways ROMS) the 68008 and 65816 processors also accesses this directly.

Yes, the blitter can draw to it's own off-screen buffer and then copy this to the main SYStem RAM (in about 10ms i.e half a 50Hz TV field) this is how I've been using it on the Model B. I've not investigated the Master yet but it would probably be faster to just use CHIP RAM as on the beeb unless only a small number of drawing operations were going on. If you're plotting masked sprites or drawing lines the screen needs to be read as well as written all at 2MHz if using main/LYNNE ram which quickly eats into time. The copy from CHIP ram to SYS/LYNNE is faster than the screen is output so tearing is not really an issue - but it should be possible. In all my tests/demos I stop the CPU while the CHIP to SYS copy is happening - it should be possible though to have double buffers in CHIP ram and SYS ram and have the CPU start doing some stuff while the copy is going. It is also possible in theory to use the DMA controller to do the CHIP to SYS copy and have the blitter be drawing the next screen at the same time...

No daft questions! I need to get some time to really flush out the Master/Elk memory layouts. I haven't really used the Elk or Master enough to have a feel for the best way to use the ROM slots.

D

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

Re: A blitter for the beeb?

Post by jregel » Thu Nov 28, 2019 2:59 pm

Thanks Dominic - really interesting information. As a Master owner, I’m seeing this through the lens of how the Blitter board will work on the Master, and I don’t know quite so much about the B and Electron (despite owning one when I was growing up).

Re: OSRAM-like functionality, this could be interesting, especially if anyone wanted to do their own operating system that fully utilises the entire 6502 address space. Although I guess the most straightforward way to have a large memory space these days is to use a Pi co-processor, so maybe not a critical feature?

It’s tempting to suggest that having the ability to map chipset RAM to any of the ROM slots would be really useful. For example, having the ability to map the four SWRAM banks in a Master to faster chipset RAM or, better, to be able to replace the built in ROMs like View, Viewsheet and Edit, patch ADFS, replace DFS etc. would be extremely cool (especially if that could be battery backed up…). A bit like some of the multi-os options, but more flexible/configurable.

Of course, at that point you’re now creating a ROM/RAM board for the Master, as well as the Blitter, Copper, DMA and sound upgrade, so you may want to avoid this in fear of feature creep! :-)

Regarding the off-screen buffering, it certainly sounds like the optimum approach will be to have one or more screen buffers in chipset RAM, with the final image being copied to system RAM prior to display.

To take that concept further, does the Blitter have sufficient power to simulate something like a dual playfield screen mode? Something like having 2x20K buffers in chipset RAM, each representing a separate screen layer, and using the Blitter to combine these into a third 20K buffer in chipset RAM which is then copied to system RAM as a Mode 2 frame?

Thanks.
BBC Master Turbo, Retroclinic External Datacentre, VideoNuLA, PiTubeDirect with Pi Zero, Gotek USB Floppy Emulator

dominicbeesley
Posts: 1162
Joined: Tue Apr 30, 2013 12:16 pm
Contact:

Re: A blitter for the beeb?

Post by dominicbeesley » Thu Nov 28, 2019 11:38 pm

All good points. On the last one I think you're suggesting something akin to bit planes. The blitter as it stands doesn't quite do that but it is definitely now under consideration. On the beeb/Master it's less useful with only 4 planes to go at but could still be of use - I'll have a look as it's probably not that big a leap.

On a side note, I'm currently unable to play with hardware due to my house move so in my free time I've been looking at emulation. I now have a version of BeebEm that I've come up with that contains the Paula sound chip, as a 1MHz bus device [thanks Chrisn]. I'd like to make a full-on blitter version but that might be a bit (lot) more work. If anyone is interested in sampling(!) the Paula goodness I'll post it up for a try out!

D

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

Re: A blitter for the beeb?

Post by jregel » Fri Nov 29, 2019 10:24 am

Thanks Dominic

My original thought process was basically that if a 20K Mode 2 screen could be comprised of 2x10K Mode 5 screens, you could have an interesting and useful seven colour mode which provides a four colour background layer and a three colour foreground layer (plus transparent). Or a Mode 1 screen that similarly comprises of 2 x Mode 4 layers.

If the foreground layer colours mapped to logical colours 0-3 (with 0 being transparent) and the background layer mapped to 4-7, then you’d get what looked like a Mode 2 screen, but with a lower memory and processor overhead to update a single layer, while also allowing for some nice parallax effects (e.g., scrolling foreground with static background, or static foreground with scrolling background, or both scrolling at different speeds). Or it could be simply used to draw software sprites to the foreground without having to manually manage and redraw the background.

Of course, the Beeb doesn’t have the ability to do that, so it was a purely academic thought-exercise. I did wonder if the Blitter would be able to do that sort of thing, but then guessed that doing the mapping of Mode 5 format pixels to Mode 2 format pixels was not something the Blitter could do, whereas blitting two Mode 2 buffers into a single Mode 2 screen would be simpler (albeit more processor and memory intensive) and would achieve a similar final result.

Does that make sense? :-)
BBC Master Turbo, Retroclinic External Datacentre, VideoNuLA, PiTubeDirect with Pi Zero, Gotek USB Floppy Emulator

dominicbeesley
Posts: 1162
Joined: Tue Apr 30, 2013 12:16 pm
Contact:

Re: A blitter for the beeb?

Post by dominicbeesley » Fri Nov 29, 2019 1:41 pm

The Blitter doesn't do anything with the actual video generation so new modes aren't really possible - though with shadowing in place larger screen modes are possible.

At present it's not possible to blit say 2 bits per pixel sprites into a 4 bits per pixel screen map but it might be worth looking at. It _is_ possible to plot 1 bit per pixel sprites into any mode though, so it might be possible to plot 4 colour sprites as a pair of 1 bit per pixel operations. Kind of how it works on the Amiga I think

D

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

Re: A blitter for the beeb?

Post by jregel » Fri Nov 29, 2019 4:46 pm

dominicbeesley wrote:
Fri Nov 29, 2019 1:41 pm
The Blitter doesn't do anything with the actual video generation so new modes aren't really possible - though with shadowing in place larger screen modes are possible.
Yep, understood. Any "new modes" would ultimately have the output characteristics and limitations of existing screen modes. I was thinking of it in terms of what the blitter could add. For example, "Mode 200" (I made that up at random! :-)) could be 160x256 and 7 colours on screen with dual playfields, but to the 6845 and Video[N]ULA, would be read as Mode 2. It's the blitter that's adding the extra magic to "normal" modes.
dominicbeesley wrote:
Fri Nov 29, 2019 1:41 pm
At present it's not possible to blit say 2 bits per pixel sprites into a 4 bits per pixel screen map but it might be worth looking at. It _is_ possible to plot 1 bit per pixel sprites into any mode though, so it might be possible to plot 4 colour sprites as a pair of 1 bit per pixel operations. Kind of how it works on the Amiga I think

D
Yes, it was the Amiga dual playfields that I was partly influenced by. I guess the main difference is that in my thinking above, I was assuming the pixel format would be "chunky" BBC format and not bitplanes.
BBC Master Turbo, Retroclinic External Datacentre, VideoNuLA, PiTubeDirect with Pi Zero, Gotek USB Floppy Emulator

dominicbeesley
Posts: 1162
Joined: Tue Apr 30, 2013 12:16 pm
Contact:

Re: A blitter for the beeb?

Post by dominicbeesley » Sun Dec 01, 2019 11:55 pm

Would there be interest in me doing a BeebEm version that contained the Blitter - this would probably be a fork and unlikely to contain all the extra processors initially?

If there's interest I'll start on it now - I'm about to start on a big refactor of the vhdl which is a bit of a mess and will I'm going through that it might be a good time to start on an emulated version, which would allow me to get more of the time consuming support software written.

To get my eye in I've ported the Paula part (sound chip only) to BeebEm - this is the 1MHz bus version which can be run on Hoglet's fpga board. There's a link to a binary and source-code and more info here viewtopic.php?f=53&t=18340

D

Aside: I've now got my dream workshop where I can have all my beebs set up but I find it is far too cold - so until I've finished insulating I'm unlikely to get much real hardware/testing done in the next month or two.

Aside2: I would do this for B-em too but I've still not managed to compile it on my machine!

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

Re: A blitter for the beeb?

Post by jregel » Thu Dec 05, 2019 6:36 pm

dominicbeesley wrote:
Sun Dec 01, 2019 11:55 pm
Would there be interest in me doing a BeebEm version that contained the Blitter - this would probably be a fork and unlikely to contain all the extra processors initially?

If there's interest I'll start on it now - I'm about to start on a big refactor of the vhdl which is a bit of a mess and will I'm going through that it might be a good time to start on an emulated version, which would allow me to get more of the time consuming support software written.

To get my eye in I've ported the Paula part (sound chip only) to BeebEm - this is the 1MHz bus version which can be run on Hoglet's fpga board. There's a link to a binary and source-code and more info here viewtopic.php?f=53&t=18340

D

Aside: I've now got my dream workshop where I can have all my beebs set up but I find it is far too cold - so until I've finished insulating I'm unlikely to get much real hardware/testing done in the next month or two.

Aside2: I would do this for B-em too but I've still not managed to compile it on my machine!
I would guess that at some point, having emulator support for the Blitter will be very useful to encourage development. If you were to do that now, you'd also potentially benefit from others (smarter than me!) who could start coding for it, and probably suggest minor tweaks that may have been missed [I'm reminded of a comment by John Carmack, that if the Atari Jaguar's blitter had double buffered some of its registers, that texture mapping performance would have massively increased].
BBC Master Turbo, Retroclinic External Datacentre, VideoNuLA, PiTubeDirect with Pi Zero, Gotek USB Floppy Emulator

dominicbeesley
Posts: 1162
Joined: Tue Apr 30, 2013 12:16 pm
Contact:

Re: A blitter for the beeb?

Post by dominicbeesley » Fri Dec 06, 2019 11:23 am

Now there's a thing I'd not thought of! Double buffering so one action can be set off while the next is being constructed...cool!

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

Re: A blitter for the beeb?

Post by jregel » Tue Dec 17, 2019 1:46 pm

dominicbeesley wrote:
Fri Dec 06, 2019 11:23 am
Now there's a thing I'd not thought of! Double buffering so one action can be set off while the next is being constructed...cool!
Credit the double buffering idea to John Carmack :-)

Regarding my previous comments re: dual playfield modes, I realise I assumed the Blitter was natively working with a BBC screen layout, but how does the Blitter actually do it? Does it work in bitplanes (as per the Amiga) and then doing a final translation to BBC format before displaying?

Also, do you still plan on supporting the mapping of x/y co-ordinates to screen co-ordinates? Coincidentally, I was reading about the unreleased Commodore 65 last night, and it apparently had a similar feature to convert bitplanes to the C64/C65 native format using a hardware conversion mechanism they called Display Address Translator (DAT). So, you’ve at least got a name for it if you do implement that feature… :-)
BBC Master Turbo, Retroclinic External Datacentre, VideoNuLA, PiTubeDirect with Pi Zero, Gotek USB Floppy Emulator

Post Reply

Return to “8-bit acorn hardware”