--------------- FIDO MESSAGE AREA==> TOPIC: 145 ASSEMBLY LANG. Ref: E5H00000Date: 05/11/97 From: TRAVIS HEIN Time: 09:51pm \/To: ALL (Read 2 times) Subj: Creating my own OS Hello ALL Like most of you, I am a computer programmer/ user that has become fustrated with the currently available choices of operating systems. Being a second year computer engineer, with a very strong aptitude to learn, and a developing background in assembly language, and the 80x86 architecture, and support hardware, I feel that it is time that I start to do something about it. In the next little while I want to design an OS to give more usability to the computer programer and users alike. I thought I would reach out to see if there are any other brave individuals or groups of individuals out there in BBS land that felt the same way, such that we could share ideas and or discussions and or criticisms. Hope to hear from you! --- FMail 0.92 * Origin: The Programmer's Oasis on FIDONET! (1:348/203) --------------- FIDO MESSAGE AREA==> TOPIC: 145 ASSEMBLY LANG. Ref: E5H00001Date: 05/11/97 From: RENE HERMAN Time: 11:08pm \/To: ALL (Read 2 times) Subj: OpenDOS Kernel Source Code / TASM * Crossposted in 80XXX * Crossposted in MSDOS.028 All, As you might be aware, Caldera released the sourcecode to their OpenDOS MS-DOS compatible operating system (version 7.01) on the fifth of may. (http://www.caldera.com or http://www.caldera.co.uk) To build IBMDOS, only supplied tools are used, and simply running MAKE.BAT yielded a byte identical IBMDOS.COM. However, IBMBIO uses MASM version 4, and some of it's tools, which I don't own. In trying to build it using TASM (version 4), I ran into some incompatibilities between TASM's /uM400 switch (or "VERSION M400" directive) and MASM 4, most noticably (sp?) the handling of "offset GROUPNAME:SEGMENTNAME". MASM 4 (apparently) assembles this to the offset of the segment in the group, whereas TASM, when trying to emulate MASM 4, always generates 0. This meant some changes to the source files were necessary to get it to compile (to a byte identical IBMBIO.COM). I thought I'd share what I found to be necessary. Fortunately, only minor changes to three files are required. In the next message I'll post a makefile. 1. File: BIOSGRPS.EQU Define zero org labels in some segments, so that INIT.ASM can refer to these. Example: Line 37, change: ENDCODE segment public byte 'ENDCODE' ENDCODE ends To: ENDCODE segment public byte 'ENDCODE' _ENDCODE label ENDCODE ends Do the same for the RCODE, RESUMECODE, RESBIOS, IDATA and INITDATA segments. 2. File: INIT.ASM A. Lines 195, 201, 579, 646, 796, 798, 801, 827, 828, 832. Change the "CGROUP:segment" or "CG:segment" to "CGROUP:_segment" and "CG:_segment", respectively. Example: Line 195, change: dw offset CGROUP:INITDATA ; compresses from INITDATA onwards To: dw offset CGROUP:_INITDATA ; compresses from INITDATA onwards B. Line 518, 519. Replace "equ" with "=", to avoid an error on the preceding "public" statement (undefined sybol "word"): Line 518, change: local_id equ word ptr local_buffer + IDOFF local_pt equ word ptr local_buffer + PTOFF To: local_id = word ptr local_buffer + IDOFF local_pt = word ptr local_buffer + PTOFF 3. File: DISK.ASM Define cs: assumes around the "reset" proc: Line 141, change: reset proc far reset endp To: ASSUME CS:ROS reset proc far reset endp ASSUME CS:CGROUP With the above changes applied, and using the makefile in the next message with the TASM 4 package I got it to compile to a byte identical IBMBIO.COM (byte identical to the prebuild IBMBIO.COM supplied in the BIN subdirectory). Regards, Rene Herman --- * Origin: The JAM Zone, Groningen, Netherlands, +31-50-5490252 2:282/543.18) --------------- FIDO MESSAGE AREA==> TOPIC: 145 ASSEMBLY LANG. Ref: E5H00002Date: 05/12/97 From: RENE HERMAN Time: 12:35am \/To: ALL (Read 2 times) Subj: OpenDOS IBMBIO makefile * Crossposted in 80XXX * Crossposted in MSDOS.028 All, Please note that this message is "continued" from the previous ("OpenDOS Kernel Source Code / TASM"). With the changes to the source files as described in the previous message applied, you'll probably want to use this makefile rather than changing the supplied MAKE.BAT to build IBMBIO.COM. Unlike MAKE.BAT it serves as a handy reference to the source file dependacies (sp?). You should only have to change the "GTLS" (global tools) variable to point to your TASM\BIN directory. Place it in the IBMBIO directory and rename MAKE.BAT to MAKE.ORG (or whatever). Make sure the "BIN" subdirectory exists before running MAKE. == MAKEFILE =============================================================== # # OpenDOS 7.01 IBMBIO.COM # GTLS = c:\tasm\bin TASM = $(GTLS)\tasm.exe LINK = $(GTLS)\tlink.exe LIBR = $(GTLS)\tlib.exe LTLS = ..\ltools RASM = $(LTLS)\rasm_sh.exe $(LTLS)\rasm86.exe FXUP = $(LTLS)\fixupp.exe EXBI = $(LTLS)\exe2bin.exe CBIO = $(LTLS)\compbios.exe .\bin\ibmbio.com: .\bin\bios.exe $(EXBI) .\bin\bios.exe .\bin\ibmbio.com $(CBIO) .\bin\ibmbio.com .\bin\bios.exe: .\bin\biosgrps.obj \ .\bin\init.obj \ .\bin\clock.obj \ .\bin\console.obj \ .\bin\disk.obj \ .\bin\serpar.obj \ .\bin\biosmsgs.obj \ .\bin\biosinit.obj \ .\bin\config.obj \ .\bin\genercfg.obj \ .\bin\nlsfunc.obj \ .\bin\bdosldr.obj \ .\bin\stacks.obj \ .\bin\initmsgs.obj \ .\bin\biosstub.lib $(LINK) /k @bios.lnk .\bin\biosstub.lib: .\bin\bdosstub.obj \ .\bin\confstub.obj $(LIBR) .\bin\biosstub.lib -+ .\bin\bdosstub.obj -+ .\bin\confstub.obj .asm.obj: $(TASM) /uM400 $&.asm, .\bin\$&.obj .a86.obj: $(RASM) . .\$&.a86 .\bin\$&.obj $$szpz /DDRDOS35=0 /DADDDRV=0 $(FXUP) .\bin\$&.obj .\bin\bdosstub.obj: bdosstub.a86 .\bin\confstub.obj: confstub.a86 .\bin\biosgrps.obj: biosgrps.asm \ biosgrps.equ .\bin\init.obj: init.asm \ biosgrps.equ \ drmacros.equ \ ibmros.equ \ msdos.equ \ request.equ \ bpb.equ \ udsc.equ \ driver.equ \ biosmsgs.def .\bin\clock.obj: clock.asm \ biosgrps.equ \ drmacros.equ \ ibmros.equ \ request.equ \ driver.equ .\bin\console.obj: console.asm \ biosgrps.equ \ drmacros.equ \ ibmros.equ \ request.equ \ driver.equ .\bin\disk.obj: disk.asm \ biosgrps.equ \ drmacros.equ \ ibmros.equ \ request.equ \ bpb.equ \ udsc.equ \ driver.equ \ biosmsgs.def .\bin\serpar.obj: serpar.asm \ biosgrps.equ \ drmacros.equ \ ibmros.equ \ request.equ \ driver.equ .\bin\biosmsgs.obj: biosmsgs.asm \ biosgrps.equ .\bin\biosinit.obj: biosinit.a86 \ msdos.equ \ psp.def \ f52data.def \ doshndl.def \ config.equ \ fdos.equ \ modfunc.def \ patch.cod \ initmsgs.def .\bin\config.obj: config.a86 \ config.equ \ msdos.equ \ char.def \ reqhdr.equ \ driver.equ \ fdos.equ \ f52data.def \ doshndl.def \ country.def \ initmsgs.def .\bin\genercfg.obj: genercfg.a86 \ config.equ \ msdos.equ \ char.def \ reqhdr.equ \ driver.equ \ fdos.equ \ f52data.def \ doshndl.def \ country.def \ initmsgs.def .\bin\nlsfunc.obj: nlsfunc.a86 \ config.equ \ msdos.equ \ mserror.equ .\bin\bdosldr.obj: bdosldr.a86 \ reqhdr.equ \ driver.equ \ config.equ \ initmsgs.def .\bin\stacks.obj: stacks.asm .\bin\initmsgs.obj: initmsgs.asm # # Makefile by Rene Herman, 2:282/543.18 (fidonet), 08 may 1997 # =========================================================================== Regards, Rene Herman --- * Origin: The JAM Zone, Groningen, Netherlands, +31-50-5490252 2:282/543.18) --------------- FIDO MESSAGE AREA==> TOPIC: 145 ASSEMBLY LANG. Ref: E5H00003Date: 05/12/97 From: BARRY BLOCK Time: 12:44pm \/To: FLEMMING SONDERGAARD (Read 2 times) Subj: Bosskey.Asm - sysreq.asm Hello Flemming, BB>> Your code was cs:ss BB>> How is this different from push cs, pop ds, then ss? FS> By using the stack you are accessing the memory at location SS:SP. I now see the problem. I believe... Denis explained that we can't be sure where sp is. You said to Denis we can't trust where ss is. BB>> Well, I may be wrong, but, not needed anyway, as the stack is the same BB>> on return from Int 2E. So I thought. FS> If the stack is the same, what's the point in saving SS and IP? (SP) That was Denis idea. It may be a good one! R. Brown says only IP is restored on return from Int 2Eh. But I found that there is no stack problem. Some prog's run ok. 4DOS is reporting a memory problem on return, when using other prog's. List.com is ok. QuikEdit has a problem. I'd like to know if Turbo Debugger can be used (how?) to see if the stack is ok on return. Kind regards, Barry --- Terminate 4.00/Pro * Origin: EBO-BBS A'dam +31-20-6002828 (2:280/901.42) --------------- FIDO MESSAGE AREA==> TOPIC: 145 ASSEMBLY LANG. Ref: E5I00000Date: 05/12/97 From: TOM ST DENIS Time: 08:21pm \/To: ALL (Read 2 times) Subj: intel reference Here's a text file --- Maximus 3.01 * Origin: You're on vacation and nobody knows you * (1:163/105) --------------- FIDO MESSAGE AREA==> TOPIC: 145 ASSEMBLY LANG. Ref: E5I00001Date: 05/09/97 From: BENJAMIN L MCGEE Time: 10:49am \/To: DENIS BOYLES (Read 2 times) Subj: code compiled bitmap Area: QUIK_BAS Date: 05-05-97 05:24 (Public) From: Denis Boyles To: Benjamin L Mcgee Subject: MY TURN! BLM> It's my turn to post one of those useless little programs BLM> that everybody is so fond of. Of course since it's my BLM> program It uses an assembly language function, my apologies BLM> to those that don't have the AarowSoft assembler. :( DB> Here's a speedup thought for the assembly part. Try converting DB> the bitmap into a code compiled bitmap. That is, make each pixel DB> into a DB> MOV word/byte [BX+offset],color DB> That way the bitmap itself will be "code" so it will run warp DB> speed, instead of loading/setting. :) That is a very good idea. Have you ever done this? READ AS: "Please post some code, please please please!" thanx *Prune: A plum that has seen better days. blm --- FLAME v1.1 * Origin: Purgatoire BBS, 719-846-0140, Trinidad, CO, V.34 (1:15/7) --------------- FIDO MESSAGE AREA==> TOPIC: 145 ASSEMBLY LANG. Ref: E5I00002Date: 05/12/97 From: GLEN MCNABB Time: 04:58pm \/To: TRAVIS HEIN (Read 2 times) Subj: Creating my own OS Hi Travis, On <11 May, 21:51>, Travis Hein wrote to All : TH> Like most of you, I am a computer programmer/ user that has become TH> fustrated with the currently available choices of operating systems. TH> In the next little while I want to design an OS to give more usability to TH> the Your treading on ground heavily travelled. Try searching internet on "FreeDos" and "Freedows". You can find some buddies who have pretty much the same idea... Glen.. --- ProBoard v2.15 [Reg] * Origin: Bucolic Fair, Pasco WA 1-509-545-5031 (1:3407/25) --------------- FIDO MESSAGE AREA==> TOPIC: 145 ASSEMBLY LANG. Ref: E5I00003Date: 05/12/97 From: DENIS BOYLES Time: 10:30pm \/To: PHIL QUINTON (Read 2 times) Subj: 16.7m 640 x 480 PQ>Hi, Can someone tell me how to put my graphix mode PQ>into 640 x 480, displaying 16.7 millions colours? It would depend on you video card, since each one has a different mode # for it. The "ugly" way would be to program the video card directly, setting various port registers. (specific to your card) PQ>Will I need to set 16.7m via an Int 10 call? That's be a better way, and certainly easier. You would need to check with you card for specific video mode numbers. If your card supports the VESA standard, then it should be simple enough to use those modes. Which I don't what they, since I just have a plain jane VGA card. :( However, you would use some thing like: mov AX,VideoMode int 10h The same as you normally would, you video card should update the ROM BIOS to handle the new modes. PQ>I want to be able to place three values, red, green and blue PQ>somewhere to put it on the screen. Since the video card updates the ROM functions, I wouldn't be surprised if there wasn't a function to do this. Like the current write pixel function, but exanded for different modes. PQ>Usually in 320x200, you place a value 0-255 in the PQ>appropriate place from A000 I Think, is this the same PQ>except I have to place a 24bit number instead? I don't know, never dabbled with it, well I can't. :( It's possible you would just write three bytes (RGB) into video memory. Like MODE 13, but where the three bytes would represent one pixel. ie: 63 63 63 A000:000 0 1 2 <- might represent one pixel. Alternatively, it might be planar. With three planes RGB, that are written with the bytes, kinda like EGA, but with 8-bits instead of 1. ie: 63 A000:000 0 <- Written to RED plain 63 A000:000 0 <- Written to GREEN plain 63 A000:000 0 <- Written to BLUE plain Cheers, Denis Boyles * OLX 2.1 TD * Proofread carefully to see if you any words out. --- Maximus/2 3.01 * Origin: Frog Hollow Port Moody BC 604-469-0264/0284 (1:153/290) FS> BB> Well, I may be wrong, but, not needed anyway, as the stack is the ame FS> BB> on return from Int 2E. FS>If the stack is the same, what's the point in saving SS and IP? Because it isn't the same on the return, not with MS-DOS v6.xx anyway! FS> ___,/| FS> \ o_O| - Flemming Sondergaard FS> =(_|_)= FS> U Ain't he cute! :) here putty, putty, putty, I thought I saw a putty cat, I DID, I DID see a putty cat. Cheers, Denis Boyles * OLX 2.1 TD * All hope abandon, ye who enter messages here. --- Maximus/2 3.01 * Origin: Frog Hollow Port Moody BC 604-469-0264/0284 (1:153/290) --------------- FIDO MESSAGE AREA==> TOPIC: 145 ASSEMBLY LANG. Ref: E5I00004Date: 05/12/97 From: DENIS BOYLES Time: 10:46pm \/To: FLEMMING SONDERGAARD (Read 2 times) Subj: Bosskey.Asm - sysreq.asm FS> BB> Well, I may be wrong, but, not needed anyway, as the stack is the ame FS> BB> on return from Int 2E. FS>If the stack is the same, what's the point in saving SS and IP? Because it isn't the same on the return, not with MS-DOS v6.xx anyway! FS> ___,/| FS> \ o_O| - Flemming Sondergaard FS> =(_|_)= FS> U Ain't he cute! :) here putty, putty, putty, I thought I saw a putty cat, I DID, I DID see a putty cat. Cheers, Denis Boyles * OLX 2.1 TD * All hope abandon, ye who enter messages here. --- Maximus/2 3.01 * Origin: Frog Hollow Port Moody BC 604-469-0264/0284 (1:153/290) --------------- FIDO MESSAGE AREA==> TOPIC: 145 ASSEMBLY LANG. Ref: E5I00005Date: 05/12/97 From: DENIS BOYLES Time: 10:51pm \/To: BARRY BLOCK (Read 2 times) Subj: Bosskey.Asm - sysreq.asm Hi Barry, FS> BB> Well, I may be wrong, but, not needed anyway, as the stack is the ame FS> BB> on return from Int 2E. It's not the same on the return. Which is major crash problem one. SS:SP are toasted after the INT 2E call. Quick example using DEBUG:... (speaking of which did you know that OpenDOS (Novell) debug supports 386+ instructions? It does :), you can do things like MOV EAX,......) Anyway... darn, SS:SP is preserved with OpenDOS! :) wouldn't you know it. I'll have to boot from a DOS 6 floppy... darn where's the DOS 6 floppy... ...found it :) ok, here's my informal results: BEFORE INT 2E CALL SS = 1538 SP = FFFE AFTER INT 2E CALL SS = 0E38 SP = 0603 Which is why it needs to be saved, SS:SP that is. Cheers, Denis Boyles * OLX 2.1 TD * All hope abandon, ye who enter messages here. --- Maximus/2 3.01 * Origin: Frog Hollow Port Moody BC 604-469-0264/0284 (1:153/290)