I found assembler listing in Dragon Quest 1.rom

페이지 1/2
| 2

By moldov31337

Resident (62)

moldov31337의 아바타

10-03-2021, 12:05

I found very wierd stuff. In Dragon Quest 1 if I scroll the file in hex editor, I see asm listing from C000 to FFFF.
Not sure is that original rom or hacked by someone. Anyways, no idea why someone put asm listing in the rom.

Any ideas guys?

Login or 등록 to post comments

By Sandy Brand

Master (229)

Sandy Brand의 아바타

10-03-2021, 14:21

Nice find! Smile

There can be many reasons why unexpected data can be found in these old programs.
Especially for ROMS, coders didn't expect that anyone would go through the trouble to actually try and decompile what was stored in them. So it could be either be some left-over data that was never removed, or just some dummy data that was added to 'pad' the size of the executable to make it fit/align in ROM memory.

Most likely though it is a 'bug' in the compiler/assembler they used back then.
Probably, while assembling the code, it needed to add some padding somewhere and just increased a memory pointer without actually cleaning up what was already there, which in this case happened to be some source code that was copied around in memory by the assembler.

By santiontanon

Paragon (1418)

santiontanon의 아바타

10-03-2021, 15:41

ha! very curious!!! I just took a look and it's not a small chunk of assembler, it's 1200+ lines of assembler, with comments, labels, etc. very cool! I wonder if this is the last piece that remains of the original source code

By Guillian

Prophet (3438)

Guillian의 아바타

10-03-2021, 15:50

Some years ago, I searched for chuncks of code in the games, and I found more than I expected:
Bestial Warrior, BMX Simulator, Dragon Quest 1, Dragon Slayer 6, Fray, Ghost Busters, Rescate en el Golfo, Graphsaurus, Haja no Fuin, Hammer Boy, Makyu, Midisaurus, Ninja Kun, Nobunga, Pachicom, RAM, Retaliator, Time Bomb, Warau, Winter games...

Some of the code chunks are quite big (about 100 KB) like in Graphsaurus or Midisaurus

;**************************************
;
;	MIDISAURUS SYSUTEM PROGRAM
;		1990-02-01
;
;	KIRIKO Ver2.0	FOR MSX-DOS
;		1991-5-03
;
;	   MAIN PROG. BY CO-DEUZ
;
;
;
;
;	M-SIOS 324 (MSX TURBO-R)V.-1.0
;		1991-07-19
;
;	INI.LOADER FOR MSX-DOS2
;
;**************************************

	TITLE	MSX2
	NAME	SM

	ENT
		LDVCO,VCO,VDPCOM,LAD0,LAD1,LAD2,LAD3
		KEYST,BFSV,BFLD,MVCO
		VRADHS,VRADHR,DTSPC,DTSPD
		/
	GLOBAL
		MIDIIN,MDTMIN,MDINTR,SDO,SDOO,SDOOB,SOO,SDF
		CROK,GRF0,DIRC,DCHY,DCHZ,SVSRN,LDSRN
		DISK,DISS,PDSERR,SDCHK,DSERR/
;*******************************
;	START
;*******************************
	ORG	0100H


;
;	LD	HL,DTBUF
;	LD	DE,0090H	;MAIN PRG.SAVED SECTOR
;	LD	B,08H		;2000H
;	CALL	0C000H		;DISK DIRECT
;
;	LD	HL,DTBUF
;	LD	DE,0C000H
;	LD	BC,1000H
;	LDIR
;
	LD	IX,KOUSL		;
	LD	(IX+05),09		;
	CALL	SETMIDI

	DI
	CALL	STSET
	CALL	XENASC
;;;	CALL	VDPINF
	EI
	JP	ROOP

Fray:

;											DATE: 90-10-06	
; TITLE    	:	ボスのサブ									
;															
; AUTHOR	:	中津 泰彦									
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

	NMLIST
	NLIST
	TITLE	BOSS_SUB
	INCLUDE	A:\LANG\PROASM\INCLUDE\COMMON.MAC
	INCLUDE	A:\LANG\PROASM\INCLUDE\EXZ80.MAC
	INCLUDE	A:\LANG\PROASM\INCLUDE\MSX_VDP.MAC
	
	INCLUDE	\FRAY_AD\FRAY\GAMEDISK.H
	INCLUDE	\FRAY_AD\FRAY\OVR.H
	INCLUDE	\FRAY_AD\FRAY\COM.H
	LIST

