Discussion:
I need help getting disassembled RAM above $D000
Add Reply
TommyGoog
2017-07-18 08:53:41 UTC
Reply
Permalink
Raw Message
I'm currently bootstrap tracing an AppleII diskette (Conflict in Vietnam disk from Asimov) to explore the inner workings of the software. I'm using AppleWin in AppleII+ mode.

I would like to get a nice disassembled listing of the code above $D000 in the "RAMCARD" RAM addressing range.

The bootstrap code first reads from the disk into the lower 48K RAM. Then it modifies the code greatly. It then moves it to the $D000 RAM, and then greatly modifies it again.

I have been able to modify the bootstrap code on the diskette by changing an instruction to BRK (0x00) just after the $D000 RAM code has been modified. Booting the disk will load $D000 properly, modify it, and then drop me into the Monitor with the "*" prompt.

I'd now like to do the equivalent of turning on the printer from the monitor prompt with "1<ctrl>P", and then enter "D000LLLLLLLLLLLLLLLL", with many many "L"s.

Now obviously that will only display the ROM version of memory above $D000 because the monitor resides in the ROM and ROM must be active for the "L" command to work.

I seem to recall a long time ago reading about moving the monitor code to the lower 48K RAM space and then executing it from there, but I don't recall what book that was in or if it was something I read on the Internet.

Alternatively, is there a way to do this using the AppleWin's debugger with it's disassembly ability?

Any ideas or help is appreciated!

Tommy
Delfs
2017-07-18 14:03:58 UTC
Reply
Permalink
Raw Message
Post by TommyGoog
I'm currently bootstrap tracing an AppleII diskette (Conflict in Vietnam disk from Asimov) to explore the inner workings of the software. I'm using AppleWin in AppleII+ mode.
I would like to get a nice disassembled listing of the code above $D000 in the "RAMCARD" RAM addressing range.
The bootstrap code first reads from the disk into the lower 48K RAM. Then it modifies the code greatly. It then moves it to the $D000 RAM, and then greatly modifies it again.
I have been able to modify the bootstrap code on the diskette by changing an instruction to BRK (0x00) just after the $D000 RAM code has been modified. Booting the disk will load $D000 properly, modify it, and then drop me into the Monitor with the "*" prompt.
I'd now like to do the equivalent of turning on the printer from the monitor prompt with "1<ctrl>P", and then enter "D000LLLLLLLLLLLLLLLL", with many many "L"s.
Now obviously that will only display the ROM version of memory above $D000 because the monitor resides in the ROM and ROM must be active for the "L" command to work.
I seem to recall a long time ago reading about moving the monitor code to the lower 48K RAM space and then executing it from there, but I don't recall what book that was in or if it was something I read on the Internet.
Alternatively, is there a way to do this using the AppleWin's debugger with it's disassembly ability?
Any ideas or help is appreciated!
Tommy
Maybe easier to move the code from bank switched upper memory down to lower memory and list it that way... maybe modifying the disk to force the code to load in lower memory.

http://www.applelogic.org/files/AIIETECHREF2.pdf
This book starting at page 79 should be helpful in understanding how to activate the proper memory banks. A quick and dirty memory move program would be needed for the move.

I've seen this info in some cracking texts. Maybe read some of the cracks by 4AM to learn some of the secrets of tracing code and shifting memory around. A great resource there also is Computist magazine.
http://computist.textfiles.com/
Michael 'AppleWin Debugger Dev'
2017-07-18 14:13:05 UTC
Reply
Permalink
Raw Message
Post by TommyGoog
I'm using AppleWin in AppleII+ mode.
I would like to get a nice disassembled listing of the code above $D000 in the "RAMCARD" RAM addressing range.
I'd now like to do the equivalent of turning on the printer from the monitor prompt with "1<ctrl>P", and then enter "D000LLLLLLLLLLLLLLLL", with many many "L"s.
Alternatively, is there a way to do this using the AppleWin's debugger with it's disassembly ability?
Tommy, here is what I would do:

1. With the debugger active (F7) if you press Ctrl-PrintScreen it will copy the disassembly sub-window to the clipboard. One can then paste it into Notepad++, gVim, etc.

The advantage is that you use the `SYM name = addr` to markup functions & variables and see them in the output.

2. You can use the OUT command to turn on/off the Lang. Card (LC) banks.
i.e.
out c080 // turn on LC bank 2
out c081 // turn on ROM
out c088 // turn on LC bank 1

3. You'll probably want a development snapshot (nightly build) of the next version of AppleWin that shows which Lang. Card. Bank is active.

http://peopleofhonoronly.com/michael/dev/applewin/nightlybuild/AppleWin.exe

If you want to wait for an official .exe you'll want to follow when #406 has been merged into master.
https://github.com/AppleWin/AppleWin/issues/406

Hope this helps.
TommyGoog
2017-07-18 21:47:08 UTC
Reply
Permalink
Raw Message
Post by Michael 'AppleWin Debugger Dev'
Hope this helps.
Thank you Michael, especially for describing the "out" command to switch banks, as I was not aware of it (I think yesterday I tried entering just "C080" thinking that might magically work.)

It will be a bit cumbersome to do all memory from D000 to FFFF, but at least it's better than some alternatives.

The use of SYM names is also interesting, but at this point (before examining the code much), I don't have very many symbols defined.

Yesterday when I "installed" the latest released version, I was actually hoping to see AppleWin display the active Language Card bank, but it's good to know that feature is coming.

And with the help of Google, I "remembered" where I had read about moving the "old" system monitor to lower RAM. It was in a manual I got with my very first AppleII computer (without the "+", "e" or "c" appended). The manual is "Programmer's Aid #1" which accompanied the chip installed in the $D0 ROM socket. The description is Example 8 on P. 24.

And on yet another tangent, the manual "Programmer's Aid #1" at Asimov is a badly OCR'd version of the document. For example, p. 24 under (b) has this:

"700<F700.FFFF ctrl * return"

but the actual document has:

"700<F700.FFFF ctrl Y * return

The bootstrap code for "Conflict in Vietnam" follows the description in the Programmer's Aid manual of breaking the code into segments of code and data before modifying and relocating it to the Language Card addresses ($D000..$DFFF).

Well, looks like I have some copying and pasting to get to.

Tommy
Michael 'AppleWin Debugger Dev'
2017-07-18 22:18:54 UTC
Reply
Permalink
Raw Message
Post by TommyGoog
Thank you Michael, especially for describing the "out" command to switch banks, as I was not aware of it (I think yesterday I tried entering just "C080" thinking that might magically work.)
Glad the info. helped!
Post by TommyGoog
It will be a bit cumbersome to do all memory from D000 to FFFF, but at least it's better than some alternatives.
Speaking of making this less tedious and wish-list features ...

Since Ctrl-PrintScreen will only do one "screen" of disassembly it sounds like you would like like a feature where you could trigger the debugger copy/paste from a debugger command, ideally an address range to annotate, and save it to a file?

Currently, you can use the debugger RUN to run a debugger script -- but without the ability to trigger saving the disassembly this isn't really useful.

I'd imagine you would want a future debugger command like this:

disasm D000:FFFF,"game_lc.txt"

to get a nice annotated disassembly that AppleWin uses.

I'm doing more and more disassembly these days so I'll add this to my internal wishlist of features since I could use the same thing. :-)
Post by TommyGoog
The use of SYM names is also interesting, but at this point (before examining the code much), I don't have very many symbols defined.
One thing I do when disassembling (games) is to make a debugger script. i.e. Here is a very tiny snippet from an actually Apple 2 game I'm currently reverse engineering.

- - -8< foo - - -

// AppleWin Debugger Script for Game: Foo
symmain off
symbasic off
symuser clear

db HgrPage 94 // Which page we are drawing on

// Player
db P.Items E1 // PlayerNumInventory
db P.Inv1 E2 // PlayerInventorySlot1
db P.Inv2 E3 // PlayerInventorySlot1
db P.Inv3 E4 // PlayerInventorySlot1
db P.Inv4 E5 // PlayerInventorySlot1
db P.Inv5 E6 // PlayerInventorySlot1

// Funcs
sym MemCpy = b000 // @bf12
sym .memcopy1 = b00d
sym .memcopy2 = b00e
sym .memcopydone = b021

- - -8< foo - - -

I also use the F11/F12 to load/save the Apple State.

As I figure the function and variable names out, I update the text file "Foo", and have the debugger use them by executing the script via:

RUN foo

That way you can fix typo's and take your time to figure out the locations.

You can also use the C++ comment // for a line comment.
Post by TommyGoog
Yesterday when I "installed" the latest released version, I was actually hoping to see AppleWin display the active Language Card bank, but it's good to know that feature is coming.
Soon!
Post by TommyGoog
And on yet another tangent, the manual "Programmer's Aid #1" at Asimov is a badly OCR'd version of the document.
Sadly, quite a few PDF's haven't been OCR'd properly. :-/

