Today I hacked ...

discussion of beeb/electron applications, languages, utils and educational s/w
User avatar
Pernod
Posts: 1216
Joined: Fri Jun 08, 2012 10:01 pm
Location: Croydon, UK
Contact:

Re: Today I hacked "The Real You"

Post by Pernod » Mon Dec 12, 2016 12:40 pm

lurkio wrote:Replacing the TOPs with three NOPs made things a little clearer:
Thanks for the explanation. I've also seen this, many years ago, but never understood it until now. It's surprising that DiscDoctor, Exmon 2, etc. never handled this.
- Nigel

BBC Model B, ATPL Sidewise, Acorn Speech, 2xWatford Floppy Drives, AMX Mouse, Viglen case, BeebZIF, etc.

User avatar
lurkio
Posts: 1611
Joined: Tue Apr 09, 2013 11:30 pm
Location: Doomawangara
Contact:

Re: Today I hacked "The Real You"

Post by lurkio » Mon Dec 12, 2016 1:39 pm

Pernod wrote:It's surprising that DiscDoctor, Exmon 2, etc. never handled this.
Is anyone (with the initials JGH) up for patching Disc Doctor so that it will recognise undocumented 6502 opcodes?!

:wink:

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

Re: Today I hacked "The Real You"

Post by billcarr2005 » Mon Dec 12, 2016 1:45 pm

lurkio wrote:~
What made it tricky was that when I tried to use Disc Doctor's *DIS command to disassemble the machine-code that loads the main program, the machine-code didn't seem to be valid:

Well, it turns out that the hex-byte &7C, followed by two more (random?) bytes, is an undocumented 6502 opcode that's known as "TOP" (or "Triple NOP"), which simply takes up three bytes in RAM but performs no meaningful action when executed! Every other instruction in the loader code was a TOP instruction, the sole purpose of which was to obfuscate the code and make disassembly difficult!
Early Acornsoft disk titles had similar obfuscation. Rob Northen mentions having to redo the protection because it wasn't compatible with the BBC Master here
http://codetapper.com/amiga/interviews/rob-northen/

I've also attached the SSDified version from the FSD I had, even if it's just used to check against the tape files.
Didn't work properly with Watford DFS 1.30, but works OK with Watford DFS 1.44 and Acorn DFS.
The file BOOT appears to do some low level stuff checking the protected track, but it doesn't appear to be *RUN from anywhere!
Attachments
THE REAL YOU.zip
The Real You
(33.06 KiB) Downloaded 37 times

User avatar
flaxcottage
Posts: 3088
Joined: Thu Dec 13, 2012 8:46 pm
Location: Derbyshire
Contact:

Re: Today I hacked ...

Post by flaxcottage » Mon Dec 12, 2016 9:52 pm

Nice detective work Mr Lurkio. =D> =D> =D>
- John

Why do I keep collecting Acorn gear? I'm going to need a considerably bigger man-cave. :?

roganjosh
Posts: 23
Joined: Sat Dec 10, 2016 6:51 pm
Contact:

Re: Today I hacked ...

Post by roganjosh » Thu Dec 15, 2016 8:26 pm

For amusement value I just created a special variant of one of my disassemblers
that implements those illegal opcode mnemonics and addressing modes (attached).
I'm afraid it's no DiscDoctor or Exmon though, just a simple little tool.

Hopefully not too many typos added in doing the extension.

Alan
Attachments
bod.zip
Bad opcode disasssembler
(2.83 KiB) Downloaded 36 times

User avatar
lurkio
Posts: 1611
Joined: Tue Apr 09, 2013 11:30 pm
Location: Doomawangara
Contact:

Today I hacked The Secret Diary of Adrian Mole

Post by lurkio » Tue Feb 14, 2017 12:17 am

The Secret Diary Of Adrian Mole by Level 9 isn't Master-compatible. This is how the game should look, as indeed it does on a Model B:
  • 1.png
    Screenshot of TSDOAM on a Model B
