Indeed a lot can be done, it depends on your skill and will. There is an entire demo scene which can hint you into what is realistically achievable with the hardware config of the Pocket 8086, and there is also a large vintage library of commercial games that were released back in the day, some of which are great examples.

Just settle for a minimal hardware target with one or two variations and start coding.

I would go for 8088 @ 4.77Mhz on CGA and VGA as an option. I would also consider 512 KB of memory, and OPL3 with PC internal speaker (PSG) as another option. Target should be an XT (not AT) type computer.

Good luck!

Yes, I have tried one of the demo scene programs on the Pocket 8086 (8088 Domination). It didn't work. The graphics were all corrupted. I guess it must make certain assumptions on timing or hardware characteristics of original hardware.

I have also tried quite a few games now, with varying degrees of success. So, I think I have a feel for what it can and can't do.

As for my skills, I'd say I am currently rusty with game dev but eager to learn. I did write games for my own amusement 25yrs ago (in C or QBASIC for PC and earlier in BBC BASIC for the BBC Micro) and also did some Assembly programming (though not on x86).

My day job is in software development. But not game dev. I got the Pocket 8086 with the intention of using it to learn x86 assembly on one of the most basic PCs. To really understand how it works. Writing a game seems like a fun way to learn...

The developers of the demo didn't add support for timings of the V20 processor, that's why it fails.
V20 is more efficient than i8088. Same goes for RAM speeds, it has to be slow DRAM (SRAM is faster).

The demo must be run on an 99.99% IBM PC 5150 compatible hardware.
That's why most PC/XT emulators can't run it properly, either.

Because if the hardware is just a tiny bit too good, then it will fail.
The demo couldn't have worked on an IBM PC/XT 286 or Amstrad PC1512/PC1640, either.

Edit: Oh. I just realized it's old 8088 Domination rather than Area 5150.
Well, 8088 Domination might be run on faster PCs. Are you sure you got the right version?
https://www.youtube.com/watch?v=WKgu6EyMu4s

I had the Book 8088 and got rid of it.
I couldn't stand the aspect ratio nor the glare of the screen, plus text on it was too small. I wouldn't recommend it for text-based work (like programming).
It had a V20 and VGA and OPL3. Also, forget about demos that target CGA timing trickery as the VGA chip is not register-compatible with CGA.

I add my voice to the suggestion of text-mode char-redefine demo/games on this device. It seems most suitable. You can also add OPL3 music as long as it doesn't need veey fast changes and the data processing is minimal.

Good point. 🙂👍

The funny thing is, though, that we tend to think i8088 PC=CGA/Text graphics, whereas the i8086 (8086-2) was the heart of the NEC PC-9801 from early 80s.
An Japanese office PC with 640x400 hi-res graphics in 8 colours (fixed) or 16 colours (16c out of 4096c; slightly later models with more video RAM).

Edit: The OPL3 is fine for listening to music made in AdlibTracker.
There's a player application, too, which might work with 16-Bit CPUs and OPL2/3.

wbahnassi wrote on 2024-12-16, 20:39:

I had the Book 8088 and got rid of it. I couldn't stand the aspect ratio nor the glare of the screen, plus text on it was too sm […]
Show full quote

I had the Book 8088 and got rid of it.
I couldn't stand the aspect ratio nor the glare of the screen, plus text on it was too small. I wouldn't recommend it for text-based work (like programming).
It had a V20 and VGA and OPL3. Also, forget about demos that target CGA timing trickery as the VGA chip is not register-compatible with CGA.

I add my voice to the suggestion of text-mode char-redefine demo/games on this device. It seems most suitable. You can also add OPL3 music as long as it doesn't need veey fast changes and the data processing is minimal.

I believe the Book 8088 had a terrible screen compared to the one on the Pocket 8086. To me, the screen is quite clear. Though I don't intend to do development using the onboard screen / keyboard. I will either use a more modern machine, and transfer the compiled files over for testing, or I will just use the Pocket 8086 connected to PS/2 keyboard and CRT.

I have purchased a few books on x86 assembly. I will try to learn the basics of assembly and experiment with what I can do with regards to graphics / sound. I also have a copy of Borland C++ complete with manuals (with support for C). I'm thinking that I will write most logic in C and do the timing critical stuff in assembly. Unless, someone would advise me against this of course. I will probably do some comparisons of performance between C and asm just to be sure I won't lose too much performance. My assumption is that for the game logic, the compiler will probably do a better job at making optimal code than I will if I were to try to do it in assembly. I am aware that Planet X3 was written 100% in assembly language. Do people think that gained much performance?

Jo22 wrote on 2024-12-16, 20:09:

The developers of the demo didn't add support for timings of the V20 processor, that's why it fails. V20 is more efficient than […]
Show full quote

The developers of the demo didn't add support for timings of the V20 processor, that's why it fails.
V20 is more efficient than i8088. Same goes for RAM speeds, it has to be slow DRAM (SRAM is faster).

The demo must be run on an 99.99% IBM PC 5150 compatible hardware.
That's why most PC/XT emulators can't run it properly, either.

