Update. Found an early emulator for the NEC PC-6000 series, iP6/Windows.
This platform was better known in Europe/US as the NEC TREK computer system.
The latest release runs on Windows 3.1+Win32s, but there's a problem with the video.

Issue seems to be on the Windows 3.1 side, in GDI/WinDIB. We saw a similar issue with vMac before.
Just to be sure, I used an unaccelerated SVGA driver and different colour depths, as well.
On European Windows XP, it runs as expected. NT 3.51 failed (no luck w/ MSIME32).

If you're on Windows 9x or an older Windows NT operating system that's not Japanese,
you may need the WINNLS dummy DLL or the real thing (WINNLS.DLL, IMM.DLL)
See https://otakuworld.com/index.html?/toys/utils.html

The emulator can be found at http://p6ers.net/mm/pc-6001/

It emulates the basic PC-6001 (32KB),-which basically has no software support-,
as well as the more popular PC-6001 mk2 and successors: PC-6001 mk2SR, PC-6601 and PC-6601SR.
A floppy drive for the PC-6001 Mk2 seems to be emulated, too.

Specs of the basic model (PC-6001)
NEC µPD780 CPU (Zilog Z80 clone),
16 KB RAM (32 KB max expansion)
AY-3-8910 3-voice PSG
ROM Cartridge connector
cassette tape interface
2x joystick port
parallel printer connector
composite video output, RF modulator output

It supports four screen modes; 32x16 characters with 4 colors,
64x48 pixel graphics with 9 colors, 128x192 graphics with 4 colors,
and 256x192 graphics with white and green colors.

Edit: Demonstration of different video modes: https://www.youtube.com/watch?v=TbEVbHwsB6I

Source: https://en.wikipedia.org/wiki/File:NEC_PC-600 … _brown_seat.jpg

NEC TREK pictures: http://www.blackdiamond.co.za/incomp/nectrekpix.html

PS: I've attached an archive containing the versions on the aforementioned website.
In addition, replacement files for the BASIC interpreter and the character font are provided (BIOS files).

I hope that's okay - to my understanding, these are free remakes of the originals (GPL license etc).
They're merely usable for getting basic emulation of the original PC-6001 going, also.
That being said, I'll remove them on request, of course. There are no bad intentions.

I've merely attached them, because they're really hard to find.
It requires lots of patience and traveling across Japanese language websites.

It's hard to imagine how anemic a lot of these old computers really were in terms of raw hardware performance if they can be emulated so well on such old hardware. It's so impressive to see all of this hard work by so many talented people.

This was also the era of experienced ASM programmers, so I would imagine that so much if this code is very tight for the era, and this is what helps so many of them run as well as that do.

Hi Kahenraz, nice to see you again! 😃

Kahenraz wrote on 2023-11-17, 04:54:

It's hard to imagine how anemic a lot of these old computers really were in terms of raw hardware performance if they can be emulated so well on such old hardware.
It's so impressive to see all of this hard work by so many talented people.

I know, right?! 🙂
The 8 and 16 Bit microchip era (including 16/32-Bit era) was kind of special here, in some way or another.

At one hand, you could build/fix things on a kitchen table at home, while simultaneously the hardware was capable enough to be used in daily life.

That's also why, say, Amiga people used to be so enthusiastic, I think.
With a soldering iron, a few wires and a stack of books about programming/hardware design, everything seemed possible.

The power was in the hand of the user, there was a feeling of being independent and creative.
And it wasn't wrong, I think. The 16-Bit era had a lot to offer.

Believe it or not, I managed to get the GBC game Shantae to run on an 10 MHz 80286 PC with VGA graphics.
I used no$GB, if I remember correctly.

_
Generally speaking, the trick was (is) to take "shortcuts in emulation".
Because of the hardware limitations of the time, developers/programmers had to get creative. 🙂👍

Many earlier emulators thus used tricks, that could be enabled, to enhance performance.
Playing with the timings and skipping certain parts were two of them.

On the other hand, many accuracy fans didn't quite like that approach (they even existed back then).

Even though all the hackery was an optional feature, most of the time (tricks could be disabled in emulators often, in favor of clean/more compatible emulation).

_
Back in the later 90s, games had been widely patched/tricked to work well in emulators.
And as time went on, this ended up in the extreme.
At some point, the resulting binaries did end up as being incompatible with real hardware.

Ok, in principle, that wouldn't have been so bad if the internet wasn't the way it was.:
Instead of distributing patches and games separately, the retro fans started sharing pre-patched binaries.
Which merely ran in emulation. Or worse, on specific type (& version!) of an emulator.

That's about (roughly) when emulators got internal patching ability, I believe, to at least also partially prevent modified binaries from spreading.

The whole re-dumping scene started roughly at that time, too.
People had an increasing interest in preservation of "clean" (unaltered) binary images.

That's when the header formats had been improved, as well, I believe.

There was an increasing desire not just being able to play old games or run old applications,
but also preserve the original experience.