But on a Master it looks like this:
  • 2.png
    Screenshot of TSDOAM on a Master 128
Instead of text below the illustrations, you just get garbage pixels. I decided to investigate, using my new-found BeebEm debugger skills.

I set breakpoints in the OSWRCH and OSASCI code in the OS 1.2 ROM in Model B mode, so that BeebEm would break execution when it hit one of them -- which it never did!

Instead of using OS routines for printing text, the game seems to use custom code, presumably for speed. The game fetches the 8x8 pixel definition of every character of text that it needs to print on screen by peeking into the OS1.2 ROM, where the character definitions are stored at &C000 upwards (eight bytes for every char). The game then pokes the chardef directly to screen RAM.

The problem is that in a Master the chardefs are stored somewhere else! They're in slot 15, in the Terminal ROM, which isn't always paged in and accessible to user code -- and even if it was it wouldn't help because the chardefs are at a different memory location in a Master: at &B900 in the Terminal ROM, as opposed to &C000 in the OS1.2 ROM in a Model B.

I tried to work around the problem by saving the chardefs to disc and then loading them into memory at &C000 in the Master so that the game code would find the chardefs in the same place that they'd be in in a Model B. Things went well until I tried saving my position in the game -- at which point all the chardef data at &C000 was promptly overwritten by the Master's DFS!

Eventually I came up with a solution that actually seemed to work. In the game code, I changed the chardef lookup address from &C000 to &B900. I then used BeebEm's debugger to locate a point in the code where I could splice in my own short routine that paged the Terminal ROM in -- so that whenever the game looked up a chardef, the chardef was actually there, waiting to be found.

Code: Select all

Alterations to file $.CODE2 for Master-compatibility:

P%=&22AE:[OPT 3:JSR &1D70:RTS:]:REM shim

