(25 replies, posted in News)

Invite sent.

Amedia are listing the Replay for sale  both as board and board+case bundle. I assume that means they still have a board or two in stock.

The ATX power adapter has connections for power LED and switch also. There's a link to a USA and EU based retailer in the recommended parts section of the main website http://www.fpgaarcade.com/


(4 replies, posted in C64)

Nice, I'll definitely check this out as soon as I have a spare moment.


(31 replies, posted in News)

I've emailed you the link. Let me know if you have any issues with it.


(31 replies, posted in News)

I sent an invite via the board email, although I'm not sure if that has been fixed yet. If you didn't receive the invite let me know.

I've uploaded a new release of the Acorn Electron core.

This release adds quite a few new features.

  * Plus1 expansion support allowing ROMs and joysticks to be used.
  * Uncompressed UEF loading support, no more conversion to raw before loading.
  * Turbo Load. An experimental non-authentic feature to speed up tape load times by ~6x. Elite will now load in ~52s rather than just over 5 minutes.

You can download this and prior releases at https://github.com/Sector14/acorn-elect … e/releases

Please note, version 2.0+ of the core requires an Arm firmware newer than 8th January 2018. Users of older firmware will be unable to load uef (or raw) files due to the switch to a new ARM supported tape driver.

Instructions on how to use the Plus1 can be found in the included readme.md file.

Known Issues

(Edit: Potentially fixed as of v2.0.1) Turbo mode isn't fully stable yet, although it feels close, there is the odd time a game such as BeachHead will get stuck on the loading screen forever saying "SEARCHING". If that happens, eject and re-insert the tape and it'll eventually pickup where it left off.

(Edit: Fixed as of v2.0.1) Also, there's an issueatm where if the tape runs out, the OSD will slow to a crawl, if you give it long enough key presses will eventually make it to the OSD and turning off play or ejecting the tape will bring it back to normal. We know the cause of this problem and a fix will be made available in time.


(4 replies, posted in Arcade)

Nice work. Hopefully someone can find time to port some of these over smile

As for timing issues, I don't have enough experience to advise on that, but I will pass on the same advice I received when I had weird timing issues. Which from your post it sounds like you're already aware of, switch everything over to using clock enables based on a master clock, rather than deriving new clocks. It helps avoid a host of subtle timing issues.


(31 replies, posted in News)

@slim: There's recent builds of all public cores available at http://svn.fpgaarcade.com/  if you access the svn repo itself. Check the sdcard/ directory for each core for the binary and corresponding ini. Although keep in mind you may need a newer firmware (a build from 2018 will do) for the Acorn Electron. I've held off doing a new "release" for that until a new firmware has been rolled out. Although that's the only core I'm aware of that depends on a newer firmware.

There hasn't been a new set of zipped releases in a while due to a few reasons, amongst them, Mike has been heads down finishing up the daughter board, cpu changes and working on the replay2. Also there's a migration coming from svn to git which will require a new method of doing releases.

Hopefully as things settle down after the move to git changes will be a little more visible to people smile

The SVN repo is going to be moving to a new home on https://github.com/fpgaarcade/

As part of the move, email addresses will need to be added to every svn user who has made at least one commit to the SVN repo.

Whilst we can use dummy emails, if after the migration you'd like your future git commits and existing svn commits to show as by the same author, we'll need to know your current SVN user name and which email address you want linking to it.

Feel free to PM me or reply below.


(2 replies, posted in General discussion)

I power mine off when I'm done. I often jump between cores though, so there's little to gain by leaving it on.

If I get around to playing Sphinx Adventure (game I used to have on the Acorn but never got far with and want to replay for nostalgias sake) I might leave it turned on, that game iirc had no save option smile

There's a recent interview with Kevin about the supernt which touches on video output (direct time link).

Where exactly the accuracy line should be drawn is a question I was also pondering the other month and I'm still not really sure on the answer.

For example, I spent a little time improving the Acorn Electron core for both video and audio output accuracy.

For audio it was a no brainer decision, the new output is closer to the original with no knock effects.

For video, it's less clear. Anyone using a TV Scart connection should have an almost identical (minor differences as noted in blog post) signal to the Issue 2 Electron but on the flip side even with a scan doubler enabled, the non standard PAL signal means many modern monitors will not work with it.

A compatible mode was added to make it work with (hopefully) a wide range of monitors but it brings a few accuracy hits with it (including a timing one)

At which point, if any, should striving for accuracy become less important than compatibility and usability? I'm honestly not sure.

For now, I think the accuracy is worth the reduced compatibility, especially when the accuracy has a noticeable impact (be it visual or timing) and perhaps there are more (optional) tweaks that can be made at a later date to improve compatibility.

From another pov, there's a question of authentic display. By that I mean if the original system used Scart and when using Scart with the replay the display is a faithful representation, but when using the replay's HDMI it's too "crisp". I'm not sure I'd feel it important to "dirty" up the HDMI display to more closely replicate the original system (although I know many feel that is important).

If the replay was unable to output via Scart or the display when using Scart was crisper or otherwise not faithful to the original with the same connection method, then I'd want to improve (worsen ? big_smile) that. But using hdmi feels like you're making use of an option for increased compatibility and that comes at the expense of accuracy (authenticity may be a better term as the HDMI crispness is perhaps more accurate smile )

I expect there'll be split opinions on this one though.


(1 replies, posted in BBC B/ Acorn)

I've just checked in an update to the Acorn Electron core and added a new release zip 20180104_acorn_electron.zip (should appear overnight)

This version has a re-written PAL generation logic that more accurately replicates the Electron's video signal. Interrupt timing that is based on the PAL signal logic is subsequently more accurate to the point the core can be run side-by-side with an Electron and the two remain in sync (when in "authentic" mode). This version also fixes a display glitch with Firetrack caused by the video wrap logic.

