Scali wrote:

I explained how: by running Falcon 3.0. It was especially obvious with the animations it played. With real EMS, it would just st […]
Show full quote

georgel wrote:

No way. How did you measure that EMS performance?

I explained how: by running Falcon 3.0.
It was especially obvious with the animations it played.
With real EMS, it would just store each frame in a separate EMS frame, and copy the data to VRAM.
When using EMM386, it would have to copy the memory from XMS into the EMS frame first, and then the additional copy to VRAM.
That overhead completely messed up the animation playback, turning it into a slideshow.

Sure, throw enough horsepower at it, and even with EMM386 it works again... but a 386SX-16 was not enough horsepower, ergo performance penalty was far from 0.

Have you debugged that game? No. I am not sure you figured out why EMM386 slowed it down but I do think it was not EMS related. Try QEMM386 by the way. What you explain now means that you don't know how memory mapping works -- no copy is needed between XMS & EMS they share one pool with 386 memory managers if configured correctly. The game most likely utilizes EMS and not XMS at all.

georgel wrote:

Have you debugged that game? No. I am not sure you figured out why EMM386 slowed it down but I do think it was not an EMS related.

Oh for crying out loud.
Have you run the game on a 386SX-16 with NEAT chipset?
No? Then shut up.
It was EMM386, because that is the test I did:
Run the game with EMM386 to provide EMS.
Then re-run the game with the NEAT LIM-EMS driver to provide EMS.

It is an established FACT that the game ran much slower with EMM386. I don't need to debug the game for that.
The only thing that changed was software vs hardware EMS. Ergo, that is the root cause of the performance difference.

georgel wrote:

What you explain now means that you don't know how memory mapping works- - no copy is needed between XMS & EMS they share one pool with 386 memory managers if configured correctly. The game either utilizes EMS or XMS.

Yea, whatever.
You think you're the shit, don't you?
I know the difference between memory mapping and copying. I don't think anyone would doubt that.

Basically you are arguing from the assumption that EMS emulation in software is free, when it is clearly not. EMM386 has to set up a v86 environment and virtualize various parts of the system. Even if everything else is 100% perfectly optimized, a 386SX-16 that virtualization overhead alone will be significant.
Not sure why you're trying to argue otherwise, because it clearly doesn't make sense to do so. But you've argued nonsense before, so hey. In a very annoying and pedantic matter I might add.

Scali, you are spreading rumors without analyzing the game at all. This is lie and it is written by you because it exists only in your semi-educated fantasy:

Scali wrote:

When using EMM386, it would have to copy the memory from XMS into the EMS frame first, and then the additional copy to VRAM.

How many FPS with 386 manager and without it did you get with Falcon 3.0 on 386 16 MHz. With what onboard cache if any? I will do the tests within 24hrs!

georgel wrote:

Scali, you are spreading rumors without analyzing the game at all. This is lie and it is written by you because it exists only in your semi-educated fantasy:

Yea whatever.
You're the one spreading lies here, about

georgel wrote:

and performance penalty is practically near 0.

georgel wrote:

He could have verified his doubtful theory before producing untested and "complicated" ROM shadowing card on some of the widespread motherboards that have such ROM shadowing support built-in into their chipsets and controlled via their CMOS Setups.

Scali wrote:

Yea, whatever.
You think you're the shit, don't you?

he really does, and I'm sick of his shit

my "doubtful" theory was carefully derived and tested, with the help of several posters in this thread (not georgel)

Caluser2000 wrote:

I can allocate EMS from my 286s bios.

neat

maxtherabbit wrote:

Caluser2000 wrote:

I can allocate EMS from my 286s bios.

neat

I see what you did there 😀

I always would prefer Hardware EMS on a slow Machine.

Jo22 wrote:

...

There is no such thing as "Real" EMS. The LIM EMS standard is software only, hence why some EMS boards are incompatible with others, despite having the same function overall.

I never claimed that EMS was for 386+, I didn't even bring up EMM386.

