Beeb FPGA

[hoglet]

Hi Guys,

Warning, long post ahead

Over the last couple of days I've been trying to get a BBC Model B core running on the Papilio Duo (my FPGA board of choice at the moment):
http://papilio.cc/index.php?n=Papilio.P ... dwareGuide
http://papilio.cc/index.php?n=Papilio.C ... tingShield

There has been quite a bit of recent activity on Beeb FPGA cores on the Replay and Mist forums:
http://www.fpgaarcade.com/punbb/viewtopic.php?id=448
http://www.atari-forum.com/viewtopic.php?t=27906

I did think about starting with one of these, but both have got quite complex due their respective hardware platforms.

So instead I started with Mike Stirling's original work from 2011, which was attached to this thread:
http://www.mike-stirling.com/retro-fpga ... gn-detail/

I removed everything that was non-essential (e.g. the debugger), and ported what was was left from Altera to Xilinx.

I fairly quickly got something running that would boot and run Basic programs reliably, so the next step was to try to add in BEEB.MMC support.

I tried the original SUPERMMC ROM without much success. Then I realized I would need something more recent, as I needed SDHC support. So today I've been trying to get Dukkie's latest build (0210) working. Finally, after fixing a really subtle 6522 core bug relating to the operation of the shift register, it's now working perfectly.

I've been testing a few games from the STH archive and most seem to work. For example, Elite, Snapper, Chuckie Egg and Rocket Raid all work. But frustratingly, Planetoid (my favourite game) doesn't. It hangs after drawing the initial screen.

I'm aware the Planetoid uses the User VIA in an unusual way, i.e. PB7 toggling under Timer 1 control. This caused problems with early versions of BeebEm. But I'm pretty sure this functionality is present and working. Snapper, I think, also uses it, and this works fine.

I've tried updating the T65 core to the latest version, and also tried switching to AlanD's core. Neither of these things helped.

A bit of a long shot, but I wonder if anyone reading this has used a Beeb FPGA core recently (either on Mist, Replay, or an Altera board)? It would be great to know if Planetoid works on these systems.

Anyway, here's my roadmap for this project:

1. The ROMs are currently implemented with FPGA Block RAM, which is pretty scarce. Instead, I'd like to try to use write-protected external SRAM for as it's much more plentiful. There obviously a bootstrapping issue (i.e. how to load the ROM images into the external RAM), but the solution here looks really neat: http://papilio.cc/index.php?n=Playground.Bootstrap.

2. Once I free up some Block RAM, I can probably include ICE-T65 which should make debugging much easier.

3. Look at whether there are any bug fixes from either the Mist or Replay work that should be back-ported. Stephen Leary's name seems to come up a lot. He's been working on the Archie and Beeb Mist cores. Anyone know him?

4. Try to get character rounding working in Mode 7, which probably means fixing interlaced video.

5. Add a scan doubler for VGA output.

6. Implement the additional hardware present on a Master 128 and make "master mode" (and OS) jumper selectable.

7. Have a go at making a multi-boot image that contains the Atom, Electron, BBC Model B and BBC Master 128 designs.

This may take some time.....

Does anyone else have a Papilio Duo and Classic Computing shield?

Dave

PS, As always, the code is on github:
https://github.com/hoglet67/BeebFpga

[tricky]

Any chance of adding support for the 6845 half horizontal character scrolling via the h-sync pulse width trick?
I only know of my Rally-X demo that uses it on the beeb, but I think EdgeGrinder on the CPC uses it.

[grannyg]

Planetoid hangs on the Mist board too. Just after pressing space to start the game.

[hoglet]

Hi Chris,

Planetoid hangs on the Mist board too. Just after pressing space to start the game.

Thanks for testing this - sounds exactly like what I am seeing.

Once I get the ICE embedded as well, I'll have a go at debugging this.

Dave

[hoglet]

Hi Guys,

I've got Planetoid working now - it turned out to be a 6522 issue.

Planetoid uses timer T1 to toggle PB7 in one shot mode. There are two parts to this:
- Toggling PB7 when T1 expires - this was correctly implemented in the VHDL
- Clearing PB7 when T1C-H is written - this was missing from the VHDL

The fix is pretty small:
https://github.com/hoglet67/BeebFpga/co ... 21775af5f8

And it makes all the difference....

Dave

[hoglet]

Hi Tricky,