We really should get a list of which PDF's need to be touched up and edited someday.
TommyGoog
2017-07-19 00:33:23 UTC
Reply
Permalink
Raw Message
Post by TommyGoog
The manual is "Programmer's Aid #1" which accompanied the chip installed in
the $D0 ROM socket.
The bootstrap code for "Conflict in Vietnam" follows the description in the
Programmer's Aid manual of breaking the code into segments of code and data
before modifying and relocating it to the Language Card addresses
($D000..$DFFF).
Tommy
This was a prescient observation I made earlier today. In the Applewin GitHub issue for "Conflict in Vietnam", sicklittlemonekey posted that CIV is compiled with Galfo Systems "Integer Basic Compiler":

http://www.willegal.net/appleii/IBC.html

In the documentation for that compiler (http://www.willegal.net/appleii/CH%20Galf%20int%20basic%20doc.pdf) is the following reference on P 29:

1) HI-RES use of PROGRAMMER´S AID #1 ROM.

It would seem that the behavior of the code I am bootstrap tracing was likely influenced by Programmer's Aid #1!


Tommy
James Davis
2017-07-18 20:11:27 UTC
Reply
Permalink
Raw Message
Post by TommyGoog
I'm currently bootstrap tracing an AppleII diskette (Conflict in Vietnam disk from Asimov) to explore the inner workings of the software. I'm using AppleWin in AppleII+ mode.
I would like to get a nice disassembled listing of the code above $D000 in the "RAMCARD" RAM addressing range.
The bootstrap code first reads from the disk into the lower 48K RAM. Then it modifies the code greatly. It then moves it to the $D000 RAM, and then greatly modifies it again.
I have been able to modify the bootstrap code on the diskette by changing an instruction to BRK (0x00) just after the $D000 RAM code has been modified. Booting the disk will load $D000 properly, modify it, and then drop me into the Monitor with the "*" prompt.
I'd now like to do the equivalent of turning on the printer from the monitor prompt with "1<ctrl>P", and then enter "D000LLLLLLLLLLLLLLLL", with many many "L"s.
Now obviously that will only display the ROM version of memory above $D000 because the monitor resides in the ROM and ROM must be active for the "L" command to work.
I seem to recall a long time ago reading about moving the monitor code to the lower 48K RAM space and then executing it from there, but I don't recall what book that was in or if it was something I read on the Internet.
Alternatively, is there a way to do this using the AppleWin's debugger with it's disassembly ability?
Any ideas or help is appreciated!
Tommy
Hi Tommy,

Sounds like an interesting project you have.

Do you know about the CiderPress Archive Utility? It can source your code right off of a disk-image of any Apple II software/progam disk. And, you can copy that/it into a text file, and read it in any text editor.

It would be interesting to capture the modified code at each step of the way though--which is what I assume you are trying to do by "bootstrap tracing" a diskette. For that you will need something like the following "M/L Relocater":

Back in the day (Oct.'83) I wrote a "Machine Language (M/L) Relocation Module" in 6502 Assembly that I could scan into a PDF and upload to Asimov
for you (and everyone), if you are interested in using it. I don't remember how it works, so you might also have to figure that out yourself.

Let me know (here) if you want it.

James Davis
Michael 'AppleWin Debugger Dev'
2017-07-18 21:00:55 UTC
Reply
Permalink
Raw Message
Post by James Davis
Do you know about the CiderPress Archive Utility?
It can source your code right off of a disk-image of any Apple II software/program disk.
That's assuming Tommy is using a "ripped" copy which has been loaded onto a DOS / ProDOS disk.

If Tommy is using a minimal "cracked" copy that has been converted to a regular 16-sector image then there may be no standard file system that CiderPress can use/read.

The DSK image in question can be found under:
ftp://ftp.apple.asimov.net/pub/apple_II/images/games/strategy/

of which there are two:

* Conflict In Vietnam (1986)(Microprose)[cr](Disk 1 of 1 Side A).zip
* ConflictInVietnam1.dsk

I was curious and took a look at both disks.

The latter looks like it has minimal DOS commands on T$0S$B @ $80:

DLD
SAVE
LOCK
UNLOCK

The normal DOS3.3 commands can be found on T$1S$7.

Track 1, Sector 9 @ $75 runs the startup program: \\

It looks like it is a modified DOS3.3 since the DOS3.3 file types can be found at Track 2, Sector 2, @ $A7: TIABSRAB, and the DOS3.3 error message on Track 2, Sector 8.

Sure enough it has a DOS 3.3 catalog on T11SF so CiderPress might be an option.

Taking a look at the first DSK it looks like it is very similar to the second DSK.

NOTE: There is the file "G" starts on Track $11, Sector $6 -- right in the middle of the normal Catalog track !

Some programs also use a hybrid approach. i.e. Fantavision has a ProDOS volume for data files but the actual binary itself is directly loaded from Tracks $17 .. $21 with a nibble count on Track $22. While the nibble count has been patched to ignore track $22 via the cracks there is no standard file entry in the ProDOS volume for the binary. :-/

Looks like Tommy lucked out here. ;-)
TommyGoog
2017-07-18 22:12:58 UTC
Reply
Permalink
Raw Message
Post by Michael 'AppleWin Debugger Dev'
ftp://ftp.apple.asimov.net/pub/apple_II/images/games/strategy/
* Conflict In Vietnam (1986)(Microprose)[cr](Disk 1 of 1 Side A).zip
* ConflictInVietnam1.dsk
I was curious and took a look at both disks.
DLD
SAVE
LOCK
UNLOCK
Indeed I am using the Asimov Conflict In Vietnam disks. Although there are 2 "versions" at Asimov, someone else indicated they were identical. I haven't checked.

The game does use a modified DOS at least during the bootstrap code. But your comment about "minimal DOS commands" is not necessarily correct. During the bootstrap load, (from Track $1 Sector 7), and initially loaded to $A884 are these strings :

INIT, LOAD, SAVE, RUN, CHAIN, DELETE, LOCK, UNLOCK, CLOSE, READ, EXEC, POSITION, OPEN, APPEND, RENAME, CATALOG, MON, NOMON, PR#, IN#, MAXFILES, FP,
INT, BSAVE, BLOAD, BRUN, VERIFY.

In addition, part of the modification code changes "CHAIN" to "TLIST", and "INT" to "PAD".

Tommy
Michael 'AppleWin Debugger Dev'
2017-07-18 22:24:55 UTC
Reply
Permalink
Raw Message
Post by TommyGoog
Although there are 2 "versions" at Asimov, someone else indicated they were identical. I haven't checked.
Let's try to authoritatively answer that ...

unzip Conflict\ In\ Vietnam\ \(1986\)\(Microprose\)\[cr\]\(Disk\ 1\ of\ 1\ Side\ A\).zip
hexdump Conflict\ In\ Vietnam\ \(1986\)\(Microprose\)\[cr\]\(Disk\ 1\ of\ 1\ Side\ A\).dsk > a
hexdump ConflictInVietnam1.dsk > b
diff a b

... so, yes, they are byte for byte identical.
Post by TommyGoog
INIT, LOAD, SAVE, RUN, CHAIN, DELETE, LOCK, UNLOCK, CLOSE, READ, EXEC, POSITION, OPEN, APPEND, RENAME, CATALOG, MON, NOMON, PR#, IN#, MAXFILES, FP,
INT, BSAVE, BLOAD, BRUN, VERIFY.
Ah, gotcha. Guess I jumped the gun on that one. :-) I see the standard DOS3.3 commands are present in one of my earlier posts but didn't pay too much attention to that.
Post by TommyGoog
In addition, part of the modification code changes "CHAIN" to "TLIST", and "INT" to "PAD".
Yeah, that's pretty standard fare for early DOS games -- change a few commands so the user has no clue unless they inspect the memory.
James Davis
2017-07-19 01:36:49 UTC
Reply
Permalink
Raw Message
Post by Michael 'AppleWin Debugger Dev'
unzip Conflict\ In\ Vietnam\ \(1986\)\(Microprose\)\[cr\]\(Disk\ 1\ of\ 1\ Side\ A\).zip
hexdump Conflict\ In\ Vietnam\ \(1986\)\(Microprose\)\[cr\]\(Disk\ 1\ of\ 1\ Side\ A\).dsk > a
hexdump ConflictInVietnam1.dsk > b
diff a b
... so, yes, they are byte for byte identical.
Michael,

Have you tried ExamDiff (v1.9) Freeware Visual File Comparison Tool <http://www.prestosoft.com/edp_examdiff.asp>?