Because if the hardware is just a tiny bit too good, then it will fail.
The demo couldn't have worked on an IBM PC/XT 286 or Amstrad PC1512/PC1640, either.

Edit: Oh. I just realized it's old 8088 Domination rather than Area 5150.
Well, 8088 Domination might be run on faster PCs. Are you sure you got the right version?
https://www.youtube.com/watch?v=WKgu6EyMu4s

Sorry, just checked the USB drive I used. It was Area 5150 that I tried on it. Not 8088 Domination.

My Pocket 8086 currently has an AMD 8088 8Mhz CPU in it. I ran the Area 5150 demo at 4.77Mhz.

C for high-level logic and non time-critical code should be fine. I doubt XT software were written at all in C, but who cares 😅

For fun yeah, though people are changing up their devices to suit their tastes/needs and there are several video chips. So it's not really a super locked down platform. I would imagine whichever specific configs it targets there may be a dozen enthusiastic and grateful users. For profit, doubt it will make anything but a couple of pity payments.

Unless you knock out something with high cross demographic appeal first go, like Angry Birds, you are certain to be appealing to a niche of a niche, so while there may be millions of people who would have liked your thing, few of them might have a Pocket 8086 so you can't expect every owner on the planet to be beating a path to your doorstep as the saying goes if you invent a "better mousetrap".

wbahnassi wrote on 2024-12-16, 22:02:

C for high-level logic and non time-critical code should be fine. I doubt XT software were written at all in C, but who cares 😅

Turbo Pascal for the win! 😁

wbahnassi wrote on 2024-12-16, 22:02:

C for high-level logic and non time-critical code should be fine. I doubt XT software were written at all in C, but who cares 😅

Whilst it would certainly be an interesting challenge to do a complex game 100% in ASM, that will drastically increase the development time. Having said that though, at least initially, I probably will try to do a simple game to learn the ropes. Maybe something like bouncing babies. I may well do that 100% in ASM and then again in C and compare performance.

One game I would love to have on my Pocket 8086 is Chuckie Egg. But not like the 1989 DOS port. I mean one that looks and sounds as close to the BBC Micro version as possible. That was my childhood favourite game. I suspect that might be a bit too much for the 4.77Mhz 8088 with EGA/VGA. But maybe I'm wrong.

x86 isn't really a great platform to do 100% assembly on, but it is certainly better to work with than some 8bit CPU like Z80 or 6502.

One big thing you can do in assembly that compilers don't easily let you is manage very precisely how you use data within the code so that you can use shorter instructions and variety of tricks with data alignment, and get really space efficient program as a result. That leaves more space for assets that otherwise would not fit, although perhaps not dramatically so. I can tell that the new software for my YMF71x card is currently 17KB in size (100% assembly) and does almost all the stuff the old software did which was a 120KB monster EXE written in QuickBASIC 4.5. I'm sure C version would be much smaller but I'm sure it will not beat the assembly one as far as size goes.

Tiido wrote on 2024-12-17, 08:51:

x86 isn't really a great platform to do 100% assembly on, but it is certainly better to work with than some 8bit CPU like Z80 or 6502.

One big thing you can do in assembly that compilers don't easily let you is manage very precisely how you use data within the code so that you can use shorter instructions and variety of tricks with data alignment, and get really space efficient program as a result. That leaves more space for assets that otherwise would not fit, although perhaps not dramatically so. I can tell that the new software for my YMF71x card is currently 17KB in size (100% assembly) and does almost all the stuff the old software did which was a 120KB monster EXE written in QuickBASIC 4.5. I'm sure C version would be much smaller but I'm sure it will not beat the assembly one as far as size goes.

Yes, that makes sense. Though I think the CPU performance will be more of an issue than the amount of memory. 640k RAM is 20x more than the BBC Micro had for example. So if I'm looking to create a game something like Chuckie Egg, I'd think the assets shouldn't take much space.

RetroPCCupboard wrote on 2024-12-17, 11:26:

Tiido wrote on 2024-12-17, 08:51:

x86 isn't really a great platform to do 100% assembly on, but it is certainly better to work with than some 8bit CPU like Z80 or 6502.

One big thing you can do in assembly that compilers don't easily let you is manage very precisely how you use data within the code so that you can use shorter instructions and variety of tricks with data alignment, and get really space efficient program as a result. That leaves more space for assets that otherwise would not fit, although perhaps not dramatically so. I can tell that the new software for my YMF71x card is currently 17KB in size (100% assembly) and does almost all the stuff the old software did which was a 120KB monster EXE written in QuickBASIC 4.5. I'm sure C version would be much smaller but I'm sure it will not beat the assembly one as far as size goes.

Yes, that makes sense. Though I think the CPU performance will be more of an issue than the amount of memory. 640k RAM is 20x more than the BBC Micro had for example. So if I'm looking to create a game something like Chuckie Egg, I'd think the assets shouldn't take much space.

That reminds me of SymbOS that runs on certain Z80 machines.
It can multitask quite a few applications and supports a few megabytes of RAM via bank-switching.
Even has a CPU and RAM gauge in the upper right, so system load can be seen.
I still wonder if the system could be modified to run via "8080 emulation mode" on an IBM PC with NEC V20/V30.