Rick's b.log - entry 2020/12/27

Christmas

Somehow that turned into a clean up of part of the living room, putting mom's stuff in the spare room, and numerous other cups of tea.

I did some work on Rarthur (see below). I promised myself I wouldn't on Christmas Day, but changed my mind when I saw the TV schedules. "Carry On Matron"? Seriously?

I then watched a few more episodes of Buffy season 7 on Prime and a forgettable movie (something about the children of superheroes?) on Netflix. It didn't involve any brain power, and was a good antidote to Buffy which is getting pretty dark for its big finale.

Record player

While I was coding, I listened to Simon and Garfunkel on my new record player.

Old fashioned music to code to!

Having taken a deeper look at the record player, the primary thing that stands out is that it uses a ceramic piezo cartridge.
You see, we all know that a record player works by having a tiny needle drag through the grooves of a record. The walls of the grooves are etched in a manner not unlike a waveform of the sound. Therefore as the needle passes through the groove, it is wobbled. Actually, it is wobbled in two dimensions (45 degrees up and left, and 45 degrees up and right) which is how stereo is created.
Now, the thing is to find a way to convert that physical motion into an electrical signal. To do this, there are two primary methods. The most accurate is to have the needle move a tiny magnet held within a wire coil. This induces a current in a manner similar to how microphones work. However because the movements are tiny, the voltages created are tiny so these sorts of devices need pre-amplification and equalisation.
The second method is to have the motion of the needle directly translated into an electrical current due to the piezoelectric effect of flexing a specially prepared piece of ceramic (hence the name ceramic cartridge). The needle is attached to a cantilever (which should be metal, cheap plastic ones are dreadful), which in turn is connected to a piece of hard rubber that acts as a joint between the ceramic transducer and the needle's metal arm. As the needle moves, it directly presses on the transducer which creates a voltage representing the sound.

The stylus and cartridge.

The primary difference, and thus the popularity of ceramic cartridges in cheap record players is that the output voltage is a lot higher, so it can theoretically be directly connected to a line in input to an amplifier (no pre-amp needed), but the mechanical properties of the arrangement tends to emphasise the bass and de-emphasise the treble. In other words, it is also possible to skip the equalisation because things will generally sound "acceptable" when played with a ceramic cartridge.
I say "acceptable" as it isn't an inverse RIAA curve because the RIAA is more complicated than that, but if you just want to listen to a record and you aren't an audiophile then it will suffice.
The cartridge is a P-188 which is a clone of the Chuo Denshi CZ800, which was actually designed in the '80s but has made a comeback in these low cost record players (to the point where a lot of people just call it a Crosley cartridge).

Unfortunately, my record player appears to operate by wiring the ceramic cartridge directly to a line level input. While this will work, it will result in poor audio (mostly missing bass) because line inputs are fairly low impedence, while ceramic cartridges expect a fairly high impedence. I will try, some time, wiring a large resistor (something in the order of 500kohm?) in line with the cartridge to see if that makes any difference? I am not sure if I should wire it to the positive signal outputs (would need two that are near identical resistance) or in line with the common negative signal output (will only need one resistor). When I get around to it, I'll try in line with the common negative to see how that behaves. Trying to better match the cartridge to the input should help to improve the bass response too (for complicated electrical reasons that I'd be lying if I said I understood).

Another problem is that the cartridge can generate output that overloads the amplifiers input and ends up clipped and distorted. I know the end of The Boxer goes nuts, but you don't really expect Beverley Craven's Promise Me to distort. This distortion is omnipresent, in headphones, in recordings... With a little luck, bunging a resistor in-line (as mentioned just above) will attenuate the signal so it doesn't max out like that. I'd rather have a quieter signal that one needs to turn the volume up, than a maxed out signal that sounds bad at any volume.