James Davis
Michael 'AppleWin Debugger Dev'
2017-07-19 01:43:38 UTC
Reply
Permalink
Raw Message
Post by TommyGoog
Michael,
Have you tried ExamDiff (v1.9) Freeware Visual File Comparison Tool <http://www.prestosoft.com/edp_examdiff.asp>?
Sorry, no. I'm sure there are a TON of GUI Visual Diff tools but I tend to use command line utilities that are a) open source, and b) I can use across Windows, OSX, and Linux, or write my own.
Michael 'AppleWin Debugger Dev'
2017-07-18 21:05:39 UTC
Reply
Permalink
Raw Message
Post by TommyGoog
I'm currently bootstrap tracing an AppleII diskette (Conflict in Vietnam disk from Asimov) to explore the inner workings of the software. I'm using AppleWin in AppleII+ mode.
Taking a look at the boot program "\\", on Track $F, Sector $2, it has this at the end:

RUNS
BRUNA

Since DOS 3.3 ignores spaces after commands this is the same as:

RUN S
BRUN A
Michael 'AppleWin Debugger Dev'
2017-07-18 21:13:16 UTC
Reply
Permalink
Raw Message
Post by TommyGoog
I'm currently bootstrap tracing an AppleII diskette (Conflict in Vietnam disk from Asimov) to explore the inner workings of the software. I'm using AppleWin in AppleII+ mode.
Startup Program \\ loads at $200, the keyboard buffer location

Applesoft program "S", relevant lines:

10 HOME: CALL 08615
60 PRINT "BLOADG":PRINT "BRUNA"

G loads @ $0800
A loads @ $5500
Nick Westgate
2017-07-18 22:53:31 UTC
Reply
Permalink
Raw Message
Post by TommyGoog
Any ideas or help is appreciated!
Since you're doing this in AppleWin you could possibly save the memory directly to a file on your PC. Michael hasn't mentioned that below, and I don't know the command off-hand. Then you could import the file into a disk image.

Personally, I would simply boot a DOS disk and write a quick assembly language routine (in the mini-assembler - then save it to disk) to access $C080 and move $D000-FFFF down into main RAM. Then you can BSAVE it to disk.

Then as James suggests I would open the disk in CiderPress, change the aux type to $D000 and double-click the file to view the disassembly.

Cheers,
Nick.
Michael 'AppleWin Debugger Dev'
2017-07-18 23:03:32 UTC
Reply
Permalink
Raw Message
Post by Nick Westgate
Post by TommyGoog
Any ideas or help is appreciated!
Since you're doing this in AppleWin you could possibly save the memory directly to a file on your PC. Michael hasn't mentioned that below, and I don't know the command off-hand. Then you could import the file into a disk image.
In the debugger:

BSAVE "langcard.bin",D000:FFFF

Thanks for the the nudge Nick. :-)
TommyGoog
2017-07-19 00:20:49 UTC
Reply
Permalink
Raw Message
On Tuesday, July 18, 2017 at 5:53:33 PM UTC-5, Nick Westgate wrote:

Thank you for the suggestions Nick.
Since you're doing this in AppleWin you could possibly save the memory directly to a file on your PC.... Then you could import the file into a disk image.
I'm not sure what you mean by "import the file into a disk image". Could you explain this a bit more?
Personally, I would simply boot a DOS disk and write a quick assembly language routine (in the mini-assembler - then save it to disk) to access $C080 and move $D000-FFFF down into main RAM. Then you can BSAVE it to disk.
Then as James suggests I would open the disk in CiderPress, change the aux type to $D000 and double-click the file to view the disassembly.
I'm not currently using CiderPress. I guess that's one more thing for me to start learning how to use.

Tommy
Michael 'AppleWin Debugger Dev'
2017-07-19 00:46:22 UTC
Reply
Permalink
Raw Message
Post by TommyGoog
Since you're doing this in AppleWin you could possibly save the memory directly to a file on your PC.... Then you could import the file into a disk image.
I'm not sure what you mean by "import the file into a disk image". Could you explain this a bit more?
What Nick is getting at is taking a memory snapshot -- basically saving it to disk.

There are a few ways to do this. The easiest way is probably to use the debugger.

F7
bsave "langcard.bin",D000:FFFF
F7
eject CIV disk
insert DOS data disk
boot it
F7
bload "langcard.bin",2000
F7
BSAVE CIV.LC.BIN,A$2000,L$3000
Post by TommyGoog
Personally, I would simply boot a DOS disk and write a quick assembly language routine (in the mini-assembler - then save it to disk) to access $C080 and move $D000-FFFF down into main RAM. Then you can BSAVE it to disk.
Alternatively, you could write a small program to save the LC contents.
i.e.

!300: LDA $C080
LDA $C080
LDX #0
LDA $D000,X
STA $2000,X
INX
BNE $308
INC $309
INC $30C
LDA $309
BNE $306
STA $C081
STA $C081
RTS

Which assembles to:

300:AD 80 C0 AD 80 C0 A2 00
308:BD 00 D0 9D 00 20 E8 D0
310:F7 EE 09 03 EE 0C 03 AD
318:09 03 D0 EA 8D 81 C0 8D
320:81 C0 60

Save it via:

BSAVE MOVE.LC.BIN,A$300,L$23

Then whenever you need to save the LC

BRUN MOVE.LC.BIN
BSAVE CIV.LC.BIN,A$2000,L$3000

Hope this helps
Nick Westgate
2017-07-19 02:45:03 UTC
Reply
Permalink
Raw Message
On Wednesday, 19 July 2017 12:46:24 UTC+12, Michael 'AppleWin Debugger Dev' > > Alternatively, you could write a small program to save the LC contents.

Yes, like that.

Although you don't need two accesses to any switches in this case (since we don't need to write-enabled the LC.)

Cheers,
Nick.
TommyGoog
2017-07-25 07:34:59 UTC
Reply
Permalink
Raw Message
Post by Michael 'AppleWin Debugger Dev'
Alternatively, you could write a small program to save the LC contents.
i.e.
!300: LDA $C080
LDA $C080
LDX #0
LDA $D000,X
STA $2000,X
INX
BNE $308
INC $309
INC $30C
LDA $309
BNE $306
STA $C081
STA $C081
RTS
300:AD 80 C0 AD 80 C0 A2 00
308:BD 00 D0 9D 00 20 E8 D0
310:F7 EE 09 03 EE 0C 03 AD
318:09 03 D0 EA 8D 81 C0 8D
320:81 C0 60
BSAVE MOVE.LC.BIN,A$300,L$23
Hope this helps
The program does not work as advertised.

You are incrementing the low order byte for the source and destination address, and also checking the low order byte to see if you have completed the transfer. Obviously you want to be working with the high order bytes.


0300- AD 80 C0 LDA $C080
0303- AD 80 C0 LDA $C080
0306- A2 00 LDX #$00
0308- BD 00 D0 LDA $D000,X
030B- 9D 00 20 STA $2000,X
030E- E8 INX
030F- D0 F7 BNE $0308
0311- EE 0A 03 INC $030A
0314- EE 0D 03 INC $030D
0317- AD 0A 03 LDA $030A
031A- D0 EA BNE $0306
031C- 8D 81 C0 STA $C081
031F- 8D 81 C0 STA $C081
0322- 60 RTS

0300- AD 80 C0 AD 80 C0 A2 00
0308- BD 00 D0 9D 00 20 E8 D0
0310- F7 EE 0A 03 EE 0D 03 AD
0318- 0A 03 D0 EA 8D 81 C0 8D
0320- 81 C0 60

Previously I had used the "cut and paste" method to get a disassembled listing of code above $D000, but now I found a need for this transfer code.

Tommy
Michael 'AppleWin Debugger Dev'
2017-07-25 15:08:19 UTC
Reply
Permalink
Raw Message
Post by TommyGoog
You are incrementing the low order byte for the source and destination address, and also checking the low order byte to see if you have completed the transfer. Obviously you want to be working with the high order bytes.
Whoops, I had an off-by-one bug. Yes you are correct. That will teach me to post code without first verifying it works. ;-)
James Davis
2017-07-19 01:43:29 UTC
Reply
Permalink
Raw Message
Post by TommyGoog
I'm not currently using CiderPress. I guess that's one more thing for me to start learning how to use.
Tommy,

Some sources for CiderPress:

ftp://public.asimov.net/pub/apple_II/documentation/misc/ciderpress_tutorial.pdf

ftp://public.asimov.net/pub/apple_II/unsorted/Multi-Disk Catalog - User Manual (Sensible Software, 1981).pdf

ftp://public.asimov.net/pub/apple_II/utility/CiderPress Features.txt

ftp://public.asimov.net/pub/apple_II/utility/CiderPress Tutorial-samples.zip

ftp://public.asimov.net/pub/apple_II/utility/CiderPress301.asm

ftp://public.asimov.net/pub/apple_II/utility/CiderPress301.zip

ftp://public.asimov.net/pub/apple_II/utility/CiderPress302d1.zip

ftp://public.asimov.net/pub/apple_II/utility/CiderPress400-stable release.zip

ftp://public.asimov.net/pub/apple_II/utility/CiderPress400d1.zip

ftp://public.asimov.net/pub/apple_II/utility/CiderPress401.zip

ftp://public.asimov.net/pub/apple_II/utility/CiderPressSrc301.zip


