Re: Gemini 80-Bus System
 

Normally when two adjacent data lines look identical with frequent half-logic levels as they do on the uppermost two images on that page, it suggests that the two lines are shorted together either physically (track short/solder splash) or by a fault in one of the devices on the bus.

The half-levels are caused by one line (say D0) trying to go high at the same time as the other (say D1) goes low. You get a high on both lines when both lines are trying to be high, a low on both lines when both are trying to be low, and a half-level when they are trying to be in opposite states.

Re: Gemini 80-Bus System
 

Thank you for your reply, this is very helpful and gives me some confidence that I am on the right track (no pun intended).

I have now removed all of the socketed chips, RAM, CRTC etc to try and remove as much as I can from the bus and I have visually inspected the tracks and soldering very carefully, however, the scope shows the same display. The remaining chips are soldered in and whilst I am happy to start the process of socketing these chips, it would be good to try and narrow things down beforehand.

I guess I could see if there is track I could break somewhere to give me a mid point in terms of the chip count to try and narrow things down a little.

Re: Gemini 80-Bus System
 

Just measuring resistance between the tracks will give some indication of distance - use a digital multimeter on the lower resistance range.

Re: Gemini 80-Bus System
 

Ah, for once I am slightly ahead, I did indeed check with a digital multimeter and sure enough D0 was connected to D1. By wandering around the board it was fairly easy to identify that the issue seemed to be under the CRTC controller socket. After lifting the socket slightly and much searching with a very powerful magnifying glass, there it was, a small sliver of copper from one track, touching the other. This was removed with a fine scalpel blade and hey presto I can see pulses on IORQ.

I replaced all the ICs and IVC Monitor and I now have a perfectly good IVC Video card, and to be honest I can't quite believe it.

My theory of how this all happened is that the original fault of the blown CPU and faulty IC31 is anyones guess, however, when I removed the CRTC to test it I suspect I either damaged the track slightly beneath the socket or disturbed some previous damage. Oops >:(

At this point I must extend my thanks to Neal, John B, Julie, SiriusHardware and others who chipped in. Without you guys I would have given up long ago. Many many thanks.

Photos of a working Gemini are at the bottom of the page... ;D https://glasstty.com/wiki/index.php/Gemini_IVC_Problems

Time to get the SCSI working, which means I am back on the hunt for a Gemini CP/M Bios with Winchester support....

Re: Gemini 80-Bus System
 

**** Congratulations **** - you can now have some fun. There must be gemini machines with a hard disk somewhere.

Good luck with getting a hard disk running - I don't have much in the way of Gemini sources to help out although I have written SCSI drivers as well as the SCSI emulation for xbeaver.

Re: Gemini 80-Bus System
 

Congratulations on your successful debug and repair. Amongst the mysteries: what code was that ROM actually causing the Z80 to execute?

Neal

Re: Gemini 80-Bus System
 

Thanks all, like I said before, without you guys I would not be where I am now.

Neal: A mystery indeed... but I am happy to leave that as a mystery. :)

John: I will have a go at setting up a T-Net server next, I really appreciated the facility on xbeaver.

Tony: I would love to take a dump and archive that Simon ROM you have, it may be the only one left. I would also love to get the Bios off your hard disk sometime.

Re: Gemini 80-Bus System
 

When my linux box died it needed a new motherboard. I bought a replacement and linux needed a new install to work properly so I ended up using an old motherboard as a replacement. This older motherboard used the hdd drivers rather than the sda drivers. I found these to be a lot slower and also the linux system (maybe because of the backward change from sda to hda) would disable interrupts for a while. This caused disruption with the mouse and the serial ports.

In this case I actually found that using USB serial ports worked more reliably.

With gemini remember that 9600 baud has a divisor of 13. On a PC 9600 baud has a divisor of 12. In practice this means that 9600 baud is the fastest common baud rate between the machines. However it is still usable - indeed I have used T-NET to install floppy disk images for my matmos machine which I recovered/upgraded recently. It now supports 3.5 inch 1.44MByte disks - upgraded from 360k disks.

Personally I think T-NET is one of the most used programs I have written in Z80 code. The only pain is that it drives the serial port directly and hence needs a different version for each machine.

