Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Cas

Pages: [1] 2 3 ... 18
Stunts Related Programs / Re: [idea] Replay auto-upload
« on: February 18, 2019, 11:22:38 PM »
I figure this could even grow to become a non-web client and a Stunts community protocol. In the meantime, an area on the website where you could "drop" the replay file could be fast enough; at least, much faster than what we've been doing so far, I guess.

I have more ideas regarding this "protocol", but I think they are out of scope in this thread. I'll write about it separately.

General Chat - ZSC / DOS and DOSBox memory systems and Stunts
« on: February 10, 2019, 01:19:44 AM »
As I was saying in the shoutbox, I'll post some things I know about how things work in a real DOS PC and how similar or not they could be in DOSBox, particularly as it could affect Stunts. Most of this is just for curiousity, but maybe there's a use for it. Feel free to comment or correct me if I'm wrong.

Memory system
The first versions of DOS were created to run on 16bit PCs, that is, computers that were based on the Intel 8088 processor, which is a cheaper version of the 8086. Both were 16bit (had 16 bit registers and addressing instructions), but the 8088 internally had only an 8bit data bus, which made it somewhat slower. No difference for the programmer.

Real Mode Memory
These microprocessors are special in that they address memory by combining a segment and an offset, not just one address. That is, say you have a 16bit address (pointer). That would be a number from 0 to 65535 (FFFFh in hexadecimal). You have one byte at each address, so you can store a value at 0, another at 1 and so on, up to 65535 byte values. Now, that's only 64K, not much. The classical way to multiply this was to just add memory "banks", so you'd have another register that would hold the bank number. If you had 10 banks, that would total 640K. The problem with this was that it wasted a lot of memory (64K was a lot back then), so Intel, for its 8086, instead of banks, used segments. A segment does not start just where the previous one ends. Instead, it overlaps with most of the previous segment, only offset by 16 bytes. So, for an address consisting of a segment and an offset, the byte at 0000:0000 is the first byte; next is 0000:0001, and so on, but the byte at 0001:0000 is the same as the one at 0000:0010 and the byte at 3000:9A16 is the same as the one at 39A1:0006. Clear?  Well, the purpose of this is to be able to load a program at almost any point in memory so that it'd still run. Stunts is not always loaded at the same address, but the offset at which it loads should always be the same.

On XTs, the maximum addressable memory was 1 megabyte, but because addresses starting at A000:0000 were dedicated to hardware, RAM could only be addressed up to 9000:FFFF, so max RAM was 640K. When the AT was introduced, one thing that was important was to allow for more RAM. This couldn't be done with this old system, so the old addressing system was called "real mode" and a new one was introduced called "protected mode". In protected mode, a segment can start at any point of memory and the segment number has nothing to do with its starting location. Also, the size of a segment does not have to be 64K. Because this is so different from real mode, in general, real mode (DOS) programs can't run in protected mode and vice-versa. Stunts was born in a era in which compatibility with XT was still important, so it only uses this "conventional" RAM up to 640K. But how do other DOS games access "extended" memory?

Extended Memory and HIMEM.SYS
Intel would've liked operating systems to immediately be updated to use protected mode instead of real mode, but things never change that fast. Several tricks came up to access extended memory, but the one provided with DOS usually was a driver called HIMEM.SYS. This driver, when loaded, installed some functions in memory that did things like "copy this amount of memory from this region in extended memory to this other region in conventional memory". The DOS program would call HIMEM in real mode, then HIMEM would temporarily enter protected mode, access memory, copy the data, then jump back to real mode and return control to the program. On the 286, it was not possible to switch back to real mode, so the whole micorprocessor had to be reset, yet preserve the memory, for this to be accomplished. In other words, 286s are extremely slow at accessing extended memory in DOS. 386s and later are able to switch in both directions. Still, switching does take time, so a DOS program that uses XMS (extended memory) is slower at memory access than one that runs in protected mode or one that runs in real mode using only conventional memory.