P%=&1D70:[OPT 3:LDA #15:STA &F4:STA &FE30:LDA #0:STA &229C:RTS:]:REM shim target

P%=&1D6A:[OPT 3:JSR &1D70:JMP &6B00]:REM new start address

?&2130=&B9:REM hi-byte of chardefs location in Terminal ROM
Download my Master-compatible version of the game here:
:idea:

User avatar
richardtoohey
Posts: 3563
Joined: Thu Dec 29, 2011 5:13 am
Location: Tauranga, New Zealand
Contact:

Re: Today I hacked ...

Post by richardtoohey » Wed Feb 15, 2017 7:46 pm

=D> Master conversions are fun - challenging without needing too much work (especially compared to trying to find enough bytes to shuffle tape games around DFS!)

User avatar
flaxcottage
Posts: 3088
Joined: Thu Dec 13, 2012 8:46 pm
Location: Derbyshire
Contact:

Re: Today I hacked ...

Post by flaxcottage » Sun Nov 26, 2017 5:29 pm

Over the last month or so I have been looking at archiving Music Master II, published by AB Euroean Marketing Division. This is a simple recorder tutor with some good graphics and is suited to the intended audience.

The disc was original but did not have a label (although strange I have met several other titles like that).

The copy protection on the disc was really very clever and would have defeated most copying BITD. It defeated ADI on my Master although ADI reported an identical clone of the disc. (The Master has a 1770 disc interface. Maybe a 8271 interface on a Beeb would have coped better?)

The 40T disc was formatted on tracks 0-19. Tracks 20-39 were unformatted. When catalogued there were only three files showing, !BOOT, BOOT and t.set1. I checked the catalogue for hidden filenames but these really were the only three files on the disc.

!BOOT was a machine code file which loaded at &7000, set a few memory locations from &3AA upwards and then ran the file BOOT.

BOOT was a machine code file which resided from &900 to &AFF and which loaded sectors directly from the disc surface into memory, depending on the contents of locations &3AA to &3B1. The code was a mind-numbing maze of internal jumps, repeated self-modification and frequent calls to OSWORD to set the special registers of the 8271 chip.

When I scanned the disc in 40T mode I noted that the logical track numbers were double the physical track numbers. Only even tracks were represented. In 80T mode all odd numbered tracks were blank (filled with E5 from formatting). Most even numbered tracks were also filled with E5. There was little data on the disc, only odd sectors in a track holding data.

Not only that but physical tracks 13-19 had physical sectors numbered logically from 128-137. This layout was enough to defeat my attempts at extracting the programs, especially since the programs were not held in contiguous, consecutive sectors.

However, the program BOOT was able to extract the program code successfully and to run it. Time for another approach.

Even though I was not able to fully understand the intricacies of the machine code I did note that inside BOOT there were the commands OLD followed by RUN, which were placed into the keyboard buffer. This indicated the use of a BASIC program. I modified RUN to be LI., which would list the code after loading.

Examining the BOOT code found *FX200,3 and *FX3 calls to disable VDU output, SPOOL output and Printer output. These were replaced with NOP codes and the modified file was saved on drive 1. !BOOT was modified to run :1.BOOT and saved on drive 1.

Running :1.!BOOT, the modified one, loaded my modified :1.BOOT file which ran, loaded and LISTed a BASIC file from drive 0, the original disc. This BASIC file I saved then examined it. At several points in the code there were statements such as ?&3AA=70:?&3AB=&FF:*RUN BOOT. When executed in immediate mode these loaded files from the disc in drive 0.

All was not as simple as finding these lines, executing them in immediate mode and saving the loaded files. Oh, no! The BOOT file was self-modifying and had to be used in the order set by the programmers in order to extract the right data at the right time. Also some of the files loaded were machine code files or were data and their destination addresses and lengths were not known.

To solve this problem I programmed the function keys to set the page 3 parameters and call :1.BOOT. Key F0 made the first call, F1 the second and so on. Before each call I ran an EXEC file which filled user RAM with zeros. After each call, which was not a BASIC loader, I ran an immediately executed program which searched user RAM from an input start address for the first non-zero data. Then entering EXMON I was able to determine whether this was machine code or data. In either case the end of the non-zero bytes was found and the memory *SAVEed onto drive 1.

Using this method I was able to extract 5 files from the original disc. These were 3 BASIC programs, a MODE4 partial screen for the program title and a machine code routine, which loaded at &4250, above HIMEM, which was set by the BASIC programs.

Each BASIC program required some minor editing, mostly to remove the calls to *RUN BOOT and replace these with appropriate *LOAD or CHAIN commands.

The files have been linked correctly and appear to work now on DFS and ADFS. They will be tested on NFS and RAMFS (they should work) and then I can pronounce this title HACKED!!! =D> =D>
- John

Why do I keep collecting Acorn gear? I'm going to need a considerably bigger man-cave. :?

User avatar
flaxcottage
Posts: 3088
Joined: Thu Dec 13, 2012 8:46 pm
Location: Derbyshire
Contact:

Re: Today I hacked ...

Post by flaxcottage » Tue Jan 30, 2018 5:37 pm

The protection on some John Wiley Software titles had me stumped for a while. The title comprised two discs.

The discs were 40 track but only 35 tracks were formatted on the first. *VERIFY ran and stopped at track 23 with no errors so within this formatted section there appeared to be no rogue sectors.

*CAT was 'disabled'. Only the title showed then nothing. Using ADI to examine T0 S0 showed a fairly standard method of disabling the output from *CAT. The first filename on the catalogue was CHR$(3) followed by CHR$(21), which together would stop output to the printer and screen. The last filename on the catlogue had an identical name. ADI gave the filenames of the other files on the disc.

I attempted to clone the disc using ADI but the clone did not work. Again this is a common occurrence with disc protection.

The boot option was set to RUN. I examined !BOOT using Exmon2 and found that it essentially ran a file called BOOT, having first placed a value in location &03AA.

BOOT did many things;

- it disabled all ROMs except for BASIC,
- it reset many vectors in page 2,
- it checked that track 36 was not formatted,
- it read the disc catalogue directly from sectors 0 and 1 of track 0,
- it loaded and ran a machine code program starting at 0B18,
- it loaded and ran some hidden BASIC programs (these were hidden at the end of some of the normal titles on the disc) directly from the disc surface,
- it loaded a machine code keyboard input routine into &0900 to &0AFF
- it loaded and ran a couple of BASIC programs, getting the value of PAGE from the disc catalogue,
- it used the values stored in &03AA and &03AB to determine which code to load and run and for &03AB whether the code was BASIC or machine code.

Disassembling the file BOOT showed that it ran machine code programs after loading them by executing a jump indirect through zero page and it ran BASIC programs by placing *BASIC[CR]OLD[CR]RUN[CR] in the keyboard buffer. An easy way in was to replace the JMP command for the jump indirect with a RTS command to return to BASIC and to replace RUN with LI. (short for LIST).

Four values in all were passed to BOOT via &03AA. These loaded memory from &0900 to &0AFF and loaded three BASIC programs, START, INTRO and CONTS2. Using the modified BOOT file these hidden files were loaded and saved to a new disc. This disc had to be 80 track in order to have enough storage space to include the original files as well for the archive.

Minor changes were made to these BASIC titles. The changes removed the commands such as ?&3AA=66:*RUN BOOT with CHAIN"CONTS2" for instance, *LOADed the machine code into pages &900 to &AFF and added a line to read the CHARS file using BGET# and to VDU23 the character definitions. The original used *LOAD CHARS, which only works on a model B or B+.

The title now runs properly without needing the file BOOT on a model B, B+ and Master with the exception of the Break key not working according to the documentation. If either Break or Ctrl-Break are pressed the machine hangs with a * prompt. Fixing this is on my to-do list. :?
- John

Why do I keep collecting Acorn gear? I'm going to need a considerably bigger man-cave. :?

User avatar
vanekp
Posts: 540
Joined: Thu Nov 30, 2000 7:09 am
Location: The Netherlands
Contact:

Re: Today I hacked ...

Post by vanekp » Tue Jan 30, 2018 9:29 pm

nice P.M. :)
Peter.

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