EMS memory was primarily designed to add more memory to 8088 / 8086 machines with limited address space and was designed to allow businesses to load much larger documents in programs like Lotus 1-2-3 (hence Lotus-Intel-Microsoft) and dBase III.

It's use in games did not come until much later, and by that point complex games capable of using EMS also (for the most part) supported XMS and faster processors. Finding a game that will run well on an 8088 that requires more than 640K is damn near impossible - It's almost all business software and Windows.

I agree that EMS can be useful, but what's the issue with using a standard EMS board? They're easy to find and you can still get the memory chips brand new for cheap. I got a BocaRAM XT for $30 in box, I don't understand why you would want to produce a new version, which will cost more and likely have to be assembled. It seems like a waste of time.

Not to mention, many 286 boards and even some 8088 / 8086 boards are capable of using EMS on the motherboard.

It was discussed in another thread the possibility of a "max everything" card to provide the full 32MB of EMS and 16MB of XMS on one board. I think this would be much more preferred.

FAMICOMASTER wrote:

There is no such thing as "Real" EMS. The LIM EMS standard is software only, hence why some EMS boards are incompatible with others, despite having the same function overall.

Disagree. While you are 100% technically correct, the spirit of EMS as it was originally implemented (hence the "real"), was in hardware.

FAMICOMASTER wrote:

I agree that EMS can be useful, but what's the issue with using a standard EMS board? They're easy to find and you can still get the memory chips brand new for cheap. I got a BocaRAM XT for $30 in box, I don't understand why you would want to produce a new version, which will cost more and likely have to be assembled. It seems like a waste of time.

I think you maybe misunderstanding what I'm doing here - I am using a standard EMS board, the AST RAMpage+ 286. The ISA card that I designed is simply an Option ROM board with 16-bit support.

Doesn't the AST RAMPage 286 support 16 bit access through the SuperPak software?

If you're installing option ROMs, do most motherboards of this era not have option ROM sockets on the board? Why not install it on a network card or other device with a socket?

FAMICOMASTER wrote:

Doesn't the AST RAMPage 286 support 16 bit access through the SuperPak software?

If you're installing option ROMs, do most motherboards of this era not have option ROM sockets on the board? Why not install it on a network card or other device with a socket?

Its all been explained bro, just go back and read the thread its too complicated to BLUF

Well it's finally over. SCSI and EMS coexisting. 16-bit ROM access. Zero wait AST rampage.

I'm still ironing out some logic issues on my card design with respect to the use of SBHE# and MEMCS16# that prevent it from being used as a truly general purpose tool like I originally intended.

BUT I got it working well enough to solve this problem at least. What I ended up doing was assembling the card with only one EPROM (containing the odd bytes of the SCSI BIOS) and the 688 address decoder. I jumpered the card to C800 (same as the SCSI card) and connected CE# on the ROM to the P=Q# output on the 688. OE# on the ROM is driven by SMEMR# from the ISA bus. SA[13:1] on the ISA bus go to A[12:0] on the ROM. This way when the system boots, the Adaptec card's onboard ROM BIOS IC functions as normal with 8-bit transfers. All the while my card is serving the odd address bytes on D[15:8], which go ignored by the system board in 8-bit transfer mode. Then when the AST driver kicks in and forces the C/D segments of UMA to 16-bit mode, the Adaptec's ROM BIOS continues to be responsible for serving the even bytes of the ROM on D[7:0] while my card serves the odd bytes on D[15:8]

So, georgel, my theory was 100% correct. Thanks for doubting me and being a nuisance generally, it really motivated me to continue with this project to spite you

The final solution is pretty nice still, congrats ~

maxtherabbit wrote:

Well it's finally over. SCSI and EMS coexisting. 16-bit ROM access. Zero wait AST rampage. […]
Show full quote

Well it's finally over. SCSI and EMS coexisting. 16-bit ROM access. Zero wait AST rampage.

I'm still ironing out some logic issues on my card design with respect to the use of SBHE# and MEMCS16# that prevent it from being used as a truly general purpose tool like I originally intended.

