close
Skip to main content
rn3aoh u/rn3aoh avatar

Eugene Medvedev

u/rn3aoh

Feed options
Hot
New
Top
View
Card
Compact

One useful thing I can tell you for certain is that the layout does not match any of the widely used pre-1950s Russian layouts (there were several competing ones differing in the position of a few letters) nor the post-1950 standardized layout.

The 5th letter from the left on the bottom row is a yus, which was dropped from most widely-used Slavic languages by the time first typebar typewriters were invented -- except Bulgarian and Macedonian. From which it was dropped by 1945.

The layout is otherwise very close to the post-1945 Bulgarian Cyrillic layout.

Which means that this is most likely a pre-1945 machine made for the Bulgarian market, by the looks of it a Continental A or maybe Continental A Standard. With the way internet search is broken these days, digging up anything more specific proved difficult.


This looks very similar to Olympia Traveler, but upon research turns out it is its own thing, even though the relation is there. They are apparently rare enough that the Typewriter Database only has one listed.

Olympia is generally considered a very reputable brand among European typewriters, so it's a matter of whether you believe the price is right more than anything.


Printing the keys themselves is trivial. Getting a letter on the keys is a bit more complicated, but also not too difficult. The real problem is making the type slugs -- the ones soldered onto the end of the typebars in most typebar machines.

There are people who succeeded in printing Selectric typeballs but I couldn't tell you how long do these last. Their OpenSCAD code might come in useful when designing regular type slugs. The problem with resin-printed (FDM printers are just not detailed enough) slugs is that there would be no reliable way to attach them to the typebars for all machines where the slugs are meant to be soldered: a resin print will not survive this. Superglue might work for a while, but does not sound like a good idea.

There are companies that will 3d-print a model in metal for you, however, and you can use a 3d-printed slug to produce a mold for casting, so it's not hopeless to do, just quite involved.


Missing one screenshot or another is probably because another console on the card has an identically named game, so it can't tell where the screenshot should go. Rename the rom file by adding (something) to the end only on one of the consoles, and the ambiguity will go away.


There is currently no RetroArch core for emulating BBC B as far as I can see. There's no reason one shouldn't be possible, but getting one is not something you can do by following instructions, because nobody has done it at all, yet.

Take a look at this Github issue.


PBP files are not a requirement, they're a convenience. Let's do a proper lecture here, because tutorials are bad for your brain, they teach people to do things without understanding why are they doing them...

RetroArch will read CDs in the normal ISO, CUE/BIN (and even BIN with a lost CUE as long as the CUE was simple enough) formats, IMG (which is actually the same as BIN with a lost CUE) as well as compressed CHD and PBP. (I'm actually not sure if CSO is specific to PSP or not, but nobody seems to use it for PS1, so let's skip it.)

It is generally a good idea to use a compressed disk format, because SD cards are slow, and the less data you have to read off a card to run the game, the faster it will be, even accounting for the time spent decompressing it into memory -- especially considering that RG35XX only has 256Mb worth of RAM, so a full CD image would never fit in there.

CHD is the more generic disk compression format, which is only able to contain one disk per file, but is applicable to any CD format (including SegaCD and PC Engine).

PBP is a Playstation 1 specific variation, originally designed to play PS1 games on a jailbroken PSP. It's a Playstation-specific format, that has the distinction of being able to contain more than one disk in the same file.

M3U is a playlist file. In the simplest variation, it's a plaintext file listing other kinds of ROM file, one per line, allowing you to tell RetroArch that these files constitute a disk set, which makes it easier to swap disks when you need to, and give GarlicOS launcher (which turns every file it finds into a launcher menu entry) a single line to show while hiding all the individual disks from view in a subdirectory. (In case you're up to making an M3U and you use BIN/CUE images, you want to have the CUE files in the M3U, but not the BIN)

You don't have to use any of them. In the long enough run, you will probably find PBP more convenient for PSX, because this way at least you can't lose or forget a single disk out of a disk set.

But just dumping the files you get into Roms/PS will work for ISO , BIN/CUE and IMG, though it might not look as neat or work as fast.


I've no idea how ScummVM core handles screenshots, if it even does. It's very possible it doesn't, though. In cases like these, you can use Screenshot Daemon, and then manually rename the screenshot it makes to match what RetroArch screenshot name would be:

<rom filename without extension, in this case the name of the .scummvm file>-0-0.png

Then Nimshot will pick it up. (It ignores the date and time, so you can just put zeroes there.)


The mask I packed with it covers the left side of the image entirely, so maybe. Try flipping it horizontally?