Better sound for the Archimedes with OPA4134PA Burr Brown OA

[Zarchos]

Tonight I did a bit of soldering ...

more tomorrow.

It works but there's sthing additional to mod to get the best of it.

[Zarchos]

Now added ...

It rocks !

Listening at the moment to CD2part2 (tune from part 2 of the Crystal Dream PC Demo) with QTM, and gosh I can feel the difference.

So for those who had not been curious enough to zoom on the 1st picture and google the chip :
I've replaced the operational amplifier, 'standard' quality, found in the Archimedes, namely the LM324N (IC39) by a Burr Brown 'hi-fi quality' compatable one, the OPA4134PA.
And it's really worth it !
I can compare with another A3000 whose filters I had removed, and the difference I can hear with the Burr Brown :
- much deeper basses
- more detailed trebble
- far less if not no distortion
- better separation of instruments, producing an overall neater sound image
- clearer 'attacks' of each sound

I had kept my fingers crossed it would be worth doing the job, and I'm not disappointed. At all.

[flaxcottage]

Very nice. The first picture looked like something out of "War of the Worlds" had just landed.

I love these Heath-Robinson mods.

Why not solder the socket to the board, though?

[Zarchos]

Very nice. The first picture looked like something out of "War of the Worlds" had just landed.

I love these Heath-Robinson mods.

Why not solder the socket to the board, though?

Agreed !
I had more the 'Eiffel Tower' in mind or wrongly installed scaffolder (about to collapse) image in mind due to professional background but your image is excellent.

Well, Sir, I tried to remove the solder but to no avail, and I had nothing at hand (like what some use to pick olives or clean their teeth or even matches) to try to set the holes free of the solder, so it's been done like that.
This part had to be done yesterday, so it's the result.


The datasheet of the Burr Brown is here :
http://pdf.datasheetcatalog.com/datashe ... achg7y.pdf
Could a good soul tell me if I should add the 2 x 10nF capacitors as described in the schematics ( on page 8 ), or is the circuit as found in the A3000 (and other Archies ?) good as it is now ?
And where I should add them...

In addition, I think it's still necessary to have the 2 capacitors between the OA and the output sockets, when you decide to bypass the filters, because this chip isn't protected ; but could sbdy tell me if it's still the case with this higher spec BB OA chip by reading the datasheet ? Just in case. Thanks in advance.


PS : Thanks for the reference to Heath-Robinson, for my own personal culture.

PS2 : Readers unaware of sound filters too powerful on most Archies should read this :
http://qubeserver.com/Qube/projects/a30 ... tered.html

[poink]

Could a good soul tell me if I should add the 2 x 10nF capacitors as described in the schematics ( on page 8 ), or is the circuit as found in the A3000 (and other Archies ?) good as it is now ?
And where I should add them...

I think there one 10nF ceramic, low-ESR capacitors between the positive power rail and ground, placed as close to the device as possible. There's a layout example on page 14 of the PDF (official source). You'd only need two if the A3000's sound system was dual rail; and it looks like it's single rail.

The caps you need might already be fitted - the A3000 should already have them, as it's also recommended by the LM324 datasheet? They might be easier to find on the board - decoupling caps aren't always shown on the schematic anywhere close to the part. I think Acorn might have implemented something similar with the R90/C95 pair.

In addition, I think it's still necessary to have the 2 capacitors between the OA and the output sockets, when you decide to bypass the filters, because this chip isn't protected

Those capacitors have nothing to do with the filtering - they're there to remove DC offset, and are required unless a DC servo (or similar) had been implemented. The size isn't critical, although larger is generally better - the suggested 10-100uF is fairly typical.

Be careful if following that mod; as the circuit diagram says that the less heavily filtered audio is on pin 1 and 8 (which looks correct from pictures of the board), whereas the guide you've linked says 1 and 14.

[Zarchos]

[SNIP]
Be careful if following that mod; as the circuit diagram says that the less heavily filtered audio is on pin 1 and 8 (which looks correct from pictures of the board), whereas the guide you've linked says 1 and 14.

Hey that's interesting.
Do you mean for both OAs, the one found in the Archies and the Burr Brown, in order to get the less filtered sound, it's not pin 1 (1 OUT left) and 14 (4 OUT right) which should be used as described on the Qube RISC OS projects page, copy hereafter :

A3000SoundLM324.jpg (8.46 KiB) Viewed 2085 times

but
- pin 1 (1 OUT left)
- pin 8 (3 OUT right) ?