That finally ended up in very sophisticated emulators such as BSNES, which were *very* demanding.
And not ideal for casual playing, maybe, but rather great for studying/research.

These emulators were primarily designed to be cycle exact and to mimic the internal working of the real model.

It was essentially no longer traditional emulation at this point, but an evolutionary step torwards mimicry.
The FPGA movement contributed to this, as well, maybe.

Anyway, I'm speaking under correction here. That's just my current, personal point-of-view.
So I hope I'm not getting quoted here. 😅

Emulator developers, cr*ckers and sceners are more competent to make a proper statement here.

Kahenraz wrote on 2023-11-17, 04:54:

This was also the era of experienced ASM programmers, so I would imagine that so much if this code is very tight for the era, and this is what helps so many of them run as well as that do.

Yay! Makes me remember my father's ring binders!
He's got collected a lot of 8-Bit era listings, mainly containing Z80 assembly (not sure if Intel or Zilog Mnemonics, though).
Anyway, if there's an interest, I can post some photos! 😃

Kahenraz wrote on 2023-11-17, 04:54:

It's hard to imagine how anemic a lot of these old computers really were in terms of raw hardware performance if they can be emulated so well on such old hardware. It's so impressive to see all of this hard work by so many talented people.

This was also the era of experienced ASM programmers, so I would imagine that so much if this code is very tight for the era, and this is what helps so many of them run as well as that do.

I got "calibrated" to emulation being possible on about 4-6 times the clock speed on the host system, with it managing about 95% compatibility.... that it seems to take 20-100 times the clock to get that last 5% these days really ticks me off.... and the size... holy crap... I'm not sure it could be any larger if it was a lookup table of every instruction combo result.

I had a similar experience with N64 emulators. They would run just fine on my old Vanta and some Pentium processor for Mario 64 back in the day, but it took years and many Ghz to manage the last bit of compatibility and speed needed by most games.

BitWrangler wrote on 2023-11-17, 15:56:

Kahenraz wrote on 2023-11-17, 04:54:

It's hard to imagine how anemic a lot of these old computers really were in terms of raw hardware performance if they can be emulated so well on such old hardware. It's so impressive to see all of this hard work by so many talented people.

This was also the era of experienced ASM programmers, so I would imagine that so much if this code is very tight for the era, and this is what helps so many of them run as well as that do.

I got "calibrated" to emulation being possible on about 4-6 times the clock speed on the host system, with it managing about 95% compatibility.... that it seems to take 20-100 times the clock to get that last 5% these days really ticks me off.... and the size... holy crap... I'm not sure it could be any larger if it was a lookup table of every instruction combo result.

I hope you guys don't mind if I join that discussion. 🤓
Personally, I remember that at one point, factor 10 was a vague rule of thumb, too.
It was somewhat convenient as a number to tell beginners about emulation.
That way, they got a feeling for complexity of the vintage systems.

So they understood why an 1GHz Pentium III was needed to emulate, say, an 386/486 era PC.
Or why a 10 MHz AT (and up) was needed to emulate a humble C64 at 1 MHz.

But things have quite changed for the worse since the days of ZSNES and small, quick C64 emulators.

That's why a few years ago I got a bit angry over BSNES and its wasteful use of resources..
While my basic opinion hasn't changed, I do try my best to tolerate such nitpicking emulators by thinking of them as neat research/debugging tools.

Their accuracy is really helpful to troubleshoot certain things, to emulate the complete hardware of things like Super Gameboy adapter or the Satellaview.

But playing games on them? Casually? I really don't know. It somehow doesn't feel right to me, not sure how to explain.
(In my head, a scene of Bill&Ted playing their precious guitars very badly shows up.)
Even if the raw processing power was there, I would kind of feel guilty to torture/abuse any modern computer that way.
I can already hear the cooling fans "crying"..

That being said, if these highly accurate emulators would use the GPU shaders to run heavy emulation code, it would be different, maybe.
- GPUs are using some kind of parallel computing (many simple units performing tasks),
so the load is spread evenly across the GPU.

But that's just me, of course. Anyone is free to use what he/she/they feels comfortable with. 🙂

Quick update. Found some remarkable online gallery with fan art related to video game classics.
You can find it here. It's a Japanese site. I've found it while browsing for emulator utilities.

Quick update. I'll try to be on-topic again, soon.
I'll do some more testing with the PC-6000 emulator and also show you that Z80 emulator.
Hope that's okay. Sorry for being a bit too chatty at times, also..

Quick update. Got some games going for the PC-6001 emulator.. Classics like Mappy or Hurry Fox. ^^
Unfortunately, I can use cassette format only so far. Haven't figured out how to read P6 RAM images or load from diskette.

Problem is, there are different BASIC interpreters for each "mode" and I don't know how to use diskette command.
I'll check for the manual or see if I can find anything helpful online..

In the mean time, if you like, please have a look at this article.
It's about getting floppy drive (Gotek) to work.

