Another Bush internet.tv mod thread

[thecellartroll]

I still think that adding the VCO circuitry would be the next logical step to getting VGA working properly on the IBX board?

I assume that even @philpem's modded ROM efforts still won't be able to produce all the screen modes without hardware modification.

[philpem]

There are some fairly extensive Kernel changes in the NC build related to screen modes - I'm not sure what the impact of these is. VIDC20 programming is a bit of a black art to me...!

Hardware wise I was going to add ZIF sockets (for playing with ROMs) and the audio components. I have no use for VGA-out as my use-case is TV-out.

[thecellartroll]

I have no use for VGA-out as my use-case is TV-out.

Interesting. I think the IBX200 would be a good candidate for that as it has SCART on the mainboard. I don't think it has an unpopulated audio circuit though.

[philpem]

I have no use for VGA-out as my use-case is TV-out.

Interesting. I think the IBX200 would be a good candidate for that as it has SCART on the mainboard. I don't think it has an unpopulated audio circuit though.

The IBX100 isn't a bad candidate for it either -- adding audio means installing a couple of components to the main PCB (audio DAC, amplifier and some passives), and connecting them to the SCART just involves a JST connector and some wires soldered to the underside of the SCART PCB.

If the 200 doesn't have the pads for the parts, I'd be tempted to pick up an ebay-special I2S stereo DAC and install that, rather than using the PCB pads. It'd save spinning a PCB.

[thecellartroll]

If that would work it would be cheaper than installing the missing audio components anyway. The amp chip is not so easily obtainable now.

[philpem]

Good news, everyone...

I've been making steady progress getting RISC IS 5 (32bit) ported to the Bush box. It booted the HAL and Kernel for the first time on Thursday night, but has some video and serial port issues.
Notably SerialDeviceDriver crashes on load, and the default video mode is badly timed VGA with separate sync, but needs to be PAL with composite sync.

I've put a post on the ROOL forumw in the Porting subforum, with instructions on how to build the ROM.

I'm busy for the next week or so but should be working on it again when I'm less busy!

The RO3.71 build on GitHub still works, of course.

[mogwaay]

Great work, well done!

I have a surfset that I hope to someday get some time to RiscPC-ify it so glad to hear that there is some work making RiscOS more compatible.

[thecellartroll]

Good news, everyone...

I've been making steady progress getting RISC IS 5 (32bit) ported to the Bush box. It booted the HAL and Kernel for the first time on Thursday night, but has some video and serial port issues.
Notably SerialDeviceDriver crashes on load, and the default video mode is badly timed VGA with separate sync, but needs to be PAL with composite sync.

I've put a post on the ROOL forumw in the Porting subforum, with instructions on how to build the ROM.

I'm busy for the next week or so but should be working on it again when I'm less busy!

The RO3.71 build on GitHub still works, of course.

Nice one! I’ll need to find some big EPROMs myself to try it out

[philpem]

Good news! The RO5 build booted to a star prompt for the first time this evening:

(Yes I know there's a data abort there from the GPIO driver, but I got a star prompt and I'm choosing to count this as a win!)

