Announce: uRTC-8 universal RTC for the PCW and other Z-80 computers

[torrind]

Thanks Geoff, your version worked!!


Top job as always.




Darren

[GeoffB17]

Darren,

Thanks for the note.  Happy to be able to help.

I'd be interested to hear that the INITDIR works fine with the Gotek drives as well.  The computer should see the image EXACTLY as it would a real disk, so it OUGHT to be able to manipulate the directory section of the .DSK (or whatever) file exactly as it would an actual disk.   I assume the process accesses the disk sectors directly.

Don't forget that the uIDE drives will have capacity for 384 files (max, dep on file sizes and 'extents') instead of the original 512.   The use of SET applies drive by drive (and disk by disk) so there could be cases where it's better to NOT use INITDIR.

I'm not sure how Jon's file has lost a byte, but I think Jon uses RS232 data transfer to move files between CP/M and PC, so I guess that somewhere along the way he's transferred the INITDIR.COM file and the link has dropped a byte.   So everything after that point has been one byte out, which will seriously upset the program.  Might have done something much worse than merely lock up the computer??

Geoff

[torrind]

Thanks Geoff...


INITDIR appears to work perfectly with Gotek drives and I have successfully timestamped files added to both A: and B: drives.


As an aside, I can't do the C: drive as there isn't enough room (im guessing because of c0: c1: c2: etc etc) is there anyway of doing this other than removing all files from each drive?


Darren

[JohnElliott]

CP/M time stamps occupy every fourth directory entry, so INITDIR won't work on a drive where over ¾ of the directory entries are in use. You'll need to move some files off until fewer than ¾ of the entries are in use - there is no way round that.

SHOW x: [DIR] gives the number of free directory entries

SHOW x: [DRIVE] gives the total number of directory entries.

[JonB]

Just a note to say uRTC is live!!!   - it was all down to DDCC (Darrens Dodgy Cable Crimping)

Phew!

[GUNHED]

Sorry guys, I kind of lost track... are they now available?

[JonB]

Yes, though I am now waiting for some more clock chips. So there will be a short delay if you want one.

[GUNHED]

Yes, though I am now waiting for some more clock chips. So there will be a short delay if you want one.

Well, I would like to take two of them. Doesn't matter if I need to wait. Maybe you can add two of the IDE adapters for the PcW too. Would save postage. 

[JonB]

For sure. Fortunately I just got a new set of uIDE boards...

Do you need a DOM or adapter boards with them?

[GUNHED]

For sure. Fortunately I just got a new set of uIDE boards...

Do you need a DOM or adapter boards with them?

Actually, I would need two complete working sets (for a friend and me). Please PM me as soon as you have them ready for shipping. I'm looking forward to this since decades. 
Oh, and everything external if possible. If not then I don't mind taking an internal board(s). 

[JonB]

I can build one external adapter at the moment. It's the edge connectors, I have one left. Do you want the lite or video version? Refer to the wiki page for details.

Just to remind you, uIDE can't boot the PCW yet. You boot using a floppy then everything runs from the DOM. You need CP/M Plus v1.15 or later. There's an image download link on the wiki page.

[GUNHED]

Hi, the wiki page is huge. Lot's of work done. However from scratch I can't find the difference between light and video version. In case the video version has more features I'll go with the video version please.

[JonB]

The difference is that the Video version incorporates a composite video connector, which you don't need unless your screen has failed.

[GUNHED]

Ah, thanks! That's a cool feature actually. Since the monitors are running well I would prefer the lite (non-video) version. 

[torrind]

Bad news All!

My uRTC has died. The first issue I experienced was the error as per the attached pic (Pic 1)

I used the uRTC command to put the date and time back to normal, typed 'DATE' again and all was fine. I rebooted and the same thing happened again. I then changed the date and time again and rebooted. Now I get "URTC timeout during read operation"

I had a spare RTC chip which I replaced but this didn't work. I also replaced my cable just in case and swapped over the 688N IC but no joy.

Pic 2 shows a survey dump -

Any ideas folks?

Thanks,

Darren

[JonB]

Well the first thing I see is you are using an old version of URTC.COM with -tp argument - this had an option for the Superbrain (-ts) but I later separated them into two COM files. The earlier version also had a few bugs in its date derivation code. So if I were you I'd try the later version first. Oddly I didn't update the version number - still says v0.2 but the help message is different.