If it's the case it would be a good idea to inform people who did the mod presented on the Qube RISC OS projects page they should modify the mod, and well to tell Charlie to modify his page about this mod.

The documentation of the OA is a bit like Greek to me, so what's the text or schematics / diagram detailing the level of filtering for the output pins ?

PS : Why the picture isn't directly viewable and must be downloaded, I've got no idea.

[poink]

Do you mean for both OAs, the one found in the Archies and the Burr Brown, in order to get the less filtered sound, it's not pin 1 (1 OUT left) and 14 (4 OUT right) which should be used as described on the Qube RISC OS projects page

The chip is just 4 'identical' op-amps in a single package; it's the circuits around those opamps that implement the filters. Acorn could have used them in any order - '1 OUT' is just the 'first' op amp in the package, and it's on the 'first' because of convention.

The source for those pins is Acorn's A3000 schematic; the red crosses are where the unfiltered sound is taken off via some 10uF capacitors for the internal audio connector in the other Archimedes machines. I've tried to label what the various parts of the circuit do.

Acorn's use of the LM324 in the Arcs is very odd; I guess in the A3000 there was little choice - opamps that run as low as +5V would have been a rarity at the time, but it really doesn't make sense in other Arcs, where there's ±5V or +12V available; which would have allowed the use of significantly better (but still cheap) opamps like the TL074.

edit: Then again, there's also the question about why Acorn seems to have applied a cut-off as low as 3kHz, especially as they used a 3rd order Sallen-Key topology, which is going to roll things off pretty sharply.

[Zarchos]

In your diagram isn't it 'speakers amplifier' you should have written instead of 'headphone amplifier' ?

I still don't understand why you spoke of outputs from the OA that are or not filtered, if in fact it's just a duplicate system.
Your quote
'The chip is just 4 'identical' op-amps in a single package'
and the mod on the Qube RISC OS project directly uses the outputs from the OA (red cross on your diagram), so what's after (ie the filters) isn't relevant for this mod : its purpose is to not suffer from the processing operated on the chip outputs.
So let me repeat again my question : is it ok to use pins 1 and 8, or 1 and 14 for the mod : is it exactly the same thing or not (output, direct from the chip, is exactly the same for pin 8 or 14. Yes / no ? Thanks.).

[poink]

In your diagram isn't it 'speakers amplifier' you should have written instead of 'headphone amplifier' ?

Yes it should be 'speaker'; I'm way too used to seeing the LM386 in that circuitry used to drive headphones; so I see that block as a 'headphone amplifier'.

I still don't understand why you spoke of outputs from the OA that are or not filtered, if in fact it's just a duplicate system.

The only duplication is for left and right channels.

There are 4 opamps (inside LM324/OPA4134 package). Two of them (one for each channel) convert the VIDC's differential output to a single-ended signal, their outputs are the 'unfiltered' sound. The other two (one for each channel) plus a transistor (also, one for each channel) form the active element in the filter, and therefore their outputs are the 'filtered' sound.

So let me repeat again my question : is it ok to use pins 1 and 8, or 1 and 14 for the mod : is it exactly the same thing or not.

No, it's not the same thing. Look where pin 8 is and where pin 14 is.

Pin 14 is not (directly) connected to a red cross; it's the output of the filter (give or take the transistor being used to increase drive capability). So, according to the A3000 schematic, if you connect to pin 14, you'll get filtered output on your right channel.

I'm a bit surprised that no one has heard the difference between left and right - especially considering the difference between the OPA4134 and LM324 is apparently audible.

[Zarchos]

Thanks for the explanation about how the sound is constructed, now I remember some parts of the datasheet detailing this.

If I understand you correctly there are some filters in the OA ?
So : getting rid of what's after the OA can be good, but it could be better to connect to the unfiltered pins of the OA (left AND right).

I'm going to listen again to some tunes (at present I use pin 1 and 8, exactly as detailed by Charlie) and then I'll modify the mod to connect to pin 1 and 14 and listen again to the very same tunes.

EDIT : Trying to understand the diagram, if it's 14 to get unfiltered sound for right, then it should be 7 to get unfiltered sound for left ?
I'm not able to understand the diagram, but I'm able to have a reasoning by analogy/comparison, and it's what I'd say, seeing the 4 blocks depicting the OA.

[steve3000]

and then I'll modify the mod to connect to pin 1 and 14 and listen again to the very same tunes.

If you're using QTM, you can force all output through left or right channel using SWI QTM_Stereo with R0=0, R1=3 (left) or 4 (right).

