BitWrangler wrote on 2024-04-23, 13:29:

It's got 8MB of XMS you can allocate 4MB of that as EMS and still have 4MB to run everything that's not dog slow on a 386. Hardware EMS and 386es don't play nice. (Anything that sees a 386 and can use EMS assumes EMM386 and crashes if it's a hardware EMS driver)

It probably means nothing, but years ago I've played the 32-Bit game "Lollypop" on a 486DLC (or was it my Pentium 133?) with an installed AST Rampage 286.
As far as I can remember, it behaved normally.

Windows might be different, not sure.
Windows 3.0 Real-Mode kernal is quite EMS friendly.
Windows 3.1 Standard-Mode kernal does tolerate an EMS driver, at least.
Can't remember if that also includes remm.sys driver.

What windows (3.1 and 9x) does NOT tolerate, is an EMS provider that does not support a specific software extension that basically tells it to disable itself so EMM386 can do stuff in protected mode.

There are EMS providers that are NOT EMM386, that work JUST FINE in an abundance of unusual settings (Including NTVDM!!), like EMSMAGIC.

http://www.emsmagic.com/manual/emsmagic.txt

In theory, as long as your driver behaves much the same way, without aliasing, and totally in real mode (no protected mode code), and it properly is able to bow out to EMM386 when windows wants to do fancy shit with it (which is pretty often), then like EMS magic, it will work "Just fine."

ascle wrote on 2024-04-23, 15:19:

if it somehow did i would hope it'd have some RAM we could piggyback on but i doubt it'd have enough to matter...
i noticed the machine technically supports up to 16MB and the RAM chips are just soldered in... been debating on and off if i want to install some sockets and just slot in the max amount of RAM to see if it'd work. the only issue would be sourcing compatible chips. X)

Yep, after a quick look sourcing compatible chips is a non-trivial feat. Although I'll go look through my pile of EDO DRAM on 72pin boards and see if there's something usable there. I'm guessing it'd take a daughter board, though, as I don't recall seeing that SOJ-42 package commonly when EDO DRAM was a thing.

Okay, so upgrade options? More ram? Faster cpu?

Can we cram a blue lightning and 32mb of ram in there?

About memory expansion, I think it really depends on use case.
I think I've way too often told already that my father had a 386DX-40 PC with 16MB of RAM or that I had a 286-12 PC with 4MB of RAM.
Way back in early-mid 90s. But it wasn't for luxury whatsoever.

The programs (Windows programs) we had were memory hungery, simply.
It was even worse on the 286, because Standard-Mode didn't offer any virtual memory.

Try running something like Visual Basic (it simply was popular back then, among all users. Free working models did exist), T-Online or CompuServe Information Manager with 2MB and find out how far you can get.

On Windows 95, which my father had used, the situation was even more deceptive.
Windows 95 seemed to run on 16 MB just fine after a clean boot.
Opening Calculator or Notepad didn't cause any noticeable change, either.
But the more often you open/closed applications the HDD activity got more and more noticeable.

After launching full-fledged applications like Netscape, Visual Basic or Delphi+Interbase the two internal IDE HDDs sounded like a grinder.
Windows 95 apparently had a hard time swapping.

So in retrospect, I wouldn't use Windows 95 with anything less than 32 MB anymore.
It's memory management is somewhat broken. Windows 98/SE is much better here.

But again, it really depends on use case.
Playing SkiFree or Minesweeper on 95 doesn't need more than 8 MB of RAM.

Programming for fun is another matter, though.
Please let me quote myself from an earlier thread :

Jo22 wrote:

For programmers (aka software/hardware developers), which wrote the software that people at home used, it was a bit different, o […]
Show full quote

For programmers (aka software/hardware developers), which wrote the software that people at home used, it was a bit different, of course.
From what I learned from my father's Windows C programming books (1990-1993), the specs were like this (please fasten your seat belts):

Minimum: AT 80386 with 25 MHz, 2 or 4 MB main memory, 80 MB HDD (< 28ms access time), VGA graphics
"Optimum": AT/EISA 80386 with 33 MHz, 4 MB main memory, 120 MB HDD (< 18ms access time), Super VGA graphics
High-end (high comfort): AT/EISA 80486 with 33 or 50 MHz, 8MB of main memory or more, 200 MB SCSI or ESDI HDD (< 18ms access time), Super VGA graphics

In the book, the compilation time of the sample project was being said to be 6 (!) minutes.
The HDDs were the most limiting factor, it seems. Having a RAM drive or a large HDD cache (in HDD or in software) would have made a change.

Edit: The book was written in the Windows 3.x days, of course. Windows 95 on its own has higher requirements, of course.

The whole of the thing is the 6117, CPU, chipset, I/O controllers, all in the one chip. It's a System On a Chip... the chip is the whole system... remove the 6117 and there is very little system left.

So upgrade beyond 386SX40 and 16MB (16MB is possible, supports 4 banks) needs new motherboard, with replacement of CPU, chipset, and I/O functions along with 32bit memory bus if you want a lot of memory.

The 6117 is particularly low power, and almost anything else you could replace it with will give you battery life you can measure with an egg timer, so you'll need to quadruple the battery and charging system capacity.

