• Please review our updated Terms and Rules here

Exidy Sorcerer II Questions

Oh well, seems that I'm going to need some time to check the video output of my machine (I remember it of good quality without glitches).
It turns out that my Sorcerer II doesn't get any power at all; so I need to check all the PSU circuit; but I don't have the MkII schematics, all the docs refer to the MkI model.

Does your machine came with specific MkII documentation?
 
Thanks!, now it's booting again :). It was easy to fix after all, only a broken mains cable.

My Sorcerer behaves the same, all commands shows the same glitches and tearing. I suppose that's normal and the Sorcerer's video system has some kind of arbitration against CPU accesses.

Btw, my monitor seems to be a dutch "1.3/B" version, I'll dump it ASAP if it's not preserved
 
What about the games? Can you run something like Astro Attacker and see if it does the same thing?
 
Yeah they worked just fine for me on my Sorcerer. I didn't have to change the baud rate or anything. Could it be your tape recorder volume/tone? I had to adjust that a little on mine.

Could it be your special monitor?
 
No idea, I'm using a PDA to load them, it usually works fine with other machines or even with the Sorcerer.

I can try to calibrate the load circuit following the led advices, trying with a standard tape player or recreating the WAV file with MESS. I can also compress to MP3, IIRC this format had work better for me when playing with the Sorcerer.
 
Good news, everyone!

I may have found the cause of the tearing / jitter during screen access. I looked at the HSYNC circuit on an oscilloscope and saw that, during screen RAM accesses (Monitor command TE FE00 FF00), there is a one cycle jitter in timing between HSYNC pulses. That's one cycle of the 6 MHz clock, which is the time it takes for two pixels to clock out.

It appears to be a bug in Exidy's original circuit. The low bit of the horizontal counter gets loaded from the output of a flipflop which clocks the E256 signal. The problem is that, during screen access, that flipflop gets set in order to briefly blank the pixels. That's by design, and it's why we see the brief, short, black lines. But a side effect is that, if the access happens when the counter reloads, the wrong value gets loaded into the counter, causing a short (by 2 pixels) scan line, and horizontal jitter on a CRT monitor. When I lifted IC3A pin 3, the jitter on the scope went away. I have not yet looked at it on a CRT but it really seems like the culprit.

Presently, IC3A (IC22A on the II) pin 3 connects to IC7B (IC17A on the II) pin 9. The fix will be to connect it to IC7B (IC17A on the II) pin 12 instead.

I'll post again after checking the fix on a CRT.
 
Wow! I assume this fix could apply to the Sorcerer II as well?

EDIT: Re-reading your comment I see that it can. I wonder if this will have any negative effects?
 
tempest said:
Wow! I assume this fix could apply to the Sorcerer II as well?

EDIT: Re-reading your comment I see that it can. I wonder if this will have any negative effects?
Click to expand...

Ditto, I was thinking also about something related to the Sorcerer's video architecture; but I wonder if it can be corrected without other issues. Nice find anyway!
 
That mod is different. It alters the video signal levels. It sounds reasonable but I haven't tried it.

I checked my fix on a CRT and it works. No more horizontal jitter during screen updates!

There will be no negative effects because it does not alter the video timing. It just keeps that timing the same whether the CPU accesses screen RAM or not.
 
Any ever try to add a speaker to the Sorcerer? I have an article that says you can do it by hooking speaker wires to pins 1 and 4 on the parallel port. I think some games like Galaxians support this.
 
Last edited:
My I has no cassette interface daughterboard so I connected an Arduino to the UART and programmed it to simulate a tape and it works! The Arduino generates the UART's send and receive clocks just as the daughterboard would do, so I tried 1200, 4800, and 20833 baud and they all work. Wow, it could load a 48K binary tape image in under 30 seconds. Now I need some tape images.
 
You must log in or register to reply here.
Back
Top