With all the controversy over 64bit pinball, and where and how things appeared, then disappeared to the discovery that the x64 version was a thing, but it was left off the install manifest but shipped on CD, along with my simple script to just extract it, the problem was that ARM32/64 users were left in the cold.
Don’t get me wrong, the original 32bit exe runs fine under emulation, but who wants emulation when you can have NATIVE CODE?! You’d have to try to find the source code (lol good luck!) or reverse engineer the program. And that’s what happened, enter:
I’m using Visual Studio 2019 to build this, and it was great it *just worked*. Hurray!
There is also a rebuild going on for SDL to bring Space Cadet Pin Ball to Linux and beyond. The only downside is that it uses a number of ‘new C++ features’ locking out older platforms. I’d done some work to dumb it down although there is a bit of this new fangled C++ I’m unsure of what is going on. So that means, unfortunately Itanium users are left in the dark, as Visual Studio 2010 is too old.
(This is a guest post by Antoni Sawicki aka Tenox)
Just for fun with virtualization I wanted to try out VMWare ESXiforARM64, most specifically Raspberry PI. ESXi for ARM has been around for a couple of years now. Since PI4 packs 8GB of RAM and has a reasonably fast CPU it can be a worthwhile experience. Also more OSes for Raspberry PI are now available in UEFI boot mode.
Not going to go through exact installation steps as these are all around the web and youtube. Just to summary you will need to download an image from VMWare website as well as bunch of UEFI firmware files from github and combine it all together on to a SD card. When you boot it you will go through an install process which is straightforward. You can overwrite install media and use it as the target so no need for multiple SD cards. Once it boots you will see familiar ESXi boot screen:
ESXi booting on Raspberry PI 4
In order to get it going you will obviously need to add some storage. You can use NFS, iSCSI or locally attached USB drive. For the latest you need to disable USB arbitrator.
# /etc/init.d/usbarbitrator stop
# chkconfig usbarbitrator off
What can it run?
ESXi ARM only officially supports only UEFI boot based OSes. Fortunately this is a default option for Ubuntu PI, Free/Net/OpenBSD also work and so does Windows. But what about OSes that use U-Boot? Since ESXi-ARM Fling 1.1 you can boot oses in a “direct” mode with no UEFI! This is a huge step, but unfortunately as of today it doesn’t support UEFI-less VGA, only a serial port. Hopefully this can be fixed in future. I would love to have a RISC OS and/or Plan 9 VM. On the other hand Plan 9 supports EFI boot so an image could be made.
Windows guest install was also much easier than I expected. Thanks to UUP dump you basically roll your own bootable ISO. I think it’s actually easier to get it going on ESXi than natively on RPI hardware or QEMU.
Windows 10 Guest VM on ESXi Fling Raspberry PI
NIC driver obviously did not work by default, but there is a VMXNET3 ARM64 driver in the wild:
VMXNET3 for Windows 10 ARM64 on ESXi Fling on Raspberry PI
What is it good for?
Right now probably just for fun. But I can easily see datacenters filled in with ARM servers running ESXi. Future is bright and free of Intel! Personally I will keep it around for development purposes if I need to make builds for ARM on various OSes.
While talking about home brew 8080 and 8086 systems on Discord an ebay search brought me to Elijah’s store page where this small little curiosity was up for sale. It’s literally just a NEC v30 on a Raspberry Pi hat, for a mere $15 USD! Interestingly enough the v30 can operate at 3.3v meaning no special hardware is required to interface to the GPIO bus on a Pi. This reminds me so much of the CP/M cartridge for the Commodore 64, and the price being so right I quickly ordered one and eagerly awaited to 2 weeks shipping to Asia.
While I have Pi 4’s that I run Windows 10 on to drive some displays & power point, I wanted to use the slightly faster Pi400 for this. The Pi400 has a compatible GPIO expansion port so just like a cartridge it’s a simple matter of slotting the card, powering up and building the software. While there is an included binary, it’s a 32bit one, and I’m running Manjaro on the Pi400 for a similar look/feel as the PineBook Pro. Anyways the dependences are SDL2, and an odly named ‘wiringPi’ library that allows C programs to interface to the GPIO.
You can download the emulator over on homebrew8088, specifically the Raspberry Pi Second Project. The last ‘ver 2’ download has the project configured for a v30 which is an 8086 analogue, unlike the v20 which is an 8088. When physically interfacing to the processor things like this really matter!
With the emulator built it was pretty simple to fire it up, and boot into MS-DOS:
first boot!
I have to admit I was a little startled at first as I really had no idea if this was going to work at all. I’d spoken to an engineer friend and he was saying plugging a CPU directly into the GPIO bus, and toggling connections to actually emulate the board was both crazy and that without any electrical buffers it’d most likely either fry the processor and maybe the Pi as well. I suspect this being low voltage may be sparing both, although I have no EE so I’m not going to pretend to know.
Loading up Norton SI confirms what Elijah had posted on Ebay is that it runs very slowly about 1/3rd the speed of an XT. Now I may not know anything about hardware but this seemed at least something a profiler could at least tell me what is going on, and if someone like me helicoptering in on the shoulder of giants could see something.
This will build a profiled version of the emulator that’ll let us know which functions are being called both the number of times, and how much time to do so. Not knowing anything but having profiled other emulators, the usual pattern is that you spend most time fetching and possibly translating memory; Both in feeding instructions and pushing/popping data from stack and pointers. Waiting is usually for initialisation and for IO.
Once you’ve run your profiled executable, it’ll dump a binary file gmon.out which you can then use gprof to format to a text file like this:
gprof pi gmon.out > report.txt
And then looking at the report you can see where the top time, along with top calls are. Some things just take a while to complete and other well they get called far too often.
As expected Start_System_Bus takes 1 second, followed by 1,100,374 calls to set the Data_Bus_Direction_8086_OUT (no doubt the Pi needs to alternate between reading and writing to the CPU), followed by 5,954,106 ticks of the CLK function. Of course the real culprit is Print_Char_9x16 which was called 286,883 times, and is responsible for nearly 40% of the tuntime!
Obviously for a simple MS-DOS boot the screen should not be calling any print char anywhere near this many times. Clearly something is amiss. Not knowing anything I added a simple counter to block at the top of the Print_Char_9x16 function to let it only execute 1:1000 times, and I got this:
Obviously it’s not right, which means that the culprit really isn’t Print_Char_9x16 but rather what is calling it. It was a simple change to each of the Mode functions to only render a fraction of the time, and I changed it to a define to let me fire it more often. This is a simple diff, assuming WordPress doesn’t screw it up. It’s not pretty but it gets the job done.
$ diff -ruN ver2/vga.cpp ver2-j/vga.cpp
--- ver2/vga.cpp 2020-07-29 10:36:51.000000000 +0800
+++ ver2-j/vga.cpp 2021-06-04 01:51:33.546124473 +0800
@@ -1,5 +1,9 @@
#include "vga.h"
+static int do9x16 = 0;
+#define VIDU 5000
+
+
void Print_Char_18x16(SDL_Renderer *Renderer, int x, int y, unsigned char Ascii_value)
{
for (int i = 0; i < 9; i++)
@@ -23,6 +27,12 @@
void Mode_0_40x25(SDL_Renderer *Renderer, char* Video_Memory, char* Cursor_Position)
{
+do9x16++;
+if(do9x16>VIDU)
+ {do9x16=0;}
+else
+ {return;}
+
int index = 0;
for (int j = 0; j < 25; j++)
{
@@ -36,6 +46,7 @@
Print_Char_18x16(Renderer, (Cursor_Position[0] * 18), (Cursor_Position[1] * 16), 0xDB);
SDL_RenderPresent(Renderer);
}
+
void Print_Char_9x16(SDL_Renderer *Renderer, int x, int y, unsigned char Ascii_value)
{
for (int i = 0; i < 9; i++)
@@ -57,6 +68,12 @@
}
void Mode_2_80x25(SDL_Renderer *Renderer, char* Video_Memory, char* Cursor_Position)
{
+do9x16++;
+if(do9x16>VIDU)
+ {do9x16=0;}
+else
+ {return;}
+
int index = 0;
for (int j = 0; j < 25; j++)
{
@@ -102,6 +119,12 @@
void Graphics_Mode_320_200_Palette_0(SDL_Renderer *Renderer, char* Video_Memory)
{
+do9x16++;
+if(do9x16>VIDU)
+ {do9x16=0;}
+else
+ {return;}
+
SDL_RenderClear(Renderer);
int index = 0;
for (int j = 0; j < 100; j++)
@@ -156,6 +179,12 @@
}
void Graphics_Mode_320_200_Palette_1(SDL_Renderer *Renderer, char* Video_Memory)
{
+do9x16++;
+if(do9x16>VIDU)
+ {do9x16=0;}
+else
+ {return;}
+
SDL_RenderClear(Renderer);
int index = 0;
for (int j = 0; j < 100; j++)
While it feels more responsive on the console, it’s still incredibly slow. SI was returning the same speed which means that although we aren’t hitting the screen anywhere near as often it’s still doing far too much. Is it really a GPIO bus limitation? Again I have no idea. But the next function of course is the clock.
First I tried dividing the usleep in half thinking that maybe it’s not getting called enough. And running SI revealed that I’d gone from a 0.3 to a 0.1! Obviously this is not the desired effect! So instead of a divide I multiplied it by four:
Now it’s scoring a 1.5! Obviously these are all ‘magic numbers’ and tied to the Pi400 and more importantly I haven’t studied the code at all, I’m not trying to disparage or anything, if anything it’s just a quick example why profiling your code can be so important! At the same time trying to run games is so incredibly slow I don’t even know if my changes had any actual impact to speed as emulation of benchmarks can be such a finickie thing.
My goto game, Battletech 3025 Crescent Hawks Inception loads to the first splash but then seems to hang. I could be impatient or there could be further issues but I’m just some impatient tourist with a C compiler…
With my changes and re-running the profiler I now see this:
Which is now what I expect with the bulk of the emulation now calling Read_Memory, with the Clock following that and of course our tamed screen renderer (although its still called far too much!) with the Data_Bus_Direction being further down the list. No doubt some double buffering and checking what changed in between calls would go a LONG way to optimise it, just as would actually studying the source code.
The one cool thing about this is that if I wanted to write a PC emulator this way gives me the confidence that the CPU is not only 100% cycle accurate, but it’s 100% bug for bug accurate since we are using a physical processor.
And again for $15 USD + Shipping I cannot recommend this enough!
So yes, it’s most certainly built from a MacBook Air looking frame. But it’s not the same build materials, which of course is to be expected as these are far cheaper. Unlike the other ARM book I have, this one doesn’t have a GPRS modem, and as of this moment doesn’t natively run Windows. Which with it’s paltry 4GB of RAM and 64GB of disk space is just as well.
adding a 32bit runtime
Just as the MIPS64 had it’s weirdisims, the ARM64 is in the same seat. I didn’t see anything all that clear on Manjaro, and 32bit, at the same time debootstrap is available in the repo, allowing you to quickly install a 32bit Debian userland to chroot into. It’s pretty much the same steps as before, with the only real change being to use the armhf processor family giving a 32bit tree.
Maybe it’s my overall familiarity with Debian, but I find the environment far easier to deal with. Well that and of course many things just build so much nicer in 32bit mode, than 64bit mode sadly. It’s a shame that many distros don’t seem to include a matching 32bit/64bit libset but here we are.
Another plus is that Debian has far more robust mirrors world wide, and downloading components and updates is FAR faster than Manajro.
Loose clips?!
In the first week however disaster struck as I had it ‘sleeping’ one night and plugged in to charge, and when I opened the lid, I got nothing. The charging led showed RED for some reason like it was still charging, and no matter what I tried on the keyboard it just would not turn on.
Searching online didn’t give me much other than people saying that they were replacing the built in flash and didn’t seat it correctly. Did my kids or cat knock it over when I wasn’t looking? Was it on the edge of not being seated from shipping? I have no idea.
Lid off!
Well as much as I love opening new stuff, it was acting dead so I guess nothing to lose. That said the screws come off pretty easily but there is 2 sizes as the ones up front are super short. With the lid off you can see that the battery is 2x the size of the motherboard. And yeah of course it being ARM, its very raspberry pi – ish. And I guess it’s really no surprise.
The mainboard
On the mainboard there is 2 push buttons, and 2 sliding jumpers. One is hidden beneath the black tape. I hit the reset button, and slid both sliders up and down and then pressed down on the 64GB chip. I flipped it over to see if that did anything, and surprisingly it’d turn itself on!
I quickly shut it down, and screwed it back together. And I’ve been using it daily over the last week without any further issues with it powering on. Again I have no idea what was wrong but at least it seemed easy enough to open up and hit some buttons. Which brings me to the overall feel:
Build quality
It’s really hard to slam the PineBook Pro. It has incredibly lofty goals, and for the pricepoint it’s absolutely insanely good value. The body has been molded from what at best could be called an ‘inspired by the Mac Book Air’ but it’s the keyboard and trackpoint where it falls short. The keys have too much travel for their own good, and seem to twist a little giving a klunk as they don’t depress quite right. I have had issues with the arrow keys trying to play DooM via DOSBox. And I’ve become so spoilt with backlit keys, that although I know how to touchtype I still look from time to time.
The trackpoint is miserable, it’s constantly jumping the mouse (no palm detection)? and it just doesn’t glide or click ‘right’. But I know I’m being 100% unfair as I’m comparing this to a laptop that is 5x the price. I’ve written this and other stuff on the laptop and it’s just been so jumpy at times for seemingly no reason when I type it’ll jump and click at the worst possible moments.
The flip side is that FPS stuff is impossible as the keyboard and trackpoint won’t deliberately work at the same time. And I have no idea how to go about dealing with that. I guess use an external mouse.
Another stupid low point is the speakers. They are so tinny which I guess is to be expected, but they are so quite. I guess I should play test tones, and get some app to measure dB, but comparing it to anything else again just seems so unfair.
That said the screen is AMAZING. I had worried that the screen was going to be terrible, but no the screen is an absolute high point of the machine.
Battery life has been pretty good, and from opening it up, it’s no surprise as it does have a massive battery. They do include clips to bypass the battery all together if you want to run it from DC mains 100%. The only issue I have had with battery life is that Manjaro doesn’t seem to have hibernation support. And many times I put it to sleep when I go to sleep it’ll wake up with zero percent remaining. I don’t see that as a fault of the physical build, rather the OS.
Software and FSF flailings?
I don’t know much about Manjaro but it’s default setup sure feels a lot like the way Debian felt when they were under pressure to keep all non-free stuff segregated and partitioned away from users. The problem as it’s always been is that popular software has almost always been commercial, especially for normal uses. Turning on Community and Contributions should really be the default setting with people who want to be FSF pure having to click the button giving normal people the best possible experience. As an old person who’s been hearing about the ‘year of the Linux desktop’ is at hand back in 1997 (Va Linux et al), and been an on and off user since SLS, it’s always about the users. All the plugins and bookmarks and shared data stuff I have is on Chromium and having to hunt down how to turn it on sucked, as I was moments away from just doing the usual ‘user’ thing of wiping the install because I can’t find an app.
Distro shopping has been the worst thing to plague Linux since it was apparent that Linus wasn’t going to bless us a userland, unlike BSD. I know some see it as a strength but it’s always been such a critical weakness for the user. Oddly enough the circle has come around to bite enough people that Docker is a thing to deal with dependency and distro hell.
Games!
Well without a doubt visit astr0baby’s blog and enjoy some good hand holding to get a bunch of open stuff built. It’s toally worth it. And incredible to play 64bit Duke Nukem 3D!
Is it worth it?
Well if you want non x86 on the go, the price simply cannot be beat. However the default Linux install is alien to me, but I’m trying to learn to deal with it. And of course the weird power on issue really precludes this from normal people. I’d recommend it to anyone comfortable with Linux and a screwdriver. If you are 100% hardware focused it’s a laptop, no GPIO so it’s going to be a little bit of a bummer. If you are scared of opening it up, you may find like I did that you very well might have to. However for anyone in the middle absolutely.
“Normies” this isn’t the laptop you want. .. I’d say “yet” as I’m sure that build quality will only improve, just as software will hopefully get a bit more friendly for adding stuff like Chrome (what a mission to get it installed!).
Final ramblings
Years ago in college we joked that 30 years in the future you could get a quad processor Dec Alpha as a bundle in with a box of cereal. That a computer would be an impulse purchase at the supermarket. It seemed so laughable but a given as manufacturing and acceptance of that internet thing was a given. But that was the future from 30 years ago.
This is really nothing more than a placeholder for me… Unless someone else knows the answer, then it’s really ‘how not to cross compile GCC’.
First I’m using the EMX’ified version of GCC from my MinGW to EMX cross. It didn’t require that much massaging to get it to build, the usual unzip as ascii to convert text, and in no time I can build cc1.
[email protected]:/src/emx/src/gcc-2.5.8# file cc1
cc1: ELF 32-bit LSB pie executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=42c0c8de7175edade7614dc92d5d13e4421e0e6f, with debug_info, not stripped
and it crashes in what has to be a 2020 most unfortunte name
Reading symbols from cc1...done.
(gdb) r
Starting program: /src/emx/src/gcc-2.5.8/cc1
Program received signal SIGSEGV, Segmentation fault.
0x004f6b84 in rtx_cost (x=<error reading variable: Cannot access memory at address 0xff7efff0>,
outer_code=<error reading variable: Cannot access memory at address 0xff7effec>) at cse.c:667
667 {
(gdb)
Yes, it really crashes in rtx_cost. Good thing there isn’t a super popular card from Nvidia that is currently being short squeezed by crypto miners right now called the RTX where everyone is looking for a good price. 😐
I had then been thinking perhaps it’s because I’m using GCC 8.3.0, maybe it’s introducing some new and exciting bug? So I cross compiled GCC 4.1.2 as follows:
Keeping in mind that my knowledge of ARM is pretty much nill, especially on Linux. The compile went mostly okay, just have to remember the gnu inline macro’s as needed from back in the day (-fgnu89-inline) and while it builds, it is insisting on using collect2 which of course is screwing things up. And of course I don’t want it as my system compiler. As a hack I found system gcc 8 can link things fine as I didn’t want to spend all day messing with GCC/collect2
I copied xgcc, cc1 and cpp from 4.1.2 into a /412 directory, and rebuilt 2.5.8 with the following shell:
As you can see the cross wasn’t picking up the right include paths, so I just cheated, and dumped them from 8, and just copied them into this script. I re-ran the build and had 2 issues,
/412/xgcc -B/412 -g -O0 -I. -I./config -I/usr/lib/gcc/arm-linux-gnueabihf/8/include -I/usr/local/include -I/usr/lib/gcc/arm-linux-gnueabihf/8/include-fixed -I/usr/include/arm-linux-gnueabihf -I/usr/include -c -DIN_GCC -g -std=gnu89 -I. -I. -I./config local-al.c
....
/tmp/ccMguyhs.s: Assembler messages:
/tmp/ccMguyhs.s:5001: Error: selected processor does not support `fltd f1,r3' in ARM mode
/tmp/ccMguyhs.s:5025: Error: selected processor does not support `fltd f0,r3' in ARM mode
/tmp/ccMguyhs.s:5026: Error: selected processor does not support `dvfd f1,f1,f0' in ARM mode
/tmp/ccMguyhs.s:5027: Error: selected processor does not support `ldfd f0,.L489' in ARM mode
/tmp/ccMguyhs.s:5028: Error: selected processor does not support `mufd f0,f1,f0' in ARM mode
and so on. Also failing was global.c Again the same weird instruction/asm mix being triggered. Other than those two, cc1 will build, but unsurprisingly:
Reading symbols from cc1...done.
(gdb) r
Starting program: /src/emx/src/gcc-2.5.8/cc1
Program received signal SIGSEGV, Segmentation fault.
0x004f6b84 in rtx_cost (x=<error reading variable: Cannot access memory at address 0xff7efff0>,
outer_code=<error reading variable: Cannot access memory at address 0xff7effec>) at cse.c:667
667 {
(gdb)
Well, at least it’s consistent?
Or a fun way to kill a couple hours.
**EDIT I went ahead and looked in the 4.1 source for ARM stuff..
[email protected]:/src/gcc-4.1.2# grep arm config*|grep linux
grep: config: Is a directory
configure: arm*-*-linux-gnueabi)
configure.in: arm*-*-linux-gnueabi)
it didn’t like the gnueabihf stuff one bit.
I tried to rebuild as linux-gnueabi
./configure --target=arm-linux-gnueabi --host=arm-linux-gnueabi --build=arm-linux-gnueabi
make LANGUAGES=c HOST_CFLAGS='-fgnu89-inline' CFLAGS='-fgnu89-inline'
And then re-built GCC 2.5.8 with the same error, but slightly further into the program:
Starting program: /src/emx/src/gcc-2.5.8/cc1
Program received signal SIGSEGV, Segmentation fault.
0x004f2a20 in rtx_cost (x=0x41, outer_code=PLUS) at cse.c:679
679 code = GET_CODE (x);
(gdb) bt
#0 0x004f2a20 in rtx_cost (x=0x41, outer_code=PLUS) at cse.c:679
#1 0x004f2e20 in rtx_cost (x=0x60c3f8, outer_code=SET) at cse.c:736
#2 0x004ac2dc in init_expmed () at expmed.c:87
#3 0x0045ae28 in compile_file (name=0x5c96ec "stdin") at toplev.c:1648
#4 0x0045f6fc in main (argc=1, argv=0xfffefd04, envp=0xfffefd0c) at toplev.c:3569
(gdb)
The positive thing is that there was no weird register errors while compiling, and it built 100% normally…? “arm-linux-gnueabihf” almost seems right, specs needs fixing to point to “/lib/ld-linux-armhf.so.3” instead of “/lib/ld-linux.so.3” along with the linker target.
As far as computers go, Raspberry Pi’s are cheap. The latest (and vastly incompatible) Pi4 is no real exception. Now you’d think Microsoft would want to get WoA (Windows on ARM) into as many hands as possible to get people to port apps to the new cpu architecture. But that is not the case.
As of this moment there is no real desktop machines, the only route to go is with the laptops, which are the few models from Lenovo, HP, Acer and Microsoft themselves. Brand new these things are not cheap, and of course people find out quickly enough that the emulation just isn’t quite there (not all that surprising) and of course the lack of native apps doesn’t help. It’s that chicken/egg problem that can only be solved by getting hardware into people’s hands.
Developers!
So getting back to to the Pi, on ETA Prime’s channel I saw this video, which quickly went over how to get Windows 10 up and running in no time flat.
Pi4 (4GB/8GB it doesn’t matter thanks to a DMA bug you can only use 3GB)
On the Discord look for the #download-links and look for build 0.2.1 After you extract it, the image should be about 10GB
10,100,932,608 build 0.2.1.img
With a MD5 checksum of: aad51a0e02ba947d24d543ff8ed612b0
Use etcher to write the image to the SD. It took me about 5 minutes to do so. No bigge. I unplugged the SD/IDE/USB adapter thing I’m using, plugged it back in, and used Windows disk manager to expand the partition to take up the rest of the disk. It’s not terribly complicated to setup.
SSD FlashedRight click and select ExtendThe default option will consume the entire disk
After that slap in the SD to your Pi4 and away you go. Or so I first thought.
Realistically you also need:
A USB Hub
A USB Ethernet adapter (I have some cheapo no name realtek)
A USB audio card
A mini HDMI to regular human sized HDMI cables/adapters
a 5Amp USB charger for extra power!
As I found out rather quickly that the only peripherals that are working is the USB ports. However the USB controller has some DMA bug where it can’t xfer higher than 3GB which caps the current memory ceiling to 3GB.
Otherwise the Pi will think and reboot a few times, and about 15-30 minutes later (I didn’t time it, I walked out) you’ll be up and running Windows 10 on ARM!
It’s heavily customized in that when Windows boots up it is only consuming about 1GB of RAM. So that gives us just under 2GB for user programs. GREAT! Included is the setup program for the latest beta of Microsoft Edge (with the chromium engine) so at least you can actually hit web sites. However Google doesn’t like it, so if you are going to try to watch anything with DRM it will not work.
While many people complain about STEAM, game compatibility, really what on earth were you expecting? Naturally people will want to know how fast it is, and well… It’s not. Although it does have 4 cores, running at 1.5Ghz, there is barely any cache (well compared to an i7/Xeon), and it’s clearly not a power house of a box. The only real test of a machine like this is going to be native stuff. And speaking of, it’s nice that my previous builds for ARM still work! The sales guy that borrwed the ASUS should be back soon so I can do some side by side comparisons of how slow they are.
In addition to DOSBox, Neko98, and frontvm, I managed to get MAME 0.36 cross compiled and I had to disable the DirectX input and output, as although they do compile they have issues on the Pi4. So it’s GDI all the way. That said, it does run:
This isn’t the port you want, or the platform to play it on. I’m using the command line Visual C++ tools to build this, and MAME 0.37 drifted to being more of a MinGW thing, and I just don’t feel like fighting the build process.
Another point of fun, is that this processor & OS does have x86 compatibility you can take things to the extreme with OTVDM, and run Win16 based programs on Windows 10 for ARM! Not that I would know why you want Excel 3.0, but rest assured, it works fine.
The platform supports WSL, so I went ahead and installed Ubuntu 18 & 20… and both have one apparently known catastrophic failure on the Pi’s. When trying to update packages the updater crashes. The fault is apparently in dirmngr, or the usual Linux bandaid of switching distros. There doesn’t appear to be any ‘fix’ to this, so if anyone knows what to do, I’m all ears. Also don’t enable WSL2, it’ll hang at the bootloader. I ended up having to reflash the disk.
In my quick conclusion, is this the RISC Windows workstation of the future? No, not really. It’s more the $50(+peripherals) tyre kicker edition. It’s a cheap way into the platform, to see what the fuss is all about. This machine feels like a low end i3, the CPU just isn’t there, it’s only a BCM2711 Cortex-A72, so there isn’t all that much to be expected. On the other hand it’s FAR FAR FAR cheaper than something like the Surface X. If you have the hardware it’s worth checking out if you are interested in non x86 Windows. Otherwise you aren’t going to miss much.
Details don’t seem to be anywhere near as complete as I’d like them for now, but the long speculated move to ARM has finally begun. Interestingly enough, it’s the end of OS X 10.x as now we have version 11, currently named macOS Big Sur:
I guess the more interesting thing will be the emulation in the new Rosetta2, if this is actual emulation or is this going to be relying on LLVM’s intermediary byte-code, allowing a user experience more akin to Java.
With the move to ARM, this will spell the end of the Hackintoshes. Which is a shame, as the best way to experience OS X, most certainly has been on non Apple hardware. I guess time will tell regarding the adoption of the desktops, but as always since the introduction of the Apple Store & Apps, computers have accounted for a negligible fraction of Apple’s sales. Even sales of iPads surpass those of all the computers combined.
The upcoming transition kit will be a Mac mini sporting the A12Z SoC, 16GB of memory and a 512GB SSD. This is the same processor in the current iPad Pro.
The Transition Kit is $500 USD, however it’s invite only. You can try your luck here at:
Naturally I was denied the opportunity to give them $500.
I suppose as time goes on more and more details will become available. I’m sure there will be a race to get Qemu to run Big Sur, although Im sure the retail product will be signed and encrypted, and Apple will consolify their ecosystem.
On the gaming side, however being able to run iOS apps on the desktop means that the Mac is now a serious gaming contender for the casual market. Can apple bridge the Candy Crush gap where Microsoft failed with RT?
BMC64 is a bare metal fork of VICE’s C64 emulator optimized for the Raspberry Pi. It has 50hz/60hz smooth scrolling, low video/audio latency and a number of other features that make it perfect for building your own C64 replica machine.
I had to pick up some bits and bobs as there is some circuits I wanted to try to build, and oddly enough the electronic store I went to had some Pi’s! I bought 2 zero’s and 2 three’s! They aren’t cheap, sadly but I honestly doubt any zero’s actually ever sold for £5, and these cost me $168! Each! (just under £20!).
Anyways since I had nothing to do with these things, I already ordered a 1541 hat for the Commodore 64c, so I’ll need a 3 for that, but I was looking around and ran into the bmc64!
You do have to drop in your BIOS files manually, which is the only tedious bit, then dump over your taps’ and d64’s. My 3 boots up in a few seconds straight to the BASIC screen, like it’s 1983!
I was expecting it to be a lot of work, and it really was a SNAP. Not that I have any shortage of machines, or tiny machines to run VICE, but this running on metal is honestly kind of exciting.
I’d have loaded it on the zero, but it uses some mini HDMI port, and all I have is regular HDMI cables. I also picked up some heat sinks for the CPU’s as no doubt, no idle loops means it’ll get toasty.
It’s something I’d encourage people to check out, if anything to see how versatile a bare metal program can be for the pi’s.. Although apparently they screwed up the 4, it’s too different from the 0/2/3 for some reason.
So after the crazed purchase I made a few weeks ago, I returned from Japan, and was able to unbox and use the machine I’d been wanting for a while, a non x86 Windows laptop!
The NovaGo has a Snapdragon 835, and my phone, the ASUS ROG phone has the 845. Yes for this week, my cellphone actually has the stronger processor than my computer. Honestly this is almost an unthinkable situation! Although I haven’t been using my phone as a desktop substitute this week. It’s amazing how MS screwed up 10 on the phones, and Continium.
By default it comes crippled with this ‘S’ mode Windows, which hearkens back to the Windows RT launch, with the difference that it’s a quick trip to the application store to unlock Windows 10 Professional. It’s a free download as it should be, and it doesn’t even require a reboot!
Build quality isn’t so bad, the screen folds all the way back to make the machine into a ‘tablet’ although I don’t like that mode so much, it just feels wrong to wrap a keyboard around a monitor. However if you have rambunctious young kids, it’s great as when someone went running by me flailing their arms around like a while animal, when they struck the laptop the screen could easily fold back 180 degrees. Yay.
My first thing to do after setting up Office and VMWare VDI was to install the Linux subsystem, and Ubuntu. it’s exactly the same as it is on x86_64, which is great. And this let’s me have the best of both worlds, just like x86_64. As much as I dislike stumbling around with that aborted child of Pascal & Fortran (Python) at least I can run it under (mostly) Linux to get something close to like the production environment.
The C/C++ compiler is actually all cross tools. I wanted CLI only stuff because I like torturing myself, and it required a few GB of downloads. The good news is that the latest Windows 10 SDK does support GDI/CLI apps, so no crazy SDK hacking required, unlike back in the Windows RT days. Oddly enough the Taskforce 87 interpreter runs fine, but nothing else does.
I did a horrible job at hacking up SDL 1.2 to at least run (kind of, the audio doesn’t work, and it’s all WinDB*EDIT I got it fixed!!!) I got a few things up and running, including DOSBox and FrontVM. One thing that greatly helps is that i386 binaries ‘just work’. Honestly you wouldn’t even know you are running them when you are. Which made hunting down the ARM64 version of Chromium Edge kind of difficult to find. There really needs to be a more apparent way to tell them apart, if anything for battery efficiency.
Again the audio in my crap SDL build doesn’t work, so DOSBox is silent, and without Direct X, the text mode is tiny. Oh also, there is no OpenGL in this version of Windows dev kit for some reason. Running ssystem is ungodly slow. Also the default optimizations seems to be Os, optimize for space, and on this ASUS I have to say /Ox is way way faster. DooM is quite playable on DOSBox when build with /Ox, unlike /Os.
For me, I spend most of my day to day in Office, and VMWare VDI, connecting to secure networks. So I’m just one step above a terminal. Which I guess is kind of sad, but this machine more than fills that roll for me. The 120GB of storage is tight. This isn’t a development machine persay, nor is it something to download tonnes of data to, it’s a lightweight machine where it’s strength is the built in 4G modem, and when running ARM software the longer battery life. To me the biggest drawback is that the keyboard isn’t backlit. Even though I touch type, I didn’t realize how much I’d grown used to it for casual use.
I guess it’s a hard toss up from this and a PINEBOOK Pro, I think most readers here would prefer the Pinebook, for all it’s openness, although I still like the idea of being able to copy over the Win32s version of Lemmings, and it just running. For me I kind of like this thing, although once I switch back to an x86_64 with more memory, better GPU and disk options, maybe this just feels like some kids toy.
Neko98 ARM!
I don’t know how I didn’t think of this, but I also ported Neko98! Although the STL is having an issue with the ‘control panel’ so Neko is on autopilot.
This app can’t run on your PC
As for the emulation, it is 32bit only, so expect to see this stupid message quite a bit. The neckbeard is a nice touch though.
Also built into the thing is a cell modem. I guess it’s really not a surprise as the 835 really is a cellphone SOC. I have a ‘wifi egg’ as they are called here, a WiFi hotspot with unlimited internet from CLS, which is on the old 4G network. I popped the SIM in, and it picked up the APN settings on it’s own and I was connected in under a minute. I have to say that it’s about time that SIM cards have this stuff programmed into them for a plug & play experience. And thankfully the ASUS is unlocked, although from what I understand these were sold in the USA bundled with some cell service plans.
For anyone with one of these rare machines that cares to play along you can find my built stuff on my ‘vpsland’ archive: