Another Bush internet.tv mod thread

philpem · Post by **philpem** » Thu Dec 22, 2022 7:10 pm

My IBX100 arrived yesterday -- thanks @thecellartroll!

The ROMs can be read on a standard EPROM reader. You need to tell it they're ST Micro M27C322 (32Mbit, 16-bit wide) ROMs and disable device-ID checking. They match the ones Myelin uploaded elsewhere, so I won't bother uploading them again... you can get them from his thread: viewtopic.php?t=19132

I've set it up with a Zip drive and got it to the desktop ... only problem now is, the mouse cursor won't move, even with MouseKeys or KeyRat loaded

Does anyone know how to get the mouse cursor to move?

Now onto my thoughts about the mods...

PS/2 mod

If anyone wants to do the PS/2 mod, the connectors are available from AliExpress: https://www.aliexpress.com/item/32786896527.html
If that doesn't work, search for "PS2 double socket", "PS2 socket keyboard and mouse" or similar.
It doesn't matter (electrically) but the tracks seem to route the bottom socket to the little Philips chip that handles the keyboard and IR remote, and the top socket goes towards the 37C669 Super I/O. My guess is that means the mouse is the top one.

Sadly the bottom PS/2 socket is blocked by the 8-pin socket on the power board. That means either the motherboard will need to be unscrewed and tilted up to access the keyboard port, or the power board tilted out of the way.

In terms of alternative mods - I'm thinking the best option might be to drill holes in the back and fit a pair of chassis-mount mini-DIN sockets.

Annoyingly the pin pitch isn't 2.54mm, but it's close enough that bending the pins on a 2.54mm pin or socket header should be enough to make it fit the PCB. Remove the middle two pins from the left side, and it should be a perfect fit for the PCB.
After that's done, get a PS/2 Y-cable (or a pair of extensions) and cut off the plug end. Crimp a 2x4 0.1in socket onto the ends, wired appropriately.

RISC OS 3.71

Evidently RO3.71 boots fairly well on the stock hardware, as a 4MB ROM.

I figure we probably want to cherry-pick some of the changes from Spinner (first-gen NC) and Kernel 5.13 branch of the RISC OS Open codebase: https://gitlab.riscosopen.org/RiscOS/So ... ernel-5_13

Chances are we'll want --

* Up to 16MB of ROM mappable - https://gitlab.riscosopen.org/RiscOS/So ... 8111a85eb1
* First attempt to get POST working on 8MB ROM - https://gitlab.riscosopen.org/RiscOS/So ... 608b60aea0
* More adjustments to 8MB ROM situation - https://gitlab.riscosopen.org/RiscOS/So ... d16fbc7dd3

There are some other changes related to the 669 Super I/O and blinking the front panel LEDs if the POST fails, they'll probably be needed later on, but just the 8MB ROM changes and some build system tweaks should be enough to get an 8MB kernel image.

Going further might require an ArcFlash for the Bush, but who knows... the PCMCIA slot next to the ROM socket is apparently for a flash ROM cartridge (likely PCMCIA linear Flash or some custom thing).

Interestingly the NC remote allowed delete-power-on using the right arrow key: https://gitlab.riscosopen.org/RiscOS/So ... 56a0b352df
It's up for debate whether this protocol is what the Bush NC keyboard uses, via the little Philips IR/PS2 chip.

Relevant codenames in the ROOL source --

Spinner - first-gen NC
Lazarus - Internet TV
Bethany - multilingual Internet TV

In terms of ways folks can play along at home -- the RO3.71 code builds with the last (26bit) version of Norcroft/Acorn C, which is sat on 4corn. In theory the old ROOL Kernel should build with it too, at least in this era. If it doesn't, Gerph's RISC OS build service has the Norcroft compiler, so that's possibly a route forward for people. Though I'd feel bad about hammering it without buying him a few beers to cover the AWS minutes...

thecellartroll · Post by **thecellartroll** » Thu Dec 22, 2022 7:47 pm

philpem wrote: ↑Thu Dec 22, 2022 7:10 pm Sadly the bottom PS/2 socket is blocked by the 8-pin socket on the power board. That means either the motherboard will need to be unscrewed and tilted up to access the keyboard port, or the power board tilted out of the way.

This isn't an issue on IBX250 or 260 as the power board is different. IMO you may as well throw the power board away and take video straight from the video header on the board

That does kill the IR keyboard too of course, but that is also guff so no real loss.

philpem · Post by **philpem** » Fri Dec 23, 2022 1:14 am

Good news everyone!