Re: Today I hacked ...

Post by billcarr2005 » Sat Feb 24, 2018 11:41 pm

The Taroda Scheme (started a few days ago)

The game wouldn't work with my Watford Electronics DFS 1.30 - when "B" is executed, "Bad sum - file disconnected" is displayed... works with WE DFS 1.44 though!
Disk was formatted 80 track, reported as 40 track with the last 40 tracks unformatted.
Catalogue was prevented from viewing by control codes, although *INFO * shows the files...
BOOT executes an OSWORD &7F block to load an extra 256 bytes of data immediately following the code to do it, this then loads the title screen "S" and kicks off the copy protection...

Tracks 2,3 and 4 report incorrect sector sizes - of 512, 2048 and 4096 bytes, so wouldn't work on 1770 DFS
The "skew" of the tracks is checked on tracks 2,3,4 and 5... if the first sector isn't numbered 6, 2, 9 and 9 respectively then "Copy !!" is displayed.

The main program "B" is *RUN to an RTS and then EOR'd by &FF and RUN
There was also a check for the original disk after a SAVE command has been issued, using

Code: Select all

B50 LDA #&05
B52 LDX #&59
B54 LDY #&0B
B56 JMP OSGBPB (FFD1)
B59 BRK
B5A 5C
B5B 0B
which then puts the disk title length, the disk title and the boot option into &B5C, and then checking that &B62 is ","

Non standard tracks, ie. not 10 x 256, were as follows

Code: Select all

Title: The Taroda Scheme 

80 Tracks
Tr.#  No.S  Sec.# Tr.ID Head# SecID IDsiz REsiz Error

02    09    00    02    00    06    0200  0100  OK
            01    02    00    07    0200  0100  OK
            02    02    00    08    0200  0100  OK
            03    02    00    09    0200  0100  OK
            04    02    00    00    0200  0200  Deleted data
            05    02    00    02    0200  0100  OK
            06    02    00    03    0200  0100  OK
            07    02    00    04    0200  0100  OK
            08    02    00    05    0200  0100  OK

