Disassembling the Educational System Master Cartridge

[tschak909]

Yes, but at specific points.

 

-Thom

[flashjazzcat]

I'll wager and kind of inter-record gap falls neatly on powers of two, just like extended banks.

[UNIXcoffee928]

Well, if you're writing a program, anyway...

 

Why not just write something that opens & reads the tape and immediately writes it to disk as a sequential file?

 

You could then browse the resultant disk-file with a sector editor for the repeated hexadecimal sequence that represent the breaks.

 

Once you determine the hex sequence for the breaks, use it as the chop-point with a file-splitting utility, to break things down into more manageable chunks that can fit in RAM.

 

Just use the tools in the "bash" shell to do your automated file trimming, into whatever size chunks that you're looking for.

 

Once you have the appropriate sized chunks of data, then you should be able to proceed with your plan.

[Rybags]

The problem is it's a custom tape format and probably doesn't have fixed record lengths, and you can't just stop motor control or initiate other IO types whenever you want when doing tape operations, aside from the long IRG CIO generated types.

Edited May 4, 2015 by Rybags

[tschak909]

Yup, Rybags beat me to it. Listen to the tapes, guys. You'll see _very_ quickly that this is a custom tape format. It is stream oriented. There are no record gaps. There is no error correction. I _do_ think there is speed correction (the IRQ samples VCOUNT...so...maybe.)

 

It is very much akin to a MODEM transmission happening at about 450 baud. and it makes trying to save the data nothing short of a headache... so... I will try to see if I can reproduce the decoding routine, and look at the data in a buffer.

 

-Thom

[UNIXcoffee928]

The problem is it's a custom tape format and probably doesn't have fixed record lengths, and you can't just stop motor control or initiate other IO types whenever you want when doing tape operations, aside from the long IRG CIO generated types.

Your earlier suggestion about using a DAW seems very sensible.

 

Maybe A8CAS can be used to some effect? There is some info on Block I/O here, that might be helpful.

 

Then again, since it is a stream, like a modem transmission, you could capture enough of it to be able to provide further clues, if you just have your program stop reading the tape after say 32K-48K is read in, then go through the captured data looking for patterns.

[tschak909]

As I said, since the data is EOR'ed, I will try to reproduce the decoding routine, and dump sections to page 6, and save them for further analysis from inside the emulator debugger. I have it written, I just have to debug why the IRQ routine isn't being fired (even though I set IRQEN for serin, and turned on the cassette motor...)

 

-Thom

[UNIXcoffee928]

There was an Atari book called "Advanced Software Protection Techniques", and if I recall, it had a section on cassettes, might be worth looking at.

[tschak909]

for _ANYONE_ wanting to have a discussion on this topic, please read:

 

http://www.atarimania.com/documents/All_about_Cassette_Tapes.pdf

 

Specifically the section on "Dorsett Educational Tapes" It's an eye opener.

 

-Thom

[tschak909]

