z80 assembly issue?

[arpruss]

I tried running the z80 assembly code through zmac, and then through z80emu (https://github.com/anotherlin/z80emu) with a quick-and-dirty implementation of the relevant rst 38 functions. I am getting a weird result:

[
WELCOME TO CHESS! CARE FOR A GAME?
y
DO YOU WANT TO PLAY WHITE(w) OR BLACK(b)?
w
SELECT LOOK AHEAD (1-6)
1
[
  PLAYER SARGON
  [□][□][□][□][
01 a2-a4 aC-e5
02

The brackets are due to unimplemented control codes in the output function, but the problem is the response to the first move: aC-e5 .

Maybe there is some bug in the emulation, or in my conversion of the zmac .hex file, but I thought I'd ask you if you have ever met such a weird symptom.

[billforsternz]

I have been putting quite a lot of effort into getting actual Z80 code going, and I can assure you that it works as advertised. It does take a lot of patience and attention to detail to make it work (either with a real Z80

• I have helped a man in Switzerland and we got there eventually - or with a Z80 emulator). I am sorry I am a bit overwhelmed at the moment and I can't offer to get involved with your project. But I can encourage you to keep trying, to try to figure out what is going wrong. Failing that, I am determined to publish my working Z80 version, in the form of a CP/M version for generic CP/M computers - i.e. with the Jupiter I/O primitives replaced, early in the new year. If you wait for that, maybe you can compare your code to mine instruction by instruction.

Good luck!

Bill.

On Fri, 10 Dec 2021 at 18:08, arpruss @.***> wrote:

I tried running the z80 assembly code through zmac, and then through z80emu (https://github.com/anotherlin/z80emu) with a quick-and-dirty implementation of the relevant rst 38 functions. I am getting a weird result:

[ WELCOME TO CHESS! CARE FOR A GAME? y DO YOU WANT TO PLAY WHITE(w) OR BLACK(b)? w SELECT LOOK AHEAD (1-6) 1 [ PLAYER SARGON [□][□][□][□][ 01 a2-a4 aC-e5 02

The brackets are due to unimplemented control codes in the output function, but the problem is the response to the first move: aC-e5 .

Maybe there is some bug in the emulation, or in my conversion of the zmac .hex file, but I thought I'd ask you if you have ever met such a weird symptom.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/billforsternz/retro-sargon/issues/4, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABSQYSQI2OGY6IYVB3S6QDDUQGDLPANCNFSM5JYH7Q6A . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

-- Bill Forster 15A Boundary Road Kelburn Wellington 6012 New Zealand +64 21 357 371 @.***

[arpruss]

Thanks for the encouragement!

Are there binaries of the asm file somewhere that I could try running through the emulator?

[arpruss]

I figured it out. The .asm file assembles to an origin at 0000, which doesn't work with RST 38 very well! My code to handle the Jupiter i/o ended up overwriting the opening book. Shifting the orgin to 0100 fixed the problem.

[billforsternz]

Well done!

In general Sargon doesn't enjoy the first 100h bytes of memory, as this comment indicates;

;In general it seems Sargon doesn't want memory allocated ;in the first page of memory, so we start TBASE at 100h not ;at 0h. One reason is that Sargon extensively uses a trick ;to test for a NULL pointer; it tests whether the hi byte of ;a pointer == 0 considers this as a equivalent to testing ;whether the whole pointer == 0 (works as long as pointers ;never point to page 0). ;

I don't have binaries (yet) because the original Sargon code is heavily Jupiter dependent (I/O - screen graphics). As mentioned earlier I am working on a version that will work with vanilla CP/M with ascii art 'graphics' (and also a wider array of Z80 assemblers).

I'd like to include a set of reference test vector type complete games, with timing information etc.

Anyway, I can't be working on this now, I'll return to it in the new year.

Bill.

Bill.

On Sat, 11 Dec 2021 at 07:39, arpruss @.***> wrote:

I figured it out. The .asm file assembles to an origin at 0000, which doesn't work with RST 38 very well! My code to handle the Jupiter i/o ended up overwriting the opening book. Shifting the orgin to 0100 fixed the problem.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/billforsternz/retro-sargon/issues/4#issuecomment-991206183, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABSQYSTZWT2MWEQPIUPL2T3UQJCO5ANCNFSM5JYH7Q6A . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

-- Bill Forster 15A Boundary Road Kelburn Wellington 6012 New Zealand +64 21 357 371 @.***

[arpruss]

I had to insert an ORG 100h before the definition of START, because even though TBASE is at START+100h, there is some data (e.g., the "opening book") that is stored below TBASE.

[arpruss]

In case you're interested, here's a quick-and-dirty python script that runs sargon in text mode without a board: https://gist.github.com/arpruss/c714dd7682d7c7bd7aa8263709d4501e

(BTW, as far as I could track it down, the copyright on the book was owned by Hayden which was owned by MacMillan, which passed to Simon and Schuster, which passed to Pearson Education. I asked Pearson Education for permission to use the code, and they said they did not have the book in their records, so copyrightwise I'm at a blind alley, and fair use is all that's left.)