03    0A    00    03    00    02    0800  0100  OK
            01    03    00    03    0800  0100  OK
            02    03    00    04    0800  0100  OK
            03    03    00    05    0800  0100  OK
            04    03    00    06    0800  0100  OK
            05    03    00    07    0800  0100  OK
            06    03    00    08    0800  0100  OK
            07    03    00    09    0800  0100  OK
            08    03    00    00    0800  0100  OK
            09    03    00    01    0800  0100  OK

04    0A    00    04    00    09    1000  0100  OK
            01    04    00    00    1000  0100  OK
            02    04    00    01    1000  0100  OK
            03    04    00    02    1000  0100  OK
            04    04    00    03    1000  0100  OK
            05    04    00    04    1000  0100  OK
            06    04    00    05    1000  0100  OK
            07    04    00    06    1000  0100  OK
            08    04    00    07    1000  0100  OK
            09    04    00    08    1000  0100  OK

05    0A    00    05    00    09    0100  0100  OK
            01    05    00    00    0100  0100  OK
            02    05    00    01    0100  0100  OK
            03    05    00    02    0100  0100  OK
            04    05    00    03    0100  0100  OK
            05    05    00    04    0100  0100  OK
            06    05    00    05    0100  0100  OK
            07    05    00    06    0100  0100  OK
            08    05    00    07    0100  0100  OK
            09    05    00    08    0100  0100  OK
Download is available here
viewtopic.php?f=32&t=14611

User avatar
CMcDougall
Posts: 6093
Joined: Wed Feb 02, 2005 3:13 pm
Location: Shadow in a Valley of Scotland
Contact:

Re: Today I hacked ...

Post by CMcDougall » Thu Jul 12, 2018 6:18 pm

A new 51/4" 40T educational disc from 'Oneswitch'/Barrie.
Olympics for a Micromike. (Graphics really good (much better than Electron User Olympic))

Track1 looked unformatted, ADI rom could not even copy it :shock:

UPURS also said bad track1, end copy also no worky.

Had a word with 'BillCarr' so made a .FSD of it for him to look at, a fail too.

Then I had a eureka moment, may be track1 had sector's 1to9 hidden. BillC confirmed this looking at the *RUN !boot only.

Thoughts were to change the !boot so it stopped after 'loading' the skew machine code. No worky either as it did not like being changed at all at just sat at >_ after a call& :(

noticed a few basic progs on the disc, so copied whole disc to another , used *opt1,2 to see which loaded after the dodgy track1, it was Menu.

changed the copied Menu to 10th

loaded up uncopyable original disc, waited until Intro had finished, swapped in my copy.
Saved off all memory 0to7C00.

Then could get it to work from a .DSD disc with some typing *DR.2, *L. BIT11 (1100 to 7C00), *L. BIT9 (900 to B00), PAGE=&2200, OLD, *DR.0, RUN :D

Passed this disc to BillC, he tidied it up so now not messy and a .SSD !

This is a first for having 8x Sector0s on Track1 :|
ImageImageImage

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

Re: Today I hacked ...

Post by duikkie » Fri Jul 13, 2018 4:09 am

no more people use a system that has more track 0 , my protected disc use bad track 0 , track 1 , track 2 = track 0 and i do not rember but was track 4 not also track 0 .

it only wordks with 8271 , because there you have a command for skip bad tracks. but maybe all chip controles looking for track 0 ? if first track 0 is not found further on disc to find track 0 steping 255 times ???

it i one of the maybe tricks
CMcDougall wrote:
Thu Jul 12, 2018 6:18 pm
A new 51/4" 40T educational disc from 'Oneswitch'/Barrie.
Olympics for a Micromike. (Graphics really good (much better than Electron User Olympic))

Track1 looked unformatted, ADI rom could not even copy it :shock:

UPURS also said bad track1, end copy also no worky.

Had a word with 'BillCarr' so made a .FSD of it for him to look at, a fail too.

Then I had a eureka moment, may be track1 had sector's 1to9 hidden. BillC confirmed this looking at the *RUN !boot only.

Thoughts were to change the !boot so it stopped after 'loading' the skew machine code. No worky either as it did not like being changed at all at just sat at >_ after a call& :(

noticed a few basic progs on the disc, so copied whole disc to another , used *opt1,2 to see which loaded after the dodgy track1, it was Menu.

changed the copied Menu to 10th

loaded up uncopyable original disc, waited until Intro had finished, swapped in my copy.
Saved off all memory 0to7C00.

Then could get it to work from a .DSD disc with some typing *DR.2, *L. BIT11 (1100 to 7C00), *L. BIT9 (900 to B00), PAGE=&2200, OLD, *DR.0, RUN :D

Passed this disc to BillC, he tidied it up so now not messy and a .SSD !

This is a first for having 8x Sector0s on Track1 :|

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

Re: Today I hacked ...

Post by duikkie » Fri Jul 13, 2018 4:18 am

there is one protection on disc i have not seen yet :) , maybe one day someone will use the found "bug"in formating a disc
and use it for protecting a program :) i used it ones for demo was a disc with invator or someting : , with tank en houses at th the bottom of the screen.

