Today I hacked ...

discussion of beeb/electron applications, languages, utils and educational s/w
duikkie
Posts: 2953
Joined: Fri Feb 07, 2014 3:28 pm
Contact:

Re: Today I hacked ...

Post by duikkie » Thu Jul 19, 2018 6:21 am

is this working on a real beeb ?
i don't have here a real bbc to test :(
duikkie wrote:
Wed Jul 18, 2018 4:04 pm
test this !

i am not a player . how to move in this game ?

i have to lose !boot. because the disc is full

changed program menu

you need to do

pa.=&2200
ch."menu"
do not know about the ?&8f=127 ???

try it ? see test

duikkie wrote:
Mon Jul 16, 2018 7:16 am
i think if you add *lo. hack 900 to menu program then it will work oke ?

*save "hack" 900 +200 900 900

duikkie
Posts: 2953
Joined: Fri Feb 07, 2014 3:28 pm
Contact:

Re: Today I hacked ...

Post by duikkie » Thu Jul 19, 2018 2:35 pm

oke test2.ssd
almost what the programmers had in mind

the menu is allso the begin screen :shock:

the *exec !boot and load menu till line 850
if you delete every think after that there is more room

the ?&8f=127 i know understand
the second time it is ?&8f=0
and the hole menu is loaded :)

still not sure if you can play ?
Attachments
Test2.ssd
(112.5 KiB) Downloaded 6 times
Last edited by duikkie on Thu Jul 19, 2018 2:36 pm, edited 1 time in total.

duikkie
Posts: 2953
Joined: Fri Feb 07, 2014 3:28 pm
Contact:

Re: Today I hacked ...

Post by duikkie » Sun Jul 22, 2018 7:03 pm

oke this is the fix

still not sure if it runs oke ?

too hot to try ?

i have changed !boot

in menu part line 1 to 480 (first part)
del line 20 and 80

this program is now &1e8 big

loaded at 1900 normale

put a up loader at &2100

the hack part at &2200 to &2400

first download hack from &2200 to &900
then upload "menu" from &1900 to &2200
zet pa.=&2200:old:run

so simple :)
Attachments
fixolympics.ssd
(95 KiB) Downloaded 6 times

User avatar
billcarr2005
Posts: 1358
Joined: Fri Sep 09, 2005 3:01 pm
Location: UK
Contact:

Re: Today I hacked ...

Post by billcarr2005 » Mon Jul 23, 2018 4:54 am

duikkie wrote:
Sun Jul 22, 2018 7:03 pm
oke this is the fix

still not sure if it runs oke ?

too hot to try ?
As Col wrote here, there's already a fully working version (not that another version / method can hurt!)
viewtopic.php?f=2&t=9061&start=60#p208824

The "hack" part is stored in !BOOT, then relocated and everything continues as it does on the original disk, in the same way, at the same time, except the data isn't coming from the "bad" track. Nothing else needs to get modified!

duikkie
Posts: 2953
Joined: Fri Feb 07, 2014 3:28 pm
Contact:

Re: Today I hacked ...

Post by duikkie » Mon Jul 23, 2018 5:45 am

oke :)

it is hot , and i am an old man. maybe that is the reason
i do not read every thing that is written :) ??

billcarr2005 wrote:
Mon Jul 23, 2018 4:54 am
duikkie wrote:
Sun Jul 22, 2018 7:03 pm
oke this is the fix

still not sure if it runs oke ?

too hot to try ?
As Col wrote here, there's already a fully working version (not that another version / method can hurt!)
viewtopic.php?f=2&t=9061&start=60#p208824

The "hack" part is stored in !BOOT, then relocated and everything continues as it does on the original disk, in the same way, at the same time, except the data isn't coming from the "bad" track. Nothing else needs to get modified!

duikkie
Posts: 2953
Joined: Fri Feb 07, 2014 3:28 pm
Contact:

Re: Today I hacked ...

Post by duikkie » Wed Jul 25, 2018 2:43 pm

oke know how it is done :)

the m code with !boot reads every time track 1 sector 0 , because all sectors are 0 :)
now how to get every sector 0 in memory &2000 ... &2a00 it is timing.
riscky but that is why i do not work on every dfs.

from &30d9 to &312c they are syncing the disc time
at &312c they want to read track1 ten sectors with delay at &3139
from &3155 to &3167 they check if all sector 0 from track 1 are in the mode
7,4,1,8,5,2,9,6,3,0 with add dec 7 and &0f .... 7+7=14 and &0f=04 04+7=11 and &0f=01 .....

the byte on &2xcc is the offset for the program *51 .... 7*51=&165+&900=&a65 so this sector is at &a65+51 bytes

the rest i have explaned. they *exec !boot till end of program text ? first part
with &8f=127 then second time &8f=0 run the rest of the program

the only thing i do not know is the contens of the secotors

sector track 1 0 with 7 looks like -MARDIS- till &C8 then

