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

Agreed !flaxcottage wrote: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?
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.Zarchos wrote: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...
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.poink wrote: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
Hey that's interesting.poink wrote:[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.
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.Zarchos wrote: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
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'.Zarchos wrote:In your diagram isn't it 'speakers amplifier' you should have written instead of 'headphone amplifier' ?
The only duplication is for left and right channels.Zarchos wrote: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.
No, it's not the same thing. Look where pin 8 is and where pin 14 is.Zarchos wrote: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.
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).Zarchos wrote:and then I'll modify the mod to connect to pin 1 and 14 and listen again to the very same tunes.
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.Zarchos wrote:If I understand you correctly there are some filters in the OA ?
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.Zarchos wrote: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).
Other way round? (Charlie said 1 and 14.)Zarchos wrote: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.
I was actually wondering about that.Zarchos wrote: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 ...
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.poink wrote:I was actually wondering about that.Zarchos wrote: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 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.
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 scratchpoink wrote:The problem, of course, is that, piecemeal, you start to find you're implementing almost a complete Archimedes!
I intend to mod an A5000, it'll be easier to test your work, Steve (transferring data to an a3000 isn't very easy).steve3000 wrote: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
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 scratchpoink wrote:The problem, of course, is that, piecemeal, you start to find you're implementing almost a complete Archimedes!
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'.steve3000 wrote: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
What a good idea. Would this work for all none-ARM250 machines?poink wrote:..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.
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.JonC wrote:What a good idea. Would this work for all none-ARM250 machines?poink wrote:..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.
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.JonC wrote:What a good idea. Would this work for all none-ARM250 machines?
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.steve3000 wrote:If shadowing of screen memory was implemented using additional on-board RAM in the upgrade
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).steve3000 wrote:still limited to 480kb though, unless you patch/rewrite the OS pretty significantly...
It's no more difficult than 8 channel, 22050Hz sound, of course, as both have exactly the same data rate.steve3000 wrote:however CD quality (16bit stereo @ 44.1KHz) would be a challenge again because of the 512kb addressing limit of the VIDC
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.dp11 wrote:Just to clarify some thing. The vidc is only connected to the arm databus and not the address bus.
However, I don't think any are totally compliant - probably good enough though.dp11 wrote:FPGA vidc to hdmi replacement shouldn't be too hard. Some FPGAs can drive tdms signals directly so could be a single chip solution.
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..dp11 wrote:Just to clarify some thing. The vidc is only connected to the arm databus and not the address bus.
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.poink wrote: 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.
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.poink wrote: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).
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.AndyMc1280 wrote: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.
Or, equally, I assume, socketing the VIDC.paulv wrote: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.
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.paulv wrote: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.