I found some useful stuff deep in the "bush-hacking" mailing list archives (http://www.earth.li/pipermail/bush-hacking/)!

115200 Baud PPP link over the 1st serial port
It turns out the Super I/O is misconfigured and only one of the serial ports will generate IRQs. There's a BASIC program here which reconfigures the Super I/O to generate IRQs for both serial ports on the same IRQ output:
http://www.earth.li/pipermail/bush-hack ... 00127.html

Flash ROMs
I found a photo somewhere (http://www.kyllikki.org/hardware/bushst ... se-mod.jpg) of a Bush STB with a Macronix MX29F1615PC-90 flash ROM fitted -- these are 16Mbit (1M x 16-bit = 2Mbyte) flash chips, giving 32Mbit = 4Mbyte total.
32Mbit (2M * 16 = 4Mbyte) parts seem to be a rarity in 5V - there's the MX29L3211, but that's a 3V part, obsolete, and only available in SMD packages.
Seems like M27C322 EPROMs might be the way to go.

Why's my mouse not working?
Per http://www.earth.li/pipermail/bush-hack ... 00123.html - the mini remote included with the IBX100 has mouse buttons which move the cursor. The cursors on the top-right of the big Bush KB200 IR keyboard ... are cursor keys and enter (the centre nub might be enter, it might be Select/left mouse). So you can't move the cursor about with a KB200.

KeyRat is an unknown quantity, and doesn't seem to emulate the mouse cursor, only the buttons. (someone prove me wrong on this?)

MKey / MouseKey (http://www.bleb.org/writings/bushstb/article2.html) seems to include code to move the cursor, but I'm not sure what the magic keypress is... Edit: the archived copy on ArcArc (https://arcarc.nl/apps.html) says the numeric keypad is needed to move the cursor... which isn't present on the Bush keyboard either.

Warfarin (also on ArcArc) uses Alt + cursor keys for motion and Alt+Ins/Home/PgUp for the mouse buttons. However: the keycodes for the buttons are configurable with environment variables; scancodes &5A, &5B and &5C are the ones MouseKey uses, which is A, S, D, for Select, Menu, Adjust, respectively.

Connector pinouts

http://web.archive.org/web/200312040906 ... bx100.html

Copied below for convenience...

What's inside the box

There are 2 circuit boards inside the box - a power supply and video encoder board and the main processor board.

The power supply and video encoder board contains a power connector, reverse polarity protection and filtering for the incoming power, front panel LED driver circuitry and a video encoder.

The video encoder take RGB video from the main board and converts it to PAL composite video. It is based around the AD724 video encoder chip. The RGB signals are also buffered and connected to the scart socket. Use the RGB output in preference to the composite video output - it gives far better results. You may need to grab the composite sync signal from the processor board to sync old (non SCART) monitors that aren't happy stripping sync from the composite signal.
The processor board

Components

Lucent modem DSP chipset
PS7500 ARM710 core SoC
SMSC FDC37C669 Super IO / FDC
24C32 4Kx8 serial EEPROM

Connectors

PL1 - Audio out (not fitted)
1 - Left out
2 - 0V
3 - Right out

Audio-out isn't fitted as standard, and NC-OS doesn't include the sound Modules. There are two ways forward:
Bodge in a RISC PC 16bit sound upgrade: http://www.kyllikki.org/hardware/bushstb/mod-sound.html
Fit the missing components: see:
http://www.earth.li/pipermail/bush-hack ... 00084.html (most of the component values)
http://www.earth.li/pipermail/bush-hack ... 00093.html (corrections)
http://www.earth.li/pipermail/bush-hack ... 00086.html (more updates)
http://www.earth.li/pipermail/bush-hack ... 00087.html (decoupling caps)
http://www.earth.li/pipermail/bush-hack ... 00092.html (J-K flipflop)

The schematic links in the thread are broken; it later moved to leman.net: http://web.archive.org/web/200307140318 ... _audio.pdf
Datasheets for the audio chips: http://web.archive.org/web/200304021318 ... index.html

PL2 - RGB out
1 - Red
2 - 0V
3 - Green
4 - 0V
5 - Blue
6 - 0V
7 - 0V
8 - Composite Sync

PL3 - 68 pin expansion connector
This appears to provide D31-D0, A23-A2 but precious few control signals. It would probably be a useful place for taking off buses to connect to Ethernet controller etc.
Pin 5 appears to not be connected to the CPU, but is pulled low through a 320R resistor. Presumably it can be used to disable the onboard ROM.
There are almost certainly some errors in this pinout. Please let me know if you find anything.

26/06/02 - Thanks to Theo Markettos for pointing out that this pinout is very similar to PCMCIA flash memory cards. It looks hopeful that a PCMCIA memory module could be used, although some modifications will probably need to be made around the status bits to prevent them forcing the high word of the data bus.
I have numbered the pins in the same order as the PCMCIA connector.

1 - GND
2 - D3
3 - D4
4 - D5
5 - D6
6 - D7
7 - nROMCS (CE1)
8 - LA12
9 - (OE)/ROM disable?
10 - LA13
11 - LA11
12 - LA10
13 - LA15
14 - LA16
15 - nIOW
16 - D16 (BUSY)
17 - +5V
18 - NC (VPP1)
19 - LA18
20 - LA17
21 - LA14
22 - LA9
23 - LA8
24 - LA7
25 - LA6
26 - LA5
27 - LA4
28 - LA3
29 - LA2
30 - D0
31 - D1
32 - D2
33 - NC
34 - GND

35 - GND
36 - D17 (CD1)
37 - D11
38 - D12
39 - D13
40 - D14
41 - D15
42 - NC (CE2)
43 - D18 (NC)
44 - D19 (NC)
45 - D20 (NC)
46 - LA19
47 - LA20
48 - LA21
49 - LA22 (NC)
50 - LA23 (NC)
51 - +5V
52 - NC (VPP2)
53 - D21 (NC)
54 - D22 (NC)
55 - D23 (NC)
56 - D24 (NC)
57 - D25 (NC)
58 - D26 (NC)
59 - D27 (NC)
60 - D28 (NC)
61 - D29 (REG)
62 - D30 (BVD2)
63 - NC (BVD1)
64 - D8
65 - D9
66 - D10
67 - D31 (CD2)
68 - GND

PL4 - Front panel
1 - IR in
2 - 0V
3 - 0V
4 - LED
5 - Fn (Standby)

PL7 - Power
1 - +5V
2 - +5V
3 - 0V
4 - 0V

PL8 - ? (not fitted)

SK1 - PS/2 Mouse/keyboard (not fitted)
You should also add clamping diodes D1,D2,D3 and D4 if you want to use this connector. It's connected to the PS7500, and the RISC-OS software will happily make use of a keyboard if one is connected.

SK2 - 72 pin SIMM RAM module
Supplied with 4*5118164, 8MB EDO.

SK3 - DB25 parallel port

SK4 - RJ45 modem phone line port

philpem · Post by **philpem** » Fri Jan 13, 2023 5:27 pm

I've been doing a bit of tracing and modding --

The mystery extra pins near the RGB connector
Going by the silkscreen on the board, there's an unfitted additional connector, PL8, which partially overlaps PL2 (the RGB+Csync output connector). Pin 1 starts as if it were pin 9 of PL2.

The two extra pins are:
1: Ground
2: IOP7 on the Cirrus chip, pin 172. This is a GPIO.

Going by the GPIO map in the ROOL source (RiscOS/Sources/HWSupport/PortMan/Resources/Lazarus/Tags) -- GPIO 7 is the right LED. So this would activate if the right ("Internet") LED was on.

Code: Select all

EEPROM_Protect:     1:0:2
LED_Left:           3:0:3
NTSC:               4:0:0
Front_Panel_Button: 6:0:0
LED_Right:          7:0:3

The format is bitnumber:port:flags.
Flag bit 0 is "inverted", flag bit 1 is "output pin".

So it seems this is an output which comes on when the box is running (not in standby).

That would also suggest (to me anyway) that the LED pin was being used to generate the "video present" signal on the SCART socket. If the LED's on, turn the video output on.

Bodge resistor
I've traced the bodge resistor which is soldered between one pad of R77 and one of R49. It's exactly what it's been described as: a pull-down resistor which pulls down a data line (D2 from memory) on the data bus. Basically it forces the Podule detect active.

Keyboard and mouse ports
I've just about given up waiting for the keyboard and mouse sockets to arrive on the slow boat - I got an email a few days ago to say the delivery date has been pushed back to February-March.
Instead I've ordered a PS/2 splitter cable to cut up for the sockets, and fitted the pin headers:

It was fairly easy to get these to fit. I had to bend the PCB-side pins in a little, solder the connector down, then bend the top-side pins in a little to straighten them out. An empty socket housing went straight over the top.

The four protection diodes should be fitted too, I used four BAT54S diodes after checking the pinout.

RISC OS 3.71
I've forked the RO3.71 source repository to https://github.com/philpem/RiscOS_371_BushSTB. For now, the master branch has some clean-ups on it, and the whole thing can be built from a (clean) source checkout. Most of the build cruft is gone from the HEAD of the master branch.

I've started porting bits of the ROOL source code across, but it seems to be quite dependent on the new-style build system. There are also some kernel changes which nicely broke the FPEmulator build.

ROOL source code
The public release of the ROOL source contains a lot of the main software components for the Bush Internet TV set-top. From the codename list, the codename we want to look out for is "Lazarus".

Notable bits:

Sources/Programmer/HdrSrc/hdr/Machine: lots of Lazarus-related kernel configuration definitions, including the GPIO mappings, special "standby" keycode, modem I/O mappings and "fake podule" ID, and so on.
Kernel: A lot of Lazarus-related stuff is on the "Customer_M_Demo" branch if you work back a bit. The 5.13 tagged kernel release seems to be the one the IBX100 shipped with.
BuildSys/ModuleDB: Lists a few NC modules as being in the ROOL source, but "closed": NCMALib, STBBoot, STBChoices, STBRoot, modem drivers and utilities, keyboard driver (RCMMDriver) and so on. What a shame they're not part of the open-source release.

It seems like there's a reasonable prospect of getting the ROOL branch built for the Bush IBX, but as with RO3.71 we'll be missing a lot of things.

Onward, ever onward!

thecellartroll · Post by **thecellartroll** » Fri Jan 13, 2023 6:35 pm

How is PS2 behaving for you?

Under RO3.71 I find that it doesn't behave very well. It would be nice to have a 3.71 ROM with the NCs PS2 module and the zip drive drivers instead of some other app. Then some real playing with stuff could happen.

thecellartroll · Post by **thecellartroll** » Fri Jan 13, 2023 6:38 pm

philpem wrote: ↑Fri Jan 13, 2023 5:27 pm I've been doing a bit of tracing and modding --

Bodge resistor
I've traced the bodge resistor which is soldered between one pad of R77 and one of R49. It's exactly what it's been described as: a pull-down resistor which pulls down a data line (D2 from memory) on the data bus. Basically it forces the Podule detect active.

Interesting. I wonder whether removing it makes the podule slots appear as empty. That would certainly help with adding an IDE podule.

I'm away for two weeks so it'll be February before I see the IBX again.

philpem · Post by **philpem** » Sat Jan 21, 2023 9:04 pm

thecellartroll wrote: ↑Fri Jan 13, 2023 6:38 pm
philpem wrote: ↑Fri Jan 13, 2023 5:27 pm I've been doing a bit of tracing and modding --

Bodge resistor
I've traced the bodge resistor which is soldered between one pad of R77 and one of R49. It's exactly what it's been described as: a pull-down resistor which pulls down a data line (D2 from memory) on the data bus. Basically it forces the Podule detect active.

Interesting. I wonder whether removing it makes the podule slots appear as empty. That would certainly help with adding an IDE podule.

That (probably) wouldn't disable the modem, though... it'd be sat on the bus as the podule slot.
It might be easier to add IDE by connecting to the Super I/O chip's IDE outputs, which would have a side benefit of working on ADFS.

I've been doing a bit of work on RO3.71: https://github.com/philpem/RiscOS_371_BushSTB (NC branch)

Currently working:

5.13 kernel (same as the Bush box came with) with NVRAM manager and Port Manager modules (no RTC needed; LEDs and video are controllable)
Boots to the Supervisor prompt.
PS/2 mouse and keyboard (need to do *Configure MouseType 3 for the mouse to work)
RISC OS Desktop

Currently not working:

Video output switch-on -- this is a GPIO issue and just needs the PortManager driver modifying to turn A/V on
Infrared remote/keyboard (driver source for RCMMDriver isn't in the ROOL repos)
Adding boot files to ResourceFS (need to have a think about this)
Booting straight into the Desktop (probably an NVRAM change)

I haven't fitted the RTC mod yet. The NC branch includes some upstream changes from ROOL's kernel which allows the box to boot with just the NVRAM EEPROM, albeit with no battery-backed realtime clock.

thecellartroll · Post by **thecellartroll** » Tue Jan 24, 2023 12:05 am

Nice work! Are you burning these to 8mb ROMS for testing?

philpem · Post by **philpem** » Tue Jan 24, 2023 1:40 am

thecellartroll wrote: ↑Tue Jan 24, 2023 12:05 am Nice work! Are you burning these to 8mb ROMS for testing?

Yeah, a pair of 27C322 EPROMs each time, and I've got two pairs on hand so I can program the next rev while I'm testing the other.

I've got a box of ten chips on the way from China as I'm getting tired of waiting for the EPROM eraser.

Someone's suggested backporting the Nested WIMP, which could be an interesting addition. It'd save softloading it, which would obviously save some RAM. After that point, I'm not sure what else to add.

thecellartroll · Post by **thecellartroll** » Tue Jan 24, 2023 5:27 pm

Are you able to put the zip drivers in? I assume there should be space in an 8mb ROM since the space for Fresco and the like would not be necessary.

I'm guessing you're also using the PS2 driver from RO NC? Does it behave properly with ctrl break working when mouse and keyboard are plugged in?

philpem · Post by **philpem** » Tue Jan 24, 2023 7:19 pm

thecellartroll wrote: ↑Tue Jan 24, 2023 5:27 pm Are you able to put the zip drivers in? I assume there should be space in an 8mb ROM since the space for Fresco and the like would not be necessary.

That's actually the last thing I did - I copied the last version I could find of the Argo drivers (https://downloads.orpheusweb.co.uk/pub/RISCOS/Argo/Zip/) into ResourceFS. I haven't tried that ROM build yet, though.

I was looking at RO5 (there's enough left of the Bush STB stuff that an IOMD build might even boot) but that would need a 32bit Zip driver writing. Sadly both PowerZip and the Argo driver are 26-bit-only. The good news there is, it "only" needs a SCSI driver writing, as parallel Zip drives are really an Iomega VPI0/PPA (Parallel Port Adapter) or VPI2/IMM (Iomega MatchMaker) parallel-to-SCSI converter chip mated to a SCSI Zip drive.

Sadly I doubt the documentation for the chip is available any more, so such a project would have to be done by porting the Linux PPA or IMM driver cores (or the FreeBSD VPO one) across and adding the RISC OS bits:
https://github.com/freebsd/freebsd-src/ ... /dev/ppbus (vpo.c/h, vpoio.c/h)
https://github.com/torvalds/linux/tree/ ... ivers/scsi (ppa.c/h, imm.c/h)

thecellartroll wrote: ↑Tue Jan 24, 2023 5:27 pm I'm guessing you're also using the PS2 driver from RO NC? Does it behave properly with ctrl break working when mouse and keyboard are plugged in?

I'm using the one from RO3.71!
You have to do *Configure MouseType 3 on boot, but after that you have a full working PS/2 mouse and keyboard.

I haven't copied the RCMM keyboard driver across yet, it may be linked against the Shared C Library in the Pace ROM, in which case it's an open question whether it can be transplanted like that at all.

I haven't tried Ctrl-Break with a PS/2 keyboard, but it works on an A7000 so I imagine it should work here? (ho hum) unless the "STB" (set top box) kernel config flag disables that.

thecellartroll · Post by **thecellartroll** » Mon Jan 30, 2023 8:54 pm

philpem wrote: ↑Tue Jan 24, 2023 7:19 pm
I haven't copied the RCMM keyboard driver across yet, it may be linked against the Shared C Library in the Pace ROM, in which case it's an open question whether it can be transplanted like that at all.

I haven't tried Ctrl-Break with a PS/2 keyboard, but it works on an A7000 so I imagine it should work here? (ho hum) unless the "STB" (set top box) kernel config flag disables that.

On mine I soldered a two-way PS2 socket harvested from an old motherboard. I also added the diodes. Although the mouse and keyboard work correctly for some reason ctrl-break doesn't work if there is anything plugged into the "mouse" socket. It just hangs rather than resetting the machine. If yours doesn't behave the same then there must be a difference in the ROM or I must have DONE something when I fitted the socket. The latter is entirely possible as I have no skills.

thecellartroll · Post by **thecellartroll** » Thu Feb 02, 2023 9:35 pm

Update: looks like I killed mine by leaving it without a battery for two weeks. It seems like the CMOS RAM chip has got stuck in some configuration that prevents the machine from booting. Of course since Del power on does nothing there is no way to fix that without replacing the chip. Bah.

Unless Post Box could force a copy of A CMOS RAM save perhaps from an A7000 on to the chip?

IanJeffray · Post by **IanJeffray** » Thu Feb 02, 2023 10:16 pm

thecellartroll wrote: ↑Thu Feb 02, 2023 9:35 pm Update: looks like I killed mine by leaving it without a battery for two weeks. It seems like the CMOS RAM chip has got stuck in some configuration that prevents the machine from booting. Of course since Del power on does nothing there is no way to fix that without replacing the chip. Bah.

That seems bronto unlikely. It's not like silicon dies when powered down.

thecellartroll wrote: ↑Thu Feb 02, 2023 9:35 pm Unless Post Box could force a copy of A CMOS RAM save perhaps from an A7000 on to the chip?

"POSTbox" can't. Unless you fancy writing python scripts to use POSTbox to bitbang an I2C bus out of IOMD like RISC OS does...

thecellartroll · Post by **thecellartroll** » Thu Feb 02, 2023 10:47 pm

IanJeffray wrote: ↑Thu Feb 02, 2023 10:16 pm That seems bronto unlikely. It's not like silicon dies when powered down.

Since it worked and then sat with no power and no battery for two weeks then didn't work, something died while powered down.

But of course the CMOS RAM chip doesn't need to be dead. It just needs to be in a state that upsets RISC OS. We know that most of the settings get randomised if you leave it without a battery for ages but we also know that not all the settings get randomised or lost at the same time based on my experiences of having the CMOS RAM chip in there without the battery circuit.

What is very weird is that sometimes the keyboard lights come on and Caps Lock and Num Lock work but mostly the keyboard lights don't come on at all. I haven't plugged POSTbox in again yet. That can be a job for the weekend.

Ultimately though Phils custom ROM is the future for these boxes I think. Maybe we will just have to accept no VGA.

thecellartroll · Post by **thecellartroll** » Fri Feb 10, 2023 10:22 pm

Update: leaving it alone for another couple of weeks seems to have sorted it. Note to self: don't pull the battery out again!

philpem · Post by **philpem** » Tue May 02, 2023 1:40 am

I've wandered back into this thread after spotting a minor mistake ... I'd forgotten to link the Usenet post which explained how to fit the sound components to an IBX... and foolishly I didn't bookmark it. Oh well. More internet deep diving later... I've edited the prior post to avoid confusing people. Here's what I've found --

Audio-out isn't fitted as standard, and NC-OS doesn't include the sound Modules. There are two ways forward:

Bodge in a RISC PC 16bit sound upgrade: http://www.kyllikki.org/hardware/bushstb/mod-sound.html

Fit the missing components: see:
http://www.earth.li/pipermail/bush-hack ... 00084.html (most of the component values)
http://www.earth.li/pipermail/bush-hack ... 00093.html (corrections)
http://www.earth.li/pipermail/bush-hack ... 00086.html (more updates)
http://www.earth.li/pipermail/bush-hack ... 00087.html (decoupling caps)
http://www.earth.li/pipermail/bush-hack ... 00092.html (J-K flipflop)

The schematic links in the thread are broken; it later moved to leman.net:
http://web.archive.org/web/200307140318 ... _audio.pdf
I suspect this is the most accurate representation of what the parts should be, and how they're wired up, but I haven't checked. YMMV.

Same website also has datasheets for the audio chips: http://web.archive.org/web/200304021318 ... index.html

This is something I'd like to try, especially as I've got a possible use for the STB (TV video+audio generation).

Latest on RISC OS is I'm busy doing other things at the moment (mainly a solar/PV inverter install and under-floor Ethernet cabling). I've got a background task to get the Zip driver going, and after that I'm going to look at how much of the STB code is still left in the RO5 Kernel.

Network is a TBD. I wanted to do a PLIP driver - I figured RO had a SLIP driver. Turns out it actually has PPP, which is a more complex protocol. That means the driver is more complex too.
I'd have to dike all the PPPD code out of the PPPDriver (there's a lot of it), then implement PLIP or SLIP.
I can probably pull that off using the DCI4 Spec on Theo M's website (text file), but it's a shame I've not found a nicer-formatted version of that which is easier to read.

IanJeffray · Post by **IanJeffray** » Tue May 02, 2023 9:49 am

philpem wrote: ↑Tue May 02, 2023 1:40 am I figured RO had a SLIP driver.

Well, there's this... http://arcarc.nl/archive/Archives%20to% ... DRIVER.ARC

philpem · Post by **philpem** » Tue May 02, 2023 11:18 am

IanJeffray wrote: ↑Tue May 02, 2023 9:49 am
philpem wrote: ↑Tue May 02, 2023 1:40 am I figured RO had a SLIP driver.
Well, there's this... http://arcarc.nl/archive/Archives%20to% ... DRIVER.ARC

Sadly there's no source code included - which would have been useful to convert the driver from SLIP to PLIP. (easier than doing the same to the PPP driver)

thecellartroll · Post by **thecellartroll** » Wed May 31, 2023 3:03 pm

I now have a (dead) A7000 mainboard on my desk, so I will try to work out how the VGA output on that is connected to the SOC and perhaps see where I went wrong.

I am aware that the SOC is different, but since the mainboard layout isn't (AFAIK) hopefully the VGA interface will also be the same.

I may try to fix the A7000 mainboard in another thread.

thecellartroll · Post by **thecellartroll** » Wed May 31, 2023 9:32 pm

This will be the first place for investigation I guess:

mogwaay · Post by **mogwaay** » Fri Jun 02, 2023 10:14 am

thecellartroll wrote: ↑Wed May 31, 2023 3:03 pm I now have a (dead) A7000 mainboard on my desk, so I will try to work out how the VGA output on that is connected to the SOC and perhaps see where I went wrong.

I am aware that the SOC is different, but since the mainboard layout isn't (AFAIK) hopefully the VGA interface will also be the same.

I may try to fix the A7000 mainboard in another thread.

This is very cool! I got myself a IBX200 a while ago with the intention of seeing if it could be made into a basic A7000(+). But getting information on the A7000(+) was not easy - I had been scouring internet for photos of the mainboard just to get grainy pics to try and pick out bits out of, so it's brilliant that you've got hold of a board to study in more detail to see what they did to connect it to signals from the 7500 chip. Good luck, I'll be interested to know how you get on!

I got myself bogged down on this by trying to build a Flash ROM replacement chip using 4x 39SF040s to create an easier to flash 27C160 replacement so I could try and get RiscOS5 on it, but I haven't managed to get this board working yet... I'm doing this between other projects, so I might post up where I've got with that on another thread as someone else with an interest in a 27C160 flash replacement might like to find out where I've gone wrong...

philpem · Post by **philpem** » Mon Jun 05, 2023 8:34 am

I haven't looked in the Kernel code in a while -- but you may not be getting separate syncs if the VIDC part of the 7500FE was configured for composite sync. Although that's speculation, I don't usually poke VIDC at such a low level. (though I may have to if I want NTSC support)

The NVRAM module in the Stardot repositories (and some of the Kernel changes) are responsible for forcing the monitor type and video mode to PAL TV. Could be that doing so turns off the separate syncs?

philpem · Post by **philpem** » Mon Jun 05, 2023 9:10 am

mogwaay wrote: ↑Fri Jun 02, 2023 10:14 am I got myself bogged down on this by trying to build a Flash ROM replacement chip using 4x 39SF040s to create an easier to flash 27C160 replacement so I could try and get RiscOS5 on it, but I haven't managed to get this board working yet... I'm doing this between other projects, so I might post up where I've got with that on another thread as someone else with an interest in a 27C160 flash replacement might like to find out where I've gone wrong...

That's neat! I've been trying to get RO5 going on mine too, using 27C160 EPROMs (I bought about a dozen of them). I've been meaning to make a "stagger mount" board so I can fit ZIF sockets - sadly the sockets on the PCB are too close together to take them as they are.

I've been talking to ROOL about getting some of the software components for the Bush box released, but many are Pace proprietary. There was some good news though -- the Zip drive driver source code is now open, and in the ROOL repositories (IZipFS and PPADriverJ). I've also managed to track down the original author and he's provided the ZipFiler source code. Sadly it's all in assembler...

The IR Keyboard/Mouse driver and modem driver are "under investigation" but the current thinking (last I heard) was they probably can't be released openly as they were done by Pace under contract for Bush.

I figured the modem driver could be replaced with a patched 16550 Blockdriver, and the keyboard could be done by using one of the keyboard drivers in the ROOL source tree as a base, and "keyb_serir.c" / "serir_ps2.c" from Vincent Sanders' kernel patch (http://www.kyllikki.org/software/armlinux/) to get some idea how the keyboard protocol works.
There's also a bit of code in the Kernel which gives some extra info on the protocol: https://gitlab.riscosopen.org/RiscOS/So ... 56a0b352df
Matching this up with https://www.sbprojects.net/knowledge/ir/rcmm.php suggests that the keyboard controller chip is just an RC-MM to RS232 converter.

mogwaay · Post by **mogwaay** » Tue Jun 06, 2023 9:59 am

philpem wrote: ↑Mon Jun 05, 2023 9:10 am
That's neat! I've been trying to get RO5 going on mine too, using 27C160 EPROMs (I bought about a dozen of them). I've been meaning to make a "stagger mount" board so I can fit ZIF sockets - sadly the sockets on the PCB are too close together to take them as they are.

Thanks, I have another idea to try and get my board working, but then I will probably kick it into the long grass...

I was going to try and hacked version of the RO5 binaries that might be able to use the EEPROM instead of the RTC NVRAM. The code base seemed to have an EEPROM detection code in it but it was being skipped by a config setting. My change was:

Change:
https://gitlab.riscosopen.org/RiscOS/So ... /NVRAM#L39

Code: Select all

HAL_NVMemoryType
        LDR     R0, =NVMemoryFlag_IIC :OR: NVMemoryFlag_ProtectAtEnd
        MOV     pc, lr

To:

Code: Select all

HAL_NVMemoryType
        LDR     R0, =NVMemoryFlag_MaybeIIC :OR: NVMemoryFlag_ProtectAtEnd
        MOV     pc, lr

Those are defined here:
https://gitlab.riscosopen.org/RiscOS/So ... tries#L201

Code: Select all

; NVMemory

NVMemoryFlag_None               * 0
NVMemoryFlag_MaybeIIC           * 1
NVMemoryFlag_IIC                * 2
NVMemoryFlag_HAL                * 3

Which is just changing a '2' to a '1' in the lower bits of R0.

Found it at 0x1830 in Ghidra, it loads the value from address 0x1864, so changed that byte from 0x02 to 0x01 and saved it.

I think that's whats attached here, I did it a while ago, tested it in Emulator but haven't done anything since. It did seem to clear out the NVRAM in the emulator so would probably clear out the EEPROM if it worked, I've no idea

Presented as is - use at your own risk!!!

riscos5-hack0.bin.zip: (2.02 MiB) Downloaded 17 times

thecellartroll · Post by **thecellartroll** » Fri Jun 23, 2023 3:33 pm

So the obtaining of an A7000 board has paid small dividends.

The A7000 board behaves in exactly the same way as the IBX board with VGA turning off in anything other than TV mode if it doesn't have a +12v supply.

As @IanJeffray says, the RPC requires 12v for its VCO. And the A7000 board is the same. That circuit is entirely missing on the IBX board.

The A7000 circuit looks to be pretty much the same as the RPC one, and only appears to have two tracks to the SoC just like the RPC schematic. So I think it should be possible to re-create this circuit and connect it to the SoC.

I think it would be sensible to design a little board that combines this with the also missing CMOS RAM circuit.

I can't design PCBs. Yet.

This also means that the IBX board will need a proper PSU with +5v and +12v.

thecellartroll · Post by **thecellartroll** » Fri Jun 23, 2023 3:33 pm

IanJeffray · Post by **IanJeffray** » Fri Jun 23, 2023 3:44 pm

thecellartroll wrote: ↑Fri Jun 23, 2023 3:33 pm That circuit is entirely missing on the IBX board.

But must be replaced by something equivalent or you'd not get any VIDC function at all...

thecellartroll · Post by **thecellartroll** » Fri Jun 23, 2023 3:48 pm

IanJeffray wrote: ↑Fri Jun 23, 2023 3:44 pm
thecellartroll wrote: ↑Fri Jun 23, 2023 3:33 pm That circuit is entirely missing on the IBX board.
But must be replaced by something equivalent or you'd not get any VIDC function at all...

The A7000 board produced screen display in what appeared to be Mode 2 several times when it wasn't booting at all. And that was before I connected a 12v supply so it seems that the SoC is capable of TV mode output when the VCO isn't working on the A7000 too.

IanJeffray · Post by **IanJeffray** » Fri Jun 23, 2023 4:10 pm

thecellartroll wrote: ↑Fri Jun 23, 2023 3:48 pm it seems that the SoC is capable of TV mode output when the VCO isn't working on the A7000 too.

"it seems". Hmmh. Let's look at the 7500FE documentation...

The ARM7500FE is capable of generating a display at any pixel rate up to 120MHz.
The pixel clock may be selected from one of 3 sources

...

The video sub-system has two separate external clock inputs and includes a phase
locked loop to enable the control of an external VCO.
The pixel clock source can be selected to be VCLKI (using an external VCO), HCLK,
which is driven directly in from the HCLK pin, or IOCK32 (also referred to as RCLK),
which is the internal I/O subsystem clock and is generated directly from the main
I_OCLK

It's just VIDC20.

So I guess NCOS may get away without using VCO as only a 'TV resolution' MODEs was required. RISC OS may always use the VCO - HCLK is only routed to the genlock connector on RiscPC.

stardot.org.uk

Another Bush internet.tv mod thread

Re: Another Bush internet.tv mod thread

Re: Another Bush internet.tv mod thread

Re: Another Bush internet.tv mod thread

Re: Another Bush internet.tv mod thread

Re: Another Bush internet.tv mod thread

Re: Another Bush internet.tv mod thread

Re: Another Bush internet.tv mod thread

Re: Another Bush internet.tv mod thread

Re: Another Bush internet.tv mod thread

Re: Another Bush internet.tv mod thread

Re: Another Bush internet.tv mod thread

Re: Another Bush internet.tv mod thread

Re: Another Bush internet.tv mod thread

Re: Another Bush internet.tv mod thread

Re: Another Bush internet.tv mod thread

Re: Another Bush internet.tv mod thread

Re: Another Bush internet.tv mod thread

Re: Another Bush internet.tv mod thread

Re: Another Bush internet.tv mod thread

Re: Another Bush internet.tv mod thread

Re: Another Bush internet.tv mod thread

Re: Another Bush internet.tv mod thread

Re: Another Bush internet.tv mod thread

Re: Another Bush internet.tv mod thread

Re: Another Bush internet.tv mod thread

Re: Another Bush internet.tv mod thread

Re: Another Bush internet.tv mod thread

Re: Another Bush internet.tv mod thread

Re: Another Bush internet.tv mod thread

Re: Another Bush internet.tv mod thread