That said, the internal speakers aren't anything to talk about. Playing symphonic metal through Bluetooth is comically bad. There isn't much that can be done about this, short of replacing the internal speakers with bigger ones, but that has the dual issue of physical size limitations and the problem of speakers that are too powerful causing vibrations within what is basically an empty wooden box. Think of the purpose of a big empty box in most string instruments.
I'm not too worried about the internal speakers. If you look at the photo above, you might just see that I have it plugged into my desktop speakers which aren't great, but they're better.

The main problems are the overloading and the barely-present bass. I put this down to a mismatch between the cartridge and the amplifier.

The main board is pretty much fixed and solid state. There are no potentiometers to tweak anything, no tone control, nothing. I guess this is to be expected in a budget record player. It's a shame, though, that there is no way to tweak the input. That a device has been created in which the primary input (the record playing part) can overload the amplifier is...bizarre.
There is an empty part on the main board for a socket for connecting a battery pack. I don't know how this actually works (as in, what happens if battery and USB are connected at the same time?) or if it works automatically or if it needs support in the firmware. Something to look at another time.
Having said that, a simpler mod could be to intercept the USB's 5V and put one of those USB battery packs inline with it, so you can run it from the battery normally, or plug it in to charge.

Record player main board.

An interesting thing is that the four keys of the control keypad are connected to the main board by two wires. I'm guessing this is hooked up to an ADC, and each key is wired through a different resistor, so the controller can tell which key was pressed by measuring what voltage is being passed back to it. It's a way of reducing the number of wires necessary (and inputs to dedicate to them) to a simple two wires and one input.

The deck board passes the signal from the stylus directly to the main board for amplification. The rest of the wiring is concerned with the motor speeds. It looks as if it isn't actually a stepper motor, but a specially built motor that can run at 33¹/₃, 45, or 78rpm depending on which wire is passing current. There is a potentiometer here for tweaking the deck speed. I'd check mine if I had a clue how. It "sounds" correct, but then music can be a percent or two out and still sound mostly correct (as evidenced by British television where 24fps movies have been sped up to the 25fps television frame rate since forever).

Record player deck board.

The next thing to look at is adding an ajustable bolt to the far end of the stylus arm. This is because there is no balancing at all provided, so the entire weight of the arm is pressing down on the stylus. From YouTube videos, this appears to be around five and a half grams.
This is the primary reason why audiophiles dump vitriol on these sorts of record players. They'd wet themselves at the idea of letting anything over 2g near their record collection.
The interesting thing is that the "official" specification of vinyl discs is to be able to cope with tracking weights in the order of 10g, purely because technology in the heyday of records wasn't as advanced as it is now. Certainly, a late '70s or early '80s record changer turntable used to have fairly large tracking weights as the entire setup was mechanical. And, anyway, a tracking weight of 2g back then would likely have scratched records to hell and back as they'd simply not have stayed in the grooves.
Depending upon where you look, the clone P-188 cartridge works with a tracking weight of either 2-4g or 4-6g. If the latter, then this record player is actually in range. However I'd like to lighten it a little to something in the order of 4g.

The tracking weight isn't what damages records. What does that is a misaligned stylus. If it isn't directly straight down on the groove, it'll scrape one side more than the other. This is very likely what is happening with these cheap record players given that there is no adjustment possible in that respect, plus the entire arrangement is snap together which might introduce some play.
Likewise, the entire cartridge needs to be aligned to follow the grooves so the stylus travels in what is essentially a straight line. If the entire cartridge is rotated off axis, then the results will be less severe than a tilted needle, but it'll still be following one of the sides of the groove more than running down the centre.

The stylus playing a record.

I purchased a pack of four diamond styli from Amazon. A simple snap-fit replacement for the original. They looked identical, so either mine came with a diamond stylus rather than sapphire (cheaper, weaker) or these Chinese knock-offs are all the same thing. I can't say it sounded any different, but I've not tried a side-by-side comparison. I won't bother with that until I've sorted out the generally poor audio. Until then, there's no point.

On the other hand, my original stylus was slightly off centre, so the replacement is good, straight at least. Which isn't too much to ask, is it? ☺