The keyboard handling also happens inside the Pokey IRQ. (this basically means, that besides the initialization routines (which consist of either copying tables or zeroing regions), and the routines that change state based on the ZP data that's set by the interrupt routine. almost all of this program runs inside the interrupt.)

 

As expected, the program looks for the keys '1', '2', and '3', but interestingly enough, it also looks for Enter, and Space.

[tschak909]

The NUL bytes (after they've been EOR'd) are handled by $BA03. It looks for two of them at the start of tape reading, and this is used exclusively for speed calculation (the results are used to adjust AUDF4), Since these bytes do not occur elsewhere except at the start of a tape side, there is no further speed adjustment for jitter as the tape continues.

 

(sorry, slight correction, they are also present, any time Dorsett had a gap in the data. Which was often common with the in place editing that was done during their production and maintenance process.)

 

-Thom

[tschak909]

A breakthrough! Was able to string together enough of an IRQ routine to see the raw data being dumped into $0600 (and I pointed a display list there to check):

 

[UNIXcoffee928]

That was an interesting .pdf. You're really doing a great job with this project, thanks for all of your hard work!

[tschak909]

Am I correct that the IRQ routine basically begins at $B99C, and ends at $BAB0 ?

 

It's somewhat difficult to figure out, because the exit routine is in the middle of the IRQ routine.

 

-Thom

[UNIXcoffee928]

Am I correct that the IRQ routine basically begins at $B99C, and ends at $BAB0 ?

 

It's somewhat difficult to figure out, because the exit routine is in the middle of the IRQ routine.

 

-Thom

Your video shows an "Illegal Instruction Hit" at BC27, with reference to BC26. What is happening here? Can you show more debugging in the next video?

[tschak909]

yeah, it's because i threw a BRK there, to cause the emulator to stop in its tracks.

 

Interestingly enough,

 

turns out my understanding of the timing byte (0x00) is very wrong. It's everywhere, but not all the time... I added a little bit into my IRQ to change COLPF2 to $5C when $00 is present in SERIN, versus $00 when anything else is present in SERIN...and wowza...flittering line city.

 

This is where the rubber meets the road, and this shit's about to get really slow...

 

p.s. if I posted code on github, would anyone collaborate?

 

-Thom

[tschak909]

Actually, tracing through the cartridge, it looks like the NUL byte is used anywhere there wishes to be a pause in the output. At which time, the POKEY registers are also re-adjusted for jitter correction by timing the occurance of successive NULs against vcount modulus 131... this just gets more and more interesting...

 

I’ve also never seen code outside of a monitor or a basic interpreter that uses the ($00,X) indirect addressing mode, so much.

-Thom

[UNIXcoffee928]

...It's everywhere, but not all the time... ...

 

-Thom

Well, if all else fails, you can start a new religion, based upon the philosophical concept of "Random Omnipresence", which you have just discovered, ha!

 

Posting code would probably be helpful, but you are very detail-oriented in your video presentation, so if you post more video, it would probably have the greatest impact, since not everyone has your testing environment set up.

[tschak909]

Ugh, this is making my head hurt, all these table driven indirect accesses in the code are making my head spin. A combination of $00,X and ($00,X) reads and writes are used all over this thing, it's just a mash of clever unreadable code.).. aiiiigh!

 

-Thom

[JamesD]

Sounds like an interpreter of sorts.

[tschak909]

That's correct. It's akin to a terminal emulator.

 

Right now, am trying to map out variables. looks like $80-$A4 are used for variable storage.. .so far, $81 provides the correct answer.

 

-Thom

 

Can somebody provide a simple example of how ($00,X) is used, vs ($00),X ? I understand from a conceptual point of view, just looking for something a bit more concrete, that can be explained in detail.

[tschak909]

$82 = Current screen memory location (Lo)

$83 = Current screen memory location (Hi)

$84 = Line offset begin (Lo)

$85 = Line offset begin (Hi)

 

...the march continues....

[JamesD]

That's correct. It's akin to a terminal emulator.

 

Right now, am trying to map out variables. looks like $80-$A4 are used for variable storage.. .so far, $81 provides the correct answer.

 

-Thom

 

Can somebody provide a simple example of how ($00,X) is used, vs ($00),X ? I understand from a conceptual point of view, just looking for something a bit more concrete, that can be explained in detail.

If I remember right... (and I might not)

Just remember that the index X is added based on the parenthesis.

The pointer is located at $00 + X

The pointer is located at ($00) and then add X to the pointer

 

 

So in the first case, X is an index into a table located at $00

 

In the 2nd case, the pointer at zero may point to an array and X is the offset within that array

Edited May 6, 2015 by JamesD

[luckybuck]

I can't believe what I am reading here: just a few days ago and then such a mega event like this?

 

What is going on in 2015?

 

@Thom: Where word can't express it, pictures must do the job:

Please go ahead, that is a fantastic job you have already done! You are so close to the 100 %. Please go ahead.

 

@Xuel: Thanks, the disassembly shows a lot!

 

With all forces combined and contribution or donation of the still 2 missing packages, we can make it done, even it has taken 36 years...

 

Many thanks to you all.

[Rybags]

There is no ($00),X

 

Only ($00),Y

 

Maybe this thing uses some sort of bytecode interpreter - I'd agree. To work it out might be hard. If there's a common entry point, becomes easier. If you can intercept calls then trace and work out what each code does then you're a long way to solving it.