Any chance of adding support for the 6845 half horizontal character scrolling via the h-sync pulse width trick?
I only know of my Rally-X demo that uses it on the beeb, but I think EdgeGrinder on the CPC uses it.

Anything is possible - I'll add it to the roadmap.

Dave

[fordp]

Hi,
I saw tour post on FpgaArcade.com.

This is awesome stuff you are doing with Mike Sterling's core.

I have a few FPGA platforms as well as a real BBC Master and a broken BBC B.

I will be following your progress and will try and get your cores running on my DE1 if possible.

My feature requests are as follows:
1) Scan doubler, yes on your list.
2) Midi Interface to match the real one I have on my BBC (6850 based).
3) Real Floppy interface 1770 based would be good!

Good Luck with your project.

FordP

[JonC]

Just a thought, but rather than trying to include loads of ports, would it be easier to have it connect to a breakout board with all the standard BBC/Master ports on that instead. You could add extra ports that are not on the beeb too.
This approach would allow someone else to work on thee electronics while the other person concentrates on the FPGA development.

I may be talking rubbish, but it just seemed like a sensible approach

[firthmj]

Hi,

Out of vague interest (depends whether I can still locate the board I'm thinking of), how easy do you think this would be to get running on another Xilinx platform?

At one point I had a Xilinx ML501 stashed away - the FPGA should be serious overkill for a Beeb Emulation, but would have interesting possibilities (e.g. emulating a Beeb with a CoPro if I'm right about how much FPGA resource would be available)

How much is the Papilio Duo board? It would be cool if it was possible to get an accurate speed BBC running on hardware that costs less than buying a genuine one!

Michael

[hoglet]

Hi Michael,

Out of vague interest (depends whether I can still locate the board I'm thinking of), how easy do you think this would be to get running on another Xilinx platform?

It should be possible, but I don't think it would be straight forward.

The Papilio Duo doesn't have any external parallel FLASH, so I'm currently bootstrapping the BBC ROM images from SPI FLASH into external SRAM on power up. This requires:
- external SPI FLASH large enough to hold the Xilinx bitstream plus BBC ROMs (e.g. 16 paged ROMs + OS = 272KB)
- external SRAM, currently using 512KB, as this also holds the ROMs

One thing I realized with Mike Stirling's design is that it requires the external SRAM to cycle at 32MHz. The Altera DE1 board he used and the Papilio Duo both have 10ns SRAM, so this actually works reliably. Now, the memory system in the Beeb only runs at 4MHz, so it should be possible to improve things with some redesign.

At one point I had a Xilinx ML501 stashed away - the FPGA should be serious overkill for a Beeb Emulation, but would have interesting possibilities (e.g. emulating a Beeb with a CoPro if I'm right about how much FPGA resource would be available)

Looks like this board has parallel FLASH, so the bootstrapping above would not be needed. You could probably just use block RAM for main memory. This is what the Mist guys have done:
https://github.com/mist-devel/mist-boar ... /cores/bbc

I think the hard thing will be supporting several different memory architectures from the same code base.

How much is the Papilio Duo board? It would be cool if it was possible to get an accurate speed BBC running on hardware that costs less than buying a genuine one!

It's pretty expensive when you include shipping from the US, plus the Classic Computing shield. About £90 in total.

There is a thread looking a cheaper options:
http://www.stardot.org.uk/forums/viewto ... =3&t=10285

But nothing there is ideal for a Beeb FPGA.

Dave

[flynnjs]

So I just mapped this and it looks like it fits fairly comfortably in the LX9.
Are we just missing a cheap platform with enough external SRAM?
What about 5v interfacing for legacy peripherals?

I agree, it would be nice if we have a board that would be cheaper than
an original. And greener too (no lead, less leccy).

[hoglet]

So I just mapped this and it looks like it fits fairly comfortably in the LX9.
Are we just missing a cheap platform with enough external SRAM?
What about 5v interfacing for legacy peripherals?

I agree, it would be nice if we have a board that would be cheaper than
an original. And greener too (no lead, less leccy).

The ideal "minimal" platform would have:
- LX9 FPGA
- 512KB SRAM - 8 bit wide would be fine, ideally 10ns
- SPI FLASH (large enough for several designs plus ROMs)
- VGA
- Audio (ideally an external SPI DAC)
- PS/2
- SD card slot

I'm less clear how far we would want to push this in terms of legacy peripherals
- Tube
- 1MHz Bus
- Floppy
- associated level shifters
as they would make the board bigger/more expensive. Maybe, as JonC suggested earlier, these would be on a separate wing.

BTW, This is what I made for Atom FPGA:
viewtopic.php?f=44&t=6313&start=150#p88030

Dave

[tricky]

I am still hoping to do something with a miniSpartan3 ($29), but haven't started. Its bigger brother the miniSpartan6+ looks OK to my untrained eyes: no keyboard connector, but maybe one of the USBs could be used, does have RAM, MMC, LX9 and HDMI for $75 + P&P.

[hoglet]

I am still hoping to do something with a miniSpartan3 ($29), but haven't started. Its bigger brother the miniSpartan6+ looks OK to my untrained eyes: no keyboard connector, but maybe one of the USBs could be used, does have RAM, MMC, LX9 and HDMI for $75 + P&P.

A PS/2 interface could easily be wires in to one of the extension headers.

A bit of a ramble here.....

The main problem with this board for an FPGA implementation of the Beeb is it has SDRAM (Synchronous Dynamic RAM) rather than SRAM (Static RAM), which is much harder to interface to.

Here's the data sheet if you are interested: The SDRAM is an Alliance AS4C16M16S:
http://www.alliancememory.com/pdf/dram/ ... 16m16s.pdf

To give you an idea of the difficulties in using SDRAM, have a read of this thread:
https://www.scarabhardware.com/forums/t ... layground/

Some of the Spartan 6 parts contain an intergrated SDRAM controller (called a MCB):
http://www.xilinx.com/support/documenta ... /ug388.pdf
Unfortunately, this is omitted from the smaller (non-BGA) packages. But the Scarab board seems to use the larger FTG256 package, which does include two MCBs. But I don't think they wired up the SDRAM correctly. Hence the discussion about a new version that is MCB compatible:
https://www.scarabhardware.com/forums/t ... ew-design/

One popular open source SDRAM controller is Mike Field's:
http://hamsterworks.co.nz/mediawiki/ind ... Controller
Read latency is ~17 cycles, so at 100MHz this would be 170ns. The Beeb needs to fit 4 memory accesses into 1us, so this might just be possible. But then you need to squeeze in refresh cycles.

Maybe you can see now why I have a bias towards old-fashioned async SRAM

Dave

PS Also, I don't actually have a FPFA board that includes SDRAM - Maybe if I did I would overcome this bias.

[firthmj]

So I just mapped this and it looks like it fits fairly comfortably in the LX9.
Are we just missing a cheap platform with enough external SRAM?
What about 5v interfacing for legacy peripherals?

I agree, it would be nice if we have a board that would be cheaper than
an original. And greener too (no lead, less leccy).

The ideal "minimal" platform would have:
- LX9 FPGA
- 512KB SRAM - 8 bit wide would be fine, ideally 10ns
- SPI FLASH (large enough for several designs plus ROMs)
- VGA
- Audio (ideally an external SPI DAC)
- PS/2
- SD card slot

I'm less clear how far we would want to push this in terms of legacy peripherals
- Tube
- 1MHz Bus
- Floppy
- associated level shifters
as they would make the board bigger/more expensive. Maybe, as JonC suggested earlier, these would be on a separate wing.

BTW, This is what I made for Atom FPGA:
viewtopic.php?f=44&t=6313&start=150#p88030

Dave

I think it would be good to implement the Tube and 1MHz bus if possible. If you have to have the 8bit data bus and a chunk of the address bus available externally anyway for the SRAM, then for these, you just need level shifters, and the ability to do the clock stretching the 1MHz bus uses - I can't remember how it is done in the BBC B, but I think it is just 2 or 3 TTL chips. For convenience, you could have the chip select signals coming directly out of the FPGA if there are 3 pins spare (for !TUBE, FRED and JIM)

For me, "real" floppy isn't that interesting, emulating it internally to a "jukebox" SD card in the way you have already done seems more useful in this century.

Not sure how much work would be needed to make FPGA Beeb plug directly into the Lx9CoPro board, but that would be a cool aim (at least in my mind!)

[hoglet]

Here's an update on progress over the weekend.

1. Bootstrapping of ROMs

The Beeb has lots of ROMs - a fully populated Beeb can have 16 sideways ROMs (16K each) plus the OS. The Papilio Duo doesn't have any external ROMs, and up until now I've been using FPGA Block RAM, which only allowed for 3 ROMs. Last week I came across an idea for bootstrapping data from SPI FLASH into external SRAM on power up: http://papilio.cc/index.php?n=Playground.Bootstrap. So this is now what I'm doing, and it's working really well. I'll probably use the same approach in the Atom and Electron.

2. Integration of ICE-T65

I did some refactoring of ICE-T65 to expose a fulling synchronous interface with clock enable, to make it more straight forward to replace the T65 core in the BeebFPGA with ICE-T65. Connect the Duo to a PC with a the USB cable, and you have full debugging capabilities. It's really cool to be able to single step through games like Planetoids, inspect registers, memory etc. I'm sure this will be invaluable for debugging compatibility issues (like the Planetoids one, which was a 6522 bug).

3. 6845 issues

I've been working my way through several bugs / missing bits of functionality:
- Fixed the cursor flash rate
- Fixed a bug where the cursor was incorrectly positioned in column 40 rather than column 0
- Fixed the reset behaviour so the display doesn't blank when break is held down
- Implemented R05_V_Total_Adjust so vertical timing now accurate
- Corrected the timing of VSync which is particularly critical to ensure Odd and Even fields in Mode 7 are recognised. Now the VSync signal is 100% identical to a real Beeb, i.e. each field is exactly 312.5 lines (20mS), and the Vsync pulse aligns with the display start.

4. SA5050 issues

- The pixel data in Mode 7 (12MHz pixel clock) was being reclocked at 16Mhz by the Video ULA which made it look awful.
- Implemented character rounding (which involved lots of head scratching). This is computed in real time (like the original SAA5050 does), rather than using a 2x font with everything pre-calculated. I added a second port to the character generator ROM so that the reference row could be read out. Then is just a small matter of a few gates.

Here's a photo of Mode 7 before character rounding was implemented:

And after:

It looks just like a real Beeb now

Any chance of adding support for the 6845 half horizontal character scrolling via the h-sync pulse width trick?
I only know of my Rally-X demo that uses it on the beeb, but I think EdgeGrinder on the CPC uses it.

Do you have a simple test program for this? Or can you point me to your Rally-X demo please.

I think the next thing I want to look at is a Scan Doubler, to support VGA output. This is very timely, as there have been discussions around making a standalone scan doubler here:
http://www.stardot.org.uk/forums/viewto ... f=3&t=8896
I'm wondering whether to have a go at making this in such a way that it could be used standalone. Or whether to cheat, and use the pixel clocks that are readily available in BeebFpga (recovering the pixel clock is the hard part of making an external scan doubler for the Beeb.)

Does anyone have a short list of games I should test against (e.g. ones that are known to cause problems with Emulator, ones that do palette switching, etc)?

Dave

[hoglet]

Any chance of adding support for the 6845 half horizontal character scrolling via the h-sync pulse width trick?
I only know of my Rally-X demo that uses it on the beeb, but I think EdgeGrinder on the CPC uses it.

I tried this:

Code: Select all

>MODE 2
>VDU 19,0,4;0;
>?&FE00=3:?&FE01=39

On my CRT monitor the screen shifted left by half a character. But on my LCD monitor nothing happened.

I then tried the same with a real Beeb, and got the same results.

For which I conclude this is working in Beeb FPGA, but the technique is not compatible will all monitors.

Dave

[tricky]

Cool, it does only work on CRTs, B-em and jsbeeb (beta site) AFAIK as beeb-em doesn't support the trick. Attached is the RallyX demo, keys Q to U adjust the "even" frame's horizontal offset, while A to J adjust the "odd" frame's horizontal offset and keys Z to M adjust the offset for the status area at the bottom. If you run the demo, you should be able to press U, S and B to set up offsets that give horizontal scrolling as smooth as the vertical (use CRSR keys). On a real CRT, I don't think USB was best, but should work.

Phoenix is attached, which, uses partial palette programming to give: cyan stars, blue stars and clusters of cyan+blue and blue+cyan+red stars. This works correctly on a real beeb, beeb-em, b-em and jsbeeb.

Frogger is attached as it has 16 "frames"/"screens" per vsync with different colours and start addresses. This works correctly on a real beeb (if I have the correct version), b-em, jsbeeb (main or beta) but fails on beeb-em as its timing is a bit off.

You could also try the Image viewer disc to check timing as their is no flicker on any real beeb I have tried, but on some configurations, disabling interrupts for 10 seconds can cause some issues.

[tricky]

While my wishes are coming true, how about speech! I think the tms5220 has been decapped, but I don't know of any chip level emulation. The simulation in beeb-em seems to work quite well, so there must be sufficient documentation somewhere.
Has anyone found a suitable keyboard? The game Gil and I wrote, Jeltron is a two player simultaneous shoot'em up and requires up to 12 concurrent key presses

PS This project is looking great and I can't wait to see where it goes.

[hoglet]

Hi Tricky,

The good news - Image Viewer works (and looks amazing!)

Now the bad news....

- Frogger - none of the cars seem to be moving, but at the top there's a green bar that sliding to the right.

- Phoenix - I see two copies of the screen, one on top of the other, but different colours. It's possible to play it though. This sounds like it might be a 6845 bug. Any idea what's going on here?

- RallyX - I see a flickering track to start with, but then this scroll off the top of the screen vertically when I hit return, and I'm left with just the status area and nothing happening. The keys Z to M do work, and do shift the status area, but nothing else does.

Seems like there much work still to be done here!

Edit: With Frogger I get the same results on my Master Compact. Maybe there is an incompatibility with SmartSPI? Would you expect this to work on a Master Compact?

Edit2: With RallyX I just figured out you need to use the cursor keys to scroll around. Is this all that is implemented so far? The horizontal scrolling seems to be working, but the vertical scrolling is really messed up. The whole screen, including the status area, is moving around. This could be a hardware scrolling bug in the 6845 I guess.

Dave

[tricky]

Sorry, Frogger is just a static screen apart from the green bar, I included it as it has 16 vertical rupture sections with different start addresses and if the 6845 timing is off a bit, the display is usually quite wrong.
RallyX is just a demo of the scrolling and uses a similar vertical scroll to Phoenix, so I guess they both hit the same 6845 issue. They both basically use the technique described in RichTW's Virtical Rupture tutorial on RetroSoftware.
RallyX should have non-smooth horizontal scrolling with flickering at the sides with any combination of hsync settings other than U+S or Y+A if memory serves.
AstroBlaster uses a similar scrolling to RallyX, but without the half-character technique, but does give the 6845 a workout. There is a known but where the display jumps a single pixel when you start a new level (inc dying/starting a new game). The attached zip is not the latest AstroBlaster, but should work OK for testing (I think there is a newer on on the AstroBlaster thread).

[sPhilMainwaring]

I read this thread right to the bottom then I thought ... he must have been working on this for ages; how come I've not seen it before. Then I looked at the thread date 5 days!!!!!

Incredible Dave

One thing I didn't notice ... ADVAL() how easy would that be (hardware wise)?

Edit: Also when you mention the 6522 do you just mean the system via or do you also reproduce the user via / user port and are the I/O pins available for software that reads and writes to the user port (Does this include the printer port too?)

Edit 2: Also, also this got me thinking about the PS/2 keyboard ... does this just go into the FPGA alchemy and get decoded or does it somehow get mapped to an array of read write pins that are accessible on the board ... what I mean here is could we buy an old beeb shell with a beeb keyboard and be able to simply connect the keyboard/boot options via a ribbon cable to your FPGA thingymajig ... how does this black magic work!

Thanks

[hoglet]

One thing I didn't notice ... ADVAL() how easy would that be (hardware wise)?

If the FPGA hardware has an A/D convertor, then it should be straight forward. Unfortunately, the Papilio Duo/Classic Computing shield doesn't.

I guess you could interface a digital joystick, and have this output fixed analog values. Anyone know how well the Digital Joystick Adapter that Bryce is selling on Amibay works?

It's based on a design for BBC Micro User (May 83) with mistakes corrected.

BTW, a few weeks ago the Mist guys added Joystick/Analog support to their version of the Beeb core (also derived from Mike Stirling's original work)
https://github.com/mist-devel/mist-boar ... cfb0995088
But I think they have way of mapping from USB joysticks:
https://code.google.com/p/mist-board/wiki/TheBoard

Dave

[sPhilMainwaring]

Oooh poo ... sorry Dave I edited my post twice while you'd already replied to the A/D bit ... did you catch the rest about the User port / Printer port and beeb keyboard

Edit 1 (or edit 3): The dual joystick port adaptor looks cool ... I was thinking more along the lines of how easy is the beeb A/D circuitry to copy / replicate / modernise and extract from a main beeb circuit diagram

Sorry I don't know much about the internals of the FPGA stuff you use ... I guess my low level view of it is doesn't everything ultimately connect to logic and ICs connected to address, data and control lines and are the internal FPGA representations of these "extendible" outside the FPGA box? Maybe these are silly questions or maybe they might change / help implementation?

I remember we were talking about this at ABUG in August (especially the "near 64K limits") but I didn't really understand parts ... just that it would be _cool_

Needy aren't I

[hoglet]

RallyX is just a demo of the scrolling and uses a similar vertical scroll to Phoenix, so I guess they both hit the same 6845 issue. They both basically use the technique described in RichTW's Virtical Rupture tutorial on RetroSoftware.

OK, I think I found this tutorial.
https://web.archive.org/web/20150630035 ... _scrolling
I'll try and digest it, and then see what's not been implemented correctly.

Thanks....

Dave

[hoglet]

Right, another small step forward.

I tracked down the 6845 bug that was messing up Phoenix and Rally-X Demo. These both make use of R05_V_TOTAL_ADJ and I has only covered the case where this value was less than one row of scan lines (e.g. < 8 in most modes). I think the Vertical Rupture scrolling needs it to work with 8.

I found Rich TW's article very interesting:
https://web.archive.org/web/20150630035 ... _scrolling

He attaches two test disks. The first (Rupture1.ssd) works perfectly. The second (SmoothScroll.ssd) works in 7 of the offset, but messes up in the 8th. This was a bit of a surprise, I with Phoenix working I thought I had fixed the bug.

Anyway, after lots of fiddling around, it seems that what's happening is the timer interrupt handler is happening slightly too early, or running slightly too quickly. If I change the timer constant in lines 700 and 710 from 93 to 79 it starts working perfectly:

Code: Select all

  700 LDA#((5+V%)*512+6*64-93)AND255:STA&FE48
  710 LDA#((5+V%)*512+6*64-93)DIV256:STA&FE49

That equates to my BeebFPGA being ~14us faster through the interrupt handler. The timer value really does seem to be that critical. As another data point, on a real Beeb if I change the constant from 93 to 106 it starts fails in a similar way.

Tricky or Rich, any ideas how the 93 was determined? Experimentally or empirically?

I have a suspicion that BeebFPGA is not implementing the 1MHz slow down in quite the same way as the Beeb does, and I think in some cases (depending on the phase of the 1MHz and 2MHz clocks), fewer cycles are wasted. I'll have a play with this tomorrow and see if it makes a difference.

Edit: The other possibility is that maybe in a real 6845, once you are within the "Total Scan Line Adjust" period, further changes are R05 are ignored. i.e. a counter is loaded with R05 at the end of the normal rows, then this decrements to 0. In my current implementation it's a bit more dynamic. So, these lines:

Code: Select all

  570 LDA#5:STA&FE00
  580 LDAiline:STA&FE01

will take effect immediately. The more I think about it, the more I think this might be what is happening.

Dave

[BigEd]

Might be worth reading some of the dev blog posts for jsbeeb, perhaps especially Part Four - IRQs and timers

[tricky]

For phoenix, it was experimental, but for frogger,I had to write a simple 6845 sim.
From what I can remember, must comparisons are done at specific times against the current register value, except R12/13 which are latched at start of each" frame", not each vsync.

[hoglet]

Right..... after re-writing the 6845 R05_V_TOTAL_ADJ implementation for a third time, it seems to now be working without any visual glitches on all the examples that I can throw at it, including Firebird and all of those provided by Tricky.

I don't think it's yet 100% cycle accurate with a real Beeb, but it's pretty damn close now. I suspect that either:
- the latest T65 core has a couple of cases that are not cycle accurate, or
- the 1MHz Bus cycle stretching is not working quite the same in all cases, or
- there is some other effect that I'm not understanding

I'm not going to sweat any longer on this until I can find an actual Game that is failing.

On the SAA5050/Teletext front I've tweaked the character rounding so it handles double height characters correctly, and tried some of the test pages from this thread:
http://www.stardot.org.uk/forums/viewto ... 6&p=109200
It looks like the only thing remaining to be implemented is Graphics Hold which I will look at tomorrow.

All the changes are in github:
https://github.com/hoglet67/BeebFpga/commits/master

Dave

[leenew]

This is looking amazingly good
I don't know if you are tired of getting praise yet Dave?
But have some more from me!

Lee.