Title says it all.... so let's go directly into ASSEMBLY :)
-A 100
1454:0100 mov ah,9
1454:0102 mov dx,109
1454:0105 int 21
1454:0107 int 20
1454:0109 db "Booting...$"
1454:0114
-rcx
CX0016
14
My goal is to use that simple code as a bootloader of an external hard drive.
I tried to write it to the current drive
-w 0 0 0 1
but obviosly it's protecting sector 0 so I want to write it to another drive without saving it to a bin file and use external softwares.
Small tweak needed here :D
Related
I am trying to use Xyce for a project and am running into this issue. I am copying the DC sweep netlist example from the Xyce user guide on page 39 to notepad and saving it as test2c.cir. I then copy it over into the Xyce directory and run the Xyce terminal and run the simulate command and am unable to generate any output. Is there a step I am missing to be able to run the Diode Clipper Circuit DC Sweep file? Am I saving the cir file in the right directory? It seems that the circuit "loads properly" and the syntax is fine, but I am not getting a figure output I am expecting. I believe the issue might be that my PC doesnt have a way to open prn files, in that case, how would I fix that?
Diode Clipper Circuit
** Voltage Sources
VCC 1 0 5V
VIN 3 0 0V
* Analysis Command
.DC VIN -10 15 1
* Output
.PRINT DC V(3) V(2) V(4)
* Diodes
D1 2 1 D1N3940
D2 0 2 D1N3940
* Resistors
R1 2 3 1K
R2 1 2 3.3K
R3 2 0 3.3K
R4 4 0 5.6K
* Capacitor
C1 2 4 0.47u
.MODEL D1N3940 D(
+ IS=4E-10 RS=.105 N=1.48 TT=8E-7
+ CJO=1.95E-11 VJ=.4 M=.38 EG=1.36
+ XTI=-8 KF=0 AF=1 FC=.9
+ BV=600 IBV=1E-4)
.END
And this is the directory...
UPDATE:
I changed the Analysis Command to save files as different formats (csv, raw, dat) and it still gives me the same error. Aborts because it cant open test.cir.___. Is the problem maybe something to do with where the program directory is located?
I was informed what a possible fix would be and it worked. The Xyce installation was in a location without admin permission (by default after serial installation). The easiest thing to try that worked was to cd to another directory with the netlist file and run Xyce in that other directory. That generated the output file correctly!
I'm trying to use DOSBox with debug.exe on a 64-bit system. It works perfectly fine if I enter the commands manually. When I redirect input from a file with:
debug < [file]
it doesn't work. On every line except for the first it displays an error similar to this:
DOSBox will eventually hang and crash. Is there any way to fix this?
The input file I am trying to process as commands is:
a 100
jmp 145
db 'Hello, World!', 0D, 0A, 'Press any key to continue . . .$'
a 145
mov ah, 09
mov dx, 102
int 21
mov ah, 08
int 21
int 20
rcx
100
n hello.com
w
q
I can reproduce the behavior you are seeing in this scenario:
DOSBox 0.74 on Windows and Linux
DEBUG.EXE from Windows XP copied to DOSBox
DEBUG.EXE from various versions of MS-DOS will cause problem including unexpected hangs. See this Stackoverflow question for another related problem.
I found a version of DEBUG.COM from FreeDOS that works as expected. I have made DEBUG.COM available for download from my website. Alternatively you can download the ZIP File from Softpedia and extract DEBUG.COM.
When I run DEBUG.COM I get this:
S:\>debug.com <hello.asm
-a 100
0BFB:0100 jmp 145
0BFB:0102 db 'Hello, World!', 0D, 0A, 'Press any key to continue . . .$'
0BFB:0131
-a 145
0BFB:0145 mov ah, 09
0BFB:0147 mov dx, 102
0BFB:014A int 21
0BFB:014C mov ah, 08
0BFB:014E int 21
0BFB:0150 int 20
0BFB:0152
-rcx
CX 0000
:100
-n hello.com
-w
Writing 00100 bytes
-q
S:\>hello
Hello, World!
Had same problem in DosBox 0.74 with DEBUG.EXE script redirection. Discovered that it could be fixed by changing the end-of-line characters in the script file from [CR][LF] to just [CR] when redirecting into DEBUG.EXE.
Pasting your file into the Scite editor and viewing the line-end characters showed this:
a 100{CR][LF]
jmp 145[CR][LF].... et cetera
I used an option in Scite to change the EOL characters to [CR] alone, getting
a 100{CR]
jmp 145[CR].... et cetera
saved the file, and was able to redirect it into DEBUG.EXE with no problem.
Not sure why [CR][LF] causes the issue with DEBUG.EXE, but hope this helps.
DEBUG.COM handles either EOL sequence with no glitch, so makes sense to use it instead, especially with its extended features. But one can use DEBUG.EXE it seems, with this fix, FWIW. The Scite editor is a neat tool.
I found the same problem running a script file for Debug within Dosbox.
but I found another editor: Notepad2. runs great and small and changes color to highlight assembler words.
Had to use debug ver 1.25 though.
Than you Michael Petch. I was trying everything to get the output of FreeDos clone of MS-DEBUG to save into a text file. But it was not the path, the speed, or the memory allotment that was blocking the redirection of output. It was indeed the line feed and cursor return combination. I quickly wrote a program to take out cursor return and leave line feed. It now redirects! I can also take out the line feed and leave the cursor returns, and DEBUG redirects to file as well. The small glitch is I have to access Windows outside the or close the DosBox window, for the outputted DEBUG code to become visible in a directory listing.
This is how I redirect DEBUG output to a file:
DEBUG < game.dbg > game.lst
DD is a tool for linux which can Write partial data from MBR.bin to a sector in USB (instead of writing a whole sector). Now I need to do such thing in windows. There is a DD for windows, but it seems it will write a whole sector!
I need to write first 440 bytes of a mbr file to a usb stick. the code in linux is:
dd if=mbr.bin of=/dev/sd<X> bs=440 count=1
and in windows it will be:
dd bs=440 count=1 if=mbr.bin of=\\.\<x>:
where x is the volume letter. But in windows it will cause USB to be corrupted and usb need to be formatted. It seems it writes the whole data. How can I solve this problem?
Copy a complete block!
e.g. for a 512 byte blocksize (512-440=72)
copy mbr.bin mbr.full
dd bs=1 if=\\.\<x>: skip=440 seek=440 of=mbr.full count=72
dd bs=512 if=mbr.full of=\\.\<x>: count=1
Are you sure you pass the parameters correctly? Maybe the win version expects it to be /bs=440. Just a guess. Can't you anyway just truncate the file to 440 bytes?
The attached code is a supplied source for a SaveGame cleaner.
The only thing that is not clear is the entry point, which has been set as main.
But the decompiler at [http://www.onlinedisassembler.com/odaweb/] gave something like _start.
The first codeblock is
; SaveTool V 1.13
_______________________________________________________________________________________
[true 1 false 0 NULL 0]
[FilterStrings: B$ 'Save Files', 0, '*.ess', 0
0,0,0]
*Error 6 error A2044: invalid character in file SaveCleaner.asm 12 1* SaveCleanerNextline
[UserFileFilter: 0 #50] [ChoosenFile: 0 #64]
[OFN_FILEMUSTEXIST 01000 OFN_PATHMUSTEXIST 0800 OFN_LONGNAMES 0200000
OFN_EXPLORER 080000 OFN_HIDEREADONLY 04]
[OFN_FLAGS OFN_FILEMUSTEXIST+OFN_PATHMUSTEXIST+OFN_LONGNAMES+OFN_HIDEREADONLY+OFN_EXPLORER]
[OpenFileNameStructure: len hwndFileOwner: 0 OF_hInstance: 0 FilterStrings
0 0 1 FullChoosenFile 200 ChoosenFile
80 NULL OpenFileTitle OFN_FLAGS
nFileOffsetinChoosenFile: W$ 0 nFileExtensioninChoosenFile: 0
DefaultExtension: D$ NULL
HookCustomData: NULL HookProcPtr: NULL HookTemplateName: 0 0 0 0 ]
[OpenFileTitle: 'Open .ess file' 0]
*Error 6 error A2044: invalid character in file SaveCleaner.asm 12 1 SaveCleanerNextline*
[FullChoosenFile: 0 #64] [<16 algn: 0]
__________________________________________________________________________________________
The complete codeblock is too large for posting here so it can be downloaded (right click) at [http://www.ozemail.com.au/~lmstearn/files/SaveTool-source.asm]
The config has been set correctly to compile the code but comes up with a mass of errors.
SaveCleaner.asm(142): error A2008: syntax error :
SaveCleaner.asm(156): error A2044: invalid character in file
SaveCleaner.asm(158): fatal error A1012: error count exceeds 100; stopping assembly
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\BuildCustomizations\masm.targets(49,5): >error MSB3721: The command "ml.exe /c /nologo /Zi /Fo"Debug\SaveCleaner.obj" /I >"C:\masm32\lib" /I "C:\masm32\include" /I "C:\masm32\macros" /W3 /errorReport:prompt >/TaSaveCleaner.asm" exited with code 1.
What is missed in the VS setup?
It looks that your asm source is a RosASM source code and you will have no chance to compile it under MASM / Visual Studio.
RosASM is a win32 assembler that used a quite original design that let it store the source code inside the compiled executable (in a dedicated section) and many other features like an integrated IDE, integrated debugger, some powerful macros, a resource editor, a dialog editor, an original source navigation style that does not need scrolling bar, the possibility to divide the source in chapters called "titles"... Quite a surprising tool that need some practice to get comfortable with it, that I still use for asm win32 programming.
I have checked that the code assembles with RosASM, but I get neither an error nor a result as I do not have the corresponding game.
The original RosASM web site is now vanished, but there is a dedicated forum recently back online and I maintain an archive site where you can get binaries, and a lot of examples and fully functional applications (even a working NES emulator) made with RosASM that could help you to learn RosASM usage. FYI, SpASM is RosASM ancestor and BUASM was a revamping of RosASM that is unfinished.
Concerning the executable entry point, you can get it by looking at the Proc Main int the TITLE MAIN, that reads:
Proc Main:
call 'KERNEL32.HeapCreate' 0 0 0 | mov D$Heap eax
call 'Kernel32.GetModuleHandleA' 0 | mov D$hInstance eax
call 'USER32.DialogBoxParamA' eax IDD_MAINDIALOG &NULL DialogProc &NULL
call 'KERNEL32.HeapDestroy' D$Heap
call 'KERNEL32.ExitProcess' 0
EndP
HTH.
I am trying to understand why lseek() is used in this image creator. Why 5 bytes away from start of file? If I changed that number, the OS won't boot.
The image creator creates a .img file with the bootloader.bin inside.
/* modify the sector count */
total_sector_number = file_size / 512
lseek(disk_image_fd, 5, SEEK_SET);
write(disk_image_fd, &total_sector_number, 2);
write(disk_image_fd, &kernel_32_sector_number, 2);
//printf("%d\n", lawl);
printf("TOTAL_SECTOR_NUMBER : %d\n", total_sector_number);
printf("KERNEL_32_SECTOR_NUMBER : %d\n", kernel_32_sector_number);
The source code (image maker):
http://pastebin.com/raw.php?i=MuDpYP3Y
Bootloader:
http://pastebin.com/raw.php?i=kzw2ZaU1
The hexdump with lseek() and writing umber of sectors to byte at offset 5:
Without lseek() OS does not boot correctly.
I only figured this out because of your previous post Bootloader memory location which contained different source code for the bootloader.
You mentioned the two unknown variables TOTALSECTORCOUNT and KERNEL32SECTORCOUNT. These variables were near the beginning of the file, and I guess when assembled they sit 5 bytes into the binary. Calling lseek with the SEEK_SET parameter moves the file pointer to 5 bytes after the beginning of the file. It then writes the two values which will overwrite the ones in the bootloader code.
When you remove the lseek it will instead append the two values to the end of the file. If you changed the offset parameter of lseek to zero it would overwrite the jmp command of the bootloader instead.
Notice in your hexdump.
00000000 00eb b8fa 02c0 0000 c000 e08e e88e 00b8
^ ^- kernel_32_sector_number is never initialized.
|-total_sector_number which was calculated in code before the write.