http://a2ciderpress.com/

http://github.com/fadden/ciderpress/


James Davis
Nick Westgate
2017-07-19 02:37:00 UTC
Reply
Permalink
Raw Message
Post by TommyGoog
I'm not sure what you mean by "import the file into a disk image". Could you explain this a bit more?
If you BSAVE from AppleWin, the file will be on your PC's HDD.

You'll need to get it into a disk image to then open with CiderPress to get the disassembly. You can do that with CiderPress or whatever other disk image tools you use.

But Michael has given you a way to do it with BSAVE and BLOAD in AppleWin (then BSAVE in DOS).

Cheers,
Nick.
TommyGoog
2017-07-23 04:39:41 UTC
Reply
Permalink
Raw Message
I'm currently bootstrap tracing an AppleII diskette (Conflict in Vietnam disk from Asimov) to explore the inner workings of the software.> Tommy
Here is an update of my investigations to the boot process for "Conflict in Vietnam" (Civ).

The DOS that boots Civ is a variation of DiversiDos (which is a variation of DOS3.3 from 1980).

The starting point of the DOS on CiV seems to be one of the following:

Diversi-Copy 1.0.dsk
DiversiCopy3.1.dsk

There are 1 or 2 additional changes to the DiversiDos on CiV that do not appear in any of the DiversiDos images on Asimov. I'm not familiar with DiversiDos to know if it might make those additional changes while "cracking" the original CiV.

Without the original disk image for "Conflict in Vietnam", it is impossible(?) to know if it had DiversiDos to begin with, or if the "cracking" of CiV by Kristo put DiversiDos on the image that now resides on Asimov. Since the program was apparently written using Galfo Systems Integer Basic Compiler, either scenario seems likely.

Tommy
Antoine Vignau
2017-07-23 05:10:28 UTC
Reply
Permalink
Raw Message
Kristo is Godfather's brother, aka GDF. GFF was a well-known pirate in France,

av
Nick Westgate
2017-07-23 22:45:13 UTC
Reply
Permalink
Raw Message
Post by TommyGoog
Without the original disk image for "Conflict in Vietnam", it is impossible(?) to know if it had DiversiDos to begin with
You should have a look at the other Microprose titles for which there are NIBs on asimov. The protection is very similar, they use Galfo IBC, so I think the build of the disks - DOS etc is probably also similar.

Did you see Kristo's tribute on the disk? (Track $22.)

Antoine translated it for me:
"Ce déplombage est dédié à Coluche qui n'y connaissait rien à l'informatique."

"This crack is dedicated to Coluche, who knew nothing about IT."

That is, he seems to dedicate it to:
https://en.wikipedia.org/wiki/Coluche
Which dates the crack I guess.

Cheers,
Nick.
TommyGoog
2017-07-24 10:54:49 UTC
Reply
Permalink
Raw Message
Post by Nick Westgate
You should have a look at the other Microprose titles for which there are NIBs on asimov. The protection is very similar, they use Galfo IBC, so I think the build of the disks - DOS etc is probably also similar.
Did you see Kristo's tribute on the disk? (Track $22.)
Nick.
Ty Nick for pointing out Kristo's Track $22 tribute to Coluche(!!) and the link to his wiki.

I looked briefly at one of the other MicroProse disks earlier this week and realized the boot processes were identical, but didn't pursue it much.

I think I'm getting too old to do this kind of code exploration. I keep getting side tracked and falling down rabbit holes (Just ask Alice, and if you can make the connection between rabbit holes and "Conflict in Vietnam"...well I've got a "plane" to catch.)

Early in the boot process I noticed the code checked for an <esc> key press. Using AppleWin, I booted and pressed <esc>. To my surprise nothing unusual happened. Then I tried pressing the <esc> key multiple times during the boot process and got the message:

PROGRAM REQUIRES MINIMUM 64K MEMORY
AND APPLESOFT ON MOTHERBOARD

Next I tried booting the disk in AppleWin using AppleII (original) mode expecting to see that message, and all it did was hang (after I first remembered to enter "C600G").

Then I discovered that I had AppleWin's "Disk access speed:" set to "Enhanced Speed". So I changed it to "Authentic Speed" and tried a few more things.

Later I came to realize what the <esc> key processing was all about.

I should have learned early on by "Michael 'AppleWin Debugger Dev" comments in this thread that I could actually examine the CiV disk using normal DOS.

I started making comparisons between the CiV boot code and what I thought was a normal DOS disk (MASTER.DSK) as found in the AppleWin directory. Eventually I compared DOS3.3 (from 1980) and DOS3.3 (from 1983) with MASTER.DSK and discovered MASTER.DSK did not match either of the DOS3.3 code exactly.

And very oddly enough I discovered that MASTER.DSK DOS boot load code more closely matched CiV than did either of the Dos3.3 disks!

And at some point I noticed this difference at $B3AF:

"#C RSD 3891C"

It replaced this string:

" EMULOV KSID"

This led me to the discovery that the CiV disk image was created using DiversiDos (or DiversiCopy) some time after 1983.

So next I started down the path of examining Diversi software (which I was unfamiliar with) by downloading disks from Asimov.

The documentation for Diversi is a bit of a rambling stream-of-consciousness document, with some parts rather scary. Let me share one piece that cracks me up every time I read the last sentence:

+++++

To speed up DOS even more, change the
motor start time to 1/2 sec with:

POKE 47102,236

99% of drives will work correctly this
way. However, an occasional drive
will destroy disks.

+++++

If you run Diversi-DOS (Diversi-DOS_4c.dsk) you can create a boot image very similar to CiV. First you initialize a blank disk using "Apple DOS 3.3 August 1980.dsk". Be sure to use the 1980 version, not the 1983 version. Then run Diversi-DOS and choose 2 "PUT DIVERSI-DOS ONTO A DISK" , and answer "Y" to "INSTALL FREE SECTOR PATCH?", and note the message at the very top of the screen "REMOVE THIS DISK (DIVERSI-DOS MASTER)", which of course I did not do the first time....Alice? Where are you?.... And next choose 'D' for "64K DOS".

After all that, you will have a boot disk which very very closely matches the CiV boot process. I've compared sequences of code from $9D00..$BFFF and found only a few minor differences, although there is one that I do not understand. If anyone could explain it to me I'd appreciate it. The normal code for DOS3.3 is this:

9EF3- AE 51 AA LDX $AA51
9EF6- F0 08 BEQ $9F00 *****
9EF8- C9 BF CMP #$BF
9EFA- F0 75 BEQ $9F71
9EFC- C5 33 CMP $33
9EFE- F0 27 BEQ $9F27 *****

The code in CiV (which is different from any code I've seen so far from Diversi) is this:

9EF3- AE 51 AA LDX $AA51
9EF6- F0 04 BEQ $9EFC *****
9EF8- C9 BF CMP #$BF
9EFA- F0 75 BEQ $9F71
9EFC- C5 33 CMP $33
9EFE- F0 71 BEQ $9F71 *****

I'm using Michael Pohoreski's fine work-in-progress in Github (apple2_dos33):

https://htmlpreview.github.io/?https://github.com/Michaelangel007/apple2_dos33/blob/master/dos33.html

...you can find this code after the label "COS00". You can also see a nice "state handler" flowchart that is displayed following label "EWRITE".

I've stared at the diagram, looked at "Beneath Apple Dos", stared at the CiV code, stared at DOS3.3 code, and my head is spinning trying to answer the questions, "why is this code different?" and "what are the consequences of the differences".

By the way, Diversi-DOS dynamically alters DOS in the range $9D00..$BFFF using a process similar to "Programmer's Aid #1" code for "relocating machine code". Heck it even uses the same MONITOR subroutine $F88E INSDS2 to determine the number of bytes in the instruction. Talk about your rabbit holes! Tom, get back on track again!

Once those changes are made to $9D00..$BFFF the code is moved to the RAM card at $DD00..FFFF. Next an additional 70+ "patches" are applied to the code, and eventually the DOS boot process is completed.

And to answer the question about the <esc> key from earlier: Pressing the <esc> key during the boot process for a diskette created with Diversi-DOS prevents DOS from being relocated to the RAM card at $DD00.

Well, time to find some more rabbit holes.

Tommy
Antoine Vignau
2017-07-24 12:26:52 UTC
Reply
Permalink
Raw Message
The Galfo Integer basic floppy contains a disassembler of the compiled code.
It would be interesting to know if Microprose used an enhanced version of Galfo's runtime or not.

Antoine
Michael 'AppleWin Debugger Dev'
2017-07-24 15:38:09 UTC
Reply
Permalink
Raw Message
Post by TommyGoog
I should have learned early on by "Michael 'AppleWin Debugger Dev" comments in this thread that I could actually examine the CiV disk using normal DOS.
:-)

