The original discussion is on pouet.net: http://www.pouet.net/topic.php?which=9855
The idea is to fix the Oric Giga Demo, which suffered from a number of issues:
- Our loader was not mature at the time, so it was crashing a lot, we had to use a hacked Sedoric loader instead, resulting in a first a very slow loading time in some parts, and second the fact we could not use the overlay memory means the demo has no music at all
- The floppy builder was not very mature either, and as a result there are some bugs on the disk, like the message "Lifeiis short", the double "ii" is a bug caused by the tool writing datas incorrectly to the disk.
- Some other glitches, like the 60hz switch during the rotozoom, which causes some screens to go berzerk
- The overly visible red line on the scrolling picture (because at the time we did not have any conversion tool that could handle pictures taller than the screen)
- The broken rotating thingies which were supposed to be a 3D Studio animation, but it got broken during the packing
- The end logo which was brutally converted and looks like crap
- EDIT: Apparently it does not run on ORIC1 either, it calls Oric Atmos ROM functions such as HIRES
The idea is to fix the demo, at a minimum that would involve repackaging all of it using the new loader, which would in turn leave the overlay memory free, which would allow me to put a music.
If I can find ways to fix the rest without spending the rest of my life on it (hint: I do not have the source codes...), I will try to fix some of the most glaring bugs.
And since it looks like the various development diaries seem to interest people, I will document the progress in this thread.
Don't expect fast progress though, I will probably spend an hour here, an hour there, so it may take months
Fixing the Oric Giga Demo
Re: Fixing the Oric Giga Demo
First step: Extraction of the actual Sedoric files.
When you boot the demo you can CTRL+C, which shows easily that there are only two real files on the floppy:
- MENU.COM
- DISK.COM
The first one is a basic program which shows the intro page and then loads the second one.
that one is easy to rip out:
For the second one, we need first to find the start and end address:
My disassembler of choice is from the C64 people and is named Regenerator. Unfortunately it does not know the Oric file format, so I need to convert the file to C64 format, which basically means removing the Oric header,
When you boot the demo you can CTRL+C, which shows easily that there are only two real files on the floppy:
- MENU.COM
- DISK.COM
The first one is a basic program which shows the intro page and then loads the second one.
Code: Select all
1 POKE #BBA4,0
2 POKE #26A,14
10 CLS
20 PAPER0
30 INK 7
40 PRINT"======================================"
50 PRINT CHR$(27);"T";
70 PRINT CHR$(27);"A";
75 PRINT CHR$(27);"J";
80 PRINT "ORIC GIGA DEMO BY DEFENCE-FORCE"
90 PRINT CHR$(27);"T";
100 PRINT CHR$(27);"C";
110 PRINT CHR$(27);"J";
120 PRINT "ORIC GIGA DEMO BY DEFENCE-FORCE"
130 PRINT"======================================"
135 PRINT""
140 PRINT"Presented and rated #1 at the VIP3"
150 PRINT"July 2001"
160 PRINT""
170 PRINT"HTTP://WWW.ORIC-INTERNATIONAL.COM"
180 PRINT"HTTP://WWW.DEFENCE-FORCE.ORG"
189 PRINT"
190 PRINT"--------------------------------------"
191 PRINT""
200 PRINT"Code : Dbug, Jede, Twilighte"
205 PRINT
210 PRINT"Gfx : Eaks, Twilighte"
215 PRINT
220 PRINT"Music : Twilighte"
235 PRINT
240 PRINTCHR$(96);:PRINT" Defence-Force 2001"
245 PRINT:PRINT
1000 PRINT"======================================"
1009 PRINT CHR$(27);"T";
1010 PRINT CHR$(27);"A";
1020 PRINT CHR$(27);"N";
1030 PRINT " PRESS ANY KEY TO START"
1033 PRINT CHR$(27);"T";
1034 PRINT CHR$(27);"C";
1035 PRINT CHR$(27);"N";
1040 PRINT " PRESS ANY KEY TO START"
2000 PRINT"======================================"
2020 GET A$
2030 !DISK.COM
(the ,N option is used to disable the auto-start)LOAD"MENU.COM",N
CSAVE"MENU.TAP"
For the second one, we need first to find the start and end address:
Now that we know that it loads and starts from 50A and finishes in 800, we can save it as well:LOAD"DISK.COM",V
050A 0800 41 050A
After some inspection in the debugger, it appears to be 100% assembler code, which fortunately is much easier to disassemble that C, so the next step is to disassemble it and add readable labels.LOAD"DISK.COM",N
CSAVE"DISK.TAP",A#050A,E#0800
My disassembler of choice is from the C64 people and is named Regenerator. Unfortunately it does not know the Oric file format, so I need to convert the file to C64 format, which basically means removing the Oric header,
and then adding the C64 header which is just two bytes containing the load address! Does not look very readable, but now we can load it in Regenerator and start abusing of the "add labels" feature. And that's basically all I have for today%osdk%/bin/header -h0 DISK.TAP disk.prg
Re: Fixing the Oric Giga Demo
I'm done with the disassembling of the loader:
So basically what this loader do is to use the various tables that contain information about where the files are on disk to call the Sedoric function that loads sectors.
Some of the demo screens load in $800 (just after the loader itself), some in $1000, and for some strange reason the last part is loaded in $765a
As you can see, there are also calls to the overlay switch code (in page 4), HIRES and CHARSET initialization (ATMOS Rom calls).
The loop in the middle is the one that charges all the logos shown during the greetings. I always wondered why it was so slow, I guess the two jsr wait may have something to do with it.
I guess the next step is to find a way to use the sector/track/size table to extract the binary blobs from the DSK file, and then convert all that to use the new FloppyBuilder and see if it runs.
Code: Select all
;
; **** ZP ABSOLUTE ADRESSES ****
;
index_logo = $4F
;
; **** USER LABELS ****
;
current_sector = $0200
current_track = $0201
load_counter = $0202
current_drive = $0203
buffer_low = $0204
buffer_high = $0205
file_index = $0206
sedoric_swap_overlay = $04F2
sedoric_romram_flag = $04FB
run_0800 = $0800
run_1000 = $1000
run_765a = $765A
sedoric_drive = $C000
sedoric_track = $C001
sedoric_sector = $C002
sedoric_buffer_low = $C003
sedoric_buffer_high = $C004
rom_hires = $EC33
rom_init_charsets = $F8D0
sedoric_read_sector = $FFB8
* = $050A
JSR initialize
LDX #$00
JSR load_file
JSR run_1000
LDX #$01
JSR load_file
JSR run_0800
LDY #$FF
loop_wait JSR wait
INY
BNE loop_wait
LDX #$05
JSR load_file
JSR run_0800
JSR rom_hires
LDX #$03
JSR load_file
JSR run_0800
LDX #$02
JSR load_file
JSR run_0800
JSR rom_init_charsets
JSR rom_hires
LDX #$04
JSR load_file
JSR run_0800
LDX #$06
JSR load_file
LDA #$00
STA index_logo
logo_patch_index =*+$01
loop_load_logo LDX #$0A
JSR load_file
JSR run_0800
INC index_logo
INC logo_patch_index
JSR wait
JSR wait
LDX index_logo
CPX #$33
BNE loop_load_logo
LDX #$07
JSR load_file
JSR run_0800
LDX #$08
JSR load_file
JSR run_0800
LDX #$09
JSR load_file
JSR run_0800
JSR rom_hires
LDX #$3D
JSR load_file
JSR run_765a
RTS
load_file STX file_index
JSR fetch_file_info
load_loop JSR find_next_sector
INC current_sector
DEC load_counter
BNE load_loop
JSR find_next_sector
RTS
fetch_file_info LDX file_index
LDA table_sectors,X
STA current_sector
LDA table_drives
STA current_drive
LDA table_tracks,X
STA current_track
LDA table_addresses_low
STA buffer_low
LDA table_addresses_high,X
STA buffer_high
LDA table_sector_count,X
STA load_counter
RTS
find_next_sector JSR load_sector
INC buffer_high
LDA current_sector
CMP #$11
BNE same_track
INC current_track
LDA #$00
STA current_sector
same_track RTS
wait PHA
TXA
PHA
TYA
PHA
LDY #$00
incrementation2 LDX #$00
incrementation22 INX
BNE incrementation22
INY
BNE incrementation2
PLA
TAY
PLA
TAX
PLA
RTS
initialize LDA #$00
STA file_index
LDA #$86
STA sedoric_romram_flag
RTS
load_sector JSR sedoric_swap_overlay
LDA buffer_low
STA sedoric_buffer_low
LDA buffer_high
STA sedoric_buffer_high
LDA current_drive
STA sedoric_drive
LDA current_track
STA sedoric_track
LDA current_sector
STA sedoric_sector
JSR sedoric_read_sector
JSR sedoric_swap_overlay
RTS
table_drives .BYTE $00
table_sectors .BYTE $01,$05,$05,$06,$07,$11,$0D,$07
.BYTE $0F,$11,$07,$0F,$06,$0E,$01,$09
.BYTE $11,$08,$10,$07,$0F,$06,$0E,$05
.BYTE $0D,$04,$0C,$03,$0B,$02,$0A,$01
.BYTE $09,$11,$08,$10,$07,$0F,$06,$0E
.BYTE $05,$01,$09,$11,$08,$10,$07,$0F
.BYTE $06,$0E,$05,$0D,$04,$0C,$03,$0B
.BYTE $02,$0A,$01,$09,$11,$08,$02
table_tracks .BYTE $80,$84,$86,$88,$90,$90,$91,$92
.BYTE $95,$9C,$A5,$A5,$A6,$A6,$07,$07
.BYTE $07,$08,$08,$09,$09,$0A,$0A,$0B
.BYTE $0B,$0C,$0C,$0D,$0D,$0E,$0E,$0F
.BYTE $0F,$0F,$10,$10,$11,$11,$12,$12
.BYTE $13,$15,$15,$15,$16,$16,$17,$17
.BYTE $18,$18,$19,$19,$1A,$1A,$1B,$1B
.BYTE $1C,$1C,$1D,$1D,$1D,$1E,$24
table_sector_count .BYTE $47,$21
.BYTE $22,$88,$09,$0C,$0A,$3A,$78,$8E
.BYTE $07,$07,$07,$07,$07,$07,$07,$07
.BYTE $07,$07,$07,$07,$07,$07,$07,$07
.BYTE $07,$07,$07,$07,$07,$07,$07,$07
.BYTE $07,$07,$07,$07,$07,$07,$07,$07
.BYTE $07,$07,$07,$07,$07,$07,$07,$07
.BYTE $07,$07,$07,$07,$07,$07,$07,$07
.BYTE $07,$07,$07,$5F,$0E
table_addresses_low .BYTE $00
table_addresses_high .BYTE $10,$08,$08,$08,$08,$08,$08,$08
.BYTE $08,$08,$0A,$0A,$0A,$0A,$0A,$0A
.BYTE $0A,$0A,$0A,$0A,$0A,$0A,$0A,$0A
.BYTE $0A,$0A,$0A,$0A,$0A,$0A,$0A,$0A
.BYTE $0A,$0A,$0A,$0A,$0A,$0A,$0A,$0A
.BYTE $0A,$0A,$0A,$0A,$0A,$0A,$0A,$0A
.BYTE $0A,$0A,$0A,$0A,$0A,$0A,$0A,$0A
.BYTE $0A,$0A,$0A,$0A,$0A,$60
.BYTE $DC,$00,$00
Some of the demo screens load in $800 (just after the loader itself), some in $1000, and for some strange reason the last part is loaded in $765a
As you can see, there are also calls to the overlay switch code (in page 4), HIRES and CHARSET initialization (ATMOS Rom calls).
The loop in the middle is the one that charges all the logos shown during the greetings. I always wondered why it was so slow, I guess the two jsr wait may have something to do with it.
I guess the next step is to find a way to use the sector/track/size table to extract the binary blobs from the DSK file, and then convert all that to use the new FloppyBuilder and see if it runs.
Re: Fixing the Oric Giga Demo
And more good news, I managed to locate the original picture used on the poster scroll, did a naive conversion with the Img2Oric mode, looks much better already
The source picture was 540x720, I reduced it to 240x320, and then had to fix PictConv because the Img2Oric algorithm would not accept a picture taller than 200 pixels (the fixed version is in SVN, will be in the next OSDK publish).- ibisum
- Wing Commander
- Posts: 1655
- Joined: Fri Apr 03, 2009 8:56 am
- Location: Vienna, Austria
- Contact:
Re: Fixing the Oric Giga Demo
I can't imagine what the world of Oric would have been like if we'd had such quality pictures to drool over way back then ..
- Hialmar
- Flight Lieutenant
- Posts: 349
- Joined: Tue Mar 04, 2014 11:25 am
- Location: Toulouse, France
- Contact:
Re: Fixing the Oric Giga Demo
Thanks a lot for this post.
It is really interesting to find out about this wonderful disassembler tool from the C64.
I have a plan of porting "L'Aigle d'Or" to C and this will help me a lot I think
It is really interesting to find out about this wonderful disassembler tool from the C64.
I have a plan of porting "L'Aigle d'Or" to C and this will help me a lot I think