Video output is a bit screwed at the moment (it's outputting separate sync instead of composite) and the GPIO driver is crashing on load, but other than that the box boots quite happily.

I also found this little piece of plastic rattling around in the bottom of my IBX100's metal case. Does anyone who's taken one apart remember where it goes?

[sP1d3r]

The IBX100 isn't a bad candidate for it either -- adding audio means installing a couple of components to the main PCB (audio DAC, amplifier and some passives), and connecting them to the SCART just involves a JST connector and some wires soldered to the underside of the SCART PCB.

If the 200 doesn't have the pads for the parts, I'd be tempted to pick up an ebay-special I2S stereo DAC and install that, rather than using the PCB pads. It'd save spinning a PCB.

Apparently the Risc PC 16-bit audio upgrade for pre-SA motherboards has all the components, although I've not seen one fitted on an IBX motherboard.

[thecellartroll]

Video output is a bit screwed at the moment (it's outputting separate sync instead of composite) and the GPIO driver is crashing on load, but other than that the box boots quite happily.
2023-10-04 01.04.04.jpg

Interesting, since separate sync is one of the things missing when booting RO3.71! The chips arrived today so I'll have to do some burning and investigating on my modded box (if I ever get another day off from work).

I have no idea what that plastic thing is. Mine doesn't have it!

[sP1d3r]

The IBX100 isn't a bad candidate for it either -- adding audio means installing a couple of components to the main PCB (audio DAC, amplifier and some passives), and connecting them to the SCART just involves a JST connector and some wires soldered to the underside of the SCART PCB.

If the 200 doesn't have the pads for the parts, I'd be tempted to pick up an ebay-special I2S stereo DAC and install that, rather than using the PCB pads. It'd save spinning a PCB.

Apparently the Risc PC 16-bit audio upgrade for pre-SA motherboards has all the components, although I've not seen one fitted on an IBX motherboard.

Here's a pic of one:

Risc PC 16-bit audio upgrade

I've read a forum post about adding an IDE drive to an A3010, I wonder if something in the same vein with either a drive or a floppy would be possible on an IBX motherboard!

[philpem]

Interesting, since separate sync is one of the things missing when booting RO3.71! The chips arrived today so I'll have to do some burning and investigating on my modded box (if I ever get another day off from work).

Now that I can explain! On a Bush box, the monitor type table in the kernel (which translates the ID bits back into Sync, Mode and MonitorType values) is hacked to force interlaced sync, mode 12 or 15 (NC is mode 12, RO5 is mode 15), and a TV-type monitor.

Most of the code for that is in the Kernel, in s.PMF.osinit. Look for stuff that's wrapped in "STB" ifdefs, or checking for "IOMD_C_PALNTSCType" to be nonzero (i.e. there's a PAL/NTSC config bit on the ARM7500FE's "CLINES" 8-bit GPIO port).
(The GPIO tag file for the Bush box in the RO5 source hints that it may have originally had a front-panel power button too)

The other bit worth checking is TranslateMonitorLeadType, in the same file. For set-top-boxes, it will only detect a TV. In theory, *Configure-ing Mode, MonitorType and Sync should get things going, but there might be bits overriding the CMOS too.

In short, it'll need a bit of work, but it'll need less work on RO5. As a minimum, a VGA cable and a mod to pick up the other sync signal.

I'm trying to find a good place to fit a serial port header... for reasons of sanity, if I do, it'll be TX/RX, and RTS/CTS. Enough for a PPP connection.

I have no idea what that plastic thing is. Mine doesn't have it!

I'm starting to think it might have been from something else I dismantled... possibly an old hard drive, who knows. It's propped up on the shelf waiting for me to recognise it at some indeterminate point in the future!


Edit: I forgot to mention I'd figured out what the two unpopulated crystals were for, and some of what's needed to make them work.

• X2: Sound clock. To use this, fit X2 (11.2896 MHz), R20 (probably 22 Ohms), C41 (probably 100nF for decoupling)
• X3: VIDC HCLK. To use this, fit X3 (25.175MHz), R32 (probably 22 Ohms), C64 (probably 100nF)

The two resistors are series impedance-matching resistors. All the other crystals use 22 Ohm resistors, so those will probably work here too. Without them the clock signal won't reach the SoC.

For completeness, the other two crystal cans are X6 = 64MHz, which is MEMCLK; and X5 = 48MHz, which is CPUCLK.

The sound clock is for an external 11.2896 MHz crystal oscillator can, which is useful if you want CD-compatible audio sample rates (e.g. 44100Hz and divisions thereof) instead of RISC OS-compatible sample rates. Using this will involve patching RISC OS around a bit to enable it (VIDC SCR register CLKSEL bit needs flipping) and dealing with the fallout from the sample rates not being the same as VIDC10.
Normally RISC OS clocks the sound system from the VIDC 24MHz reference clock, and the VIDC has a divide-by-1.5 to get VIDC10's 16MHz sound clock.

The VIDC HCLK is an optional external high-speed VIDC pixel clock which is meant to supplement the VCO. As the Bush box has no VCO, it could be useful for generating VGA modes - it's effectively an on-board VIDC Enhancer. Again, RISC OS doesn't use it by default. Making it work will involve some kernel patching (change HdrSrc.Machine.Machine to enable it, and hack the kernel about to enable it as a clock source where it makes sense).
In theory, HCLK can be as high as 125 MHz (minimum high time 4ns + minimum low time 4ns) but 100 MHz is more practical, factoring rise and fall times.

I've attached the Cirrus Logic ARM7500FE SoC datasheet, the VIDC20 datasheet in PDF form, and the slightly hard-to-find ARM Application Note 17 on VIDC clock sources.

[drjaymz]

I just aquired a bush tv 14 inch for gaming.. I say just, I mean 2020 and just got around to turning it on. I noticed a network socket on it. I haven't opened it up to see inside, is this and internet TV?

[philpem]

I just aquired a bush tv 14 inch for gaming.. I say just, I mean 2020 and just got around to turning it on. I noticed a network socket on it. I haven't opened it up to see inside, is this and internet TV?

It's hard to tell -- can you post the model number (should be on the label on the back) and a photo of the front and back?

[philpem]

Sound mod - IBX100 and IBX250/IBX260

I've been having a dig into the sound mod as popularised by a variety of people. While I could pick up the parts and fit them, that's obviously too "easy" by some definition. The DAC isn't easy to find, and there are quite a few tiny support components needed.
I had a look round and found these DAC modules: https://www.amazon.co.uk/DollaTek-PCM51 ... 07PMGGMJF/
They're meant for Raspberry Pis, have a 5V regulator, a PCM5102A I2S audio DAC, take I2S audio and give line-level audio out. Perfect for strapping onto a SCART socket.

There's a slight catch in that the Bush IBX100 doesn't have the 11.2896MHz crystal. But having ripped into the sound driver, it turns out the crystal is only needed for the CD-audio sample rates (44100, 22050 and 11025 Hz). The rest are clocked from the system clock.
That's good - because it means WaveSynth_Beep, Percussion and so on should work without it.

The ARM7500FE has two output data formats for stereo 16bit digital sound: "Japanese" and "Normal". The RO5 IOMD_HAL configures the VIDC20 to generate Japanese-format audio. That means the WS (word select, aka LRCK) changes state when the MSB of a new 16-bit word is output, and WS's state indicates the left/right channel (high for left, low for right).
Obviously the DAC needs to support that ... check the datasheet (https://www.ti.com/lit/ds/symlink/pcm5102a.pdf) ... and it does.
It's called "Left Justified mode"

And going by http://www.kyllikki.org/hardware/bushstb/mod-sound.html - the sound data, power and ground can be picked up on IC1 and IC2.

The wiring's as follows...

Board setup -- make these connections with wire links on the DAC board.

• FMT -> 3.3V (signal format, high = Left Justified)
• XMT -> 3.3V (software mute, high = off)
• FLT -> GND (filter select, low = normal)
• DMP -> GND (de-emphasis, low = off)
• SCL -> GND (system clock, grounded = use internally-generated PLL clock for the DAC)

Wires from the DAC board to the IBX motherboard

• VCC -> IC1 pin 14
• GND -> IC1 pin 7
• BCK ->IC1 pin 9 (SDCLK) = sound data bit clock
• DIN -> IC1 pin 13 (SDATA) = sound data
• LCK -> IC2 pin 2 (WS) = left/right clock

Photos of the mod attached! It's really not that hard... maybe.

If you want to use this with the standard NCOS ROM, you'll need to softload the sound drivers. Details for that are on HeyRick.

To finish the mod, connect a short 3-pin screened cable between the relevant pins on the SCART connector, and the L/G/R pins on the DAC. Ideally use a connector so this can be disconnected for maintenance.

[thecellartroll]

Very cool. I have a RPC 16bit sound module, but I'm guessing one could just add the missing crystal for support of the other frequencies for full compatibility with this module?

[philpem]

Very cool. I have a RPC 16bit sound module, but I'm guessing one could just add the missing crystal for support of the other frequencies for full compatibility with this module?

Yep! I've got two crystals on order to prove it.

If the crystal isn't fitted, the CD sample rates (44100, 22050, 11025) won't work, but the standard VIDC ones will be fine.
Most Arc software will use the VIDC sample rates, excepting MP3 players and similar things.

[thecellartroll]

Good fun! I now have a batch of big EPROMs to try out your ROM mods, but it will likely be the end of November before I get to it.

[philpem]

Good fun! I now have a batch of big EPROMs to try out your ROM mods, but it will likely be the end of November before I get to it.

The good news is, by the end of November the changes might be in the official code repository -- ROOL have started to merge my patches in.
That probably won't include interlaced video support with differing fields (720x576 high resolution mode) as I'm trying to figure out how to integrate the into the VIDC driver.

At some point I'd like to go back and do some work on RO3.71 too, especially getting the PAL TV MDF, RCMM keyboard, interlaced video and Zip drive drivers loaded in.
It'd be fun to have a version of RO that booted into a games menu and E-Type (other games are available), and had working IR keyboard or joystick input to play it.

[mogwaay]

The good news is, by the end of November the changes might be in the official code repository -- ROOL have started to merge my patches in.

Wow, nice work, I've never been quite sure how 'open' RISC OS Open was so glad to hear you're able to contribute to it. What do you use for development environment?

[mogwaay]

The good news is, by the end of November the changes might be in the official code repository -- ROOL have started to merge my patches in.

Wow, nice work, I've never been quite sure how 'open' RISC OS Open was so glad to hear you're able to contribute to it. What do you use for development environment?

[philpem]

Wow, nice work, I've never been quite sure how 'open' RISC OS Open was so glad to hear you're able to contribute to it. What do you use for development environment?

It's ROOL's own one, £50 for a licence and a year of updates, then £25 per year after that.

https://www.riscosopen.org/content/sales/dde

[thecellartroll]

Anyone care to check my homework? I am sure that I have missed all kinds of conventions as I've never drawn a schematic before.

I am particularly perturbed by pin numbers on Q2 and Q3 not matching the actual symbols.

[philpem]

I am particularly perturbed by pin numbers on Q2 and Q3 not matching the actual symbols.

Pin 1 is the bottom-left corner pin, on the side with two pins.
Pin 2 is the bottom-right corner pin, opposite pin 1.
Pin 3 is the one pin on its lonesome on the top side.

Kicad's got it right, per Onsemi: https://www.onsemi.com/pdf/datasheet/bc846-d.pdf
and Nexperia: https://assets.nexperia.com/documents/d ... 7X_SER.pdf

Seems like Acorn created the SOT23 packages in their CAD system, and got pins 1 and 2 the wrong way round...

[thecellartroll]

I am particularly perturbed by pin numbers on Q2 and Q3 not matching the actual symbols.

Pin 1 is the bottom-left corner pin, on the side with two pins.
Pin 2 is the bottom-right corner pin, opposite pin 1.
Pin 3 is the one pin on its lonesome on the top side.

Kicad's got it right, per Onsemi: https://www.onsemi.com/pdf/datasheet/bc846-d.pdf
and Nexperia: https://assets.nexperia.com/documents/d ... 7X_SER.pdf

Seems like Acorn created the SOT23 packages in their CAD system, and got pins 1 and 2 the wrong way round...

Thanks! Does this mean that my schematic is borked? Do I need to re-route the connections to those pins?

[philpem]

Thanks! Does this mean that my schematic is borked? Do I need to re-route the connections to those pins?

No, it means Acorn's is -- but the borkage in the schematic is "fixed" by similar borkage in the PCB layout.

The circuit wouldn't make any sense if you swapped the base and emitter. You'd have to fit the transistors upside down to get the right pinout.

And having made this mistake before, I can tell you that yes, that's the exact way you fix it on a prototype without re-spinning the board... the IPC7711/21B compliant way is to glue the transistor down upside down and run wires... the way every engineer I know did it was to bend the pins or use big solder blobs. Disgusting fix, but a lot of things are done on prototypes that would never in a billion years be done in production.

[wiggy]

And having made this mistake before, I can tell you that yes, that's the exact way you fix it on a prototype without re-spinning the board...

Oh yes! Been there, done that...