Kiosk style interface
Steve Pampling (1551) 7942 posts |
Model B, and it was less than 299. |
Martin Avison (27) 1422 posts |
Dunno about GEC making some parts – but there was a general GEC employee offer. I got an A from the offer at £299 in September 1982, and got a B upgrade in November for £70. Was still working a few years ago.
Not for this employee! |
Steve Pampling (1551) 7942 posts |
Model B, and it was less than 299. Never queried the deal, besides the chance of getting a simple straight answer was minimal. Ernie was in sales and could have sold sand to Saudi and probably did. |
Chris Evans (457) 1614 posts |
The Beeb was announced in 1981 but the first deliveries weren’t until 1982. I ordered my B IIRC 21.9.1981 (they weren’t taking orders before then) I got mine Easter Saturday 1982. There was at least a six month wait initially. I think it was 1983 before the queues disappeared. |
Steve Drain (222) 1620 posts |
The decoding for 16 sideways Roms was built into the circuit board, although many add-onboards did their own. I modified my suite of 16 Bs with 64k Eproms (4 × 16k) in the Rom sockets. This required a link change on the board and a patch to the sockets from where the decoding was on the board. I actually had 32k sideways static Ram in one of the Rom sockets, for flexibility. Happy days. ;-) |
ronald-scheckelhoff (2262) 60 posts |
@All: Thanks for the interesting stories about the early OS and the machines. My EtherUSB seems to be taking its time at the post office, so I worked around the “no network” scenario with an MSDOS formatted USB disk. Using another machine (FreeBSD11/AMD64) I downloaded zeropain_noexpire, HardDisc4/zip, and the newer ROM onto that disk, and plugged it into the Raspberry Pi2. Then: I opened new task window, and practiced: *MOUNT *DIR Fat32Fs::Fat32_0.$ *EX I could see the HardDisc4/zip and other files in the extract directory (yippee!) – so, I double-clicked on HardDisc4/zip, located the directory that was then extracted, changed the filer opts on the destination to “force” overwrite, group selected all the new files, and dragged them over the existing ones. I dropped them in and watched the progess bar count files. (so proud of myself). (BTW: Amazon Books is your friend): Currently using “Raspberry Pi RISC OS SYSTEM Programming Revealed,” by Bruce Smith. |
ronald-scheckelhoff (2262) 60 posts |
After practicing my RISC OS commands, I realized that it automounts, and I had only to click the icon for it at the bottom of the screen LOL. |
Colin (478) 2433 posts |
I don’t think an external adapter will help you unless your pi2 is broken. The settings to get the built in Ethernet working are exactly the same as the settings you need for an external adapter so if you can’t get the internal one working you won’t get the external usb adapter working. |
Colin (478) 2433 posts |
The EtherUSB interface is the onboard NIC. I thought the Pi SD card images came with the network already configured. |
ronald-scheckelhoff (2262) 60 posts |
The EtherUSB interface is the onboard NIC. I thought the Pi SD card images came with the network already configured. Ah – that should point me back to Amazon for a book on Pi board specifics. Luckily, I just picked up the “Raspberry Pi Hardware Reference” by Warren Gay, but obviously I’ve not read far enough into it at this point :-) The domain name resolver is listed as “Acorn” – and I don’t know if that’s the standard resolver or not. Obviously, my Raspberry hardware experience is approximately equal to my RISC OS experience :-( But, that’s what makes it interesting. |
Colin (478) 2433 posts |
In a turn around from the usual advice I’m going to suggest that you are reading too many manuals :-) Assuming your Pi is plugged into a broadband modem: 1) Double click on !boot in the root directory – The configuration window pops up And it should work Edit: Added missing clearing the gateway address at step 12 – as suggested by Chris Evans. |
ronald-scheckelhoff (2262) 60 posts |
In a turn around from the usual advice I’m going to suggest that you are reading too many manuals :-) That cross-eyed (partially blind) guy staring back at me in the mirror is proof! Anyway Colin – thanks for the step-by-step. That probably IS what a newbie like me is looking for… But, the setup I used followed your itemized list pretty closely. I tried it that way, and then without DHCP and all manual settings. The real culprit turns out to be a little embarrassing. I’m using Netsurf on RiscOS to type this. Finally, after hours of chasing my tail, I noticed there was no “cable connected” LED lit on the Raspberry. I changed the cable, and here we are using RiscOS on the net. Nice! One may wonder why I never looked at the LED? Well, I was using the same cable on my PC, just switching it back and forth between the PC and the Raspberry. It works fine on the PC! So, the Raspberry RJ45 is just a tad bit more loose, or wide, so that the wire lands on the end of the old cable I was using did not make contact within the connector. The PC RJ45 must have had an ever so slightly tighter arrangement, and works. So, this is a new one for me. Sorry for all the fuss. |
ronald-scheckelhoff (2262) 60 posts |
To test the original February, 2015 SD image, I reimaged the uSD I was using, and restarted the machine using the fresh image. It works fine now, with the new cable. So, as everyone else was saying, there’s nothing wrong with the February image, at least as far as network connectivity goes. It was a good exercise for me, forcing me to update the ROM, userland, a module, and being cause for me to play with RISCOS ideas about mounting things such as an MSDOS USB disk, as well as being an excuse to try a few other miscellaneous commands. If I had known the command equivalent for “ifconfig” (it probably IS ifconfig?) or a few other network related commands, I might have noticed this little faux-pas earlier. I really need to become familiar with the directory structure, so as to find these things. Pretty much at ground zero. Many thanks to those who chimed in. Speaking of commands, what is the best reference for that? The manual, I suppose is the automatic response, but I like paper. Anyone care to share their favorite RISCOS book list? I should search the forum for that, I’m sure there’s a thread somewhere… -Ron |
Chris Evans (457) 1614 posts |
To add to Colin’s set up list. |
Rick Murray (539) 13409 posts |
It may have been a cross-over / non-cross-over cable. If I have it correct, you need a straight wired (non-cross-over) cable to connect a computer to a hub, router, or modem. If you are connecting a computer back to back to another computer, you need a cross-over cable. Except these days you can usually get away with either as the cables have no obvious markings to specify which is which and the network interface chip can usually figure out what sort of cable is connected (I think they call this “auto polarity” or somesuch?). |
David Feugey (2125) 2687 posts |
http://www.riscos.fr/decouvrez.html |
ronald-scheckelhoff (2262) 60 posts |
It may have been a cross-over / non-cross-over cable. If I have it correct, you need a straight wired (non-cross-over) cable to connect ... @Rick: It’s morning here and I still can’t believe the CABLE caused all this fuss, making me seem silly in the process. Maybe I AM silly. I checked the cable by inspecting the wired sides of the ends, holding them next to each other (how I always do it) – and the colors have the same L-to-R pattern. So, ,it’s not a crossover. Thanks for mentioning that though, as it’s a good snafu to mess with me the next time! Metre and a half thick ... Sounds like a castle to me. Reasonable then to run a Castle OS (sorry). |
ronald-scheckelhoff (2262) 60 posts |
It’s in French, but see at the end of the page. Lots of books are available. Thanks to RISCOS.com. @David: Thank you for the excellent list. I’ll run it through Amazon, and see if I can fatten the bookshelf. Given I’m taking this on, about thirty five years late, some may be out of print, I suppose… |
Steve Pampling (1551) 7942 posts |
Apart from an electrical tester there is no other way. Basically automated or visual. If you were dealing with a failing Gb interface and a working 100Mb I’d suspect connection on one of the 8 pins being dodgy. |
ronald-scheckelhoff (2262) 60 posts |
|raik| DDE / GCC: With the code I play around, DDE compiles faster. The code has nearly the same size. Speed I can not say. I’ve been looking at the GCC port for RISCOS, and based on forum posts, it seems one could only compile programs that use fairly simple /configure scripts with native GCC. I also noticed that all of the PakMan packages (or at least most of them) contain only static libraries. I’m assuming at this point that I’m using the DDE for any serious project, in terms of a native compile. Does anyone use native GCC for non-nix code on RISCOS? Just as a test, I thought I’d recompile cURL to use PolarSSL, which is the first thing I do on most systems. The /configure is fairly complicated for cURL, and my readings on this forum indicate that native GCC isn’t the way to go for complex config scripts. Relative to the DDE, working with *nix world code bases like cURL, how well does that work? No *nix world makestuff, so not at all? I know that, performance wise, it’ll be 10x faster to cross compile. The purpose of the recompile for cURL is for Netsurf, of course. Is cross compilation the only realistic means for the latter? Thanks in advance for reading another noo-b question. |
Rick Murray (539) 13409 posts |
[disclosure: I have and use the DDE]
Well, there’s your first problem. ;-)
If you are playing with GCC, a more solid answer would be to just try it. I don’t think the RISC OS versions of anything offer the same degree of flexibility as a Unix box, but I don’t think GCC is entirely backward either.
I think the dynamic library thing is fairly new. Remember, RISC OS has exactly zero concept of dynamic libraries. The closest we get is SharedCLibrary which has a number of issues, such as the fact that you cannot replace a softloaded CLib with another softloaded CLib otherwise everything will blow up. And it works with direct jumps into known bits of code (handled by Stubs) rather than linking to function by name.
I don’t know. I think both are competent enough tools for building projects, they’re just slightly different in how they work. Unfortunately, GCC is soon? now? dropping/dropped support for native RISC OS executables in preference to ELF executables. There’s a program that can convert ELF to AIF, but it’s an extra step to need to know about (and note that ELF will not work on a machine without the GCC libraries and stuff installed).
Well, one could point out that NetSurf was originally a RISC OS browser, so it was actually ported the other way. ;-) https://en.wikipedia.org/wiki/NetSurf
Without doubt, but depending on how your setup is arranged, those faster compile times may diminish due to taking the compiled code to the machine it is supposed to run upon. I believe, generally speaking, that “complicated” build systems may need to be simplified to work with either RISC OS compiler2. If you don’t have the DDE, then try GCC first. It’s free, so give it a whirl. 1 …in 1989 perhaps… ;-) 2 That said, the RISC OS build system is somewhere between epic and insane. I’ve not read the log, but I’ve seen BASIC whizzing by, some perl, and I think it exercises all of the dusty obscure parts of the assembler. |
Dave Higton (1515) 3407 posts |
Yes. You’ll need a 64 bit x86 Linux installation (I use Ubuntu). The task of creating a build system for NetSurf with anything else would be absolutely enormous. You have to consider building not only NetSurf, not only the libraries that Netsurf uses, but a suite of build tools too. And when you’d gone through all this pain, all that would happen is that every build would take many times as long. There is no gain, only pain.
I share a RAM drive on the RISC OS machine via NFS by means of Moonfish, and mount it on the Linux box. An invocation of a shell script does both the build/package process (last stage of the NetSurf build) and the copy over NFS to the RO machine. The transfer must be, oh, 2 seconds. |
Malcolm Hussain-Gambles (1596) 811 posts |
This is just my viewpoint…here we go… ;-) From what I’ve seen the GCC compiled code runs pretty badly on RISC OS and is fairly painful to use. So I’d say if you want to get something up and running quickly that’s fairly complex, using GCC could reduce your pain by many orders of magnitude depending on the libraries you want to use. |
Chris Mahoney (1684) 2106 posts |
Another issue, which isn’t inherent to GCC but rather the nature of ported software, is that many of the tools that are available haven’t been ported “well”. For example, I was recently trying to add a file called “res” to my SVN repository. It’s a Toolbox resource file. “svn add res” didn’t work; I had to use “svn add res,fae” to manually indicate the file type. Typically, a native app won’t have issues like that since they’ve been built specifically for RISC OS. It can be easy to port an app with GCC but the manual tweaks are often left undone. It’s a shame, but as noted it’s not an inherent problem with GCC. |
Steve Fryatt (216) 2049 posts |
Really? Yes, you “need” elf2aif to get a native AIF executable. I must have missed the “extra step” required to make it happen, however: it’s a transparent part of calling GCC on the version I’m using.
I’d be intrigued to know what’s bad (in the context of the above) about Locate 2, CashBook and PrintPDF, to name but three. All are native apps, using the SCL, with no ported code and compiled using the GCCSDK Cross Compiler.
I’d suggest that you might want to read up on what GCC actually is: you can generate completely “native” apps with either GCC or the DDE, in exactly the same way. All the stuff I compile with GCC (NetSurf excepted) use the SCL and don’t touch Unixlib or any ported code. The GCCSDK and the Cross Compiler also make it easy to port code from Linux, but they’re in addition to GCC itself. |