I just tried some things out on the 4.86. If i can live without EMS, i have got 595Kb. This is not 601Kb only because i can not live without Hungarian keyboard (Keyboard can not be loaded in UMB). In this case i have got 49Kb free in the UMB.
(I counted in Kb here, not 1000 bytes. So that 595Kb means approximately 609000 byte.)
I know only one game what needs this "magical" 601Kb of memory: Wolf from Sanctuary Woods (If i wrote well) with sound and music. I could not make it running (to hear it's music) in the past when I configured my files (without EMS) on a boot disk. I did not cut off the hungarian keyboard (keyb.com), and 595Kb was not enough :-?
I think we can allocate up to 500Kb in "extreme situations". This will be OK on at about 95% of the DOS (emulated) systems (i think). And we can go up to 550Kb if we write the program for people who knows a few things about DOS. But i do not think that a programmer should allocate more.
That 400Kb is the "healthy maximum".
(And what about real DOS systems? Where the EXE itself is in the base memory? I heard that when EMS is available the EXE is being placed there. So the 400Kb is only the memory limit, with an average 50Kb to 100Kb EXE it will eat up 450Kb to 500Kb in reality. So i do not think that you can "allocate" that 601Kb ever. You may have 600Kb allocated, but then what your 1Kb EXE can do?)
Portions of the EXE code can be placed in the EMS, but by any means it can be ran from there. EMS is for data. The IP register just points to base memory, hence the EXEcutable instructions must reside in the first 640 Kb. You can place EXE code in the EMS using overlays (LINK.EXE in PDS does this) but when the modules in EMS have to be ran they are loaded in the first 640 Kb.
I had such a big amount of free memory 'cause I liked good ol' japanese games
and they were such memory hogs
In real mode, you can run code from anywhere in the first 1088K of memory (1 MB + 64K HMA). This includes EMS when the pages are mapped to the pageframe.
Yeah, sorry for the inconsistence, I mean that only can be executed what can be pointed by CS:IP.
I could reach 619Kb (633600 bytes) with my DOS
BUFFERS=1, STACKS=0,0, no Hungarian keyboard, but everything other was loaded (into UMB). These are not the best idea for copying files, ect., but it works... I found an other nice trick to increase memory: some program can be loaded high! For example when i called LH NC, Norton Commander consumed a healthy 0 bytes from the main memory
. On the other hand QB.EXE will only load 240 bytes of itself into the UMB when we try to call this way. This trick can not be used with programs compiled in QB to place their EXE in UMB because then the free UMB will be the total memory (For example LH freememo, which is 16Kb in size and contain a PRINT FRE(-1) instruction reported 24Kb free memory when loaded into UMB).
I think BUFFERS has not got too much affect on system performance. Possibly because i am using SmartDrive what uses XMS for the same thing what is BUFFERS for. So i set it to 15, and got 610Kb of memory in "normal mode" (Everything what i need is loaded).
Finally i could start Wolf with music... But only PC speaker... My sound card is a so unique type that it freezed everything other and only let the game run in MPU - 401 mode where it did not made any sound... But the effects worked in Sound Blaster mode. Everyone can imagine what a silly thing is when it is raining what can be heard from the two speakers and the same time some tones come out from (somewhere under the table) the PC speaker too...
(To tell the truth my PC Speaker is not under the table, only the computer is there. The speaker is a third box in front of my screen - made by Spotted Cheetah
)
You know much about DOS
The thing i wrote here was typed on my 486 (where i have not got Internet), and the copy+pasted here (Hungary and Internet... ARRGGHH!). Had You ever tried out that LH thing? It looks useful... But not for QBasic. I tried it with Commander Keen: it worked. Maybe i will try it with some other games too. I think it is only QB which language can not execute programs this way.
LH attempts to load high. It can take parameters for you to tell you where to locate stuff. Have you tried MEMMAKER? It calculates those parameters for you.
But pretty much mem you freed
I think you can enable the keyboard driver.
And if I were you I'd go and buy a good ole ISA Sound Blaster 16 for $1.
(This competition turned into a "Who can have more from 640Kb" race... But it is interesting too
)
Now after i spent hours on hand - configuring, and once i ran Memmaker, i have got 595Kb (602Kb without Hungarian keyboard) with EMS. On the UMB side only 3Kb is free: there was nothing what i could place there...
Without EMS i have got 619Kb in conventional, and 42Kb free memory in UMB. Note that these all are the configurations what I AM REALLY USING, not something what i just created for competition. It is 622Kb what i could get out of my DOS when i disabled everything what may consume conventional memory (Buffers=1, Stacks=0,0 ect.).
Memmaker made only a big mess
. After to have the bests, i had to reconfigure those sizes. This was how i could reach these values
And to keep something from the original subject: I am working... Now i could make two sprites running around on a colorful background which produced 18FPS on everything higher than 20Mhz
And if You told about it - why anybody need splitted EXEs loading partially into EMS? If an EXE itself is larger than 150 or 200Kb, you can imagine how much memory would it need... So i think DOS 16 can be left in its 1088Kb of memory, and if someone needs more (memory than that limit), then may split his or her EXE into overlays and use EMS or XMS. I think it is a silly thing to have a huge EXE somewhere in the EMS memory while it works just only in the 640Kb conventional memory...
I had found a nice trick for accurate timing in pureQB
It uses up the Play statement (without anything can be heard), i think it would be the most useful for someone who wants to add real (SoundBlaster) music for his or her QB game. Of course this way long PC speaker background musics can be played too. Or if someone needs more ticks than 18 per second
Code:
ON PLAY(1) GOSUB newplay
PLAY ON
PLAY "MBL16N0"
a = 0
DO
LOCATE 1, 1
PRINT a
LOOP UNTIL INKEY$ = CHR$(27)
PLAY OFF
END
newplay:
PLAY "MBL16N0"
IF a < 20000 THEN a = a + 1
RETURN
In the same time i found a worse thing too. The usage of the basic library disables upper memory, and if i load NC high, then the compiled program which uses mouse (or EMS, or anything what needs that library) freezes the computer on exit. I think i will have to find out how to control the mouse through ports if i want to prevent this (It is interesting that UMB will not be completely disabled, only the communication with this area. The drivers loaded there will keep working, but i can no longer get any information on the state of that memory).
Microsoft Qbasic: "Lightpen is popular, but who has got mouse?"
It is a bit annoying that they wrote handlers for joystick, for lightpen (and some poor things for keyboard), but nothing for mouse...
I had already found the mouse related things (and a lot of keyboard stuff) in my copy of Ralph Brown's list (I am talking about ports here, not interrupts. That one is much easyer, but impossible in pureQB), but that is so concise that i could not well understand it yet. I may have to find some tutorials on that.
Regarding the included LONG arrays in BT... If anybody's interested; I made them using GSU. I drew the gfx with PCIE and used GSU to convert them to code. Both PCIE and GSU are developed by myself... But were not pretty popular... (I really don't know why...I still use them!!!) And as far as I remember, they can be downloaded on my old page. If not, then you can pm me and I will send them by email.
So you made something like my sprite editor, and created your code with it
It would be an another competition to find out what is the sortest thing to store data in the exe. This would be strings on the first thought, but what if we need to use ", or the code 13 string (a part of ENTER) ect... My DATA stuff is not the best, but it is readable. I think your way is one of the shortests.
I think your program is a good idea, and most of it is well - made. I think you should fix some parts of it (and use my code to create better PC speaker musics). If you do this, i think this game will be a very nice pureQB thing
And remove those INP60s. That can freeze some computers since it is not an "offical" keyboard handling. I am talking about that the keyboard must be accessed only when it has data for the system. And this can not be done in pureQB since the keyboard interrupt takes all of those datas.