NOTE: I go by all 3 names: Michael Pohoreski, Michael 'AppleWin Debugger Dev", Michaelangel007
Post by TommyGoog
First you initialize a blank disk using "Apple DOS 3.3 August 1980.dsk". Be sure to use the 1980 version, not the 1983 version.
I guess I'll have to mark up the differences between the 1980 and 1983 versions too ...
Post by TommyGoog
https://htmlpreview.github.io/?https://github.com/Michaelangel007/apple2_dos33/blob/master/dos33.html
Glad to see someone else is finding my HTML annotated version of DOS33.3 source code useful -- I figured I couldn't be the only one!

I made some progress this weekend on getting another few pages done -- the link you used will always have the latest changes.

Currently these 13 pages of the assembly source still need to be typed up and converted to plain text.

* Page 71
* Page 82-84
* Pages 116-121
* Page 126
* Pages 134-136

And then marked up, and opcodes added, etc. Slowly but surely this project is getting done.

AppleWin debugger symbols are also eventually coming which is why i started this project.

Also I have plans to _fully_ document the ProntoDOS and Diversi-DOS changes once it is done -- since I _very_ curious to know _exactly_ what bytes were changed with ProntoDOS.
Post by TommyGoog
You can also see a nice "state handler" flowchart that is displayed following label "EWRITE".
Just a note that I'll eventually be circling back and cleaning up that flowchart -- now that I actually have names for some of the states -- but great to hear it was useful !

Michael "Michaelangel007" Pohoreski, aka AppleWin Debugger Maintainer
qkumba
2017-07-24 18:08:10 UTC
Reply
Permalink
Raw Message
Post by Michael 'AppleWin Debugger Dev'
Also I have plans to _fully_ document the ProntoDOS and Diversi-DOS changes once it is done -- since I _very_ curious to know _exactly_ what bytes were changed with ProntoDOS.
Don't forget to document the Diversi-DOS easter egg, in that case.
You'll know it when you see it. :-)
Michael 'AppleWin Debugger Dev'
2017-07-26 20:08:27 UTC
Reply
Permalink
Raw Message
Post by qkumba
Post by Michael 'AppleWin Debugger Dev'
Also I have plans to _fully_ document the ProntoDOS and Diversi-DOS changes once it is done -- since I _very_ curious to know _exactly_ what bytes were changed with ProntoDOS.
Don't forget to document the Diversi-DOS easter egg, in that case.
You'll know it when you see it. :-)
Cool -- I don't know about that one! Looking forward to (re)discovering it. :-)
Michael 'AppleWin Debugger Dev'
2017-07-24 15:45:06 UTC
Reply
Permalink
Raw Message
Post by TommyGoog
9EF3- AE 51 AA LDX $AA51
9EF6- F0 08 BEQ $9F00 *****
9EF8- C9 BF CMP #$BF
9EFA- F0 75 BEQ $9F71
9EFC- C5 33 CMP $33
9EFE- F0 27 BEQ $9F27 *****
9EF3- AE 51 AA LDX $AA51
9EF6- F0 04 BEQ $9EFC *****
9EF8- C9 BF CMP #$BF
9EFA- F0 75 BEQ $9F71
9EFC- C5 33 CMP $33
9EFE- F0 71 BEQ $9F71 *****
As you know DOS3.x on a 64K machine is relocated up by $80 pages. The code at $9EF3 is originally loaded @ $1EF3 -- here is the snippet from source:

1EF3:AE 51 2A 075 COS00 LDX ISTATE ;IS IN STATE NOT ZERO
1EF6:F0 08 076 BEQ COS01 ;
1EF8:C9 BF 077 CMP #'?'+$80 ; THEN IS THIS ?
1EFA:F0 75 078 BEQ COS6 ; THEN PRINT ONLY IF MONITOR
1EFC:C5 33 079 CMP PROMPT
1EFE:F0 27 080 BEQ COS2A

Looks like a bug-fix to the state table was made?
TommyGoog
2017-07-24 17:50:36 UTC
Reply
Permalink
Raw Message
I think "it depends".

If I initialize a blank diskette using DOS3.3(1983) with AppleWin in AppleII+ mode it is a "slave" diskette and when booted the initial load of DOS is to $9B00..$BFFF which is also its final resting place. Even if I boot that diskette on an AppleIIe, the initial load (and final resting place) is to $9B00. This discussion assumes AppleII+ is 48K bytes RAM on the motherboard. AppleII+ machines with less than 48K RAM wouldn't even be able to boot it.

If I modify the diskette to be a "master" diskette, then I think the initial load is to $1D00 (relocation code to $1B00) and it gets moved upwards to $9D00(or higher on IIe?)
Post by Michael 'AppleWin Debugger Dev'
Looks like a bug-fix to the state table was made?
It is not one of the DOS3.3(1983) documented fixes.
Michael 'AppleWin Debugger Dev'
2017-07-24 18:31:34 UTC
Reply
Permalink
Raw Message
Post by TommyGoog
I think "it depends".
Right -- I was assuming a "Master" disk. If a "Slave" disk, then all bets are off, since it could be anywhere in the 48K (well, anywhere between $1B00 ... and $9B00)
Post by TommyGoog
If I modify the diskette to be a "master" diskette, then I think the initial load is to $1D00 (relocation code to $1B00) and it gets moved upwards to $9D00(or higher on IIe?)
According to my understanding it is $1B00

00132 096 ORG ORIGIN
00133 097 *
00134 098 *
00135 099 REP 40
00136 100 PAGE
1B00:4C 84 1D 00137 101 BEGIN JMP DBINIT ; === DOS loads @ $1B00 ===

I've marked up the load address locations my commentary

00004 004 ORIGIN EQU $1B00

00008 008 INCLUDE RELOCTR,,2 ; $1B00 .. $1C80, T0SA - T0SB
00009 009 INCLUDE DOSINIT,,2 ; $1C81 .. $1E80, T0SB - T0SD
00010 010 INCLUDE DOSHOOK,,2 ; $1E81 .. $1FCC, T0SD - T0SE
00011 011 INCLUDE CMDSCAN,,2 ; $1FCD .. $2192, T0SE - T1S0
00012 012 INCLUDE XOPNCLS,,2 ; $2193 .. $2330, T1S0 - T1S2
00013 013 INCLUDE XLODSAV,,2 ; $2331 .. $250F, T1S2 - T1S4
00014 014 INCLUDE XMISCMD,,2 ; $2510 .. $26A7, T1S4 - T1S5
00015 015 INCLUDE DOSGOER,,2 ; $26A8 .. $27D3, T1S5 - T1S6
00016 016 INCLUDE BLDFTAB,,2 ; $27D4 .. $2883, T1S6 - T1S7
00017 017 INCLUDE CMDTBLS,,2 ; $2884 .. $2A4E, T1S7 - T1S9
00018 018 INCLUDE FDOSENT,,2 ; $2A4F .. $2B21, T1S9 - T1SA
00019 019 INCLUDE FOPCLRW,,2 ; $2B22 .. $2CEE, T1SA - T1SB
00020 020 INCLUDE FDELCAT,,2 ; $2CEF .. $2E8D, T1SB - T1SD
00021 021 INCLUDE FMTRWIO,,2 ; $2E8E .. $2FF6, T1SD - T1SE
00022 022 INCLUDE FLOCNXB,,2 ; $2FF7 .. $31C8, T1SE - T2S0
00023 023 INCLUDE FLOCSEC,,2 ; $31C9 .. $3396, T2S0 - T2S2
00024 024 INCLUDE FVCBUFS,,2 ; $3397 .. $35FD, T2S2 - T2S4
00025 025 INLUCDE BOOTLDR,,2 ; $35FE .. $37FF, T0S0 - T0S1
00026 026 INCLUDE COREQUS,,1 ; n/a
00027 027 INCLUDE PRENIBL,,1 ; $3800 .. $3829, T0S2
00028 028 INCLUDE WRITRTN,,1 ; $382A .. $38C1, T0S2
00029 029 INCLUDE POSTNRD,,1 ; $38C2 .. $3943, T0S2 - T0S3
00030 030 INCLDUE RDADSEK,,1 ; $3944 .. $39FC, T0S3
00031 031 INCLUDE MSWAITR,,1 ; $39FD .. $3C55, T0S3 - T0S6
00032 032 INCLUDE WRITADR,,1 ; $3C56 .. $3CFF, T0S6
00033 033 INCLUDE RWTSONE,,1 ; $3D00 .. $3DAA, T0S7
00034 034 INCLUDE RWTSTWO,,1 ; $3DAB .. $3EAE, T0S7 - T0S8
00035 035 INCLUDE FORMATR,,1 ; $3EAF .. $3FC7, T0S8 - T0S9
00036 036 INCLUDE DOSPTCH,,1 ; $3FC8 .. $3FFF, T0S9
Post by TommyGoog
Post by Michael 'AppleWin Debugger Dev'
Looks like a bug-fix to the state table was made?
It is not one of the DOS3.3(1983) documented fixes.
Could be an internal patch?
Or it could be part of the copy protection?

