Also, non-power-of-two dumps can be used to get a driver going; people are generally more likely to get you un-soldered flash chips when they know it's gonna contribute to emulation.
I've seen quite a lot of people consider the non-power of 2 roms to be more correct than what we have anyway, because they're what gets programmed into the chips in many cases, with the rest of the rom not even being cleared (so thus could contain random data in the actual chips.. This is especially true of flash based ones where you don't have to erase the entire rom first.
(also flash dumps containing the extra error correction data, which some systems need / use for general purpose storage also won't be power of 2, see the cv1k flash roms for example)
S.C.S. GmbH Komtek-I (German TRS-80 clone ,likely the same as the Radionic R1001)
This article says that the German S.C.S. Gmbh produced the TRS-80 clones called Komtek 1, but the manuals have "Komtek Computers Ltd." on their front page.
The computer is called "Komtek 1" throughout the manuals, the name KT 1001 appears to be some sort of backsplanation from a clone of the Komtek 1, the Radionic R1001. Since the ROMs are identical, it was probably a case of badge enineering.
So it's either a "Komtek Computers Ltd. Komtek 1" or a "Radionics R1001" - or both
So I finally got around to digging through MAME's source code and seeing if I can get the OS to boot. After some initial trial and error, I commented out the PICUs out of the address map structure and noticed a slight difference. I noticed that they were not in the memory map for MESS's emulation, so by removing the PICUs for CPU 1 and 2 (located at addresses $FCFC and $FCFD respectively), I got the video to start drawing the "LOADING SYSTEM" text to the top of the screen after boot up (if you watch the machine boot up in slow-motion, this is a good sign).
Furthermore, I decided to comment out the channel cards in the address map structure in addition to the PICUs and I actually got the final start-of-execution address ($1C31) for the OS to load in $FE01. Unfortunately, the OS did not boot up, instead, it just drew bunches of 6s on the screen in an endless loop.
Something like pre-enable? There used to be an option for that back in the .dat format but I think it vanished when MAME moved on. I haven't used the cheat system in nearly a decade as I despise having to use the debug UI to search for cheats, which is the equivalent of creating a website using edlin.
Well, after the last SDLmame release I have done other tests and I found that almost all drivers where 3D stuff is involved have a dramatic boost in speed under Mojave while under High Sierra (and previous OSes) they are sluggish. This is true, for axample not only for System22 games but also for the Ultra64 based Midway games, now all of them are a very really enjoyable experience so for me the Mojave upgrade has been a big thumbs up!
I don't know exactly where the problem is because both OSX 10.13 and 10.14 were installed on my Macs from scratch so no other apps or settings were slowing down the machines, also the build of SDLmame was done with the exactly same compile options and the SDL library was absolutely the same, and so the Xcode version. This happens also with binary builds from other people like the ones available, for example, from sdlmame.lngn.net so I know for sure is not a problem of my compilers. Also is not GPU brand related because I have experienced the same thing both with a nVidia GTX680 and a ADM HD7950.
I am quite sure that this performance degradation happened since a certain MAME version on, because I remember very well that Ridge Racer was running smoothly and at a certain point it becomes stuttering both on audio and video refresh. I also regularly checked the forum to see if other users were experiencing the same issue but no one come out to talk about this so always thought it was a driver issue to be fixed in the future.
Well, it seems in the end it has been fixed by Apple :-) Of course the Windows version of SDLmame never suffered this problem, but the very strange thing is that on OSX it made no difference for metal/opengl/soft video acceleration setting, it was like somewhere there was an handbrake on the speed of those 3D games.