Oh Wow...,
I played the C64 version.
[url=http://en.wikipedia.org/wiki/The_Seven_Cities_of_Gold_(video_game]http://en.wikipedia.org/wiki/The_Seven_Cities_of_Gold_(video_game[/url])
Didn't know, there was a remake for the PC.

Instabuy!

Oh, and since someone mentioned "Jumpman" - that would be an instabuy, too! ;o)

Me thinks you're forgetting that even though the game doesn't use DOS, that doesn't mean it doesn't use BIOS. And I'd be pretty surprised if DOSBox doesn't emulate standard BIOS calls like INT 13h which allows arbitrary access to disk sectors. In fact...

Grab the source (because they have no docs I can find), then check out the file src/ints/bios_disk.cpp. You can see it hooking its emulation into the int 13h slot in the interrupt table when it does "RealSetVec(0x13,CALLBACK_RealPointer(call_int13))" in the 'BIOS_SetupDisks' method. If you follow the 'CALLBACK_Setup' call in the previous line into src/cpu/callback.cpp where it invokes 'CALLBACK_SetupExtra' you'll see DOSBox does its own machine-code generation in order to create an interrupt handler wrapper around their C-code implementation (the 'INT13_DiskHandler' method back in bios_disk.cpp). DOSBox only implements the most common int 13h functions (presumably the ones they've actually ran into) and logs ("INT13: Function %x called on drive %x (dos drive %d)") if a program tries to use an int 13h function DOSBox doesn't implement.

So, while it's certainly possible for a PC game to not work on DOSBox, your particular example (reading raw disk data in arbitrary patterns) wouldn't cause any problem.

"Seven Cities of Gold" was my best selling game. It garnered a SPA Gold Disk and a number of minor awards. It was also my first game that didn't allow for more than one player. It was planned to be multi-player but during during development it lost that aspect, along with colonists and development. To keep it's focus (and allow for a really large world) it ended up just covering the early exploration and conquest of the new world. It was published in '84 by Electronic Arts and it was the game Trip Hawkins (founder of EA) coined the term "edu-tainment" to describe on the press tour introducing it. (Back then the term wasn't the kiss of death it is now).
There are several things I'm proud of about that game. Unlike most strategy-adventure games then (and now as well) which load the player with numerous economic and logistical decisions, it only used four commodities to model the constraints and opportunities facing the Conquistadors (men, food, {trade} goods and gold). I also like the way I was able to reflect the unique interactions between natives and Conquistadors when they shared neither a language nor cultural values in common. I came up with a simple arcade element which also included a number of subtle "secret" opportunities that I was quite gratified to learn that folks found on their own. Finally, the fact that our "New World" was randomly generated (and so large it required disk caching and overlays) made exploring a challenge fraught with peril and surprises. It sufficiently captured the sense of panic that comes from being lost in the wilderness and running out of supplies as well as the joy of rescue (which was something I experienced once backpacking and wanted to make a touchstone of this design).
Our biggest frustration with this product was that it was developed in the days when you had to write a number of different versions since no platform was pre-eminent. There were Atari 800, C64, Apple, Mac and IBM PC versions of the game put out but the only "full" version was on the Atari. On the others we did the best we could with what we had.
- Dan Bunten (source)

So, all you folks talking about how great the game was on the C64 haven't even seen the full version yet! (I'm assuming the remake is the full version and then some. Can anyone verify that whatever was left out of the original IBM PC version was put back in in the remake?)

Nice writeup find JadedOne!

It's worth mentioning that in contrast to the fun to play game as Columbus, in real life he was a monster - to try to pay for his costs, he wanted gold, and enslaved the native population - a million people if I recall - and treated them brutally, where 99% of the population was killed within years. It was a culture where incidents like two twelve year old boys with a parrot were killed to take the parrot, where the natives committed suicide over the horrible situation.

We should not whitewash the truth to the point people don't know it, while enjoying the fun of the game based on it.

One thing that really told me the story was how when Columbus first reached land, and the natives according to his own diary swam out to meet him very friendly, the very first day he himself writes how he had his soldiers show them metal sword to see their reaction to see if they had any such weapons, and estimated how many men he would need to enslave all the natives. Not the stuff of the romantic adventure we'd like to think.

Feel proud, IAmSinistar. You successfully revived a classic and gave it a second chance!

I wonder if it would be possible to add the C64 game to the package, pre-setup in VICE?

I had loads of fun playing this during the mid 80s on my Commodore 64. My favorite part was paralyzing the nearby indigenous people by flashing some jewelry, as the glittering gold was supposed to dazzle the primitive savages. Never played the PC version; I hope it's comparable to the mighty C-64 one!

Thank you for the writeup. So, if an OS uses a "Read" function that is different from DOS' one, DOSBox would handle it properly because it would use the OS' one instead of DOS' one? Or would it not use the OS' different code because it would ignore the OS' part?
And if it doesn't ignore the OS part, does that mean you can use DOSBox to boot Linux?

Such a great classic release... thanks everyone involved!