PS - Most of my work on CP/M has been done with the CCPZ extended command processor. It would be worth installing that on your system because it is so much nicer. T-NET also plays happier with CCPZ.

usage

T-NET <network drives> installs T-NET with upto four network drives - the limit is in xbeaver
eg T-NET NOP installs network drive N O and P

and T-NET R
removes T-NET

Re: Gemini 80-Bus System
 

Just to help you out - I have created a ccpz 64k version of CP/M for you... see attached. It also has a version of T-NET configured for your machine.

Re: Gemini 80-Bus System
 

Just for grins I considered the effect of a d0/d1 short on my test loop. The only opcodes that have d0/=d1 are

21 Id hl xxxx
7e ld a (hl)

7e could turn into 7f (ld a,a) or 7c (ld l,h)
21 could turn into 20 (jr nz xx) or 23 (inc hl) but in either case would mess with the program flow.

I'm kind of intrigued because the code did seem to be looping and the in instruction should have been uncorrupted so I still don't understand why no /iorq.

Neal

Re: Gemini 80-Bus System
 

Would have continued past the jr - the eeprom probably had 0ff in unused locations wish would be rst 38h - eg a call to 38h and this would have caused the loop.

Re: Gemini 80-Bus System
 

Thank you for the disk John, really appreciated. I will sort some time next week to try it. Will keep you posted.

I have just been running Wordstar 4 SVC version taken from your hard disk image but received a report of not enough memory when I try and open a new file, so still plenty to keep me busy. :).

Re: Gemini 80-Bus System
 

You are running a 32K system still I believe - which is why you do not have enough memory. I have just checked and I can run ws4-svc without VPM/M which is with a CP/M system with hard disk support so you should be able to on your floppy system.

You wont be able to run VPM/M though as you need a GM813 card and at least 128K of memory! (Memory is free in the emulator, but I did run VPM/M on real hardware!).

Re: Gemini 80-Bus System
 

It was using a 64K disk, it certainly reported 64K, however, I have spent quite a lot of time creating the basic disk images with python so I could have something wrong or mixed up. I will try it again properly next week and let you know.

Re: Gemini 80-Bus System
 

This should help check you have the correct version

That is more memory than my hard disk version (started with option "-o i" to inhibit vpm/m) in which I can run ws4-svc and edit a a file

So your 64k floppy system should have enough memory.

Re: Gemini 80-Bus System
 

Thanks John that is very useful. I just ran mapmem and I get those same values, interestingly I can create Non-Document files but when I try and create a Document file it reports the error 'Not enough memory to continue'. This is the SVC version of WS and I have the IVC, don't know if that would make a difference.

I will look into it next week. I will probably want to use WS3 anyway so please don't waste any more time on it, I just saw that there was a patched version of 4 and thought I would try it.

Re: Gemini 80-Bus System
 

Well - I am surprised by ws4 - your floppy system has more memory available to programs than my hard disk system and I have checked document mode does not work on xbeaver without VPM/M.

Just to compare xbeaver with VPM/M has 6400 more bytes of memory compared to your floppy system. WS4 works ok with that :-(.

You should be ok with WS-SVC or NW

One star for VPM/M please !

See http://81.105.120.101/xbeaver/operating_systems.html for more detail on the VPM/M memory layout.

Re: Gemini 80-Bus System
 

Your version of CP/M has a different sign on banner to mine - I wonder where it came from?

Re: Gemini 80-Bus System
 

I added it to indicate the dpb change for the 80 track qdds 788k disk images.

Re: Gemini 80-Bus System
 

I have just been reading about Richard Beal's SYS which appears to have been supplied as source for adapting to both Nascom and Gemini systems. SYS seems to be a great way to adapt and re-adapt the bios part of CP/M and supports all manner of floppy disk formats. The last version which, if the purchaser could show they had the Gemini HD system, would include the SYSb6a.MAC module thereby including Winchester support. I am wondering if this may be a way forward for me.

This would rely on me obtaining SYS with the SYSb6a.MAC module? I think the version was SYSB15 which was compiled to SYS.COM. Even if this isn't the best route for me, it would be great to get this archived.