Definitely needs investigation !
TommyGoog
2017-07-24 23:50:48 UTC
Reply
Permalink
Raw Message
Post by Michael 'AppleWin Debugger Dev'
Right -- I was assuming a "Master" disk. If a "Slave" disk, then all bets are off, since it could be anywhere in the 48K (well, anywhere between $1B00 ... and $9B00)
Post by TommyGoog
If I modify the diskette to be a "master" diskette, then I think the initial load is to $1D00 (relocation code to $1B00) and it gets moved upwards to $9D00(or higher on IIe?)
According to my understanding it is $1B00
I actually wrote $1B00 initially in my message. Then I realized that $1B00..$1CFF is not really DOS but just part of the boot process. For example, even with a master diskette you won't find the range $1B00..$1CFF relocated to $9B00..9CFF. I think it was in "Beneath Apple DOS" that I read that the relocator code on a "slave" diskette is all zeros. I should have written:

"On a master diskette the initial load is to $1B00 which includes 2 sectors of relocator code started at $1B00. DOS from $1D00 is then relocated upwards to $9D00."
Michael 'AppleWin Debugger Dev'
2017-07-24 18:36:31 UTC
Reply
Permalink
Raw Message
Post by TommyGoog
If I modify the diskette to be a "master" diskette,
a "slave" diskette and when booted the initial load of DOS is to $9B00..$BFFF
That's one of those things I haven't gotten around to documenting for DOS 3.x, etc. Mind sharing?
I imagine one would need to write an "unrelocate" function? :-)
TommyGoog
2017-07-25 00:10:11 UTC
Reply
Permalink
Raw Message
Post by Michael 'AppleWin Debugger Dev'
Post by TommyGoog
If I modify the diskette to be a "master" diskette,
a "slave" diskette and when booted the initial load of DOS is to $9B00..$BFFF
That's one of those things I haven't gotten around to documenting for DOS 3.x, etc. Mind sharing?
I imagine one would need to write an "unrelocate" function? :-)
I'm not sure what you are asking me to share. There is a discussion in the manual that came with DOS3.3, "The DOS Manual, Disk Operating System", that describes the process of creating a slave diskette. In Chapter 5 p.44 is a section "Using the MASTER CREATE Program" to create a master diskette from a slave.

In Beneath Apple Dos, p 5-6 there is a discussion of "The Boot Process" which distinguishes between booting a slave vs a master diskette and where in memory pieces get loaded.

Hope that helps.
Michael 'AppleWin Debugger Dev'
2017-07-25 15:12:48 UTC
Reply
Permalink
Raw Message
Post by TommyGoog
I'm not sure what you are asking me to share. There is a discussion in the manual that came with DOS3.3, "The DOS Manual, Disk Operating System", that describes the process of creating a slave diskette. In Chapter 5 p.44 is a section "Using the MASTER CREATE Program" to create a master diskette from a slave.
Sorry, I was't more clear. I'm NOT asking how to make a slave disk. I was wondering how you did the reverse.

i.e. When you said
Post by TommyGoog
If I modify the diskette to be a "master" diskette,
How are you converting a slave disk BACK to be a master disk for Diversi-DOS ?
Are you just using Copy ][+'s "Copy DOS" option? Basically copying tracks $00..$02 from a master disk over to the CIV dis?

Hope this is clear now.
TommyGoog
2017-07-25 18:09:38 UTC
Reply
Permalink
Raw Message
Post by Michael 'AppleWin Debugger Dev'
Sorry, I was't more clear. I'm NOT asking how to make a slave disk. I was wondering how you did the reverse.
Let me try to clear up the confusion.

I'm not reversing any disk from being a "slave" diskette back to a "master" diskette.

In one message you wrote that DOS is initially loaded to $1B00 and then is moved up.

I was trying to point out that DOS is not always initially loaded to $1B00. It depends if the diskette is a slave diskette or a master diskette.

"Conflict in Vietnam" is like a slave diskette in that it is NOT initially loaded to $1B00, but loads directly to $9B00 (and then is moved upwards).

At the beginning of the message you are quoting, I wrote: "If I initialize a blank diskette...it is a "slave" diskette."

In the next paragraph I was referring to that "slave" diskette when I wrote: "If I modify the diskette to be a 'master'".

I was referring to the method for converting an INIT'd disk from slave to master as documented in the Apple DOS3.3 manual.

Back in the 1980s I would think everyone was creating slave diskettes (using INIT) and almost no one was converting them to master diskettes.

What I am currently doing with CiV is trying to determine the differences between DOS3.3 and the DiversiDOS on the CiV disk.

Earlier I discovered that if I use DOS3.3(1980) to INIT a blank diskette, and then use Diversi4c.DSK to put DiversiDos on that diskette, that it very closely resembles the DOS on CiV.

Assuming that the "Decisions in the Desert" .NIB disk image is from an original unaltered MicroProse diskette, it's clear that MicroProse used DiversiDos as their operating system for their games. If I've done the comparisons correctly, there are no differences in the OS between CiV and DiD on the first 3 tracks of the disks.

I hope I haven't confused you more :)
Michael 'AppleWin Debugger Dev'
2017-07-26 20:07:48 UTC
Reply
Permalink
Raw Message
Post by TommyGoog
I was referring to the method for converting an INIT'd disk from slave to master as documented in the Apple DOS3.3 manual.
Ah! OK, this makes sense now. It has literally been decades since I've RTFM DOS 3.x manual. :-) I didn't realize Apple actually documented that! I'll have to dig up that section again.
Post by TommyGoog
Earlier I discovered that if I use DOS3.3(1980) to INIT a blank diskette, and then use Diversi4c.DSK to put DiversiDos on that diskette, that it very closely resembles the DOS on CiV.
Interesting. I've only used DiverseiDOS a few times -- I'll have to track down that disk and see what it is doing.
Post by TommyGoog
Assuming that the "Decisions in the Desert" .NIB disk image is from an original unaltered MicroProse diskette, it's clear that MicroProse used DiversiDos as their operating system for their games. If I've done the comparisons correctly, there are no differences in the OS between CiV and DiD on the first 3 tracks of the disks.
Definitely post your "diff finding" here. :-)
Post by TommyGoog
I hope I haven't confused you more :)
Nope! Thanks for the clarification Tommy.
TommyGoog
2017-07-29 12:15:37 UTC
Reply
Permalink
Raw Message
Post by Michael 'AppleWin Debugger Dev'
Definitely post your "diff finding" here. :-)
I'm not sure where to begin.

For comparisons ("diffs") in this project so far I've used the following:

