Electron FPGA

for bbc micro/electron hardware, peripherals & programming issues (NOT emulators!)
User avatar
hoglet
Posts: 6620
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: Electron FPGA

Postby hoglet » Sat Nov 21, 2015 10:56 pm

grannyg wrote:Does MMFS have the ability to swap MMB files like SmartSPI? If not could it be added. [-o<

It doesn't at the moment.

It's easy to change the ROMS that are included - just edit the make_rom_image.sh file in the roms directory. So you can customize it to include what ever you want.

Dave

User avatar
hoglet
Posts: 6620
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: Electron FPGA

Postby hoglet » Sun Nov 22, 2015 10:33 am

I should say that the reason I prefer MMFS over other MMC ROMs is that it's possible to configure it so that it uses sideways RAM as workspace:
IMG_0154.JPG

This means that PAGE remains at E00, which should make it much easier to migrate tape based games.

I've also now implemented the ABR lock registers at &FCDC-&FCDF, so the LOCK and UNLOCK commands work.

Dave

grannyg
Posts: 35
Joined: Tue Sep 10, 2013 3:06 pm

Re: Electron FPGA

Postby grannyg » Sun Nov 22, 2015 10:59 am

hoglet wrote:This means that PAGE remains at E00, which should make it much easier to migrate tape based games.



Having page at E00 cures all the problems I was having with certain games. :D

User avatar
hoglet
Posts: 6620
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: Electron FPGA

Postby hoglet » Sun Nov 22, 2015 4:52 pm

Hi Guys,

I've got a bit carried away this afternoon, and now have a Jafa-compatible Mode 7 implemented.

IMG_0156.JPG

This involved adding the following into the ElectronULA design:
- a multiplexor into the Video Ram address bus
- a HD6845SP at &FC1C-&FC1F (from BeebFpga)
- a SAA5050 (from BeebFpga)
- a multiplexor into the video output path
- the MIST scan doubler so this works in VGA mode
- the Jafa Mode 7 ROM

All of this is easily disabled.

The only thing I wasn't clear about was how to control the multiplexors to switch over to Mode 7. I was expecting to find an additional hardware register somewhere, but the really isn't one. I ended up using the MSB of the memory address being output by the 6845, and this seems to work perfectly. I'll be watching with interest DaveH's reverse engineering of an actual Jafa Mode 7 Mk 1 to see if this is how the real hardware does it as well.

I've also added in the ICE-T65 debugger, which you can access through the second USB Serial port at 57600 baud (/dev/ttyUSB1 on Linux).

I just need to spend a bit of time now getting rid of some of the build warnings!

Dave

User avatar
hoglet
Posts: 6620
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: Electron FPGA

Postby hoglet » Sun Nov 29, 2015 6:47 pm

I have a couple of questions for the Electron peeps....

I'm working on porting Electron FPGA to the Altera DE1. The Altera FPGA this uses (the 2C20) has much less internal block RAM than the Xilinx XC6SLX9 used on the Papilo (26K cf. 64K). The consequence of this is that some of main memory will have to shift to external SRAM.

Is it possible (by fiddling with the ULA registers) to set the location of the start of screen memory to less that &3000?

Are any games known to make use of this feature?

Dave

User avatar
MartinB
Posts: 4555
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity

Re: Electron FPGA

Postby MartinB » Sun Nov 29, 2015 7:16 pm

Dave wrote:Is it possible (by fiddling with the ULA registers) to set the location of the start of screen memory to less that &3000?

Not tried it myself but according to this interesting piece , yes. Have a read Dave.... :wink:

User avatar
hoglet
Posts: 6620
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: Electron FPGA

Postby hoglet » Sun Nov 29, 2015 9:01 pm

MartinB wrote:
Dave wrote:Is it possible (by fiddling with the ULA registers) to set the location of the start of screen memory to less that &3000?

Not tried it myself but according to this interesting piece , yes. Have a read Dave.... :wink:

Thanks for this info Martin - very interesting.

I wonder if anyone actually uses this?

Dave

User avatar
hoglet
Posts: 6620
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: Electron FPGA

Postby hoglet » Sun Nov 29, 2015 9:08 pm

I've just pushed an early Altera DE1 build if anyone is feeling brave:
https://github.com/hoglet67/ElectronFpg ... ra/release

The Electron FPGA and Beeb FPGA FLASH ROM images can co-exist (to make it easy to switch between the designs).

To program both ROM Images into FLASH using the DE1 Control Panel tool:
1. Erase FLASH.
2. Write BeebFPGA ROM image to address 0.
3. Write ElectronFPGA ROM image to address 80000.

If you already have the Beeb image programmed, you just need to do step 3 to add the Electron one.

Dave

User avatar
fordp
Posts: 919
Joined: Sun Feb 12, 2012 9:08 pm
Location: Kent, England

Re: Electron FPGA

Postby fordp » Sun Nov 29, 2015 11:20 pm

Hi Dave,

I will give it a go on Monday night and report back.

I have never used and Electron!

Cheers.

FordP
FordP (Simon Ellwood)
Time is an illusion. Lunchtime, doubly so!

User avatar
TheCorfiot
Posts: 648
Joined: Mon Jan 08, 2007 5:22 pm

Re: Electron FPGA

Postby TheCorfiot » Sun Nov 29, 2015 11:35 pm

I will load it up by tomorrow and get back to you.

Thanks again.
:)