By theNestruo

Champion (296)

theNestruo의 아바타

10-03-2021, 17:19

Sandy Brand wrote:

Most likely though it is a 'bug' in the compiler/assembler they used back then.
Probably, while assembling the code, it needed to add some padding somewhere and just increased a memory pointer without actually cleaning up what was already there, which in this case happened to be some source code that was copied around in memory by the assembler.

That's the most likely explanation.

Btw, it happens to be relatively common. In The Cutting Room Floor they have an entire section dedicated to games with uncompiled source code ([url=https://tcrf.net/Dragon_Quest_(MSX)]Dragon Quest 1[/url] included)

By PingPong

Prophet (3737)

PingPong의 아바타

10-03-2021, 22:26

santiontanon wrote:

ha! very curious!!! I just took a look and it's not a small chunk of assembler, it's 1200+ lines of assembler, with comments, labels, etc. very cool! I wonder if this is the last piece that remains of the original source code

hypotesys: if you use i computer to assemble a program in memory, the program is stored in memory in two distinct forms:
the textual representation that the assembler need to assemble the program and the actual machine code.
now suppose you freeze an image of this computer memory, like a .rom is: you get the scenario you talked of

By moldov31337

Resident (62)

moldov31337의 아바타

12-03-2021, 13:32

theNestruo wrote:
Sandy Brand wrote:

Most likely though it is a 'bug' in the compiler/assembler they used back then.
Probably, while assembling the code, it needed to add some padding somewhere and just increased a memory pointer without actually cleaning up what was already there, which in this case happened to be some source code that was copied around in memory by the assembler.

That's the most likely explanation.

Btw, it happens to be relatively common. In The Cutting Room Floor they have an entire section dedicated to games with uncompiled source code ([url=https://tcrf.net/Dragon_Quest_(MSX)]Dragon Quest 1[/url] included)

Thanks a lot. I didn't know that before...looks like no one was taking care to have their code unrevealed:)

By moldov31337

Resident (62)

moldov31337의 아바타

12-03-2021, 13:33

Sandy Brand wrote:

Nice find! Smile

There can be many reasons why unexpected data can be found in these old programs.
Especially for ROMS, coders didn't expect that anyone would go through the trouble to actually try and decompile what was stored in them. So it could be either be some left-over data that was never removed, or just some dummy data that was added to 'pad' the size of the executable to make it fit/align in ROM memory.

Most likely though it is a 'bug' in the compiler/assembler they used back then.
Probably, while assembling the code, it needed to add some padding somewhere and just increased a memory pointer without actually cleaning up what was already there, which in this case happened to be some source code that was copied around in memory by the assembler.

Yeah, it can be kinda bug, but what about the expencive ROM IC's by that time. Before seing this I was sure that developers and publishing companies were quite picky on the data volume. Usage of asm listing in ROM means occupying very expencive media by that time - 80th.

By sdsnatcher73

Paragon (1979)

sdsnatcher73의 아바타

12-03-2021, 13:34

But also apparently nobody looked at the actual resulting ROM file...

By Sandy Brand

Master (229)

Sandy Brand의 아바타

12-03-2021, 15:43

Very true, but probably ROM was bought in sizes of 8kB, 16kB, 32kB, etc. So you need to add padding somewhere to 'fill it up' Smile

It could be an actual assembler/linker bug that was never discovered because it never 'leaked' memory in quantities that were actually noticeable.

Also, many games were produced under strict deadlines back then same as they are now. Maybe they knew about it but never had the time to digg into it and solve it Smile

By sdsnatcher73

Paragon (1979)

sdsnatcher73의 아바타

12-03-2021, 17:45

I wonder how much the size of the code is in the rom? Could it have fit in a smaller mask ROM?

페이지 1/2
| 2