Re: 8088 and 610 saga continues...

Hello!

W dniu 2011-01-23 16:49, Hoffmann-Vetter, Martin pisze:

> Did you have some more information about the IPC functions? I've look at the MSDOS.PRG and find some routines for reading sectors from disk and so on. 

No. But most of them can be deduced by looking at the IO.SYS code. I can
post a disassembly if you want.

At $0810 on 6509 side is the jump table to IPC routines.

> At this time a found a mysteric: The MSDOS.PRG is to short (directory shows 2817 bytes including two bytes for the starting address). There is program code after the last (23) bytes in the last sector of the disk. Did you have complete disassembled the code?

Not yet, but I'm working on it. There are some things I don't
understand, for example some strange stuff at $0600-$07FF.

> Okay, have a unterstand it, that this byte (10021h) is cleared after an ipc call from 8088 to 6509? 

Yes, exactly.

> At a look at the rom listing CBM-II there are some different causes for the ipc server at the 6509. Only if the highest bit at the ipc command is set to one the dram bus is arbitrated, the function called and after them released. When an ipc call without this bit is called, the 6509 can't access the dram at bank 1 and can't owerwrite the address 10021h.

That's one of the reasons I believe it is overwritten on the 8088 side.
It would be much easier for the 8088 to do it, just set DS to zero and
write to byte 0021h.

> Is this the only address that was changed? Can you test it?

This is the only I noticed, but there may be many more. I will try to
make memory snapshots and compare them.

Now that would make a plausible theory - the IPC code is randomly
overwriting memory bytes, which causes the MS-DOS code to become
corrupted and hang.

On a side note, 21h is the port number used to pass IPC data to the
6509. Coincidentally, the momory location of the same address gets
overwritten.

> And the other question is, why don't overwrite the 720 this byte?

I made one error here. INT 08h is used only to cold-start the loader.
Then it is not used because 6509 is not calling 8088 for anything, only
the other way around. So the theory with overwiting different memory
bytes and corrupting the code is more likely to me.

> I don't think this is a solution. It works on the 720 and all thes hardware control lines are on the coprocessor board.

Exactly. But the hangs are occuring at random places, and this would
normally mean a hardware problem to me.

> But where are they? I've look at the schematics and can't found anything. The difference are:
> * Pin PC7 (Pin# 32) is at the low profile connected to ground, at the high profile over a resistor to VCC.
> * The low profile has an additional video output circuit for the composite video output.

What about the dot clock? The 720 screen is 350 pixels high, but 610
screen is only 200. Is there any difference in clock generation to
reflect this? Otherwise the 720 screen refresh rate would be about 35 Hz
and that would cause noticeable flicker.

Regards,
Michau.


       Message was sent through the cbm-hackers mailing list