DOS3.3 (1980)
DOS3.3 (1983)
MASTER.DSK (from AppleWin)
MySlave.DSK (INIT'd from DOS3.3 1980)
Diversi-DOS_4c.DSK
MyDiversi.DSK ("Y" and "D", see note below)
Conflict in Vietnam.DSK
Decisions in the Desert.NIB

...and others, including DOS3.1 and DOS3.2, various Diversi disks, and other Diversi options. I've used AppleWin in configurations of AppleII, AppleII+, and AppleIIe.

My Diversi.DSK was created by using MySlave.DSK as input to DiversiDos and using options "Y" and "D" to apply DiversiDos to it.

In doing comparisons of code, I sometimes need to look at the various places where the code is loaded. For example, during a Master boot, the code for "DOS BASIC INTERPRETER - INITIAL ENTRY" is loaded to $1D84, which then gets moved to $9D84. $9D84 is where a slave diskette puts it and where DiversiDos and CiV first put it. For CiV and DiversiDos, the code at $9D84 is then modified and moved to $DD84.

After the code is modified and moved to $DD84, there is a "Patch file" (you might also call it a "change file" or "corrections file"), where 70+ patches are dynamically applied to the code in the $C000 to $FFFF range (and also to the lower 48K RAM space). These patches are in addition to finding other places in the code where self-modification takes place. For example, the initial "detour" at $B747. There you will find a JMP $9D84 in normal DOS3.3 code, but when DiversiDos is first loaded, $B747 is a JMP $9B00 and in the code at $9B00, the JMP at $B747 is self-modified "back" to JMP $9D84.

And sometimes my head explodes because I cannot easily get a dissassembled listing of code in the $DD00..$FFFF range without having to first move it so yet ANOTHER addressing range (for example $2000).

Like the other AppleII projects I've worked on, I really question whether this will be useful to any but a handful of souls. And a hard part for me is trying to make this interesting for anyone to read. The likelihood that I quit before reaching the end is high.

At times this is all very confusing, but I will attempt in future posts to detail the bootstrap for CiV and how it differs from DOS3.3 (1980) and from MyDiversi.DSK.

Tommy
Antoine Vignau
2017-07-29 12:31:49 UTC
Reply
Permalink
Raw Message
Grab the binaries and use a real disassembler like The Flaming Bird Disassembler. That will ease your task a lot!

av
TommyGoog
2017-07-30 18:59:11 UTC
Reply
Permalink
Raw Message
Post by TommyGoog
I will attempt in future posts to detail the bootstrap for CiV and how it differs from DOS3.3 (1980) and from MyDiversi.DSK.
Conflict in Vietnam

To view the following diagram properly, use a mono-spaced font (such as Courier New), and change all the periods to spaces. Printing to your favorite dot matrix printer is optional.

This is a map of the initial CiV bootstrap code before it is modified, relocated to [DD00..FFFF], and "patched" further.

......(1).+------+
..........|.0800.|
.+-------<|......|...JMP.B700
.v........|.08FF.|
.v........+------+
.v
.v....(4).+------+
.v........|.8700.|<<<<<<<<<<+
.v........|......|..........^
.v.+<<<<<<|......|JMP.BFAA..^
.v.v......+.8900.+...(DD84).^
.v.v......|......|..........^
.v.v......|......|..........^
.v.v......|.91FF.|..........^
.v.v......+------+..........^
.v.v........................^
.v.v........................^
.v.v..(3).+------+..........^
.v.v......|.9B00.|<<<<<<+...^
.v.v......|......|......^...^
.v.v......|......|>>>>>>>>>>+..JMP.8700
.v.v......+.9D00.+......^
.v.+>>>>>>|......|......^
.v........|.B5FF.|......^
.v........+------+......^
.v......................^
.v....(2).+------+......^
.v........|.B600.|......^
.v........|......|......^
.+>>>>>>>>+.B700.+......^
..........|......|>>>>>>+..JMP.9B00
..........+.B800.+
..........|......|
..........|.BFFF.|
..........+------+


Track 0 Sector 0 (T0S0) is loaded to 800. The code and data from 800 to 85C, and the bytes at 8FD to 8FF are identical a slave disk initialized using DOS3.3 (1980). From 85D to 8FC a DOS disk has random unused bytes, but CiV (or DiversiDos) uses this space for some of its code after T0S0 is read into [B600..B6FF] and later relocated to [F600..F6FF].

There are 2 versions of DOS3.3. One was released by Apple in 1980 and the other in 1983. The 1983 version has a few "bug fixes" to it as documented in Beneath Apple Dos (p. 2-4, p. 7-4, and 8-41). CiV is based on a version of DOS3.3 that was modified by DiversiDos and then likely modified some more (copy protection scheme etc.) The DOS3.3 (1983) "bug fixes" do not appear on the CiV disk, so it would seem Dos3.3 (1980) was a likely starting point.

CiV is a slave disk because the next part of the bootstrap code is loaded directly to B600. From track 0, sectors 0 to 9 are loaded to B600..BFFF. Once the 800 code has completed it's task, it JMPs to B700.

The code from B700 to BFFF is nearly identical to DOS3.3.


DIFFERENCES IN CODE FROM B600 TO BFFF
=====================================

[B600..B6FF]
As mentioned earlier, [B600..B6FF] is a copy of T0S0.

[B738]
At B738 is JSR B793 (BOOTIO) to read the next bunch of sectors from disk. This loads [T0SA..T2S4] into memory at [9B00..B5FF].

--For a DOS3.3 master boot, [9B00..9CFF] is not loaded with anything.
--For a DOS3.3 slave boot, [9B00..9CFF] is loaded from [T0SA..T0SB] which is all zeros.
--For a CiV boot, [9B00..9CFF] is loaded with DiversiDos bootstrap code.

[B747]
At B747 in DOS is JMP 9D84 (DBINIT DOS BASIC INTERPRETER - INITIAL ENTRY).
At B747 in CiV is JMP 9B00 to execute DiversiDos setup code.
An interesting note about this JMP 9B00 is that at 9B00 the code self-modifies this jump at B747 "back" to JMP 9D84. They apparently only want to enter this DiversiDos code once during bootstrap, and if for any reason they come back to B747 they want to then proceed with the normal bootstrap code. The DiversiDos execution path at 9B00 eventually rejoins this main path of code at 9D84, but by then 9D84 has relocated to DD84 so the JMP is actually to DD84.

[B7EB]
The RWTS IOB table begins at B7E8. B7EB is the expected Volume #.
--For DOS, B7EB is $FE
--For CiV, B7EB is $00 (match any).
B7EB is not altered before the call to BOOTIO (B793).
After the call to BOOTIO, DOS and CiV both set $B7EB to #$FF which is an invalid Volume number.

[B7F5]
$B7F5 in the RWTS IOB is the return error code.
--For DOS, its initial value is $EB.
--For CiV, its initial value is $03.
Since this value is set or cleared(?) by calling RWTS, the difference is insignificant.

[BA05]
BA05 is in MSWAIT which begins at BA00.
--For DOS this is INC $4E.
--For CiV this is INC $46.

DOS3.3 has this:

BA00: A2 11 LDX #$11
BA02: CA DEX
BA03: D0 FD BNE BA02
BA05: E6 46 INC $46
BA07: D0 02 BNE BA0B
BA09: E6 47 INC $47

CiV has this:

BA00: A2 11 LDX #$11
BA02: CA DEX
BA03: D0 FD BNE BA02
BA05: E6 46 INC $4E ***** 4E *****
BA07: D0 02 BNE BA0B
BA09: E6 47 INC $47

This sequence also shows up at BDA3 with the same difference. DiversiDos makes this change when applying DiversiDos to a disk.

The AUTOSTART ROM listing defines 4E/4F as RNDL and RNDH, and 47 as YREG.
The DOS3.3 listing defines 46/47 as MONTIMEL/MONTIMEH (Motion on time counters).

[BA69..BA95]
--DOS3.3 (1980) has random garbage here.
--DOS3.3 (1983) has the "Append Bug Patch".
--CiV has code.

[BB02..BB22] and
[BBDF..BC22]
The NYBBLE buffers reside here [$BB00..BC55].
There is no significance to these being different between DOS and CiV.

[BCDF..BCFF]
--For DOS, this is "padding" containing random garbage.
--For CiV, there is code here.
There is no significance to these being different between DOS and CiV.

[BDA3]
--For DOS, uses $46 as noted under BA05 change.
--For CiV, uses $4E as noted under BA05 change.


[BED2..BFA5]
--For DOS, use $45 as the NSYNC zero page location.
--For CiV, use $46 as the NSYNC zero page location.

[BEAF..BF0C] "Disk Format"
[BF0D..BF1B] "Write Track Subroutine"
[BF29..BFA7] "Verify Routine"

The only differences in this range of code is the use of $46 instead of $45 as the zero page location.

DOS defines NSYNC as $45.
Monitor code defines A5H and ACC as $45.
Monitor code defines XREG as $46.

I'm not sure why the code from BED2 to BFA5 uses $46 instead of $45 for the zero page location of NSYNC.

Next up will be the code at 9B00.

If anyone thinks this is useful posting this to CSA2 let me know.

Tommy
Michael 'AppleWin Debugger Dev'
2017-07-30 19:31:33 UTC
Reply
Permalink
Raw Message
Nice work Tommy!

These notes will come in handy if/when I get around to producing an .s for DiversiDOS
Antoine Vignau
2017-07-31 06:25:56 UTC
Reply
Permalink
Raw Message
Sorry, i am lost, Tommy.
Do you work on disassembling DOSes or CiV? If you focus on CiV, working from a NIB or DSK of the original game may save you time. I may be wrong but I have the feeling that the DOS on the Asimov images of CiV are not the one that came with the original game.

I am sure qkumba will tell the truth ;-)

Antoine
qkumba
2017-07-31 17:15:05 UTC
Reply
Permalink
Raw Message
:-) Yes, the CiV on Asimov has been modified from the original in significant ways that make it a poor choice for disassembly.
It will also fail its copy-protection tests when left to run for long enough.
TommyGoog
2017-08-01 05:26:52 UTC
Reply
Permalink
Raw Message
Post by Antoine Vignau
Sorry, i am lost, Tommy.
Do you work on disassembling DOSes or CiV? If you focus on CiV, working from a NIB or DSK of the original game may save you time. I may be wrong but I have the feeling that the DOS on the Asimov images of CiV are not the one that came with the original game.
I am sure qkumba will tell the truth ;-)
Antoine
The CiV disk on Asimov produces an error. My goal is to see if I can determine what causes that error and to possibly create a disk image that will work properly.

Of course working from an original would save time, but I don't have the original or access to the original.

I have begun my investigation of the disk by starting with the bootstrap code. The disk for CiV at Asimov is based on DiversiDos. Disassembling the code will now also be helpful to Michael since he has tentative plans to examine DiversiDos in the future.

Like you, when I started looking at the cracked CiV disk, I was worried the OS was altered by the person doing the "crack", however...

I have examined the "Decisions in the Desert" NIB image at Asimov. Both those programs are by MicroProse. If I did my analysis correctly, the DiD.NIB and the CiV.DSK have identical bootstrap OS code by DiversiDos. Obviously the NIB image could be cracked or not the original -- I simply don't know at this point, but the DiD NIB does not show the "cracked by" messages that CiV does so there is at least hope.