This should allow you to hear filtered sound from right channel connected to pin 14 and unfiltered sound from left channel connected to pin 1.

[poink]

If I understand you correctly there are some filters in the OA ?

Other way around, the filter uses an op-amp. Op-amps (or operational amplifiers), are just a type of amplifier; their basic function is to take an input signal, and output a larger signal.

So, if you look at the diagram, the opamps are the triangles (the circuit symbol for one is: http://3.bp.blogspot.com/-P9gTdQxIzvo/U ... _block.jpg ). You'll probably notice that there are 6 opamps in total in the A3000's sound output. Two of those are the LM386s to drive the speakers (which we'll ignore) and there's 4 marked LM324, because the LM324 chip contains 4 op amps.

getting rid of what's after the OA can be good, but it could be better to connect to the unfiltered pins of the OA (left AND right).

That's what I'd suggest; getting rid of the filters altogether almost certainly won't do anything to improve sound over just connecting before them.

Once you're doing enough soldering to replace the opamp, then there's there's certainly a lot of opportunity to put in a much better circuit (higher voltages, more solid offset voltages, using op amps in parallel etc.,) However, there's no point in putting in something that's significantly better than the VIDC's sound output - and the OPA4134 probably already is.

I'm going to listen again to some tunes (at present I use pin 1 and 8, exactly as detailed by Charlie) and then I'll modify the mod to connect to pin 1 and 14 and listen again to the very same tunes.

Other way round? (Charlie said 1 and 14.)

Careful though - it's very easy to convince yourself that you can hear an improvement if you know which the 'new' version is - in the audiophile world some people end up wasting tens of thousands on it.

[Zarchos]

ok yes it's pins 1 and 14 at present, as Charlie detailed.
I've got no doubt the OPA4134PA is a bit of luxury, but well for less than 10 euros including shipping, I wanted to try.
I dream sbdy would build an add on to sample the VIDC sound output, interpolate the signal like the Gravis UltraSound did at the time, to then re output it ...

[poink]

I dream sbdy would build an add on to sample the VIDC sound output, interpolate the signal like the Gravis UltraSound did at the time, to then re output it ...

I was actually wondering about that.

I suspect that the way to do it is a bit further back - ie., what the the NESRGB does: Watch the digital side lines of the VIDC, and grab the data off the memory bus (the ROM sockets are a reasonable place - or maybe with a PLCC socket over the VIDC, Amiga style[1]) as the MEMC delivers the data. The advantage of this method is that you'd get the data from the sound DMA in the best possible quality. Obviously, once you're doing that, there's a temptation to add some improvements - adding additional modes for 16bit/44.1kHz stereo sound and the like.

...then you might start thinking that you can really give yourself some work to do and replace some of the video parts of the VIDC - you could then add on-chip scandoubling, DVI/HDMI outputs etc., Putting 512kB (IIRC, the video memory limit) of RAM on-board (and shadowing the writes into the screen memory) would allow the entire VIDC video refresh to be stopped (although, this needs at least a partial MEMC implementation as well, in order to catch writes to screen memory via logically mapped pages)

The problem, of course, is that, piecemeal, you start to find you're implementing almost a complete Archimedes!

[1] Horrible, but apparently effective.

[Zarchos]

I dream sbdy would build an add on to sample the VIDC sound output, interpolate the signal like the Gravis UltraSound did at the time, to then re output it ...

I was actually wondering about that.

I suspect that the way to do it is a bit further back - ie., what the the NESRGB does: Watch the digital side lines of the VIDC, and grab the data off the memory bus (the ROM sockets are a reasonable place - or maybe with a PLCC socket over the VIDC, Amiga style[1]) as the MEMC delivers the data. The advantage of this method is that you'd get the data from the sound DMA in the best possible quality. Obviously, once you're doing that, there's a temptation to add some improvements - adding additional modes for 16bit/44.1kHz stereo sound and the like.

...then you might start thinking that you can really give yourself some work to do and replace some of the video parts of the VIDC - you could then add on-chip scandoubling, DVI/HDMI outputs etc., Putting 512kB (IIRC, the video memory limit) of RAM on-board (and shadowing the writes into the screen memory) would allow the entire VIDC video refresh to be stopped (although, this needs at least a partial MEMC implementation as well, in order to catch writes to screen memory via logically mapped pages)

The problem, of course, is that, piecemeal, you start to find you're implementing almost a complete Archimedes!

[1] Horrible, but apparently effective.

Ah ah I thought of all this (and a few others you didn't list) and it's one of these retro bounty projects I'd like to fund in the future.
All chips logics are implemented in the MiST, after all, so I think there's hope (in particular if fueling a bit of money to give some incentive to people who could do it, so that ... they do it !)

[steve3000]

This is great work so far, and I'm keen to hear the difference myself and to try my VIDC1 15bit sound output (see viewtopic.php?f=29&t=10874&p=134295#p134906) though the improved opamp

The problem, of course, is that, piecemeal, you start to find you're implementing almost a complete Archimedes!

This is really good point to remember... Depending how much you start to redesign and improve, you could spend a lot of time and effort effectively designing a 'RiscPC' from scratch

[Zarchos]

This is great work so far, and I'm keen to hear the difference myself and to try my VIDC1 15bit sound output (see viewtopic.php?f=29&t=10874&p=134295#p134906) though the improved opamp

The problem, of course, is that, piecemeal, you start to find you're implementing almost a complete Archimedes!

This is really good point to remember... Depending how much you start to redesign and improve, you could spend a lot of time and effort effectively designing a 'RiscPC' from scratch

I intend to mod an A5000, it'll be easier to test your work, Steve (transferring data to an a3000 isn't very easy).
If you want an OA with a socket, pm me, I'll gladly send you these parts.

[Zarchos]

OK so did the mod as Poink suggested.
Been listening to various tunes (mostly the Shadow Of The Beast tunes), the tune by Romeo in the RSI demo from the Amiga (interesting because it's very catchy https://youtu.be/oTmpqBn4dfA?t=8m44s ), and for the 8 channel tunes : Crystal Dream (Part 2) https://www.youtube.com/watch?v=BLMUfBikxTY PC demo (CD2Part2) (bloody awesome !), dimension https://modarchive.org/index.php?reques ... uery=35321 , SpaceDream, unfertig
and yes it's better, neater.

EDIT : I'm back to say it's really awesome with this Burr Brown chip, do this mod, you won't regret it I can't stop listening again and again, and thinking 'Woooaaooowww'.

[poink]

This is really good point to remember... Depending how much you start to redesign and improve, you could spend a lot of time and effort effectively designing a 'RiscPC' from scratch

And, if you're going to go that far, rather than a niche upgrade product, you might as well make something standalone. Cost and effort-wise it's probably similar (where you lose in having to reimplement things, you'd win in terms of not needing to work out how to implement things etc.,), but more people could benefit from a standalone upgraded 'Arc'.

A rule of thumb to avoid 'designing a whole machine' is probably to stay away from implementing functionality from more than one chip. So long as you drop things like shadowing writes to screen memory[1], a VIDC upgrade should be reasonable.

I'd envisage a board that'd be fitted like an ARM3 upgrade (but to the VIDC socket) which would provide a built in VIDC enhancer, scandoubler, high(er) quality audio DAC, separate video and audio clocks, and, potentially, a DVI/HDMI-type video output.

In terms of new software, I think you'd only need some to take advantage of new functionality (eg., a CD quality audio mode).
The VIDC enhancer could probably be made to work with an (unmodified) AutoVIDC, and the scandoubler could probably be automatically enabled when a 15kHz mode was selected.

[1] Incidentally, this is actually nearly pointless in a 'fresh' implementation: just use faster RAM!

[JonC]

..snip..

I'd envisage a board that'd be fitted like an ARM3 upgrade (but to the VIDC socket) which would provide a built in VIDC enhancer, scandoubler, high(er) quality audio DAC, separate video and audio clocks, and, potentially, a DVI/HDMI-type video output.

In terms of new software, I think you'd only need some to take advantage of new functionality (eg., a CD quality audio mode).
The VIDC enhancer could probably be made to work with an (unmodified) AutoVIDC, and the scandoubler could probably be automatically enabled when a 15kHz mode was selected.

What a good idea. Would this work for all none-ARM250 machines?

[steve3000]

..snip..

I'd envisage a board that'd be fitted like an ARM3 upgrade (but to the VIDC socket) which would provide a built in VIDC enhancer, scandoubler, high(er) quality audio DAC, separate video and audio clocks, and, potentially, a DVI/HDMI-type video output.

In terms of new software, I think you'd only need some to take advantage of new functionality (eg., a CD quality audio mode).
The VIDC enhancer could probably be made to work with an (unmodified) AutoVIDC, and the scandoubler could probably be automatically enabled when a 15kHz mode was selected.

What a good idea. Would this work for all none-ARM250 machines?

It is an interesting idea and such an upgrade should work on all non-ARM250 machines except the A4 (because of space restrictions), and on the A5000/A3000 you would need to remove the surface mount VIDC and provide a socket first.

There are some issues to resolve before this would be practical, but it would be great to try to implement. From my own experience, the VIDC chip is the most prone to an early death of the four ARM chips in an Archimedes* - so a replacement in some form, with added improvements along the way, would be great [*I've personally had 3 x VIDC chips die (2 x original 'Arabella' VIDCs, 1 x later VIDC1 from an A5000), one IOC, one MEMC, and I've never experienced an ARM2 or ARM3 chip die on me.]

As regards improvements, a built-in/improved VIDC enhancer and scan-double should be doable (although higher resolution screen modes would be limited to 480kb memory, because of the 512kb limited address bus to VIDC) and possibly a fully re-definable 256 colour palette. If shadowing of screen memory was implemented using additional on-board RAM in the upgrade, you could implement higher refresh rates and the maximum 256 colours in the higher resolution modes such as 800x600 (still limited to 480kb though, unless you patch/rewrite the OS pretty significantly...) - and I think this would be more convenient than trying to overclock ram in the older A300/A400 series? DVI/HDMI output could be possible, but this would need significant auxiliary components to take the feed from the upgrade board to the outside of the computer.

Improving 8bit sound would be straight forward, oversampling and separate sound clock should all be possible, however CD quality (16bit stereo @ 44.1KHz) would be a challenge again because of the 512kb addressing limit of the VIDC. You may end up having to reduce screen resolution to provide enough memory for a decent 16bit stereo sound buffer...

...anyhow these are just my thoughts on what may be possible when considering the Archimedes circuitry and RISC OS 3.1. You'd then have to find someone to actually design such an FPGA implementation and upgrade board...

[dp11]

FPGA vidc to hdmi replacement shouldn't be too hard. Some FPGAs can drive tdms signals directly so could be a single chip solution. All of the analogue stuff the vidc does then wouldn't be needed. Having enough ram to store a line of video for line doubling again would be easy.

Just to clarify some thing. The vidc is only connected to the arm databus and not the address bus.

[poink]

What a good idea. Would this work for all none-ARM250 machines?

In principle it'd work for all the machines that have a separate VIDC (so A3xx, A4xx, A540, A3000, A5000, R140, R260 and mezzanine A3010) - assuming it'd physically fit.

It would be more difficult to fit to the A3000 and mezzaine A3010 (same reason as the ARM3 is more difficult; there's no socket). It's probably not practical for the mezzaine A3010 - an is probably the better upgrade, and the card for that would block access to the VIDC socket. The truly determined[1] could probably make a carrier board/custom variant that gets the data bus from the ROM sockets.

[1] Which might well describe anyone who'd upgrade their A3010 with an ARM3 in the first place.

If shadowing of screen memory was implemented using additional on-board RAM in the upgrade

The problem is that unless you do it ColourCard style (and make the same refresh/machine speed tradeoff), you have to reimplement a chunk of MEMC, which means you also need access to the address bus etc., At that point, it's looking towards a reimplementation of the Arc than a VIDC upgrade.

still limited to 480kb though, unless you patch/rewrite the OS pretty significantly...

It's also a MEMC rather than VIDC limitation - as far as the VIDC is concerned (other than in terms of data rate!) you could ask for modes like 1440x960 (I think the logical limit is something like 2048x1024).

however CD quality (16bit stereo @ 44.1KHz) would be a challenge again because of the 512kb addressing limit of the VIDC

It's no more difficult than 8 channel, 22050Hz sound, of course, as both have exactly the same data rate.

[steve3000]

Just to clarify some thing. The vidc is only connected to the arm databus and not the address bus.

Correct. I should have been clearer, it is the MEMC which imposes the 512kb limit, so without replacing the MEMC, any VIDC upgrade is limited to accessing only the first 512kb of physical ram.

[poink]

FPGA vidc to hdmi replacement shouldn't be too hard. Some FPGAs can drive tdms signals directly so could be a single chip solution.

However, I don't think any are totally compliant - probably good enough though.

The big question about VIDC-on-FPGA is regarding RISC OS starting up. In the VIDC enhancer thread, it was mentioned that if the VIDC's not clocked, RISC OS won't start, which probably means there'd be a race between power on and the FPGA loading its configuration. (There's a couple of workarounds - including the upgrade hooking onto the reset line, so it can hold the machine in reset until it's ready).

Just to clarify some thing. The vidc is only connected to the arm databus and not the address bus.

Yup, which is why anything that gets into MEMC's territory is so much additional work; and then, once you're in MEMC's territory, there's a load of upgrades that suddenly become possible: eg., giving every machine - other than the A4 and ARM250 machines - 16MB of RAM; and in the VIDC+MEMC combined territory, there's fun stuff like hardware blitting operations etc., etc..

[AndyMc1280]

It would be more difficult to fit to the A3000 and mezzaine A3010 (same reason as the ARM3 is more difficult; there's no socket). It's probably not practical for the mezzaine A3010 - an is probably the better upgrade, and the card for that would block access to the VIDC socket. The truly determined[1] could probably make a carrier board/custom variant that gets the data bus from the ROM sockets.

[1] Which might well describe anyone who'd upgrade their A3010 with an ARM3 in the first place.

As someone with such an upgrade - yes its just too d*mn tight for space, there is pretty much no room for a socketed chip other than that for the ARM 2/3. I'd love more RAM and the like but the Mezzanine board isn't the easiest to work on. PaulV did mine and needed a fair dose of brave pills just to get the ARM 3 going.

[paulv]

The big question about VIDC-on-FPGA is regarding RISC OS starting up. In the VIDC enhancer thread, it was mentioned that if the VIDC's not clocked, RISC OS won't start, which probably means there'd be a race between power on and the FPGA loading its configuration. (There's a couple of workarounds - including the upgrade hooking onto the reset line, so it can hold the machine in reset until it's ready).

It does start, RO2 works fine, it's the RO3 POST that complains. You end up with a POST error, the floppy flashes away about VIRQ and SIRQ failures, then the machine boots just fine. It's one of the few POST errors that still allows the machine to boot.

The issue is then that if the machine starts with anything else other than a 24MHz crystal, it takes 3 or 4 minutes to boot up because of the POST error which no-one really wants.

Paul

[paulv]

As someone with such an upgrade - yes its just too d*mn tight for space, there is pretty much no room for a socketed chip other than that for the ARM 2/3. I'd love more RAM and the like but the Mezzanine board isn't the easiest to work on. PaulV did mine and needed a fair dose of brave pills just to get the ARM 3 going.

The ARM2 socket when fitted to an Adelaide board buts up and is in contact with the MEMC chip. There is no space for a second socket. That's why when I fixed Andrew's machine with a new MEMC I soldered it back onto the Adelaide board. To get the ARM2 socket to fit, I had to file down the side that came into contact with MEMC to allow all the pads to line up with the socket itself. Once the socket was soldered in, the strength lost by filing the socket wall down was augmented by the MEMC physically supporting that side of the socket.

So no, unless you trace the pads to the riser connections and make a daughter board to house a couple of MEMC chips, there's no was you could socket the MEMC at the same time as the ARM2 on an Adelaide board.

Paul

[poink]

So no, unless you trace the pads to the riser connections and make a daughter board to house a couple of MEMC chips, there's no was you could socket the MEMC at the same time as the ARM2 on an Adelaide board.

Or, equally, I assume, socketing the VIDC.

Most of the lines you need are accessible from the ROM sockets, but you'd still have maybe a couple of dozen (I've not counted) to wire back to the Adelaide. Yes, wiring-wise; a VIDC+MEMC+RAM board is probably less wiring than just VIDC, but at that point you're only IOC and importing the Amulet core from an ARM250 anyway!

The issue is then that if the machine starts with anything else other than a 24MHz crystal, it takes 3 or 4 minutes to boot up because of the POST error which no-one really wants.

It's good to know that it will boot, because that makes this slightly easier, as (for anyone who's not aware) the problem here is the related one, that when the machine's first powered on, the FPGA takes a while to read its configuration, so the mooted VIDC replacement only starts working after some time after power on.

Perhaps, the solution is to use something like Altera's MAX 10 line; which can at least do instant on - of course, it still has the usual problem of lacking 5V tolerant I/Os etc.,

[Zarchos]

The Archimedes core for the MiST exists, it means the VIDC logic has already been re implemented in an FPGA.
We have the author on *. (terriblefire).
He said he would answer any question related to his project with the MiST.
Couldn't we start a new thread 'Archie MiST and Archie superchips design' ?

To me what's been done for the MiST, in itself is remarkable, but it's also a ramp to hardware development for the real Archies : the MiST becomes a development board and the work so far to create the Archie core, the basis of 'logics' (which ?) to add 'bits and bobs' to.