On Thursday (01/29/2009 at 07:22PM +0000), Tony Duell wrote: I'm counting on that :-) OK. Thanks for that tip. I don't know yet which style it is as I have not opened the unit up. But, lacking the docs at this point, that is the next step. It does correctly punch the feed holes and will appear to do so all day long. It's only when I press the button with the big black dot that it attempts to punch all eight holes and stalls. The feed hole punching screws up then too. Will find out in a day or two as soon as I receive the round tuits that I ordered for the weekend. I appreciate the info. Chris

Hello, I have rewritten my old systems CP/M 2.2 CBIOS to add an IDE Drive. I've run into a problem that has me stumped. Everything works as long as I don't try and copy or assemble a large Assembly file (>80KB). I will be going along fine and then out of nowhere I will see CP/M request access to Drive "T". My debug info says SELDSK is requesting Drive 0FF00h. I have added debug code to all the CBIOS routines so that they report what they are doing to the console (slow but nice). I've gone through my code many times and tested each routine via an embedded debug monitor. I believe I have added every CP/M 2.2 patch (1-6 and 9)that is specific to the CBIOS including those dealing with Blocking/Deblocking. In the back of my mind I kept wondering if I was exceeding CP/M's Stack Depth. I can find no information on the web or in my doc's that specifies what the maximum Stack usage is for a CBIOS. Do any of you have any thoughts on my Stack Question? Are there other issues with Blocking/Deblocking that become visible with large Disk Drives, and that are not covered in any of the published DRI patches? Thanks for your assistance. Robo

Hi Chuck, Thanks for the reply. My IDE drive is about 2GB which is overkill and beyond the capacities of CP/M 2.2. So I'm only using 20MB of the drive for this project. My system uses Interrupts for Floppy but polling for the IDE. In the mid 70's and early 80's I did lots of CBIOS work and never ran into stack problems with CP/M. Maybe the code was simpler and I used fewer Calls, Pushes and Pop's. I am currently using a Private Stack for some of my CBIOS debug routines since they are more stack intensive. Did you find that you had to make any other changes to the Blocking/Deblocking code other than the recommended CP/M 2.2 patches for success? Thanks Robo -----Original Message----- From: cctech-bounces at classiccmp.org [mailto:cctech-bounces at classiccmp.org] On Behalf Of Chuck Guzis Sent: Friday, January 30, 2009 7:29 PM To: General Discussion: On-Topic and Off-Topic Posts Subject: Re: Stack Depth requirements for CP/M 2.2 CBIOS On 30 Jan 2009 at 19:08, ROBO5.8 wrote: I 0FF00h. embedded 9)that What do you mean by "large"? I've run 2.2 with disks up to 20MB with no problems. CP/M's stack can't be depended upon for much space at all. Since my BIOS code was interrupt driven, every interrupt service routine started with a change to a private "system" stack. I recall having a lot of problems before doing that. Cheers, Chuck

Hi, I am looking to borrow, rent or possibly purchase a working Z80 In-Circuit Emulator. If anyone has one I would appreciate their assistance. Thanks Robo

On Fri, 2009-02-20 at 10:40 -0500, ROBO5.8 wrote: Yo, I don't have an emulator but I do have a "Prolog M824 Z-80 System Analyzer" that I'd be willing to part with. I haven't plugged in in this millennium but, I'd be willing to bet it still works. I have the pod with the CPU clip, and original briefcase style carrying case, but no manuals. It's in excellent condition. Doh... I was wrong. I do have an in circuit emulator "somewhere". It's a small box that plugs into the Z80's socket. It has a RS232 interface for programming and a monitor/assembler in ROM. Once again, I haven't powered it up in many years but, believe it would still work. I do have a manual for this thing "somewhere". I used the emulator on a small STD BUS project I was working on and it did a great job. It's an excellent tool for low-level debugging and hardware development. Sorry, I can't give them away but, If you're interested in making a "reasonable" offer, contact me off list. Steve Robertson steerex [at] ccvn [dot] com

Just a general maybe way off the wall comment. I have done this several times, and hand wired lots of z80s. In every case where its a almost run, it is power. Have you put a scope on vcc and see that its rock solid? You describe a random case it fails at different points, this has to be either power to cpu, or buffers and eproms not presenting the cpu with valid data. There is no other cause, and a emulator wont help you find it. This is hardware, look at, with 2 probes the buffered I/O on each bit (in, signal, out signal). Brute force replace any buffer drivers. Who else is on the same wire, remove any shared bussed devices, I hope they are sockets. The problem that it is chip failures is almost zero. It is power, a bad decouple cap somewhere, like when all address lines roll and the buffer chip pulls a slug, sagging the rest down. Look at all address and data lines on the scope, should be a clean cat eye with never a trace in the middle or floating. This is fun stuff, enjoy. Randy _________________________________________________________________ Windows Live?: Discover 10 secrets about the new Windows Live. http://windowslive.com/connect/post/jamiethomson.spaces.live.com-Blog-cns!5…