The final thing is that my records need a good clean. Two decades of being stored in a damp environment mean they look like they need a wash. Not sure exactly how the heck to do that. Would a mixture of washing up liquid and water (no rubbing!) work?

Rarthur

Anyway, we got to talking about this, the UI on DOS thing. That's when DavidS volunteered a guy he knows called Mike who apparently estimated that making a clone of the RISC OS UI to run on FreeDOS would take about 3,000 hours at a cost of $125 per hour. DavidS deleted his original post before I had a chance to read it, but luckily somebody quoted it.
When pressed, DavidS replied to me on Chatcube (which I rarely use) to say that Mike's contact infomation was A to Z Software, Wilmington, KS. Amusngly, Wilmington is a... what was the phrase, "unincorporated community"? Something like that. It's basically a church, a graveyard, and a couple of farms. It looks like the sort of place that doesn't even have reliable electricity, never mind the sort of connectivity a professional programmer would need (as $125 per hour, he'd better be damn hot).

I pushed a bit more on the forum, and DavidS replied more on Chatcube (a sort of RISC OS specific messenger system like Telegraph) to say that as Mike is not familiar with RISC OS part of the time quoted is researching the system. So, wait, a guy gives a quote for the implementation of something he has no idea what it is? Yeah. So a bit more pressing and DavidS replied more on Chatcube to point out that it's easy to find Mike, phone book area 316 which is the same as his store front in Wichita. DavidS says he doesn't like to give out contact details without permission (what, a published phone number?) and finally said, and I quote: He said if you do want to get hold of him, the listed 316 area telephone number is accurate. Tell them to look it up in the book and give me a call if they want".
Searching the entirety of Kansas for all businesses with "Software" in the title, and "A to Z" in the title produced a few matches, but nothing that was a match for this Mike. And all of the ridiculous obfuscation (how the hell is a person in France supposed to look up a number in a printed phone book?) is likely - in my estimation - to be due to this Mike being a complete fabrication.

Still, what got me about this was the quote. Three thousand hours at $125 per hour. If we assume five to six weeks of holiday per year (as is common in France - five weeks statutory plus various public holidays for various (mostly religious) reasons), then 3,000 hours comes just short of two years working full time (seven hour days, Mon-Fri for 35 hour weeks).
And as for the overall cost? A little over a third of a million dollars.

All to make a clone of the RISC OS UI to run under FreeDOS. Remember, it will be a clone. It doesn't need to work correctly because it won't be capable of actually running RISC OS software (what with being compiled to run on the ARM not the x86). It just needs to look-alike.

I call bullshit on this entire thing.

With that in mind, please allow me to introduce something I've been on and off working on over the winter holiday. It's called Rarthur, meaning "Rick's Arthur".
As this an entirely pointless exercise, I've decided to have a crack at cloning Arthur rather than RISC OS.

Here's the DOS version:

Rarthur DOS version.

At this point, the Calculator and Clock work. The Calculator can accept the icons being clicked, or keyboard input. The "task manager" polls each applet in turn, so the clock updates every second.
Windows can be created, moved, resized, and closed. You can see that I'm in the process of resizing the Diary.
Note-Pad and Diary both open empty windows. That's all they do at this time. I only added keyboard support this morning.
The Filer doesn't do anything yet.

Adjust-click Exit to get some debugging into on the task list and window stack. Or Select-click it to quit.

The resizing doesn't (yet) take into account window max or min sizes. It's a bit simplistic, and the scroll bars are currently fixed. I'll get around to it.

The bar at the top of the screen shows the mouse X,Y and which keys are pressed (S, M, or A). If the mouse is over a window, it'll report which window. And if over an icon, it'll report that (whether window furniture or actual icon).
The icon code currently only creates invisible icons (as used by Calculator to overlay the bitmap) as I've not had a need to draw actual icons.

Now here's the shocker:

Rarthur RISC OS version.