An OS is a different beast than a bootable game. A bootable game is most likely not going to invest the effort in writing device drivers for a multitude of disk controllers -- it's just too great a task for the context of one game, and disk performance is not a critical factor for games. (Even just writing to the ATA spec is a pain from what I've seen, and a lot of DOS games predate any sort of standardization on the software interface for ATA.) Because that's the case, a bootable game is likely to use disk functionality which is readily available -- and on (pre-UEFI era) IBM PC compatibles that means BIOS int 13h functions. An OS, on the other hand, generally does come with its own device drivers for disk controllers. (I may seem to contradict that later, but if you consider DOS not a real OS there's no contradiction.) While an OS will make use of BIOS (or EFI) during the initial part of its boot process, at some point during boot it will have (via BIOS/EFI disk functions) loaded its own drivers and the OS will then switch over to using its own device drivers and cease making any calls to BIOS.

Could you boot Linux in DOSBox (assuming there's a 16 bit real-mode x86 version of Linux around)? In theory, if it used a disk "driver" that solely relied on BIOS int 13h, yes. If it uses a disk driver that (as normal disk drivers tend to do) talks directly to the disk controller hardware (e.g., using the ATA/SATA software protocol), then no -- as far as I can tell DOSBox has zero code for emulating ATA (or any other) disk controller hardware.

For other (non-disk) device drivers the story is different. E.g., writing bare-metal code for an IBM PC serial port is rather trivial (due to the simple and mostly standardized UART hardware interface), so a DOS game using the serial port is quite likely going to access it directly -- subsequently DOSBox does have serial hardware emulation. Hardware timers and timer-interrupts are also fairly easy to use directly, and DOSBox emulates those as well (src/hardware/pic.cpp). Ditto for the keyboard. And tons of DOS games directly access video and sound hardware, so of course DOSBox emulates those as well. (I also see DOSBox emulation support for joystick, dma and cmos {real time clock}.) For some of these (keyboard, video, maybe some others) DOSBox supports both direct access and BIOS access of the device. (Some need both -- IIRC vesa requires BIOS int 10h calls to query and set modes, but you have direct access to the actual video buffer memory, or at least a selected "window" of said memory. It's been a long time since I've written any vesa code.)

I think you might be confusing file system with disk driver -- these are two completely distinct things in most operating systems. I believe DOS (or at least earlier versions of it) did not come with its own disk driver. DOS itself used BIOS 13h for accessing the disk. (Note that DOS was Microsoft code while BIOS was IBM code.) DOS did however come with an implementation of the FAT file system -- BIOS knew nothing about FAT. (You can think of DOS as being built on top of BIOS, and the FAT file system being built on top of BIOS 13h functions.) So when you say ""Read" function that is different from DOS" I wonder which read you are talking about -- are you talking about a file read (which requires a file system by definition) or are you talking about a raw disk read (which does not directly involve a file system, even if it is used to read data normally managed by a file system and/or might be issued on a file system's behalf)?

DOSBox will never "use the OS' one" (assuming the OS isn't playing tricks like modifying the software interrupt table). If the OS tries to read using BIOS 13h functions, then DOSBox will try to fulfill that read request. If the OS tries to read using direct access to disk controller hardware, DOSBox will balk. (I assume DOSBox will log or otherwise make a note of an unknown/unsupported memory or I/O address being accessed in that case.)

I'm not sure how familiar you are with how computers work, but when something happens like "an OS uses a read function", there are specifics that go with that -- exactly how did the OS try to do the read? E.g., OS code invokes interrupt 13h with such-and-such arguments vs. OS code calls subroutine at address @xxxx which is part of the OS'es disk driver code vs. OS pokes at a given IO address where it expects SATA hardware to reside. I can't tell you what happens when "an OS uses a read function" unless I know some of those details. As hopefully one can surmise at this point, "OS code invokes interrupt 13h" should work (as long as the arguments indicate one of the common disk functions that DOSBox implements), whereas the "OS pokes at a given IO address" case isn't going to work with DOSBox.

Can't even get an opening credit for that now a days...:)

I should clarify the above. What I meant is that if the OS asks DOSBox to do a disk read via int 13h, DOSBox will not turn around and use any of that OS'es code to do that read. Instead DOSBox is going to use the host environment to do the read. (E.g., if you were running Linux in DOSBox while running DOSBox on Windows, if Linux did an int 13h disk read DOSBox would turn around and use a windows function to emulate the disk read).

If the OS is invoking "read file", that would be the OS invoking a call on its own file system. DOSBox won't even "see" that call. (Technically DOSBox sees all since it's emulating the processor, but it won't interfere with that call in any way, and it will have no idea that this is a "read file" call.) Likewise if the OS is invoking "read raw disk" on its own disk driver, DOSBox won't interfere with that call (and won't know that it's a "read raw disk" call). You don't get an interaction between the OS code and DOSBox until the OS disk driver code tries to initiate the actual raw disk access, either by invoking int 13h or via direct memory/IO accesses. The former will work while the latter will not.

Thank you for the clarification. I was considering mostly a case where the PC Booter would direct reads to specific disk tracks, depending on what file was called instead of what the file allocation table said, in which case DOSBox would still read those specific tracks, at least if I understood you correctly.
While I do have quite a bit of computer experience, I never really dallied with the BIOS part of the code, nor with direct memory access, so thank you for taking the time to explain those to me.

Similar in concept, obviously with old graphics and a little less variety. Still a very fun game...games play shorter/quicker and it is very replayable.