How many people haven’t looked at their Game Boy Advance (GBA) handheld gaming device and wondered how much better it might be if it could run FreeDOS. Inside an 8086 emulator. If you’re like [ZZAZZ] and similarly suffer intrusive project-related thoughts, then this might be a moment of clear recognition, somewhat like sharing one’s story at a Programmers Anonymous meeting, but we digress.
In the video, the basic premise of making even the 8086tiny emulator work on the GBA seemed improbable on the outset – courtesy of the rather limited memory environment provided by the GBA – before even daring to look at things like disk access.
However, letting silly things like segmented memory and mismatched memory addresses deter us from pleasing said intrusive thoughts would be beyond the pale. Ergo we get a shining example of how days of rewriting code, stripping code, debugging code, fixing alignment issues in code and writing work-arounds for newly discovered issues in code can ultimately lead to the proud moment where FreeDOS boots on the GBA.
Granted it takes over an hour to do so, and has to be started from a butchered Pokémon Emerald save file, courtesy of a well-known exploit in that game, thankfully preserved in counterfeit cartridges.
Admittedly we’re not sure what practical applications there are for FreeDOS on the GBA, but that’s never stopped hackers from taking on impossible projects before, so there’s no sense letting it get in the way now.
Thanks to [Jinxy] for the tip.
Actually, Z80 GameBoy CPU is a distant cousin of early X86 so it should be possible to binary translate MS-DOS on the fly and get it to run at full speed.
Isn’t the main CPU in the GBA an ARM? IIRC the Z80 is there for backwards compatibility with older Gameboy games.
I think so, but classic GBC games like Zelda DX hat the ability to detect if they ran on a GBA.
Maybe it’s possible to have both CPUs running same time somehow?
In either mode doesn’t matter, maybe. If a GB game can access ARM chip or GBA game can access DMG CPU, I mean.
Nay.
If I recall correctly, the CPU starts off as GBA, and check the cartridge switch (so no read/write to the cartridge yet).
If the cartridge switch is set to GB, the CPU switches to compatibility mode, but also switch the cartridge data bus to GB, meaning 16bits address and 8bit data “5Volts”.
If not, the cartridge bus is left as it, with hybrid address/data mode, 16bits, 3.3V.
The GBA/GB detection was done very easily. Nintendo initialized one specific register at a different value on purpose. The only real usage was to correct your color palettes to work better with the GBA screen. Some game used it to offer bonuses too (like Zelda Oracle of Season and the “Advanced ring”).
But as far as I know, you can’t access anything of the “real” GBA hardware, as opposed to the Super Game Boy Mode (that would have been so dope!)
The 8086 being 16 bit and the Z80 8 bit would make this pretty much an emulator not a translator.
Now, running CP/M would be easier, since it was written for the 8080/Z80
Albert’s idea wasn’t so wrong in principle, I think.
The NEC V20/V30 provide i8080 emulation through register-renaming.
So they map 8080 intructions onto 8086 counterparts.
That’s why NEC V20/V30 lack Z80 compatibility, also.
The 8086 didn’t feature anything comparable to begin with.
That being said, the problem I see is segmentation.
The Z80/i8080 has 64KB address range, which matches the 64KB segment size of 8086 (and the COM file).
So in order to gain more than 64KB of memory, bank-switching is needed.
Or, someone has to write a “tiny DOS” that fits into less than 64KB.
It’s certainly possible! The EXE loader and internal commands of DOS are the biggest.
Writing a simple DOS that can run COM files only is not much more work than writing a CP/M clone, which there had been many.
“Now, running CP/M would be easier, since it was written for the 8080/Z80”
Or MSX-DOS, which shared some things with MS-DOS. FAT12 filesystem, for example.
https://en.wikipedia.org/wiki/MSX-DOS
Writing a 8086+DOS emulator for CP/M or MSX-DOS might be a possibility.
Like an Z80 emulator in reverse (NICE22, Z80MU etc), basically.
It would allow running text adventures, maybe. Or playing Alleycat, if CGA emulation was added.
It’s just an idea, though. Actual implementation is different from theory, of course. Easier said than done.
what gameboy had a Z80? the nintendo gameboy has an SM83 core which is a relative, but isn’t a Z80.
also technically they are relatives of the 8080, not the 8086. early CP/M (8080 only) might run. Any CP/M targeting the Z80 though is off the table without heavy patching. given how closely DOS relies on 86 features, it would still have to emulate a lot of CPU state.
“what gameboy had a Z80? the nintendo gameboy has an SM83 core which is a relative, but isn’t a Z80.”
Yes, the DMG CPU was an Z80-ish CPU and not a true Z80.
But that’s nitpicking and known since the 90s.
In the press, the Gameboy was always being treated as a Z80 handheld, so users are not to blame to call it a Z80 platform.
There had been data loggers and other accessories to use the GB as a productive tools.
In great parts because Z80 tool chain could be used here.
Traditionally, emulators also use a modified Z80 core to emulate the 8-Bit Gameboys. :)
Hi, I think there’s room for improvement.
An 10 MHz 286 PC from 1988 can boot MS-DOS 6.2 via 8088 PC emulator in roughly same amount of time as this modern ARM handheld.
https://tinyurl.com/muu6vnhf
Correction. The 286 is faster, actually? 😲
ca. 20 min for POST (memory test)
ca. 12 min booting DOS
ca. 2,5 min for executing “VER” command
286 is older, sure, but a GBA is not a modern device. It’s 25 years old and runs on AA batteries.
Yes, but the 80286 has 134k transistors, is from 1982 and that 8088 emulator was written in QuickBasic 4.5 and uses full CPU emulation (no JIT).
Normally, an Acorn Archimedes from 1987 with the first ARM chip should run circles around it, even.
Or so I think. I’m just a layman.
Just for clarification, the 80286 isn’t booting DOS natively but runs an PC emulator:
An unoptimized IBM PC emulator (written in Basic) running itself on a “slow” PC/AT from the 80s.
So it’s comparable to an 80s era IBM PC/AT 5170 emulating an 80s era IBM PC/XT 5160 entirely in software, essentially.
And still being faster than a handheld with a modern ARM7TDMI processor at 18 MHz.
For comparison, in 1987-1989, the Acorn Archimedes with ARM1 at 8 MHz ran PC emulators, too. At usable speeds.
It’s been listed here: https://chrisacorns.computinghistory.org.uk/AcornOS.html
The very first ARM computer already was a power house, so to say.
There was no slow ARM processor ever, in that sense.
Even the old GBA processor was quite powerful, given enough RAM.
This video from the 80s gives an impression how powerful it was.
https://www.youtube.com/watch?v=VK5AZrg3ZD8
That being said, I don’t mean to provide any criticism here.
Making a GBA run DOS or ELKs is a very tricky task to do!
The author who did it was very good, my compliments! 😃👍
I just meant to give an idea how powerful hardware from the 80s could be.
Both 80286 and ARM in this case.
Because nowadays, it’s too easy to think that old technology was primitive, which it wasn’t.
Even the simple 6502 was notable, in its own ways. ;)
18 MHz ARM7TDMI is not exactly a modern CPU… :)
The ARM7TDMI rev3 has 0,8 MIPS per MHz. At 18 MHz, that’s about 16 MIPS.
The 80286 at 10 MHz has merely 1,5 MIPS, by comparison.
Sources/references:
https://developer.arm.com/documentation/dvi0027/b/applications-and-benefits
https://en.wikipedia.org/wiki/Intel_80286#History_and_performance
Indeed. I ran a PC emulator (PC Conqueror) on my Sinclair QL back in the day. Emulating an 8088 on a 7.5 MHz m68008 was slow, but I could boot MS-DOS, even with drivers and stuff, within a minute or two. I could even play some games.
Granted, PC Conqueror was written in optimized m68k assembly, but a 16 MHz Arm chip with 16 bit RAM and significantly fewer cycles per instruction shouldn’t be THAT much slower.
Can GBA run the original DOS version of DOOM?
Very unlikely.
The GBA port was already quite optimized at the time.
Now, today, it has even been optimized a bit more, but still, the memory constrains are the biggest barrier.
Now, you can without too much problems repack the original game and run it in modern GBA DooM engine.
But the original code? I don’t think so, no.