As a consequence of the PAL signal changes and due to the Electron using a non-standard PAL signal, the scan line doubler alone is not able to provide a signal most monitors will display. The option for that has instead been combined with a mode selection between "authentic" and "compatible".

Authentic mode is for those who have a TV to connect to via Scart or a monitor capable of running @ 15.625kHz and putting up with the quirks in the Electron's PAL signal. Some monitors will display video when connected via HDMI but the aspect ratio will be wrong unless your monitor lets you switch to 4:3 (mine didn't) also monitors don't seem to like the odd PAL signal and have more flicker as a result than a TV would.

Compatible mode tweaks the PAL signal slightly by dropping 1/2 a scan line per field and enabling the scan line doubler. This will allow monitors to work with it over VGA/DVI and HDMI.

The downside to compatible mode is the loss of 1 scan line per frame means interrupts based on the video logic will trigger ever so slightly faster than in authentic mode and thus games will run ever so slightly faster, roughly 1 second faster than a real Electron every 5 minutes. Not really noticeable in games, but if you're running a timing/stopwatch style program keep it in mind or use authentic mode.


(5 replies, posted in BBC B/ Acorn)

I've not done any side by side tests, but it should run at the same speed as the original Electron which does mean tape loading is just as slow as it was sad

There's going to be a few quirks and differences since until recently all the ULA work has been based on guess work and the reverse engineering others have done. Still getting my head around the recently released schematics to see where improvements are needed smile

As for BBC programs, I guess that depends if they were compatible with the Electron. I believe the Electron was slower than the BBC though? I don't really know much about the BBC, maybe someone else can chime in on that one.


(5 replies, posted in BBC B/ Acorn)

The core for the Acorn Electron is now available in the public SVN in a preview state. It's nearly feature complete, with the exception of sound but there are a few known issues.

Basic/asm programs can be used from the boot prompt, games can be loaded from a virtual cassette and data saved back out. The readme in the core sdcard folder contains more information on usage of the core, required roms and converting UEF games to a format the core can use.


A couple of games will not work due to how they depend on interrupts being generated when you don't expect it. Joe Blade and Southern Belle for example. I've got a development version that now runs Joe Blade but before I push that out I'm going over the recently released ULA schematics to see if I can nail down just when each interrupt was enabled outside of what the docs originally stated.

My immediate plans are to look at improving the interrupt handling as well as sound generation. After that the OSD for cassette control will need fast forward and rewind adding, but to be usable that will need a display counter and we're still discussing the best way to support that. There's also been a discussion about getting UEF support in to avoid the hassle of the conversion step to raw.

Once that's all done, it'll be accuracy improvements, testing load/save support with a real cassette player, hopefully no bug fixing wink and looking into add-on hardware the Electron supported via the expansion bus to see what if any is worth making available.

If you play through any games and encounter any issues, please let me know.

If any of you use VSCode as your VHDL editor, I've just made a post on my blog with information on how to setup VSCode to build a core via ctrl+shift+b, program the FPGA via ctrl+shift+p and also extract errors/warnings from the build output so that you can jump directly to the error.

VSCode VHDL Build/Program Task

This is how the errors look from a failed build:

Failed build problems tab

It's not without its quirks, but I'm finding it quite an improvement with a lot of jumping around between editor, terminal and the impact gui avoided.

If you're not using VS Code, it's really worth a look despite being driven by MS, it's open-source and supports Linux smile


(35 replies, posted in Expansion cards)

The daughterboard will include an Ethernet socket. It sounds like it's getting closer to done too smile


(317 replies, posted in News)

SteveM wrote:

I'd like one for the current baseboard as well. Hopefully you don't mind shipping outside the EU of course wink

Good job it's nearly done, otherwise it'd be considered "outside the EU" to ship one to the UK for me too - brexit sad


(76 replies, posted in Amiga)

Looking forward to getting a hold of one of these for the USB smile


(2 replies, posted in BBC B/ Acorn)

I've started to do a bit of reading about the various i/o options for the Electron. I only ever remember dealing with the cassette interface when I used one in the 80's, but from what I've read there was also a floppy disk option and various  ROMs via expansion bus.

For the cassette interface, one option is to use the Generic FileIO from the Framework and to implement UEF support in the core and then an additional wrapper to interface that with the 4 cassette related pins of the ULA itself.

The ULA could then load/save via SD Card but also expose the same interface to aux i/o so that with a bit of additional hardware, a physical cassette player could be used instead.

There was mention in the other BBC thread however about the WD177x floppy drive. Was support for that ever completed? As from what I've read, Acorn used the WD1770 controller in the "Acorn DFS 1770". So if code for that already exists, that might turn out to be a quicker way to get this core up and running with load/save support, at least until I read up on the UEF and decide on an implementation (UEF might be useful to support for floppy too and not just cassette.).

Has much more thought been given to the BBC core for I/O? Does implementing UEF in the core sound like a sane strategy? Alternative suggestions?


(187 replies, posted in C64)

What's the ini file like that you're using?

uigiflip: yes, from what I've heard that will work fine.


(3 replies, posted in General discussion)

I bought a cheap ps2 keyboard to tide me over until the daughter board with the USB sockets is ready.

I wouldn't be surprised if there's a usb/ps2 active adapter, although when I did a quick search before getting the ps2 keyboard most hits were really ps2 to usb despite the wording in product title sad


(5 replies, posted in General discussion)

According to the console log it's running "ARM Firmware: 20160724_589". I've not updated the firmware since buying it but will take a look just in case that helps.

If not, and if the above file doesn't show any issue for you, I can zip up the core source and binary for you to try.