00 00 00 00 07 then bytes program 51 bytes i think the other sectors start the same from &c8 you get an other number
00 00 00 00 04

but it is all about timing, so it will work or not the timing = &1388 m seconds delay * X ??

billcarr2005 wrote:
Sun Jul 15, 2018 11:31 am
duikkie wrote:
Sun Jul 15, 2018 5:16 am
yeah, but how ?

if a discchip(8271or1770) reads a sector it is the hole sector 128 bytes, (like &e00)you can set you memory 51 bytes futher that you can do so the next sector comes &e52 and so on. but then you must know which sector is the start .

if a track has more the same sectors id , the you have a problem
like what sector does the head read first ?

if you have track 0 sec 0 head 0 leng 0 then track 0 sec 1 head 0 leng 0 and again track 0 sec 0 head 0 leng 0

how does the discchip (8271/1770) knows that it has option 1 to start and not option 3 on place &e00 ?

you don't know when the head is on the discface.

it can start at option 3 , go round the take option 2 , then may option 3 again. it is a gamble :)

it can start at option 1 , go around for sec 1 (option 2) , never finding option 3.

i can not see how you know that you have the right order for loading .

there is a solution to this , but it is gambling it in all times you ever read a sector that is
different in bytes .

track0sec0 first byte ea, read read read read maybe a time you read track0sec0 with first byte &a9 ?
but that must be in de program :) , and how long does it take ?

it you every see it , you must show and tell :)
Each 256 byte sector has a "sector number" within the data, so that when the program reads the sector, it knows which one it is (ie. 0 to 9 in a specific position within the data).
256 bytes are always read from the sector, it's just 205 of them are discarded, not used, surplus to requirements. Only 51 bytes are copied into the necessary code.
By the looks of the placement of the necessary sectors, it appeared that they were being read on the "skew" (probably not the correct phrase), that is every 7 sectors, but this is only based on the 2 sectors i had access to...
Sectors read in the following order 7, 4, 1, 8, 5, 2, 9, 6, 3, 0
I don't know how long it took, because i don't have access to the disk.
Coeus wrote:
Sun Jul 15, 2018 8:36 am
When reading, I would not expect the disc controller to use the index hole at all. It will simply start reading data until it finds the ID for the specified sector and will then generate the interrupt to start transferring that sector.

So, with all the sectors having the same ID which one you get is essentially random.

The program could handle this one of two ways:

1. To load a specific sector it could poll the FDC for the index hole pulse, then set a timer for the right amount of rotational delay, then issue the FDC command to read the sector.

2. To read all the sectors in the track it could just issue a read sector command ten times in quick succession. Then it would need to have put the real sector ID (rather than duplicated one) into the sector data somewhere so it can then work out what order they are in and re-assemble the data in the right order.

What seems more of a puzzle is how it is possible to have a disc that does not have at least the first three sectors of track 0 written normally and still have DFS read it to execute the first program from that disc that then controls the FDC directly.
The disk reading code is custom @ &D00
There is no "real sector ID" other than the duplicated (ie. the same) one
The "protected" track is 1 not track 0

Here is the not very annotated notes from the code in !BOOT which helped me to understand what was vaguely going on...

Code: Select all

-----
*EXEC !BOOT
*FX3,6
PAGE=&2200:?&8F=127:*FX200,3
LO."MENU"
R%=PAGE:REPEAT:A$=$R%:R%=R%+LEN(A$)+1:UNTIL RIGHT$(A$,11)="END OF PROG"
?R%=&FF
1
*FX3,0
RUN

-----

DISASSEMBLY
-----------
3000 - 308A FROM *EXEC
308B *FX200,3
3094 LDA 8006 ; BMI 309A
3099 RTS

309A LDX #00
309C LDA 32A3,X ; CMP #FF ; BEQ 30AA
30A3 JSR OSASCI ; INX ; JMP 309C

30AA LDA FE4E ; PHA
30AE LDA FE6E ; PHA
30B2 LDA #7F ; STA FE4E ; STA FE6E
30BA LDA FE80 ; STA 3293 ; BNE 30D9

30C2 OSBYTE 8F,0C,FF (PAGED ROM SERVICE REQUEST)
30CB STY 3294
30CE LDX #1A
30D0 LDA 3278,X ; STA D00,X
30D6 DEX ; BPL 30D0

30D9 JSR 31CD ; BCS 30D9

30DE LDA 20CC ; STA 3295

30E4 JSR 31CD ; BCS 30D9

30E9 LDA 20CC ; JSR 3257 ; STA 3296

30F2 JSR 31CD ; BCS 30D9
30F7 LDA 20CC ; STA 3295

30FD LDX #02 ; JSR 3263

3102 JSR 31CD ; BCS 30D9
3107 LDA 20CC ; JSR 3257 ; CMP 3296
3110 PHP
3111 ASL 3296 ; ASL 3296 ; INC 3296
311A PLP
311B BNE 3123
311D DEC 3296 ; DEC 3296
3123 SEC
3124 LDA #1C ; SBC 3296 ; STA 3295
312C LDA #0A ; STA 3296
3131 LDA #20 ; STA 3297