Hello, A kind poster mentioned that I should have given the list my general location so members would better able to assist me. I am located in the NY City Metro area. Please advise if you have a Z80 In Circuit Emulator available. Thanks Robo

This sounds a bit like the GNT Model 34 mechanism, which I have the service manual for. In this punch, the punch pins are controlled by solenoids in a little slot-in moduke (8 solenoids and some simple linkages), there's a motor-driven camshaft and a couple of external soenoids for tape feed. IIRC the solenoids in that machine are similar to the coils used in 'Continntal' relays. The GNT 34 is suprisingly easy to dismantle, but only if you know the tricks. For example, the seletor unit (solenoid module) slides out after releasing a spring catch, the camshaft comes out from one side after loosening the bearing retainer, and so on. If you try to start by separating the side plates you get in a mess very quickly (please don't ask...) -tony

I think I;d have reduced the number of trial-and-errors by (a) looking at the state of the (5) model-select pins on that UART chip. They define the word size, parity and number of stop bits. And then I'd have hung a counter off the Rx clock pin of the UART (pin 17 IIRC) and measured the frequency. It's 16 times tbe baud rate. My guess is that it'll keep up with the 300 baud data stream (i.e. 30 cps) and not need any flow control lines. That was quite common in paper tape punches -- the maximum available baud rate corresponted to the speed of the mechanism (or a litttle less). It can't be that complicated... Noe's the time to learn the gentle art of tracing out a schematic... -tony

Kheireddine Saidi wrote: ... In what way did it not work? Did anything happen at all when you sent serial characters? Is the power supply OK? You haven't given us much information to go on! -- John Honniball coredump at gifford.co.uk

On 17 Sep 2010 at 18:57, Tony Duell wrote: Also, there might be a set of jumpers to change from current loop to RS232C. Many (if not most) punches tended to use current loop, parciularly in CNC applications, so it's a pretty fair guess that that's the way this one is set up. --Chuck

Yes, the PSU inside the punch. Many of use have discovered the hard way that elecrronic stuff doesn't work unless it's getting the right power, and that PSU problems are common (I am one of the ones who has spent a long time tracking down nasty faults before realising the PSU is not doing what it should be...) That sounds as though it's working properly, though. Sounds OK. Any port that claims to be RS232 compatable should send <-3V for one state and >+3V for the other. Most desktop machines swing between =112V and +12V, I am told some laptops have a much smaller swing than this (but my _ancient_ laptops generally use -12V and +12V). But anyway.... Most RS232 devices of that sort of vintage use a 1489 receiver (or a 75189 which is much the same thing). This chip will take -ve input voltage sithoug damage, but it has a single threshold of IIRC, a little over 1V. That is, a swing from 0V to 3V would be OK. So wouid -3V to +3V, Or -12V to +12V. I shouldn't say this, but you can feed a TTL level signal into such a receiver chip and expect it to work. I've done this a few times fro testing, I would enver do it on a deviec that was to be used by someone else. What I would do next is a little conection-tracing inside the punch. Where does the RxD (data input pin (3?) on the DB25 connector) go? Can you trace it to an RS232 receiver chip like a 1489? If you have a logic probe or 'scope, does the output of the appropriate section of this receiver change state when you send data to the punch? Is ther a recognisable serial chip? Either a 'dumb' 40 pin UART, like a 6402 or a microprocessor bus chip (6850, 6551, Z80-SIO, 8250, 8251, etc). If you can find one, is the serial input (receiver input, whatever) pin of that changing state when you send data from the PC? If not, what is between the line receiver and the serial chip? Maybe some jumpers to select a currnet loop interface (as others have suggested). -tony

Hi, I got it working, well, what I have is a parallel interface GNT 3601 puncher rather than a serial one. Thanks to chris for the document. Actually I'm still having a timing problem, some bytes gets missed while others gets punched twice. I'll see how I could solve it (I'll probabely be checking the ack line but i got to make an other cable). It's a software problem. Then I think thats an advantage of the serial interface over the parallel. Sure the parallel is faster at punching, but I have time :-p I would had preffered not having to worry about synchronization than to punsh faster. I could send the parallel pinouts if someone needs them. Thank you people, tsch?ss S. Kheireddine