User avatar
hoglet
Posts: 6620
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: Electron FPGA

Postby hoglet » Mon Nov 30, 2015 12:18 pm

Hi Guys,

The line input jack is now hooked up to the tape input of the ULA, so loading from tape should be possible.

This uses the ADC side of the WM8731 DAC/ADC on the DE1 board to digitise the signal. In fact, it really just uses the sign bit of the ADC output,, but this seems to be working really well.

I've just successfully loaded Fire Track and had a play. :D

I've also added tape monitoring (enabled via SW0) and a simple VU Meter using the green LED. Adjust the level so about 5 or 6 LEDs light up.

Dave

User avatar
hoglet
Posts: 6620
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: Electron FPGA

Postby hoglet » Mon Nov 30, 2015 4:10 pm

For anyone trying this out, Ray posted his Electron BEEB.MMB Image earlier in the thread:
viewtopic.php?t=9911&start=30#p117962

To start the menu, type:

Code: Select all

*DBOOT 100

IMG_1045.JPG

mmbimager.png

Dave

User avatar
davidb
Posts: 1901
Joined: Sun Nov 11, 2007 10:11 pm
Contact:

Re: Electron FPGA

Postby davidb » Mon Nov 30, 2015 4:36 pm

This question has probably already been answered, but I've not been paying attention: how do the games get loaded from the BEEB.MMB image? Is there a ROM involved that does that?

User avatar
hoglet
Posts: 6620
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: Electron FPGA

Postby hoglet » Mon Nov 30, 2015 5:02 pm

davidb wrote:This question has probably already been answered, but I've not been paying attention: how do the games get loaded from the BEEB.MMB image? Is there a ROM involved that does that?

Yes, there is a ROM involved.

I'm using Martin Mather's MMFS, with a few tweaks:
- I've added support for SDHC cards
- It's re-compiled with the correct address for the Electron 6522 (&FCBx)
- It's configured with the option to use sideways RAM for workspace - &B600-&BFFF in the slot in which the ROM is installed.

What you end up with is a solution that leaves PAGE at &E00. :D

I don't understand why more people aren't using MMFS. It's a complete re-write of MMBEEB starting with DFS 2.26 and bits of DFS 2.24 from the Master. I came across it in this thread which is 3 years old.

I think Martin's done a great job on this. =D> =D> =D>

In Electron FPGA it appears in ROM Slot 4, and I've made just &B600-&BFFF writeable in this slot, so it's not possible for the ROM code to get corrupted.