3136 LDX 3295 ; JSR 3263
313C JSR 31CD ; BCS 312C

3141 INC 3297 ; DEC 3296 ; BNE 3136

3149 LDA #CC ; STA 70 ; LDA #20 ; STA 71 --> 20CC
3151 LDX #09
3153 LDY #00
3155 CLC ; SED
3157 LDA (70), Y ; ADC #07 ; CLD ; AND #0F ; INC 71
3160 CMP (70), Y ; BNE 312C
3164 DEX ; BNE 3155

3167 LDY 3294 ; CPY #FF ; BEQ 3175

316E OSBYTE 8F, 0B, [3294]

3175 PLA ; STA FE6E
3179 PLA ; STA FE4E

317D LDA #CC ; STA 70 ; LDA #20 ; STA 71 --> 20CC
3185 LDA #FF ; STA 72 ; LDA #08 ; STA 73 --> 08FF

318D LDY #00
318F LDA (70),Y ; TAX
3192 CPX #00  ; BEQ 31A7

3196 CLC
3197 LDA 72 ; ADC #33 ; STA 72
319D LDA 73 ; ADC #00 ; STA 73
31A3 DEX
31A4 JMP 3192

31A7 INY ; CPY #34 ; BEQ 31B3
31AC LDA (70),Y ; STA (72),Y
31B0 JMP 31A7

31B3 INC 71
31B5 LDA 71 ; CMP #2A ; BNE 3185
318B LDA #08 ; STA AFE
31C0 LDA #0C ; STA AFF
31C5 OSCLI 32BF "EXEC !BOOT"
31CC RTS

31CD LDA 3293 (FE80) ; BEQ 31E9
31D2 LDA 3297 (20); STA 329A (MEMORY HIGH)
31D8 OSW7F 3298
31E1 LDA 32A2 (ERROR CODE); CLC ; BEQ 31E8
31E7 SEC
31E8 RTS

31E9 JSR 322A ; BNE 3202
31EE LDA #3A ; JSR 3238 (WRITE SPECIAL?)
31F3 LDA #23 ; JSR 323F
31F8 LDA #48 ; JSR 323F
31FD JSR 322A

3200 BEQ 31FD

3202 LDA #00 ; STA 70 ; LDA 3297 ; STA 71
320B LDA #53 ; JSR 3238 (READ DATA)
3210 LDA #01 ; JSR 323F	(TRACK 01)
3215 LDA #00 ; JSR 323F (SECTOR 00)
321A LDA #21 ; JSR 323F (256 x 1)
321F JSR 324C

3222 LDA FE81 ; CLC ; BEQ 3229
3228 SEC
3229 RTS

322A LDA #6C ; JSR 3238 (READ DRIVE STATUS)
322F JSR 324C
3232 LDA FE81 ; AND #04
3237 RTS

(COMMAND)
3238 JSR 324C ; STA FE80
323E RTS

(PARAMETERS)
323F PHA
3240 LDA FE80 ; AND #20 ; BNE 3240
3247 PLA ; STA FE81
324B RTS

324C BIT FE80 ; BMI 324C
3251 BIT FE80 ; BMI 324C
3256 RTS

3257 CMP 3295 ; BCS 325F
325C ADC #0A ; SEC ; 
325F SBC 3295
3262 RTS

(DELAY?)
3263 LDA #88 ; STA FE64
3268 LDA #13 ; STA FE65
326D LDA FE6D ; AND #40 ; BEQ 326D
3274 DEX ; BNE 3263
3277 RTS

(DISK HANDLING?)
3278 PHA ; TYA ; PHA
327B LDA FE80 ; AND #04 ; BEQ 328F
3282 LDA FE84
3285 LDY #00 ; STA (70),Y ; INC 70 ; BNE 328F
328D INC 71
328F PLA ; TAY ; PLA ; RTI

3293 [FE80]
3294 [PAGED ROM SERVICE REQUEST RETURN ARGUMENT]
3295 [20CC]
3296 [AFTER JSR 3257]
3297 #20

     98 99 9A 9B 9C 9D 9E 9F A0 A1 A2
3298 00 00 20 00 00 03 53 01 00 21 00	2000, READ T01S00 256 x 1

32A3 MODE 7
32A5 PRINTTAB(12,10) 
32A8 "Loading..."[0D]
32B4 VDU23,0,6,11,0,0,0,0,0,0

32BF EXEC !BOOT


duikkie
Posts: 2953
Joined: Fri Feb 07, 2014 3:28 pm
Contact:

Re: Today I hacked ...

Post by duikkie » Wed Jul 25, 2018 2:55 pm

very strange is that the programmers not use to check in the main program if the disck with track 1 is still there ???

sub program : read id's of track 1 eor with data if not a result disk is not org. disc. bad disc/program :D

Post Reply