Second thing I see is a missing space in the uIDE XDRIVER signon prompt. I would not have released it like that (I'm a bit of a stickler for prettyness).

So I am wondering if your drive has got corrupted. uRTC is a dead simple design and there is very little that can go wrong. In fact, it is so simple that I didn't even bother prototyping it before sending it for board production.

Looking at your SURVEY.COM output, I see C0-C7 missing. uRTC uses C0-CF (thanks to Epson's chip interface) and so all of these should be listed as active. You've only got C8-CF showing and this suggests a problem with the connections to the clock chip. If you have a multimeter, please check the following connections for continuity:-

Clock chip pin 4 to CPU A0
Clock chip pin 5 to CPU A1
Clock chip pin 6 to CPU A2
Clock chip pin 7 to CPU A3

Or, if you have a logic probe, see if the clock chip pins are active by probing them for activity. If they are flashing then you know they are connected to the CPU.

Next, test the 668 in the same way. Pins 2, 4, 6 and 8 are A7-A4 respectively.

If those are OK, put the probe on the /CS0 pin of the clock chip (pin 2) and try to run uRTC (no arguments needed). If there is activity then you know the 668 is working and selecting the clock chip.

If all else fails you'll need a new clock chip. I do not know if they are known for fragility. If you want to send me one or more chips to try in one of my units, PM me.

[torrind]

Hi Jon,


Thanks for the comprehensive instructions - I started by updating the uIDE driver which has now sorted out the space issue. I'm sure I was using the newest uRTC driver but I downloaded it again with no success. How do I confirm that im using the newest version of this driver please?


Looking at the next set of tasks for checking the physical pins of the RTC IC, you mention checking chip pin 4 to CPU A0 first? Although I know where chip pin 4 is, I don't know where CPU A0 is. Can you advise as I'll also need to do the same with checking the 668 connections.


PS. my RTC IC has slightly different numbering on it to yours supplied on the uRTC = "RTC72421 B EPSON 1742C" although I don't think this is an issue.

<EDIT: I also created a brand new v1.12 image onto a spare DOM just incase of any corruption. This didn't change anything either.>



Regards,


Darren

[JonB]

Hi Darren

Your RTC chip should be ok to use.

Google "Z80 pinout" to get a diagram of the processor with the pins labelled. When testing continuity do not have the computer switched on.

Issue the command "URTC -h" and tell me what it says.

Make sure you are using -t (not -tp) in your profile.sub.

Cheers
JonB

[torrind]

Hi Jon,


All working again!


Basically, I continuity tested the pins on the two IC's to the CPU pins as suggested and all tested fine except 668 pin 6 to CPU pin 6 - I checked the connection and realised this pin wasn't soldered on the uRTC. I soldered it and this then worked OK, however, the clock still couldn't be found.


I then changed the RTC chip to one of mine again and this didn't work, but I left it in.


Finally, whilst I had the iron out, I re-soldered all pins on both the 668 IC and the RTC IC. This cured the problem and everything worked again 


The only issue I then had was that after issuing a date and time change to the uRTC, I noticed that the uRTC didn't increment the time, it stayed the same date and time as per my original values. To cure this, I put your original RTC IC back in - It seems that whilst similar, my RTC ICs don't work.


Anyway - All sorted. Thanks again for the help.


Darren

[JonB]

Hang on a mo - are you saying I missed a pin when I soldered the socket in? 

If so, apologies for that! Not sure what was the problem with the other joints - I use good quality Kester 60/40 lead / tin solder with rosin core and I have a Hakko temperature controlled iron so I am surprised some of the joints were unreliable... again, sorry.

[JonB]

Quick update on availability.

The next batch of clock chips still has not arrived, although the arrival estimate is not in the past yet so I cannot complain to the seller. I have ordered another batch from a different company (also Chinese) and hope to see them before the end of the year. As soon as I get them I'll be building more boards.

Thanks to all who are waiting for your patience!

[GeoffB17]

Hello Jon,

Just a note to report that my uRTC is working fine, no problems.   I'm keeping an eye on timekeeping, and I've noticed almost no time slippage so far - maybe a few seconds over a month or so.

I've not yet done very much regarding setting up some disks to make full/proper use of the time settings, but it's just a matter of time.  Time to spend, that is.  Worth doing with some disks, maybe not so useful with others.

Thanks again.

Geoff

[JonB]

I am still waiting for new clock chips, darn it.

In the meantime I made some uIDE boards which didn't work properly. After a lot of head scratching I discovered the problem - a sub standard batch of LS668 comparators which don't work properly when bombarded with valid IDE data reads. Changing these for another brand I have in my parts bin makes the uIDE work properly. Bit of a relief... however, this same batch is used in the uRTC board. So if you are experiencing intermittent problems try to swap out the larger chip.

As a side note, the conditions under which the uRTC registers are accessed are much less rigorous than the uIDE data read operation. This may be why it seems to be OK in the uRTC application, but not in uIDE.

[JonB]

Typical - moan about late chips one day, then they turn up the next day! 

I'll be reaching out to everyone who has requested boards today. With luck you might get them by Christmas...

[attach=1]

[GUNHED]

Wonderful! Please PM me your PayPal and the amount of cash I need to send.