It you are interested in trying it, the binary I'm using (v1.05) is here:
https://github.com/hoglet67/ElectronFpg ... _swram.rom
This should work when loaded into a real Electron Sideways RAM slot, as long as it is write enabled. If not, you'll get a Card? error.

Dave

User avatar
davidb
Posts: 1901
Joined: Sun Nov 11, 2007 10:11 pm
Contact:

Re: Electron FPGA

Postby davidb » Mon Nov 30, 2015 5:35 pm

hoglet wrote:I don't understand why more people aren't using MMFS. It's a complete re-write of MMBEEB starting with DFS 2.26 and bits of DFS 2.24 from the Master. I came across it in this thread which is 3 years old.

It's because it's hidden in a thread about DFS ROM source code. :roll: ;) :D

Still, now that I'm aware of it, I wonder if it might be useful for what DaveH is doing with the MGC.

User avatar
fordp
Posts: 919
Joined: Sun Feb 12, 2012 9:08 pm
Location: Kent, England

Re: Electron FPGA

Postby fordp » Mon Nov 30, 2015 6:48 pm

I built it in Quartus and it works!
14489092193611557594102.jpg


I still do not know how to use an Electron, and my BBC music programs will not work I presume!

Edit: Just checked and the Beeb still works so I must have done something right!

Cheers
FordP
FordP (Simon Ellwood)
Time is an illusion. Lunchtime, doubly so!

User avatar
TheCorfiot
Posts: 648
Joined: Mon Jan 08, 2007 5:22 pm

Re: Electron FPGA

Postby TheCorfiot » Tue Dec 01, 2015 2:21 am

Well Dave what can i say, for first release it's just about there, Well done chap.

Some speed issues, for example snapper
sound appears to run too slowly, ex Arcadians and snapper.

I believe the Jafa Mode7 emulation is supposed to survive a CTRL Break, need to check using PC emulator

Thanks again for all your hard work...I'm still blown away with your Mode 7 Implementation, you cannot tell it apart from the real thing..
:)

User avatar
hoglet
Posts: 6620
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: Electron FPGA

Postby hoglet » Tue Dec 01, 2015 7:12 am

TheCorfiot wrote:Some speed issues, for example snapper
sound appears to run too slowly, ex Arcadians and snapper.

Can you try at the different speeds, and see which one (if any) seems right?
- F1 = 1MHz fixed
- F2 = 2MHz with contention (the default)
- F3 = 2MHz fixed
- F4 = 4MHz fixed
It's quote possible I've messed up the contention logic - I did change it quite recently.
TheCorfiot wrote:I believe the Jafa Mode7 emulation is supposed to survive a CTRL Break, need to check using PC emulator

On the real Jafa box there is a big green button which you are meant to use instead of break. It generated an NMI which the Jafa ROM then processes as a break. I'm not currently implementing the big green button.

Dave

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

Re: Electron FPGA

Postby ThomasHarte » Tue Feb 09, 2016 7:30 pm

Belated query, though only by a little, which appears not yet to be addressed: have you resolved what the ULA does with a mid-line mode change?

If I programmatically switch from Mode 6 to Mode 4 on a line that would have pixel content in the latter but not the former, does the rest of that line contain pixel content? If I switch from Mode 4 to Mode 2, from what address do pixels continue to be read? Or would I get

Or is the real answer simply that the output type decision is made once per line, not upon every cycle? Or at least some of it — e.g. the pixel clock — even if the byte interpretation is still up for grabs?

I not only do not currently have access to an Electron but no longer reside in the UK so it is unlikely that this will change. Otherwise a quick BASIC program would probably mostly answer the question.

Suggested other potential ULA enhancement: don't increase the precision of the start address register, but make the sync periods adjustable. If I could shuffle up to 8 lines from the top blank period to the bottom, I could get a perfectly smooth vertical scroll. If I could shuffle up to 64 of the 1024 horizontal pixel clock cycles from the left to the right, I could do the same horizontally, though I guess that'd probably end up needing to be a multiple of 8 to align with the RAM clock, disallowing a better-than-1-pixel scroll unless you had an extra latch in there? I'm speculating extemporaneously, maybe my logic is flawed.

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