Rarthur, while aimed at being an arbitrary Arthur clone for DOS, is actually written on RISC OS. Thanks to the beauty of C (and a bit of dick waving at the person who started this mess, given his obvious dislike of C and preference for assembler) I only needed to write a system specific file for RISC OS, another for DOS, and a clone of bits of the Borland BGI driver for RISC OS. Once that was done, the same core code can be easily built for either platform. As I'm using FastDOSbox, I have a little Obey file to sync the RISC OS files into the DOS-like directory structure. So I sync, fire up DOSbox, and then rebuild. The DOSbox configuration starts everything up automatically, I just need to open a menu and pick an option.

So mostly I look at this:

Rarthur source on RISC OS.

But sometimes I see this:

Building Rarthur on TurboC++.

The entire thing has been designed from scratch, drawing the windows and such from the ground up.

I would estimate that, thus far, I have spent maybe thirty hours on it to get to this state, basically just sitting down and hacking out some code.
It's 208K of code, creating a ~51K program for RISC OS and a ~100K executable for DOS (the object files add up to ~60K, the rest will be the various libraries used).

The four things that took the most time:

• Dealing with differences between RISC OS and BGI. One of the main issues is that RISC OS considers 0,0 to be the bottom left of the screen, while in BGI it's the top left. As Rarthur itself works to the RISC OS way of having the origin be the bottom left (window position x,y means the bottom left corner), all of the Y co-ords need flipped on DOS. So rather than using the drawing primatives directly, they all go through a layer of indirection that messes around with the Y co-ord as necessary.
  Actually, it's a little more complex than that due to graphics clipping.
• Having to relearn the BGI system. It's been maybe thirty years since I last did any graphics stuff using BGI.
  There was plenty of weirdness to deal with. It's perfectly possible to change the window background colour. However, it appears to do this not by actually changing the colour but by simply altering what "black" is which has consequences for any drawing code trying to use black, which now isn't. So I have to instead draw a screen sized rectangle, which is braindead.
• Having to come up with various sorts of optimisations for things that were slow. For example, the Calculator bitmap is a simple bitmap with a byte representing a pixel. It isn't packed or anything, it's designed to be quick to plot, but it's still slow. So the first time the Calculator is drawn the slow way. Then the window manager takes a copy of the window background as a native bitmap and just plots that in the future. It's all done automatically.
  The same thing happens for Clock because BGI uses the horribly slow method of using a pie chart routine to deal with filled circles. But this one is a bit hackier because it isn't drawn from a bitmap. It is drawn directly and the app messes with the window structure directly to create the bitmap.
• And, of course, working out all sorts of little challenges like if you redraw a window that is overlapped by others, redrawing the others. This is because the system does not use redraw rectangles, it simply redraws the entire window, so anything overlapping will itself need redrawn.
  It's not a perfect method, as a current limitation is that all windows overlapping the target window will be redrawn, but any window overlapping one of the other windows but not the target would not be redrawn. I'll fix this some time in the future. It's not a priority.

It started out as a way to prove a point (3000 hours and a third of a million dollars?) but it in itself has become an interesting project in how to make a simple GUI. More specifically, a simple GUI that actually works. I downloaded and tested something called TurboGUI (by Siva Chandran.P) but I didn't even bother looking at the code when I realised that not only did it suffer from redraw failures, but it was pathologically unable to cope with window stacking. If you should download and try this (note - you'll need the EGAVGA.BGI driver) open up the "Simple window" with the text input box, and then open up the "About" window and place it over the top of the Simple window. Then click where the writeable icon would be in the underlying window and start typing.

How not to do a GUI.

Rarthur does't do a lot - Clock and Calculator work, and that's about it. But if you want to give it a whirl, here's an archive. The EXE is for DOS. You don't need EGAVGA.BGI because it's built in (unlike Siva, I read the documentation ☺), and the other one is a RISC OS executable. Works on my Pi2. It'll need a 640x480 (256 colour) mode. If your machine can't do that (ARMbook?) then sorry, you're SOL.

Update! (2020/12/28, 2pm) A few small fixes to fix vertical glitching of the window position when attempting to resize it below minimum or over the iconbar; as well as now respecting min/max sizes. You'll also note that Diary no longer has scroll bars. That's because it has been set as "not resizable" so the window creation automatically removes the scroll bars.