Expanded Memory and EMM386.EXE
Another popular driver for extra memory is EMM386.EXE. It's story is completely different. Before the AT, if you wanted more than 640K, what you could do is buy an expensive expansion card that you would place in an ISA slot and would add more memory to your system. Because the microprocessor could not address more than 1M, you had to install a driver. Calling some interrupt functions, you were able to change which 16K memory bank from the expansion card were to be mapped to a memory region in high memory (such as C000:0000, for example). These cards were forgotten when the AT came up, but because some programs made use of them, it made sense to create a driver that would emulate these cards with extended RAM. That's what EMM386.EXE did. It was so much easier to use this driver than HIMEM that many DOS games actually require it, even though they came up much later than these expansion cards were no longer used. The 386 or later, instead of switching modes and copying memory, would remain in protected mode all the time and "emulate real mode" using something called "virtual 86 mode", a much faster approach than that of HIMEM (with some drawbacks). But V86 does not exist in 286s. There was a EMM286 driver which worked doing something more like what HIMEM does.

The latest DOS games used neither of these methods. Instead, a special driver called DPMI or VCPI is loaded just before the game is run. The driver enters true protected mode and installs many memory management functions in memory, then executes the actual game program, which will run in flat memory, meaning it has full access to all of the extended memory without needing to set banks or to copy, just directly. This is a lot faster. Only loading and unloading the program is slower. A disadvantage is that accessing DOS functions now becomes much slower, as you have to jump to real mode, execute the function and return to protected mode, but while utilities do a lot of this, games do a lot less. These programs can run in 32bit native code. In theory, it would be possible to create a 64bit "DPMI" driver, but if it exists, I don't know of it. Latest commercial DOS games date from around 1997, much earlier than 64bit PCs.

DOSBox and memory models
DOSBox is a very powerful emulator. It is also build intelligently. It does not emulate what is not necessary to emulate. For example, the mouse in DOS is accessed by calling its driver functions, so DOSBox emulates the driver, but does not emulate the serial port it was usually attached to, because games normally didn't access that port directly. Same way, DOSBox makes sure memory is address where you expect, but doesn't emulate what would've make it available there in a real DOS computer. I think HIMEM.SYS and EMM386.EXE functions are ready to respond from the moment you run DOSBox. I even believe that some DPMI emulation is already available even if you don't load your own DPMI driver (which was what normally happened with DOS games), but memory access is probably just as fast as if it were direct, because no actual banking or copying is going on and there's no switching between memory modes being made. The microprocessor also may be emulated at a speed that is not typical of a computer that handles memory in the way the emulation is allowing, so some games may get confused about which computer they're running on and execute too fast or too slow. Stunts runs really well on DOSBox, but the default configuration is usually a little bit too slow and you may need to increase its speed to be able to race comfortably. This is because DOSBox is trying to keep emulation slow by default so that speed is consistent with the hardware the game will find emulated.

With DOSBox, some programs will not load at the same memory region as they would in a true DOS machine. If a program loads several modules at different memory locations, they may not end where expected. Most games don't have a problem with this, but sometimes, it is important. For example, the Neverlock crack that comes up when you run Stunts_K expects some relative location for some Stunts modules. If you load something before you load Stunts, such as a different mouse driver, for instance, and it takes up more memory, Stunts may end up loaded where Neverlock doesn't expect it. Both programs will run, but Neverlock will fail to disable the DRM system. If this happens, check to see what is being loaded before Stunts.

Stunts Chat / Re: Keyboard issues and ghosting
« on: January 04, 2019, 12:01:14 AM »
For quite some time, I didn't want to switch to new keyboards precisely because of this. Even in DOS, new keyboards were appalling for games. This is one reason why I got used to English keyboard distribution and never changed it (when I had my first computer, all keyboards were in English). Then, I bought a PS/2 gaming keyboard years ago (my old one is DIN) and finally, two years ago, I bought a USB keyboard, but it's a mechanical one, gaming keyboard too (Redragon). Even though it's USB, I can say it works perfectly well.

I also wanted to add that, before I joined the Stunts community, when I played Stunts in my computer, I always used Space and Enter for the gears. I only switched to A and Z later on. I don't remember if I actually knew that combination existed. I probably did, since I had already found Shift+F1 in the track editor and other tricks.

Car creation with Stressed / Re: Stunts goes Dtm
« on: November 28, 2018, 09:02:25 PM »
Man, after this time on the community, I should have at least one car of my own design. I've never sat to analyse exactly what each thing does. The 3D design, I already understand. It's still a lot of work to do, but I can see how it's done. It's the car functioning that gets me confused... mostly. I'll be taking a deep read in the Wiki. Is there any important thing that I need to know about creating my own car that are not there?  I figure I should also read this subforum thoroughly!  Where to start! XD