Re: Electron FPGA

Postby tricky » Mon Jun 06, 2016 11:21 pm

I was thinking along similar lines for scrolling, but was wondering about adding the more registered to the video to allow blanking of pixels on the left and right and shiftingt the whole image lef or right.
Bring able to blank more than one byte on either side could be useful, asi do in frogger. Blanking the sides also allows smooth horizontal scrolling without having to blank and redraw the side likei have to for Rally-X on the beeb. This assumes that you already have horizontal byte scrolling.
I don't have any plans to write for the elk, so this wouldn't be for me, i think it would be useful though.

User avatar
daveejhitchins
Posts: 3691
Joined: Wed Jun 13, 2012 5:23 pm
Location: Newton Aycliffe, County Durham

Re: Electron FPGA

Postby daveejhitchins » Tue Jun 07, 2016 7:11 am

tricky wrote:I don't have any plans to write for the elk
:shock:

Dave H :?

:lol:
Parts: UM6502CE, GAL22V10D, GAL16V8D, AS6C62256A, TC514400AZ, WD1772, R6522, TMS27C512, AT28C256
Products: ARA II, ABR, ATI, AP6, MGC, AP5 . . .
For a price list, contact me at: Retro Hardware AT dave ej hitchins DOT plus DOT com

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

Re: Electron FPGA

Postby tricky » Tue Jun 07, 2016 11:42 am

Well i don't!
I do like the idea of beeb mode on the electron with the fpga doing most of the work.
I beeb with smooth horizontal hardware scrolling sounds great to me and i imagine it would broaden the appeal of a reserected elk even more.

User avatar
daveejhitchins
Posts: 3691
Joined: Wed Jun 13, 2012 5:23 pm
Location: Newton Aycliffe, County Durham

Re: Electron FPGA

Postby daveejhitchins » Tue Jun 07, 2016 3:10 pm

Yes, definitely hoping to have a near-as-possible beeb mode, in amongst the various other modes e.g. Turbo etc.

Dave H :D
Parts: UM6502CE, GAL22V10D, GAL16V8D, AS6C62256A, TC514400AZ, WD1772, R6522, TMS27C512, AT28C256
Products: ARA II, ABR, ATI, AP6, MGC, AP5 . . .
For a price list, contact me at: Retro Hardware AT dave ej hitchins DOT plus DOT com

User avatar
hicks
Posts: 47
Joined: Fri Sep 29, 2017 10:39 am
Location: UK
Contact:

Re: Electron FPGA

Postby hicks » Fri Nov 24, 2017 9:12 pm

hoglet wrote:However, I just hooked my Electron up to a proper old CRT monitor (a Commodore 1084) and it's definitely producing an interlaced display, and it looks like the timing is spot on at 50Hz, with each field containing 312.5 x 64us lines.

Further investigation with a decent storage scope allows me to see the composite sync signal in gory detail):

First (Odd) Field:
Image
Second (Even) Field:
Image


I've been looking at my Electron's video output the last couple of days as I wanted to confirm it's interlaced and not a pseudo progressive and found the same as you. However, the partial pulses either side of the 2.5 lines (160us) vsync struck me as odd (shows in your images above too).

When I traced through the signal on my scope, there's 2.5 lines (160us) of vsync, then a partial pulse, then 28 scanlines of 64us, 250 further 64us scanlines of video data, then 31 scanlines, then a partial pulse before the vsync again (next field follows same pattern). Ignoring the 4 partial pulses, that's 311.5 lines per field.

The partial pulses either side of the vsync have widths (roughly) of 11us and 17us for field 1 image and 43us, 49us for field 2. Matching these up 11us+49us=60us and 17us+43us=60us along with 4us hsync for each means these sum up to 1 extra scanline for each field giving the interlace expected total of 312.5 lines per field.