BUT I got it working well enough to solve this problem at least. What I ended up doing was assembling the card with only one EPROM (containing the odd bytes of the SCSI BIOS) and the 688 address decoder. I jumpered the card to C800 (same as the SCSI card) and connected CE# on the ROM to the P=Q# output on the 688. OE# on the ROM is driven by SMEMR# from the ISA bus. SA[13:1] on the ISA bus go to A[12:0] on the ROM. This way when the system boots, the Adaptec card's onboard ROM BIOS IC functions as normal with 8-bit transfers. All the while my card is serving the odd address bytes on D[15:8], which go ignored by the system board in 8-bit transfer mode. Then when the AST driver kicks in and forces the C/D segments of UMA to 16-bit mode, the Adaptec's ROM BIOS continues to be responsible for serving the even bytes of the ROM on D[7:0] while my card serves the odd bytes on D[15:8]

So, georgel, my theory was 100% correct. Thanks for doubting me and being a nuisance generally, it really motivated me to continue with this project to spite you

How can we be sure that this setup is working at all? The doubt was much more in your not so wise course taken to deal with the problem. The most useless card in the world you have built which is still buggy. If I start showing every step of my projects and building PCBs I would flood the forums. In vcfed you are mentioning about problems with many chipsets, etc. The theory could have been verified on almost any 386/486 motherboard which setup allowed shadowing of ROM regions, with 0 programming and 0 waste of PCB resources.

georgel wrote:

How can we be sure that this setup is working at all?

I guess you can't. But there's one thing you can be sure of, no one likes you

maxtherabbit wrote:

I guess you can't. But there's one thing you can be sure of, no one likes you

Don't speak on behalf of everybody. Your certainty is a cause of very high error rate and bad productivity of yours. Next time use a universal PCB for your useless projects, this at least will shorten your trial and error cycles by months.

georgel wrote:

maxtherabbit wrote:

I guess you can't. But there's one thing you can be sure of, no one likes you

Don't speak on behalf of everybody. Your certainty is a cause of very high error rate and bad productivity of yours. Next time use a universal PCB for your useless projects, this at least will shorten your trial and error cycles by months.

ok sigmund fraud you've analyzed me so well

It cost me $23.70US to get five prototype PCBs made from JLCPCB, that included beveling the card edge and ENIG plating. I know ENIG is not suitable for a production run of edge connectors, but I wasn't going to pay for hard gold for a test and wanted something better than HASL.

Find me an ISA prototyping card on ebay for less than $23.70 shipped, oh wait you can't. So let's break down what I got for my massive waste of $23.70 in resources:

1) I solved the original problem. The goal here was never to prove theories, it was to get a bus mastering SCSI HBA and hardware EMS card to coexist peacefully in the same machine, a machine that lacks any support of shadow RAM. That is now a reality. Believe it or not.

2) I have 4 extra PCBs left over that will function as 8-bit ROM cards providing up to 64kB in option ROM space with no additional modification in any 8-bit slot. This matches the performance of the closest similar device on the market, the Lo Tech ROM card whose PCB alone sells for $9.99 + shipping. And I have 4 of them, a $39.96 value! The BOM costs would be similar, and my design uses JEDEC standard EPROMs instead of flash memory (which could be viewed as a feature or anti-feature depending on your perspective).

3) I have learned, and am continuing to learn the vagaries of 16-bit ISA signalling. And now I'm able to help another VCFED user attempt to design his own 16-bit card.

4) Because I participated in science, I now have the data to properly revise the design to meet the original goals of a universal 8/16bit ROM card. This has been done.

I was never "certain" that my 16-bit ISA logic was correct, I produced a prototype after consulting the available documentation and a peer review. Turns out I made some mistakes, but it was still close enough to be bodged into solving the problem. I was however certain of the cause of the SCSI/EMS incompatibility (thanks again to kjliew, bakemono, Matth79 and Scali for their assistance in deriving that fact) and my certainty was borne out by reality.