View Full Version : upd765 minimal code for initial program loader

September 3rd, 2010, 04:55 PM
With help from several on this list and others, my IMS5000sx hardware is basically fixed and ready, and can run code from EPROM and i/o with peripherals.

EPROM space is limited to 2kb on a 2732.

Original Initial Program Loader code was lost years ago when somebody swapped the EPROM.

So I'm having to reconstruct EPROM code to boot CP/M 2.2 from 5.25" FDD.

I'm building this into a cut-down Zapple-based monitor with basic testing and debugging. The main design criterion is compact code, not execution speed. The tighter the code, the more monitor capabilities I can fit in 2048 bytes.

I have full CP/M BIOS source, but the upd765 routines in that are far more complex than necessary for initial program load - they test every conceivable variable at every point, which is fine for a running BIOS but takes up too much EPROM space.

All I need is to read 15 x 256byte sectors from track 0, 16 sectors from track 1, write them to RAM address D000H, then jump to D806 for BDOS entry point and warm boot CP/M. Then BIOS can do its thing.

I've searched high and low, including this forum and Digital Research archive, but all documents or examples seem to be for other cases - eg for 16-bit implementations.

Various "skeletal" loaders always leave out the key upd765 instruction sequence!

Can anyone suggest a source for suitable example Z80 code, or step-by-step coding tutorial for 8-bit upd765 FDD controller?

Any help appreciated.


September 3rd, 2010, 05:14 PM
Have a look at the code from the Herb Johnson (Compupro and Andrew's N8VEM boards) (http://www.retrotechnology.com/herbs_stuff/d_comp.html).

September 6th, 2010, 05:58 PM
Thanks Chuck - I've got hold of the monitor and test code you suggested and will work through those.

Andrew has also suggested I might be able to use or adapt working code from routines written for one of his N8VEM boards to drive upd765 controller.

Is there any merit in considering non-DMA disk read? I'm wondering if this would be simpler, shorter code and maybe shortcut some read-write buffering.

For this purpose, speed of execution is not significant.

Where might I find discussion or examples regarding DMA v. non-DMA?


September 6th, 2010, 06:17 PM
Well, DMA is nice because once you've started it, you don't have anything to do until you get an interrupt, then you need only read the result codes. If you're not using the "drive ready" line, you've got another complication. If the "ready" line is simply tied true (as it is on the 5150), a "not ready" condition will cause the 765 to hang and necessitate an external reset. That means that you'll have to also have a deadman timer to detect the not-ready condition. With DMA, you can sit in a timed CPU loop waiting for the hang. When running multi-thread operating systems (e.g. MP/M), you initiate a disk operation and don't get called back until the operation is complete.

So, yes, there are advantages to DMA.

When the 765 is used in a real 8" drive system the way it was intended, it's pretty nice--you can do overlapped seeks on multiple units, interrupt on not-read-to-ready transitions, etc. By tying "ready" true, you give up a lot.

September 7th, 2010, 12:35 AM
Jacob Nevins disassembles the PCW boot ROM at the bottom of this page (http://www.chiark.greenend.org.uk/~jacobn/cpm/pcwboot.html); that loads the first sector from a disc and jumps to it, in 256 bytes.

September 7th, 2010, 08:40 AM
Thanks for the Amstrad link, John. I've successfully modded a Joyce to handle 720K floppies on boot (it's just a byte in the boot sector). It should be observed that the PCW does make use of the "drive ready" line.

As a bit of contrast, the original Tarbell S100 controller used a 32-byte bipolar PROM to run its boot program. (It used the WD1771, which in general, is easier to work with than the 765).

September 14th, 2010, 04:20 PM
Thanks for all this advice. It prompted me to go back to review the BIOS source code for the system, which I have on a known-good disk image.

It seems I may be able to cram the boot/warmboot code into the 2732 together with barebones monitor code and device intitialisation. The system disks are configured for a single-stage system load - ie. the EPROM code loads the whole 2k CP/M BIOS, not just a boot sector.

This means using DMA. The other conclusion, supported by Chuck's post here, is that I can't practically bypass the hardware interrupt handling routines, though I can save some bytes by limiting error handling to a simple fail and reboot to monitor.

The idea is that initial load (2k system) will jump to a full warmboot under control of the loaded BIOS. The warm boot can do the detailed error-checking. Errors at initial load can be tracked down using the EPROM monitor which has breakpoint, examine and substitute capability.

Current task seems to be to get the hardware interrupt handling to work properly.

Thanks all,

September 24th, 2010, 04:51 PM
The magic "A>" has appeared and my stash of 20 year-old 5.25" floppies is now being read again. Warm Boot code from BIOS.ASM solved the upd765-specific issues, and careful analysis of system tracks lifted from a known-good diskette indicated what need to be modified. When that "A>" finally appeared after 20 years absence, I felt the joy last known when a child was born!

I've been posting here for about a year, starting as a novice in s-100, and getting a lot of useful advice that has contributed to restoring this old machine, including some offline help from Forum members in many different areas of inquiry.

Thanks to all.

Herb Johnson has been a keen off-line coach and has kept a chronicle of my progress from inarticulate blunderer to modestly-successful restorer.

Anyone interested in the process that someone like me can undertake, thanks mainly to Web resources and community goodwill, can see that story and references to my sources of help at http://www.retrotechnology.com/herbs_stuff/thwaites.htm.

Next stages for me are:

1. Get my second FDD (TandonTM100-2) working

2. Identify appropriate software (or Assembler source code) for serial RS232 i/o data and file transfer between CP/M2.2 and PC environments (DOS, Windows or Linux)

3. Return attention to revival of VT100 console with power-supply and character generator issues.


November 3rd, 2010, 05:54 PM
An update on this:

1. 2nd Tandon FDD now operational - speed adjustment, radial alignment, and also a strange distortion in the diskette slot frame that was pushing the diskette down too hard on the fixed (bottom) head. This bent the diskette surface over the head and prevented good contact with the spring-loaded (top) head. Easily fixed once identified. Has anyone experienced that sort of diskette slot misalignment before?

2. For s-100 to PC data transfer, went for a 1983 Modem7 with specific IMS5000 overlay because lightweight, available on Walnut Creek CDROM, and as capable as I need. On PC end, Hyperterm with Xmodem protocol is providing good transfers both ways with CRC verification. All I need.

3. VT100 power supply - original still with unidentified fault. Planning to use AT supply but need to synthesize -24vdc and bump up -12vdc to 1amp for VT100 specs.