I have already learned a lot about DiveriDos OS by my examination in the past few weeks and better yet have started to share what I have found.

And of course, sometimes we climb mountains simply because they are there.

Tommy
Antoine Vignau
2017-08-01 06:19:30 UTC
Reply
Permalink
Raw Message
I made a .fdi image of the two sides of CiV yesterday. Write a mail to me (see the contact page of brutal deluxe fr) and I'll send them to you.

fdi means OpenEmulator means Mac. Is that fine for you?

Antoine
Nick Westgate
2017-08-01 06:35:46 UTC
Reply
Permalink
Raw Message
Post by Antoine Vignau
I made a .fdi image of the two sides of CiV yesterday. Write a mail to me (see the contact page of brutal deluxe fr) and I'll send them to you.
fdi means OpenEmulator means Mac. Is that fine for you?
I think Tommy prefers AppleWin. ; - ) A .nib image is good enough if someone wants to crack it. Qkumba has probably already started...

BTW, I wonder if Bill Basham's involvement was limited to the use of his DOS, or whether he did the protection for these disks.

His scheme on Passport Design's MIDI software was grueling as Antoine and Michael Mahon have testified. There's a CSA2 thread about it.

Cheers,
Nick.
TommyGoog
2017-08-01 14:11:02 UTC
Reply
Permalink
Raw Message
Post by Nick Westgate
Post by Antoine Vignau
I made a .fdi image of the two sides of CiV yesterday. Write a mail to me (see the contact page of brutal deluxe fr) and I'll send them to you.
fdi means OpenEmulator means Mac. Is that fine for you?
I think Tommy prefers AppleWin. ; - ) A .nib image is good enough if someone wants to crack it.
Nick.
I am using Windows10 and various versions of AppleWin, so I don't think an .fdi image will work for me.

I would think the best thing to do is to place an uncracked .dsk or .nib image to Asimov. Even if it doesn't work "out of the box" I think it is important to archive original images and not just the cracked versions.

Tommy
Antoine Vignau
2017-08-01 15:20:32 UTC
Reply
Permalink
Raw Message
OK, Tommy, I'll see if I can make a non-cracked but normalized DSK of CiV.

Stay tuned,
Antoine
qkumba
2017-08-01 18:34:27 UTC
Reply
Permalink
Raw Message
Post by TommyGoog
I would think the best thing to do is to place an uncracked .dsk or .nib image to Asimov. Even if it doesn't work "out of the box" I think it is important to archive original images and not just the cracked versions.
.dsk won't run properly. Only .nib has a chance to work.
The CiV on Asimov is not cracked properly and does not run properly.
I will work on it, but first I want to finish cracking the 128k version of CiE.
Antoine Vignau
2017-08-01 15:23:07 UTC
Reply
Permalink
Raw Message
You are right, Nick, Applewin means Windows, sorry!

And, yes, Basham's code is unreadable but if you find the exit point, you're done in 5 minutes. If you don't, that takes more time :-)

Antoine
qkumba
2017-08-01 18:35:23 UTC
Reply
Permalink
Raw Message
Post by Antoine Vignau
And, yes, Basham's code is unreadable but if you find the exit point, you're done in 5 minutes. If you don't, that takes more time :-)
Yes, that's true! I got to try it at KFest with some new MIDI titles.
I believe that it required only a one byte patch but in just the right place.
Michael 'AppleWin Debugger Dev'
2017-07-24 15:49:01 UTC
Reply
Permalink
Raw Message
Post by TommyGoog
...you can find this code after the label "COS00". You can also see a nice "state handler" flowchart that is displayed following label "EWRITE".
If you append this to the URL ...

#EWRITE

... here is a direct link ...

https://htmlpreview.github.io/?https://github.com/Michaelangel007/apple2_dos33/blob/master/dos33.html#EWRITE

... to help you save some time scrolling down.
Michael 'AppleWin Debugger Dev'
2017-07-24 15:52:54 UTC
Reply
Permalink
Raw Message
Post by TommyGoog
By the way, Diversi-DOS dynamically alters DOS in the range $9D00..$BFFF using a process similar to "Programmer's Aid #1" code for "relocating machine code". Heck it even uses the same MONITOR subroutine $F88E INSDS2 to determine the number of bytes in the instruction. Talk about your rabbit holes! Tom, get back on track again!
That's because DOS 3.x does that :-)
See function: DR7

https://htmlpreview.github.io/?https://github.com/Michaelangel007/apple2_dos33/blob/master/dos33.html#DR7

00249 213 ;
00250 214 ;RELOCATE CODE
00251 215 ;
1BAF:A2 00 00252 216 LDX #0
1BB1:8E 9C 33 00253 217 DR7 STX TEMP1
00254 218 ;
1BB4:BD 5A 1C 00255 219 LDA CDETAB+1,X ; GET A START OF CODE ADR
1BB7:85 40 00256 220 STA ZPGWRK ; PUT IN ZPG
1BB9:BD 5B 1C 00257 221 LDA CDETAB+2,X
1BBC:85 41 00258 222 STA ZPGWRK+1
00259 223 ;
1BBE:A2 00 00260 224 DR8 LDX #0 ; GET OP CODE
1BC0:A1 40 00261 225 LDA (ZPGWRK,X) ; GO FIND OUT HOW LONG ; Since we don't have a linker, interesting hack of using
1BC2:20 8E F8 00262 226 JSR INSDS2 ; monitor ROM to get instruction opcode length
00263 227 ;
1BC5:A4 2F 00264 228 LDY LENGTH ; GET HOW LONG ; crappy var name -- length of what?? Oh OPCODE_LEN
1BC7:C0 02 00265 229 CPY #2 ; IF IT AIN'T ; *sigh* #3-1 is clearer since zero based
1BC9:D0 11 00266 230 BNE DR9 ; 3 THEN DON'T RELOC ; 300:A9 20 20 8E F8 A5 2F 09 30 4C ED FD
1BCB:B1 40 00267 231 LDA (ZPGWRK),Y ; GET PAGE FROM INST
1BCD:CD 7A 1C 00268 232 CMP RSPAGE ; IF PAGE < REL START
1BD0:90 0A 00269 233 BCC DR9 ; THEN IGNOR
1BD2:CD 7B 1C 00270 234 CMP REPAGE ; IF PAGE >= REL END
1BD5:B0 05 00271 235 BCS DR9 ; THEN IGNORE
1BD7:6D 7F 1C 00272 236 ADC DELTA ; ELSE ADD DELTA
1BDA:91 40 00273 237 STA (ZPGWRK),Y ; TO RELOCATE
00274 238 ;
1BDC:38 00275 239 DR9 SEC
1BDD:A5 2F 00276 240 LDA LENGTH ; ADD LENGTH ; === Page 114 ===
1BDF:65 40 00277 241 ADC ZPGWRK ; TO PC
1BE1:95 40 00278 242 STA ZPGWRK
1BE3:A9 00 00279 243 LDA #0
1BE5:65 41 00280 244 ADC ZPGWRK+1
1BE7:85 41 00281 245 STA ZPGWRK+1
00282 246 ;
1BE9:AE 9C 33 00283 247 LDX TEMP1 ; CHECK FOR END
1BEC:DD 5D 1C 00284 248 CMP CDETAB+4,X ; OF CODE SEGMENT
1BEF:90 CD 00285 249 BCC DR8 ; BR NOT END
1BF1:A5 40 00286 250 LDA ZPGWRK
1BF3:DD 5C 1C 00287 251 CMP CDETAB+3,X
1BF6:90 C6 00288 252 BCC DR8 ; BR NOT END
00289 253 ;
1BF8:8A 00290 254 TXA
1BF9:18 00291 255 CLC
1BFA:69 04 00292 256 ADC #04 ; INCREMENT TABLE INDEX
1BFC:AA 00293 257 TAX
1BFD:EC 59 1C 00294 258 CPX CDETAB ; DONE
1C00:90 AF 00295 259 BCC DR7 ; BR IF NOT ; === T0SB ===
TommyGoog
2017-07-24 18:30:07 UTC
Reply
Permalink
Raw Message
Post by Michael 'AppleWin Debugger Dev'
Post by TommyGoog
By the way, Diversi-DOS dynamically alters DOS in the range $9D00..$BFFF using a process similar to "Programmer's Aid #1" code for "relocating machine code".
That's because DOS 3.x does that :-)
See function: DR7
As I mentioned in the earlier post, I think "it depends" regarding the relocating.

The code in CiV for relocating is a little different too. It moves everything up #$40 pages, but also makes additional movement of two tables, one of which is the I/O Control Block for RWTS. The IOCB starts at $B7E8 and after relocating would normally reside at $F7E8, but it is instead moved to $BFD5 in lower 48K RAM. Yeah, it can be confusing at times.
Loading...