The moral of this story, boys and girls, is don't try to bullshit a nerd in the middle of winter when he's on furlough. That translates to a lot of free time. Some of which can be devoted to pointless activities...

Your comments:

Please note that while I check this page every so often, I am not able to control what users write; therefore I disclaim all liability for unpleasant and/or infringing and/or defamatory material. Undesired content will be removed as soon as it is noticed. By leaving a comment, you agree not to post material that is illegal or in bad taste, and you should be aware that the time and your IP address are both recorded, should it be necessary to find out who you are. Oh, and don't bother trying to inline HTML. I'm not that stupid! ☺ ADDING COMMENTS DOES NOT WORK IF READING TRANSLATED VERSIONS.
 
You can now follow comment additions with the comment RSS feed. This is distinct from the b.log RSS feed, so you can subscribe to one or both as you wish.

Rick, 28th December 2020, 01:15

Oh, and about that ridiculous $125 an hour rate.    " As of Dec 15, 2020, the average annual pay for a C Programmer in the United States is $61,166 a year. Just in case you need a simple salary calculator, that works out to be approximately $29.41 an hour. "    This information supposedly from https://www.ziprecruiter.com/Salaries/C-Programmer-Salary but it keeps redirecting to a "local version" for me.

David Boddie, 28th December 2020, 17:44

"Rick's Arthur" -> Richard IV / CISC OS / Rick's OS

David Pilling, 29th December 2020, 02:04

On the record deck - a ceramic cartridge preamp inserted between cartridge and the electronics it connects to. I guessed there would be such a thing on ebay but I found this circuit which uses a cheap ten a penny MOSFET:    https://www.petervis.com/record_players_and_turntables/ce ramic-cartridge-preamp-circuit/preamp-circuit.html    As to measuring the rotation speed - put a mark on the side of the platter and monitor it with some sort of photocell/transistor/diode - it is an easy Arduino project, perhaps slightly harder with a Pi. Another option would be an opto-interrupter with something stuck to the platter to go through the slot.    The programmer in the USA sounds to be making reasonable demands. Yes he is above average wages but he is working for himself, and taking some risk. It would not be sane to employ such a person (someone who has no clue about RISC OS and how it works). As you have proved get someone who knows what they're doing, they can do the work a lot more efficiently.    You keep going on about this - Wine style emulation is the future then (?) (Wine Is Not an Emulator)

David Pilling, 29th December 2020, 19:23

In t'old days you'd get a paper disc to put on the platter, printed with lines, to get the rate of change of light up, and then use a strobe-o-scope (flashing light) to measure the rotation speed.    These days you can get things on ebay for measuring rotational frequency, they shine a laser on the object and measure the frequency of what is reflected. I've used one on computer fans to check the speed. Print your own disc and use the cheap ebay thing.    Mr. Vis of the preamp, pooh poohs the idea of a big resistor.    UK government regularly spends billions on computer software, you can bet the people employed will not be hobbyists and will be well rewarded. I have encountered such real world programmers, skilled and organised people. Those government projects regularly end in complete failure.    That's how it is, lots of money does not mean success. Of course for those who get the money it is success of a kind.    An interesting thing for vinyl is the static electricity gun, squeeze the trigger fire charged particles on your disc and the dust drops off.

David Pilling, 30th December 2020, 18:43

I observe that I had to recreate the Draw module for Ovation Pro on Windows. Happy to share that code.

Rob, 4th January 2021, 23:14

On record player speeds .... there are android apps you can download (search RPM Speed and wow for one) that you just place your phone on the middle of the deck and it tells you how fast it's moving...    Nice on Rarthur... I've had people say "this can't be done" and being able to give them a working app a few days later is priceless :)

Add a comment (v0.11) [help?] . . . try the comment feed!
		Your name
		Your email	(optional)
		Validation	Are you real? Please type 72827 backwards.
		Your comment