but my protecting discs are over for the moment allso programming :( maybe in the future i can focus again :(

the problem is you must can think out of the box, find bugs in chips and use it :)

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

Re: Today I hacked ...

Post by billcarr2005 » Fri Jul 13, 2018 8:22 am

CMcDougall wrote:
Thu Jul 12, 2018 6:18 pm

[snip]
Then I had a eureka moment, may be track1 had sector's 1to9 hidden. BillC confirmed this looking at the *RUN !boot only.

.....

This is a first for having 8x Sector0s on Track1 :|
The sectors aren't hidden, just duplicated IDs, so most copying programs don't find anything past the first (unique) entry

The track has 10 sectors with 256 bytes in each (ie. standard), it's just that the sector IDs have then been altered to be the same.
51 bytes are then read from each sector giving 510 bytes and the loader program adds 2 more bytes of information to the code area, making &200 bytes from &900 to &AFF!

As Colin said, it's the first time I've seen a track with all IDs exactly the same... surprised it wasn't used more... although maybe it was temperamental on different combinations of drives / DFSs
Last edited by billcarr2005 on Fri Jul 13, 2018 8:23 am, edited 1 time in total.

OneSwitch
Posts: 86
Joined: Tue Nov 22, 2011 5:50 pm
Contact:

Re: Today I hacked ...

Post by OneSwitch » Sat Jul 14, 2018 11:25 am

Huge thanks for all your work on preserving MicroMike Olympics. It's a really impressive game, especially one purely aimed at a very niche audience:

https://switchgaming.blogspot.com/2018/ ... ardis.html

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

Re: Today I hacked ...

Post by duikkie » Sat Jul 14, 2018 5:40 pm

how do you see that happening ?

if id is the same the first good id that the head finds it loads in memory ?

so how is it only 51 bytes ? or is there a program that knows load sec and
then if same read again ??


billcarr2005 wrote:
Fri Jul 13, 2018 8:22 am
CMcDougall wrote:
Thu Jul 12, 2018 6:18 pm

[snip]
Then I had a eureka moment, may be track1 had sector's 1to9 hidden. BillC confirmed this looking at the *RUN !boot only.

.....

This is a first for having 8x Sector0s on Track1 :|
The sectors aren't hidden, just duplicated IDs, so most copying programs don't find anything past the first (unique) entry

The track has 10 sectors with 256 bytes in each (ie. standard), it's just that the sector IDs have then been altered to be the same.
51 bytes are then read from each sector giving 510 bytes and the loader program adds 2 more bytes of information to the code area, making &200 bytes from &900 to &AFF!

As Colin said, it's the first time I've seen a track with all IDs exactly the same... surprised it wasn't used more... although maybe it was temperamental on different combinations of drives / DFSs

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

Re: Today I hacked ...

Post by billcarr2005 » Sat Jul 14, 2018 10:21 pm

duikkie wrote:
Sat Jul 14, 2018 5:40 pm
how do you see that happening ?

if id is the same the first good id that the head finds it loads in memory ?

so how is it only 51 bytes ? or is there a program that knows load sec and
then if same read again ??
I didn't see it happening, because i don't have the disk.
Low level code to access the disk drive
It's only 51 bytes so that all 10 sectors have to be read to obtain the code in it's entirity!

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

Re: Today I hacked ...

Post by duikkie » 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 :)
billcarr2005 wrote:
Sat Jul 14, 2018 10:21 pm
duikkie wrote:
Sat Jul 14, 2018 5:40 pm
how do you see that happening ?