If you want upgrade-ability in your portable 386 machine, start with a Compaq Portable III or something, or begin with a Pi-Top kit if you wanna do custom boards... because you'll have to strip this out to the bare shell to get faster CPU or more than 16MB. You may be able to design an FPGA core to pin compatibility with the 6117, but although you can get a 468/33 System on a ~$100 FPGA, wasting LUTs to get it to match the 6117 pinout and external breakouts, may mean you need a $300 FPGA, and power consumption is gonna blow the budget again. So back to battery life of minutes. You will also be stuck with a 16MB 16bit memory bus limit with a direct pin 6117 replacement FPGA.

BitWrangler wrote on 2024-04-24, 15:50:

So upgrade beyond 386SX40 and 16MB (16MB is possible, supports 4 banks) needs new motherboard, with replacement of CPU, chipset, and I/O functions along with 32bit memory bus if you want a lot of memory.

I'd agree that's the only reasonable hack for this particular system. To that effect if anyone has a part for a SOJ-42 EDO DRAM (I'll do the work on a non "T" if necessary) that's 2M instead of 1M part number I'll try it out. I can't, for the life of me, find a part number for a 2M SOJ package part. Or any for sale.

Heck, *mostly* pin compatible and needing a daughter-board designed would be fine.

Hello, I am new here. I just got my pocket 386 and my impressions so far:

The screen is only held by 2 screws instead of 4 like the book 8088, so the screen's upper shell is loose because there are no screws to hold it in place.

Mine comes with the right speaker rattling, so I just disconnected the cable and left it in there while waiting for replacement.

I like the new power button, now I can put the thing in bag without having to pull the red cap out 😁

I tried to run some of my apps written in Free Pascal (real mode) and noticed these apps enter infinite loop whenever they try to call int 10h functions. I also tried to run Adlib Tracker II and it has similar issue. The funny thing is that this piece of code:

1asm
2  mov ah,1 ; ah can be whatever, no need to be 1
3  int 10h
4end;

Causes infinite loop if it was built with Free Pascal, but it is fine if this same code was built with Turbo Pascal instead.

So I guess there's a bug in the BIOS?

kagamma wrote on 2024-04-26, 07:12:

Hello, I am new here. I just got my pocket 386 and my impressions so far: […]
Show full quote

Hello, I am new here. I just got my pocket 386 and my impressions so far:

The screen is only held by 2 screws instead of 4 like the book 8088, so the screen's upper shell is loose because there are no screws to hold it in place.

Mine comes with the right speaker rattling, so I just disconnected the cable and left it in there while waiting for replacement.

I like the new power button, now I can put the thing in bag without having to pull the red cap out 😁

I tried to run some of my apps written in Free Pascal (real mode) and noticed these apps enter infinite loop whenever they try to call int 10h functions. I also tried to run Adlib Tracker II and it has similar issue. The funny thing is that this piece of code:

Copy code to clipboard

1asm
2  mov ah,1 ; ah can be whatever, no need to be 1
3  int 10h
4end;

Causes infinite loop if it was built with Free Pascal, but it is fine if this same code was built with Turbo Pascal instead.

So I guess there's a bug in the BIOS?

Perhaps an issue with its VGA chipset?

Does this thing support hercules modes correctly? It might not be 100% vga.

wierd_w wrote on 2024-04-26, 07:58:

Perhaps an issue with its VGA chipset?

Does this thing support hercules modes correctly? It might not be 100% vga.

I don't think so. The app runs normally if I replace all int 10h calls by writing to the VGA registers directly instead: https://github.com/Kagamma/nepper/commit/6852 … a69885517c44f62

Edit: Also other games and apps work fine, only Adlib Tracker II has this issue.

Does loading scitech display doctor fix it?

This thing presumably has a real vintage chipset, so it should detect/use.

It comes with a cirrus logic, although I haven't checked to see exactly which chipset it uses.
I am not familiar with scitech display doctor. I will try it after I come back from vacation.

Edit: I just notice the label outside the shell, so it is CL-GD5428.

Also called UniVBE, Scitech Display Doctor is a universal vesa bios extender for a great many period accurate video chipsets, since it was hit and miss on even having a VESA driver, or having a VESA driver that did not have showstopping bugs (like your apparent INT10h loop bug.)

The makers of the software gifted the software to the world a number of years back, and passed on a free license key file set. Vogons driver archive has a mirror of it.

http://www.vogonsdrivers.com/getfile.php?fileid=346

It basically grabs the INT10h entry vector entry, and the like, away from the hardware supplied one. It's a TSR that supplants any VBE present, or provides VBE services for devices that did not have a VBE bios present (Like ET4000 cards and pals.)

wierd_w wrote on 2024-04-26, 09:55:

Also called UniVBE, Scitech Display Doctor is a universal vesa bios extender for a great many period accurate video chipsets, si […]
Show full quote

Also called UniVBE, Scitech Display Doctor is a universal vesa bios extender for a great many period accurate video chipsets, since it was hit and miss on even having a VESA driver, or having a VESA driver that did not have showstopping bugs (like your apparent INT10h loop bug.)

The makers of the software gifted the software to the world a number of years back, and passed on a free license key file set. Vogons driver archive has a mirror of it.

http://www.vogonsdrivers.com/getfile.php?fileid=346

It basically grabs the INT10h entry vector entry, and the like, away from the hardware supplied one. It's a TSR that supplants any VBE present, or provides VBE services for devices that did not have a VBE bios present (Like ET4000 cards and pals.)

It's great, *if* it works. My experience wasn't that great so far.

UNIVBE 4.0 and old hardware

Edit: That being said, it's worth a try. Maybe it will fix int10h issues as a side effect. 🙂👍

Still prefer the original TSRs, though, if available.
I say "available", because technically speaking, most ISA VGAs did have VBE drivers and utilities - on the supplied diskettes.

For some reason, though, users seemingly didn't have access to them. Or didn't care, thought they were unnecessary on DOS etc.

Maybe they bought their first VGA card as bulk ware, by some shady seller, maybe got it by "a friend". Without any software, of course. I don't know. 🤷‍♂️

Edit: I almost forgot. It's also possible to install a RAM-based version of VGA BIOS. It worked for me, at least.
Fixing a VGA issue in Qemu 0.9 (&Kqemu)

Anyone know why NT 3.51 might have a hard time booting on this thing? It's not the low RAM -- I have it booting with 8MB in VirtualBox. On the Pocket386 it hangs after changing text resolution during "OS Loader v3.51........." but before the blue boot screen, with the text cut off at the top. Chipset issue?

It very well could be the same int10h issue being discussed.

Int10h is invoked to tell the graphics card to switch modes, based on a value stored in register ah.

In the 'for realz, THIS is causing a loop! da fuq!?' Example cited, the code is basically saying 'put the value 01 into register ah, call int10'.

In that example, '01' refers to entering a freaking TEXT mode.

If nt3.5 is calling int10, and going into an infinite loop, it would 'hang' after trying to change the screen mode.

ah = 1 is not even about change video mode. It is simply changes the cursor shape.

In case of my apps, they are calling ah = 2 to move the cursor around, and this is also causing the loop bug.

wierd_w wrote on 2024-04-26, 07:58:

kagamma wrote on 2024-04-26, 07:12:

Hello, I am new here. I just got my pocket 386 and my impressions so far: […]
Show full quote

Hello, I am new here. I just got my pocket 386 and my impressions so far:

The screen is only held by 2 screws instead of 4 like the book 8088, so the screen's upper shell is loose because there are no screws to hold it in place.

Mine comes with the right speaker rattling, so I just disconnected the cable and left it in there while waiting for replacement.

I like the new power button, now I can put the thing in bag without having to pull the red cap out 😁

I tried to run some of my apps written in Free Pascal (real mode) and noticed these apps enter infinite loop whenever they try to call int 10h functions. I also tried to run Adlib Tracker II and it has similar issue. The funny thing is that this piece of code:

Copy code to clipboard

1asm
2  mov ah,1 ; ah can be whatever, no need to be 1
3  int 10h
4end;

Causes infinite loop if it was built with Free Pascal, but it is fine if this same code was built with Turbo Pascal instead.

So I guess there's a bug in the BIOS?

Perhaps an issue with its VGA chipset?

Does this thing support hercules modes correctly? It might not be 100% vga.

Mine arrived with the Cirrus Logic GD5429, there were other chipsets specified as possible, I guess depending on supply. But I'd expect mine is going to have all the abilities and quirks of the 5429, which when I have ran one in the past, I don't remember any bad quirks.

I've got hardly any hours on it so far though, it's been a horrible week for getting the opportunity to play with it.

Jo22 wrote on 2024-04-26, 10:05:

For some reason, though, users seemingly didn't have access to them. Or didn't care, thought they were unnecessary on DOS etc. […]
Show full quote

For some reason, though, users seemingly didn't have access to them. Or didn't care, thought they were unnecessary on DOS etc.

Maybe they bought their first VGA card as bulk ware, by some shady seller, maybe got it by "a friend". Without any software, of course. I don't know. 🤷‍♂️

Edit: I almost forgot. It's also possible to install a RAM-based version of VGA BIOS. It worked for me, at least.
Fixing a VGA issue in Qemu 0.9 (&Kqemu)

That was the case for me circa the mid 90s. Typically the hardware was second or third hand... there certainly weren't floppy disks included or a friendly sales rep. Sometimes the manufacturer was gone.

If it worked okay that was about as good as I was getting. Drivers were only sought if something didn't work.

There was a bit of a time lag between VBE 2.0 being useful from about '96ish and the VGA chipsets most ppl had being from about 1994ish apart from newest ones that had VBE 2.0 in BIOS. So there were cards and install disks created before VBE 2.0 was a thing or worth worrying about, that continued to be cranked out. Getting updated files was another matter, many manufacturers still had stuff only on dial in BBS, or had compuserve and prodigy support operations, didn't get everything on FTP when they went to internet, or had it on Website that didn't get archived before being slashed and burned for a new version. It's like thinking it proves the US Army shot JFK because they had guns and ammo.