https://www.leadedsolder.com/2021/05/18/mr-pc … -drive-fix.html

Quick update. I've decided to use OS/2 with ODIN for taking screenshots, to keep the 90s experience intact.

However, I've faced some trouble here. I couldn't get Japanese OS/2 Warp 3 to work properly in Virtual PC.

Also, installing what felt like 30 fix packs (all in Japanese) or so felt like a nightmare. So I gave up on that idea.

Then, I thought about installing Japanese OS/2 Warp 4, with the latest fix packs included.
Installation was no problem, but ODIN failed to launch. Because, the HPFS driver in that OS/2 Warp release didn't work.

But HPFS was needed to access the D:\ partition were ODIN was installed (ODIN wants long filenames so HPFS was needed; C:\ uses FAT).

*sigh* So I'm a bit stuck here. Sorry for the delay.

You could try using your phone with Google Translate to read the Japanese language dialogs.

Kahenraz wrote on 2023-12-17, 10:24:

You could try using your phone with Google Translate to read the Japanese language dialogs.

Thank you, that's a really good idea. ^^

Quick update. I tried to get Japanese versions of OS/2 going with ODIN and the HPFS filesystem.
The latter was needed, because I'm using FAT for the OS/2 boot partition (safer; WinImage can access it too) and HPFS for partition with the ODIN installation.
To my understanding, ODIN and Win32 applications make use of long file names in such a way that FAT isn't enough.

Unfortunately, I didn't manage those things to get along well in the end.
Maybe it's because there are some differences in memory locations between western and eastern OS/2
(ODIN kernal is like a memory hook) that cause incompatibilities, not sure.

I've also tried to get Warp 3 to run ODIN, but those ~60 updates that had to be installed were a bit too much for me.
That nice OCR translator application did work, but was limited to 3 translations a day, unless being registered..

So I went a different route and instead I'm showing you Japanese versions of OS/2 separately.
I hope that's okay.

Quick update. I got Mappy to run via iP6, as promised months ago. Sorry to keep you wainting for so long! 😅
The keyboard input works, too. Use num pad to control Mappy.

Credits/Wallpaper: Lum by unknown artist

Quick Update. Here's also Harry Fox (aka Hurry Fox), another beloved PC-6001 era classic! ^^
Aww, I miss those times when innocent children stories with a slightly saddened undertone made it into a game. 🥹

A second part also exists, by the way. The game's parser recognizes the arrow keys, so you can move around without typing in Japanse.
(Btw, some games also accept English input in the form of E, W, S, N for corresponding directions.)

Credits/Wallpaper: Lum by unknown artist

I hope that's okay for now. I'd really like to try out more things eventually, but I don't have a schedule yet.
I'm confident though, that Windows 3.1+Win32s are capable to run iP6 and other early emulator releases. 😄

What's a bit of a hold back are the limitations of Windows 3 GDI. Unfortunately, big parts of GDI on Windows 3.x platform are in the graphics drivers.
So I don't know if Windows 3.x is the main culprit. Maybe it just needs a more feature complete graphics driver?

Jo22 wrote on 2024-05-15, 16:42:

big parts of GDI on Windows 3.x platform are in the graphics drivers. Maybe it just needs a more feature complete graphics driver

Time to retire that VM and start trying physical graphics cards and their drivers?

elszgensa wrote on 2024-05-15, 16:58:

Jo22 wrote on 2024-05-15, 16:42:

big parts of GDI on Windows 3.x platform are in the graphics drivers. Maybe it just needs a more feature complete graphics driver

Time to retire that VM and start trying physical graphics cards and their drivers?

That's a good idea, actually. I do have a space problem, though, which holds me back so many times.
It doesn't help either that the few Windows 3.1 machines I've got fully assembled are 80286 based. 😅

Still, your idea isn't bad at all. I'll have to try different things, including physical hardware.
Maybe I'll also include weirdos like TIGA boards..

But the big question is what graphics hardware has the best drivers or rather, the most modern GDI implementation.

Hm. Maybe I should also try to install a Japanese edition graphics driver, juyt to be sure it matches Japanese Windows 3.1/Win32s?
- So far, I've used international drivers. Maybe that was a mistake, especially in respect to things like fonts and encoding stuff?

I'm no Win3 driver guru but fwiw I'd probably look at a couple Matrox cards first. They used to be pretty good. As for the language, I'm not sure how the system's GUI's encoding would influence the internals of a driver. I'd expect it to be mostly limited to mojibake in control panels etc, but you never know, maybe it causes a setting to be set wrong because a dropdown menu's contents aren't what's expected or something. Making it all match certainly won't hurt.

Oh, but before that maybe give another VM software a try first; Virtual PC's machines are rather "fixed". I've barely used it but hear PCEMU has a vast array of emulatable hardware to choose from. Since your focus is more on getting the drivers(' features) to run at all and not necessarily on performance or correctness, well, maybe worth spending an hour or two before getting out the bare metal "big guns".