if id is the same the first good id that the head finds it loads in memory ?

so how is it only 51 bytes ? or is there a program that knows load sec and
then if same read again ??
I didn't see it happening, because i don't have the disk.
Low level code to access the disk drive
It's only 51 bytes so that all 10 sectors have to be read to obtain the code in it's entirity!
Last edited by duikkie on Sun Jul 15, 2018 5:17 am, edited 1 time in total.

Coeus
Posts: 821
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: Today I hacked ...

Post by Coeus » Sun Jul 15, 2018 8:36 am

duikkie wrote:
Sun Jul 15, 2018 5:16 am
yeah, but how ?
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.
Last edited by Coeus on Sun Jul 15, 2018 8:38 am, edited 1 time in total.

User avatar
CMcDougall
Posts: 6093
Joined: Wed Feb 02, 2005 3:13 pm
Location: Shadow in a Valley of Scotland
Contact:

Re: Today I hacked ...

Post by CMcDougall » Sun Jul 15, 2018 8:49 am

^ yes #1 , BillCarr did mention that on one of my emails, loading the 'bad' track1 into mem &2000 to &2900 and timing things going on.

Below is my DSD copy that used !Boot to do the tricks :evil:

EDIT: original worked on Acorn 1770FDC DFS2.26 & Acorn FDC8271 DFS1.20 , it took about 2 seconds (utter guess) to get the MCode that ends up &900 to &AFF
Attachments
olympics02-MARID(MicroMike 40T.zip
(55.54 KiB) Downloaded 6 times
Last edited by CMcDougall on Sun Jul 15, 2018 8:55 am, edited 2 times in total.
ImageImageImage

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

Re: Today I hacked ...

Post by billcarr2005 » 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

Last edited by billcarr2005 on Sun Jul 15, 2018 11:38 am, edited 1 time in total.

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

Re: Today I hacked ...

Post by duikkie » Sun Jul 15, 2018 11:37 am

by 8271 you don't need track 0 , sec 0 sec1 and sec2. look at my disc protect systeem :). if the 8271 do not find after index hole track 0,sec0,1 it steps 255 times all over de disc to find it :) so track 0 sec1,sec2 can be at track 9
the only thing you have to do is make track 9 the ids for track 0 , 8271 will find your track 0, sec0,sec1 on track 9 :)
(1770 i don't know) . further 8271 has a command bad track register. if you order that track 0 is bad than track 1 is track0 #-o

timing is not good because every discdrive has different timing of moving head and arm discdrive.

i don't know if a 10 sector read of a track read multi sectors with same id ?
never try that :) , it can be that sectors with same id are skiped ?

most of the faults and what the 8271 can do i tryed and used :)
i have still 1 protection i have not seen hacked. and i will not tell :)