Stunts Chat / Re: Race for Kicks
« on: November 22, 2018, 08:02:21 AM »
Yep... it's almost finished. I'm glad that the system has been doing pretty well. No major bugs. The issue with Leo's replays had to do with the fact that it had been designed for one car per race and had to retouch it, but other than that, I'm happy that it works well. I'll have to start thinking what we'll do for the last race of the year :)

Competition 2018 / Re: Z209 - pArAnOiA
« on: November 20, 2018, 11:50:34 PM »
Very enjoyable track!  I like how there're many ways of improving that you can choose from and not just sticking to being able to accomplish the tricks other pipsqueaks did. I like to post my first replays for each track without looking at other pipsqueaks' replays and that's what I've done so far. Another thing I like from this track is that freestyle and GAR tend to demand very different paths.

Competition 2018 / Re: Z208 - Invaders
« on: November 19, 2018, 08:30:03 PM »
Yes, it was nice. My original intention was to post another replay nearer the end of the race, but I became suddenly quite busy those last days. At least, I was able to participate at the beginning.

Competition 2019 / Re: Guest tracks 2019
« on: November 19, 2018, 08:28:15 PM »
That would be awesome. And if I'm not mistaken, it would be the first season in which all tracks are designed by different people

Competition 2019 / Re: Guest tracks 2019
« on: November 19, 2018, 07:59:16 AM »
Nice to see you back in the forum, CTG!  Hey, only one race still needs an author!

Competition 2019 / Re: Cars and rules for 2019
« on: November 19, 2018, 07:57:02 AM »
Great work!  I would like to make some experiments with car balancing next season in R4K, as I said, but I'm not sure. Being OWOOT, using slow cars would mean tiny tracks and the popularity of the tournament is not like that of ZakStunts, so not having to consider different cars simplifies it for participants, which might otherwise prefer not to race. I do have an idea I still have to work upon, though.

Competition 2019 / Re: Cars and rules for 2019
« on: November 16, 2018, 08:17:38 PM »
Yes, there is this issue the guys point out. In my terms, normally, all cars could have a fixed handicap if they were similar in their handling, only with different top speeds and an acceleration proportional to the top speed. But that's not what happens. Some cars are capable of things that make them very different from a track to another and PG is the single most noticeable one of these features. So, say, Porsche Marcy Indy should get not one, but two fixed handicap values if one wanted to do this. But then how would one judge which would apply?

I think the current car-shuffling system in ZakStunts does a decent job in getting us try all cars. It could be better, but it's really hard to make it better without, well, making it worse XD   I see this and for this reason, I'm just as much in favour as I am against about changing it and will support any outcome. If you guys want, I can set up an experimental shuffling system different from that in ZakStunts during next season so we can mess up there and not break anything here. For example, in the past, I was thinking of setting up fixed handicap values, but obtaining them from the results of at least two different tracks (one favourable for PG and one not favourable), making an average. This would make PG cars non-suitable for some tracks, but very good for others. Another thing that could work is simply banning a race's top-car from the rest of the races in the season.

Well, anyway, I'm at your service

Competition 2019 / Re: Guest tracks 2019
« on: November 16, 2018, 08:00:18 PM »
Great!  It looks like we're going a have a season with tracks from most of us :)

Competition 2019 / Re: Cars and rules for 2019
« on: November 13, 2018, 10:02:02 PM »
I'm not sure about the slowing down. That is, it'd be interesting to test, but could cause the last five or six races of the season to be all-slow. If the cars recover more slowly but go down just as fast as before, this could happen. I'm OK with both doing it and not doing it. I'll agree with what most of you guys want :)

Competition 2019 / Re: Guest tracks 2019
« on: November 13, 2018, 09:52:32 PM »
I'll book 213 and 218 (April and August). If only one is needed, you can drop August. If one more is needed, let me know and I'll be glad to post a third one :)

Car creation with Stressed / Re: Stunts goes Dtm
« on: November 01, 2018, 02:29:02 AM »
It's open now! :)  This will be the first multi-car race in R4K. Let's see how it works out. I found a couple of bugs in the website as a result of the track update, which I expected. Now they're fixed.

Pages: [1] 2 3 ... 18