What strikes me as odd is that the pulses are not 1/2 a scanline but are split in two per field and that the split is not symmetric. It's almost as if the 160us VSync just starts part way through a 4 scanline block rather than aligned to the start of a scanline, so it begins at 11us into a scanline, then for the second field there's the 1/2 scanline offset giving a start 43us into a scanline.

I wonder if this is why my scope wouldn't correctly decode both odd and even fields.

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

Re: Electron FPGA

Postby ThomasHarte » Fri Nov 24, 2017 9:27 pm

hicks wrote:...

I wonder if this is why my scope wouldn't correctly decode both odd and even fields.

I guess it might also suggest something a bit more subtle than the dichotomy between a progressive and an interlaced machine. A valid response by a genuinely analogue CRT to a sync that isn't exactly on the half-scanline would be to start the next field not exactly half a line offset from the last. You could in principle end up with any vertical offset between the two fields, from the none whatsoever of completely progressive to the exactly half of conferment interlaced. That'd be no more off-spec than a progressive signal already is. A TV with better error correction should nudge it to one end of the spectrum, but I don't see why it should be uniform in which.

User avatar
hicks
Posts: 47
Joined: Fri Sep 29, 2017 10:39 am
Location: UK
Contact:

Re: Electron FPGA

Postby hicks » Sat Nov 25, 2017 4:54 pm

ThomasHarte wrote:I guess it might also suggest something a bit more subtle than the dichotomy between a progressive and an interlaced machine.


I think that's more or less what the pseudo progressive setup takes advantage of, ensuring that a TV outputs both field one and field two with no offset which in effect turns 576i @ 50Hz into a 287p @ 50Hz. Whether the partial pulses are also accomplishing the same, I'm not sure, but it seems it may be.

I've given a full interlace signal a go today and the flicker is very apparent. The Electron on my TV looks to more closely match (visually at least) the pseudo progressive output.

I'm going to leave my core using the pseudo progressive signal for now as it's visually very close to the Electron's output.

User avatar
hicks
Posts: 47
Joined: Fri Sep 29, 2017 10:39 am
Location: UK
Contact:

Re: Electron FPGA

Postby hicks » Sat Dec 02, 2017 11:58 am

I was comparing some recent sound filtering (lpf+hpf) improvements I'd made in my core by running the NightWorld intro screen on both my Electron and core at the same time. After a few minutes of listening I noticed the music had gone slightly out of sync between the two. The more time passed and the further out of sync they became.

By starting the game on both Core and Electron at the same time and observing the moon at the bottom of the screen that reaches the right hand side in sync on the first cycle, but then the Electron is slightly behind on the second and falls further and further behind with each cycle. I measured about 10 seconds out of sync after about 50 minutes.

I'm curious if Dave's core exhibits this too.

If you need the UEF https://www.stairwaytohell.com/electron ... orld_E.zip

User avatar
hicks
Posts: 47
Joined: Fri Sep 29, 2017 10:39 am
Location: UK
Contact:

Re: Electron FPGA

Postby hicks » Wed Dec 13, 2017 11:21 pm

I've rewritten the signal generation for my core now. The previous pseudo progressive signal required dropping a line and adding half a short scanline sync extra, to make two identical 312 line fields. It resulted in a nice flicker free "progressive" display rather than the horrible flicker that a true interlaced signal produces, but I believe that line loss threw out the timing.

The new implementation is a more accurate recreation of the Electron's signal, warts and all. It's now a 625 line interlaced PAL signal but with the same counter timing that results in the production of the differing width partial pulses either side of vsync.

The partial pulses cause a similar effect to the pseudo progressive signal so no flickering, however they're managing to do it without the need to drop a whole scanline and throw out the timing. I wonder who came up with this TV sync "hack" first? Either way, I like it :mrgreen:

With this change the timing between the core and Electron appears to be very close. No more audio going out of sync or moon reaching the edge first and a timing loop remains in sync between the two.


Return to “hardware”

Who is online

Users browsing this forum: 1024MAK, Bing [Bot], crj, ssgoodwin and 9 guests