all my protection are on this forum , i sometimes called them today i protec or somelike that.
the 8271 was a fine chip , the 1770 reads as a elephant [-X , missing a few command and handle track id different



Coeus wrote:
Sun Jul 15, 2018 8:36 am
duikkie wrote:
Sun Jul 15, 2018 5:16 am
yeah, but how ?
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.

Coeus
Posts: 821
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: Today I hacked ...

Post by Coeus » Sun Jul 15, 2018 2:03 pm

duikkie wrote:
Sun Jul 15, 2018 11:37 am
by 8271 you don't need track 0 , sec 0 sec1 and sec2. look at my disc protect systeem :). if the 8271 do not find after index hole track 0,sec0,1 it steps 255 times all over de disc to find it :) so track 0 sec1,sec2 can be at track 9
the only thing you have to do is make track 9 the ids for track 0 ...
That's an interesting feature. I assume you mean if it does not find the sector between any two index pulses, as by that it knows it has seen a complete revolution.
duikkie wrote:
Sun Jul 15, 2018 11:37 am
the 8271 was a fine chip , the 1770 reads as a elephant [-X , missing a few command and handle track id different
The big advantage of the 1770 was that was available in quantity and therefore available at a sensible price rather than having to pay through the nose for something that was in short supply. The 1770 does not contain drive selection logic but a latch chip is cheap enough and was much less than the difference between the 1770 and the 8271. The 1770 also happens to do double density.

So there is an issue with copy protection that only works on an 8271. Some people never had one - I am one of them. BITD, if I bought a piece of software that refused to work on a 1770 I would have returned it and demanded a refund.
Last edited by Coeus on Sun Jul 15, 2018 2:35 pm, edited 1 time in total.

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

Re: Today I hacked ...

Post by duikkie » Mon Jul 16, 2018 5:31 am

if we want to know what is going on we need the disk track ID from track 0 and track 1
the !boot i think is on the real track 0 , loads track 1 with delayes own nmi routine (&d00)
comparing every loading sector with the one it has loaded in memory at 2000 to 2a00
looking only from 20CC on, till 2100 , 21cc to 2200 every time 51 byters(&33)
track1 program is download to &900 to &b00 (10*51bytes) with &AFE=&08 and &AFF=&0C

so what is on track 1 :)

at end and of !boot it tells *exec !boot what is on &3000 ?

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: 2867
Joined: Fri Feb 07, 2014 3:28 pm
Contact:

Re: Today I hacked ...

Post by duikkie » 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
Last edited by duikkie on Mon Jul 16, 2018 7:17 am, edited 1 time in total.

User avatar
CMcDougall
Posts: 6093
Joined: Wed Feb 02, 2005 3:13 pm
Location: Shadow in a Valley of Scotland
Contact:

Re: Today I hacked ...

Post by CMcDougall » Mon Jul 16, 2018 6:04 pm

viewtopic.php?f=2&t=7190&start=540#p208573
yes working copy & video of it here :

you can see Track1 sector0 with the .DSD I posted, I used ADT rom command *DEX C
nothing can read 1to9 , not even ADI / Enigma rom :x
hence why no original image using .FSD files.
ImageImageImage

User avatar
kieranhj
Posts: 684
Joined: Sat Sep 19, 2015 10:11 pm
Location: Farnham, Surrey, UK
Contact:

Re: Today I hacked ...

Post by kieranhj » Tue Jul 17, 2018 11:46 am

Today I hacked the Elite loader. Probably been done many times before but was easier with the source to hand..!
Bitshifters Collective | Retro Code & Demos for BBC Micro & Acorn computers | https://bitshifters.github.io/

User avatar
flaxcottage
Posts: 3088
Joined: Thu Dec 13, 2012 8:46 pm
Location: Derbyshire
Contact:

Re: Today I hacked ...

Post by flaxcottage » Tue Jul 17, 2018 4:01 pm

Well done, sir! =D>

I remember the feeling BITD when I did it with the original release. It was the first hack I ever made. It took me two days of patiently following the labyrinthine machine code to work out that a piece of code placed values on the stack to re-direct subroutine returns and that data were stored on deleted tracks.

I'd like to say it was easy but then it wasn't. :lol:
- John

Why do I keep collecting Acorn gear? I'm going to need a considerably bigger man-cave. :?

Post Reply